Error trying to resize encrypted partition

No probs, just be aware that in place luks resizing is much more prone to errors, as you have discovered, hence this thread.

1 Like

@unix_lover

Howto shrink a LUKS1/LUKS2 encrypted partition containing a ext4 filesystem
============================================================

  1. Boot into live environment

  2. Open your encrypted partition, e. g. /dev/sda7
    sudo cryptsetup luksOpen /dev/sda7 crypt

  3. Check ext4 filesystem for errors
    sudo e2fsck -f /dev/mapper/crypt

  4. (Temporarily) shrink ext4 filesystem to minimum size (recommended)
    sudo resize2fs -pM /dev/mapper/crypt
    .
    You could also resize to a specific size, e. g. 6GiB x1024x1024x1024=6442450944Byte /512=12582912 sectors (blocks)
    sudo resize2fs -p /dev/mapper/crypt 12582912s
    Just make sure to resize to a smaller size than in step 8.

  5. Check ext4 filesystem for errors
    sudo e2fsck -f /dev/mapper/crypt

  6. Take note of the luks container header size (in sectors)
    For 512 bit key length (e . g. for the default aes-xts-plain with 512 bit key) the LUKS1 header is 2 MiB. LUKS2 header is 4 MiB if created with cryptsetup < 2.1 or 16 MiB if created with cryptsetup ≥ 2.1.
    sudo cryptsetup status crypt | grep offset

  7. (Optional) Calculate the minimum luks volume size (in sectors)
    7.1 Get the newly shrunken ext4 filesystem size (in Bytes)
    sudo dumpe2fs -h /dev/mapper/crypt |& awk -F: '/Block count/{count=$2} /Block size/{size=$2} END{print count*size}'
    7.2 Divide the above bytes by 512 to calculate the occupied sectors; e. g. 804773888 Byte /512 = 1571824 sectors
    7.3 Add the luks header size from step 6. to 7.2; e. g. 1571824 + 32768 = 1604592 sectors [x512 /1024/1024/1024 =0.77GiB]
    .
    In this example, 1604592 sectors is the absolute minimum size you may choose to resize the luks volume to in the following steps!

  8. Resize luks container to e. g. 6GiB [x1024x1024x1024=6442450944Byte /512=12582912 sectors (blocks)]
    sudo cryptsetup --size 12582912 resize crypt

  9. Grow the temporarily shrunken ext4 filesystem to the maximum size the luks volume will now allow
    sudo resize2fs -p /dev/mapper/crypt
    and check
    sudo e2fsck -f /dev/mapper/crypt

  10. Close the luks volume
    sudo cryptsetup luksClose crypt

  11. Rewrite partition table
    Note: We’ll assume /dev/sda7 is partition number 7
    This step is potentially dangerous as we will delete your original luks partition and recreate it by writing new start and end sectors to the partition table. Please take care to use the correct values!
    .
    sudo parted /dev/sda
    (parted) unit s
    (parted) p
    (parted) rm 7
    .
    We’ll now recreate this partition with the old START sector shown when you entered p (for example 21532672) and a new end sector.
    .
    New END sector = ~START sector~ + ~ext4 filesystem size from step 8~ + ~luks header size from step 6~
    e. g. 34148352s = 21532672s + 12582912s + 32768s
    (parted) mkpart primary 21532672s 34148352s
    (parted) p
    (parted) quit

  12. Reboot!

4 Likes

It seems like I had to only run this command and then I could use gparted to resize the entire encrypted partition (after decrypting it) as I did have some errors on the partition. Thanks for your help and support :slight_smile:

Why were there errors on the drive if you happened to know? And also how is the OS still able to run fine then?

Or just create a new encryted partition and rsync your system / data into it.

This method is failsafe, basically a manual copy-on-write version of in place luks container resizing.

Almost idiot proof too. Almost.

Ok, if I do this on a separate drive, and then I end up deleting the encrypted partition and then creating a new partition to the size that I want to, how would I clone the partition back into the partition where I want / to sit, I can’t just copy and paste the folders and files as the OS fails to boot?

Okay, here is what I did to relocate 3 uefi systems recently, which were on single luks partitions. I use swap files not swap partitions.

Use gparted to create your new partition of the correct size. Lets assume new root partition is /dev/sdb1 going forward.

Luks encrypt your partition.

sudo cryptsetup -y -v --type luks1 luksFormat /dev/sdb1

NOTE :

Until recently grub didn’t support containers of type luks2, so I used to create luks1 containers for my root partitions. I think this has changed now and grub now supports luks2. You can remove --type luks1 if you wish.

Open luks container, create filesystem, which in my case is ext4.

sudo cryptsetup open /dev/sdb1 luksroot
mkfs.ext4 /dev/mapper/luksroot

Mount the new file system.

sudo mount /dev/mapper/luksroot /mnt

When using rsync to copy an entire system exclude these directories. Create file rs-exclude.txt containing.

/dev
/tmp
/sys
/proc

Use rsync to copy the contents of / to /mnt.

sudo rsync -av --exclude-from=rs-exclude.txt / /mnt

The rsync -a flag (ie archive) will preserve file permissions and attributes.

To make this new system chroot-able.

sudo mkdir /mnt/dev
sudo mkdir /mnt/proc
sudo mkdir /mnt/sys
sudo mkdir /mnt/tmp

Get the UUIDs for your new luks partition and file system.

lsblk -f

Edit /mnt/etc/crypttab and replace any old UUIDs with new UUIDs.
Edit /mnt/etc/fstab and replace any old UUIDs with new UUIDs.
Edit /mnt/default/grub and replace old UUIDs with new UUIDs.

Double check these, if they are incorrect your system won’t boot.

Now chroot into your new system.

sudo arch-chroot /mnt

Mount your efi partition from within chroot shell.

sudo mount /dev/sdXX /boot/efi

Re-install grub on new system from within chroot.

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS --recheck

Check your efi boot order.

efibootmgr

Re-order if necessary as EndeavourOS will now be first in boot order.

efibootmgr -o [XXXX,YYYY,ZZZZ]

You should also be able to do this from BIOS, but I don’t know your machine.

Regenerate initramfs images and update grub within chroot.

sudo mkinitcpio -P
sudo update-grub

Reboot.

Practice this in a VM first, multiple times, make any mistakes there.

I cannot stress this enough.

This is what I did before attemping this process on my actual system, which subsequently went smoothly as I followed a process I knew worked.

This process is also useful for cloning systems, migrating systems onto a different file system (ie ext4 → btrfs) without re-installing, moving systems onto different drives without re-installing, failsafe luks root paritition resizing … etc.

3 Likes