我处于 grub 救援模式，可用命令只是 ls，搜索，search.file 不存在。
我已经找到我的分区使用ext2，即hd0 msdos6。
当我执行 ls 时，它由 tmp/ root/ var/ dev/ proc/ run/ sys/ 组成
我们所期待的正常启动是 root 也能启动吗？
但是 boot/ 在哪里？我什至不知道为什么 grub 现在坏了。
我已经知道它可以通过另一个Linux（例如 boot seq dick ）来修复，但我对此犹豫不决。因为我需要先借某人的电脑将其安装在拇指驱动器上。
答案1
是的，你需要依赖像启动修复盘这样的iso工具。
在这种情况下，我建议使用 rufus 而不是 unetbootin。
只是为了防止额外的烦恼。
具体来说，如果您有双启动，这些工具可能会通过 Linux 恢复 Windows（如果有）。
为了防止这种情况，您可以单击高级选项，然后单击 mbr 选项选项卡。然后选择您想要的正确分区。选择错误的分区也会导致启动失败。所以请小心。
您可以利用内置的 gparted 来帮助您找到正确的分区
答案2
当我执行 ls 时，它由 tmp/ root/ var/ dev/ proc/ run/ sys/ 组成
这确实看起来像根文件系统，但是：
/bin应该是根文件系统上的目录（或/usr/bin某些新发行版中的符号链接），但它丢失了- 应该有
/boot作为/boot文件系统的挂载点或只是作为常规目录，但它丢失了 /dev是基于 RAM 的文件系统的挂载点/dev，它就在那里/etc应该始终是根文件系统上的一个目录，它丢失了- 如果没有单独的
/home分区，那么/home也应该是一个常规目录；也失踪了 /lib应该类似于/bin，也缺少/media并且/mnt应该基本上是空目录，用作可移动媒体和系统管理操作的挂载点，这些都丢失了/proc是虚拟文件系统的挂载点/proc，它就在那里/root有没有/run是基于 RAM 的 tmpfs 的挂载点，专用于 PID 文件和其他运行时状态，它就在那里/sbin应该类似于/bin，它丢失了/sys是虚拟文件系统的挂载点sysfs，它就在那里/tmp通常是基于 RAM 的挂载点tmpfs/usr在现代系统中应该是根文件系统上的常规目录，但它丢失了/var可能是常规目录或挂载点，它就在那里
呃哦...这看起来像是...的结果sudo rm -rf /或类似的结果。如果这是真的，那么i386-pc/normal.mod就会失踪你最不担心的。
根分区上仍然存在的大部分目录都是系统正常运行时用作其他文件系统挂载点的目录。剩下的几个普通目录都在字母排序顺序的末尾。
如果不首先卸载活动挂载点，则无法删除rm -rf它们，这可能解释了大多数目录仍然存在的原因。
其他的（基本上只是/root和/var）可能纯粹是靠运气而得救：系统可能已经崩溃，因为 和/lib（/usr/lib和/或rm命令本身）中的基本系统库在 和 的删除之前被删除了，/root有/var时间完成。
我很遗憾地说，假设您已正确识别分区，这看起来像是一个介于“严重损坏”和“完全损坏”之间的系统。
您可能希望从实时 Linux 介质启动并挂载所有分区（一开始是只读的！），以查看是否有任何重要文件未受到破坏。并尽你所能恢复一切到不同的磁盘。如果您想尝试恢复已删除的文件，不要向该分区写入任何内容和别跑fsck直到您用尽所有恢复可能性（包括但不限于使用以下命令扫描分区内容）摄影记录）并准备放弃挽救任何进一步数据的希望。