Failure to mount hard-drive, corrupt file system

Legiontheai · 2019-03-14 22:14:19

So I know that a windows program corrupted my Filesystem in the Linux partition (ext2fsd). I ran some of the commands [here](https://askubuntu.com/questioqns/849872 … 921#857921) on the sda4 drive and it seemed to solve it but sdb2 still doesn't work(sda is where the Linux boot itself is)
Is the drive recoverable? How?

d_fajardo · 2019-03-14 22:39:45

The page you quoted is gone.
What explicit commands did you try and what are the outputs?

Legiontheai · 2019-03-14 22:45:02

https://askubuntu.com/questions/849872/ … 921#857921
This is the correct link. The command was fsck.ext4 -p -b 884736 -B 4096 /dev/sda5
I ran it on the corrupted sda4 and it fixed it. Could not to the same on sdb2.

Legiontheai · 2019-03-14 23:07:50

If I run fsck - f it returns superblock checksum does not match superblock. If I then run e2fsck -b 8193 and e2fsck -b 32768 it returns "Bad magic number in superblock while trying to open /dev/sdb2"

seth · 2019-03-15 07:32:36

lsblk -f

I assume you're just assuming that those parameters fit your disks?

dumpe2fs -h /dev/sdb2

Legiontheai · 2019-03-15 10:57:05

seth wrote:

lsblk -f
I assume you're just assuming that those parameters fit your disks?
dumpe2fs -h /dev/sdb2

Yeah I did assume that for "fsck.ext4 -p -b 884736 -B 4096 /dev/sda5"(I dont know what those numbers are supposed to stand for). Regarding "fsck - f" it suggested me to run " e2fsck -b 8193 and e2fsck -b 32768" afterwards.

lsblk -f gives me:

 NAME   FSTYPE LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                     
├─sda1 ext4         cb7d2ed7-1aa2-4ff1-9bc0-85bd7b8e8c11  119.7M    30% /boot
├─sda2 swap         07e6efc4-519b-4afe-9ad1-6e948327329b                [SWAP]
├─sda3 ext4         980a07a0-f478-4a99-b182-4b551584ff32     10G    61% /
└─sda4 ext4         7cd18f32-07f6-49b2-b1ff-386fc8696f7a    6.7G    85% /home
sdb                                                                     
├─sdb1 ext4         07451aa4-9b0e-4b83-beb3-443ed9694f17                
└─sdb2 ext4         07451aa4-9b0e-4b83-beb3-443ed9694f17

and dumpe2fs -h /dev/sdb2 gives me:

dumpe2fs 1.45.0 (6-Mar-2019)
Filesystem volume name:   <none>
Last mounted on:          /home/harddrive
Filesystem UUID:          07451aa4-9b0e-4b83-beb3-443ed9694f17
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              35454976
Block count:              141790134
Reserved block count:     7089506
Free blocks:              12444975
Free inodes:              35323074
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      990
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Oct 27 09:00:33 2018
Last mount time:          Mon Mar 11 14:27:41 2019
Last write time:          Mon Mar 11 14:32:57 2019
Mount count:              89
Maximum mount count:      -1
Last checked:             Sat Oct 27 09:06:59 2018
Check interval:           0 (<none>)
Lifetime writes:          1035 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a85590a9-eb20-4955-8757-165d464275b7
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x557ef9f5
Journal features:         journal_incompat_revoke journal_checksum_v3
Journal size:             1024M
Journal length:           262144
Journal sequence:         0x0000a466
Journal start:            0
Journal checksum type:    crc32c
Journal checksum:         0xf12a976b

dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdb2
*** Run e2fsck now!

seth · 2019-03-15 12:23:22

sdb1 & sdb2 have the same UUIDs, you can start to be worried…
Were those disks part of a raid?

Try to replicate the FS generation to see the suppsed superblock position, see https://wiki.archlinux.org/index.php/Fi … ery#e2fsck using the "mke2fs -n …" method.

Legiontheai · 2019-03-15 16:02:16

Yeah sdb1 had the windows partition but I deleted it in fdisk yesterday and added a new partition (fdisk d, n, x) but I don't really care what happens to sdb1 since it's empty. I don't really know what a raid is, so I'm going with no.

mke2fs -n says that "/dev/sdb2 contains a ext4 file system, proceed anyway?"

seth · 2019-03-15 19:23:00

As the wiki quotes from the manpage, the "-n" switch will prevent mke2fs from real action.
It ist however important that you otherwise pass the same parameters (journal, blocksize, …) as you did when originally creating the FS.

Legiontheai · 2019-03-15 19:34:56

Is there any command that lists those? I just created the partition using the default numbers way back when I installed arch

seth · 2019-03-15 19:49:16

dumpe2fs - looks pretty standard to me, though.

Legiontheai · 2019-03-15 20:20:11

dumpe2fs gives me

Filesystem volume name:   <none>
Last mounted on:          /home/harddrive
Filesystem UUID:          07451aa4-9b0e-4b83-beb3-443ed9694f17
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              35454976
Block count:              141790134
Reserved block count:     7089506
Free blocks:              12444975
Free inodes:              35323074
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      990
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Oct 27 09:00:33 2018
Last mount time:          Mon Mar 11 14:27:41 2019
Last write time:          Mon Mar 11 14:32:57 2019
Mount count:              89
Maximum mount count:      -1
Last checked:             Sat Oct 27 09:06:59 2018
Check interval:           0 (<none>)
Lifetime writes:          1035 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a85590a9-eb20-4955-8757-165d464275b7
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x557ef9f5
Journal features:         journal_incompat_revoke journal_checksum_v3
Journal size:             1024M
Journal length:           262144
Journal sequence:         0x0000a466
Journal start:            0
Journal checksum type:    crc32c
Journal checksum:         0xf12a976b

and sudo mke2fs -n -b 4096 -g 32768 -N 35454976 -J size=1024 /dev/sdb2 gives me

mke2fs 1.45.0 (6-Mar-2019)
/dev/sdb2 contains a ext4 file system
Proceed anyway? (y,N) y
Creating filesystem with 141790134 4k blocks and 35454976 inodes
Filesystem UUID: 6af19236-d938-4cb0-8bf4-626db8e3aaf9
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000

loqs · 2019-03-15 20:28:20

If you try fsck with the suggested other backup superblocks than 884736?
If those all have bad magic please post the output of `fsck -f` you mentioned in post #6.

Legiontheai · 2019-03-15 21:29:37

fsck with the backups gives bad magic yes.

sudo fsck -f /dev/sdb2
fsck from util-linux 2.33.1
e2fsck 1.45.0 (6-Mar-2019)
ext2fs_open2: Superblock checksum does not match superblock
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Superblock checksum does not match superblock while trying to open /dev/sdb2

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>

seth · 2019-03-15 21:48:41

If there's *no* usable superblock left, the FS is toast.
If you don't have backups, it's time to hate yourself and hope for https://wiki.archlinux.org/index.php/Fi … d_PhotoRec
But tbh: if *all* superblocks are corrupted, there's probably not much left… :-(

One thing: have testdisk scan the disk for lost partitions, in case you screwed things when deleting the windows partition (the duplicate UUID is suspicious)

Arch Linux

#1 2019-03-14 22:14:19

Failure to mount hard-drive, corrupt file system

#2 2019-03-14 22:39:45

Re: Failure to mount hard-drive, corrupt file system

#3 2019-03-14 22:45:02

Re: Failure to mount hard-drive, corrupt file system

#4 2019-03-14 23:07:50

Re: Failure to mount hard-drive, corrupt file system

#5 2019-03-15 07:32:36

Re: Failure to mount hard-drive, corrupt file system

#6 2019-03-15 10:57:05

Re: Failure to mount hard-drive, corrupt file system

#7 2019-03-15 12:23:22

Re: Failure to mount hard-drive, corrupt file system

#8 2019-03-15 16:02:16

Re: Failure to mount hard-drive, corrupt file system

#9 2019-03-15 19:23:00

Re: Failure to mount hard-drive, corrupt file system

#10 2019-03-15 19:34:56

Re: Failure to mount hard-drive, corrupt file system

#11 2019-03-15 19:49:16

Re: Failure to mount hard-drive, corrupt file system

#12 2019-03-15 20:20:11

Re: Failure to mount hard-drive, corrupt file system

#13 2019-03-15 20:28:20

Re: Failure to mount hard-drive, corrupt file system

#14 2019-03-15 21:29:37

Re: Failure to mount hard-drive, corrupt file system

#15 2019-03-15 21:48:41

Re: Failure to mount hard-drive, corrupt file system

Board footer