root resizefs mount point
Bug report
When using bootc along with cloud-init, the resizefs plugin doesn't function properly due to how bootc lays out its filesystems.
Before cloud-init starts, it:
- mounts
/ - bindmounts / to
/etc,/var,/sysroot(ro) - mounts composefs over
/(ro)
Then resizefs tries to resize / and it fails, as its composefs
For now, I've patched cloud-init to change the path from / to /etc and it works.
There needs to be a way to customize the path used for resizing the rootfs to support bootc.
Normally with cloud-init resizing rootfs happens after the partition containing the rootfs is first grown (via cc_growpart, which typically uses the growpart utility which is only designed for MBR or GPT partitioned storage devices).
What type of device is the rootfs stored on and how is it partitioned? Can you show your user-data for "growpart:" ? If you are nor using cc_growpart then how are you resizing wherever the rootfs is stored?
Secondly the cc_resizefs module is documented as only supporting resizing the rootfs (the module is misnamed, it really should be called cc_resizerootfs) - that would be "/" - any other mountpoint is not the rootfs (though it could be a bind mount to it).
Therefore extending cc_resizefs to support specifying a mountpoint would in effect be extending cc_resizefs to support resizing filesystems other than a rootfs.
From reading relevant Fedora docs regarding /etc it says "While it appears as a mount point, it is always part of the machine’s local root filesystem", it says /etc is part of the rootfs, not that it is the rootfs.