One Does Not Simply Post Errors Without Context

So I was installing Xen on my CentOS VM. Probably not the best idea to begin with, but it’s a dependency for some software that is made by a company I recently applied for a postion at. Chances are, once they discover the absolute mess I made just trying to get the dang dependencies working, they will have a much easier time determining whether to hire me or not.

After the installation process, you have to reboot, and boot into Xen. When I went to do this, I was met with the VirtualBox startup splash screen, immediately followed by the grub bootloader screen, and a list of operating systems to choose from. Xen was automatically selected so I let it count down and begin booting.

However, instead of booting normally, I was once again met with the VirtualBox startup screen, the bootloader, and the list of OS’s.

Shoulda’ Backed It Up.

To remedy this situation, I thought I could just wait for the next grub screen to pop up, select the old operating system, boot into that, uninstall Xen, and reboot to find my system in roughly the same state as before the issue.

Oh just how wrong I was.

After booting into my old CentOS config, I went to /etc/sysconfig/kernel and set the param to default. Then I punched in

yum erase kernel-xen

And that’s where everything went wrong.

When I went to reboot the VM, I was met with the command line of the grub bootloader. And after a few minutes of poking around, I discovered that the contents of /boot/grub/grub.conf had been erased entirely. Leaving nothing but an empty file in its place.

How To Fix It

After hiding under my desk in the fetal position failed to produce any desirable results, I thought to myself “maybe the problem would be fixable if I actually tried to fix it.”

My first attempt involved trying to boot the VM from a live USB, and simply copying the grub.conf file over. However this ultimately proved unsuccessful as the operating systems had different configurations. (One was vanilla CentOS, the other was a Vagrant-provisioned CentOS install.)

Attempting to boot from the other grub file just caused the box to crash.

Next I tried unmounting the VM, mounting the disk as a filesystem on another VM, and extracting the critical files. This worked well, and I was able to move all critical files from the old disk onto the new disk. From there I was able to reinstall the VM, and restore it to its original working state by moving all the critical files I needed back onto it.

The only thing left to do was to reinstall some of the programs that had gone missing.

Conclusion

So maybe this post didn’t go quite as advertised. I wasn’t able to restore the original VM with all the original files, but I was able to essentially copy it all into an identical machine. Hopefully next time I can be smart about it and actually backup my VM before trying to do something like that.