On Wed, Jun 11, 2014 at 3:48 AM, Thomas Goirand <
zigo@debian.org> wrote:
>
> On 05/06/2014 10:26 PM, Juerg Haefliger wrote:
> > All,
> >
> > With Kernel 3.8 and later, it's no longer necessary to resize the root
> > partition in cloud images in the initrd while root is unmounted, it can
> > now be done online during the regular sysv boot process. That makes
> > cloud-initramsfs-tools kind of obsolete (for newer kernels that is).
> >
> > Secondly, growpart (which is part of cloud-utils) kind of grew into the
> > wild IMHO. I'd like to start over from scratch.
> >
> > Thirdly, apparently the ARM people are using the growroot feature so
> > they can put their image on any-sized SD card and it enlarges itself on
> > first boot. That's not really a cloud use case so having to install
> > cloud packages (which pull in other cloud dependencies) for that is
> > suboptimal.
> >
> > What I'm proposing is to create a new package that does both partition
> > and filesystem resizing during sysv boot. Just that, nothing else,
> > probably configurable somehow through a config file. In functionality,
> > it would replace cloud-utils (more precisely, the growpart script) and
> > cloud-initramfs-tools and could probably replace the two over time.
> >
> > I'm not a DD or package maintainer so don't really now how to go about
> > it. I could put something together and throw it up on github as a starter.
> >
> > Thoughts? Comments? Concerns?
> >
> > Thanks
> > ...Juerg
>
> This reply is overdue, sorry.
No worries. We're ll busy.
> I honestly don't see what would justify breaking something that already
> was proven to work well. If the resize of partitions is working well in
> the initramfs, in all cases, why should we care about resizing it later
> on and address only the specific case of newer kernel, just because it
> is possible?
Yes. I believe there should be as little as possible in initramfs and if it can be done elsewhere, it should.
> I don't think you'd be addressing any issue by moving the
> partition resize into a sysv-rc process. Quite the opposite: you'd have
> to add systemd support and/or sysv-rc dependencies, and it may be more
> complicated at the end.
You need that for an initramfs-approach as well. From my experience (I'm maintaining the package in EPEL and Fedora) it was a pain to get it to work in initramfs for both sysv and systemd (but that could be just me being somewhat ignorant when it comes to systemd). If you screw up in initramfs your machine becomes unbootable. By screwing up I don't necessarily mean thrashing the partition table or the filesystem. I ran into some problems with systemd interfering with the unmounting of the root partition but again, that could be just me not knowing too much about systemd. Testing an initramfs-based solution is also cumbersome and more difficult.
> The binary package cloud-initramfs-growroot is really an independent
> binary package. While it is part of the source package
> cloud-initramfs-tools, it can be used standalone. The growpart utility
> is a simple shell script, just like the rest of cloud-utils. They can't,
> in any way, be a problem in a setup (the package contains no init script
> or daemon).
>
> For the ARM guys, the only issue is the package names, or am I missing
> something?
Not sure if the ARM guys need cloud-init as well to do the actual filesystem resizing but if they do, that's less than optimal. cloud-init - as you know - has a gigantic dependency list. I have a use case where I build an image that is dd'ed over the disk of a non-cloud machine that needs to resize itself on first boot. To install cloud-init just for automatic filesystem resizing is a horrible horrible hack.
Resizing the root partition and the filesystem is an operation that
is not strictly tied to a cloud environment and as such deserves its own package.
> Your thoughts?
Just thought it was a good idea and wanted some feedback.
Thanks
...Juerg
> Cheers,
>
> Thomas
>