Re: kernel problem: Booting with initrd and init fails

[Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de>]

Herbert Xu <herbert@gondor.apana.org.au> writes:

> On Mon, Oct 25, 1999 at 11:36:42PM +0200, Goswin Brederlow wrote:
> >
> > > > That should load a ramdisk during boot but startx /bin/ash instead of
> > > > /sbin/init or /linuxrc. Instead it will startx /linuxrc and if that
> > > > and /sbin/init are missing it tries to remount / as specified in the
> > > > kernel.
> >
> > It is and it isn't. If lilo/grub/linload/syslinux sees a initrd=<file>
> > (and possible load_ramdisk=1) it will load that as an initial
> > ramdisk. The kernel then detects that ramdisk and boots from that
> > ignoring its internal "root=" setting for the moment. If the ramdisk
> > holds a /linuxrc that gets executed and then the kernel will mount the 
> > device named in /proc/sys/kernel/real_root_device, which is the device 
> > used as root when compileing the kernel (normaly) but can be
> > overwritten in the /linuxrc.
> 
> Well, you've just said it yourself.  Before the real root is mounted, the
> piece of code that executes init= is never run.  So all you get is /linuxrc.

I had a look at the actual code and patched in some kprintf lines to
see whats going on. Its true that the booting will do the /linuxrc,
but after that it returns and continues as if no linuxrc ever existed. 

> So if you want to get a shell at that point link it to linuxrc.

I want that, but I want to specify the file used. A few lines extra
and now I have a boot parameter called "linuxrc=" analog to the
"init=" stuff. But the behaviour with "init=" is still strange/buggy.

The normal procedure when initrd is used is to first
execve("/linuxrc"..) and then remount the real root and continue as
normal.

The init value given on the command line will be stored correctly in
"execute_command" before the linuxrc stuff and will be executed by
execve also. If that fails the kernel will try a few other things as
well.

My a:syslinux.cfg has the entry

LABEL demo
        APPEND vga=0x791 load_ramdisk=1 initrd=root.bin init=/bin/sh
        KERNEL linux

I added a kprintf to the code to see whats going on and the
execute_comand points to "/bin/sh", just as it should and everything
should work, but all I get is:

: : No such file or directory.

After that only a power off help. Normaly I would think it should try
the next execve, since the first failed, but no luck.

Now the real groovy thing: If I boot with the bootdisk and use

BOOT: demo init=/bin/sh

at the promt, the execute_command will be exactly the same, but then
it works.

So when I enter the init by hand it works exactly as it should and if
I have it only in the append line it fails for no apparent
reason. Maybe the order of parameters is important, but it shouldn't
matter. Too bad that I can't test with lilo, it doesn't know about
"init=" in the lilo.conf file. 

May the Source be with you.
			Goswin