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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]