Resize EFI on an older installation (or skip fallback kernel creation?)

Long story short. I have an installation may be more than a year old with only 300M EFI as first partition and the rest of the 1 TB disk as the encrypted LUKS partition.

It was a GRUB install and I switched to systemd boot. Works great, but as I’d like to have the LTS kernel along with the latest current kernel I often run out of space when dracut rebuilds kernels. Not much missing, but enough not to create one of the kernels.

What is the correct order with wich tools to resize encrypted root to 1G smaller, move it to the end and make EFI bigger to be 1GB?

I used to do it with a live GParted Linux, but I suppose the LUKS partition s inside a LVM container… And that’s where I’m lost…

Is there a how to out there fitting EOS installs?

Backup

  1. Backup
  2. Any partition manager you feel comfortable with.

however thats where i have to leave it as I no nothing about LUKS so not sure how that would work.

Backup - sure :wink:

I remeber that partition sizes might be wrong inside a LVM volume when using a partition manager. But my info might be outdated. So was looking for a LVM expert.

Yeah sorry don’t use encryption.

Hm, may be things are easier…

sudo pvdisplay /dev/mapper/luks-a9da828d-...
  Failed to find physical volume "/dev/mapper/luks-...".

So no LVM in place, just an ordinary partition that GParted can handle?

But from Arch wiki

Partition alignment

Aligning partitions correctly avoids excessive read-modify-write cycles. A typical practice for personal computers is to have each partition’s start and size aligned to 1 MiB (1 048 576 bytes) marks. This covers all common page and block size scenarios, as it is divisible by all commonly used sizes—1 MiB, 512 KiB, 128 KiB, 4 KiB, and 512 B.

Warning: Misaligned partitions will prevent being able to use 4096 byte sectors with dm-crypt/LUKS. See [8].

If I were you, I would just ignore that 300 MB esp partition at the beginning of the disk and create a new one at the end of it.

You won’t be needing to move that whole 1 TB partition, with surely lots of data on to the right, a time consuming and prone to errors process. You would just need to shrink it 1 GB, after you have decrypted it. Gparted should have an option (right-click on the partition > decrypt ?).

Then you can chroot into the system and set up systemd-boot anew, making changes to fstab etc.

1 Like

Just found a description confirming that it is not taht difficult

https://www.mattduck.com/2021-11-linux-backups - Step 2)
Decrypting/opening the partition before opeing gparted makes gparted aware of content and “should” work…

Thanks pebcak for the hint.

Just another thought to save some space in EFI…

For reasons if sth. breaks during a regular update: Is it better to have a fallback kernel image or a completely different kernel

currently I have
6.6 LTS
6.6 LTS-fallback
6.7
6.7 fallback

So better keep both 6.6 or tell dracut with NO_DRACUT_FALLBACK="true" to skip fallback kernel creation and have the regular 6.6 and 6.7

So I can save a lot of space and time - no need to repartition… I could even have a ZEN Kernel to play around :wink:

What do you think?