In September, I updated packages on my Fedora 14 machine using ‘yum’ (Yellowdog Updater Modified), and rebooted. I was greeted with an unfriendly grub prompt. Boot was broken, and I didn’t know why.
Normally when I want to rescue a Linux system, I use the Fedora install DVD’s rescue mode. Unfortunately, my DVD drive stopped working just after the warranty expired. So I booted using a Linux-on-a-USB image that I carry around with me.
I planned on replicating the rescue mode experience by manually mounting the partitions in /mnt/sysimage, then chroot, and then run ‘grub-install’ to fix things. And that’s what I did, except for a few snags.
The first snag is that I had installed Fedora with default partitioning options (something I rarely do), and it had helpfully used LVM to configure my disk drive. LVM adds a layer of indirection, so I had to figure out how to mount an LVM volume instead of a disk partition. As a general rule, I never use LVM on desktop or laptop machines because I don’t like the additional complexity, especially when I’m trying to mount a drive to recover data.
The next snag is that Linux uses UUIDs for hard disks these days, instead of helpful, human-readable labels. In the good old days, Linux distributions would label the root partition, the home partition, and others. But not when I let the installer work its default magic. So, I had to figure out which volume contained my root partition, my boot partition, and so forth.
Once I mounted my partitions properly, I was ready to “chroot /mnt/sysimage”, and after I did, I ran “grub-install”. No luck. This was the third snag.
I realized that /boot/grub/grub.conf was empty. And grub-install doesn’t fix the problem — it can’t populate information that is completely missing, like knowing what disk UUID to use for the root partition.
“No problem,” I thought, “I’ll just restore from backup…”. Except, I didn’t have a backup. As a general rule, I back up /var, /home and /etc, but not /boot. Now I know better.
Surely, I thought, there should be a copy of grub.conf that the package updates had left around. But there wasn’t.
Such a critical file, and there was no automated backup. No “restore point”. No way to recreate it from data in /etc. What an oversight!
This is the first time I can remember having had an update eat my grub.conf file, and I’ve been running Linux since before distributions switched to grub as a boot loader. On the other hand, maybe I jumped to to an incorrect conclusion — it’s possible that the updates didn’t eat my grub.conf. Regardless, grub.conf was empty and my system wouldn’t boot.
It seems to me that something this important should have been designed with more resilence.
There were two ways to fix it, as far as I could see. One is upgrade from Fedora 14 to Fedora 14 (thus preserving my data). The second is to recreate grub.conf by hand, and for that, I needed an example — a template. I used the one at http://forums.fedoraforum.org/showthread.php?t=227358. My boot up screen isn’t as pretty as it once was, but it is functional.
Lastly, I made copy of /boot/grub/grub.conf. Now where did I put it?…