After performing an upgrade of my work laptop from Fedora 11 to 12, I needed to restore access to my virtual machines. My upgrade consisted of booting off the installation media and wiping all the partitons and volumes that didn’t contain important data, essentially leaving me with a fresh install of Fedora 12.
As I had originally built the machines using logical volumes as the virtual disks, the VMs were untouched by the Fedora upgrade. However, the / partition of my Fedora installation had been overwritten and the VM definitions were lost, which meant that I was presented with a blank virtual machine manager when I opened the tool.
I ran through the wizard for creating new virtual machines and when prompted to define the storage to use, I simply used the relevant logical volumes from my local hard disk. When I tried to boot the VMs, however, the process only got so far before a kernel panic would occur, with the following error message:
After some investigation, I realised that the VMs were configured to present the virtual disks to the instances as virtio devices. The machines had originally been instantiated using virtual IDE disks, so I modified their current configuration to reflect this.
This time when I powered on the machines, they booted successfully and I was able to get on with the original task I had in mind. However, this wouldn’t help me should I end up in the same situation again following another upgrade / rebuild. The reason why the system failed to boot in the first place was that the initial ramdisk image did not contain the relevant modules to allow the kernel to recognise the virtio disks. The initial ramdisk image is used to store the kernel modules required to allow a booting system to locate the root file system; a critical step!
In order to build a ramdisk image, I had to reconfigure one of the VMs so that the disk was presented as a virtio device again and use CentOS installation media to boot into the available “rescue mode”. This can locate and mount an existing Linux installation on the available storage at the mount point:
/mnt/sysimage – this means that running the command
chroot /mnt/sysimage places you inside a chroot jail, essentially allowing you to execute commands as if you had booted into the operating system as per usual.
The command to generate an initial ramdisk image requires two arguments:
mkinitrd <image_file> <kernel_version>
The first of these two arguments, <image_file>, is used to define the file output by the process of creating the ramdisk image. The second is the version of the kernel you are making the image for. I knew that my system would, by default, boot into the latest kernel present, so I simply listed the installed kernels to confirm the version. I made a copy of the existing ramdisk image stored in the
/boot directory and executed the following command:
mkinitrd /boot/initrd-2.6.18-164.11.1.el5.img 2.6.18-164.11.1.el5
Once the command finished, I simply exited the rescue system and successfully booted the installed operating system!