How can I expand the /boot partition on a LUKS LVM full-disk

[Praxis]

...without having my head explode.

I used the automated full-disk LUKS encryption LVM method from the ISO back when Jessie was still in testing.

# deb cdrom:[Debian GNU/Linux bullseye-DI-b2 _Jessie_ - Official Snapshot amd64 kde-CD Binary-1 20141883-18:31]/ bullseye main

This created a lordly 236MB unencrypted ext2 boot partition and an encrypted LVM that filled the rest of the disk. At the time that was enough space for a few kernels, at this point it is not enough for 2 on one system! I get an error that there is no space left on the device:

Code: Select all

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-X.XX.X-X-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

Hitherto, I have been able to run an "apt-get autoremove" or manually remove older kernels and delete old dkms files from /boot, but now on one system that isn't even enough and I have to reboot on to the not-completely-installed new kernel and manually remove the only other kernel on the system in order to make the 'apt-get dist-upgrade' complete. This is frustrating and time consuming and soon I won't be able to even do this as the kernels keep expanding like my waist-line.

Personally, I think that the folx that wrote the formula for the automatic encrypted partitioning should be placed in the same digital pillory as whoever is supposed to have said "640 KB ought to be enough for anybody" in DOS a generation back. When I installed these systems drive space was already ridiculously cheap, I bought 4 x 120GB SSDs for about $150, < $40 a piece. Seems like the coder should have anticipated that 256MB would be a real limitation in just a few years and devoted at least a GB to the /boot partition. Oh well, it serves me right for accepting the installer defaults and it is water under the bridge.

I've been looking around the net for a way to shrink the LUKS encrypted LVM partition and expand the tiny ext2 /boot partition and it seems wildly complicated. I'm comfortable enough with the command line but so far this is the best guide I have found, and frankly, it makes my head spin: https://ubuntuforums.org/showthread.php?t=726724 It involves multiple commands where you need to guess the number of bloody cylinders on the partitions.

I'm sure this issue has come up before, but I've searched the forum in vain. I've played around with GUI programs like gparted, KDE Partition Manager & gnome-disk-utility and none of them seem to be up to the task of resizing and moving LVM partitions, the cryptsetup container, etc. (though KDE partitionmanager seems to be the most capable of the lot).

Has anyone successfully expanded the /boot partition on a full-disk encrypted LVM system, and if so, can they point me a useful resource that won't force me to completely digest a bunch of arcane tldp & man pages and risk exploding my computers?

[mm3100]

I will just ask in case you have EFI partition?, as then you could shrink EFI partition, move and then expand boot one.

[CwF]

I have two full disk LVM setups installed originally as Jessie with the deficient partitions. As it turns out that is plenty room for the one kernel needed. At ~40% it's just enough to upgrade, then delete the unneeded kernel. Upgrading hasn't been an issue.

If it becomes an issue my thought is to simply boot it from a separate disk, ie relocate /boot.

[p.H]

I assume that the /boot partition is stuck between the beginning of the drive and the encrypted partition, so in order to enlarge it you would need to move the whole encrypted partition ? IMO, the easiest way to enlarge /boot partition is to reduce the encrypted partition (after reducing the LVM PV inside) and create a new bigger /boot partition at the end of the drive.

If there is an EFI partition, it is usually oversized so you can reduce it in order to increase /boot.

An alternative is to not use a separate /boot. This requires / on LUKS1 not LUK2 (should be LUKS1 if originally created with jessie) and reinstalling GRUB with GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub.

Another solution may be to reduce the size of initramfs files. With the option MODULES=dep instead of MODULEs=most in /etc/initramfs-tools/initramfs-tools.conf, update-initramfs will include only required modules for this system. If plymouth is installed, you may also remove it to save a few more bytes.

[Praxis]

Thanks for the suggestions, fellow deuterostomes.

There are no EFI partitions to rob, but moving the /boot to another disk should be doable, if worse comes to worse, I suppose a USB stick would work. I'll report back on my progress. p.H.'s suggestions also look interesting. Slimming down the kernel should be fine for these old boxen. And it does appear the the systems are encrypted with LUKS1 if I glean aright:

Code: Select all

cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        512
MK digest:      92 e8 d9 d7 46 f7 d3 7b 5c e4 96 06 f7 1a 9f 99 73 3b b0 f0 
MK salt:        f1 35 4d 62 99 67 93 d8 f5 3f 8b 9f 4b ff ae 87 
                36 ee 43 67 89 4c 9b ca 29 32 b7 cd 03 f2 44 b7 
