☰

No se puede leer el superbloque en la matriz RAID 10 LUKS después de la congelación de rsync (Ubuntu Server 18.04.3 con escritorio Budgie)

tag-icon • tag-icon luks superblock
No se puede leer el superbloque en la matriz RAID 10 LUKS después de la congelación de rsync (Ubuntu Server 18.04.3 con escritorio Budgie)

Durante una rsync desde una matriz LUKS raid 10 externa (conectada por e-sata) a una unidad interna, el sistema operativo se congeló.

Después de reiniciar, ya no puedo acceder al raid externo 10. Cuando hago clic en él, aparece el siguiente mensaje de error:

Error mounting filesystem
Error mounting /dev/dm-0 at /media/marco/EXT_RAID_10: can't read superblock
on /dev/mapper/luks-49aa238c-96bc-4bf6-abeb-1f4b018ccabe (udisks-error-quark, 0)

El sistema es el servidor Ubuntu 18.04.3 con escritorio Budgie. Las 4 luces de manejo están encendidas, lo que indica que supuestamente están bien.

Salida de sudo fdisk -l:

Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x373d828f

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda2            2048 468860927 468858880 223.6G  5 Extended
/dev/sda5       443695104 468860927  25165824    12G 82 Linux swap / Solaris
/dev/sda6            4096 226996223 226992128 108.2G 83 Linux
/dev/sda7       226998272 443693055 216694784 103.3G 83 Linux

Partition table entries are not in disk order.


Disk /dev/sdf: 3.7 TiB, 4000694927360 bytes, 7813857280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B9829E9E-44BE-4381-BB42-387062B5252D

Device     Start        End    Sectors  Size Type
/dev/sdf1   2048 7813855231 7813853184  3.7T unknown


Disk /dev/mapper/luks-49aa238c-96bc-4bf6-abeb-1f4b018ccabe: 3.7 TiB, 4000690733056 bytes, 7813849088 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Salida de sudo fsck.ext4 -v /dev/sdf1:

e2fsck 1.44.1 (24-Mar-2018)
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/sdf1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
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>
 or
    e2fsck -b 32768 <device>

/dev/sdf1 contains a crypto_LUKS filesystem

Salida de sudo mke2fs -n /dev/sdf1:

Creating filesystem with 976731648 4k blocks and 244187136 inodes
Filesystem UUID: 11a09e27-4114-4555-8dd3-afcf61deacc4
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848, 512000000, 550731776, 644972544

Salida de sudo e2fsck -b 98304 /dev/sdf1:

e2fsck 1.44.1 (24-Mar-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/sdf1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
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>
 or
    e2fsck -b 32768 <device>

/dev/sdf1 contains a crypto_LUKS filesystem

Al final, el problema fue simplemente que la unidad estaba bloqueada debido a la interrupción del comando rsync (también sucedió cuando interrumpí un comando cp simple). Este simple bloqueo se complicó porque el cifrado LUKS dio un mensaje de error críptico (juego de palabras). Resolví esto quitando el candado siguiendo las instrucciones de: https://alvinabad.wordpress.com/2012/09/22/how-to-recover-a-luks-encrypted-disk/

En breve:

1. Boot from a recovery disk

2. Determine /dev address of locked LUKS partition (in this case /dev/sdh1):
~$ sudo fdisk -l

3. Display LUKS header info:
~$ sudo cryptsetup -v luksDump /dev/sdh1

4. Unlock partition with LUKS passphrase:
~$ sudo cryptsetup -v luksOpen /dev/sdh1 sdh1_crypt

5. Mount drive using Nautilus or manually:
~$ mkdir /tmp/disk
~$ sudo mount /dev/mapper/sdh1_crypt /tmp/disk

Respuesta1

Cambié el cable e hice esto: https://alvinabad.wordpress.com/2012/09/22/how-to-recover-a-luks-encrypted-disk/

Trabajó para mi:

1. Boot from a recovery disk

2. Determine /dev address of locked LUKS partition (in this case /dev/sdh1):
~$ sudo fdisk -l

3. Display LUKS header info:
~$ sudo cryptsetup -v luksDump /dev/sdh1

4. Unlock partition with LUKS passphrase:
~$ sudo cryptsetup -v luksOpen /dev/sdh1 sdh1_crypt

5. Mount drive using Nautilus or manually:
~$ mkdir /tmp/disk
~$ sudo mount /dev/mapper/sdh1_crypt /tmp/disk

Respuesta2

No tengo una configuración Raid, sin embargo, yo mismo he tenido errores con Linux.
Asegúrate de que no sean tus cables eSATA.

Cómo reparar un error del sistema de archivos en Ubuntu

Inicie su sistema usando el CD de instalación de Ubuntuy luego seleccione Probar Ubuntu.
A continuación, abra una terminal y use la línea de comando
   $ sudo fsck.ext3 -f /dev/sdaX
para iniciar una búsqueda de errores. Todos los errores encontrados deben repararse.

Puede pedirle al sistema que verifique el sistema de archivos en el próximo reinicio escribiendo
   sudo touch/forcefsck

información relacionada