Nie można zamontować dysku SSD ext4: `JBD: nie znaleziono prawidłowego superbloku dziennika`

5

Mam trochę problemu. Używam Ubuntu 10.04 LTS na moim laptopie i około 2 lata temu wymieniłem starzejący się dysk twardy na 32 GB SSD. Dzisiaj próbowałem uruchomić komputer, ale nie udało się.

Więc umieściłem dysk SSD w zewnętrznym stojaku na dyski twarde i uruchomiłem CD Live Ubuntu 10.10, aby spróbować odzyskać dane z dysku SSD. Dysk SSD pojawia się w rozwijanym menu, ale nie można go zamontować.

Log:

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

Czy istnieje sposób, aby to naprawić, aby odzyskać moje dane?

Andreja
źródło

Odpowiedzi:

4

Po prostu wykonaj:

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

(w twoim przypadku sdX jest sda1), aby odtworzyć partycję ext4 z włączonym dziennikiem. Lub ponownie sformatować partycję:

mke2fs -F -L "PartitionLabel" -t ext4 -O ^has_journal /dev/sdX
luart
źródło
1

Próbowałeś fsckna nim biegać ?

Z live boot spróbuj czegoś takiego:

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

To będzie:

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

Musisz tylko upewnić się, bez montowania, jak sądzę, że uruchamiasz go na X (SSD) i na każdej partycji (tylko na partycjach EXT4).

To powinno naprawić znane problemy systemowe, zgłoś się, jeśli nie masz nic przeciwko, i mogę zaktualizować, jeśli znajdę inne opcje.


Znalazłem również link mówiący o „superbloku”, który może być wart sprawdzenia, chociaż nie jestem tego zaznajomiony, ale używa podobnych poleceń:

sudo fsck.ext4 -v /dev/sdX

Dane wyjściowe dla złego superbloku powinny wyglądać następująco:

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>

Następnie sprawdź lokalizację kopii zapasowych superbloku:

sudo mke2fs -n /dev/sdX

Powinien ci powiedzieć, że są kopie zapasowe superbloku stored on blocks: # # #

Na koniec przywróć kopie zapasowe (jeśli istnieją):

sudo e2fsck -b block_number /dev/sdX

Ponownie nie próbowałem tego i nie mogę mówić o jego ważności - mam nadzieję, że ktoś inny może dowiedzieć się nieco więcej o tej metodzie. Źródło

nerdwaller
źródło
2
Proszę nie ślepo uruchamiać fsck na uszkodzonym dysku lub systemie plików: może bardzo szybko spieszyć się ze złym na gorsze, szczególnie podczas korzystania -y. Nawet w 2013 r., Kiedy to pytanie było aktualne, 32 GB stanowiło stosunkowo trywialną ilość miejsca do przechowywania; powszechną radą byłoby wykonanie kopii na poziomie sektora (być może nawet dwóch w tym przypadku, dotykając tylko jednego z nich) i praca nad kopią i sprawdzenie, czy można przywrócić system plików do stabilnego stanu, a następnie przywrócić naprawiony skopiuj oryginał lub po prostu wyodrębnij dane ze stałej kopii na nowy nośnik.
CVn