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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
