Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

noobaroo · 2024-04-02 11:06:57

Hi, I'm unable to mount my LUKS encrypted partition after a failed resize operation on KDE's partition manager. The device has a lot of important data on it and I really hope I can get it back.
https://i.imgur.com/2lCugkJ.png

Output of lsblk -f: https://0x0.st/Xzxx.txt

Previously /dev/sda1 was the only partition, I shrunk it with KDE Partition Manager so I could create a swap partition.
Now I can't mount /dev/sda1.

I desperately need help. I'll be very thankful for any replies.

noobaroo · 2024-04-02 17:56:13

Update:

I deleted swap (/dev/sda2) and tried to expand the partition /dev/sda1 back in hopes that it would work again, as was the case for this fellow:
https://www.reddit.com/r/linuxquestions … partition/
https://www.reddit.com/r/kde/comments/1 … _my_drive/

Only thing I did differently was use KDE Partition Manager to do the job and not lvextend.
Now the entire drive won't read at all. I don't see anything in dmesg, although it's possible I missed something. lsblk shows nothing.
This problem seems to occur a lot with KDE Partition Manager. I can't tell if it's related to the encryption or not, but it's definitely correlated to KDE Partition Manager.

Please help.

xerxes_ · 2024-04-02 19:34:29

First umount swap partition and turn off automount of it in fstab, if you set it, so no new data is written on it and don't overwrite the old one.

Post output of command 'fdisk -l /dev/sda'.

Then think about remove partition sda2 and do undo of shrink partition sda1 but don't do it by KDE Partition Manager; use for example cfdisk, parted for it. Then enlarge lvm, your filesystem on it and see what display fdisk, lsblk, try to mount it but read only, don't write anything to it until it mount successfully and you check it you can read your files without error.

Last edited by xerxes_ (2024-04-02 19:35:14)

noobaroo · 2024-04-02 22:11:39

noobaroo wrote:

Update:
I deleted swap (/dev/sda2) and tried to expand the partition /dev/sda1 back in hopes that it would work again, as was the case for this fellow:
https://www.reddit.com/r/linuxquestions … partition/
https://www.reddit.com/r/kde/comments/1 … _my_drive/
Only thing I did differently was use KDE Partition Manager to do the job and not lvextend.
Now the entire drive won't read at all. I don't see anything in dmesg, although it's possible I missed something. lsblk shows nothing.
This problem seems to occur a lot with KDE Partition Manager. I can't tell if it's related to the encryption or not, but it's definitely correlated to KDE Partition Manager.
Please help.

Okay, so here's a complicated story:
After I attempted to delete /dev/sda2 and expand /dev/sda1 with kde partition manager, my OS would no longer boot after a restart. It was stuck on vendor logo of Bios screen. In my trying to get it to boot up, I switched SATA controller to Intel RST instead of AHCI and also disabled SATA controller completely.
I should have known what Intel RST would do, that's enough to cause a dysfunction, but I actually was panicking and made my previous post with SATA controller completely disabled.
I eventually fixed my OS boot process by putting in a Kubuntu Live USB and commenting out the swap entry in my fstab.

Now SATA controller is enabled, and back to problem of it showing up, and decrypts successfully (pretty sure) but refuses to mount.

xerxes_ wrote:

First umount swap partition and turn off automount of it in fstab, if you set it, so no new data is written on it and don't overwrite the old one.
Post output of command 'fdisk -l /dev/sda'.
Then think about remove partition sda2 and do undo of shrink partition sda1 but don't do it by KDE Partition Manager; use for example cfdisk, parted for it. Then enlarge lvm, your filesystem on it and see what display fdisk, lsblk, try to mount it but read only, don't write anything to it until it mount successfully and you check it you can read your files without error.

Here is the output of

fdisk -l /dev/sda
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20PURX-64P
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 74240778-D101-4EA5-99F3-5F2BFDBB2580

