Impossible de monter le SSD ext4: `JBD: pas de superbloc de journal valide trouvé`

5

J'ai un petit problème. J'utilise Ubuntu 10.04 LTS sur mon ordinateur portable et il y a environ 2 ans, j'ai remplacé le disque dur vieillissant par un disque SSD de 32 Go. Aujourd'hui, j'ai essayé de démarrer mon ordinateur, mais cela n'a pas pu.

J'ai donc placé le SSD dans un rack de disque dur externe et démarré un live CD Ubuntu 10.10 pour tenter de récupérer des données à partir du SSD. Le disque SSD apparaît dans le menu déroulant mais il ne monte pas.

Bûche:

ubuntu@ubuntu:~$ dmesg | tail
[ 2125.445659] sd 8:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB)
[ 2125.446983] sd 8:0:0:0: [sda] Write Protect is off
[ 2125.446988] sd 8:0:0:0: [sda] Mode Sense: 17 00 00 08
[ 2125.446992] sd 8:0:0:0: [sda] Assuming drive cache: write through
[ 2125.449084] sd 8:0:0:0: [sda] Assuming drive cache: write through
[ 2125.449098]  sda: sda1 sda2 < sda5 >
[ 2125.454285] sd 8:0:0:0: [sda] Assuming drive cache: write through
[ 2125.454293] sd 8:0:0:0: [sda] Attached SCSI disk
[ 2125.777836] JBD: no valid journal superblock found
[ 2125.777840] EXT4-fs (sda1): error loading journal

Y at-il un moyen de résoudre ce problème afin que je puisse récupérer mes données?

— Andreja
source

4

Juste effectuer:

mke2fs -t ext4 -O ^has_journal /dev/sdX

(dans votre cas, sdX est sda1) pour recréer la partition ext4 avec le journal activé. Ou reformater la partition:

mke2fs -F -L "PartitionLabel" -t ext4 -O ^has_journal /dev/sdX

— Luart
source

1

Avez-vous essayé de courir fsckdessus?

Depuis le démarrage en direct, essayez quelque chose comme:

fsck.ext4 -Dcfy -C 0 /dev/sdX#

Cela va:

-D - Optimize directories
-c - Check for bad sectors
-f - Force a check
-y - Assumes 'yes' to all questions
-C 0 - Prints info to stdout

Vous devez simplement vous assurer, sans montage, que vous l’exécutiez sur X (le SSD) et sur chaque partition (uniquement les partitions EXT4).

Cela devrait résoudre les problèmes connus du système, signalez-le si cela ne vous dérange pas et je peux le mettre à jour si je trouve d'autres options.

Vous avez également trouvé un lien qui parle du "superbloc", mais je ne le connais pas mais il utilise des commandes similaires:

sudo fsck.ext4 -v /dev/sdX

La sortie d'un mauvais superbloc devrait ressembler à ceci:

fsck /dev/sda5
fsck 1.41.4 (27-Jan-2009)
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext4: **Group descriptors look bad**... trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda5

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

Puis vérifiez l’emplacement des sauvegardes de superbloc:

sudo mke2fs -n /dev/sdX

Il devrait vous dire que les sauvegardes de superbloc sont stored on blocks: # # #

Enfin, restaurez les sauvegardes (si elles existent):

sudo e2fsck -b block_number /dev/sdX

Encore une fois, je n’ai pas essayé cela et je ne peux pas parler de sa validité - espérons que quelqu'un d'autre en sache un peu plus sur cette méthode. La source

— nerdwaller
source

2

S'il vous plaît, n'exécutez pas aveuglément fsck sur un disque ou un système de fichiers cassé: cela peut très facilement aggraver les choses rapidement , en particulier lors de l'utilisation -y. Même en 2013, lorsque cette question était d'actualité, 32 Go représentaient une quantité d'espace de stockage relativement négligeable; Il est généralement conseillé de faire une copie au niveau du secteur (peut-être même deux dans ce cas, ne touchant qu’un d’eux) et de travailler sur la copie pour voir si vous pouvez rétablir le système de fichiers dans un état stable, puis restaurez le fichier corrigé. copier sur l'original ou simplement extraire les données de la copie fixe sur un nouveau support.

— un CVn