考虑这样的无头服务器：远程位置的典型 x86 机器，您可以使用库存（例如 Ubuntu 映像）远程初始化它。初始化后，您只能通过 ssh 登录 - 或远程重置它，即您无法访问 BIOS 或启动管理器提示符（例如 Grub 1）。
也许某种 KVM 是可用的，但 KVM 的使用非常昂贵，而且您必须按小时预订。
考虑到这种情况，人们可能会对启动问题感到偏执。例如：
- 如果内核升级失败怎么办？
- 早期启动过程中的 fsck 提示怎么样？可能 ssh 还不可用......
还有其他需要注意的问题吗？
对于内核升级，我配置 grub（旧版），以便menu.lst前导码包含
default saved
fallback 2 # counts from 0
第一个条目以以下内容结尾：
savedefault fallback
第一个 grub 条目是升级后的内核，第三个是已知的工作内核。另请参阅grub 手册中有关后备引导的部分。
我更改了启动脚本/etc/rc.local（在类似 Debian 的系统上），以便在成功启动时重置默认条目设置：
grub-set-default 0
这个 grub 设置有效，但例如在 Ubuntu 上这不是默认设置，并且必须menu.lst在每次内核更新后手动调整。
我供应
panic=60
作为内核参数，例如，如果root=参数错误或内核损坏，系统会在出现错误时自动重新启动。
关于 fsck 问题我不确定最好的方法是什么。在类似 Debian 的系统上你可以设置
FSCKFIX=yes
in /etc/default/rcS，它告诉 fsck 默认情况下自动修复。
但如果自动修复失败，也许我还是会提示无法远程访问？
或者，我可以通过第六列中的零禁用 fsck 检查/etc/fstab- 如果出现 fs 错误，则只需重新初始化系统并恢复备份 - 从而避免所有 fsck 麻烦？
答案1
说真的，如果您的提供商不为极端情况提供免费（或至少便宜）的手动帮助，那么是时候更换了。否则，我认为你对你的设置非常满意。
当您的系统损坏严重到 fsck 无法修复时，除了完全重新安装之外，没有什么其他可做的。实际上我还没有看到这种情况发生，除非出现致命的硬件故障。
有一点需要注意。对于这样的机器，选择稳定的发行版（Debian、RHEL、SLES），并且一定要在适当长的时间后才升级（新版本至少稳定 6 个月）。
答案2
答案3
您可以考虑制作一个自定义 initrd，其中包括 dropbear（当然，在另一个端口上运行）、足够的逻辑来让您的网络正常运行，也许还可以在需要时加载一些恢复工具。在此基础上，您可以创建一个恢复内核配置，该配置将加载网络功能并允许您通过 ssh 登录，从而允许您返回系统并尝试恢复。