At my company, we have many Red Hat Linux (v5.4) VMs running in ESX with vCenter 4.1. We wanted to upgrade from RHEL54 to RHEL55 and used "yum update" to upgrade all RPMs. All RPMs upgraded without error, even the kernel RPM (to v2.6.18-194). The problem is when we reboot the VM using the new kernel, it PANIC's like this:
Red hat nash Version 5.1.19.6 starting
Unable to access resume device ( /dev/sda7)
mount: Could not find the filesystem '/dev/root'
setuproot : moving /dev/ failed : No such file or directory
setuproot : error mounting /proc : No such file or directory
setuproot : error mounting /sys : No such file or directory
switchroot: mount failed : No such file or directory
kernel panic - not sysncing: Attempted to kill init
If you select the older kernel via grub, the VM boots just fine. The VM disk controller is pvscsi and the ethernet driver is vmxnet3. This seems to be a problem with the initrd of the newer kernel. Do I need to have the pvscsi kernel object installed into the initrd? If so how do I tell vmtools to install itself into a different kernel than is booted (I can boot 2.6.18-164 but I want to install it into 2.6.18-194)?
Does this mean we cannot utilize "yum update" for Red Hat guest OS upgrades?
Thanks in advance for any help or advice.
Greg Shepherd
Did you run vmware-config-tools.pl after the upgrade? If not, try booting the old kernel and running vmware-config-tools.pl with the --kernel-version or -k option (and your new kernel version after that), which could be used to "Build/install modules for the given kernel version instead of the running one, implies modules-only, skip-stop-start and compile."
vmware-config-tools --help
I'm not sure how I missed the vmware-config-tools.pl utility, thank you for pointing that out. It did not work quite right but it started me towards the solution.
I ran it "vmware-config-tool.pl --kernel-version 2.6.18-195.el5" but it did not work correctly. It did build a new initrd file but it named it the same version as the running kernel (/boot/initrd-2.5.18-164.el5.img), not the specified version given with --kernel-version flag. I even renamed this new initrd to /boot/initrd-2.5.18-194.el5.img and tried booting with it, but it seems to be a mix of the two kernel environments and it still PANIC'ed at boot.
I did get the new kernel to work in this way:
cd /lib/modules
cp -pr 2.6.18-164.el5/misc 2.6.18-194.el5/
cat 2.6.18-164.el5/modules.alias | egrep 'vmci|vmx|pvscsi' >> 2.6.18-194.el5/modules.alias
cat 2.6.18-164.el5/modules.dep | egrep 'vmci|vmx|pvscsi' >> 2.6.18-194.el5/modules.dep
cat 2.6.18-164.el5/modules.pcimap | egrep 'vmci|vmx|pvscsi' >> 2.6.18-194.el5/modules.pcimap
I also had an original copy of the /boot/initrd-2.5.18-164.el5.img file because vmware-config-tool.pl kept over-writing the good one.
Thank you,
Greg Shepherd
Just a point of clarification. After copying the kernel modules into /lib/modules/ and modifying the three module files, you have to manually create the initrd like this:
/sbin/mkinitrd -f --with=vmxnet3 --with=vmxnet --with=pvscsi /boot/initrd-2.6.18-194.el5 2.6.18-194.el5
reboot and the new kernel should be booted.
then run vmware-config-tools.pl and reboot again
It got me a bit of trouble getting it to work on a VM previously configured to use PVSCSI bus, but finally got it working with kernel update and tools reconfiguration without any reboots.
vmware-config-tools.pl is buggy because it always assumes you are installing/compiling the modules for the current kernel, independently of you passing the -k argument overriding the kernel version.
The internal compilation is also buggy because it installs the compiled modules in the current kernel directories instead of the new one. That's why I backup some files before module compilation and restore it later so the old kernel is still bootable.
Following is the full procedure I used (working and tested) without typos or partial information. Enjoy and let's hope VMWare fixes their buggy scripts so we don't have to do this manuallly like this:
# Reboot into the new kernel without any VM configuration changes needed
Here is more detailed article.with thorough explaination on the issue
http://www.rdoxenham.com/?p=218
Hope this helps...