[CentOS] LVM hatred, was Re: /boot on a separate partition?

[Lamar Owen]

On 06/23/2015 01:54 PM, Marko Vojinovic wrote:
> So the story ended up with lots of people in upgrading griefs purely
> because they couldn't resize the separate /boot partition, and it was
> separate because LVM was present, and LVM was present with the goal of
> making partition resizing easy! A textbook example of a catch-22,
> unbelievable!!
>

The Fedora /boot upsize was something I handled relatively easily with 
the LVM tools and another drive.  I actually used an eSATA drive for 
this, but an internal or a USB external (which would have impacted 
system performance) could have been used.  Here's what I did to resize 
my Fedora /boot when the upgrade required it several years back:

1.) Added a second drive that was larger than the drive that /boot was on;
2.) Created a PV on that drive;
3.) Added that PV to the volume group corresponding to the PV on the 
drive with /boot;
4.) Did a pvmove from the PV on the drive with /boot to the second drive 
(which took quite a while);
5.) Removed the PV on the drive with /boot from the volume group;
6.) Deleted the partition that previously contained the PV;
7.) Resized the /boot partition and its filesystem (this is doable while 
online, whereas resizing / online can be loads of fun);
8.) Created a new PV on the drive containing /boot;
9.) Added that PV back to the volume group;
10.) Resized the filesystems on the logical volumes on the volume group 
to shrink it to fit the new PV's space and resized the LV's accordingly 
(may require single-user mode to shrink some filesystems);
11.) Did a pvmove from the secondary drive back to the drive with /boot;
12.) Removed the secondary drive's PV from the VG (and removed the drive 
from the system).

I was able to do this without a reboot step or going into single user 
mode since I had not allocated all of the space in the VG to LV's, so I 
was able to skip step 10.  While the pvmoves were executing the system 
was fully up and running, but with degraded performance; no downtime was 
experienced until the maintenance window to do the version upgrade.  
Once step 12 completed, I was able to do the upgrade with no issues with 
/boot size and no loss of data on the volume group on the /boot drive.