Comment on Debian /boot is full - LVM complicating resizing the partition
stoy@lemmy.zip 1 day agoCall 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
Max_P@lemmy.max-p.me 1 day ago
It’s the boot partition, it needs to be a plain partition formatted as FAT32.
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.
stoy@lemmy.zip 1 day ago
Humm, I thought the boot partition was required to be at the start of the disk, os that not the case?
Max_P@lemmy.max-p.me 1 day ago
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.