Re: initramfs generator selection
On Thu, Dec 29, 2005 at 03:49:42PM -0500, Joey Hess wrote:
> Frans Pop wrote:
> > Hmm. I think it is on the same level as offering static network
> > configuration over DHCP or, maybe better, (not) loading some modules
> > during hardware detection.
> >
> > The main advantage of the patch as I see it is its flexibility: it allows
> > both us and derivatives to set things up as they like with only minor
> > changes:
> > - per arch defaults
> > - option of offering alternative generators
> > - option to ask the user which generator to use
> > - option to preseed
> > It also makes the installer independent of the default dependency set in
> > kernel-image packages.
>
> I'm not sure if this last is really an advantage. I'd rather leave the
> decision of which is default up to the kernel people, and we want d-i to
> behave the same as a later kernel upgrde.
The kernel team got to some pain to ensure that the choice is user
configurable, through the appropriate ramdisk= field in /etc/kernel-img.conf,
not sure if Frans uses this (recomended) method for selecting the tool, or
something else though.
We already mess up with kernel-img.conf, and a d-i installed system is in no
way similar to a plainly debootstraped system in this regard, nor will it be
the same as when upgrading from older setup not installed with d-i or
installed with an older d-i possibly.
> > I agree the question should be avoided if possible, certainly for default
> > installs. Whether to ask the question during medium priority installs is
> > debatable, but, as long as both tools have issues, IMO a good thing.
>
> As long as it's only asked at medium, I don't care that the question
> exists, but here is a way to avoid it anyway. It also makes recovering
> from a generator that doesn't work much more pleasant than having to
> follow the current advice in the question and re-install.
>
> - Modify the kernel packages to generate initramfses using each of the
> suitable tools they find, rather than just one. Name the initramfses
> consistently, and make a kernel image symlink that matches their
> name. Ie:
> /boot/vmlinuz-2.6.14-2-386.yaird -> /boot/vmlinuz-2.6.14-2-386
> /boot/initrd.img-2.6.14-2-386.yaird
> /boot/vmlinuz-2.6.14-2-386.initramfs-tools -> /boot/vmlinuz-2.6.14-2-386
> /boot/initrd.img-2.6.14-2-386.initramfs-tools
This can be done simply, i think, by setting ramdisk= in kernel-img.conf to a
home-made script invoking both mkinitrd.yaird and mkinitramfs. No need to muck
up with the kernels, which are just fine.
I am not fully sure how the mkvmlinuz call would be handled though, as it is
called with the kernel version only, and would need to call both, but this is
in the bootloader category.
Still, now that Jonas confirmed yaird will fail in the presence of non-sysfs
drivers, my initial proposal of trying out yaird and reverting to
initramfs-tools if yaird can't produce a suitable ramdisk is again more
interesting than your proposal.
> - Modify d-i to install all possibly suitable generators.
> - Modify the boot loader installers to add separate menu entries for
> the different initramfses so generated. With the symlinks set up as
> above some like grub should need no modification to display both in
> the menu. For for some boot loaders it will be harder and perhaps for
> some a user would have to manually enter the initramfs name at the
> command line to override the default.
Yeah. Again, this need wider cooperation from the bootloaders with make-kpkg
and co, and some nice setup needs to be found which would allow to automate
this. Manoj thought it was not a good idea though, and that what we currently
have is just fine, so ...
> Then if one fails to boot, you just use the other one.
>
> Personally, d-i aside, I would prefer to have this capability available
> in all my systems currently.
Yeah, i also thought about simply installing both always too myself :)
Friendly,
Sven Luther
Reply to: