Ticket #11690 (closed enhancement: fixed)

Opened 3 years ago

Last modified 2 years ago

OFW should size root partition to fill the disk

Reported by: pgf Owned by: Quozl
Priority: normal Milestone: 1.75-firmware
Component: ofw - open firmware Version: Development firmware
Keywords: Cc:
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking:

Description

currently when installing an image, ofw will create a boot partition and a root partition. the root partition is sized to the filesystem it will contain (at least, that's the end result -- perhaps the partition is resized downward as a last step?).

this may leave much of the disk unpartitioned, e.g., when installing a 4G image on an 8G disk. to be able to take advantage of online resizing (which i believe has become faster), it would be best if the root partition filled all remaining space on the disk, even if the filesystem being installed is much smaller.

(without this initial step, online resize becomes more complicated, since although linux can repartition, it won't use the new size until after a reboot.

see also #10040

Attachments

olpc.fth (4.6 kB) - added by Quozl 3 years ago.
olpc.fth which checks for the second partition being smaller than disk size, and if so extends it to the disk size. may be destructive to any non-standard partitioning. tested on os29. resize2fs can be placed in /etc/rc.local as a test. on a test here, 4gb to 8gb, resize2fs took 1m39s.

Change History

Changed 3 years ago by Quozl

  • status changed from new to assigned
  • next_action changed from never set to design
  • component changed from not assigned to kernel

the partition table is created by olpc-os-builder, not by openfirmware. during fs-update, openfirmware writes the blocks that olpc-os-builder provides.

openfirmware could be programmed to enlarge the last partition to fill all remaining space, or this could be done by the .zd file as a postscript after zblocks-end: ... but this would break fs-verify, unless we compensated by complicating fs-verify. fs-update and fs-verify are used in factory for testing, so i'm not keen to complicate them further.

instead, the partition size should be changed on first-boot, by whatever it is that openfirmware boots. you say linux can't use the new size in that boot ... (which smells like a small matter of programming, but never mind) ... that leaves kernel.git:olpc/olpc.fth which could

  • detect the first-boot condition, (absence of /bootpart/.olpc.resized)
  • change the partition table, and
  • cancel whatever condition indicates first-boot (create file).

what do you think?

(changing component to kernel, since olpc/olpc.fth is maintained in our kernel component, even though it is written in forth).

Changed 3 years ago by Quozl

olpc.fth which checks for the second partition being smaller than disk size, and if so extends it to the disk size. may be destructive to any non-standard partitioning. tested on os29. resize2fs can be placed in /etc/rc.local as a test. on a test here, 4gb to 8gb, resize2fs took 1m39s.

Changed 3 years ago by pgf

odd. i wonder why my test, noted in #10040, took only 13s. :-/

Changed 3 years ago by Quozl

In adding additional checks to the code, I could not explain the number of sectors chosen by sfdisk for the root filesystem partition. Being unable to explain it means I can't build a reliable check for it.

For .zd4, the disk image size is set in examples/olpc-os-11.3.1-xo1.75.ini as 3865470566 (0xe6666666) bytes. This is 7549747 sectors, plus 102 bytes.

sfdisk is run in olpc-os-builder:modules/sd_card_image/image.50.makefs.sh with -S 32 -H 32, which implies a cylinder size of 1024 sectors.

After fs-update of but before growing the partition, parted reports:

# parted -m /dev/mmcblk0 "unit S print"
BYT;
/dev/mmcblk0:7733248s:sd/mmc:512:512:msdos:MMC SEM04G;
1:8192s:139263s:131072s:ext2::boot;
2:139264s:7549119s:7409856s:ext4::;

These values are starting sector on disk, ending sector on disk, and size in sectors.

The ending sector is calculated; the partition table entry only contains starting sector number and size.

sfdisk has left a gap of 627 sectors after the partition and before the end of the image.

Changed 3 years ago by Quozl

  • next_action changed from design to review

Changed 3 years ago by Quozl

an alternative implementation using initramfs has been posted, i'll back off waiting for review.

Changed 3 years ago by Quozl

local testing underway with code based on a consensus specification.

Changed 3 years ago by Quozl

  • next_action changed from review to add to release
  • component changed from kernel to ofw - open firmware
  • blocking 10040 removed
  • version changed from not specified to Development firmware
  • milestone changed from 12.1.0 to 1.75-firmware

Previous plan abandoned based on Daniel and Martin's advice that initramfs will need to do the resize anyway for units in the field that are upgraded using fs-update.

A reduced patch has been committed, which has no impact on fs-update, and requires no changes to olpc-os-builder.

Changed 2 years ago by Quozl

  • status changed from assigned to closed
  • next_action changed from add to release to no action
  • resolution set to fixed

Is in Q4D06 and Q3C03.

Feature expected to be redundant when #10040 closes for 12.1.0 or later.

Note: See TracTickets for help on using tickets.