fix(storage): keep the compact root partition

[dormancygrace]

Summary

Keep the root partition supplied by the NanoKVM image instead of rewriting it at every boot.

The official v1.4.3 image already contains a 1.5 GiB p2 root filesystem. This change:

• removes both online p2 partition resizing and the background resize2fs call;
• leaves the shipped root filesystem unchanged;
• derives a new p3 start from the live p2 start and size reported by sysfs;
• aligns p3 to the next 1 MiB boundary;
• preserves already-expanded legacy p2 layouts without ever shrinking them;
• propagates partition-creation failures instead of creating the marker first.

Why keep 1.5 GiB

The previous script expanded p2 to the end of the card, shrank it to an 8,192,000,000-byte boundary through an interactive prompt, then grew ext4 in the background. This was risky and also consumed several additional gigabytes that are more useful in the data partition.

The official image geometry is already:

• p1: sectors 1..32768 (16 MiB)
• p2: sectors 32769..3178496, 3,145,728 sectors (exactly 1.5 GiB)

Reducing p2 to 1 GiB would require rebuilding and shrinking the image filesystem offline; it cannot be done safely to a mounted 1.5 GiB root at first boot. It would also leave relatively little growth margin above the reported approximately 776 MiB full installation. Keeping the existing 1.5 GiB image therefore requires no extra operation and still supports 8 GB cards comfortably.

Resulting layout

For an official image, p3 starts at aligned sector 3180544 (1553 MiB). On an 8 GiB test disk this leaves a 6.5 GiB data partition while p2 remains exactly 1.5 GiB.

For a legacy card whose p2 was already expanded to sector 16000000, p3 starts at aligned sector 16001024. Existing p3 partitions are not modified.

Validation

The current revision adds docs/storage-layout.md and README guidance on card capacity, preserved legacy roots and data partition placement. The partition-layout regression suite passes again.

• make test-partition-layout: passes official-image geometry, legacy 8 GB root, already-aligned geometry, invalid start, zero size, invalid alignment, and parted failure cases
• dash -n passes for S01fs and the test script
• ShellCheck 0.10 reports no findings other than the pre-existing informational warning for sourcing /etc/profile
• git diff --check passes
• verified the real official v1.4.3 image with fdisk: p2 is exactly 1.5 GiB
• applied the generated parted command to a disposable sparse 8 GiB disk image: p2 stayed at 1.5 GiB and p3 was created as sectors 3180544..16777215 (6.5 GiB)

Dependencies

None. This operates on the application data partition at boot and does not depend on the SDK memory-map PRs.

Try NanoKVM OS

You are also welcome to try NanoKVM OS, a beta firmware for NanoKVM Cube and PCIe that brings together our video, networking, USB and memory improvements. Feedback from real devices is very welcome! Please read the README for the current beta limitations.

[RubenNL]

Is there a reason to have 8GB reserved for the "root" partition? A full installation seems to use just 776.3MB.

Reserving 2GB for this partition should be enough for all use cases, while still allowing users with a 8GB SD card to use the product as intended.

[dormancygrace]

Agreed — the 8 GB root reservation is unnecessary. I checked the official v1.4.3 image and p2 is already exactly 1.5 GiB (3,145,728 sectors), so I updated the PR to leave p2 unchanged and derive the aligned p3 start from the live p2 geometry. On an 8 GiB test image this keeps the 1.5 GiB root and creates a 6.5 GiB data partition. I did not choose 1 GiB because that would require shrinking/rebuilding the image filesystem offline and leaves much less margin above the reported ~776 MiB installation.

[RubenNL]

Thanks :) this should allow me to use a 8GB sd card with iso files. I could even go for a 2GB card.

This should also be mentioned in the docs: "minimum sd card size: 2GB, 4+ recommended for iso file storage".