feat(resize-data): expand data partition to fill disk on first boot

[JoergZeidler]

Summary

• Adds a compile-time resize-data Cargo feature that expands the data
  partition and its ext4 filesystem to fill available disk space on first
  boot, guarded by the resized-data bootloader environment variable so
  it runs exactly once.
• Splits mount_partitions into mount_core_partitions (rootfs + boot)
  and mount_remaining_partitions (factory / cert / etc / data) so the
  bootloader can be created after boot is mounted but before the data
  partition is touched.
• Implements src/mode/resize_data.rs with GPT (sgdisk -e) and DOS
  (extended partition resize via parted) branches selected at
  compile time via #[cfg(feature = "gpt|dos")].
• Integrates resize as a first-boot step in mode::normal::run, called
  before mount_remaining_partitions.

Reason

When an omnect OS image is flashed to a disk larger than the image itself
the data partition occupies only the space baked into the image; the
remaining disk space is wasted unless the partition and its filesystem are
expanded on first boot. This ports and integrates the existing
resize_data branch implementation into the feat/boot-mode-dispatch
architecture.

Verification

All eight feature combinations pass:

cargo test --features grub,gpt
cargo test --features grub,dos
cargo test --features uboot,gpt
cargo test --features uboot,dos
cargo test --features grub,gpt,resize-data
cargo test --features grub,dos,resize-data
cargo test --features uboot,gpt,resize-data
cargo test --features uboot,dos,resize-data

- cargo clippy -- -D warnings clean across all eight combinations
- cargo fmt -- --check clean
- cargo audit — no vulnerabilities (28 crates scanned)

Spec/Plan

Used Spec:
2026-05-04-resize-data-design.md

Used Plan:
2026-05-04-resize-data.md

[JanZachmann]

Code review of the resize-data feature. Functionally sound and well-isolated behind the feature flag. The two items I would block on are the cert/factory mount-order change (intentional? please document) and the redundant .map_err(InitramfsError::ResizeData) calls (cleanup, since #[from] already does the conversion). Other comments are minor style/test-coverage items. See inline.

[JanZachmann]

All 8 review findings addressed. Verified at f50a030:

• factory → cert mount order restored ✓
• module doc-comment uses omnect_resized_data ✓
• _rootfs parameter removed (signature + caller in mode/normal.rs) ✓
• redundant .map_err(InitramfsError::ResizeData) removed throughout — bare ? via #[from] ✓
• CLI literals hoisted to SGDISK_MOVE_BACKUP_HEADER, PARTED_RESIZEPART, PARTED_RESIZE_FULL, PARTED_PRINT, E2FSCK_FIX, RESIZE2FS_FORCE ✓
• one-shot guard tests added with MockBootloader ✓
• 6× duplicated safe: TempDir comments removed ✓

cargo test clean across all four resize-data feature combinations (grub,gpt,resize-data, grub,dos,resize-data, uboot,gpt,resize-data, uboot,dos,resize-data).

One non-blocking follow-up note left on the ensure_mtab thread — the new tests there don't actually call ensure_mtab(). Approving since that finding was originally optional and the function itself is correct.

[mlilien]

that reads funny: the bootloader loaded kernel and the kernel loaded omnect-os-init.
the init process will not create a bootloader. please ask your agent for renaming options.

[JoergZeidler]

AI answer to choose the correct method name.

---

The function constructs a Box<dyn Bootloader> — a Rust object that reads/writes the bootloader
environment (grubenv file or U-Boot fw_printenv/fw_setenv). It does not create a bootloader.

Naming options:

Name	Notes
open_bootloader_env()	Most precise — it opens the env storage
init_bootloader()	Common systems pattern, slightly ambiguous
bootloader_env()	Short noun-form factory
platform_bootloader()	Emphasizes the build-time selection

Recommendation: open_bootloader_env() — directly describes what happens and aligns with the
existing BootloaderEnvKey / get_env / set_env naming in the codebase. Call site reads naturally:

let bootloader_opt = match open_bootloader_env() { ... }

---

open_bootloader_env sounds good to me. Documentation will be updated after finalize the method name.

[JoergZeidler]

changed to open_bootloader_env...

[mlilien]

why wouldn't it exist. what was the reasoning for that? imho very unlikely it isn't there. please ask your agent.
not a change request, though.

[JoergZeidler]

AI answer:
In initramfs we're running before switch_root. The initramfs root is a minimal tmpfs/ramfs — /etc/mtab is not part of it. The real rootfs (where /etc/mtab
lives as a symlink to /proc/self/mounts) hasn't been switched to yet. resize2fs reads /etc/mtab to check whether the device is currently mounted; without
it, the check silently degrades or errors. The guard creates the symlink on first run so resize2fs can do its mount-state check correctly.

[mlilien]

imho that warning makes no sense. we don't want to skip update-validation. imho that is not a warning its an unrecoverable error. you probably even don't have a valid root then. if not now, then at least at the next boot.
also the naming "Bootloader" is not good.

[JoergZeidler]

in case we have no access to the bootloader environment, we have no idea about performing update-validation or not. Should we stay in init process, or reboot the device, or try to boot the rootfs.

[JoergZeidler]

warning message is changed

[mlilien]

why does it comment that for grubenv only? ... this is not the grub path, correct? its for all implementations of bootloader environment.

[JoergZeidler]

that's true, comment changed.

[mlilien]

3 tests for the mtab handling, which is most probably not necessary.

[JoergZeidler]

mtab currently used. the parameterized helper exists and the tests are real — removing them would decrease coverage with no code benefit.

[mlilien]

this feels like code duplication. why can't you reuse the available fsck implementation? in case errors where corrected, you have no fsck result.

[JoergZeidler]

crate::filesystem::fsck implementation records CORRECTED as a distinct state in the bootloader
environment and requires a bootloader reference.
Here we need neither, this is a transient pre-resize check with no persistent result.

[mlilien]

so modes are not mutual exclusive?
why is the resizing part of the "normal" bootmode? what is a bootmode which is not normal then?

[JoergZeidler]

resize-data is a transparent first-boot operation that runs during normal boot. New boot-mode will be present in features factory-reset/flash-mode...

[mlilien]

so wie only have normal bootmode?

[JoergZeidler]

yes, now we have only normal mode, resize-data is part during first-boot in normal mode. Next feature factory-reset will be added as own mode.

[mlilien]

why is that in the mode dir?
it seems it didn't get a mode, as suggested by the previous PR.

[JoergZeidler]

resize_data.rs is in mode/ because it was designed alongside the boot-mode dispatch architecture. Since resize is not a BootMode variant, a case could be made for moving it to filesystem/ or a standalone resize/ module. However, it uses Bootloader and PartitionLayout the same way mode handlers do — and future modes (factory-reset) follow the same pattern.