ext4 - Bad magic number in super-block

Question

ext4 is failed me again! the most unstable fs

tried to fix it by restoring block from backup, but without luck..

↪ sudo fsck.ext4 -v /dev/sdd
e2fsck 1.45.6 (20-Mar-2020)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdd

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>

/dev/sdd contains DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 4294967295 sectors, extended partition table (last) data


↪ sudo mke2fs -n /dev/sdd
mke2fs 1.45.6 (20-Mar-2020)
/dev/sdd contains DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 4294967295 sectors, extended partition table (last) data
Proceed anyway? (y,N) y
Creating filesystem with 976754646 4k blocks and 244195328 inodes
Filesystem UUID: 0e4124ad-a390-4c60-bb4a-4f7c48dac23b
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
102400000, 214990848, 512000000, 550731776, 644972544


↪ sudo e2fsck -b 32768 /dev/sdd
e2fsck 1.45.6 (20-Mar-2020)
e2fsck: Bad magic number in super-block while trying to open /dev/sdd

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>

/dev/sdd contains DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 429496725 sectors, extended partition table (last) data

i've tried blocks up to 11239424

↪ sudo fdisk -l /dev/sdd
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdd: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: TOSHIBA MD04ABA4
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 7D5C7ECA-C305-3C44-AA4F-8503EB53A54F

Device     Start        End    Sectors  Size Type
/dev/sdd1   2048 7814031359 7814029312  3.7T Linux filesystem


↪ sudo e2fsck -b 32768 /dev/sdd1
e2fsck 1.45.6 (20-Mar-2020)
e2fsck: No such file or directory while trying to open /dev/sdd1
Possibly non-existent device?

`/dev/sdd` may be the wrong block device. What about `mke2fs -n /dev/sdd1`? What is the output of `fdisk -l /dev/sdd`? Add that to your question. — Hauke Laging, Jul 12 '20 at 13:40
If the partition table is corrupt, then I don't think it is a problem with the filesystem... — LustreOne, Jul 13 '20 at 02:28
@LustreOne already scanned hdd with R-Linux, everything is fine, but docs about partition table are rare and i still feels my not confident to do that — Yu Da Chi, Jul 13 '20 at 12:53

score 1 · Accepted Answer · answered Dec 20 '20 at 12:42

since you have worked partition somewhere in backup inside hdd

↪ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

The primary GPT table is corrupt, but the backup appears OK, so that will be used.

you can simply dump it and restore right after dump

sudo sfdisk -d /dev/sdb > sdb.dump
sudo sfdisk /dev/sdb < sdb.dump

and whoaliya =)

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Checking that no-one is using this disk right now ... OK

Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: TOSHIBA MD04ABA4
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 7D5C7ECA-C305-3C44-AA4F-8503EB53A54F

Old situation:

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 7814031359 7814029312  3.6T Linux filesystem

>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new GPT disklabel (GUID: 7D5C7ECA-C305-3C44-AA4F-8503EB53A54F).
/dev/sdb1: Created a new partition 1 of type 'Linux filesystem' and of size 3.6 TiB.
Partition #1 contains a ext4 signature.
/dev/sdb2: Done.

New situation:
Disklabel type: gpt
Disk identifier: 7D5C7ECA-C305-3C44-AA4F-8503EB53A54F

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 7814031359 7814029312  3.6T Linux filesystem

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

only 2 commands in terminal

only few seconds

it's so easy, don't waste your time and money for new hdd and rstudio backups ;)

OK, the first command ran fine, the second failed with below. Please advise. Device Boot Start End Sectors Size Id Type /dev/sdd1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT /dev/sdd2 206848 1250263039 1250056192 596.1G 7 HPFS/NTFS/exFAT The partition table has been altered. Calling ioctl() to re-read partition table. Re-reading the partition table failed.: Device or resource busy The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8). Syncing disks. — ericm, Jun 28 '21 at 23:36

score 0 · Answer 2 · answered Jul 12 '20 at 14:24

0

I guess in contrast to fdisk the kernel does not use the partition table backup. So you first have to repair it. It may be enough to just open the drive with fdisk /dev/sdd and write the partition table.

answered Jul 12 '20 at 14:24

Hauke Laging

88,146
18
125
174

is it safe for data? maybe first i'll try some live cd with another kernel?? – Yu Da Chi Jul 12 '20 at 14:31
I doubt that will make a change but feel free to do that. If you want to be on the safe side then you can manually create a snapshot with `dmsetup` (and maybe a small (100M) RAM disk loop device as COW volume) and make the changes to the snapshot. That way the original device is unchanged so you can test the operation. But that is complicated. Too complicated for me to add that to the answer at least. You would need `kpartx` in that case for creating a block device that is equivalent to `sdd1`. – Hauke Laging Jul 12 '20 at 14:41
thanks! you was right!! feeling bad a little, so much time wasted, it was simple as 2 commands in terminal and everything is working now, my data has been safe all the time :-) – Yu Da Chi Dec 20 '20 at 12:45

score 0 · Answer 3 · answered Jul 13 '20 at 02:31

0

If you download the e2fsprogs sources from github you could build the findsuper tool to scan the device for ext2/3/4 superblock magic values. That should tell you where on disk the filesystem is, and will help you repair the partition table.

answered Jul 13 '20 at 02:31

LustreOne

1,555
5
19

how exactly it will help? – Yu Da Chi Jul 13 '20 at 12:52

ext4 - Bad magic number in super-block

3 Answers3