Không thể gắn SSD ext4: `JBD: không tìm thấy siêu khối tạp chí hợp lệ nào '


5

Tôi có một chút vấn đề. Tôi đang chạy Ubuntu 10.04 LTS trên máy tính xách tay của mình và khoảng 2 năm trước tôi đã thay thế ổ cứng cũ bằng ổ SSD 32 GB. Hôm nay tôi đã cố gắng khởi động máy tính của mình, nhưng không thể.

Vì vậy, tôi đã đặt SSD vào giá đỡ ổ cứng gắn ngoài và khởi động CD Ubuntu 10.10 trực tiếp để cố gắng khôi phục dữ liệu từ SSD. SSD xuất hiện trong menu thả xuống nhưng nó sẽ không gắn kết.

Nhật ký:

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

Có cách nào để khắc phục điều này để tôi có thể khôi phục dữ liệu của mình không?

Câu trả lời:


4

Chỉ cần thực hiện:

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

(trong trường hợp của bạn sdX là sda1) để tái tạo các phân vùng ext4 với tạp chí được kích hoạt. Hoặc để định dạng lại phân vùng:

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

1

Bạn đã thử chạy fscktrên nó?

Từ khởi động trực tiếp, hãy thử một cái gì đó như:

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

Răng se:

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

Bạn chỉ cần đảm bảo, không cần cài đặt, tôi tin rằng bạn chạy nó trên X (SSD) và từng phân vùng (chỉ thực hiện phân vùng EXT4).

Điều đó sẽ khắc phục các sự cố đã biết của hệ thống, báo cáo lại nếu bạn không phiền và tôi có thể cập nhật nếu tôi tìm thấy các tùy chọn khác.


Cũng tìm thấy một liên kết nói về 'siêu khối' có thể đáng để kiểm tra mặc dù tôi không quen với điều này, nhưng nó sử dụng các lệnh tương tự:

sudo fsck.ext4 -v /dev/sdX

Đầu ra cho một siêu khối xấu sẽ trông giống như:

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>

Sau đó kiểm tra vị trí của các bản sao lưu superblock:

sudo mke2fs -n /dev/sdX

Nó sẽ cho bạn biết các bản sao lưu superblock là stored on blocks: # # #

Cuối cùng khôi phục lại các bản sao lưu (nếu chúng tồn tại):

sudo e2fsck -b block_number /dev/sdX

Một lần nữa, tôi đã không thử điều này và không thể nói đến tính hợp lệ của nó - hy vọng người khác có thể biết thêm một chút về phương pháp này. Nguồn


2
Xin đừng mù quáng chạy fsck trên một đĩa hoặc hệ thống tệp bị hỏng: nó có thể rất dễ dàng đưa mọi thứ từ xấu đến tồi tệ một cách vội vàng, đặc biệt là khi sử dụng -y. Ngay cả trong năm 2013, khi câu hỏi này là hiện tại, 32 GB là một dung lượng lưu trữ tương đối tầm thường; Lời khuyên phổ biến là tạo một bản sao cấp ngành (thậm chí là hai trong trường hợp này, chỉ chạm vào một trong số chúng) và làm việc trên bản sao, và xem liệu bạn có thể đưa hệ thống tệp trở lại trạng thái ổn định không, sau đó khôi phục lại bản sửa lỗi sao chép qua bản gốc hoặc đơn giản là trích xuất dữ liệu từ bản sao cố định lên phương tiện mới.
một CVn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.