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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
“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.<\/p>\n
Surely, I thought, there should be a copy of grub.conf that the package updates had left around. But there wasn’t.<\/p>\n
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!<\/p>\n
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.<\/p>\n
It seems to me that something this important should have been designed with more resilence.<\/p>\n
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.<\/p>\n
Lastly, I made copy of \/boot\/grub\/grub.conf. Now where did I put it?…<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … <\/p>\n