Device     Start        End    Sectors  Size Type
/dev/sda1   2048 3836147711 3836145664  1.8T Linux filesystem

https://0x0.st/Xz6t.txt

I thought I deleted /dev/sda2 and expanded /dev/sda1, but it appears that didn't go through.

Here is the output of of:

 sudo e2fsck -f /dev/mapper/luks-4e6501ca-0cde-4b49-b9fd-548490daec7a
e2fsck 1.47.0 (5-Feb-2023)
The filesystem size (according to the superblock) is 487865088 blocks
The physical size of the device is 479517696 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

https://0x0.st/Xz6x.txt

So you're sure I should delete /dev/sda2 and expand /dev/sda1 with cfdisk or parted? Should I do this with it decrypted or encrypted? I hope I can get this right.
Also, hopefully I got the formatting right on this post, I'm new.

xerxes_ · 2024-04-03 17:04:19

First post output of commands:

sudo file -s /dev/sda{,1,2}
fdisk -l /dev/sda
fdisk -l /dev/sda1
fdisk -l /dev/sda2

You can compare bytes and sectors between partitions.

Last edited by xerxes_ (2024-04-03 17:20:03)

seth · 2024-04-03 17:56:58

Do you have an image of the entire disk?
Don't flail around on your only copy, you're gonna hate yourself…

noobaroo · 2024-04-03 23:24:00

xerxes_ wrote:

First post output of commands:
sudo file -s /dev/sda{,1,2}
fdisk -l /dev/sda
fdisk -l /dev/sda1
fdisk -l /dev/sda2
You can compare bytes and sectors between partitions.

It looks like there is only /dev/sda1 and the rest is unallocated 33GB.

~ --> sudo file -s /dev/sda{,1,2}
[sudo] password for jokah:
/dev/sda:  DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 3907029167 sectors, extended partition table (last)
/dev/sda1: LUKS encrypted file, ver 1 [aes, xts-plain64, sha256] UUID: 4e6501ca-0cde-4b49-b9fd-548490daec7a, at 0x1000 data, 64 key bytes, MK digest 0xd74f5f536897f9b97498508172ceaac58cf14990, MK salt 0x04fb2476b21abbfc5972cd728b8728903ca9e9539a0caf0465572a744a828885, 293554 MK iterations; slot #0 active, 0x8 material offset
/dev/sda2: cannot open `/dev/sda2' (No such file or directory)
~ --> sudo fdisk -l /dev/sda
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20PURX-64P
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 74240778-D101-4EA5-99F3-5F2BFDBB2580

Device     Start        End    Sectors  Size Type
/dev/sda1   2048 3836147711 3836145664  1.8T Linux filesystem
~ --> sudo fdisk -l /dev/sda1
Disk /dev/sda1: 1.79 TiB, 1964106579968 bytes, 3836145664 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
~ --> sudo fdisk -l /dev/sda2
fdisk: cannot open /dev/sda2: No such file or directory

seth · 2024-04-04 07:31:02

Do you have an image of your disk?
You might have caused too much damage already…

Previously /dev/sda1 was the only partition, I shrunk it with KDE Partition Manager so I could create a swap partition.
Now I can't mount /dev/sda1.

I deleted swap (/dev/sda2) and tried to expand the partition /dev/sda1 back in hopes that it would work again, as was the case for this fellow:

I thought I deleted /dev/sda2 and expanded /dev/sda1, but it appears that didn't go through.

Now SATA controller is enabled, and back to problem of it showing up, and decrypts successfully (pretty sure) but refuses to mount.

After decrypting the partition, can you find files w/ testdisk?
https://wiki.archlinux.org/title/File_r … d_PhotoRec

DO NOT !!!! try to rescue files onto or otherwise WRITE ANYTHING ON /DEV/SDA!
We just want to know whether the driver is properly decrypted!

The filesystem size (according to the superblock) is 487865088 blocks
The physical size of the device is 479517696 blocks

(2000398934016-2048)/4096 = 488378645.5
This here smells *a lot* like the only problem is the partition size and growing sda1 back to its old size will fix everything but unless you're in an absolute hurry, DO NOT FLAIL AROUND ANYMORE!

Restoring the previous partition table w/ eg. cfdisk is "safe" (first close the luks container again)
You can then try to re-open LUKS and if that succeeds to mount the partition.
Iff however you're then prompted to run an fsck DO NOT RUN A DESTRUCTIVE FSCK ON THE DRIVE!
You can run an analysis to see how much is broken, but the very first thing you want to establish is that you're looking at your decrypted data!

The alternative explanation is that you changed the size of the LUKS container and the partition, but not the filesystem (probably because you tried this online, ie. w/ the partition mounted as root)
https://wiki.archlinux.org/title/Dm-cry … ile_system
In that case you'll just have to resize the filesystem but:

I'll repeat: you want to have an image of that disk and especially before writing to it anything.
Fucked up encrypted partitions are a dance on the fire.

noobaroo · 2024-04-05 13:08:16

seth wrote:

After decrypting the partition, can you find files w/ testdisk?
https://wiki.archlinux.org/title/File_r … d_PhotoRec
DO NOT !!!! try to rescue files onto or otherwise WRITE ANYTHING ON /DEV/SDA!
We just want to know whether the driver is properly decrypted!
The filesystem size (according to the superblock) is 487865088 blocks
The physical size of the device is 479517696 blocks
(2000398934016-2048)/4096 = 488378645.5
This here smells *a lot* like the only problem is the partition size and growing sda1 back to its old size will fix everything but unless you're in an absolute hurry, DO NOT FLAIL AROUND ANYMORE!
Restoring the previous partition table w/ eg. cfdisk is "safe" (first close the luks container again)
You can then try to re-open LUKS and if that succeeds to mount the partition.
Iff however you're then prompted to run an fsck DO NOT RUN A DESTRUCTIVE FSCK ON THE DRIVE!
You can run an analysis to see how much is broken, but the very first thing you want to establish is that you're looking at your decrypted data!
The alternative explanation is that you changed the size of the LUKS container and the partition, but not the filesystem (probably because you tried this online, ie. w/ the partition mounted as root)
https://wiki.archlinux.org/title/Dm-cry … ile_system
In that case you'll just have to resize the filesystem but:
I'll repeat: you want to have an image of that disk and especially before writing to it anything.
Fucked up encrypted partitions are a dance on the fire.

I don't have another blank drive that is bigger than it, to make an image onto. It's a 2TB drive and if there is a way to make an image of only the data, I can afford that (it's probably like 25-50% full and I have other 500GB drives. But if you mean for me to clone the entire drive, I don't have 2TB of free space anywhere. Maybe if there is a way to clone it in parts, like a split up rar file (.r01, .r02, .r03, etc) Even then I don't know if I have enough space.
Is there a way to clone it in parts, and do you mean the entire drive or just the actual data?

Yes, I did it online with the partition mounted as root. I blame KDE Partition Manager for allowing it. We can do lots of stuff nowadays, even hotplug RAM into/from a live system. I thought it was okay to resize as long as the GUI allowed me to.
About expanding the partition back with cfdisk, I'm pretty sure someone on IRC told me to only do that with the drive decrypted/unlocked. You're saying the opposite?
Not saying you're wrong, it could be the IRC guy was wrong, or maybe I'm just completely mistaken and either misunderstood his instructions or I'm misunderstanding your instructions, I really don't know, just trying to get clarification here.
Thanks for the help, I really appreciate it.

seth · 2024-04-05 13:42:23

The entire drive.

There're essentially two things that can have happened here:
1. You resized only the partition but not the luks container nor the filesystem inside
2. You resized the partition and the luks container, but not the partition inside.

The suggestion on IRC *might* have been to resize the FS (not the GPT partition) to the current luks container (when the container is unlocked, it's not possible otherwise) - that would be the correct action in the second case because the data outside the luks container has likely been lost anyway.

You could check the output of "cryptsetup status" for the device to see the size of the luks container, if it exceeds the partition size the container has probably not been resized and, depending on whether you've previously written to the designated swap partition, data that might have resided there *might* still be salvageable.
If it's not (and the filesystem error actually suggests that and that case 2 is what has happened) probably the only thing left to do is to resize the filesystem and hope that it didn't contain any important data (what at 25%-50% isn't even all that unlikely)

Again: don't flail around. One bad move on an encrypted partition and there's no chance to rescue any data.
(Which is why operating on an image w/ a backup ready is highly recommended)

noobaroo · 2024-04-06 04:41:05

seth wrote:

The entire drive.
There're essentially two things that can have happened here:
1. You resized only the partition but not the luks container nor the filesystem inside
2. You resized the partition and the luks container, but not the partition inside.
The suggestion on IRC *might* have been to resize the FS (not the GPT partition) to the current luks container (when the container is unlocked, it's not possible otherwise) - that would be the correct action in the second case because the data outside the luks container has likely been lost anyway.
You could check the output of "cryptsetup status" for the device to see the size of the luks container, if it exceeds the partition size the container has probably not been resized and, depending on whether you've previously written to the designated swap partition, data that might have resided there *might* still be salvageable.
If it's not (and the filesystem error actually suggests that and that case 2 is what has happened) probably the only thing left to do is to resize the filesystem and hope that it didn't contain any important data (what at 25%-50% isn't even all that unlikely)
Again: don't flail around. One bad move on an encrypted partition and there's no chance to rescue any data.
(Which is why operating on an image w/ a backup ready is highly recommended)

Thank you I resized the partition to expand it to the entire drive with LUKS decrypted, and now it works again. It did require a reboot before it would mount.
I feel extremely lucky right now. Although I supposed I was pretty unlucky that this happened in the first place.

seth · 2024-04-06 06:05:33

How exactly? c/fdisk or some GUI abstraction?
Did you check the cryptsetup status before?

If you resized it w/ only c/fdisk it should not matter whether the LUKS container was decrypted, otherwise you might have silently re-expanded the container and the end of the filesystem cotains random data instead of yours. This might not even be a problem because of its limited usage, but w/o understanding what has happened you also can't be sure about that.

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

noobaroo · 2024-04-12 00:04:45

I used cfdisk. Okay, I will mark this as solved. Hopefully others can find this and know that their disk is salveageable.
Thanks again

noobaroo · 2024-04-12 00:07:29

seth wrote:

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.

How do I do this?

V1del · 2024-04-12 01:09:32

you edit your first post in here -- potentially shorten the title a bit - and add [SOLVED]

seth · 2024-04-12 07:25:06

You also want to check the "cryptsetup status" to see whether the containerhas actually retained its full size through all of this.
In that case you originally only changed the partition table, what is completely transparent (you can do and undo that w/o any harm to the underlying partitions and filesystems as long as you're not writing around on them otherwise, eg. run mkfs on your fun-partition layout)

Arch Linux

#1 2024-04-02 11:06:57

Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#2 2024-04-02 17:56:13

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#3 2024-04-02 19:34:29

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#4 2024-04-02 22:11:39

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#5 2024-04-03 17:04:19

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#6 2024-04-03 17:56:58

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#7 2024-04-03 23:24:00

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#8 2024-04-04 07:31:02

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#9 2024-04-05 13:08:16

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#10 2024-04-05 13:42:23

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#11 2024-04-06 04:41:05

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#12 2024-04-06 06:05:33

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#13 2024-04-12 00:04:45

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#14 2024-04-12 00:07:29

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#15 2024-04-12 01:09:32

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

#16 2024-04-12 07:25:06

Re: Can't Mount HDD After Failed Resize Operation On KDE Partition Manager

Board footer