Re: initrd/initramfs: we discussed enough, let's take some action now :)

[Sven Luther <sven.luther@wanadoo.fr>]

On Sat, Oct 15, 2005 at 04:34:57PM +0200, Erik van Konijnenburg wrote:
> On Sat, Oct 15, 2005 at 08:57:31AM +0200, Sven Luther wrote:
> > On Sat, Oct 15, 2005 at 08:47:57AM +0200, Erik van Konijnenburg wrote:
> > > On Fri, Oct 14, 2005 at 12:53:41PM +0200, Jonas Smedegaard wrote:
> 
> > Hey, i didn't know the mkinitrd wrapper was shell, or i would have done it
> > myself. I wonder why you need the :
> > 
> >   if [ "$supported_host_version" != "" ]
> > 
> > though, since by default, it will test for an empty string, so this seems
> > redundant, but maybe there is some obscure shell thingies i am not aware of.
> 
> As Jonas suspected, it's coding style.  This notation works
> correctly even if the variable happens to contain "-x";
> furthermore, this notation does not require the reader
> to grok the difference between -n (null string) and -z (zero string).

Ok, ... (altough i wrote that, not Jonas :).

> > > The patch claims support for 2.6.8, which is where development
> > > started, but later yaird versions only have had testing with
> > > newer kernels.  If we could get away with claiming a later version,
> > > that can only reduce number of bug reports.
> > 
> > Not a good idea, 2.6.8 is the sarge kernel, and it should be best to keep at
> > least 2.6.8 host systems in the compatibility list, for sarge26 -> etch
> > upgrades. Not sure about target system, anything below 2.6.12 is rather
> > academic there.
> 
> Agreed with Jonas here: stick with 2.6.8; reconsider if that becomes too
> limiting.
> 
> > Also, i would like to hear your comments on the yaird-using sarge24 -> etch
> > upgrade path ? 
> 
> Though one, but cannot be avoided forever.  One of the reasons why yaird
> can be simple in principle (if not in implementation ...) is that it does
> not bother with 2.4 compatibility.  In particular, it needs /sys to do analysis.
> 
> With a bit of hand-waving, there are two broad approaches:
> * require the user to upgrade to 2.6 *somehow* before upgrading to yaird
> * extend yaird with a universal-boot mode.
> 
> The first one relies on using initrd-tools or mkinitramfs for the 2.4->2.6 step;
> it's probably quickest.
> 
> The second one is more interesting: to build a boot image that works
> on any machine, you don't have to analyse /sys.  You need such a boot image
> for the d-i, and it would help in migrating away from initrd-tools.
> The generated image would be very similar to what mkinitramfs does;
> it's not obvious that extending yaird to do this has real advantages
> over just using mkinitramfs in this context.

Indeed, i advocated using some kind of d-i based
recovery/upgrade/hardware-change method, needs investigating some still and
d-i based development. Added on my TODO list.

Friendly,

Sven Luther