[Simo Sorce]

On Tue, 2013-01-29 at 15:34 +0000, Bryn M. Reeves wrote:
> 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).

I guess it was in the short while I switched to Ubuntu, because from my
memory I used to change hardware on my machines and always be extremely
happy at how Linux was resilient to hardware changes between boots and
automatically detected new hardware without the dreaded rescue mode.

> > 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).

Yes but is /boot space still an issue these days ?
Do we still need a separate /boot at all ?
Disks are huge these days.
And speed is still an issue with modern SSDs ?

> > 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?).

This are the 2 cases I have in mind:
1. Machine breaks -> change motherboard -> boot breaks
2. Swap disk to other laptop -> boot breaks

I have done 2) for quite a while recently and I have done 1 in the past
quite a lot when I was more into changing hw relatively frequently or
fixing other people machines (and swapping disks around etc..).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York