Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Encrypted ext4 partition corrupted. Recovery possible?

  1. #1
    Join Date
    Apr 2011
    Location
    Banana
    Posts
    14

    Default 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

  2. #2
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default 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)

  3. #3
    Join Date
    Apr 2011
    Location
    Banana
    Posts
    14

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

  4. #4
    Join Date
    Nov 2009
    Location
    West Virginia Sector 13
    Posts
    15,650

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

  5. #5
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default 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)

  6. #6
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,364
    Blog Entries
    3

    Default Re: Encrypted ext4 partition corrupted. Recovery possible?

    Quote Originally Posted by tic226 View Post
    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.1; KDE Plasma 5;

  7. #7
    Join Date
    Apr 2011
    Location
    Banana
    Posts
    14

    Default 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?



  8. #8
    Join Date
    Apr 2011
    Location
    Banana
    Posts
    14

    Default Re: Encrypted ext4 partition corrupted. Recovery possible?

    Quote Originally Posted by nrickert View Post
    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


    Quote Originally Posted by gogalthorp View Post
    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...

  9. #9
    Join Date
    Apr 2011
    Location
    Banana
    Posts
    14

    Default Re: Encrypted ext4 partition corrupted. Recovery possible?

    Quote Originally Posted by tic226 View Post
    ...
    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?

  10. #10
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,869

    Default 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

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •