Mine the Harvest

Resizing Default LVM Partitions and Moving /boot

by on Jan.23, 2010, under Linux

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.

:
4 comments for this entry:
  1. Kyle Anderson

    But if you are going through all this trouble, why even have the boot partition at all? Why not copy over your boot stuff and just get rid of the boot VG and expand the root to take up everything? Its 2010, motherboards and pick up on the big partitions now adays.

  2. admin

    Hi Kyle,

    Thanks for stopping by, always glad to have your comments.

    The problem is that we are talking about grub (not grub2) and LVM. In this scenario you actually need a /boot which is not in a VG as you can not just move the contents as you suggest. Expanding the root inside the VG won’t help unless you want to switch to grub2, which is going to introduce its own set of complications. Neither is it a matter of motherboards not picking up on big partitions, and in fact I expect this to be the case by locating /boot and the end of the drive. Yeah, I’m not trying to stay below the cylinder 1024 boundary with these new fangled drives 😉

    The basic issue that many users run into is accepting the default partitioning scheme many distros present which is a small /boot, grub (version .97) and LVM. The migration routes away from this I know of are as above, or to move to grub2 and be able to boot to kernels inside an LVM. (Some more discussion along this lines is here.)

    When I resolved this for myself I noted quite a few posts on boards with people who had gotten into this same scenario, and not many articles that were of any help.

  3. Thad Cassell

    Hullo, how are you doing? I really like ur blog! I wonder if u can assist me (I am positive some other readers might also be interested). I want to get involved in creating a blog as well and I currently have a blog with Word Press, but it is quite confusing for me to use and I would like to try to find several good training guides or courses (hopefully ones that are free) that can assist me in making use of wordpress correctly. As a Word Press web master yourself, do u perhaps maybe know where i could find tutorials to do this myself?? Thank you

  4. Unable to increase the size of boot partition

    […] to use EVMS to assist in resizing the LVM and making a new, larger /boot partition to migrate to: Resizing Default LVM Partitions and Moving /boot – Mine the Harvest I found this solution to be fairly painless. Cheers, Lews Therin Reply With Quote […]

Leave a Reply

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

RSS RSS My Ramblings

Visit our friends!

A few highly recommended friends...