Kernel panic: Attempted to kill init!

[Cef]

On Tue, 29 Mar 2005 06:41, Duncan Lithgow wrote:
> First here is the output I'm getting:
> =======================
> Starting Ubuntu...
> VFS: Can't find ext3 filesystem on dev hda5.
> modprobe: FATAL: Could not open
> '/lib/module/2.6.8.1-3-386/kernel/fs/nls/nls_cp437.ko': No such file or
> directory

Of this, the important line is:

> VFS: Can't find ext3 filesystem on dev hda5.

The boot process is looking for an ext3 filesystem in hda5, and it can't find 
it. But there is more:

> FAT: codepage cp437 not found
> pivot_root: No such file or directory
> /sbin/init:429 cannot open dev/console: No such file
> Kernel panic: Attempted to kill init!
> =======================

Of that, here is the line that is most important:

> pivot_root: No such file or directory

Basically, the initrd.img is found, but it cannot change to the real root 
filesystem during the boot process. Since just before this the system could 
not find a root filesystem on hda5, it's most likely expecting the root 
filesystem to be on hda5.

If the rootfs is not on hda5, you need to change your bootloader (eg: grub, 
lilo) to point at the real root filesystem. If it is, you may need to fix the 
filesystem at hda5. It's also possible that your filesystem resides on a 
device that has not had it's module loaded (for whatever reason), and/or the 
filesystems are appearing out of order. This could (I'm guessing) also happen 
if your SATA controllers are now appearing at /dev/sd* instead of /dev/hd*

Note that the reason it can't open dev/console is because it cannot pivot_root 
to the real rootfs, which should have it's own dev/console entry, and so it 
fails and spits out that error.

A quick coverage of the boot process, which may help you to diagnose the 
problem:

At boot, the bootloader loads the kernel and the initrd.img into memory. The 
initrd.img is a small root filesystem (with kernel modules and 
scripts/programs) that is used to get the system running. The bootloader then 
runs the kernel, and points it at the initrd.img in memory. The kernel mounts 
this image as filesystem, and runs the init scripts on the initrd, which in 
turn loads any modules that are required to access the real rootfs. Once this 
is done, the real rootfs is mounted, and then the kernel is told to 
'pivot_root', which changes the root mount point to the new root filesystem. 
The system then loads the real init processes and then goes through all it's 
usual startup processes.

I personally think it would be really nice if there was a little more friendly 
message here in the case of failure. I've encountered this a number of times 
(for a number of reasons), and each time the message bugs me as being too 
technical for many people. It should be possible to detect, before the system 
gets to the pivot_root stage, that the real rootfs is not there, and to pop 
up a better message, and possibly let the user get some diagnostic output to 
help solve the problem.

-- 
 Stuart Young - aka Cefiar - cef at optus.net