Linux 实例使用 VNC 及救援模式排障

Recent Pages

Linux 实例使用 VNC 及救援模式排障

最后更新时间：2024-01-06 17:32:18

通常情况下，多数 Linux 系统类问题可通过 VNC 方式及救援模式进行排查及修复。本文介绍如何使用这两种方式排查 Linux 实例无法 SSH 登录、系统失败问题。您可通过本文了解并在遇到实例问题时，进行排查及修复。
排查工具
VNC 登录是通过 Web 浏览器远程连接云服务器的方式，一般在无法正常 SSH 远程登录实例时使用。使用 VNC 登录方式可直接观察云服务器状态，或进行修改系统内配置文件等操作。
救援模式一般在 Linux 系统无法正常启动，或无法通过 VNC 登录时使用。常见使用场景例如 fstab 配置异常、系统关键文件缺失、lib 动态库文件损坏/缺失等。
问题定位及处理
VNC 方式排查 SSH 无法登录问题
现象描述
使用 SSH 登录 Linux 实例时，出现报错信息 “ssh_exchange_identification: Connection closed by remote host”。如下图所示：
﻿
﻿
可能原因
kex_exchange_identification 阶段的 connection reset 报错，一般代表 ssh 相关进程已启动，但是配置可能存在异常，例如 sshd 配置文件权限被修改。
解决思路
参见 处理步骤，检查 sshd 进程，定位并解决问题。
处理步骤
﻿参考以下步骤，使用 VNC 登录 Linux 实例：
﻿
1. 登录 云服务器控制台，找到需要登录的 Linux 云服务器，单击右侧的登录。如下图所示：
﻿
﻿
2. 在打开的标准登录 | Linux 实例窗口，单击 VNC登录。
3. 在 login 后输入用户名，按 Enter，在 Password 后输入密码，按 Enter。如下图所示即为登录成功：
 
﻿
﻿
4. 执行以下命令，查看 sshd 进程是否正常运行。
ps -ef | grep sshd
返回结果如下图所示，sshd 进程正常。
﻿
﻿
5. 执行以下命令，查看报错原因。
sshd -t
返回类似如下图所示信息 “/var/empty/sshd must be owned by root and not group or world-writable.
”，可定位错误原因为 /var/empty/sshd/ 权限问题导致。
﻿

您还可通过查看 /var/log/secure 日志中的报错信息来辅助排查。如下图所示：
﻿
﻿
6. 执行以下命令，查看 /var/empty/sshd 目录权限。
ll -d /var/empty/sshd/
返回结果如下图所示，可知权限被修改为777。
﻿
﻿
7. 执行以下命令，修改 /var/empty/sshd/ 文件权限。
chmod 711 /var/empty/sshd/
参见 使用 SSH 登录 Linux 实例 测试后，可正常远程登录实例。
VNC 方式排查 Linux 系统启动失败问题
现象描述
无法正常 SSH 远程登录 Linux 云服务器，但使用 VNC 方式登录后，查看系统启动失败且提示信息 “Welcome to emergency mode”。如下图所示：
﻿
﻿
可能原因
可能由于 /etc/fstab 配置不当导致。
例如，已在 /etc/fstab 中配置使用设备名称自动挂载磁盘，但云服务器重启时设备名称发生改变，导致系统无法正常启动。
解决思路
参见 处理步骤 修复 /etc/fstab 配置文件，重启服务器后再进行核验。
处理步骤
1. 参见 处理步骤，使用 VNC 登录 Linux 实例。
2. 进入 VNC 界面后，查看到如 现象描述 中所示界面，请输入 root 账户密码并按 Enter 登录服务器。输入的密码默认不显示，如下图所示：
﻿
﻿
3. 进入系统后，执行以下命令，查看 fstab 文件中盘符信息是否正确。
lsblk
返回结果如下图所示，文件中盘符信息有误：
﻿
﻿
4. 执行以下命令，备份 fstab 文件。
cp /etc/fstab /home
5. 执行以下命令，使用 VI 编辑器打开 /etc/fstab 文件。
vi /etc/fstab
6. 按 i 进入编辑模式，将光标移动至错误配置行首，并输入 # 注释该行配置。如下图所示：
﻿
﻿
7. 按 Esc 输入 :wq 后，按 Enter 保存设置并退出编辑器。
8. 通过控制台重启实例，详情请参见 重启实例。
9. 验证是否能正常启动及登录。
救援模式排查 Linux 系统启动失败问题
现象描述
Linux 系统重启之后无法正常启动，提示信息有诸多 FAILED 启动失败项。如下图所示：
﻿
﻿
可能原因
可能由于关键系统文件缺失导致启动失败，例如 bin 或 lib 文件缺失。
解决思路
参见 处理步骤，通过控制台进入实例救援模式，进行问题排查及修复。
处理步骤
1. 进入救援模式前，强烈建议您对实例进行备份，以防止由于出现误操作等造成的影响。云硬盘可通过 创建快照 备份，本地系统盘可通过 创建自定义镜像 镜像备份。
2. 登录 云服务器控制台，在“实例”页面中，选择实例所在行右侧的更多 > 运维与检测 > 进入救援模式。如下图所示：
﻿
﻿
3. 在弹出的进入救援模式窗口中，设置救援模式期间登录实例的密码。如下图所示：
﻿
﻿
4. 单击进入救援模式，此时实例状态会变为进入救援模式。如下图所示，该过程一般会在几分钟内完成：
﻿

