☰

如何修复“超级块中的错误幻数”

tag-icon • tag-icon fstab gpt mbr e2fsck
如何修复“超级块中的错误幻数”

我尝试将所有数据从一个 SSD 移动到另一个 SSD。旧SSD为500GB，新SSD为1000GB。

首先我创建了一个备份：

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

然后我尝试恢复备份：

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

之后，我收到一个错误：

$ 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

你知道我该如何解决它吗？

详细信息的附加输出：

$ 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

答案1

当我在实时 debian USB 会话中使用 KDE 分区管理器移动 ext4 debian“/”分区失败时，遇到了这个问题。

对我来说很长的故事：我认为问题出在旧的/损坏的USB驱动器上，因为我使用旧的实时USB安装，并且我懒得重新安装/重新刻录实时Linux USB拇指驱动器。 KDE 分区管理器成功执行两次操作后，第三次操作（将分区向左移动），程序失败并报告错误。重新启动时，我留下了无法启动的 ext4 分区和无法安装的 ( mount: wrong fs type, bad option, bad superblock on /dev/nvme0n1p6) 分区。

当检查该分区或磁盘（fsck /dev/nvme0n1p6或fsck /dev/nvme0n1）时，它报告了“ Bad magic number in super-block”消息 - 与原始帖子的问题相同。

不工作：

  • e2fsck -b 32768 <device>

按照建议

做了什么工作：

  • 测试盘！！！ （阅读下面的更多内容）

正如我怀疑的那样，我认为问题出在修改的分区表（就像分区被移动）但未移动的数据（文件）中。修改和更正或恢复未受腐蚀的分区表进入我使用的原始状态testdisk（apt install testdisk，教程（https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step）我[deepsearch]通过 testdisk 执行并选择（右、左箭头）分区（标有 P（保留，D 表示忽略/未分配空间），我希望将其显示在新分区表中（类似于原始（未损坏），即新旧）分区表就在那一步。可能的还列出文件（按P）在丢失的分区上，以确保您要恢复正确的分区。如果它说“在此分区上找不到文件”或类似内容，则表明有关所需分区的分区表信息（开始/结束扇区）是错误的。

在目标磁盘上使用fdisk -l进行比较（与开始、结束和扇区数）并正确选择好的（无问题）分区以避免在此过程中删除它们是很有帮助的。

使用结束后testdisk，选择[write]将分区表写入磁盘。现在，该分区又可以挂载了。

答案2

像这样恢复整个磁盘映像备份后，您可能应该运行partprobe /dev/nvme0n1以确保内核对磁盘分区的想法是正确的。

lsblk -f显示 7 个分区且其中任何一个都没有可识别的文件系统类型这一事实nvme0n1表明，在恢复备份后，内核对磁盘分区的想法可能已经过时。

如果源磁盘（以及恢复的磁盘映像）已分区，则e2fsck在该/dev/nvme0n1​​设备上运行将永远不合适：您应该以适当的分区设备为目标。事实是这样e2fsck说的：

Found a gpt partition table in /dev/nvme0n1

意味着您绝对不应该运行任何类型的文件系统检查，/dev/nvme0n1因为该磁盘显然已分区。

但是，如果源磁盘最初是mkfs作为没有分区的单个文件系统（= 称为“超级软盘配置”），那么e2fsck /dev/nvme0n1可能是合适的 - 但前提是磁盘上的文件系统类型是ext2、ext3或ext4。

如果磁盘或分区包含任何其他类型的文件系统，则e2fsck不是适合它的工具：您应该使用正确的文件系统类型特定工具。

答案3

我知道这是一个旧论坛，但我通过使用 dd 向其写入 Linux 发行版 ISO 来修复 USB 上的错误超级块错误。然后我在 gparted 中将其格式化为 ext4，对其运行 fsck 并没有看到错误。

相关内容