Kernel panic - not syncing: Attempted to kill init!
 

Hi folks,

I was a Linux vigin until yesterday so appologies if I don't give all the details you might need to diagnose my problem.

Ok the details. I'm running CentOS 4.
The system has been running fine for over a year until yesterday. When we went to boot the machine we get the error below. I rebooted the machine and it booted fine. Then this morning I tried to boot it again and all I can get is the error below.

Uncompressing Linux... Ok booting the kernel
ACPI: Unable to locate RSDP
Red Hat nash version 4.3.1.6 starting
Reading all physical volumes. This may take a white
Found volume group "VolGroup00" using metadata file lvm2
2 logical volumes in volume group "VolGroup00" now active
Ext3-fs: error loading journal
mount: error 22 mounting ext3
mount: error 2 mounting none
switchroot: mount failed 22
umount /initrd/dev failed:2
Kernel panic - not syncing: Attempted to kill init!


No hardware has changed and I'm assured that no one has been messing with any software settings (pinch of salt please). I'm thinking a file system problem as the hard drive is quite old. Is there a recovery console like there is with Windows? I can get to the grub command prompt but none of the commands there look like what I need.

I'm an abolute Linux novice so please keep your explanations as simple as possible please.

Thanks
Aidan

And you lost your Linux virginity yesterday too... well done.

Boot from the CentOS dvd, and pass "linux rescue" at the boot: prompt. If you can successfully mount your root and boot partitions, post the output of fdisk -l, cat /boot/grub/grub.conf, and cat /etc/fstab.

There is a strong chance of drive failure.
When you get intermittent kernel panics, test/repair filesystem, renew backups.

I see CentOS uses LVM.
http://www.tldp.org/HOWTO/LVM-HOWTO/ (LVM Howto: JIC)

Note: the actual important errors are the following:
However - maybe just the journal is corrupted... That's what error 22 is.
http://osdir.com/ml/file-systems.ext.../msg00046.html

Here's a shortcut that will likely work for you too:
http://www.linuxquestions.org/questi...ournal-321434/
... it exploits a failsafe function in fedora, which exists in RHEL and thus CentOS probably does it too.

Kernel Panic reports to General Fault :)

Update
 

Thanks for the reply. I didn't build the original machine our linux guy was the man responsible but he has left us. I'm stuck with this now :mad:

Ok I booted from the CentOS CD when I was asked if I wanted to find a linux installation. This returned with the error "you dont have any linux partitions, press return to get a shell."

When I typed fdisk -l I got:

Disk /dev/hda: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/tracks, 9964 cylinders
Units = cylinders of 16065 * 512 =8225280

Device Boot Start End Blocks ID System
/dev/hda1 * 1 13 104391 83 Linux
/dev/hda2 14 9964 79931407+ 8e Linux LVM

cat /boot/grub/grub.conf returns
No such file or directory

cat /etc/fstab returns
No such file or directory

Sounds like the disk is done for!

I tried to follow the procedure the guy outlined in the link you recommended where I do the linux rescue and kill the machine to try and force the machine to ask for a disk check on reboot but I was never prompted to do a disk check.

Actually, that's quite good... last two commands didn't work because the fs on the partitions haven't been mounted yet.

Looks like hda1 is your boot partition and hda2 is an LVM volume holding the root partition.

Check the physical integrity of the drives: memtest86

Check the filesystems:

Testing the boot partition is easy:
# fsck /dev/hda1

... with any luck, it is the boot partition that has the missing journal.
Restore the journal to the boot partition as follows:
# tune2fs /dev/hda1 -O has_journal

I don't think so though: your error messages suggest that it is the logical volume that is missing a journal.

Testing the logical volume:
# vgscan
# vgchange -ay
# fsck /dev/VolGroup00/LogVol00

With any luck, this is possible:
# tune2fs /dev/VolGroup00/LogVol00 -O has_journal
... assuming the journal is the problem.

To examine the files, you need to mount the filesystems... as follows:

# mount /dev/VolGroup00/LogVol00 /mnt
# mount /dev/hda1 /mnt/boot
# chroot /mnt

# cat /boot/grub/grub.conf
# cat /etc/fstab

This will help you understand the layout.
Hopefully all that has fixed the problem someplace, and you can reboot normally.

Ahhh... well... just as well I talked you through the above ain't it? Did you remember to boot from HDD the second time?

Progress??
 

Again thanks for the reply. Ok this is what I'm getting now:

fsck /dev/hda1 returns:
Warning: Couldn't open /etc/fstab: No such file or dir
e2fsck 1.35 (28-Feb-2004)
/boot: Clean 38/26104 files, 12483/104388 blocks

tune2fs /dev/hda1 -O has_journal returns:
tune2fs 1.35 (28-Feb-2004)

vgscan returns command not found as does vgchange

fsck /dev/VolGroup00/LogVol00 returns:
Warning: Couldnt open /etc/fstab: No such file or directory while trying to open /dev/VolGroup00/LogVol00. The superblock could not be read or does not describe a correct ext2 filesystem.

tune2gs /dev/VolGroup00/LogVol00 -O has_journal returns
No such file or dir while trying to open /dev/VolGroup00/LogVol00 Couldn't find a valid filesystem superblock.

mount /dev/VolGroup00/LogVol00 /mnt returned
Mounting /dev/VolGroup00/LogVol00 on /mnt failed: No Such file or Dir

mount /dev/hda1 /mnt/boot returned:
No such file or dir

chroot /mnt returned: cannot execute /bin/sh: no such file or directory

The two cat commands failed with no such file or dir messages as well. I assume this is because the drive hasn't been mounted?

vgscan returns command not found as does vgchange
... you need to be root, with roots path.

locate vgscan (I don't have LVM so I cannot check for you, it's on the fedora disk though.)

None of the other commands will work without the LVM tools. i.e. vgscan looks for logical volumes and vgchange makes them available as /dev files. Once that has happened you can mount them, but not before.

.
 

I can't locate vgscan or vhchange and my system. I've done a search using find / -name vgscan.* and it returns nothing.

Any ideas?

Aidan

"locate" is a command.

But never mind... looking around, it seems there is some talk about LVM tools being unavailable in CentOS rescue mode.

This leaves you looking for a live disk with LVM tools on it, or using fedora rescue mode.

I'm trying to confirm it - if true, then this is a major bug in CentOS (or any distro that makes LVM the default).

I have found:
http://www.centos.org/modules/newbb/...iewmode=thread
... for CentOS4, but appears contradicted by:
http://www.centos.org/modules/newbb/...wmode=threaded
... which claims to have run vgscan in rescue mode.

Most people talking about rescuing LVM on CentOS <anyversion> talk about using a rescue CD or another distro in live mode. If I were you, I'd go complain.

.
 

How about putting the faulty partition into a Windows computer and running a chkdsk from there?

Any idea where I can find a live disk with LVM tools. Is this some kind of boot disk?

Why that dot after vgscan in find command? locate may work or may not work reagarding if database is built and available.

Does Windows chdsk know what to do with LVM? No! It will tell you the disk is corrupt and attempt to reformat it. Keep it away from windows.

I think the Ultimate Recovery CD will do this. Any fedora install disk should too, and maybe the fedora live CDs. I don't know about the others.

Good point - I should have seen this. OP must be still thinking in terms of windows and looking for anything vgscan.com or vgscan.exe like :)

Should be:

find / -name vgscan

Since vgscan is normally in /bin or /sbin, whereis should find it. Or ls /bin vg* and ls /sbin vg*