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.