Re: [PATCH] 5 year old bug in main.c (initrd). Can this please be fixed?

From: Richard Zidlicky (
Date: Fri May 26 2000 - 07:23:55 EST

> Richard Zidlicky wrote:
> >
> > this is correct and a few distributions (eg m68k) rely on that
> > behaviour for installation or repair ramdisks.
> Then it's easy enough for them to duplicate this kernel check in userland
> at the top of /linuxrc:

compatibility wise this would not be without major pain or a compatibility
switch. It would be nasty if my users found the 4 months old installation/rescue
ramdisk suddenly broken.

> I have NO such luxury of a simple solution like that, with the decision set in
> stone in the kernel.

can you explain in more detail what makes solutions like 'init=/linuxrc' so
impractical for you?

> > If you specify 'root=xxx' than xxx is real root that is supposed to have
> > a real init and all that stuff. If that happens to be your initial ramdisk
> > than there is no need to run linuxrc.
> Thank you for deciding that for me.

wasn't my idea to define it that way, but I found it logical. /dev/ram should
not have more special magic than necessary, if there is need for a pre-init
phase it should be usable independent of devices.

> > Why would you specify 'root=/dev/ram' if you want linuxrc to change it
> > anyway? Either don't use 'root=' or set it to the value its supposed to
> > have after linuxrc exits which won't be /dev/ram in normal circumstances.
> The idea is /dev/ram0 is not a usable root. It may not even have init.
> /linuxrc provides a userland means to perform actions before init.
> This is the typical mode of opertion of thin clients, thin servers, or other
> embedded devices.

do you need some sort of preinit= kernel parameter or what? Make a patch for that,
without breaking initial ramdisks


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:15 EST