Howdy,
Debian is complaining that /boot is full and no wonder, it's only 488 MiB. I see some stuff I can remove, but I also want to resize the partition. other than a tiny /boot the rest is taken up by an LVM volume for my /home. I figured I'd split it up someday and LVM looked interesting.
Gparted let me shrink the LVM volume a bit to make a 1.5Gib space, but I can't seem to increase the /boot EXT2 partition with that free space.
KDE partition manager lets me resize the LVM partition but I also can't increase the size of /boot.
I'm thinking it's something about the LVM logical vs physical volumes.
What am I missing? I did all of this from live USBs of Fedora and Kubuntu and Pop! to see if it made a difference. There don't seem to be many GUI LVM tools but I worry I'm making some fundamental mistake because I've resized partitions for years without issue. Any help would be appreciated.
As a side note, why does KDE ppartition Manager think my big LVM volume is mostly full? It isn't even close, maybe 25% used.
You can move the partition at the end of the disk where OP has 1.5 GB of free space. It'll leave a 500MB gap before the LVM but it is what it is.
Call me old fashioned but I don't want to move partitions containing data, especially not on the same disk.
With LVMs there are specific tools to do it, which I would trust more than just moving s partition around
~~It's the boot partition, it needs to be a plain partition formatted as FAT32.~~ noticed it's a separate boot partition as ext2, but the point stands: most likely bootloader limitations.
That said you could also just make a new one, copy the data over and delete the old one once verified the data's all good.
I wouldn't do it with a larger partition but these days moving a 500MB partition takes a couple seconds top even on spinning rust, and it's a boot partition so it's kind of whatever. Very low risk overall, and everything on it can be reinstalled and regenerated easily.
Humm, I thought the boot partition was required to be at the start of the disk, os that not the case?
It doesn't, moving it to the end of the disk is a fairly common workaround for this specific issue. UEFI only looks for a GPT partition table and a partition within it with the UUID that corresponds to the EFI System Partition (ESP) type with a supported filesystem on it. The filesystem in question is implementation dependent, but FAT32 is guaranteed to be supported so most go with that. Apple's firmwares can also do HFS+ (and APFS?). More advanced firmwares also let the user add their own drivers, in which case as long as you can find a driver for it you can use whatever filesystem you want.
It is common however to do so, out of convenience. Usually it's other partitions you want to resize, and when imagine to a new bigger disk (or cloud environments where the disk can be any size and the OS resizes itself to fit on boot), then growing the OS partition is a lot easier. But the UEFI spec doesn't care at all, some firmwares will even accept multiple ESPs on the same disk.
Some older firmwares may also have had size limits where if it's too far in the disk it can't address it which would be problematic on very large disks (2TB+), but that's old EFI woes AFAIK.