This turned out to be easier than expected, so I'm posting this short how-to. The restriction to ext3 is due to the man page for resize2fs claiming this is the only fs that can be resized without unmounting.
The scenario: you have an ext3 partition LogVol00 mounted on / and a swap partition LogVol01 in a logical volume group VolGroup00 (the default install), but you're running out of space in /, there's no room left in the volume group but you have a brand new disk drive with lots of free space. How to add some space to the / partition?
The usual problem is that / can't be unmounted, there are guides out there which involve using a livecd or dual booting into another os that recognizes logical volumes, but in this case you can do it 'on-the-fly' in Fedora.
WARNING: If you have important data in any directory under / then backup before attempting this.
I'll assume the spare disk is called /dev/sdb
1. Create a new partition of appropriate size using fdisk
Code:
fdisk /dev/sdb
n (create new partition, select start and end cylinders, all free space is selected by default)
w (save partition table and exit)
At this point you may be told that a reboot is necessary, I found it was unnecessary, but for safety you should probably reboot. Type fdisk -l again to check the new partition, I'll assume /dev/sdb1 was created ~10G in size
2. Create an ext3 filesystem in the partition (this step is optional, just a quick test that all is well)
Code:
mkfs.ext3 /dev/sdb1
3. Initialise the partition for use as a physical volume in lvm and add it to VolGroup00
Code:
pvcreate /dev/sdb1
vgextend VolGroup00 /dev/sdb1
4. Extend LogVol00 (use 'df /' to check that / is mounted on LogVol00) as required (by 10G here)
Code:
lvextend -L +10G /dev/VolGroup00/LogVol00
If you receive errors about not enough physical extents, then reduce the size of the extension a little until it fits.
5. Finally, resize the filesystem (this part normally would require unmounting /, but for ext3 and 2.6 Kernels it works while the partition is mounted)
Code:
resize2fs /dev/VolGroup00/LogVol00
Type 'df -h /', to check it worked, there should be an extra 10G available
(you can use vgdisplay, pvdisplay and lvdisplay (as root) to see detailed info, pvscan for a summary)
Note.
I've seen horror stories with lvm manipulation whereby an 'unknown uuid' error occurs for a partition, and the VolGroup can no longer be found, which prevents booting. This can be due to using e2label, mkfs etc on the partition after it has been initialised as a pv and added to the group. The error is fixable if you haven't rebooted: you need to edit /etc/lvm/backup/VolGroup00 and delete the lines referring to the unrecognized partition (they'll be a few between braces {}, the unknown uuid will be at the beginning, something like:
Code:
pv1 {
id = "gAMCGW-jdaH-VXse-HR2j-PA24-AIbb-aHMjKl"
device = "/dev/sdb1" # Hint only
status = ["ALLOCATABLE"]
dev_size = 20482812 # 9.76697 Gigabytes
pe_start = 384
pe_count = 312 # 9.75 Gigabytes
}
Remove all these lines, save the file, then run
Code:
vgcfgrestore -f /etc/lvm/backup/VolGroup00 VolGroup00
vgscan
vgscan should report all is ok (you can now try reinitialising the 'bad' partition using pvcreate, and then add it back to the VolGroup with vgextend)