MK iterations:  41000
UUID:           blahblahblah
Key Slot 0: ENABLED
        Iterations:             174863
        Salt:                   4d 7e c3 f0 e9 c2 98 6a 60 22 65 cc 7f 95 ec 97 
                                6f e7 e6 4d 22 a5 1b 91 27 ba 58 a0 57 d5 a7 45 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             230215
        Salt:                   14 76 86 e0 17 54 6d 89 31 0f 58 e3 95 6a 90 03 
                                01 80 3e b5 1d 64 1f c5 b3 34 28 2a 4e 7c c1 a6 
        Key material offset:    512
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

A little wrinkle I discovered while playing around with a scratch disk copy of one of these systems, even if I was successfully able to shrink the LVM/encrypted container and move the whole thing to the end of the disk, the free space is still on the extended partition, so I can't just expand the /boot partition, I have to make a new ext2 partition and copy things over. Or I guess I could try shrinking the extended partition with gparted, it will take a long time (about 90 minutes).

[CwF]

I suppose a USB stick would work

Yep, call it a "security key" and intentional!

[p.H]

I was successfully able to shrink the LVM/encrypted container and move the whole thing to the end of the disk

In most cases, you do not need to move the shrunk partition at the end of the disk (it takes time and causes massive data loss if the process is interrupted) ; you can just create a new /boot partition in the free space at the end of the disk. You need to move the partition so that the /boot partition remains near the beginning of the disk only when the BIOS is broken and cannot access the end of the disk.

the free space is still on the extended partition, so I can't just expand the /boot partition, I have to make a new ext2 partition and copy things over. Or I guess I could try shrinking the extended partition with gparted, it will take a long time (about 90 minutes).

Shrinking an extended partition does not imply moving any data so it should not take much time.

Extended partitions are annoying, fragile and useless when you need up to 4 partitions. A typical installation with encrypted LVM requires only 2 partitions : /boot and the encrypted LVM container, so an extended partition is useless. I guess you selected guided partitioning during the installation, which automatically creates an extended partition even when not needed. I do not use guided partitioning because of its shortcomings and use manual partitioning instead.

I would remove the extended partition and convert the logical partition into a primary partition with sfdisk, or go extreme and convert the DOS/MBR partition table to GPT with gdisk (requires creating a new "BIOS boot" partition in any free space of at least 100 kB and reinstalling GRUB).

[Praxis]

I suppose a USB stick would work

Yep, call it a "security key" and intentional!

I don't believe using a USB stick will work, or at least it didn't for me when I did a recent upgrade of a LUKS encrypted LVM from *buntu 20.04 to 22.04. The machine started as Trusty, Tahr, 14.04 and had the miserly 243 MB /boot ext2 partition. The upgrade gave me an error on the initrd stuff. When I rebooted I got a kernel panic. So I booted back to the previous kernel and got another kernel panic! Both of those are firsts for me, but harbingers of what is coming soon to these old Debian installations. So I stuck in a USB flash drive, made an ample ext2 partition, then booted a live Debian USB system I have for these emergencies and decrypted the 22.04 installation with "cryptsetup luksOpen /dev/sda5 sda5-crypt" and chrooted to it, copied everything from my SSD's tiny boot partition to the flash drive's 1.2 GB ext2 partition, then edited my fstab to point to the UUID of the new flash drive ext2 partition. Then I ran a full 'apt-get dist-upgrade' with finally completed properly, having enough room. Rebooting grub could not find the UUID, apparently USB devices are not activated at that point in the boot process.

So I booted from my live system again, decrypted & chrooted in the new Jammy 22.04 kernel, removed the remaining Focal 20.04 kernel, then deleted the stuff that was on my original 243 MB /boot partition and copied everything from the new flash drive boot partition, changed the line in my fstab to point to the original /boot partiton, and reinstalled grub and did an "upgrade-grub" for good measure. On rebooting I was able to start the computer normally, but what a hassle.
And all because some savant figured that "640 kb should be enough for anyone", er, 243 MB should be plenty for a /boot partition for the life of the installation.

What I find mind bending is that the Debian full disk LUKS installation currently sets up a 500 MB ext2 boot partition! Obviously if the kernel continues to grow at the rate it has historically that is going to be inadequate in a few years. And you can buy a terabyte SSD for under $60 in the US, its not like it would be a problem to set up the installer to make a 2 GB partition.

