Bug#333858: initrd/initramfs: we discussed enough, let's take some action now :)
On Sat, Oct 15, 2005 at 09:42:54PM +0200, Erik van Konijnenburg wrote: On Sat, Oct 15, 2005 at 06:15:04PM +0200, Jonas Smedegaard wrote: I would really like to have the choice of both approaches, also for less common tasks like switching from 2.4 or preparing an alien bootup (either for different hardware or for diskless clients). Good argument for separate implementations, but note that for the universal boot image, both mkinitramfs and yaird need to come up with an initscript that does udev and then mdadm, lvm and what have you. For this use case, the only difference is whether the cpio file is written by a perl script or by a shell script; all the intelligence is at boot time, not at build time. This makes the difference between the two approaches too small to be of much interest to Debian. For yaird, on the other hand, adding an udev-based template would make it a much more complete package. Well, which is exactly the kind of task the debian-installer does, so it is only natural to reuse that code for ramdisk regeneration and other kind of repairs :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333858: initrd/initramfs: we discussed enough, let's take some action now :)
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: That said, I also think I should be able to implement those options to the mkinitrd.yaird wrapper - if upstream doesn't beat me to it ;-). Is that an invitation :-? Hehe, thanks very much for your quick reply, now we have the trio complete, and once we upload all three, the next step can happen, namely the kernel-package patching (and NMU, since Manoj is unavailable for the next time, i asked him to approve the move, but not sure he will be around to read). Here's a concept yaird patch; basically Sven's patch with a bit of extra error checking and a minimal host version. 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. 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. Also, i would like to hear your comments on the yaird-using sarge24 - etch upgrade path ? BTW: I'm happy to see you'll move the yaird packaging to Alioth, that should give more continuity than a TLA archive I keep at home. :) Given the move to Aliot, I think further contributions from me could better be done as simple patches than as full packages. The combination of debian packaging and TLA I now use is cumbersome to say the least, so I'm eager to drop it. We use subversion on alioth, is that fine ? And do you have an alioth account and want to participate directly, or prefer to use the patching method ? Anonymous checkouts are possible too, which allow for easily sending patches per email, i think. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333858: initrd/initramfs: we discussed enough, let's take some action now :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 15 Oct 2005 08:57:31 +0200 Sven Luther [EMAIL PROTECTED] wrote: 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. I believe that still running 2.6.8 even after upgrading to etch is quite realistic. Personally I would be sceptical to switching both ramdisk-generator and kernel version at the same time and choose to do a dpkg-reconfigure on the already installed kernel (after making a backup of the old working ramdisk) before upgrading to a newer one - especially if using funny stuff like encrypted rootfs or nfsroot. In other words: If by academic you mean unlikely to happen in reality I disagree. I suggest keeping the lower versions for both host and target for now, and if too many bugreports ticks in while in testing that shows too problematic to fix we can perhaps change our minds. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDUM6zn7DbMsAkQLgRAimmAKCQVgwm8T40HgvJKeL0uhtEIaQy2QCdGrc4 zhv0LDEmFhDxWEGYG/Maakw= =ME9Q -END PGP SIGNATURE-
Bug#333858: initrd/initramfs: we discussed enough, let's take some action now :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [responding only to the bugreport, not d-k] On Sat, 15 Oct 2005 08:57:31 +0200 Sven Luther [EMAIL PROTECTED] 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. Don't remember if some shells treat the constructs differently or it is only a matter of coding style, but I always avoid if [ $supported_host_version ] and instead use either if [ $supported_host_version != ] or (preferrably) if [ -n $supported_host_version ] - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDUNA3n7DbMsAkQLgRAnUyAJwIjXNdfk9sIj+CCcF+UsG+OPNGxwCeKGk4 1ySZ2h1VbO1bCF8vXRA9OqE= =Po43 -END PGP SIGNATURE-
Bug#333858: initrd/initramfs: we discussed enough, let's take some action now :)
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]
Bug#333858: initrd/initramfs: we discussed enough, let's take some action now :)
On Sat, Oct 15, 2005 at 06:15:04PM +0200, Jonas Smedegaard wrote: On Sat, 15 Oct 2005 16:34:57 +0200 Erik van Konijnenburg [EMAIL PROTECTED] 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: I believe -n means nonzero string (not null string), and the oppposite of -z (not a geeky variation of -z). At least that's the explanation in the manpage of test in Debian sid currently. You're right of course, but note how plausible the -n lie was; With [ $aap = ] notation, you don't have to think about -n vs -z... 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 option is really a ignore the issue and hope someone else deals with it. One of the reasons I find yaird interesting is exactly that it is an alternative. If a problem shows with a kernel, you can try installing a different kernel to see if the problem goes away. Similarly if a ramdisk-generator lacks a feature you can switch to an alternative generator that handles this particular feature. As Jeff explained earlier, initramfs-tools aims to being stupid[1] and just provide a framework for other packages to hook script snippets onto. Yaird seems to aim at being smart and contain enough intelligence itself about all features it wants to support. I would really like to have the choice of both approaches, also for less common tasks like switching from 2.4 or preparing an alien bootup (either for different hardware or for diskless clients). Good argument for separate implementations, but note that for the universal boot image, both mkinitramfs and yaird need to come up with an initscript that does udev and then mdadm, lvm and what have you. For this use case, the only difference is whether the cpio file is written by a perl script or by a shell script; all the intelligence is at boot time, not at build time. This makes the difference between the two approaches too small to be of much interest to Debian. For yaird, on the other hand, adding an udev-based template would make it a much more complete package. Oh, and btw, Erik: Please have a look at http://wiki.debian.org/InitrdReplacementOptions and consider improving it. :-) Good overview; I added some datapoints to it. Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
