修复 gparted 崩溃后部分未分配的分区

修复 gparted 崩溃后部分未分配的分区

今天早些时候,我试图缩小并移动一个分区,这时 gparted 完全冻结了。(不是主操作系统分区)等了大约 4 个小时后,我强制关闭了电脑。现在,当我在 gparted 中查看分区时,它看起来像。如您所见,分区空间中的某些部分显然未分配。我无法挂载、缩小、移动或以其他方式更改分区。使用 gparted 检查它会引发错误。我该怎么办?(/dev/nvme0n1p8 是受影响的分区

编辑:e2fsck:

sudo e2fsck /dev/nvme0n1p8
e2fsck 1.43.4 (31-Jan-2017)
/dev/nvme0n1p8 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Missing '.' in directory inode 510513.
Fix<y>? yes
Setting filetype for entry '.' in ??? (510513) to 2.
Missing '..' in directory inode 510513.
Fix<y>? yes to all
Setting filetype for entry '..' in ??? (510513) to 2.
Entry 'S3J5cHRpYy50dGY=.png' in ??? (510513) has deleted/unused inode 6166343.  Clear? yes

Entry 'RnJlaWdodFRleHQgTGlnaHRTQy50dGY=.png' in ??? (510513) references inode 6167543 found in group 752's unused inodes area.
Fix? yes

ext2fs_read_inode: Inode checksum does not match inode while reading inode 6167543 in check_filetype

/dev/nvme0n1p8: ***** FILE SYSTEM WAS MODIFIED *****
e2fsck: aborted

/dev/nvme0n1p8: ***** FILE SYSTEM WAS MODIFIED *****

编辑 fdisk -l (/dev/nvme0n1p8 是受影响的分区

ubuntu-gnome@ubuntu-gnome:~$ sudo fdisk -l 
Disk /dev/loop0: 1.4 GiB, 1462083584 bytes, 2855632 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 03DB32A6-DAC5-46B5-8138-C9F14617A1FB

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048    1026047   1024000   500M EFI System
/dev/nvme0n1p2   1026048    1288191    262144   128M Microsoft reserved
/dev/nvme0n1p3   1288192   46344191  45056000  21.5G Linux swap
/dev/nvme0n1p4 971556864  972503039    946176   462M Windows recovery environmen
/dev/nvme0n1p5 972503040  997814271  25311232  12.1G Windows recovery environmen
/dev/nvme0n1p6 997816320 1000214527   2398208   1.1G Windows recovery environmen
/dev/nvme0n1p7  46344192  513597439 467253248 222.8G Linux filesystem
/dev/nvme0n1p8 513597440  971556863 457959424 218.4G Linux filesystem

Partition table entries are not in disk order.


Disk /dev/sda: 1.9 GiB, 2003828736 bytes, 3913728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x782a20f2

Device     Boot Start     End Sectors  Size Id Type
/dev/sda1  *        0 2964415 2964416  1.4G  0 Empty
/dev/sda2       84608   89215    4608  2.3M ef EFI (FAT-12/16/32)

sudo df

Filesystem     1K-blocks    Used Available Use% Mounted on
udev             8108160       0   8108160   0% /dev
tmpfs            1624936   10352   1614584   1% /run
/dev/sda         1482208 1482208         0 100% /cdrom
/dev/loop0       1427840 1427840         0 100% /rofs
aufs             8124668  209576   7915092   3% /
tmpfs            8124668   84140   8040528   2% /dev/shm
tmpfs               5120       4      5116   1% /run/lock
tmpfs            8124668       0   8124668   0% /sys/fs/cgroup
tmpfs            8124668       0   8124668   0% /tmp
tmpfs            1624932      60   1624872   1% /run/user/999

sudo mount -a没有输出

答案1

首先,你的分割看起来不错;这是文件系统它包含已损坏的内容。

分区由起点和终点或长度(具体取决于分区表类型)以及一些辅助数据(如分区类型代码)定义。分区表是非常简单的数据结构,您没有提供任何证据表明您的分区表已损坏。

另一方面,文件系统是驻留在分区内的更复杂的数据结构。也就是说,分区提供了指向文件系统数据结构开头的指针,而文件系统可以做更多有趣的事情,比如让计算机定位单个文件和目录。它们相当微妙且非常复杂。在“调整分区大小”或“移动分区”上花费的绝大部分时间实际上都花在调整文件系统数据结构,而不是分区数据结构。

我之所以要强调这种区别,是因为缺乏对它的理解可能会让你白费力气。特别是,像gdisk或(大多数情况下)这样的分区工具测试磁盘如果您的文件系统基本完好无损,但分区起始点错误,则可能会有所帮助。在这种情况下,TestDisk 可能能够找到正确的起始点并在其周围构建一个新分区。但这似乎不太可能——您的输出表明e2fsck已识别文件系统但难以修复它。如果您正在移动分区的起始点,则意味着文件系统的起始数据结构已被移动,但作业不完整或拙劣;或者操作尚未移动分区的起始点。无论哪种方式,文件系统的数据结构都已损坏,即使您可以找到旧的起始点,也无济于事。因此,您正在查看文件系统级修复,使用分区表现在标识的起始点。在您的情况下,坏的分区起始点唯一有意义的方式是,如果当前分区起始点指的是旧文件系统——要么是来自以前的分区,要么是您试图缩小的原始分区,但 GParted 已移动文件系统的起始点,但未调整分区的起始点。这两种情况都有可能,但可能性不大。如果其中一种情况正确,TestDisk 可能会找到正确的文件系统起始点。这种可能性很小。也许值得一试,但我不会对成功抱有太大希望。

另一方面,如果分区指向当前正确的文件系统起始点,那么文件系统就严重损坏了。在这种情况下,我建议您首先尝试复制所有重要的用户数据。如果分区将以只读模式挂载,您可能能够复制其中保存的数据。如果您获得足够的数据,则可以卸载文件系统,在分区中创建一个新的文件系统(或一个具有所需位置和大小的新文件系统),然后将数据复制回来。

如果分区根本无法安装,那么一些高级恢复工具可能会有所帮助。这些包括:

  • 测试磁盘-- 此工具通常用于定位文件系统并在其周围创建新分区,但据我所知,它还有一种模式,可以浏览文件系统中的文件。可以想象这会找到一些东西。不过,我对此功能了解甚少,因此无法提供有关如何使用它的更多详细信息。
  • 相簿-- 此工具可让您从严重损坏的文件系统中恢复单个文件。不过,据我上次检查,它在恢复文件名或目录结构方面做得并不好,因此您将不得不筛选大量文件。
  • debugfs-- 这是一个先进的 ext2/3/4fs 取证工具,可以帮助您恢复一些东西。
  • e2fsck——您已经尝试过此工具,但它具有可能有助于恢复的高级选项。

对于最后两个选项,我没什么建议。我相信网上有教程可以帮助解决这些问题,但我没有想到任何特定的网站,所以你的网络搜索和我一样好。如果自动选项e2fsck失败了,就像你遇到的情况一样,那么你就进入了专家文件系统恢复领域。

另一个选择是聘请专业的数据恢复服务。这可能很昂贵,但如果您的分区包含重要数据,那么这可能是值得的。

不管你做什么,在没有备份的情况下,请勿尝试写入磁盘!此时你所做的任何事情都可能使情况变得更糟,因此在你尝试使用e2fsck、TestDisk 或任何其他会写入磁盘的程序之前,务必使用dd对该分区进行原始备份(如果你通过将其起点向右移动来缩小分区,并且分区表显示新的起点,则可能还要备份分区之外的区域)。请注意,这dd本身就很危险,因此请谨慎当然输入正确的输入(if=)和输出(of=)选项!

祝您康复顺利!

相关内容