正常进入救援模式后实例的状态会变为红色叹号的“救援模式”。如下图所示：
﻿
﻿
5. 使用 root 账户及 步骤3 中设置的密码，通过以下方式登录实例。
若实例有公网 IP，则请参见 使用 SSH 登录 Linux 实例。
若实例无公网 IP，则请参见 使用 VNC 登录 Linux 实例。
6. 本文以 VNC 方式登录为例，登录成功后，依次执行以下命令挂载系统盘根分区。
说明：
救援模式下实例系统盘设备名为 vda，根分区为 vda1，默认未挂载。
mkdir -p /mnt/vm1
mount /dev/vda1 /mnt/vm1
执行完成后，返回结果如下图所示：
﻿
﻿
7. 挂载成功后，即可操作原系统根分区中的数据。
您也可使用 mount -o bind 命令，挂载原文件系统的一部分子目录，并通过 chroot 命令用来在指定的根目录下运行指令，具体操作命令如下：
mount -o bind /dev /mnt/vm1/dev
mount -o bind /dev/pts /mnt/vm1/dev/pts
mount -o bind /proc /mnt/vm1/proc
mount -o bind /run /mnt/vm1/run
mount -o bind /sys /mnt/vm1/sys
chroot /mnt/vm1 /bin/bash
执行 chroot 命令时：
若无报错信息，可继续执行 cd / 命令。
若出现如下图所示报错信息，说明无法正常切换根目录，此时可执行 cd /mnt/vm1 查看根分区数据。
﻿
﻿
8. 通过命令，可查看原系统根分区中 /usr/bin 目录下的所有文件被删除。如下图所示：
﻿
﻿
9. 此时，可创建一台同操作系统的正常机器，并执行以下命令将正常系统 /usr/bin 目录下的文件压缩后远程拷贝至异常机器上。
正常机器：依次执行以下命令
cd /usr/bin/ && tar -zcvf bin.tar.gz *
scp bin.tar.gz root@异常实例ip：/mnt/vm1/usr/bin/
说明：
有公网 IP 可通过公网拷贝，无公网 IP 需通过内网拷贝。
执行结果如下图所示：
﻿
﻿
异常机器：在救援模式下依次执行以下命令
cd /mnt/vm1/usr/bin/
tar -zxvf bin.tar.gz
chroot /mnt/vm1 /bin/bash
执行结果如下图所示：
﻿
﻿
10. 实例修复完成后，选择实例所在行右侧的更多 > 运维与检测 > 退出救援模式。如下图所示：
﻿
﻿
11. 退出救援模式后实例处于关机状态，开机后进行系统验证。如下图所示，系统已恢复。
﻿
﻿
﻿