As my old Debian & Ubuntu encrypted systems become too much of pain to maintain I think I may migrate to a new project called Spirallinux, it sets up a mostly pure-Debian system with a Calamares installer that manages to do without an encrypted boot partition at all, everything is in the main LUKS encrypted LVM so you can have as many kernels as you want.
https://spirallinux.github.io/

The downside is that for some reason encrypted Spirallinux takes 15-30 to start booting up after I enter my encryption key, but I can always distract myself with something. Apparently you can't have everything, but I'll take a slow boot over an installation with a 8 year life-expectancy every time.

[p.H]

The machine started as Trusty, Tahr, 14.04 and had the miserly 243 MB /boot ext2 partition

Which is kind of funny when you know the tendency of Ubuntu to accumulate kernels over time. I have seen Ubuntu systems with more than 20 installed kernels !

The upgrade gave me an error on the initrd stuff. When I rebooted I got a kernel panic.

Seriously, did you really reboot without fixing the "initrd stuff" first ? You are aware that you cannot boot with a valid initramfs, don't you ?

copied everything from my SSD's tiny boot partition to the flash drive's 1.2 GB ext2 partition, then edited my fstab to point to the UUID of the new flash drive ext2 partition. Then I ran a full 'apt-get dist-upgrade' with finally completed properly, having enough room. Rebooting grub could not find the UUID, apparently USB devices are not activated at that point in the boot process.

Indeed some BIOS do not expose USB drives after booting from an internal drive.
Did you try to install GRUB on the USB drive and boot from it ?

the Debian full disk LUKS installation currently sets up a 500 MB ext2 boot partition! Obviously if the kernel continues to grow at the rate it has historically that is going to be inadequate in a few years.

IMO 500 MB for /boot should be more than enough for 2 or 3 kernels for quite some time. Anyway, if you are unhappy with the guided partitioning sizes (as I am), why don't you just select manual partitioning (as I do) ?

[hamishm]

Why are your kernels so big? I have 3 and my /boot is under 200Mb including EFI, and that's including AMDGPU firmware.

Have you configured your initramfs generator to include more than needed?

