ORBIT-USER: Kernel panic from image

[Luis R. Rodriguez]

On 12/21/06, Avi Brender <abrender at eden.rutgers.edu> wrote:
> Hi All,
>
>   Yesterday I saved the image of one of my nodes in SB2 after it was working
> properly.
>
> Today I tried to load the image on nodes 1 & 2 of sb2.. But the kernel
> panics:
> g
> Kernel command line: vga=extended root=/dev/ram0 rw load_ramdisk=1
> prompt_ramdisk=1 ramdisk_size=32768 init=/vmlinuz
> initrd=initrd-orbit-pxe-1.1.4.im
> g console=ttyS0,9600 BOOT_IMAGE=linux-orbit-pxe-2.6.14
> .....
> Kernel panic - not syncing: No init found.  Try passing init= option to
> kernel.
>
>
> Any thoughts?

From:

linux/Documentation/kernel-parameters.txt

--
        init=           [KNL]
                        Format: <full_path>
                        Run specified binary instead of /sbin/init as init
                        process.
--

Being a bit more thorough -- the init argument sets the initial
command to be executed by the kernel loaded. The default behavior is
to use /sbin/init, parent of all processes (PID 1). Also since you are
using an initrd image to use for your root partition (/) it will try
to pick up the program specified from the initrd image itself.
Therefore if the argument passed does not exist as a file in your
initrd image it will fail. It will also fail if it depends on
libraries or shells not available on that initrd. I do not see why
init=/vmlinuz is being used; vmlinuz is the compressed kernel image
and not a binary program or shell you can directly execute. Think of
it this way -- the kernel has been loaded into memory and you have a /
partition available -- what's the next thing to do? This is where
/sbin/init usually kicks in.

I checked out the initrd image you are using and I see no /vmlinuz on
the image. I do see a /linuxrc which points to bin/busybox, the
busybox binary.

You can try using that instead but I suspect the problem is something
else. I see most images we use use init=some_kernel too and they do
work but I have no explanation yet as to why this works. Other
possibilities here are problems with the hardware (memory, or
motherboard).

root at repository2:/tftpboot# mkdir tmp
root at repository2:/tftpboot# cp initrd-orbit-pxe-1.1.4.img tmp/
root at repository2:/tftpboot# cd tmp/
root at repository2:/tftpboot/tmp# mv initrd-orbit-pxe-1.1.4.img
initrd-orbit-pxe-1.1.4.ex2.gz
root at repository2:/tftpboot/tmp# gunzip initrd-orbit-pxe-1.1.4.ex2.gz
root at repository2:/tftpboot/tmp# mkdir mnt
root at repository2:/tftpboot/tmp# mount -o loop initrd-orbit-pxe-1.1.4.ex2 mnt/
root at repository2:/tftpboot/tmp# cd mnt/

root at repository2:/tftpboot/tmp/mnt# ls -l
total 24
drwxr-xr-x 2 root root  1024 Nov 30  2005 bin
drwxr-xr-x 3 root root  5120 Jan  3  2005 dev
drwxr-xr-x 4 root root  1024 Nov 29  2005 etc
drwxr-xr-x 3 root root  1024 Nov 30  2005 lib
lrwxrwxrwx 1 root root    11 Nov 30  2005 linuxrc -> bin/busybox
drwx------ 2 root root 12288 Nov 30  2005 lost+found
drwxr-xr-x 2 root root  1024 Nov 29  2005 sbin
drwxr-xr-x 2 root root  1024 Nov 29  2005 tmp
drwxr-xr-x 5 root root  1024 Nov 30  2005 usr
drwxr-xr-x 3 root root  1024 Nov 29  2005 var

root at repository2:/tftpboot/tmp/mnt# ls -l bin/busybox
-rwxr-xr-x 1 root root 349448 Nov 30  2005 bin/busybox
root at repository2:/tftpboot/tmp/mnt# file bin/busybox
bin/busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.2.0, dynamically linked (uses shared libs), for
GNU/Linux 2.2.0, stripped