通常我在网上找到答案没有任何问题，但我已经尝试修复我宕机的服务器三天了，但却没有任何进展。
有问题的服务器是一台 Centos 5.5 机器，运行 openvz-kernel，更准确地说是 2.6.18-194.8.1.el5.028stab070.5。我们无法物理访问服务器，也没有某种串行/网络控制台。我们有一个通过 pxe 加载的基于 debian 的救援磁盘。
服务器有两个磁盘，SDA：
Disk /dev/sda: 320.0 GB, 320071851520 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sda1 * 524 1193 5381775 83 Linux
/dev/sda2 1 523 4200997 82 Linux swap / Solaris
/dev/sda3 1194 38913 302985900 83 Linux
Partition table entries are not in disk order
和深发展：
Disk /dev/sdb: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 38913 312568641 83 Linux
sda1 有文件系统，sda2 是交换空间，sda3 和 sdb1 一起组成 md0，挂载在 /vz 上。这是 fstab。
/dev/sda1 / ext3 defaults 1 1
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
/dev/sda2 swap swap defaults 0 0
/dev/md0 /vz ext3 defaults 0 0
和 menu.lst/grub.conf
boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/boot/grub/splash.xpm.gz
title CentOS (2.6.18-194.8.1.el5.028stab070.5)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-194.8.1.el5.028stab070.5 ro root=/dev/sda1
initrd /boot/initrd-2.6.18-194.8.1.el5.028stab070.5.img
title CentOS (default)
root (hd0,0)
kernel /boot/bzImage ro root=/dev/sda1
现在由于某种原因，服务器瘫痪了，我们无法让它恢复正常工作。我们的提供商试图通过前面提到的救援磁盘重新安装 grub 并挂载 sda1 @ /mnt 来“修复”我们的问题。
grub-install --root-directory=/mnt '(hd0)'
https://i.stack.imgur.com/1FRi6.jpg
这是服务器启动时监视器输出的照片。现在它可以清楚地加载 /etc/fstab，因为它尝试从我们的交换分区恢复。
现在，由于我们无法访问服务器，因此我们使用 Qemu 来尝试调试问题，但我们永远无法确定它的行为方式是否相同，而且每次我们在 sda1 上进行更改时，我们都需要重新启动服务器才能让 qemu 查看更改，欢迎以其他方式执行此操作。我们以以下方式使用 qemu。
qemu-system-x86_64 -vnc :0 -hda /dev/sda -hdb /dev/sdb
我们尝试重新安装最新内核。尝试制作一个不支持 raid 和强制 ext3 支持的新 initrd。从具有相同设置的服务器复制 /boot。在几乎所有可能的磁盘/分区上安装 grub。
我不知道还能尝试什么。任何建议我都非常感谢。
总结：服务器宕机了，由于“无法找到文件系统错误”无法重启
答案1
你的 grub.conf 是什么样的？也许突然有一个错误配置的 root= 或 init= 参数？
如果不是这种情况，当您通过基于 Debian 的救援系统挂载 CentOS / 分区时，是否存在 /dev 目录？如果有，它是什么样子的？如果您使用 或 检查它，它是否与 /dev/sda1 信息匹配stat？ls -lah也许 /dev/root 指向错误的位置（或者，使用错误的 mknod 参数创建）。
是的，/dev 现在应该相当动态，但你永远不知道...回到内核 2.4 的日子，我关闭了我的一个 Gentoo 系统，并在手动重新创建了一些设备节点后使其启动。
在原始问题中添加 grub.conf 后进行编辑：
您的 grub.conf 的第一行 (boot=/dev/sda) 看起来很可疑。尝试将其注释掉并重新启动。
如果这不起作用，您可能还需要使用 检查/dev/sda1参数ls -lah。它应该看起来像这样：
brw-r----- 1 root disk 104, 1 Sep 29 01:23 /dev/sda1
观察类似于104，1。然后创建/dev/root和
mknod -m 640 /dev/root b 104 1
您可以根据您的需要更改 104 和 1 的值。
希望这可以帮助！
答案2
对于我们来说，这里描述的问题实际上是分区标签丢失。