【银河麒麟】服务器系统开机黑屏故障排查与修复

【问题现象】

银河麒麟V10服务器系统开机后，过了麒麟Logo画面后黑屏，仅屏幕左上角有一个短横杠（光标）不停闪烁，无法正常进入系统。

【排查和修复过程】

1. 开启调试日志

为了获取更多的启动日志信息，需要在GRUB引导菜单中开启调试日志。通过编辑内核启动参数，追加调试选项并移除静默启动参数，可以让系统在启动时输出详细的日志。

# 在选择内核时按字母e进入GRUB编辑界面，找到linux**行，在末尾追加以下参数

#同时删除splash和quiet**参数（如果有的话），按ctrl+x启动

复制代码

console=tty0 loglevel=7 systemd.log_level=debug

2. 系统落入救援模式

添加上述参数后启动系统，发现系统因无法正常启动而落入了救援模式（rescue mode）。

# 在Control-D行后输入root用户的密码即可进入救援模式提供的命令行，密码的输入是不显示的，确认输入正确后回车即可

3. 检查传统日志文件

进入救援模式后，首先检查了传统的系统日志文件 dmesg 和 /var/log/messages，但均未发现与本次故障相关的有用信息。同时注意到一个异常现象：/var/log/messages 中最近的日志时间停留在2015.07.14，明显不正常。该问题留待后续进一步排查。

复制代码

dmesg
cat /var/log/messages

4. 通过journalctl定位错误

由于传统日志未能提供有效线索，使用 journalctl 命令查看本次启动以来的所有error级别日志。通过该命令发现了关键报错：graphical.target 处于masked（屏蔽）状态，导致图形界面无法启动。

复制代码

journalctl -xb -p err --no-pager

5. 尝试unmask无效

通过 systemctl status 确认graphical.target 确实处于masked状态。随后尝试执行 systemctl unmask 命令解除屏蔽，但问题依旧存在，说明简单的unmask操作未能从根本上解决问题。

复制代码

systemctl status graphical.target
systemctl unmask graphical.target

6. 检查target文件内容

直接查看 graphical.target 文件的内容，发现该文件内容为空。而空的 .target 文件无法被systemd正确解析，导致图形界面目标始终无法达成。

复制代码

cat /usr/lib/systemd/system/graphical.target

7. 配置网络并从正常机器拷贝文件

由于救援模式下网络接口默认未启用，需要先手动配置网络才能从同系统版本的正常机器上拷贝文件。与用户确认内网物理接口为 enp4s0f0 后，依次查看接口状态、激活接口、配置IP地址，并验证网络连通性。最后通过 scp 命令从正常机器拷贝完好的 graphical.target 文件。

复制代码

# 查看网络接口,物理接口均处于down的状态
ip a

# 确认内网使用的物理接口为enp4s0f0，查看接口状态为未激活，link detected:no
ethtool enp4s0f0

# 激活接口
ip link set enp4s0f0 up

# 配置IP地址（替换为实际的IP和掩码）
ifconfig enp4s0f0 <IP地址>/<子网掩码>

# 验证网络连通性
ping <正常机器IP>

# 从正常机器拷贝graphical.target文件（替换为实际的正常机器IP）
scp root@<正常机器IP>:/usr/lib/systemd/system/graphical.target /usr/lib/systemd/system/

8. 重载配置并尝试进入图形界面

文件拷贝完成后，需要重载systemd配置并尝试恢复图形界面。依次执行重载配置、解除屏蔽、重启目标以及切换界面的命令。但系统尝试进入图形界面后仍然失败，落入到了字符模式，说明 lightdm 服务未能正常启动。

复制代码

systemctl daemon-reload
systemctl unmask graphical.target
systemctl restart graphical.target
systemctl isolate graphical.target

9. 排查lightdm服务问题

在字符模式下输入账号密码，继续排查显示管理器问题。执行 systemctl status lightdm 命令，发现 lightdm 服务的状态同样被masked了。

复制代码

systemctl status lightdm

10. 检查lightdm.service文件

查看 lightdm.service 文件内容，发现该文件也被清空了，与前面 graphical.target 的情况一样。

复制代码

cat /usr/lib/systemd/system/lightdm.service

11. 从正常机器拷贝lightdm.service文件

由于字符模式下网络已经启动，无需再手动配置网络，直接从正常机器上将 lightdm.service 文件拷贝过来即可。

*#*替换为实际的正常机器IP

复制代码

scp root@<正常机器IP>:/usr/lib/systemd/system/lightdm.service /usr/lib/systemd/system/

12. 重载配置并重启lightdm服务

将文件拷贝完成后，再次重载systemd配置，解除 lightdm.service 的屏蔽状态，并重启该服务。

复制代码

systemctl daemon-reload
systemctl unmask lightdm.service
systemctl restart lightdm.service

13. 系统正常进入图形界面

完成上述操作后，系统成功进入了图形界面，能够正常登录进入系统桌面。

14. 重启验证

为了确保故障已排除，执行重启命令验证系统是否能正常进入图形界面。重启后确认能正常进入。

复制代码

reboot

15. 进一步排查日志问题

接下来排查之前发现的日志异常问题。date查看时间是准确的，同时检查/var/log/目录下的日志，发现多数日志最后一次轮转时间都是2025.7.13，/var/log/messages最近改动的时间是2025.7.14，可以确定日志记录服务有问题。进一步执行 systemctl status rsyslog 命令，发现系统中根本没有 rsyslog 这个服务。

复制代码

date
ls /var/log
stat /var/log/messages
systemctl status rsyslog

16. 追溯无法找到服务的原因

通过查看 dnf.log 日志相关记录，发现rsyslog服务在2025年7月14日被卸载。这解释了为什么 messages、secure 等日志在该日期之后停止写入。同时发现还有一些业务服务（如mariadb）以及系统组件（如fcitx）也在同一天被卸载。与用户核对后，确定去年7月中旬用户做过卸载业务的操作，猜测一些系统组件被误删或作为依赖被移除。

复制代码

cat /var/log/dnf.log | grep erase
cat /var/log/dnf.rpm.log

17. 安装缺失的系统组件

将缺失的系统组件重新安装回来，确保系统输入法能正常使用、日志能够正常写入和轮转。

复制代码

yum -y install fcitx
yum -y install rsyslog

【问题总结】

本次故障的原因是系统关键文件被清空：

graphical.target 文件被清空：导致systemd无法解析图形界面目标，系统开机黑屏。
lightdm.service 文件被清空：导致显示管理器无法启动，即使 graphical.target 恢复后仍无法进入图形界面。
rsyslog 服务被卸载：导致系统日志（messages、secure等）在2025年7月14日之后停止写入，增加了故障排查的难度。