[JanZachmann]

Summary

Ports flash mode 1, cloning the running disk onto another block device, from the scripted initramfs to the Rust initramfs, together with the shared flash layer that modes 2 and 3 will build on.

• src/mode/flash/ holds the trigger keys flash-mode and flash-mode-devpath, the partition-table dump rewrite, in-process replacements for the legacy dd calls, the rootfs unmount, the EFI boot-entry handling and the clone sequence.
• BootMode gets a Flash variant, dispatched before init_setup: a flash mode clones the whole disk, so the init-setup work on the running disk would not be carried over.
• The destination is compared with the booted disk by device number, so the booted disk and its partitions are refused under any name. A partition of any other disk is refused too. Both checks run before the first write.
• A flash mode queued together with a factory reset is refused, and both triggers are cleared.
• The logger can keep the run in memory. It is written to flash-mode-1.log on the source data partition on success and on failure, because the device powers off afterwards.
• Raw copies sync the destination, so a write-back error fails the clone.
• On EFI machines the init mounts efivarfs, creates the new boot entry and only then deletes the old ones, so a failure in between leaves the machine with a boot entry.
• reformat_ext4 moves to src/filesystem/, so images without factory-reset can use it.

Legacy bugs fixed rather than reproduced: the device wait reported a timeout when the device appeared on the last poll; the DOS extended-container size was wrong on every DOS machine; and the partition-UUID refresh also ran on MBR, which has no per-partition UUIDs, so mode 1 failed on DOS. The U-Boot environment size and offsets are in KB; reading them as bytes would have written 64 bytes of a 64 KB environment.

Reason

The scripted initramfs is replaced module by module. Mode 1 comes first because modes 2 and 3 reuse most of what it adds.

• flash-mode-1 is in the default feature set, like the legacy script that every image installs.
• The recipe has to pass the partition and bootloader constants into the build and install e2fsprogs (for e2image) and, on EFI machines, efibootmgr; feat(initramfs): replace the scripted initramfs with omnect-os-init meta-omnect#697 does both. Without the constants, mode 1 fails before the first write.
• The recipe always builds with gpt, so CI does not run the DOS paths.
• When flash-mode cannot be read, the device boots normally and a queued factory reset waits for the next boot, since a conflict between the two cannot be ruled out.
• The clone writes to the source disk only to clear the triggers, to store the run log and, on EFI machines, to rewrite the NVRAM boot entries.
• Inherited from the legacy script (spec §9.1): the clone keeps the source's disk identifier and most partition and filesystem UUIDs, so a lookup by UUID is ambiguous while both disks are attached.
• A test pins the clone step order of spec §4.1 through a CloneOps trait, and the EFI order through EfiOps.
• The partition UUIDs are generated before the first destructive step, from /dev/urandom, so a failing random source is an error and not a panic in PID 1.
• One EFI boot entry instead of the legacy pair is decided in spec §10.2, but needs an EFI hardware run before it ships. That run also confirms the efivarfs mount.

[JoergZeidler]

Ran fmt, clippy for eight feature combinations (grub,gpt and uboot,dos with test-utils, with factory-reset, with factory-reset,resize-data,release-image, and --no-default-features for both), tests for ten combinations (229 to 429 tests each, all green), cargo audit, and the armv7 clippy from the README: all green. --no-default-features --features grub,gpt,flash-mode,test-utils fails -D warnings, which the README already calls unsupported.

Checked against the legacy flash-mode-1 and common-sh in the meta-omnect history: the three bug claims in section 9 hold, the dump rewrite formulas and the dd replacements match, and the KB units of all five build constants match the .wks files and omnect_conv_size_param. uboot-env.bin is exactly UBOOT_ENV_SIZE KB (mkenvimage -s), so the Some(size) copy length is right.

Labels on every comment: High, Medium, Low; "blocks merge" where I would not merge without it. Nothing is Critical: no finding writes the source disk.

Blocks merge:

