Problems with Logical Volumes and new kernels

[sbbaxter]

Hi.
I have problems getting new kernels to run. I've only ever managed to get kernel upgrades to work from iso CDs - and the problem looks like it's to do with Logical Volumes.

I think when the initrd and kernel is built, during an upgrade, the Logical Volume information gets modified and stops working.

When I try to compile my own kernel, all goes well until the boot - and the fault is invariably due to Logical Volumes. It's even the same if I YUM a kernel upgrade.

I just tried to do an upgrade from FC3 2.6.11.8 to 2.6.15-1.2054_FC5 (from the isos). My old kernel (2.6.11.8) will still boot, but the new one (2.6.15-1.2054_FC5) won't - and I get as far as:

Red Hat nash version 5.0.32 starting
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
2 logical volume(s) in volume group "VolGroup00" now active
WARNING: can't access
exec of init () failed!!!: No such file or directory
Kernel Panic - not syncing: Attempted to kill init!


Can someone PLEEEEEASE tell me what I should do? I'm at my wit's end!!

[sbbaxter]

I've tried running 'linux rescue' from the FC5 install DVD, which works fine and loads the sata_via drivers.

How can I fix this? Should I try and rebuild the initrd? How do I do this?

[tashirosgt]

I can't tell you what to do about it, but let me suggest that you mention your particular hardware. Since not many messages have appeared about new kernels not working with LVM, it's likely that any solution will be particular to the hardware that you have rather than the generalities of LVM. And are you saying you can still run without problems with a certain old kernel?

[sbbaxter]

Sorry - my hardware is:
Shuttle SK43G
AMD 2.4G processor

Host bridge: VIA Technologies, Inc. VT8378 [KM400/A] Chipset Host Bridge
PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
scsi0 : sata_via
ata2: no device found (phy stat 00000000)
scsi1 : sata_via
Vendor: ATA Model: Maxtor 6Y160M0 Rev: YAR5
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 320173056 512-byte hdwr sectors (163929 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 320173056 512-byte hdwr sectors (163929 MB)
SCSI device sda: drive cache: write back


Yes. My older kernel 2.6.11.8 still loads ok - but fails on a few of the new FC5 drivers, such as the new udev.
I built this 2.6.11.8 kernel from sources.

I've tried copying the .config from the 2.6.11.8 source directory, into a vanilla 2.6.16 source and doing a make oldconfig. But I still get this problem

I've done a bit of compiling of modules in the last 2 years, but there's many gaps in my kernel compiling knowledge.

any help is appreciated??

[sbbaxter]

My other problem is, the disk is 50% full of stuff I can't afford to lose, and can't copy anywhere else - as I don't have 70G of spare storage anywhere. The whole 160G is in one single partition - so can't do a clean FC5 install.

[tashirosgt]

I don't have a clear idea of whether you have FC3 or FC5 installed, so whether the change from FC3 2.6.11.8 to 2.6.15-1.2054_FC5 would be expected to work is also unclear. Were you running FC5 with an FC3 kernel or vice versa?

As to compiling your own kernels, there are things in the configuration that affect raid and lvm, according to a search on "lvm" at:
http://kernel.xc.net/
All I can suggest is that you double check those items in your kernel configuration file. (Were you using raid on your hard drives?)

[sbbaxter]

I was running FC3 but couldn't get a newer kernel to run, due to problems (I think) with the LVM.

So, partially out of desparation, I did an FC5 upgrade from the DVD. This installed 2.6.15-1.2054.

I now have several kernels installed:
-2.6.11.8 - which was FC3 but now FC5 since the upgrade
-2.6.15-1.2054 from the DVD
-2.6.15-1.2096 from a YUM'd kernel update (while booted from 'linux rescue)
-2.6.16 vanilla - with a migrated 2.6.11.8 .config file and
-2.6.16.9, from a patched 2.6.16

2.6.11.8 is the only one that works. All others give the same error message:
Red Hat nash version 5.0.32 starting
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
2 logical volume(s) in volume group "VolGroup00" now active
WARNING: can't access
exec of init () failed!!!: No such file or directory
Kernel Panic - not syncing: Attempted to kill init!


perhaps this is an init version problem??

[sbbaxter]

OK - found why this is happening.

By default 2.6.15-1.2054_FC5 and 2096 and 2.6.16 and 2.6.16.9 are not compiling the 'init' command into initrd.

Finding this out meant buying a new disk, doing a fresh install and lots of work.

If I now go back to all the kernels (initrd files) I have installed, it's the same case. If I remove the 'init 5' or 'init 3' or 'init 1' off the grub.conf, all the kernels work.

Question for you now is, how do I get mkinitrd include the 'init' command????

[sbbaxter]

I've answered this now too.

Set the default runlevel in /etc/inittab - FC5 mkinitrd doesn't seem to support the 'init' command in the boot string

I'd always set the run level manually, or as part of grub.conf!!

[zackiv31]

A little more details to a NOOB would be appreciated baxter... How do I get my new kernels to boot (what exactly do I edit where)... and how do I make it somewhat permanent for all new kernel upgrades?

[sbbaxter]

Ok, sorry.

My problem was the /boot/grub/grub.conf line was:
title Fedora Core (2.6.16-1.2096_FC5)
root (hd0,0)
kernel /vmlinuz-2.6.16-1.2096_FC5 ro root=LABEL=/ rhgb quiet init 5
initrd /initrd-2.6.16-1.2096_FC5.img


looks like ANY FC5 kernel I tried (2.6.16-1.2096, 2.6.15-1.2054_FC5, 2.6.16.9), having 'init' in the kernel boot line resulted in the following error:
WARNING: can't access
exec of init () failed!!!: No such file or directory
Kernel Panic - not syncing: Attempted to kill init!

It looks like the 'init' command, which used to be available at boot time, is no longer. Your grub.conf now needs to be something like:
title Fedora Core (2.6.16.9)
root (hd0,0)
kernel /vmlinuz-2.6.16.9 ro root=LABEL=/ rhgb quiet
initrd /initrd-2.6.16.9.img


To permanently set which runlevel you want the system to boot to, edit /etc/inittab to include something like:
id:5:initdefault:
or
id:3:initdefault:
etc.

incidentally, you can check which runlevel you're on with the '/sbin/runlevel' command which returns 2 values $1 is the previous level & $2 is the current level.

[zackiv31]

So if my grub.conf is already in quiet mode I'm screwed?