Broke system after moving Encrypted partition


I wanted to increase my swap partition's size but ended up with an unbootable computer..
I was using encrypted btrfs.

From what I recall these were my exact steps:

  1. I opened kde partition manager and without thinking I shrunk my main partition by 3 GiB while on it.

2)There was now a new unallocated partition and so I attempted to increase the size of the swap partition but It would'nt let me, even with the free space now availiable..

  1. I realised I should of done this from a liveusb.. so I exited out and rebooted into one.
    It still would not allow me to increase the swap partition size, so I decided to give up and just revert my changes..

4)I clicked back onto my main partition and moved it to the right by that 3 GiB of unallocated space. Without thinking I hit apply before decrypting the partition...

  1. Immediately I realised my mistake and hit the cancel button. After a few secs of loading it said {waiting for operation to finish} and greyed out the cancel button.

6)4 hours later it completed with a message above the bar saying operation cancelled.... This must be wrong because kde partition manager no longer detects the filesystem and I cant boot into it.

I thought maybe just moving it
To the left by 3 GiB might work but decided to ask for help before i completely break everything(probably already have).
Luckily my most important stuff is backed up, but i would really like to try salvage this.

Not a solution to your current problem, but in case you need to resize mounted btrfs partitions again, this may be useful (except I don't know if there are extra steps to take with LUKS).
It worked for me though (without encryption).

If possible, post output of sudo parted -l /dev/DEVICE and/or sudo gdisk -l /dev/DEVICE (where DEVICE is your boot drive) from the live ISO so the experts have a picture of your partition table.
If you have a backup of /etc/fstab it may be useful too.

I think there is a small chance to salvage it, LUKS stores its encryption header at the beginning of the partition and hopefully those last 3GiB were not in use.


Hello thanks for the tip, I will indeed..
Some more Information:

When i try boot I get

error:no such cryptodisk found 
error: disk `cryptouuid/78e0a005c92f447eabb70ff35fd1240d` not found.

sudo parted -l /dev/sda:

Model: ATA WDC WD10EZEX-08W (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
1      2097kB  317MB   315MB   fat32              boot, esp
2      3753MB  991GB   987GB                root
3      991GB   1000GB  9449MB

Model: Unknown (unknown)
Disk /dev/zram0: 8291MB
Sector size (logical/physical): 4096B/4096B
Partition Table: loop
Disk Flags:

Number  Start  End     Size    File system     Flags
1      0.00B  8291MB  8291MB  linux-swap(v1)

sudo gdisk -l /dev/sda

GPT fdisk (gdisk) version 1.0.9

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Model: WDC WD10EZEX-08W
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 732F526F-1D33-244D-8D4C-27ED0A8696B7
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 6718453 sectors (3.2 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
1            4096          618495   300.0 MiB   EF00
2         7329792      1935065087   919.2 GiB   8300  root
3      1935065127      1953520064   8.8 GiB     8300

It is possible to remove encryption (decrypt) from the live environment: Removing system encryption - ArchWiki

It does not look simple and there are many grave warnings regarding data loss, so beware: here be dragons.

If you are able to remove the encryption, mounting/moving/resizing the disk will all become possible again.

1 Like

Meanwhile, I found these two posts:

partitioning - How to resize a LUKS partition by moving its start? - Ask Ubuntu
Assuming it's correct, it indicates your partition may well be recoverable after all, and that having moved it without decrypting first should not be a problem.
But, it has also been resized, the btrfs filesystem in it still thinks those 3GiB are there, and if I understand correctly those were overwritten in step 4.

grub2 - Recover deleted LUKS partition - Unix & Linux Stack Exchange
This is about a case where the partition table was deleted, but the part about mounting it on loopback may turn useful. In your case, I'd avoid searching the header and mounting with disk+offset since the partition table is still there, rather mount the LUKS partition directly.
This should confirm if the partition is in fact still readable.
Note the -r flag to losetup for "read-only".

Whether the filesystem can be directly shrinked to fit the resized partition, or the partition would have to be grown back by those 3GiB first, I don't know.

Once the filesystem is back in shape (if ever), the system may still be unbootable, because the partition UUID may have changed when moving it. /etc/fstab would have to be updated with the new UUID.

Disclaimer: in case the profusion of conditionals didn't make it clear, I don't really know, I'm just taking an educated guess. I advise to do your own research, as one more false step will likely wreck it for good.

Changed the topic title slightly. The term Bricked relates to hardware only and should only be used by seasoned pros.