我安装了一个不错的 Ubuntu 18.04 系统，并运行了许多不同的内部 SATA 驱动器，并且稳定运行了几个月，所有人都很高兴。然后有一天，发生了一次简单的停电。没问题，我们以前经历过这些。电源恢复后，服务器没有响应 SSH；有时我必须去地下室并按下盒子上的按钮才能将其重新打开。我这样做了，几分钟后，我仍然无法通过 SSH 访问。
所以现在我在地下室，盒子上连接着一个小显示器和键盘，我可以看到 Ubuntu 徽标在重启后很长一段时间都在那里，所以我按下按键⬆并观察启动加载程序，看起来似乎它的超时时间是这样的：
A start job is running for dev-disk-by\x2duuid-914d3b77\x2d06c4\x2d4514\x2d8fee\x2d1fc6eb81bbd9.device (51s / 1min 30s)
实际上一开始有两个错误，两个错误似乎都在达到 1 分 30 秒后超时。另一个超时的启动作业似乎引用了UUID=a158e6ec-1433-454c-9cd2-10f7306fde82.因此，我四处搜索并了解了超时作业中的 UUID 如何与我指定的一些 UUID 相对应，/etc/fstab以便在启动时自动安装内部硬盘驱动器。
1:30 后，我按 Enter 键进入根命令提示符，运行vim /etc/fstab并注释掉与我的 2 个错误相对应的行，所以现在文件如下所示：
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=6f90b496-401e-475f-add0-3c6d3bcae7a0 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=BFE0-55D4 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Tre ext4 defaults 0 0
UUID=6c7b175d-b80b-4069-bbbe-f82aeb302200 /media/Sam ext4 defaults 0 0
#UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 defaults 0 0
#UUID=914d3b77-06c4-4514-8fee-1fc6eb81bbd9 /media/Wes ext4 defaults 0 0
保存文件后，我运行rebootUbuntu，很快就重新启动了。它没有出现，我进入了登录屏幕。我从黑暗的地下室服务器柜里爬出来，然后从沙发上通过 SSH 回来。
我使用blkid并发现我称为 Wes 的驱动器上的 UUID 似乎与我在 中的 UUID 不同/etc/fstab，因此我进行了备份并将该 UUID 编辑为来自该行的 UUID blkid，并取消注释该行。又一个reboot，现在韦斯回来了。所以现在我只是缺少我称之为 Hex 的大 6TB 驱动器，我的/etc/fstab外观如下：
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=6f90b496-401e-475f-add0-3c6d3bcae7a0 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=BFE0-55D4 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Tre ext4 defaults 0 0
UUID=6c7b175d-b80b-4069-bbbe-f82aeb302200 /media/Sam ext4 defaults 0 0
#UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 defaults 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Wes ext4 defaults 0 0
如果我取消对 Hex 行的注释，我会陷入等待 1:30 等待同一作业超时的无限循环。如果我用来journalctl -xe查看日志并转到我认为出现问题的地方，我会看到一个红色错误，例如：
zen systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-a158e6ec\x2d1433\x2d454c\x2d9cd2\x2d10f7306fde82.device
这似乎对应于同一个六角驱动器。
由于担心驱动器已损坏，我从壁橱中取出盒子并打开它并取出了特定的硬盘驱动器。我把它拿到办公桌上，将其插入 SATA 转 USB 接口并供电。驱动器开始旋转，我将它连接到我的 Mac 笔记本电脑。当我打开磁盘工具时，我可以看到硬盘，但它说它只有1.8TB，而且我看不到分区。
我认为这部分可能是正确的，因为我似乎记得必须做一些特殊的事情来格式化 6TB 驱动器，也许 Mac 无法看到它？不管怎样，看到驱动器后我很受鼓舞，并决定将其放回服务器中。
我阅读了更多内容并搜索了更多内容，我就陷入了这个循环。我可以注释掉该/etc/fstab条目并通过 SSH 进入系统，也可以取消注释并重新启动挂起。如果我cd进入，/media/Hex我可以看到一些顶级文件夹和文件，但是广阔的大部分文件结构似乎消失了，或者对我来说是不可见的。
如何让 Hex 恢复正常？
答案1
defaults将选项替换noauto,x-systemd.automount为/etc/fstab：
UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 noauto,x-systemd.automount 0 0
来自 Archlinux 维基：使用 systemd 自动挂载
如果分区较大，在 fsck 检查时允许不依赖于它的服务启动可能会更有效。这可以通过将以下选项添加到分区的 /etc/fstab 条目来实现：
noauto,x-systemd.automount这只会在第一次访问分区时进行 fsck 和挂载，并且内核将缓冲对其的所有文件访问，直到准备好为止。例如，如果一个人有一个非常大的 /home 分区，则此方法可能是相关的。
答案2
最好的情况：系统只是尝试在文件系统上运行日志恢复和/或文件系统检查Hex，并且需要超过 1 分 30 秒，因为文件系统太大了。在这种情况下，最好在系统的其余部分启动后手动运行文件系统检查，请参阅下面的说明。
最坏的情况：磁盘可能在硬件级别出现故障。
如果您可以看到一些文件和文件夹，/media/Hex而其行被注释掉，/etc/fstab并且您没有手动安装它，那么某些程序可能已写入空目录，该目录应该只是 的安装点Hex，而实际的Hex文件系统已卸载。这与实际文件系统中的文件状态无关，但一旦文件系统的当前问题得到解决，Hex合并回真实文件系统可能会有点痛苦。Hex
暂时将/etc/fstab行注释掉。Hex系统启动并Hex连接到系统后，blkid像之前一样使用命令来识别Hex当前的设备名称。一旦知道了这一点，您就可以开始进一步的诊断。
假设包含文件系统的设备Hex的名称类似于/dev/sdX1（其中 X 是我不知道的字母 - 你必须自己弄清楚），然后删除分区号以了解相应的全磁盘设备，即/dev/sdX.也可以在不使用任何分区表的情况下初始化文件系统的整个磁盘 - 在这种情况下，blkid将报告文件系统直接存在于整个磁盘设备上/dev/sdX。
好的第一步是运行sudo smartctl -H -a -f brief -l error /dev/sdX：它应该报告磁盘的整体健康状况、SMART 属性以及磁盘本身可能记录的任何硬件级错误。如果这些表明磁盘在硬件级别上正常，则可以继续。 （如果您不确定如何解释结果，请编辑您的原始问题并将输出添加到其中。）
如果磁盘指示硬件故障，您需要做出决定：如果故障磁盘包含重要数据，则最好停止尝试自行修复它，并将磁盘发送给数据恢复专业人员。专业恢复可能会花费一些费用，但成功恢复数据的机会最高。如果您选择这样做，请不要自己对磁盘做任何进一步的事情：如果磁盘出现物理故障，保持磁盘通电可能会使问题变得更糟，并使恢复工作变得更加困难。
如果磁盘在硬件层面上没有问题，或者其中的数据“不值得专业恢复的钱，但能恢复就好了”，下一步就是了解分区情况。既然你说它是一个 6 TB 磁盘，它可能使用 GPT 分区。这些命令中的任何一个都应该显示分区布局：
sudo parted /dev/sdX print
sudo gdisk -l /dev/sdX
sudo fdisk -l /dev/sdX
（我认为fdiskUbuntu 18.04 的 足够新，足以理解 GPT 分区，但如果它报告类似 1.8 TB 的分区，而其他命令显示完整的 6 TB，那可能不是真正的问题。）
请编辑您的原始问题以添加此分区信息。接下来的步骤将取决于这些检查的结果。
如果磁盘有 SMART 故障指示，下一步将购买相同或更大大小的新磁盘，并尝试尽快将全部内容复制到新磁盘，也许使用ddrescue或类似的工具。完成此操作后，您的数据应该不会进一步恶化。
如果磁盘的 SMART 诊断正常并且可以识别文件系统，那么在继续之前先将磁盘克隆到新磁盘可能仍然是一个好主意，以防万一。然后，您可以尝试在报告包含文件系统的设备上运行文件系统检查：类似于sudo fsck.ext4 -f -C0 /dev/sdX1.在大磁盘上，这可能需要相当长的时间：该-C0选项告诉文件系统检查器在运行时提供完成百分比。
如果文件系统检查成功，下一步是尝试手动挂载它：例如，sudo mount /dev/sdX1 /media/Hex.如果它显示/media/Hex正在使用，则/media/Hex在执行安装时必须停止可能正在使用该安装点的任何服务。
如果/media/Hex安装后看起来正常，您可以松一口气，手动卸载它（sudo umount /media/Hex），取消注释其行/etc/fstab并重新启动系统：现在它应该再次正常启动，因为文件系统已被检查并完全卸载。
要在挂载真实文件系统后清理挂载点目录中剩余的所有文件（现在隐藏在真实Hex文件系统“下方”） ，您可以执行以下操作：Hex
sudo mkdir /mnt/Hex_oops
sudo mount --bind / /mnt/Hex_oops
cd /mnt/Hex_oops/media/Hex
...然后看看其中的文件和目录/mnt/Hex_oops/media/Hex是否重要。如果是，您现在可以将它们移动到真实Hex文件系统中的正确位置；如果它们只是某些应用程序自动创建的空目录，您可以删除它们（因为它们无用地占用根文件系统中的空间）。然后删除这个临时安排：
cd /
sudo umount /mnt/Hex_oops
sudo rmdir /mnt/Hex_oops