2

Once the /boot partition is half-full with a single kernel you can't upgrade,

Resizing is painful when the other partition is encrypted,

Solution: Move /boot to the encrypted partition.

Backstory: Linux Mint 17 upgraded to 20 won't allow the latest kernel to be installed; that was my dilemma. There's much written on resizing partitions—terror is induced for encrypted partitions! Fortunately there's an alternative.

Having rendered my system "unbootable," I decided to provide some guidance (my answer appears below), others will hopefully chim in.

1 Answer 1

1

Credit largely belongs to Guilhem Moulin, I merely simplify. Superuser will be required repeatedly and you may prefer to run command su for a root shell (alternatively, proceed commands with sudo where necessary).

Encrypted partition: /dev/sda5

Running fdisk -l lists partitions, e.g.,

Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 499711 497664 243M 83 Linux /dev/sda2 501758 500117503 499615746 238.2G 5 Extended /dev/sda5 501760 500117503 499615744 238.2G 83 Linux 

My encrypted partition is /dev/sda5, yours may vary (and you'll need to replace /dev/sda5 accordingly).

Prerequisite: LUKS1

Check you're using LUKS1 by checking command cryptsetup luksDump /dev/sda5 outputs

Version: 1 

For version 2, downgrade before proceeding (see the original article).

Prerequisite: GRUB2

Check you're using GRUB2 by checking command grub-install --version outputs version 2 or above.

Prerequisite: Keyboard layout

Check your passphrase remains the same when you switch to US keyboard layout. Consider changing your passphrase (for one that remains the same), or set your passphrase using a US layout (not recommended), or refer to the original article for a further workaround.

Moving /boot

Remount /boot as read-only to avoid data modification during the move:

mount -oremount,ro /boot 

Recursively copy to a temporary directory (on the encrypted partition):

cp -axT /boot /boot.tmp 

Unmount /boot and remove the (empty) directory:

umount /boot rmdir /boot 

Relocate the temporary directory:

mv -T /boot.tmp /boot 

Update /etc/fstab

Command cat /etc/fstab will output something akin to:

UUID=38e... /boot ext2 defaults 

You need to comment out that line (I favour vim).

Enable cryptomount in GRUB2

Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub, generate your GRUB configuration file,

 update-grub 

and install,

 grub-install /dev/sda 

Probably a good time to test

Now is probably a good time to test all is going well: Reboot. You should be prompted for your passphrase and (after a disturbing long delay) be dropped into a initramfs prompt. Enter the following command:

 cryptsetup luksOpen /dev/sda5 sda5_crypt 

replacing sda5_crypt with the first parameter output by cat /etc/crypttab (if you've gotten this far without having run that command, just use sda5_crypt, we can fix it later). Next issue command:

 exit 

Your system should now be booting, if it isn't, recovery should be relatively easy—boot from a Live USB and uncomment the line in /etc/fstab. (It's incredibly useful to have a Live USB available at all times.)

Boot performance degraded

GRUB isn't optimised for crypto-related CPU instructions—unlocking the encrypted partition will take considerable longer than it did before.

Optional: You can tweak for performance by sacrificing resistance against brute-force attacks. It's easier for PBKDF than Argon2—PBKDF slows brute-force attacks by requiring multiple iterations, whereas Argon2 slows attacks with a further variable, hence, tweaking PBKDF is easier. Check how many iterations are currently used with command cryptsetup luksDump /dev/sda5, e.g.,

 Key Slot 0: ENABLED Iterations: 1208036 

To improve performance by roughly a factor of two (simultaneously reducing brute-force resistance by half), we can reduce the number of iterations by just over half with command cryptsetup luksChangeKey --pbkdf-force-iterations 500000 /dev/sda5

 Enter passphrase to be changed: Enter new passphrase: Verify passphrase: 

Your existing passphrase can be reused. As far as I can tell, a new key is added: In addition to the above, command cryptsetup luksDump /dev/sda5 now outputs

 Key Slot 1: ENABLED Iterations: 500000 

PBKDF will try all key slots sequentially, to speed things up, run command cryptsetup luksOpen --test-passphrase --verbose /dev/sda5

 Enter passphrase for /dev/sda5: Key slot 1 unlocked. Command successful. 

With command cat /etc/crypttab you'll see something like

 sda5_crypt UUID=66f... none luks,discard 

add ,key-slot=1 on the end (changing 1 to match whatever you found above). If you tested all is well and used something other than that first parameter sda5_crypt, reboot and enter cryptsetup luksOpen /dev/sda5 sda5_crypt followed by exit, before the next step. Run command

 update-initramfs -u -k all 

to generate and update your initramfs image. (Strictly speaking -k all isn't required, assuming you're following these instructions because you have a single kernel.)

Update /etc/fstab

Command lsblk -o name,uuid outputs

 NAME UUID sda ├─sda1 38e... ├─sda2 └─sda5 66f... └─sda5_crypt B6U... ├─mint--vg-root 54f... └─mint--vg-swap_1 fe3... 

To make your system bootable, add the following line to /etc/fstab

 UUID=54f... / ext4 defaults 0 1 

run command update-grub followed by grub-install /dev/sda, and reboot.

Hopefully you'll now have a bootable system.

You'll need to enter your passphrase twice, which is unfortunate. Apparently there's a workaround (see the original article). I followed that entire article in one hit, ran into trouble, couldn't boot (prior to discovering cryptsetup luksOpen /dev/sda5 sda5_crypt). With the above instructions, I hope there's less chance of pain. Best of luck.

1
  • Answer of tremendous help, thanks Commented Oct 1, 2022 at 17:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.