【问题现象】银河麒麟V10服务器系统开机后过了麒麟Logo画面后黑屏仅屏幕左上角有一个短横杠光标不停闪烁无法正常进入系统。【排查和修复过程】1. 开启调试日志为了获取更多的启动日志信息需要在GRUB引导菜单中开启调试日志。通过编辑内核启动参数追加调试选项并移除静默启动参数可以让系统在启动时输出详细的日志。# 在选择内核时按字母e进入GRUB编辑界面找到linux行在末尾追加以下参数#同时删除splash和quiet参数如果有的话按ctrlx启动consoletty0 loglevel7 systemd.log_leveldebug2. 系统落入救援模式添加上述参数后启动系统发现系统因无法正常启动而落入了救援模式rescue mode。# 在Control-D行后输入root用户的密码即可进入救援模式提供的命令行密码的输入是不显示的确认输入正确后回车即可3. 检查传统日志文件进入救援模式后首先检查了传统的系统日志文件 dmesg 和 /var/log/messages但均未发现与本次故障相关的有用信息。同时注意到一个异常现象/var/log/messages 中最近的日志时间停留在2015.07.14明显不正常。该问题留待后续进一步排查。dmesg cat /var/log/messages4. 通过journalctl定位错误由于传统日志未能提供有效线索使用 journalctl 命令查看本次启动以来的所有error级别日志。通过该命令发现了关键报错graphical.target 处于masked屏蔽状态导致图形界面无法启动。journalctl -xb -p err --no-pager5. 尝试unmask无效通过 systemctl status 确认graphical.target 确实处于masked状态。随后尝试执行 systemctl unmask 命令解除屏蔽但问题依旧存在说明简单的unmask操作未能从根本上解决问题。systemctl status graphical.target systemctl unmask graphical.target6. 检查target文件内容直接查看 graphical.target 文件的内容发现该文件内容为空。而空的 .target 文件无法被systemd正确解析导致图形界面目标始终无法达成。cat /usr/lib/systemd/system/graphical.target7. 配置网络并从正常机器拷贝文件由于救援模式下网络接口默认未启用需要先手动配置网络才能从同系统版本的正常机器上拷贝文件。与用户确认内网物理接口为 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.target9. 排查lightdm服务问题在字符模式下输入账号密码继续排查显示管理器问题。执行 systemctl status lightdm 命令发现 lightdm 服务的状态同样被masked了。systemctl status lightdm10. 检查lightdm.service文件查看 lightdm.service 文件内容发现该文件也被清空了与前面 graphical.target 的情况一样。cat /usr/lib/systemd/system/lightdm.service11. 从正常机器拷贝lightdm.service文件由于字符模式下网络已经启动无需再手动配置网络直接从正常机器上将 lightdm.service 文件拷贝过来即可。#替换为实际的正常机器IPscp 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.service13. 系统正常进入图形界面完成上述操作后系统成功进入了图形界面能够正常登录进入系统桌面。14. 重启验证为了确保故障已排除执行重启命令验证系统是否能正常进入图形界面。重启后确认能正常进入。reboot15. 进一步排查日志问题接下来排查之前发现的日志异常问题。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 rsyslog16. 追溯无法找到服务的原因通过查看 dnf.log 日志相关记录发现rsyslog服务在2025年7月14日被卸载。这解释了为什么 messages、secure 等日志在该日期之后停止写入。同时发现还有一些业务服务如mariadb以及系统组件如fcitx也在同一天被卸载。与用户核对后确定去年7月中旬用户做过卸载业务的操作猜测一些系统组件被误删或作为依赖被移除。cat /var/log/dnf.log | grep erase cat /var/log/dnf.rpm.log17. 安装缺失的系统组件将缺失的系统组件重新安装回来确保系统输入法能正常使用、日志能够正常写入和轮转。yum -y install fcitx yum -y install rsyslog【问题总结】本次故障的原因是系统关键文件被清空graphical.target文件被清空导致systemd无法解析图形界面目标系统开机黑屏。lightdm.service文件被清空导致显示管理器无法启动即使 graphical.target 恢复后仍无法进入图形界面。rsyslog服务被卸载导致系统日志messages、secure等在2025年7月14日之后停止写入增加了故障排查的难度。