I have switched to dracut rather than the default generator, which might help (though that isn't the reason I switched).

[Praxis]

Why are your kernels so big? I have 3 and my /boot is under 200Mb including EFI, and that's including AMDGPU firmware.

Have you configured your initramfs generator to include more than needed?

I have switched to dracut rather than the default generator, which might help (though that isn't the reason I switched).

hamishm, I'm not going out of my way to bloat my kernels, just using the default linux-image-amd64 meta-package. Here is the machine I am on now:

Code: Select all

ls -lh /boot  ; df -h | grep boot

total 166M
-rw-r--r-- 1 root root 231K Jul 23 15:32 config-5.10.0-16-amd64
-rw-r--r-- 1 root root 231K Aug 13 06:25 config-5.10.0-17-amd64
drwxr-xr-x 5 root root 1.0K Aug 31 13:13 grub/
-rw-r--r-- 1 root root  76M Aug 31 13:12 initrd.img-5.10.0-16-amd64
-rw-r--r-- 1 root root  77M Aug 31 13:13 initrd.img-5.10.0-17-amd64
drwx------ 2 root root  12K Oct 31  2015 lost+found/
-rw-r--r-- 1 root root   83 Jul 23 15:32 System.map-5.10.0-16-amd64
-rw-r--r-- 1 root root   83 Aug 13 06:25 System.map-5.10.0-17-amd64
-rw-r--r-- 1 root root 6.6M Jul 23 15:32 vmlinuz-5.10.0-16-amd64
-rw-r--r-- 1 root root 6.7M Aug 13 06:25 vmlinuz-5.10.0-17-amd64

/dev/sda1                         ext2  234M  177M   45M  80% /boot

On this install I can fit two kernels, but not three. For some reason on other installs I can't even properly completely fit 2 kernels. It is kind of odd since my Debian installs are all cloned from the same source installer, and I haven't treated them differently, DI-b2 _Jessie_ - Official Snapshot amd64 kde-CD Binary-1 20141883-18:31.

I hadn't tried to configure my initramfs, thank you for the suggestion of dracut, that made a huge difference.

Code: Select all

ls -lh /boot  ; df -h | grep boot

total 82M
-rw-r--r-- 1 root root 231K Jul 23 15:32 config-5.10.0-16-amd64
-rw-r--r-- 1 root root 231K Aug 13 06:25 config-5.10.0-17-amd64
drwxr-xr-x 5 root root 1.0K Aug 31 13:13 grub/
-rw-r--r-- 1 root root  34M Aug 31 13:23 initrd.img-5.10.0-16-amd64
-rw-r--r-- 1 root root  34M Aug 31 13:23 initrd.img-5.10.0-17-amd64
drwx------ 2 root root  12K Oct 31  2015 lost+found/
-rw-r--r-- 1 root root   83 Jul 23 15:32 System.map-5.10.0-16-amd64
-rw-r--r-- 1 root root   83 Aug 13 06:25 System.map-5.10.0-17-amd64
-rw-r--r-- 1 root root 6.6M Jul 23 15:32 vmlinuz-5.10.0-16-amd64
-rw-r--r-- 1 root root 6.7M Aug 13 06:25 vmlinuz-5.10.0-17-amd64

/dev/sda1                         ext2  234M   93M  130M  42% /boot

So if I install new hardware will it be recognized by the new dracut-pared kernel? I wasn't able to tell for sure from the Wikipedia page though it seems like I might be able to recognize new hardware. "Dracut's initramfs depends on the Linux device manager (udev) to create symbolic links to device nodes."

p.H., yes, seriously, I rebooted without sorting out the initrd stuff because in every single previous case when I got the "Errors were encountered while processing: initramfs-tools" message I successfully booted in to the new kernel & was able to then remove the old kernel. I figured in the worst case I would be able to boot into the old focal kernel, and was surprised I wasn't able to do so.

Speaking of Ubuntu's tendency to accumulate kernels a weird thing is that when I manually remove an old kernel the default behavior is to then install the unsigned version of the same kernel, which kind of defeats the purpose.

Code: Select all

apt-get purge linux-image-5.13.0-51-generic 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  linux-image-unsigned-5.13.0-51-generic
Suggested packages:
  fdutils linux-doc | linux-hwe-5.13-source-5.13.0 linux-hwe-5.13-tools linux-modules-extra-5.13.0-51-generic
The following packages will be REMOVED:
  linux-image-5.13.0-51-generic* linux-modules-extra-5.13.0-51-generic*
The following NEW packages will be installed:
  linux-image-unsigned-5.13.0-51-generic
0 upgraded, 1 newly installed, 2 to remove and 1 not upgraded.
Need to get 10.1 MB of archives.
After this operation, 296 MB disk space will be freed.
Do you want to continue? [Y/n] 

I did a quick search to change this behavior but didn't immediately see anything, but it isn't hard to 'Ctrl+C" the action and add the unsigned version to the remove command.

BTW, I was able to use a USB drive as the /boot partition on my bedroom TV computer, I did install grub both to the SSD & the USB drive, but I didn't configure the BIOS on the first box I tried to use a USB /boot partition on to boot by default from the USB drive, if I recall correctly, maybe I would have been able to do that and it would have worked. In any case, now that I have been introduced to dracut that shouldn't be necessary.

p.H., I tried to manually partition a LUKS encrypted system with the current bullseye installer, but I wasn't able to figure it out, I was able to make a big /boot ext2 partition and then make a LUKS encrypted main partition, but the installer wouldn't let me open that partition and continue the install. Maybe I could have opened a TTY and did the necessary steps by hand, but I just got frustrated and looked around for an alternative installer and ran into Spirallinux.

Edit: my system rebooted normally after dracut and a USB wifi dongle that I didn't have plugged in when I ran dracut (and as I recall I had to compile stuff to get to work) was still recognized, allaying my fears that the slimmed down boot image would not recognize strange hardware.

[Praxis]

Well, not all is perfectly well in Muddville, when I did a poweroff I was dropped into a dracut debug shell. It pointed me to a log file in /run/initramfs, I believe. I tried to copy it somewhere but my keyboard was not responsive, and I couldn't get to a TTY. Upon rebooting (normally) I couldn't find the file. I guess this is a minor annoyance (so far), I'll pay more attention to the message in subsequent shutdowns & try to troubleshoot it. I didn't immediately see anything in dmesg and have to get ready to go somewhere, so I guess I'll just keep my eye on the issue.

[p.H]

On this install I can fit two kernels, but not three.

77 MiB per initramfs is bigger than mine (54 MiB). Maybe it includes more firmware.
Your /boot filesystem has 57 MiB free space (234 - 177; 44 MiB accounts for the 5% reserved to root) but each kernel+initramfs requires ~84 MiB. 3 kernels would require 252 MiB plus ~15 MiB for GRUB, more that the partition size. Also, upgrading an existing kernel or updating an existing initramfs temporarily requires some free space.

So if I install new hardware will it be recognized by the new dracut-pared kernel?

Why would the initramfs need to recognize new hardware ? The main purpose of the initramfs is to mount the root filesystem, so it mostly includes drivers and software for storage and ethernet (for network boot). A generic initramfs is useful if you intend to change the root device.

Speaking of Ubuntu's tendency to accumulate kernels a weird thing is that when I manually remove an old kernel the default behavior is to then install the unsigned version of the same kernel

Maybe there is some other package installed which depends on either the signed or unsigned kerne-imagel package. Check the kernel-image package reverse dependencies.

Code: Select all

apt-cache --installed rdepends llinux-image-5.13.0-51-generic

I tried to manually partition a LUKS encrypted system with the current bullseye installer, but I wasn't able to figure it out, I was able to make a big /boot ext2 partition and then make a LUKS encrypted main partition, but the installer wouldn't let me open that partition and continue the install

What do you mean by "open the partition" ?
You need to:
- create a partition and use it as an encrypted physical volume
- enter the encrypted volume management submenu and create an encrypted volume on the partition
- select the encrypted volume (/dev/mapper/XXX_crypt) and use it as an LVM physical volume
- enter the logical volume management submenu and create a volume group on the encrypted volume and logical volumes in the volume group
- select each logical volume and use is as intended (/, swap, /home...)

I was dropped into a dracut debug shell. It pointed me to a log file in /run/initramfs, I believe. I tried to copy it somewhere but my keyboard was not responsive, and I couldn't get to a TTY. Upon rebooting (normally) I couldn't find the file.

I do not know dracut and won't be able to help much about it.
Maybe the needed modules for the keyboard (PS/2, USB ?) were not included in the initramfs or automatically loaded ?
Other ttys are usually not enabled in the initramfs.
/run is a temporary filesystem (tmpfs) which does not survive after reboot.

[Praxis]

It is certainly likely I have extra firmware installed that I don't need. I don't know what specific drivers I'll need or might need so I install the free and non-free firmware metapackages, I'm on my *buntu laptop, so I can't check the exact names. But on this box I have installed linux-firmware, amd64-microcode, intel-microcode, & firmware-sof-signed.

I tried the command:

Code: Select all

 apt-cache --installed rdepends  linux-image-5.15.0-43-generic

linux-image-5.15.0-43-generic
Reverse Depends:
 |linux-modules-extra-5.15.0-43-generic
 |linux-modules-5.15.0-43-generic

I don't recall having requested the linux-modules-extra package and there doesn't seem to be a metapackage of that name installed, but trying to remove the modules-extra as well as the linux-image packages got the same behavior.

Code: Select all

apt remove linux-image-5.15.0-43-generic  linux-modules-extra-5.15.0-43-generic 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  linux-image-unsigned-5.15.0-43-generic
Suggested packages:
  fdutils linux-doc | linux-source-5.15.0 linux-tools linux-modules-extra-5.15.0-43-generic
The following packages will be REMOVED:
  linux-image-5.15.0-43-generic* linux-modules-extra-5.15.0-43-generic*
The following NEW packages will be installed:
  linux-image-unsigned-5.15.0-43-generic
0 upgraded, 1 newly installed, 2 to remove and 5 not upgraded.
Need to get 11.2 MB of archives.
After this operation, 337 MB disk space will be freed.

So I decided to remove the firmware-sof-signed, since it said signed and I don't remember installing it. That changed the behavior of the *buntu image package.

Code: Select all

apt remove firmware-sof-signed 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-headers-5.15.0-43 linux-headers-5.15.0-43-generic linux-image-5.15.0-43-generic
  linux-modules-5.15.0-43-generic linux-modules-extra-5.15.0-43-generic
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  firmware-sof-signed
0 upgraded, 0 newly installed, 1 to remove and 5 not upgraded.
After this operation, 13.6 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 429140 files and directories currently installed.)
Removing firmware-sof-signed (2.0-1ubuntu3) ...

Suddenly *buntu was showing the oldest of the 3 kernels I have installed as auto-removable and when I removed that kernel apt didn't suggest that it was going to install the unsigned version at the same time. So that seems to be one mystery solved.

As to my confusion trying to install luks-encrypted LVM manually from the installer, I'd have to go through the steps again with the installer, but don't have time for that exercise at the moment. Maybe in a week or two I'll try and document my experience. I've been using Debian for 15 years, & I couldn't figure out how to do a manual luks LVM installation from the installer, maybe I could make a little tutorial for the confused for people in my situation if I can figure it out.

[p.H]

linux-image-5.15.0-43-generic
Reverse Depends:
|linux-modules-extra-5.15.0-43-generic
|linux-modules-5.15.0-43-generic

Now you can check the dependencies of these two packages.

So I decided to remove the firmware-sof-signed, since it said signed and I don't remember installing it. That changed the behavior of the *buntu image package.

This is weird because in Debian the package firmware-sof-signed has no dependency. Also I doubt it would have a dependency with a specific kernel version.

[hamishm]

I'm not sure why you post about Ubuntu packages here. Is your Debian system working with dracut now?

[Praxis]

I'm not sure why you post about Ubuntu packages here. Is your Debian system working with dracut now?

I posted about Ubuntu because though most of my machines are Debian, some are Ubuntu and the luks-encryption scheme was the same when I installed the operating systems 8 or 10 years ago, that is, they have the small 240 MB /boot partitions that I find so annoying. At least Ubuntu has changed its partition layout for its full-disk encryption to have a bigger /boot partition these days, I believe it is 1 GB. Debian testing was still at 500 MB the last time I checked.

Dracut does work to dramatically decrease the kernel size so I could in theory get a reasonable number of kernels in the tiny 240MB /boot partition. But it also prevents me from shutting down the computer either with 'poweroff' or from the GUI. It drops me to a debug shell, as I mentioned & I have to hold the power button for a couple of seconds to turn the box off. I've had the same experience on the 3 computers I've installed dracut on. It was kind of annoying when I thought I was powering off my machine over SSH and went to the attic the next day to see the computer was still spinning.

So I have uninstalled dracut, the 'not shutting down' behavior went away when dracut did.

I ordered a couple of 'flat' USB drives for about $7 each, on two of my boxen that worked as a /boot partition. I'm a little afraid that the flash drives will die on me and leave my system unbootable so I have a cron job that backs them up every time I boot up to a tar.gz file.

[Praxis]

It turned out Spirallinux had too many downsides to be an alternative to straight Debian. The slow boot was agonizing, never knowing if it was going to decrypt the hard drive or drop me into a grub shell for the better part of a minute, plus weird additions like grub-customizer and backport kernels (and at least on the earlier version I used, other little teething problems like not including the bluetooth packages by default).

I decided to try a fresh install when Debian 12 became stable just to see what the encrypted install situation was. It turns out there are currently two separate installers, a Calamares installed that comes with the newish official live images, and the traditional Debian installer. The Calamares installer gives you a similar encrypted LVM installation to the one you get with the Spirallinux Calamares installer, that is, no unencrypted /boot partition, but also a veeeeery long wait to see if you entered the decryption key correctly, and if you flubbed it, waiting even longer before dropping you to a grub shell. The normal installer from the non-live media like the netinst image gives you the traditional /boot partition but decrypts quickly and if you mistype the key it gives you a couple of other chances before it times out for a spell (it is much faster to just reboot with Ctl+Alt+Del to try again).

Anyway, I think my ancient, four-times upgraded jessie to bookworm installs still work quite well and feel about as good as the fresh bookworm install, but the 234 MB /boot partition just wasn't going to cut it. I could use a USB flash drive, but don't really trust them long-term. Some of my systems have secondary drives where I could carve out a reasonably future-proof unencrypted /boot partition. Drive space is cheap, I use ~2 GB. But this isn't always an option for laptops or some older systems that only have 2 SATA ports, one of which is occupied by an optical drive (which I almost never use anymore).

So for me the solution is to simply clone the old updated jessie-bookworm SSD on to a larger SSD using dd or dcfldd, and then even with the old msdos partition table I can create 2 new partitions, a ~2 GB /boot and an encrypted /home partition. Then I move my home directories to the new /home partition, use "cryptsetup luksAddKey /dev/sdx /root/decryption-keyfile" and edit my /etc/crypttab & /etc/fstab to automatically decrypt the new /home partition and mount the new /boot and /home partitions at boot. You can buy a new 240 GB SSD for about $12 or so in the US, which is about a third of what I paid for a 120 GB SSD when I first installed jessie on my older systems, and it isn't much more than what I'd pay for a decent USB flash drive. And I get a lot more storage space in the bargain.

[Aki]

@Praxis: Thank you for bringing the discussion up to date.