嘿，碰到这种远程服务器卡在维护模式没法操作、还得跑回家物理干预的情况，确实够闹心的。我给你整理几个实用的方案，帮你以后不用折腾就能远程搞定这类问题：

一、配置自动修复，跳过交互式维护模式 #

Ubuntu默认在检测到文件系统错误时，会进入需要手动确认的维护模式——这就是你之前物理接键鼠才能处理的原因。我们可以让系统自动尝试修复可解决的错误，直接跳过这个环节：

• 编辑/etc/default/rcS文件，找到FSCKFIX=no这一行，改成FSCKFIX=yes。这个配置会让系统启动时自动运行fsck并修复可恢复的错误，不用等人工确认。
• 同时检查/etc/fstab里根分区的第6个字段（也就是pass参数），确保它的值是1——这表示fsck会优先检查根分区，避免遗漏关键错误。

二、让救援/维护模式支持SSH登录 #

如果自动修复解决不了问题，还是需要进入维护模式，但我们可以让这个模式下也能远程SSH连接：

1. 先确保openssh-server已经安装：sudo apt install openssh-server
2. 编辑/etc/ssh/sshd_config，调整几个关键配置：
   • 把PermitRootLogin改成yes（如果用密钥登录更安全，也可以设为prohibit-password，只允许密钥验证的root登录）
   • 确保PasswordAuthentication yes（如果需要密码登录的话，优先推荐密钥登录）
3. 把SSH服务添加到救援模式的启动项：sudo systemctl enable sshd.service --rescue
4. 最后确认救援模式下的网络能正常工作——如果是DHCP自动获取地址一般没问题，要是静态IP的话，检查/etc/netplan下的配置文件，确保网络参数在救援模式也能加载。

三、调整启动参数，避免重启挂起 #

有时候重启挂起不是因为文件系统错误，而是启动过程中某个服务卡住或者磁盘IO异常。我们可以修改GRUB启动参数来优化：

• 编辑/etc/default/grub，找到GRUB_CMDLINE_LINUX这一行，添加以下参数（按需选择）：
  • fsck.mode=force fsck.repair=yes：强制启动时运行fsck并自动修复
  • systemd.unit=rescue.target：直接进入救援模式，跳过正常启动流程
  • init=/bin/bash：临时进入单用户命令行（适合紧急修复，不建议永久配置）
• 修改完后执行sudo update-grub让配置生效。下次重启时，系统会按照新的参数启动，减少挂起的概率。

四、提前监控磁盘健康，防患于未然 #

磁盘IO错误往往是硬件故障的前兆，提前监控能帮你避免突发宕机：

• 安装smartmontools工具：sudo apt install smartmontools，然后用smartctl -a /dev/sda（替换成你的磁盘设备名）查看磁盘SMART健康报告，重点看“Overall Health Self-Assessment Test Result”是否为“PASSED”。
• 设置定时任务，比如每天自动运行一次磁盘健康检查，把结果通过邮件发送给你——用crontab -e添加类似0 0 * * * smartctl -a /dev/sda | mail -s "Disk Health Report" your-email@example.com的任务。
• 条件允许的话，配置RAID阵列或者定期备份数据，这样即使磁盘出现严重故障，也能快速切换到备用磁盘或者恢复数据，不用彻底停服。

备注：内容来源于stack exchange，提问作者Michal Oprendek