简介：面向运维人员与系统管理员的银河麒麟高级服务器操作系统V10 SP2常见问题手册，覆盖从系统安装配置、本地源搭建到服务部署的完整链路。资源以PDF格式提供，共1个文件，包大小2.76MB，内容包含ftp、内网源、nfs、ntp、snmp、iscsi等常用服务配置方案，以及进单用户方式、本地yum源搭建、bond创建、vnc搭建、软raid创建、防火墙管理等进阶操作指导。手册还针对系统安装失败、激活失效、忘记密码、ssh连接异常、图形界面闪退等高频疑难场景，给出分步骤的排查思路与具体命令，目录结构清晰，按解决方案和问题处理两个模块组织，便于快速查阅。目前已有634人学习下载。对正在使用或计划迁移至麒麟系统的运维工程师而言，手册能有效缩短问题定位时间，降低从传统服务器转向国产系统的试错成本，是一份即查即用的实用手册。
1. 麒麟服务器与系统常见问题排查：先分清版本再动手
接手一台报障的麒麟服务器，第一件事不是猜测“系统坏了”，而是先确认手里拿的到底是哪一版麒麟。银河麒麟V10的服务器版和桌面版、x86与ARM版，排障命令和软件包完全不是一套。我在实施现场反复踩过：重启后网卡不启动、yum 404、wine应用白屏、打印机服务掉线，这些都是高频问题，但大部分根因不是系统崩溃，而是版本没摸清就套用了CentOS的老经验。这篇把麒麟服务器和系统常见问题梳理成一套可复现的排查路径：先认版本、再配软件源，然后按网络、图形问题、虚拟化、打印逐项排。适合正在做麒麟适配、机房交付或系统加固的运维和交付工程师，照着命令走，能省一到两小时的误判时间。
2. 摸清系统底细：银河麒麟V10版本矩阵与软件源选型
2.1 银河麒麟V10版本矩阵：服务器版/桌面版、x86/ARM怎么选
银河麒麟V10是当前最常见的版本号，但它不是一个单一系统。按产品线分有服务器版和桌面版；按CPU架构分有x86_64和aarch64（飞腾、鲲鹏）版本。这两个维度的排列组合决定了软件包格式、内核参数和排障工具，互相之间的rpm包绝大多数不通用。
| 维度 | 区分方式 | 对排障的影响 |
|---|---|---|
| 产品线 | 服务器版 / 桌面版 | 服务器版默认不带图形桌面，软件源组成不同，很多桌面组件装不上 |
| CPU架构 | x86_64 / aarch64 | 包管理器按架构过滤，混用报“not compatible” |
| 大版本 | V10 / V10 SP1 / V10 SP2 | 内核版本和yum源配置差异，部分老SP源已下线 |
我见过最典型的翻车：把桌面版的安装包复制到服务器版上用dnf安装，结果依赖拉进来一堆X11库，系统环境被搞乱，最后只能重装。任何排障动作之前，先把版本信息打在屏幕上，至少不会跑偏。
2.2 用命令确认系统信息，拿到准确的软件包元数据
确认版本不靠肉眼，靠命令。以下四条命令在麒麟V10上都能跑，前两条是麒麟自带或定制的，后两条是通用排查：
# 发行版与版本号，确认是不是银河麒麟V10 cat /etc/os-release # 麒麟内核与版本信息工具，比 uname -r 显示更完整 nkvers # CPU 架构：x86_64 还是 aarch64，决定软件包源 uname -m # 当前内核版本 uname -rnkvers是银河麒麟特有的命令，输出里包含内核版本、操作系统版本、编译时间，比uname多出麒麟自己的构建标识。判定版本后再拉取软件源，命中率会高很多。uname -r要重点看是否有.kylin字样，这个标识直接说明内核是麒麟定制还是原版内核，定制内核在加载第三方驱动时容易遇到版本签名问题。实际操作里，把这几条命令的输出保存到本地，后续所有排查的基线都以它为准。
2.3 软件源配置：在线源、本地源与离线rpm包的三条路
麒麟V10服务器版（x86）继承了类RHEL8的仓库结构，分BaseOS和AppStream两个主仓库。在线装软件首选官方源，但内网环境往往访问不了外部源，最常见做法是挂载ISO做本地源，或者下载rpm包离线安装。选择顺序建议是：在线源 > 本地ISO源 > 离线rpm包。
# 本地源：挂载麒麟V10服务器版ISO mkdir -p /mnt/kylin mount -o loop /data/KylinV10-Server-2022.iso /mnt/kylin # 检查ISO目录结构，确认是 BaseOS/AppStream 还是 Packages 模式 ls /mnt/kylin # 生成本地仓库配置 cat > /etc/yum.repos.d/local.repo <<'EOF' [local] name=Kylin Local Repo baseurl=file:///mnt/kylin/BaseOS enabled=1 gpgcheck=0 EOF # 导入AppStream仓库 cat > /etc/yum.repos.d/local-appstream.repo <<'EOF' [local-appstream] name=Kylin Local AppStream baseurl=file:///mnt/kylin/AppStream enabled=1 gpgcheck=0 EOF # 清理缓存并确认仓库可识别 yum clean all && yum repolist这里的gpgcheck=0是内网本地源的标准做法，因为ISO自带介质完整性验证，关掉签名检查能避免内网环境里密钥未导入导致的public key not available报错。如果ISO目录名不是标准的BaseOS/AppStream，而是Packages，把baseurl改成file:///mnt/kylin/Packages。另外，各SP版本的ISO最好单独挂载，不要把SP1和SP2的包混进同一个仓库，yum会因依赖版本比对失败而陷入循环报错。
离线rpm包安装有个实用细节：yum install ./xxx.rpm会自动解析本地rpm的依赖并尝试从已启用的仓库补齐，比rpm -ivh更省心。在完全没有源的机器上，可以用yum localinstall配合--skip-broken，但别轻易加该参数，否则依赖缺失会在运行阶段才暴露。
3. 高频故障排查：网卡重启失联、修复助手、字体和时间同步
3.1 重启后网卡不启动：NetworkManager 与 ifcfg 的托管之争
麒麟V10服务器版安装完后，最常见的现象是配置静态IP写入/etc/sysconfig/network-scripts/ifcfg-ens*，重启机器后网络起不来。不少老工程师第一反应是改ONBOOT=yes，改完systemctl restart network，结果还是不生效。真实的坑在于NetworkManager与网络脚本的托管关系。
麒麟服务器版默认由NetworkManager管理网络设备，但ifcfg文件仍被读取。问题通常出在NM没有加载这个配置，或者连接名称与配置文件不匹配。优先用nmcli操作，尽量避免手改脚本：
# 查看设备当前托管状态 nmcli device status # 把设备设为由 NM 管理，防止"unmanaged"状态 nmcli device set ens33 managed yes # 修改现有连接为静态IP配置 nmcli connection modify ens33 ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 223.5.5.5 # 激活连接，这一步等效于老思路里的"重启网络" nmcli connection up ens33nmcli connection modify直接写进NM的connection配置文件，和ifcfg-ens33联动，比手工编辑更可靠。命令里的ipv4.dns按你所在网络的DNS改，内网环境务必先确认网关可达。排查时先跑nmcli device status，看到状态是unmanaged，就是NM没接管，按上述步骤执行即可。另外注意：麒麟桌面版的网络图标变灰、显示“未托管”，也是同一个原因。
3.2 麒麟系统修复助手：能用与不能用的边界
自带的“麒麟系统修复助手”在图形化系统的开始菜单里能找到，它在三类场景下确实有用：开机引导损坏（黑屏只到GRUB）、系统包依赖错乱、用户忘了重置root密码。但用它之前要搞清楚，它修复的是系统软件层面的问题，不是硬件问题也不是驱动兼容问题。磁盘坏道、固件故障、内核模块不匹配，修复助手只会提示“修复失败”，不会给你更多信息。
我一般把修复助手当作图形化入口，真正的排障用命令行收尾。引导修复的等效命令是这两条：
# 重建 initramfs，修复内核模块缺失导致的启动失败 dracut -f /boot/initramfs-$(uname -r).img $(uname -r) # 重写 GRUB2 配置并重装引导 grub2-mkconfig -o /boot/grub2/grub.cfg grub2-install /dev/sdadracut -f用于强制重建，适用于系统在内核升级后能进图形界面但某些服务模块加载失败的情形。grub2-install的目标磁盘是启动盘设备名，需要先用lsblk确认，填错会覆盖其他磁盘的引导区，这是真实踩过的现场事故。修复助手修完后如果重启依旧异常，检查/var/log/messages，报错里包含dracut字样时，回到命令行处理比反复点修复更高效。
3.3 字体下载安装与显示异常：中文字体失效怎么办
麒麟桌面版应用界面里的中文变成方块或者显示为乱码，多数是字体配置损坏或者中文字体包没有装全。老牌的“麒麟系统字体下载”需求对应的场景通常是：用户拷贝Windows下的宋体/黑体文件到麒麟，结果放了.ttc格式。麒麟基于fontconfig，能读ttf/otf，对ttc的兼容性视应用而定，装完还是方块，不代表系统坏了。
# 看当前系统可用的中文字体，确认问题是不是缺字体 fc-list :lang=zh | head # 建立字体目录并拷贝字体文件（支持 wqy、Noto、思源黑体） mkdir -p /usr/share/fonts/chinese cp ./SourceHanSansCN-Regular.otf /usr/share/fonts/chinese/ # 重建字体缓存，让 fontconfig 识别新字体 fc-cache -fv /usr/share/fonts/chinese # 验证字体是否成功注册 fc-list | grep -i sourcehanfc-cache -fv的-f是强制刷新缓存，-v输出详细过程，正常会看到“fc-cache: succeeded”字样。字体文件权限必须是644、目录权限755，权限不对时会静默跳过，不报错，这是典型的“命令执行成功但没效果”的原因。如果下载的是.otf，注意较老的Qt4应用会无法识别，优先使用.ttf格式。字体问题排查的最后一步，是重启桌面会话而不是重启系统，killall gnome-shell或注销重登，避免解释成本。
3.4 时间不同步引发的登录与证书问题：改用国内时间服务器
麒麟服务器加入AD域、执行等保基线检查、或访问HTTPS接口时，系统时间偏差超过30秒就会出现莫名其妙的“登录失败”“证书无效”。这个问题伪装性强，因为报错指向认证、指向证书，但根因是NTP没配。麒麟默认时间同步服务是chronyd，配置文件在/etc/chrony.conf。
# 编辑时区与时间同步配置 vim /etc/chrony.conf # 把默认的 pool 注释掉，换成国内可达的NTP服务器 server ntp.aliyun.com iburst server ntp.tencent.com iburst # 重启时间同步服务并验证 systemctl restart chronyd chronyc sources -v配置里的iburst参数很关键，表示首轮同步前发送8个快速请求，能明显缩短启动后的同步时间。chronyc sources -v输出中，^*前缀表示该源已成功同步，^?表示不可达。内网隔离环境没有外网访问权限时，改成指向内网时间服务器地址，配置格式不变。这里有一个追加注意点：虚拟机托管在VMware或KVM宿主机上时，关掉宿主机的“主机时间同步”选项，否则chronyd和宿主要求会来回踢，出现时间每周反复跳变。判断是否跳变，看timedatectl status里System clock synchronized字段。
4. 服务器专项场景：虚拟机管理系统、打印服务与跨系统传文件
4.1 银河麒麟虚拟机管理系统：用 virt-install 创建一台麒麟虚拟机
麒麟服务器上跑虚拟化，常见方案是KVM配合自带的虚拟机管理系统。宿主机的CPU虚拟化标志要先确认，否则建出来的虚拟机迁不迁嵌入式均为无解。确认命令是grep -Eoc '(vmx|svm)' /proc/cpuinfo，输出为0说明BIOS没开虚拟化，或者CPU不支持。
# 安装KVM相关组件，麒麟V10服务器版预装不全时需要补装 yum install qemu-kvm libvirt virt-install virt-manager -y # 启用并启动libvirtd服务 systemctl enable --now libvirtd # 创建一台名为 kylin-vm 的虚拟机，安装源为本地ISO virt-install \ --name kylin-vm \ --vcpus 4 \ --memory 8192 \ --disk path=/data/vms/kylin-vm.qcow2,size=100,format=qcow2 \ --location /data/KylinV10-Desktop-2022.iso \ --os-variant centos8 \ --network bridge=br0 \ --graphics vnc \ --noautoconsole--vcpus和--memory按宿主机实际资源调整，分配过大反而造成宿主机swap占用。--disk path指定qcow2镜像路径及其容量，format=qcow2明确镜像格式，避免与其他工具互认时产生歧义。--os-variant centos8是ARM麒麟服务器版上用不了，x86_64版本用它是兼容性最稳妥的选项。--location也可以填http源，但内网建议本地ISO。创建后virsh list --all能看到虚拟机状态，virsh console kylin-vm进文本控制台。网络方面优先用virtio网卡模型，性能更好，安装RHEL类系统会自动加载驱动。
4.2 打印服务：驱动安装与“系统打印服务已关闭”排障
打印机在麒麟桌面和服务器上都是重灾区。报“系统打印服务已关闭”，本质是CUPS服务没有运行或运行后异常退出。先看服务状态，再翻日志，顺序不要反。
# 打印服务状态，确认 active 还是 failed systemctl status cups # 打印服务实际上由套接字激活，先看监听端口 ss -lntp | grep 631 # 安装打印机驱动，优先用厂商提供的麒麟版rpm yum install ./hplip-3.22.10-1.x86_64.rpm # 重启并确认状态 systemctl restart cups systemctl status cupsss -lntp | grep 631这一步很多人跳过。CUPS的默认监听端口是631，服务显示正在运行但端口没监听，表明绑定失败，多半是IPv6/IPv4双栈冲突或/etc/cups/cupsd.conf中Listen行被注释。安装驱动后建议跑lpinfo -v，列出所有可用的打印机驱动和后端，确认USB网络打印机是否被识别。如果lpinfo输出里没有socket://或usb://条目，说明驱动后端没装上，重装驱动包比重启服务有效。驱动装好后用lpadmin添加远程打印机，地址格式socket://192.168.1.20:9100，-m指定PPD文件，就不细展开了。
4.3 与 Windows 互传文件：麒麟系统里照片打不开的真实原因
“照片在麒麟系统网传后打不开”是典型跨平台故障，问题不一定出在麒麟上。最常见的原因有三个：传输过程中文件损坏、文件格式被改名、文件路径里的中文编码错乱。先看真实文件格式，再做决定。
# 用 file 命令识别真实类型，不被扩展名迷惑 file /mnt/share/IMG_001.jpg # 挂载Windows共享目录时指定编码和SMB版本 mount -t cifs //192.168.1.10/share /mnt/share \ -o username=user,password=pass,vers=3.0,iocharset=utf8file输出的信息里会标明JPEG/HEIC/PNG。如果显示HEIC，而麒麟默认看图器不支持，转成JPEG再打开，别直接改扩展名。iocharset=utf8能让中文文件名在挂载后正常显示，避免“找不到文件”的假象。跨平台传输还有一个隐藏坑：Windows端传到麒麟时把文件放到了带空格或超长目录路径里，麒麟图形界面能看见，命令行Perl脚本常规处理会出问题，用小工具smbclient远程取文件反而能避开挂载限制。实际工作中，我通常在麒麟端用samba-client直连Windows共享，将文件复制到本地后再用file验证，不直接双击打开共享目录里的文件。
5. 麒麟服务器避坑清单：五个常见问题的踩坑记录
5.1 yum install 报 404：仓库源过期不是包不存在
现象：执行yum install httpd报错，提示Error: Failed to download metadata for repo 'appstream'，或者404。很多新手以为是软件包被删除了，反复去换镜像源。
原因：麒麟V10的官方在线源在特定SP版本停止支持后会被下线，旧仓库地址失效。也可能是本地ISO源挂载目录被卸载，仓库配置里还有残留记录。
解决：先跑yum repolist，确认repo数量与名称；再跑yum clean all清缓存，排除元数据缓存问题。仓库失效时，/etc/yum.repos.d/下指向旧版本的repo文件要替换为可用的新源或本地源，不要用CentOS源直接替换。麒麟源结构是RHEL8风格，但内部包的版本混合了麒麟定制内容，CentOS源会导致依赖冲突。这条是麒麟运维里代价最高的一课，重装系统的成本远大于细看一眼仓库配置。
5.2 虚拟机里装完麒麟网络不通：网卡类型选错
现象：在VMware或OpenStack里新建了一台麒麟V10虚拟机，安装界面里网络是通的，装完之后IP地址无法获取，ip addr看不到网卡或有网卡没IP。
原因：虚拟机模板默认使用e1000网卡，但部分麒麟内核构建时未包含e1000驱动，导致安装完成后网卡设备丢失。也可能是在创建虚拟机时未选择“桥接模式”，虚拟机只能NAT上网，DHCP获取失败。
解决：在宿主机平台上把虚拟机网卡类型改为virtio，重启虚拟机后ip addr能看到eth0。如果virtio驱动也没加载，尝试加载内核模块：
modprobe virtio_net echo virtio_net > /etc/modules-load.d/virtio_net.conf如果是VMware环境，把网络适配器从e1000改为VMXNET3并重装VMware Tools，麒麟V10对VMXNET3驱动支持更好。记住：虚拟机里装麒麟，网卡优先用paravirtualized类型，别用模拟设备。
5.3 网卡配置好重启失效：ONBOOT 与 NetworkManager 冲突
现象：手动编辑ifcfg-ens33把ONBOOT=yes，然后systemctl restart network后网络正常，但重启服务器后又失联，需要进控制台手动ifup才能恢复。
原因：麒麟V10服务器版默认由NetworkManager管理网络，systemctl restart network只是临时生效，NetworkManager启动后重新接管并以自己的连接配置为准。而NM的connection配置与ifcfg-ens33字段对应性不强，NM启动时没找到匹配连接，设备变成unmanaged或down。
解决：不要再用旧习惯改ifcfg，全部改用nmcli：
# 列出连接，确认名称后修改 nmcli connection show # 修改连接的ONBOOT等效参数，并设置自动连接 nmcli connection modify ens33 connection.autoconnect yes # 保存并激活 nmcli connection up ens33改完之后验证：systemctl status NetworkManager确认NM是主导服务，然后reboot测试，不要偷懒只重启网络服务。生产环境里这块必须重启验证，否则等于把隐患留给明天。
5.4 打印机驱动装好服务挂了：cups 的启动顺序与权限
现象：打印机驱动安装完成后，执行systemctl restart cups，服务状态显示failed，再启动打印任务无响应，客户端报“系统打印服务已关闭”。
原因：安装驱动rpm包时，自动往/usr/lib/cups/filter和/usr/lib/cups/backend写入了动态库，但动态库依赖的某个库版本不对，CUPS启动时加载驱动动态库失败。另一个原因是服务启动时对USB设备权限不足，udev规则未及时刷新。
解决：先看CUPS错误日志：
tail -n 50 /var/log/cups/error_log journalctl -u cups --no-pager -n 50日志里出现Unable to load driver时，补装对应的依赖库。USB打印机出现Permission denied时：
systemctl restart systemd-udevd systemctl restart cups规则的优先级：先确认驱动与系统版本匹配，再查udev权限，最后才考虑重新安装。直接重装驱动包解决不了库依赖问题，只会重复报错。
5.5 wine 助手装完应用白屏：缺 32 位库与内核版本不符
现象：用麒麟的wine助手安装了Windows应用（如旧版办公软件），打开后窗口白屏或闪退，没有任何错误弹窗。
原因：wine运行32位应用需要系统有32位库支持，麒麟V10服务器版默认不装i686运行库。另外wine的图形渲染依赖OpenGL，部分图形驱动下wine窗口输出异常。
解决：先看wine的位数和依赖：
# 确认当前wine是否支持32位 wine --version # 安装32位运行库，麒麟源里有兼容i686的包 yum install glibc.i686 libX11.i686 mesa-libGL.i686 -y安装完成后运行winecfg，在Libraries页签确认库加载是否正常。白屏问题多出在显卡驱动上，把桌面切换成Xorg模式而不是Wayland模式能规避一部分渲染异常。wine排障的另一个有效手段是设置WINEPREFIX后重新初始化，去掉旧的环境缓存：
WINEPREFIX=/root/wine-env1 wineboot -uwine应用能不能跑，取决于应用的运行库复杂程度。麒麟wine助手能解决一部分，但复杂应用依然建议改用原生Linux版本或找厂商的适配版，这条经验是用几次现场加班的代价换来的。
6. 把排障经验固化成巡检脚本：基线检查与批量验证
做到这一步，单台机器的故障基本能覆盖。接下来要解决的是“怎么证明这些配置在几十台机器上都是对的”。这个阶段我的习惯是写一个巡检脚本，把版本信息、仓库状态、服务状态、磁盘水位一次打印，配上SSH批量执行，比一台台登录效率高很多。
#!/bin/bash # kylin_check.sh 银河麒麟服务器巡检，用法：bash kylin_check.sh echo "===== OS 版本 =====" grep -E "PRETTY_NAME|VERSION_ID" /etc/os-release echo "===== 系统时间与同步 =====" timedatectl status | grep -E "synchronized|Time zone" echo "===== 仓库状态 =====" yum repolist | tail -n 5 echo "===== 关键服务状态 =====" for svc in NetworkManager chronyd cups libvirtd sshd; do state=$(systemctl is-active $svc) if [ "$state" = "active" ]; then echo "$svc: OK" else echo "$svc: FAIL($state)" fi done echo "===== 磁盘使用率 =====" df -h | grep -v tmpfs echo "===== 空口令账户检查 =====" awk -F: '($2==""){print "空口令: "$1}' /etc/shadow echo "===== SSH 安全基线 =====" grep -E "^PermitRootLogin|^PasswordAuthentication" /etc/ssh/sshd_config脚本里的awk -F: '($2==""){print}'是基线检查里最直接的探测空口令方法，密码不为空时字段2是加密串，为空则说明账户无口令。sshd_config检查只是粗筛，生产环境还要看MaxAuthTries和AllowUsers。这个脚本配合for host in $(cat hosts); do ssh $host bash -s < kylin_check.sh; done能完成小批量机器巡检，机器多时换Ansible托管的ansible all -m script。
我现在拿到任何一台麒麟服务器，第一件事永远是那三条命令：cat /etc/os-release、nkvers、yum repolist。这个习惯是在一次误判整晚、最后发现是仓库源失效的现场被逼出来的。巡检脚本本身不复杂，但坚持用之后，把“等故障来了再排查”变成了“定期确认环境不变”，很多问题在影响业务前就暴露了。对新接手的环境，先跑一遍脚本留个基线存档，后面再用diff对比变化，是最省心的运维方式。希望这些经验帮到你。
本文还有配套的精品资源，点击获取
