On 8/14/25 19:51, 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.My /boot partition is only 488 MB in size. Here is the output of lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 512M 0 part ├─sda3 8:3 0 9.3G 0 part ├─sda4 8:4 0 23.8G 0 part ├─sda5 8:5 0 9.3G 0 part └─sda6 8:6 0 851.3G 0 part /home/jonathan/Storage 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?) Three questions: 1. Does the above outline make sense? 2. Can anyone point me to the documentation which will show me how to do this? 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?Thanks! -- 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.
I am curious about sda -- ~31.2G is unaccounted for. Is that for SSD over-provisioning?
2025-08-15 14:32:52 dpchrist@laalaa ~ $ perl -e 'print 931.4-0.512-9.3-23.8-9.3-851.3, $/' 37.1880000000002 Both sda and nvme0n1 each appear to have both an OS and data:1. I put each OS instance on its own disk and put as much data as possible on a file server. I keep my OS instances small enough to fit onto a "16 GB" device -- HDD, SSD, USB flash drive, SD card, etc.. I allocate "1 GB" each for ESP, boot, and swap, and most of the remainder for root:
2025-08-15 15:19:42 dpchrist@laalaa ~/bullseye-secure-uefi.tracy.holgerdanske.com/examine-host.out
$ grep -v nvme lsblk.out NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 14.9G 0 disk |-sda1 8:1 0 953M 0 part /boot/efi |-sda2 8:2 0 954M 0 part /boot |-sda3 8:3 0 954M 0 part | `-sda3_crypt 254:1 0 954M 0 crypt [SWAP] `-sda4 8:4 0 11.2G 0 part `-sda4_crypt 254:0 0 11.2G 0 crypt /2. Combining the OS and data on one disk complicates disaster preparedness and recovery via imaging (e.g. dd(1), Clonezilla, etc.). It is easiest and safest to take an image of an entire disk -- you know everything is in sync. But when the disk has OS-plus-data, imaging takes longer and requires more storage. Moving the data into a dedicated partition is a work-around, if you are willing to manage piecemeal images -- MBR, primary GPT, ESP, boot partition, swap partition, root partition, secondary GPT, etc..
3. Keeping the OS instances on a separate drive facilitates OS major version upgrades via backup, wipe, fresh install, and restore. I find this approach to be simpler, to be more likely to succeed, and to produce a result that is more reliable than OS major version upgrades via in-place modification. And, the former approach forces me to exercise my backup and restore skills.
4. Motherboard firmware, the Windows installer, Windows Update, the Debian installer, update-grub(8), update-grub2(8), etc., typically look for bootable partitions and/or ESP's on all disks in a given computer. If you have multiple disks with such, the result could be confusion and broken boot for one or more OS's. I avoid these problems by installing mobile racks in my computers, putting each OS on its own disk, and inserting only one OS disk at a time (except when I boot a live disk to work on the OS disk).
David