Ask Your Question

Revision history [back]

I'm assuming that you mean, that the Fedora LVM partition is using all the free space on the device, but that the filesystem on that volume is not full.

So, the filesystem containing your files has free space; as per df -h report; but the filesystem (FS), let's assume /, is on a logical volume (LV), let's say /dev/mapper/fedora-root, is on a volume group (VG) which we'll say is fedora, which in turn is using only the one device partition as a physical volume (PV), /dev/sda3, which in turn is filling the balance of space on the physical device /dev/sda. I'm further assuming that your root filesystem is ext4 (or ext2 or ext3) and not one of the more exotic options like btrfs or xfs. mount | grep 'on / ' will show you for sure, as will Gnome Disks. (“Contents: Ext4 (version 1.0)” or similar.)

You can adjust these things, but you'll have to boot from the LiveCD to do so — you can't reduce the size of a volume that is mounted, and you can't unmount /.

The “trick” here is, you have to reduce the size of each of the parts of that stack in order: FS and LV, then VG and PV (partition). If you do them out-of-order, you'll have “random” parts of your filesystem that get cut off. The tools are pretty good about warning you about that, and even trying to stop you from hurting yourself, but caveat, beware.

First, boot from a LiveCD/LiveUSB and get to a Terminal, then type sudo -s for superuser privileges.

Make sure your LVM volumes are recognized: type lvm lvs and you should see your logical volume. The mapper name will be the volume group - the logical volume name. ls /dev/mapper to check for its precise name; if it has punctuation or something, it may be “encoded” a bit, there,

Then, make sure the filesystem isn't borked in some way to begin with. fsck -f /dev/mapper/your-vg-your-lv (and go get a coffee).

Luckily, you can resize the FS and LV together. lvm lvresize --verbose --resizefs -L 10G /dev/mapper/vgname-lvname for example. (To specify instead to reduce it by a certain amount, use -L -5G or similar, ie, a negative number.)

This will take a while; and if you (eg) pull the plug, Very Bad Things will happen. Replace 10G with your target size. (Note, it means 10 GiB, not 10 GB. 1 GiB = 1,073,741,824 bytes, 1GB = 1,000,000,000 bytes. Hard disks are sold in GB, not GiB; sadly, a lot of tools still use the two units interchangeably.)

This next part is only needed if your new OS doesn't understand LVM. If you're installing, say, Red Hat or Ubuntu, you can add a new LV to the same VG, and all is well. If you're installing, say, Haiku OS, continue:

Once the LV is resized, your VG should have free space available; lvm vgs will show the free space. We can reduce the VG and PV together with lvm pvresize --setphysicalvolumesize 10G /dev/sda3.

One possible issue is if you have sectors that have to be re-arranged; you'll get an error about extents being used after the new end of the volume. That's a bit trickier. The solution is to move them first. Use lvm pvmove --alloc anywhere /dev/sda3:2560-end — and you'll want to know, what is that magic number 2560? That number is the number of “physical extents” that your new PV will have. The physical extents are almost always 4MiB, so you can find that figure by calculating your size in MiB ÷ 4MiB⁄extent … so 10 GiB = 10 × 1024 Mib = 10,240 MiB; 10,240 MiB ÷ 4 MiB⁄extent = 2560 extents.

After doing the pvmove, you can retry the pvresize.