Bryn M. Reeves bmr at redhat.com
Tue Jan 29 15:34:49 UTC 2013


On 01/29/2013 03:24 PM, Simo Sorce wrote:
> Wow this brings me back to Windows 95/XP antifeatures where changing
> hardware even a little bit strands you to not be able to boot and having
> to go to rescue mode.

Actually this is how mkinitrd/nash worked by default for many years 
(pre-dracut, i.e. RHL-mumble.mumble all the way up to RHEL5).

> Why are we doing this ?
> Is this just to boot a little bit faster ?

It made a considerable difference with grub1 as the bootloader had to 
load the image via prehistoric IO routines. I didn't think that had 
changed much with the move to grub2 but have not measured it.

It also consumes dramatically more space on /boot which was one cause of 
user frustration with preupgrade (which admittedly was ever so slightly 
greedy about /boot space).

> I rebuilding is an issue, wouldn't it make sense to pre-generate the
> rescue initramfs at kernel build time ? Does it really need to be
> regenerated at install time ?

Since by definition it's not system-specific I think this would be 
preferable. I've heard users ask for the ability to "install" the rescue 
CD in the past (and have hacked it up to do so via PXE images in /boot 
and a grub entry).

This sounds like it would offer similar capabilities.

> So in summary, can we rather keep the current behavior by default and
> give the option to boot faster only to people that are interested in
> it ?

The new is the old and honestly it very rarely caused problems. Also, 
it's not simply hardware but also software and configuration changes 
that may mandate updating the initramfs. We can possibly cover some 
bases on the hardware and updates front but even these have very 
difficult cases (e.g. system is shut down, hardware changed, started up 
-> initramfs is not updated, how do we proceed?).

Regards,
Bryn.




More information about the devel mailing list