Kernel panic: Attempted to kill init!

[Duncan Lithgow]

> 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:
ok, but i know that that partition is ext3 ( i just checked again with
qtparted)

> > 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.
Everything is on hda5 except /swap and /boot

> If it is, you may need to fix the 
> filesystem at hda5. 
What does 'fix' mean - what are you guessing is wrong with the
filesystem there?

> 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*
Sorry I don't understand this bit

> 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.
Lost me there too...

> 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.
yup, got the theory of it now, thanks.

> 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

So, I'm sure you've provided me with some insight into what the cause of
this might be, I just can't see it myself. I've decided to stop
reinstalling things when they go wrong with linux - I shouldn't need to.
So I hope you'll keep helping me through this.

If I mount hda5 are there some files I should look for to see if they're
intact? Would that help your diagnosis?

Thanks so far, Duncan