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:
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..
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...
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
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.
