| 1 |
You keep top-posting and inverting the logical Q/A flow of this thread ... |
| 2 |
|
| 3 |
On Sunday, 17 November 2019 12:53:51 GMT n952162 wrote: |
| 4 |
> Ah, now I see. Yes, in that respect, that is, if you don't have a |
| 5 |
> chance to get /forcefsck written. |
| 6 |
|
| 7 |
Running fsck manually with various options and then trying to recover various |
| 8 |
superblock locations could get you farther than simply running fsck in an |
| 9 |
accepting fashion. |
| 10 |
|
| 11 |
If fsck.ext4 shows up "bad magic number", you can run dumpe2fs on the |
| 12 |
partition and grep for "superblock" to find the location of both primary and |
| 13 |
backup superblocks of the corrupted fs. Then you can 'e2fsck -b XXXXXXXX / |
| 14 |
dev/sdaX' for each 'XXXXXXXX' superblock location and and try mount it |
| 15 |
thereafter to see if you can access your files. With a bit of luck at least |
| 16 |
one of the supeblocks will work recovering most of the data previously saved |
| 17 |
on this fs. |
| 18 |
|
| 19 |
Needless to say, you would not try this on the original partition, but a |
| 20 |
backup image you can create with ddrescue and friends. In any case, running |
| 21 |
fsck.ext4 -n (or -E nodiscard) should not cause any fs losses, unless the |
| 22 |
disk/hardware is faulty. Hence working on a backup image is the safest |
| 23 |
option. |
| 24 |
|
| 25 |
-- |
| 26 |
Regards, |
| 27 |
|
| 28 |
Mick |
Archives