【问题现象】
银河麒麟V10服务器系统开机后，过了麒麟Logo画面后黑屏，仅屏幕左上角有一个短横杠（光标）不停闪烁，无法正常进入系统。
【排查和修复过程】
1. 开启调试日志
为了获取更多的启动日志信息，需要在GRUB引导菜单中开启调试日志。通过编辑内核启动参数，追加调试选项并移除静默启动参数，可以让系统在启动时输出详细的日志。
# 在选择内核时按字母e进入GRUB编辑界面，找到linux行，在末尾追加以下参数
#同时删除splash和quiet参数（如果有的话），按ctrl+x启动
console=tty0 loglevel=7 systemd.log_level=debug2. 系统落入救援模式
添加上述参数后启动系统，发现系统因无法正常启动而落入了救援模式（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 文件拷贝过来即可。
#替换为实际的正常机器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.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日之后停止写入，增加了故障排查的难度。
