Hello,
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.
2 Likes
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.
4 Likes