Mine the Harvest

Standard Disclaimer: This article makes recommendations on using tools to modify your LVM configuration, your /boot partition, kernel and grub. Data corruption from a mangled LVM, or a (temporarily) unbootable system through a corrupted or mis-configured grub, etc. are entirely possible. I am not responsible for any of this. If you have a running system and break it by changing these things, please realize that I am not to blame, nor will I be able to help you fix things. And of course, making complicated changes on a production environment is not advised. However, if you need to migrate to a larger /boot partition the following may help you. If you are unfamiliar with partitioning, LVM and grub, please plan on having a least a few hours to work your way through this the first time. Also, have a Live CD and possibly the SuperGrub CD already available before hand. You may also want to practice on a virtual machine before trying this on a running server, etc. Installing Virtualbox and setting an a test VM takes only minutes and provides a superlative learning environment.

There is only so far you can get with a 69M /boot.

If you are like me, when you last installed your distro you likely decided to go with the proposed LVM layout. Hey, why not right? This way you can more easily change the sizes of your logical volumes, adding more to home, stealing some from that /whatever slice you just never really ended up using. Plus you can always add another physical drive later for juicy (or potentially disastrous, I’ve heard it both ways) multi-volume LVM expansion goodness.

Or perhaps you just said “yea, sure — whatever” on the partitioning steps.

Despite the best, or worst, planning you at times just need to fix what you are left with.

In my case, for some reason know to only God and the face on Mars, when I last installed Suse I accepted the offered LVM layout, and along with the the pathetic 69M /boot partition. Well, as you start to add some other kernels for Xen, the Suse default and desktop kernels, and if you want to keep any old versions of these, or compile your own, you very quickly realize what a mistake you made.

Now, fixing this is not superlatively difficult of course, but there are easy ways and hard ways.

The hard way involves manually shrinking the LVM Volume Group (vg) which also requires shrinking the Logical Volums (lv) which it contains, which of course requires shrinking the filesystems they contain. Oh the pain.

You might think that booting to a Live CD and using gparted is the answer to your prayers, but nope. It lacks LVM support, though it’s been on the drawing boards for some time it has yet to arrive.

However, this lead me to discover the Enterprise Volume Management System at it’s sourceforge page.  This is quite a sophisticated filesystem management tool with many options and much greater granular control over your block storage device file systems. Take a look at these EVMS screenshots, oh yes indeed — be still my heart.

Depending on your distro and repos you may be able to simply install evms and evms-gui through your package manager. I simply used an Ubuntu LiveCD and installed both from the standard repos in minutes and was up and running.

Once EVMS is installed, the answer to you tiny /boot partition — sorry, your “size challenged” partition, are but a few clicks away. The basic recipe is:

1) Use EVMS to shrink the Volume Group a bit. You likely just need to shave off a few hundred megs to make a new /boot with

2) The drive will likely now have space at the end of the device, the resize of the VG is more easily done by working from the end of, rather than the start of, the VG boundaries. This space is now unpartitioned and available. Simply create a new ext3 partition from it as you normally would, then mount it as perhaps /newboot.

3) Copy / move your files from your old /boot to your /newboot. This includes all the kernels, initrd files and (very important) the grub folder and its contents.

4) Edit the menu.1st file in your grub directory in /newboot. You will have to change the root (hd0,0) lines for each kernel to point to the new location, perhaps root (hd0,2). You may also have a line near the top: gfxmenu (hd0,0)/message which will also need updated.  (The next step clarifies the numbering scheme used.)

5) Set up grub so that is will look to the new partition when booting. This is normally done by reconfiguring grub so using the grub command interface. In my case:

# grub
grub> root (hd0,2)
grub> setup (hd0)
grub> quit
# reboot

Here we are telling grub that my new grub root (NOT system root) is (hd0,2). Grub numbering starts at zero, so this in fact is telling it /hda3 (First drive, third partition). The setup command then installs the boot code into the MBR which will now look to the new /boot partition. (This points grub “stage one” that runs at boot to the location containing the files in the /grub directory (grub “stage 2”.)

If things go horribly wrong, DON’T PANIC. The most likely scenario will be that you reboot and end up at a scary grub> prompt. It is just a matter of telling grub which partition contains the kernel and initrd with the root(hdx,y) command, and then specifying the kernel=vmlinuz-2.6.blah and initrd=initrd-2.6.blah followed by the boot command. Note that grub allows for tab completion on all these steps, so it is usually not difficult to get up and running again.  Grub is quite fantastic really, and has a powerful built in environment available at the grub> prompt. If you get stuck on this step, these web sites are loaded with info that should help you get it sorted out.

This Linux Journal Magazine article is a fantastic place to learn more about grub commands and how to directly boot a kernel as briefly outlined above.

And this troubleshooting site has some other useful information on grub. (See the section “making it happen at boot time”)

Of course, there is also the official grub documentation pages.

Lastly, if you get hopelessly stuck and can’t boot your system you might find the SuperGrub Boot CD may save your day. This is a very handy tool and has a menu driven system to help recover from a variety of boot / grub / MBR  related problems.

Closing notes:

I also see there is an evms-2.5.5-initrd.gz file in the downloads, which leads me to think how easy it may be to set this up on a PXE network so this tool is readily available to you in a networked environment so you could quickly boot to it and have the tools directly available for system maintenance. I’ll have to play around with that a bit.

Another option is to follow this post and use the Fedora system-config-lvm package (converted to a .deb package if you need) which provides a similar GUI LVM management tool. However, EVMS is far more extensive. But its always good to have options.

I hope the above suggestions are helpful to you and that you find evms to be as valuable as I did.

These partitioning issues can be difficult, and having tools like evms can certainly make it much easier.