I've just updated one machine from 4.0 to 4.2. The trouble is, the new kernel doesn't want to boot (2.6.9-22.EL, also tested 2.6.9.22.0.2.EL). Usually, manually recreating initrd file solved this problem in the past for me. But not this time.
Playing around, I also noticed that if I rebuild initrd for the old kernel, then it also fails to boot. The only way to boot it up is using the original initrd image created when the system was initally installed.
The machine has two volume groups, sys and backup. The sys volume group contains logical volumes with operating system, the backup volume group just holds some temporary application data.
Looking at what goes on the console during boot, the only difference between what happens is initialization of LVM (nash script in initrd image). With the old one, it reports it has found two volume groups (backup and sys, in that order), and then that it actived all volumes in both of them. With new initrd images, it reports it has found two volume groups, but activated only volumes from volume group sys. The root file system is part of sys volume group (so its logical volume should be active). The backup volume group contains file system with some data, and it's presence (or non-presence) theoretically shouldn't affect bootability of machine. However, booting still fails with root file system not mounted and of course kernel panic since it can't find init.
I've attempted doing several things (vgchange -a y, vgcfgbackup, checking the files it created, vgcfgrestore, then recreating initrd images). But nothing helped. I guess all needed device driver are correctly loaded, since it was able to detect volume group (and both volume groups are on the same RAID controller). Running mkinitrd in verbose mode looks fine too.
Any help would be greatly appriciated.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.