Alibaba cloud international server special offer

腾讯云服务器进不去系统：VNC、救援模式与重装前要做的三件事

凌晨两点，运维群里蹦出一句“机器连不上了”，紧跟着客户补了一句：“要不直接重装吧。”我盯着屏幕的第一反应不是同意，而是把控制台的 VNC 打开——因为“连不上”这三个字，至少能指向五个完全不同的故障层，重装只是其中最贵、最不可逆的那一种处理方式。做了几年腾讯云服务器的一线支持，我见过太多机器是被“修”没的，而不是被故障弄坏的。

先分清 VNC 和 SSH：一个看屏幕，一个走网络

控制台里那个 VNC 窗口，走的是带外通道。它把实例的虚拟显卡画面推给浏览器，把你的键盘输入回传，全程不经过实例的网卡、不依赖 sshd、不看安全组入方向规则、也不理系统里的 firewalld 和 iptables。所以公网 IP 被打进黑洞、安全组被改错、网卡没起来、sshd 配置写坏，这些情况下 VNC 照样能看到登录提示符。

SSH 是带内的。它要求内核正常启动、网卡驱动加载、IP 配置到位、sshd 监听 22 端口、安全组放行来源、回程路由通，中间任何一环断掉，表现都是“连不上”，但断的位置天差地别。

VNC 也有它的边界，得说清楚：刷新慢、画面卡、默认不能复制粘贴大段文本、不能传文件、两个人同时开会互相抢键盘，实例处于“关机”状态时打不开。它不是运维通道，是“看一眼”的通道。

我判断故障的第一个动作永远是这个：开 VNC，看它停在哪。

• 停在 grub 菜单或者 grub> 提示符：引导层出了问题

• 黑屏只有一个光标，或者刷完自检信息就重启：引导或内核

• 停在 Welcome to emergency mode，或者一直等 A start job is running for dev-disk-by...：文件系统与挂载

• 出现 login: 并且能登进去：系统是活的，问题在网络或 sshd

• 满屏 kernel panic 栈：内核、驱动，极少数是内存

这一步只花三十秒，却能把后面三小时的排查范围砍掉一半。VNC 能看到 login:，就说明系统和磁盘都还活着，这时候点重装属于纯粹的信息浪费。

四种“起不来”，长得完全不一样

grub 引导损坏。 常见成因有三个：/boot 被历史内核塞满导致升级中断、误改了 grub 配置、在双系统或重装引导时把 MBR 写花。现象很固定——GRUB loading. 之后自己重启，或者直接掉进 grub> 命令行，error: unknown filesystem 也是常客。修的时候要进救援环境挂上系统盘，chroot 进去重建：grub2-install /dev/vda，再 grub2-mkconfig -o /boot/grub2/grub.cfg，Debian 系是 update-grub。提醒一句，救援环境里系统盘的设备名不一定是 vda，先用 lsblk 看清楚，写错设备名会把引导写到数据盘上。

fstab 写错。 这条占了“改完配置重启就再也没起来”的一大半。典型是加了数据盘之后手工写挂载，UUID 抄错一位；或者图省事直接写 /dev/vdb，而云盘在 virtio 上的枚举顺序会变；或者挂了 NFS 却没加 nofail，网络还没起来就卡在启动阶段。现象是 emergency mode，加一行 Failed to mount /data、Dependency failed for /data。VNC 里用 root 密码进去，先把根分区重新挂成可读可写，再注释掉出问题的那一行，改完必须先 mount -a 验证不报错，再 reboot。我见过太多人改完直接重启，第二次还是起不来，原因就是没验证。

