Shrinking an encrypted partition and enlarging /boot (was: Enlarging /boot and swap partitions)
On 2025-08-15 18:46:59 +0000, Andy Smith wrote:
> Hi Jonathan,
>
> On Fri, Aug 15, 2025 at 02:51:38AM +0000, Jonathan Wiebe wrote:
[...]
> > sdb 8:16 0 3.6T 0 disk
> > └─sdb1 8:17 0 3.6T 0 part /media/jonathan/Borg-Backup
> > nvme0n1 259:0 0 476.9G 0 disk
> > ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
> > ├─nvme0n1p2 259:2 0 488M 0 part /boot
> > └─nvme0n1p3 259:3 0 476G 0 part
> > ├─debian--vg-root 254:0 0 47.9G 0 lvm /
> > ├─debian--vg-swap_1 254:1 0 976M 0 lvm [SWAP]
> > └─debian--vg-home 254:2 0 408.1G 0 lvm /home
> >
> > As long as I am going through the process of resizing partitions I
> > thought I would increase the size of the /boot partition to 2 GB.
[...]
> It;s an okay plan but I would avoid the complicated and error-prone
> activity of shofting an entire partition and its data by instead
> relocating your ESP partition. So:
>
> - Shrink nvme0n1p3 PV by 1 GiB or so
Doesn't this need to shrink a debian--vg logical volume first?
Does LVM take care of freeing the data at the end?
> - Add new partition of 1GiB or so at the end after nvme0n1p3. Mark it as
> an ESP and format it vfat.
>
> - Copy data from nvme0n1p1 to the new ESP (nvme0n1p4)
>
> - Unmount old ESP
>
> - mkfs.ext4 nvme0n1p1 and mount it at /mnt/boot
>
> - Copy data from /boot to /mnt/boot
>
> - Unmount /boot and /mnt/boot
>
> - Destroy nvme0n1p2 that was old /boot
>
> - Grow nvme0n1p1 into the space freed up by destroying nvme0n1p2
>
> - Mount nvme0n1p1 at /boot and grow its filesystem into the full space.
> Your /boot is now as big as you wanted.
If I understand correctly, this can work only if the new /boot size is
no more 512M + 488M, i.e. about 1 GB, which might not be sufficient for
the next Debian release. Instead of having nvme0n1p1 (limited to ~1 GB)
as the new boot, couldn't the new /boot partition be put at the end,
as nvme0n1p4, and let the ESP in place? If allowed, this should be
simpler and allow a larger /boot partition.
Perhaps keep nvme0n1p2 as a backup for the current boot, but it could
also be used to grow nvme0n1p1 (/boot/efi) is need be in the future.
Moreover, in addition to that, shouldn't configuration be updated?
e.g. what should be done about the UUID?
In my case, the nvme0n1p3 partition is encrypted:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 953.9G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 488M 0 part /boot
└─nvme0n1p3 259:3 0 952.9G 0 part
└─nvme0n1p3_crypt 254:0 0 952.9G 0 crypt
├─qaa--vg-root 254:1 0 930.4G 0 lvm /
└─qaa--vg-swap_1 254:2 0 976M 0 lvm [SWAP]
According to
https://unix.stackexchange.com/questions/41091/how-can-i-shrink-a-luks-partition-what-does-cryptsetup-resize-do
it seems that KDE Partition Manager can handle that.
It is claimed that GParted cannot, but this was in 2020.
Any information?
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Reply to: