**NOTE** January 2022 - Changes to Gstreamer and Pipewire packages from PackmanPlease read the following thread about the current changes
-
 Encrypted ext4 partition corrupted. Recovery possible?
Hi!
It seems like i'm in a bit of a trouble here, maybe somebody can help me..
Running an openSUSE 12.3 x86_64 (Linux 3.7.10-1.28-desktop) with KDE 4.10.5 rel. 1,
i usually use the Partitioner in Yast2 to encrypt partitions (from what i now read that wasn't
a smart move at all...).
So yesterday i wanted to encrypt a partition (ext4), it's the only partition on a 1TB disk,
after unmounting the partition i started the partitioner, set the password for the partition
and clicked on 'Finish'. It came up with an error message and an error code (which i can't
remember, it was something like -3044) and i could either continue anyway or abort the
process, so i aborted it. But now i can't mount the partition anymore, the Yast2 Partioner
throws out error -3003 (unknown filesystem type '(null)'). So i tried fdisk -l /dev/sdc :
Code:
Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 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
Disk identifier: 0x000a19ef
Device Boot Start End Blocks Id System
/dev/sdc1 2048 1953523711 976760832 0 Empty
I don't understand the 'Empty' tag but at least it looks like the partition is still 'there'.
cryptsetup -v luksDump /dev/sdc1 gave me this:
Code:
LUKS header information for /dev/sdc1
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: b7 37 27 3a 03 ec bc a5 62 74 37 88 81 53 78 cd ca 6c 09 44
MK salt: d3 5f 80 a3 ff f7 ad 94 34 97 1e 94 52 e8 a3 c6
5c 8c 61 31 39 92 2f 73 04 8f ed 01 ab ec 60 25
MK iterations: 74250
UUID: bc1d3182-e655-4c6b-92dc-b9f1b3a74f21
Key Slot 0: ENABLED
Iterations: 297176
Salt: f2 7b 56 f4 8b 5a 69 f8 34 69 37 d0 6b 6b 20 af
0b 9a 9b f9 bf c4 68 3e 9f ed 0a 6a 80 7e 98 af
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Command successful.
This also doesn't look bad, i tried providing the key for the encrypted
partition, cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt
Code:
Enter passphrase for /dev/sdc1:
Key slot 0 unlocked.
Cannot use device /dev/sdc1 which is in use (already mapped or mounted).
Command failed with code 16: Cannot use device /dev/sdc1 which is in use (already mapped or mounted).
And here's where the trouble starts. I'm puzzled, it looks like the partition is fine and
i could decrypt the data on it but i can't mount it. I carefully poked around a bit to
gather more information. The partition was always mounted as 'sdc1' (which isn't accessible of course) and i
found the disk itself here '/dev/mapper/cr_ata-ST1000DM003-9YN162_S1D65LRJ-part1'.
tune2fs -l cr_ata-ST1000DM003-9YN162_S1D65LRJ-part1 gave me this:
Code:
tune2fs 1.42.6 (21-Sep-2012)
tune2fs: Bad magic number in super-block while trying to open cr_ata-ST1000DM003-9YN162_S1D65LRJ-part1
Couldn't find valid filesystem superblock.
stat cr_ata-ST1000DM003-9YN162_S1D65LRJ-part1 showed:
Code:
File: ‘cr_ata-ST1000DM003-9YN162_S1D65LRJ-part1’ -> ‘../dm-1’
Size: 7 Blocks: 0 IO Block: 4096 symbolic link
Device: 5h/5d Inode: 8606 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-03-01 01:39:02.634367804 +0000
Modify: 2014-03-01 01:39:02.633367804 +0000
Change: 2014-03-01 01:39:02.633367804 +0000
Birth: -
And fsck.ext4 -v /dev/sdc came up with:
Code:
e2fsck 1.42.6 (21-Sep-2012)
/dev/sdc is in use.
e2fsck: Cannot continue, aborting.
The same goes for 'sdc1'. But they're not mounted:
Code:
linux-twx7:~ # umount /dev/sdc
umount: /dev/sdc: not mounted
linux-twx7:~ # umount /dev/sdc1
umount: /dev/sdc1: not mounted
And finally this:
Code:
linux-twx7:~ # parted /dev/sdc p
Model: ATA ST1000DM003-9YN1 (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number Start End Size Type File system Flags
I'm lost, searching for hours for a solution now but i don't know how/if the
encryption is doing something weird or something i simply don't know of,
can somebody help me please?
Frank
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
On 2014-03-01 14:26, tic226 wrote:
> So i tried *fdisk -l /dev/sdc* :
....
> I don't understand the 'Empty' tag but at least it looks like the
> partition is still 'there'.
I think you can add that missing field yourself with fdisk, it should
not affect anything.
> *cryptsetup -v luksDump /dev/sdc1* gave me this:
....
> This also doesn't look bad, i tried providing the key for the encrypted
> partition, *cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt*
>
>
> Code:
> --------------------
>
> Enter passphrase for /dev/sdc1:
> Key slot 0 unlocked.
> Cannot use device /dev/sdc1 which is in use (already mapped or mounted).
> Command failed with code 16: Cannot use device /dev/sdc1 which is in use (already mapped or mounted).
>
> --------------------
Well, you should try here "dmsetup ls", because the device is already in
use with another name. Then you can probably disable it with "cryptsetup
remove WHATEVER", and then you can try again with the open sequence.
If the "dmsetup" command fails, try a listing of "/dev/mapper/" and
"/dev/dm*".
Sample:
Code:
> Telcontar:~ # dmsetup ls
> cr_cripta (253:0)
> Telcontar:~ # l /dev/mapper/
> total 0
> drwxr-xr-x 2 root root 80 Mar 1 12:14 ./
> drwxr-xr-x 20 root root 6320 Mar 1 12:38 ../
> crw------- 1 root root 10, 236 Mar 1 12:13 control
> lrwxrwxrwx 1 root root 7 Mar 1 12:14 cr_cripta -> ../dm-0
> Telcontar:~ #
--
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
Ok, so the partition was active as 'dm-1', i removed it and restarted the machine.
Then this:
Code:
linux-twx7:~ # cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt
Enter passphrase for /dev/sdc1:
Key slot 0 unlocked.
Command successful.
linux-twx7:~ # ls /dev/mapper
control cr_home sdc1_crypt
linux-twx7:~ # l /dev/mapper
total 0
drwxr-xr-x 2 root root 100 Mar 1 15:46 ./
drwxr-xr-x 20 root root 4520 Mar 1 15:48 ../
crw------- 1 root root 10, 236 Mar 1 14:33 control
lrwxrwxrwx 1 root root 7 Mar 1 15:40 cr_home -> ../dm-0
lrwxrwxrwx 1 root root 7 Mar 1 15:46 sdc1_crypt -> ../dm-1
Doesn't look bad, but the partition itself is still gone:
Code:
linux-twx7:~ # parted /dev/sdc p
Model: ATA ST1000DM003-9YN1 (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number Start End Size Type File system Flags
The encryption itself puzzles me. If the partition table/superblock
really is damaged, do i have to provide the encryption key before i can recover
anything? I supposed so but when i do that, the partition is used as 'dm-1' in
/dev/mapper , so this happens:
Code:
linux-twx7:~ # fsck.ext4 -v /dev/sdc
e2fsck 1.42.6 (21-Sep-2012)
/dev/sdc is in use.
e2fsck: Cannot continue, aborting.
So i removed it and tried again:
Code:
linux-twx7:~ # cryptsetup remove sdc1_crypt
linux-twx7:~ # l /dev/mapper
total 0
drwxr-xr-x 2 root root 80 Mar 1 15:59 ./
drwxr-xr-x 20 root root 4500 Mar 1 15:59 ../
crw------- 1 root root 10, 236 Mar 1 14:33 control
lrwxrwxrwx 1 root root 7 Mar 1 15:40 cr_home -> ../dm-0
linux-twx7:~ # fsck.ext4 -v /dev/sdc
e2fsck 1.42.6 (21-Sep-2012)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdc
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
And alternatively this:
Code:
linux-twx7:~ # cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt
Enter passphrase for /dev/sdc1:
Key slot 0 unlocked.
Command successful.
linux-twx7:~ # ls /dev/mapper
control cr_home sdc1_crypt
linux-twx7:~ # fsck.ext4 -v /dev/mapper/sdc1_crypt
e2fsck 1.42.6 (21-Sep-2012)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/mapper/sdc1_crypt
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
I read several times over the last hours that fsck.ext4 can actually handle
ext4, but when it reports the bad superblock it says ext2. I'm confused.
Any advice?
> So i tried *fdisk -l /dev/sdc* :
....
> I don't understand the 'Empty' tag but at least it looks like the
> partition is still 'there'.
I think you can add that missing field yourself with fdisk, it should
not affect anything.
I honestly have no idea what to put in there..
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
If there is corruption then perhaps it thinks it is ext2.
BTW it is better to use ext2 or 3 for sticks since ext4 is journeled and that adds read writes and can reduce the live of flash memory
Also note that the start end block definition of partitions are in the partition table and are stored on the first track. So you can have perfectly good start/end and no or bad data in the actual partition area
Note that any time you fool with partitions you should back up any data you want to keep.
If you have corruption on encrypted drives there is small chance of recovery.
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
On 2014-03-01 16:26, tic226 wrote:
> Doesn't look bad, but the partition itself is still gone:
>
>
> Code:
> --------------------
> linux-twx7:~ # parted /dev/sdc p
> Model: ATA ST1000DM003-9YN1 (scsi)
> Disk /dev/sdc: 1000GB
> Sector size (logical/physical): 512B/4096B
> Partition Table: msdos
>
> Number Start End Size Type File system Flags
>
>
> --------------------
I would prefer you used "fdisk", as the previous time.
> The encryption itself puzzles me. If the partition table/superblock
> really is damaged, do i have to provide the encryption key before i can
> recover anything?
No.
There is a disk.
The disk contains a partition table.
There is one or more partitions.
One of those partition contains an encrypted "something".
That something, when decrypted, turns out to be a filesystem.
That fylesystem can, at that point be mounted. Or not.
You do not need at all to activate decryption in order to work with the
partition table.
> I supposed so but when i do that, the partition is used as
> 'dm-1' in
> /dev/mapper , so this happens:
>
>
> Code:
> --------------------
>
> linux-twx7:~ # fsck.ext4 -v /dev/sdc
> e2fsck 1.42.6 (21-Sep-2012)
> /dev/sdc is in use.
> e2fsck: Cannot continue, aborting.
>
>
> --------------------
That will never work, in use or not.
Reasons:
sdc is the whole disk.
You normally run that on a single partition, not the whole disk.
But that will not work either, because it is encrypted.
> And alternatively this:
>
>
> Code:
> --------------------
> linux-twx7:~ # cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt
> Enter passphrase for /dev/sdc1:
> Key slot 0 unlocked.
> Command successful.
> linux-twx7:~ # ls /dev/mapper
> control cr_home sdc1_crypt
> linux-twx7:~ # fsck.ext4 -v /dev/mapper/sdc1_crypt
> e2fsck 1.42.6 (21-Sep-2012)
> ext2fs_open2: Bad magic number in super-block
> fsck.ext4: Superblock invalid, trying backup blocks...
> fsck.ext4: Bad magic number in super-block while trying to open /dev/mapper/sdc1_crypt
>
> The superblock could not be read or does not describe a correct ext2
> filesystem. If the device is valid and it really contains an ext2
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt, and you might try running e2fsck with an alternate superblock:
> e2fsck -b 8193 <device>
>
>
> --------------------
This should work, provided that the filesystem was already created, and
that it is is an ext4/3/2
You said initially that the YaST partitioner failed, so it could be that
it failed at that step. So what you cold do at this step is like this:
Code:
> Telcontar:~ # file --special-files --dereference /dev/mapper/cr_cripta
> /dev/mapper/cr_cripta: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
> Telcontar:~ #
> I read several times over the last hours that fsck.ext4 can actually
> handle ext4, but when it reports the bad superblock it says ext2. I'm confused.
No, that doesn't matter.
>> I think you can add that missing field yourself with fdisk, it should
>> not affect anything.
>
> I honestly have no idea what to put in there..
t change a partition's system id
Command (m for help): t
Partition number (1-12, default 12): 1
83
then "w" to write it and exit. "l" gives you the available types. Linux
partitions are all of them numbered "83".
--
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
 Originally Posted by tic226
Ok, so the partition was active as 'dm-1', i removed it and restarted the machine.
Then this:
Code:
linux-twx7:~ # cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt
Enter passphrase for /dev/sdc1:
Key slot 0 unlocked.
Command successful.
linux-twx7:~ # ls /dev/mapper
control cr_home sdc1_crypt
linux-twx7:~ # l /dev/mapper
total 0
drwxr-xr-x 2 root root 100 Mar 1 15:46 ./
drwxr-xr-x 20 root root 4520 Mar 1 15:48 ../
crw------- 1 root root 10, 236 Mar 1 14:33 control
lrwxrwxrwx 1 root root 7 Mar 1 15:40 cr_home -> ../dm-0
lrwxrwxrwx 1 root root 7 Mar 1 15:46 sdc1_crypt -> ../dm-1
So far, so good.
Since Yast failed, you should assume that the file system was not properly formatted. At this stage (after unlocking), try:
Code:
# mkfs -t ext4 /dev/mapper/sdc1_crypt
and see what happens.
You will lose existing data. However, if I am understanding you correctly, there isn't any existing data because this has never worked on this partition.
If "mkfs" gives an error, you will at least know what Yast was complaining about. If it goes through fine, then maybe the file system will now be usable.
openSUSE Leap 15.4 Beta; KDE Plasma 5.24.4;
testing Tumbleweed.
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
Thank you for your help and advice guys, yesterday i just shut down the machine and went
to bed, that way i couldn't at least do any further damage to the disk...
So after reading your replies this morning i first set the right ID for the partition with fdisk,
as robin_listas suggested:
>> I think you can add that missing field yourself with fdisk, it should
>> not affect anything.
>
> I honestly have no idea what to put in there..
t change a partition's system id
Command (m for help): t
Partition number (1-12, default 12): 1
83
then "w" to write it and exit. "l" gives you the available types. Linux
partitions are all of them numbered "83".
I checked and it looks better now:
Code:
linux-twx7:~ # fdisk -l /dev/sdc
Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
58 heads, 56 sectors/track, 601454 cylinders, total 1953525168 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
Disk identifier: 0x000a19ef
Device Boot Start End Blocks Id System
/dev/sdc1 2048 1953523711 976760832 83 Linux
Looking for any LUKS data on the partition showed this:
Code:
linux-twx7:/home/tic226 # cryptsetup -v luksDump /dev/sdc1
LUKS header information for /dev/sdc1
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: b7 37 27 3a 03 ec bc a5 62 74 37 88 81 53 78 cd ca 6c 09 44
MK salt: d3 5f 80 a3 ff f7 ad 94 34 97 1e 94 52 e8 a3 c6
5c 8c 61 31 39 92 2f 73 04 8f ed 01 ab ec 60 25
MK iterations: 74250
UUID: bc1d3182-e655-4c6b-92dc-b9f1b3a74f21
Key Slot 0: ENABLED
Iterations: 297176
Salt: f2 7b 56 f4 8b 5a 69 f8 34 69 37 d0 6b 6b 20 af
0b 9a 9b f9 bf c4 68 3e 9f ed 0a 6a 80 7e 98 af
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Command successful.
This looks like before but i guess it doesn't tell me anything about the
health of the partition data itself. fsck now throws up this:
Code:
linux-twx7:~ # fsck.ext4 -v /dev/sdc1
e2fsck 1.42.6 (21-Sep-2012)
EEPROM07n contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #1 (32768, counted=0).
Fix<y>? yes
Free blocks count wrong for group #2 (32768, counted=0).
Fix<y>? yes
Free blocks count wrong for group #3 (32768, counted=0).
Fix<y>?
I guessed i don't have much left to lose to i ended fsck here and
started it again with -y :
fsck.ext4 -v -y /dev/sdc1 resulted in
Code:
.
.
EEPROM07n: ***** FILE SYSTEM WAS MODIFIED *****
98632 inodes used (0.16%, out of 61054976)
2180 non-contiguous files (2.2%)
58 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 98086/429/18
151907680 blocks used (62.21%, out of 244190208)
0 bad blocks
39 large files
86088 regular files
12441 directories
0 character device files
0 block device files
0 fifos
24 links
94 symbolic links (90 fast symbolic links)
0 sockets
------------
98647 files
I rechecked
Code:
linux-twx7:~ # fsck.ext4 -v /dev/sdc1
e2fsck 1.42.6 (21-Sep-2012)
EEPROM07n: clean, 98632/61054976 files, 151907680/244190208 blocks
This looks pretty good, i guess...
But when i tried to provide the key like i did before, this happened:
Code:
linux-twx7:/home/tic226 # # cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt1
linux-twx7:/home/tic226 #
Just nothing. I checked a few things like before:
Code:
linux-twx7:/home/tic226 # cryptsetup -v luksDump /dev/sdc1
LUKS header information for /dev/sdc1
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: b7 37 27 3a 03 ec bc a5 62 74 37 88 81 53 78 cd ca 6c 09 44
MK salt: d3 5f 80 a3 ff f7 ad 94 34 97 1e 94 52 e8 a3 c6
5c 8c 61 31 39 92 2f 73 04 8f ed 01 ab ec 60 25
MK iterations: 74250
UUID: bc1d3182-e655-4c6b-92dc-b9f1b3a74f21
Key Slot 0: ENABLED
Iterations: 297176
Salt: f2 7b 56 f4 8b 5a 69 f8 34 69 37 d0 6b 6b 20 af
0b 9a 9b f9 bf c4 68 3e 9f ed 0a 6a 80 7e 98 af
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Command successful.
Code:
linux-twx7:~ # dmsetup ls
cr_home (253:0)
Code:
linux-twx7:~ # l /dev/mapper
total 0
drwxr-xr-x 2 root root 80 Mar 2 09:19 ./
drwxr-xr-x 19 root root 4480 Mar 2 09:19 ../
crw------- 1 root root 10, 236 Mar 2 09:16 control
lrwxrwxrwx 1 root root 7 Mar 2 09:16 cr_home -> ../dm-0
I ultimately tried mouting it directly, with no success of course:
Code:
linux-twx7:~ # mount /dev/sdc1 /crypt
NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted.
Password:
crypt_activate_by_passphrase: Operation not permitted
Am i missing something here? Have i now ultimately screwed up my data?
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
Originally Posted by nrickert
So far, so good.
Since Yast failed, you should assume that the file system was not properly formatted. At this stage (after unlocking), try:
Code:
# mkfs -t ext4 /dev/mapper/sdc1_crypt
and see what happens.
You will lose existing data. However, if I am understanding you correctly, there isn't any existing data because this has never worked on this partition.
If "mkfs" gives an error, you will at least know what Yast was complaining about. If it goes through fine, then maybe the file system will now be usable.
Yes, i was thinking about using mkfs as well, unfortunately there is data on the partition i'm trying to recover. So that would be one of the last options 
Originally Posted by gogalthorp
If there is corruption then perhaps it thinks it is ext2.
BTW it is better to use ext2 or 3 for sticks since ext4 is journeled and that adds read writes and can reduce the live of flash memory
Also note that the start end block definition of partitions are in the partition table and are stored on the first track. So you can have perfectly good start/end and no or bad data in the actual partition area
Note that any time you fool with partitions you should back up any data you want to keep.
If you have corruption on encrypted drives there is small chance of recovery.
Thanks for your advice, in this case it's a harddrive with ext4. Backups are really important, i thought i learned that when i messed up a harddrive
fot the first time and didn't have any. But there is still data on my partition which i would have to get back from various sources
(games and add-ons, music, etc.), it appears i never really learned the lesson and back up the whole 600GB, no i was too cheap
for that and stored just documents, photos, etc. on a 320GB backup disk. A cheap 60quid 1TB (USB) disk would have saved me
the trouble here. I ordered one this morning, hoping i learned the lesson this time...
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
Originally Posted by tic226
...
Ah snap, i made a mistake when i tried to open the LUKS container, while
copy/pasting between browser and konsole i oversaw it:
Code:
linux-twx7:/home/tic226 # # cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt1
linux-twx7:/home/tic226 #
So i tried again, this time without the typo
Code:
linux-twx7:~ # cryptsetup -v luksOpen /dev/sdc1 sdc1_crypt1
Enter passphrase for /dev/sdc1:
No key available with this passphrase.
Enter passphrase for /dev/sdc1:
No key available with this passphrase.
Enter passphrase for /dev/sdc1:
No key available with this passphrase.
Command failed with code 1: No key available with this passphrase.
I know the key... this doesn't look good
Either i missing something or i have to try re-creating the key slot
with the luks header, it still looks ok:
Code:
linux-twx7:~ # cryptsetup -v luksDump /dev/sdc1
LUKS header information for /dev/sdc1
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: b7 37 27 3a 03 ec bc a5 62 74 37 88 81 53 78 cd ca 6c 09 44
MK salt: d3 5f 80 a3 ff f7 ad 94 34 97 1e 94 52 e8 a3 c6
5c 8c 61 31 39 92 2f 73 04 8f ed 01 ab ec 60 25
MK iterations: 74250
UUID: bc1d3182-e655-4c6b-92dc-b9f1b3a74f21
Key Slot 0: ENABLED
Iterations: 297176
Salt: f2 7b 56 f4 8b 5a 69 f8 34 69 37 d0 6b 6b 20 af
0b 9a 9b f9 bf c4 68 3e 9f ed 0a 6a 80 7e 98 af
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Command successful.
Any advice on that?
-
Re: Encrypted ext4 partition corrupted. Recovery possible?
I don't understand the 'Empty' tag but at least it looks like the partition is still 'there'.
The word Empty in the System column there is only a textual interpretation of the numeric partition type 0 that is shown before it in the ID column.
Thus when you change the 0 to something else, then fdisk will also show a different text so we humans can easier understand what the partition type is.
It is easy enough to change that numeric type through fdisk. The problem may be to know what should be the correct one. The most used in Linux partitioning are:
- 82 (Linux sap / Solaris), yes for Linux Swap;
- 83 (Linux), for all Linux native file systems;
- f (W95 Ext's (LBS), for the extended partition.
You can also find other types when you still have Windows partitions on your disk in a multi boot situation.
I do not know if there is a specific type used for Luks encrypted partitions or that it simply uses 83. When you have another Luks encrypted one, you can look there.
If that type is important (in other words if any program even looks at it) depends on the software. But most people (including me) tend to use those 82 and 83 (and a few others for e.g. LVM) correctly to avoid problems/confusion. A fact that is greatly supported by high level partitioners like YaST that use the correct types by default.
Just for your information. I do not know if it has anything to do with your problem, but I saw you asking about the Empty.
Henk van Velden
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
| 