内核升级失败。 要么 /boot 空间不足导致 initramfs 没生成完整，要么第三方模块（dkms 编译的网卡、存储、加速驱动）在新内核上没编过，重启后新内核 panic，或者卡在 dracut 阶段。判断方法很简单：grub 菜单里选旧内核能进，就是这一类。处理时进旧内核，df -h /boot 和 ls /boot 看一眼是不是堆了五六个 vmlinuz，清掉最老的、留出空间，再重装内核包让 initramfs 重新生成。千万别上来就 rm -rf /boot/*，那等于亲手给自己造一个 grub 故障。

磁盘打满。 / 或 /var 写满、inode 耗尽、日志暴涨、MySQL 的 binlog 没清，都会让机器“活着但不可用”。sshd 需要写 /var/run、/tmp 和日志，写不进去就起不来，SSH 报 No space left on device，而控制台的实例状态一直显示“运行中”。VNC 进去跑 df -h、df -i、du -sh /var/* 排序看。清之前先弄清楚是什么在占：/var/log 里被 access.log 撑满最好处理，/var/lib/mysql 撑满就要先确认 binlog 还有没有从库在用，删错会让主从直接断。

救援模式能救什么，不能救什么

控制台的实例详情里有救援模式入口，支持情况跟地域、实例规格有关，以实际控制台为准。它的本质是给你一个独立的小系统去引导，把你的系统盘当成一块普通数据盘挂进来，让你能改文件、修引导、重置凭据。它不会启动你的业务，也不会替你改数据，除非你亲手写。

适用的是“配置层故障”：fstab 写错、sshd 配置改坏、误删了 /etc/passwd 里的一行、/etc/sudoers 语法错误导致 sudo 全废、grub 需要重建、密码忘了又不想重装。不适用的是“盘本身有问题”：云盘故障、文件系统损坏到根本挂不上（那得先 fsck）、实例规格不支持救援、多块盘分不清哪块是系统盘、加密盘拿不到密钥。

救援模式进不去，我的替代方案是挂盘到临时实例：同地域同可用区开一台按量计费的临时 CVM，把故障实例关机、卸载系统盘，然后在云硬盘页面把它作为数据盘挂到临时机上，mount /dev/vdb1 /mnt 之后随便改。这个办法的坑很具体——必须同可用区，否则挂不上；卸载前必须先关机；卸载前把原来的挂载信息记下来；改完必须卸载再挂回原实例，顺序错了原实例一样起不来。

再往后才是快照回滚。它的语义是整盘覆盖：回滚到某个时刻，那之后的所有写入全部消失。它不是修复，是时光机，只在“修不动了、业务优先”的时候才用。

重置密码不是重装，重装也分两种后果

重置密码只改账号凭据，不动系统盘里的业务数据。腾讯云的重置密码走实例内 agent 或者离线挂载，最终改的是 /etc/shadow 里对应那一行。但它解决不了三件事：登录服务本身被改坏、已经禁止 root 登录又没有别的可登录账号、强制密钥登录却把密码通道一并关掉。我遇到的“重置密码不生效”，八成是这三种，剩下的两成是改错了用户名。

重装是另一回事。控制台的重装系统通常分“仅系统盘”和“含数据盘”，选项名称以重装页面为准。前者只格式化系统盘，数据盘上的文件还在，但 /etc/fstab 是全新的，挂载点没了，重装完要自己挂回去；后者会把数据盘一起格式化，业务数据当场清零。那个勾选框很小，后果很大。用自定义镜像重装，等于把机器退回到做镜像的那一刻，之后装的软件、改的配置、跑出来的数据全部没有。

所以处理顺序应该是：能改配置解决的绝不重装，能进救援模式解决的绝不重装，必须重装的，先把下面这几件事做完。

重装前必须做完的动作，顺序不能反

第一件，打快照，并且等进度到 100%。系统盘一块、数据盘一块，一块都别省。快照是增量的，第一次做接近全量，耗时跟盘的大小和数据量有关，进度条没走完就动手，等于没有快照。

第二件，记录网络与实例属性。内网 IP 是多少（重装一般保留，但删机重建会变）、公网 IP 是普通公网 IP 还是弹性公网 IP（前者随实例释放）、安全组 ID 和具体规则、带宽的计费方式、有没有挂在 CLB 后端、绑的是密钥对还是密码。这些东西重装后都要一项项复原，靠回忆一定会漏。

第三件，导出“重装之后找不回来”的东西。定时任务的完整清单、/etc/nginx/conf.d 整个目录、/etc/my.cnf、/etc/redis.conf、证书和私钥、/etc/hosts、firewalld 或 iptables 的规则、docker ps -a 与 compose 文件、面板自身的数据库、.env 里的连接串。我习惯打成一个 tar 传到对象存储，命名带日期，比存在本地靠谱。

第四件，确认数据盘会不会被格式化。看页面上的勾选项，用 lsblk 和 /etc/fstab 核对挂载点，再问一句业务方“这台机器上有没有人手工建过库、存过文件”。一台腾讯云服务器不是只用来看网站的，上面经常躺着别人不知道的东西。

第五件，确认回滚路径。有没有可用快照、有没有自定义镜像、镜像是什么时候做的、镜像里是不是还留着历史密钥。最后这条特别容易被忽略——用半年前的镜像重装，等于把当时的密钥、当时的后门账号一起请回来，重装完第一件事应该是换密钥、查账号。

下面这张表是我平时直接发给客户的，按现象对层，比口头描述省事。

故障现象 根因层 优先动作 代价与注意

VNC 黑屏无输出，实例状态显示运行中 引导层，grub 或引导盘异常 看启动日志，进救援模式或挂盘重建引导 需要重启，业务中断；不要连续强制重启

停在 emergency mode，等待 dev-disk-by 设备 挂载层，fstab 与 UUID 不匹配 VNC 进 emergency shell，改 fstab 并加 nofail 改错会二次起不来，改完必须执行 mount -a 验证

VNC 有 login 且能登入，SSH 超时 网络层，安全组、sshd、防火墙 查 22 端口监听、安全组来源、sshd 配置 不要为测试把 22 端口放开到所有来源

新内核 panic，选旧内核可进 内核层，boot 分区满或驱动未编译 用旧内核进入，清理 boot 后重装内核包 旧内核先别删，保留两个版本足够

服务全挂，SSH 报 No space left 磁盘层，日志、binlog、临时文件占满 VNC 登录查 df 与 inode，定位大目录 删 binlog 可能断主从，清前先备份

重装后站点空白，数据盘成空目录 操作层，勾了含数据盘或未重新挂载 查 lsblk 与 fstab，确认是否还有快照 含数据盘重装会格式化，只有快照能救

自定义镜像重装后回到半年前 操作层，镜像时点过旧 改用最新快照，或重做镜像 镜像默认不含数据盘内容

轻量应用服务器的边界：它没有完整救援能力

轻量应用服务器 Lighthouse 用起来确实省心，但在“起不来”这件事上，能用的手段比 CVM 少一截。控制台提供快照、重装系统、重置应用镜像、重置密码，但没有通用的“把系统盘挂到另一台机器上慢慢修”的能力，也没有一整套救援入口。所以它的故障处理路径基本只有两条：快照回滚，或者重装。

这不是产品缺陷，是产品定位换来的便宜和简单。但业务设计必须跟着改：开自动快照并确认策略真的在跑、把应用数据放在独立数据盘、把配置放进代码仓库或对象存储、把备份导出到别的地方而不是留在本机、DNS 的 TTL 设短一点方便切走。轻量上跑的东西通常不大，重建成本可控，前提是你提前把“重建需要的东西”挪出了这台机器。

还有一个轻量特有的坑：它的防火墙在控制台，是一套独立规则，不在系统里的 iptables。SSH 连不上时只在系统里翻 iptables -L，很容易一无所获。这个亏我吃过一次，翻了四十分钟才发现是控制台防火墙没放行。

预防：把“能不能修”变成“不用修”

• fstab 一律用 UUID（blkid 取），非关键挂载加 nofail，每次改完 mount -a 验证一遍再重启

• /boot 单独分区留出余量，内核只保留两个版本，RHEL 系设 installonly_limit=2

• 动 fs