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.