Description of problem: Arm images use dracut-modules-growroot to enlarge the root partition on first boot. This is working well for '/dev/sda', however '/dev/mmcblk0' fails to be resized. Version-Release number of selected component (if applicable): dracut-modules-growroot-0.20-0.4.bzr85.fc19.noarch How reproducible: everytime Steps to Reproduce: 1. Boot F20 Alpha RC3 on SD card on any arm device Actual results: Root partition remains the original size. Expected results: Root partition extended to fill media. Additional info: Confirmed working on sda.
Do you happen to have a pointer to an ARM image that I could use for investigating the problem?
Juerg, The latest and greatest is here - https://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC4/Images/armhfp/ Thanks for looking at this.
Confirmed. Growroot does not properly identify the root disk: messages:Sep 25 05:27:46 localhost dracut-pre-pivot: growroot: FAILED: /dev/mmcblk0p: does not exist
Sorry this is taking so long. I've been distracted by other work and there is another problem lurking behind this bug (see https://bugzilla.redhat.com/show_bug.cgi?id=1016648). I believe I have a fix now but need to do some more testing.
Could you share your fix? I can test it... I've been working on this as well, using sysfs to properly go from partitions to devices, instead of relying on games with the disk names to figure things out. regards, Kyle
Agreed, the script mangling of the device name is ugly. Love to see your work!
Created attachment 815101 [details] growroot script Running the attached in dracut's pre-mount stage works for me.
cloud-initramfs-tools-0.20-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/cloud-initramfs-tools-0.20-2.fc20
cloud-initramfs-tools-0.20-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/cloud-initramfs-tools-0.20-2.fc19
cloud-initramfs-tools-0.20-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/cloud-initramfs-tools-0.20-2.el6
Tested on BeagleBone Black with mmcblk0, confirmed root partition is resized. The root filesystem requires a manual resize, should this also be handled?
(In reply to Paul Whalen from comment #11) > Tested on BeagleBone Black with mmcblk0, confirmed root partition is > resized. The root filesystem requires a manual resize, should this also be > handled? No. This package only resizes the partition. Filesystem resizing is up to cloud-init. I understand that ARM (mis-)uses this package for the purpose of expanding the image to the max size. Maybe we should consider a separate package for this that runs completely in post-initrd since newer kernels support online partition resizing. And the cloud-initramfs-tools package is likely to go away in F21.
> No. This package only resizes the partition. Filesystem resizing is up to > cloud-init. I understand that ARM (mis-)uses this package for the purpose of > expanding the image to the max size. Maybe we should consider a separate > package for this that runs completely in post-initrd since newer kernels > support online partition resizing. And the cloud-initramfs-tools package is > likely to go away in F21. I think it's worth splitting it out, or moving it over as a subpackage of dracut
Proposing as a freeze exception: This fixes root partition resize on ARM - tested on vexpress using vda or mmcblk, BeagleBone Black.
cloud-initramfs-tools-0.20-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
cloud-initramfs-tools-0.20-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
cloud-initramfs-tools-0.20-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.