On Mon, Aug 14, 2006 at 01:58:47PM +0200, maximilian attems wrote: > severity 382788 serious > stop see justification below > > On Mon, Aug 14, 2006 at 02:39:09AM +0200, Jonas Smedegaard wrote: > > On Sun, 13 Aug 2006 13:17:55 +0200 Pierre Habouzit wrote: > > > > > Instead, it uses a hardcoded value he takes from /etc/fstab > > > presumably, that makes a system where you rearraged the partition > > > completely impossible to boot, if you didn't faked the next /etc/fstab > > > and regenerated the initrd. > > > > > > Since I use grub, and if I do forget to change the menu.lst it has a > > > console to do so, I can always boot. the preliminary extraction of the > > > initrd then works, but the switch root just fails because it does not > > > finds the correct root, whereas it on the damn kernel command line ! > > > > Correct. That's a limitation in the yaird design: An abolute minimal > > initrd image is composed, based on your current setup. Only kernel > > modules required to access your root filesystem is included on the > > image, and only the devices needed are created. > > even initrd-tools parses the boot cmdline. > initrd-tools allowed to hardcode the root, but a different root > bootarg would override that. > > ignoring /proc/cmdline root bootarg is a critical rc bug for any > init of an initrd/initramfs generator. filed at severity serious > to raise awareness of that bug.
Jonas, i agree on this with maks and pierre, being able to override root= is a very essential feature. Furthermore, it is not all that difficult to implement (just check for an existing root= command line before providing your own copy), probably 3 lines of perl or so, since the comand line is available as /proc/cmdline. I am no perl expert though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
