How to fix "Bad magic number in super-block"

Question

I try to move all data from one SSD to another SSD. The old SSD is 500 GB, and the new SSD is 1000 GB.

Firstly I've created a backup:

dd if=/dev/nvme0n1 | gzip -c /media/ubuntu/local/backup1.img.gz

Then I tried to restore the backup:

gunzip -c /media/ubuntu/local/backup1.img.gz | dd of=/dev/nvme0n1

After that, I got an error:

$ sudo e2fsck /dev/nvme0n1
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/nvme0n1

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>

Found a gpt partition table in /dev/nvme0n1

Do you know how I can fix it?

Additional output for details:

$ lsblk -f
NAME        FSTYPE   FSVER            LABEL                    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdc                                                                                                                
└─sdc1      ntfs                      local                    824A5D3E4A5D2FE1                        244G    49% /media/ubuntu/local
nvme0n1                                                                                                            
├─nvme0n1p1                                                                                                        
├─nvme0n1p2                                                                                                        
├─nvme0n1p3                                                                                                        
├─nvme0n1p4                                                                                                        
├─nvme0n1p5                                                                                                        
├─nvme0n1p6                                                                                                        
└─nvme0n1p7      

Answer 1

I fell into this problem when failingly moving a ext4 debian "/" partition with KDE partition manager in live debian USB session.

Long story for me: I think problem was in old/corrupted USB drive, since I used old live USB installation and I was too lazy to reinstall/reburn live linux USB thumbdrive. After successfully performing 2 operations by KDE partition manager, with the third (moving of the partition to the left), the program failed and reported a error. When rebooting I was left with unbootable ext4 partition and unmountable (mount: wrong fs type, bad option, bad superblock on /dev/nvme0n1p6) one.

When checking that partition or disk (fsck /dev/nvme0n1p6 or fsck /dev/nvme0n1) it reported the "Bad magic number in super-block" message - the same as in original post's question.

Did not work:

• e2fsck -b 32768 <device>

as suggested

What did work:

• testdisk !!! (read more below)

As I suspected, the problem I think was in modified partition table (as if partition was moved) but unmoved data (files). To modify and correct or recover the uncorrupted partition table into its original state I used testdisk (apt install testdisk, tutorial (https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step) I performed [deepsearch] by testdisk and selected (right, left arrow) partitions (marked with P (remain, D means ignored/unallocated space) that I want to be present in new (similar to original (uncorrupted), i.e. new old) partition table. In that step it is possible also to list files (press P) on lost partition, to make sure you are about to recover the right partition. If it says "no files found on this partition" or sth similar, that indicates that the partition table info (start/end sectors) about that wanted partition is wrong.

It is helpful to use fdisk -l on target disk to compare (with start, end and number of sectors) and select correctly the good (unproblematic) partitions to avoid deleting them in the process.

At the end of the use of testdisk, select [write] to write the partition table to the disk. Now, as a result, the partition is again mountable.

Answer 2

After restoring a whole-disk image backup like that, you should probably run partprobe /dev/nvme0n1 to ensure the kernel's idea of the disk's partitioning will be correct.

The fact that lsblk -f shows 7 partitions on nvme0n1 with no recognizable filesystem type on any of them suggests the kernel's idea of the disk's partitioning might be out of date after restoring the backup.

If the source disk (and so the restored disk image) is partitioned, running e2fsck on the /dev/nvme0n1 device will never be appropriate: you should target the appropriate partition device(s) instead. The fact that e2fsck says:

Found a gpt partition table in /dev/nvme0n1

means you definitely should not run a filesystem check of any type on /dev/nvme0n1 as this disk is apparently partitioned.

But if the source disk was originally mkfs'd as a single filesystem without partitions (= known as "superfloppy configuration"), then e2fsck /dev/nvme0n1 might be appropriate - but only if the filesystem type on the disk is ext2, ext3 or ext4.

If the disk or partition contains a filesystem of any other type, then e2fsck is not an appropriate tool for it: you should use the correct filesystem-type-specific tool instead.

Answer 3

i know this is an old forum, but I fixed a bad super block error on a usb by writing a linux distro iso to it using dd. then i formatted it to ext4 in gparted, ran fsck on it and saw no error.