If you use Linux, there will come a time when you update the system, only to have the machine fail to boot. Typically, you're dumped at a screen that looks like the one below:

I happened to have this happen to me, and the first thing I reached for was Super GRUB2. This usually works, but in my case, the boot disk didn't boot my system, so I was stuck with manually getting my system back up.

So I went a few rounds with Google, and eventually stumbled upon this really useful guide that got me reacquainted with all the GRUB stuff that I immediately forget after I fix boot issues. While this guide is pretty awesome in explaining what needs to be done to boot most systems, there were a few extra steps I had to take to make my system boot.

I set this system up with LVM, and the root filesystem is on LVM. In my case, GRUB2 would start normally, and then fail for some reason, just dumping me to a GRUB shell. Initially, GRUB2's environment looked like this:

OK, the prefix is set to a plausible value (since my /boot is in /dev/vda1 in this case), but the LVM isn't present as shown by the ls command. Using ls with nothing else lists the partitions known to GRUB2. You can use ls -l to get more information about the partitions. This is useful if you are not sure where your boot partition or root filesystem is.

The next step, since I know my root is on LVM, is to make GRUB2 recognize LVM. We do this with the insmod command. However, before this, you might not know the name of the module to insert. You can do an ls /grub to find the module name. (You may want to have pager=1 set before doing this, as there are a lot of modules.) In my case, I want lvm.mod. So we will insmod /grub/lvm.mod and hopefully have visibility to the currently-invisible filesystems on LVM.

Now we have two new partitions recognized: swap, and our root filesystem, both on LVM. Armed with the root filesystem device name, we can now get to loading a kernel. This is on your boot partition, so ls -l / will get you a list, which also lets you know the name of your initrd.

We want the latest kernel, and since we have LVM, we know that the root device will be under /dev/mapper. We also want the root filesystem to initially be mounted read-only. So now we can assemble our linux line. In this case, it pans out to the following:

linux /vmlinuz-3.2.0-49-generic root=/dev/mapper/puchuu-root ro

You will usually need to load an initrd as well, so we can get that out of the way by loading the initrd from the same version as the kernel we loaded: initrd /initrd.img-3.2.0-49-generic

At this point, everything is done loading, and we can boot with the boot command. With any luck, the system should now boot normally.

Once you're done recovering, you can now (hopefully) fix the GRUB error that caused the system to fail in the first place. Since I'm using Ubuntu, this is done with update-grub.

And that's it. You can try rebooting and see if the system starts properly.

--
In this case, I intentionally moved grub.cfg so GRUB2 would fail, just to demonstrate to you (and again to myself) how to manually boot the system.

( link )

---

Home