Error trying to resize encrypted partition

Should I run sudo pacman -Syyu to update the entire OS, like do you mean I should update the entire OS in live mode?

You should only do that if you encounter any problems that did not happen in your current install ( an up to date system ) .

1 Like

Shrinking is a bit more complicated than growing.
Unfortunately I can’t help you with getting it done in Gparted. If you tried this and Gparted throws errors, well … (?)

I could however help you do this via cli.

But be warned, manipulating the partition table is always risky! Make sure you have backups of everything important on the whole sda drive. You could lose all other partitions on that drive. I will only help if you specifically assure me you have understood and are good with this :wink: .

You’ll basically have to do the following:

|          filesystem: EXT4                       |  (2)
|          LUKS partition: /dev/sda7              |  (1)

Steps to SHRINK the physical partition sda7 (1):

  1. shrink the ext4 filesystem (2) to minimal size
  2. resize (shrink) the LUKS container (1) to the size you desire
  3. grow the ext4 filesystem (2) to the new maximum size
  4. shrink the (crypt) physical partition /dev/sda7 (1)
  5. change partition table to reflect start and new end of (1)

Have you tried shrinking the EXT4 filesystem before shrinking the luks container?

Thanks mate.

Yes I am good with this :slight_smile:

I am a bit confused with this step, Do you mean /dev/sda7 as /dev/sda2 is my EFI boot partition as shown in this image.

Also I am a but confused between (crypt) physical partition and LUKS container. So the LUKS container is inside the (crypt) physical parition and the ext4 partition is inside the LUKS container?

May I know the commands for how to do this please?

Well through gparted after opening the LUKS partition, it shows that same partition as ext4 so I did try to resize it but then I get that error message.

This is the encrypted partition.

Sorry, yes I meant sda7!

Then it’s probably best to try doing it manually. I’ll have to get back to work in about half an hour though and would therefore like to postpone helping you out with some commands - don’t want to rush into some errors.
How time-critical is this resizing issue? Could we get back to it on Friday?



Yeah that sounds like a good idea. Hopefully it works.

THanks mate :slight_smile: I am doing this on a VM before I do this on actual hardware so it doesn’t really matter if it screws up.

Its not critical at all, its not something that I need to do now.

Yeah sure, take your time :slight_smile:, Thanks for your help mate :slight_smile: Enjoy your work if you can.

1 Like

Enjoy? Nah, it’s “work” :wink: .

Thanks, I’ll get back to you on Friday then …


Ah yeah I can understand how work can be stressful,

Thanks :slight_smile:

This is a bad idea.

Enbiggening a luks partition, and file system contained within, is risky and very prone to error.

Best way to resize a luks partition is to create a new partition of the correct size, luks encrypt it, create the file system, rsync your system / data into, then make any required config changes to allow it to boot.

You’ll need to edit crypttab, fstab, grub to use the UUIDs of your new luks partition and file system. You’ll also have to install grub again and manage your efi boot order.

Once it all works blow away the original partition.

I did this recently, relocated a bunch of my fully encrypted systems to a different SSD, using gparted, rsync and a text editor.

Much quicker, easier and reliable than reinstalling, only took about 90 mins for 3 systems. Most of that was ryncing and rebooting.

Good way to clone your system or even migrate your system onto a different file system (ie ext4 -> btfrs).

Let me know if you want any help at all.


Growing is actually much easier than shrinking.

Theoretically risky, yes … but I’ve never encountered an unrecoverable error in over a decade of resizing encrypted partitions.

If you have backups of important data, as you should, it’s so much faster resizing than recreating.

1 Like

That is why @2000 said to back up the data.

But what if I don’t have enough space on my drive (which is actually the case)? How would I be able to create a new partition then?

Copy to an external drive and replace your luks partition.

1 Like

AH I see

Not trying to sound rude or anything but I’d probably want to use @2000 method instead as that sounds more convenient, all though for the time being I will use your method, but as you and @2000 have suggested, I am going to make backups before proceeding, thanks anyways :slight_smile:

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


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!


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


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.


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.


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


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.