• clone.rs:229 a partition of another disk is accepted, and sfdisk writes into it before the check fails.
• rawio.rs:102 no fsync; a write-back error on the destination is dropped and the clone reported good.
• efi.rs:16 efivarfs is never mounted; the EFI path needs a hardware run or an explicit mount before this ships (spec 10.2 already says so for the entry count).
• clone.rs:469 the clone sequence has no ordering test and no ops trait; same gap as #25 finding 7.

Points without a diff line:

• The PR text says /sysroot; the rootfs is at /rootfs. See the comment on config/mod.rs:90.
• meta-omnect#697 exports the five constants, installs e2fsprogs, util-linux-sfdisk and efibootmgr on efi, and keeps flash-mode-1 in the default set. Its recipe hardcodes gpt, so every DOS path here is host-tested only, as the PR text says. Its SRC_URI still points at the fork branch.
• Spec, top: No **Status:** line; every other spec in the directory has one.
• Spec, section 7: "logs progress while waiting": the wait logs once now.
• Spec, section 6: One more deviation for section 9: the loader is passed as \EFI\BOOT\bootx64.efi; the legacy script's unquoted \\\\EFI\\\\BOOT reached efibootmgr as \\EFI\\BOOT\\bootx64.efi. Whether the firmware treats both the same I could not verify.
• Not verified: efivarfs on the EFI machines; that the target sfdisk emits sector-size: (util-linux 2.34 or later; an older one fails every clone at verify_sector_scale); that e2image -p reaches the console through inherited PID 1 stdio; where the feature combinations run in CI.

Signed-off-by: Joerg Zeidler 62105035+JoergZeidler@users.noreply.github.com

[JoergZeidler]

Round 2 on the 12 new commits. Every reply checked against the code; all four merge blockers are fixed as described:

• a partition of another disk is refused before sfdisk (REASON_NOT_A_WHOLE_DISK, pinned by a_partition_of_another_disk_is_refused);
• copy_range syncs the destination and reports the write-back error;
• efivarfs is mounted before efibootmgr, and the new entry is created before the old ones are deleted, pinned by the_new_entry_is_created_before_the_old_ones_are_deleted;
• clone_with runs on a CloneOps trait and the_clone_runs_its_steps_in_the_spec_order pins the full sequence for all four bootloader x table combinations, plus the two stop-early cases.

Also verified: the run log is written on failure and carries the error (run_and_persist with a log writer), the kmsg hook is tested through a real KmsgLogger on a temp file, required_constants takes the values, the UUIDs come from /dev/urandom before the rootfs is unmounted, e2image output goes through one pipe to the console and the last lines reach the error, /rootfs in spec, plans, project-context and code comments, the spec status line, and the Devpath enum with BootEnvKey in the error. 56 of 57 threads resolved; the devpath-trim one stays open as Low with a note, and the rebase point is withdrawn (squash-only repo).

Machine checks on the new head: fmt, clippy for eight feature combinations, tests for ten combinations (231 to 443 tests each), cargo audit, armv7 clippy: all green.

Two Low points inline, nothing that holds the merge. From my side merge-ready. The EFI path is still without a hardware run; spec 10.2 keeps that as the shipping condition, now covering the efivarfs mount and the loader-path spelling too.

Signed-off-by: Joerg Zeidler 62105035+JoergZeidler@users.noreply.github.com

[JoergZeidler]

Round 3, head 6a629f0: the devpath is trimmed again with parse_devpath_trims_surrounding_whitespace, the plan no longer names the v4 feature, and the 8.2 row covers the queued factory reset. The second URANDOM_PATH stays, the feature-gate reason holds. All four remaining threads resolved.

fmt, clippy (grub,gpt and uboot,dos with factory-reset,test-utils) and tests for four combinations (431 / 420 / 300 / 443) on the new head: green.

Nothing open from my side. The EFI hardware run stays the shipping condition from spec 10.2.

Signed-off-by: Joerg Zeidler 62105035+JoergZeidler@users.noreply.github.com