-- Jonathan Wiebe Our passions are there to drive us to act, not to be the seasoning of our emotional stew. Sent with Proton Mail secure email. On Friday, August 15th, 2025 at 11:47, Andy Smith <andy@strugglers.net> wrote: > Hi Jonathan, > > On Fri, Aug 15, 2025 at 02:51:38AM +0000, Jonathan Wiebe wrote: > > > I am going through the process of preparing my bookworm system for upgrade to trixie. > > > > The following statement from section 5.15 of the release notes caught my eye: > > > > - Before starting the upgrade, make sure your `/boot` partition is > > at least 768 MB in size, and has about 300 MB free. If your system > > does not have a separate `/boot` partition, there should be nothing to > > do. > > > Realistically I think you are likely to be okay and able to wait quite a > while before this problem gets near to hitting you, especially if you > take care to purge every linux-image package that you are not using > (i.e. every one except the kernel you are currently booted under) before > you do the upgrade. > > > My /boot partition is only 488 MB in size. Here is the output of lsblk: > > > When I read the subject line I prepared myself to see yet another crazy > soup of fixed size partitions. What a breath of fresh air to see volume > management in use. > > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > > > [I omitted "sda" as doesn't seem to be part of your plans.] > > > 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. > > I am also thinking of increasing my swap partition from 1GB to 32 GB (I have 32 GB of RAM). > > > > So what I believe I have to do is: > > > > 1. Reduce the size of the lvm logical volume debian--vg-home by 32.5 GB. > > 2. Increase the size of the lvm logical volume debian--vg-swap by 31 GB. > > 3. Reduce the size of the lvm physical volume by 1.5 GB. > > 4. Move the lvm physical volume to the right (if that is the correct way to put it) to make room for the increased size of /boot. > > 5. Increase the size of the /boot partition by 1.5 GB. > > > > (Do I need to move the lvm logical volume debian--vg-home before extending swap?) > > > No; in reality "debian-vg" is made from the contiguous extents of > nvme0n1p3 organised by LVM and its ordering in "lsblk" output is only > because of the minor device number it got assigned, which is based on > the order you created the logical volumes. Its extents could be anywhere > inside that partitions (though are likely to be entirely linear). > > > Three questions: > > > > 1. Does the above outline make sense? > > > 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 > > - 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. > > I prefer this way because the only data you ever really mess with is the > relatively unimportant contents of /boot and the ESP. And you can do it > all online without even a reboot. It's true that you do still have to > shrink the LVM PV but LVM makes it simple to do that, e.g. shrink it by > 2 GiB, shrink the partition it's on by 1 GiB and then gow the PV back to > the full size it's allowed. > > Your proposal to shift the contents of a massive partition will involve > rewriting a large amount of data. > > > 2. Can anyone point me to the documentation which will show me how to do this? > > > The man pages of pvresize and whatever partitioning tool you are most > familiar with, e.g. parted, should be enough for what I propose. > > If you are dead set on relocating a massive partition, I've done it from > the command line with sfdisk. > > > 3. Am I over complicating things? Should I just backup my home > > partition and re-install from scratch with all new partitions and then > > restore /home? > > > I think your way is fairly perilous but still doable (and you can always > reinstall if you scre wit up anyway, I mean you already do have backups > right 😀). I think my way is fairly simple and I wouldn't hesitate to do > it. > > As mentioned I also think you can stand to put off this work for quite > some time. My freshly installed trixie laptop from a week or so before > official release is using 97 MiB in /boot. > > Thanks, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting Thanks for your very detailed answer Andy! I very much appreciate you and all of the contributors on this list.
Attachment:
publickey - jonathan.b.wiebe@proton.me - 0x835A0CE0.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature