cloud-init-dev team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Tue, 8 Oct 2013, Haefliger, Juerg wrote:

> All,
>
> I have an issue with the growpart/growroot scripts on Fedora 20. The
> problem is that after growroot resized the root partition (in
> initramfs), systemd automatically re-mounts it and then growroot croaks
> because it can't remount root (again). This makes me wonder why we're
> running growoot after root has been mounted (and right before we pivot
> to the real root) and not before? I'm sure there must be a reason...

Its been a long time since I made this decision, and looking at it, in
debian I could have uesd 'local-premount' I suppose as the hook rather
than 'local-bottom'.  'local-premount' isn't guaranteed to actually have
the root device around (they're there to make the root device arrive).

Initially, we were not calling 'wait-for-root' at all, and If I did that
in a local-premount, it would then be done again in the 'mount' portion of
initramfs.  That would seem unnecessary.

Later, we found that after we re-wrote the partition table, we really had
to udevadm settle and wait-for-root again anyway.  This was because after
the REREAD call the device might disappear for a moment as udev responded
to the event.

So in the end, I think that moving to local-premount probably would make
sense.

I'm not really familiar with dracut or initramfs boot on fedora, so I'm
not completely able to speak to that, but the above hopefully gives *some*
insight as to why it is the way it is.
>
> Also, Fedora is using the cloud-initramfs-tools growroot package in
> their (non-cloud) ARM images to resize root on first boot. With newer
> kernels and an updated partx we don't have to do this in the initramfs
> anymore and I believe Scott moved the functionality into cloud-init. I'm

Well, cloud-init instruments the call, but the call is still just made to
'growpart'.  I added support for cloud-init to call 'parted' *or*
growpart, but the parted support turned out broken.  see bug
http://pad.lv/1212492 for more info.

> wondering if we should split it out completely into a new, separate
> package, that simply resizes the root partition and the filesystem.
> Basically decoupling it from the cloud stuff for use cases as mentioned
> above.

cloudinit/config/cc_growpart.py is not a lot of code, and supports calling
either growpart or parted, so I don't think duplication elsewhere is
terrible.

That said, I might support growpart taking some special "root" flag, or a
'growroot' program that used growpart inside cloud-utils and just figured
out what the root device was and called growpart.