简介：面向服务器运维与系统管理员，围绕银河麒麟高级服务器操作系统 V10 的日常维护场景，整理成册的常见问题速查手册。文档以解决方案和问题处理两大模块组织，涵盖本地 yum 源搭建、ftp/nfs/iscsi 服务配置、时间同步、kvm 安装、vnc 搭建、bond 与软 raid 创建、防火墙策略调整、密码复杂度配置等高频操作，并针对忘记服务器密码、系统激活、语言切换、ssh 连接异常、图形界面登录闪退、网络显示异常等实际故障提供排错思路，每项均按步骤说明，可读性与操作性俱佳。资源为单个 PDF 文件，压缩包大小 2.76MB，目录按场景划分、便于按需定位查阅，既适合新手逐步参考，也可作为团队内部运维文档的补充。已有 634 人次学习该文档，对于正在使用麒麟服务器或计划迁移到国产化系统的团队而言，是一份务实的问题速查参考。
1. 麒麟服务器和系统常见问题：先从一次“莫名其妙”的故障说起
一台银河麒麟 v10 的服务器，跑着跑着网卡“消失”了，重启以后ip a里只剩 lo。业务方催得急，我查了半小时才定位到是 NetworkManager 和 network.service 抢管理权。这样的场景在麒麟服务器上不是个例。国产化替代铺开之后，大量团队把旧 CentOS 上的运维经验直接搬过来，结果发现版本差异、包管理机制、硬件适配全都要重新摸索。这篇笔记就是把我在麒麟服务器和系统上反复踩过的常见问题、排查思路和能直接复现的修复命令整理出来，覆盖从版本选择到软件生态故障的完整路径。适合刚接手麒麟服务器的运维、做信创适配的研发，以及正在评估“麒麟能不能扛住生产环境”的团队。
2. 底层选型：版本差异、硬件匹配和不看架构就装包的代价
2.1 v10 SP1 与 SP2、通用版与专用版：同一个问题，不同版本解法不一样
麒麟 v10 不是一个“单一系统”。你从官网或渠道拿到的 ISO，可能是 SP1、SP2，也可能是面向飞腾、鲲鹏、龙芯等不同 CPU 的专用版。很多“通病”在不同版本上的表现和解法都不同。最常见的例子：SP2 升级了内核和 glibc 版本，某些在 SP1 上装得好好的离线软件包，拿到 SP2 上用dpkg -i安装，会报libsepol.so.1找不到或版本不兼容。
上机器第一件事，先确认版本信息：
cat /etc/kylin-release uname -a lscpu | grep Architecture在 x86_64 上能跑的 rpm/deb 包，拿到 aarch64（飞腾、鲲鹏）上大概率装不上。这不是麒麟的问题，是 ARM 和 x86 的二进制接口差异。所以处理问题前先看架构，再决定去哪找包。通用版 ISO 一般同时兼容 x86_64 和 aarch64，但系统里预装的软件源、内核参数会随平台不同有差异，网上搜到的教程如果没注明架构，照抄容易翻车。
版本还影响包管理器的行为。v10 早期版本更多使用yum，SP2 之后dnf成为默认，yum命令往往只是 dnf 的别名。这会导致一些旧文档里的参数失效。比如yum --disablerepo在 dnf 里还支持，但某些网络源的镜像路径写法已经变了。排查任何问题，先看/etc/os-release和/etc/yum.repos.d/下的源文件，别急着改配置。
2.2 硬件与内核：为什么换了个板卡，系统就进不去
麒麟服务器常见的硬件平台是飞腾（ARM64）和鲲鹏（ARM64），但不少团队是在 x86 服务器上先做测试。硬件相关故障里，我遇到最多的是两类：换显卡/板卡后图形界面起不来，以及 UEFI 与 Legacy 启动模式不匹配导致装完系统无法引导。
如果是 ARM 平台的点屏问题，常见做法是先加内核参数nomodeset看能不能进系统：
# 临时在 grub 启动项上追加 nomodeset，确认是否显卡驱动问题 # 编辑 /etc/default/grub，把 nomodeset 加到 GRUB_CMDLINE_LINUX 中 GRUB_CMDLINE_LINUX="nomodeset" # 生成新引导配置 grub2-mkconfig -o /boot/grub2/grub.cfgx86 平台上如果装完系统重启提示找不到引导，先检查固件是 UEFI 还是 Legacy。麒麟 v10 默认按 UEFI 安装，如果机器 BIOS 里开了 Legacy 模式，装完大概率起不来。反过来，BIOS 设为 UEFI 而引导盘是 MBR 分区表，也会黑屏。判断当前系统固件类型：
[ -d /sys/firmware/efi ] && echo "UEFI" || echo "Legacy"如果 UEFI/Legacy 不匹配，最简单是进 BIOS 改模式重装，不要试图用工具转换分区表，麒麟的引导链路对分区表格式很敏感，转换容易把启动分区搞坏。另外，新换硬盘后系统起不来，多摸一下是不是/etc/fstab里写了旧盘 UUID。麒麟对 UUID 不匹配的容忍度比 CentOS 低，挂载失败会直接进 emergency mode。
2.3 装系统前必做的三个检查：固件、文件系统与源
我经手的多数“装完就出问题”的案例，其实在安装界面就能提前避免。装系统前，花两分钟做三个检查：
# 1. 确认 CPU 架构，避免拿 x86_64 镜像装 ARM 机器 lscpu | grep Architecture # 2. 确认磁盘分区表类型，与 BIOS 启动模式匹配 fdisk -l /dev/sda | grep "Disklabel" # 3. 确认内存满足桌面环境最低要求（v10 图形化建议 4G 以上） free -h磁盘分区建议用默认的 LVM，后续扩容方便。生产环境我一般把/home独立分区，避免用户数据把根分区塞满导致系统假死。文件系统选 ext4 或 xfs 均可，xfs 在超大文件和高吞吐场景更稳，但注意 xfs 分区不能缩小，只能扩大。如果拿不准，ext4 是最不后悔的选择。
软件源在安装时就确认好，能省后面很多事。物理机安装时如果无法访问互联网，预先把 ISO 里的 Packages 目录拷到内网，或者直接指定本地光驱源。系统装完后的第一件事也应该是验证源可用，避免后面装任何软件都报错。
3. 服务与网络类故障：网卡不启动、时间漂移与软件源失效的处理
3.1 重启后网卡不启动：三条命令加一个持久化配置
“麒麟 v10 命令重启后为什么网卡不启动”是热搜词里的高频问题，也是我在生产环境遇到最多的第一类故障。现象很统一：手动配置完 IP，当时能通，一重启网络就没了，ip a里只剩 lo。
常见原因有两个：一是 NetworkManager 没有托管该网卡；二是/etc/sysconfig/network-scripts/ifcfg-ens33里写死了旧的 HWADDR，而网卡换了或虚拟机的 MAC 变了，导致配置对不上接口。
先按这个顺序排查：
# 查看网卡当前连接状态 nmcli dev status # 如果接口显示 unmanaged，说明 NetworkManager 没接管 # 设置连接为开机自启，并立即拉起 nmcli con mod ens33 connection.autoconnect yes nmcli con up ens33如果nmcli报错说找不到连接，说明 ifcfg 文件没被 NetworkManager 识别。常见做法是直接写配置文件：
cat /etc/sysconfig/network-scripts/ifcfg-ens33确保内容有这几项：
TYPE=Ethernet BOOTPROTO=static NAME=ens33 DEVICE=ens33 ONBOOT=yes IPADDR=192.168.1.20 PREFIX=24 GATEWAY=192.168.1.1 DNS1=114.114.114.114改完后执行systemctl restart NetworkManager。
这里有个重要的机制说明：麒麟 v10 同时装了 network.service 和 NetworkManager，两者如果都在启用状态，会抢网卡管理权。我的习惯是统一用 NetworkManager，把 network.service 停掉：
systemctl disable --now network.service systemctl enable --now NetworkManager.service停用 network.service 后，所有网络配置都由 NetworkManager 读取 ifcfg 文件，行为更可控，也避免“配置明明写对了，重启就丢”的问题。
3.2 时间同步失败：chrony 与国内时间服务器的配置参数
另一个高频问题是时间不同步。麒麟服务器在内网环境里跑着，业务日志时间对不上，有时差几分钟，有时差几个小时。最常见的表现是：date -R看到的时间标准和当前实际相差 8 小时，或者即使设了 chrony，chronyc tracking显示Leap status : Not synchronised。
原因是麒麟默认的 chrony 配置指向了官方时间服务器，在内网环境下根本访问不到。处理方法是改成国内时间服务器：
# 编辑 /etc/chrony.conf server ntp.aliyun.com iburst server ntp.tencent.com iburst # 允许本机局域网客户端同步（如需要） allow 192.168.0.0/16改完重启服务并验证：
systemctl restart chronyd chronyc sources -v chronyc tracking如果时间偏差已经很大（比如超过几分钟），chrony 默认不会直接大步跳变，需要手动校准：
chronyc makestep hwclock --systohchwclock --systohc这步很关键。很多系统重启后时间又变回去，是因为系统时间虽然改了，但硬件时钟（CMOS 里的 RTC）没更新。把系统时间写入硬件时钟，重启后才能保持。生产环境我还会加一条检查：
timedatectl set-local-rtc 0set-local-rtc 0表示硬件时钟使用 UTC 标准，系统启动时按北京时间换算。如果一台服务器上有双系统（比如 Windows 和麒麟共存），两套系统对 RTC 的时区处理不同，会出现反复横跳。这时候要么统一都设为 UTC，要么统一设为 localtime，二选一，不要两边都自动处理。
3.3 yum/dnf 源失效：软件源替换与 GPG 签名踩坑
在线源、离线源都可能导致yum install报错。典型的报错是Failed to download metadata for repo或Cannot retrieve metalink for repository: kylin_aarch64。这类问题的原因多半是源 URL 变了、镜像站不可达、或者 GPG 签名校验失败。
我处理内网服务器时，最稳的方案是做本地源。把 ISO 挂载出来，做成 file 协议源：
# 挂载麒麟 v10 安装镜像 mkdir -p /mnt/kylin mount -o loop /path/to/kylin-v10.iso /mnt/kylin # 备份原有源 mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak/ # 写新源 cat > /etc/yum.repos.d/local.repo <<'EOF' [kylin-local] name=Kylin Local Repo baseurl=file:///mnt/kylin enabled=1 gpgcheck=0 EOF # 验证源 dnf repolist说明一下参数：gpgcheck=0是为了跳过 GPG 签名校验，因为本地 ISO 是可信来源；如果是外网源，建议保留gpgcheck=1并导入公钥：
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-kylin很多人在线装包失败，不是源坏了，而是公钥没导入。报错信息里会带Public key for xxx.rpm is not installed。遇到这种情况，把报错里的 key URL 用rpm --import导入即可，不要一股脑把gpgcheck=0写上去，那会让服务器暴露在不可信源的风险里。
另一个坑是混用其他 Linux 发行版的源。有人图省事把 CentOS 的源指向麒麟，结果依赖解析时拉到了 glibc 或 systemd 的旧版本，把整个系统搞崩。麒麟的软件包是适配过自身内核和库版本的，混用 CentOS 源是最危险的误操作。记住一句话：麒麟的问题只用麒麟源解决，找不到的包去官网下离线 deb，不要跨发行版混源。
4. 软件生态类故障：装软件、Wine、字体和打印机的真实路径
4.1 银河麒麟安装软件命令：apt、dpkg 和留在官网的“离线包”
麒麟系统的包管理是 dpkg/apt 体系。这和 CentOS 的 rpm/yum 是两套完全不同的规则，从 CentOS 迁移过来的运维最容易在这里卡住。装软件有三个来源：
第一优先用 apt 在线安装：
sudo apt update sudo apt install nginx -y如果源里没有，再从官网下载离线 deb 包。安装时用dpkg -i，但经常遇到依赖问题：
sudo dpkg -i xxx.deb # 如果报依赖缺失，执行： sudo apt-get -f installapt-get -f install会自动修复破损的依赖关系，但前提是所需的依赖包能在当前源里找到。内网环境下依赖缺失最麻烦，我的做法是把依赖的 deb 包手动拷进去，逐个安装，别想着偷懒只敲一条命令。
判断一次安装是否成功，不要只看命令有没有报错，还要确认服务真正起来了：
dpkg -l | grep nginx systemctl status nginx --no-pager另外一个容易忽略的点：麒麟 v10 预装了“麒麟软件商店”，它的后端就是 apt。用户在图形界面点“安装”，实际执行的是 apt 的安装流程，日志在/var/log/apt/下。图形界面装不上时，切到终端直接跑 apt 看具体报错，往往比在商店里反复点更快。命令行输出比 GUI 弹窗信息量大多了，看到真正依赖哪个包缺失，再决定从哪补。
4.2 麒麟 Wine 助手：Windows 应用程序装上了却打不开的排查路径
麒麟生态不完整，有些 Windows 软件没有 Linux 版，只能用 Wine 跑。麒麟 v10 预装了“麒麟 Wine 助手”，本质是改了调用链的 Wine 环境。我见过很多“明明安装成功、双击却没反应”的案例，这里的原因一般不在 Wine 本身，而在运行库。
第一件要做的事，确认 Wine 容器是否完整：
# 检查已安装的 wine 版本 wine --version # 查看麒麟 Wine 助手的日志 ~/.kylinwine/logs/kylin-wine.log日志里常见的错误是wine: could not load kernel32.dll，这种情况多半是 32 位运行库缺失。麒麟 aarch64 版 Wine 对 32 位 Windows 程序的支持依赖 32 位系统库，装不上就会白屏或无响应。解决办法是补装 32 位运行库：
sudo apt install wine32 -y如果系统提示没有 wine32 包，可以手动配置 multiarch：
sudo dpkg --add-architecture i386 sudo apt update sudo apt install wine-i386Windows 程序双击没反应还有个常见玄学：文件权限不对。Wine 容器里的程序如果是在 root 账户下安装的，切到普通用户后可能无法访问容器，表现为点击图标无反应但进程里有 wine 在跑。处理方式是重新用当前用户安装，别共享 root 的.wine目录。
最后，如果 Wine 里跑的是 Office 或 CAD 类软件，优先检查字体。Windows 程序乱码或崩掉，往往只是缺少中文字体。从能用的 Windows 机器上拷贝simsun.ttc和msyh.ttc到~/.wine/drive_c/windows/Fonts/，再清一次字体缓存。
4.3 打印机扫描与字体乱码：驱动、IPP 协议和字体缓存三件事
“银河麒麟 v10 SP1 怎么安装打印机扫描”是热搜里的高频词。打印机问题是桌面环境里最消耗耐心的部分。麒麟自带的打印管理走的是 CUPS 体系，和大多数 Linux 发行版一致。设置里选“添加打印机”时，如果自动发现不到，不要手动输入型号，改用 IPP 协议直连：
ipp://打印机IP:631/ipp/print很多国产打印机品牌官网提供了 Linux 驱动，优先下官方 deb 包。下载后：
sudo dpkg -i printer_driver.deb sudo apt-get -f install sudo systemctl restart cups扫描功能的处理逻辑不同。扫描走的是 SANE 协议，麒麟自带的扫描软件是simple-scan。驱动装完后扫描仪还认不到，多半是缺少后端库：
sudo apt install sane-airscan字体问题则集中在“Windows 上传到麒麟的文件打开乱码”和“麒麟系统字体下载安装后不生效”。乱码百分之九十是中文字体缺失，安装字体后需要清缓存：
fc-cache -fv fc-list | grep "SimSun|微软雅黑|Noto Sans CJK"华为、飞腾这些平台还容易遇到一个现象：字体文件复制到/usr/share/fonts/后fc-list能看到，但应用里依然是方块。这是应用没重启、没有重新读取字体缓存。重启应用或注销重登即可，不需要反复重建缓存。
5. 避坑：看起来不是系统问题，却坑了半天的 5 个案例
5.1 现象：重启后网卡 MAC 地址变了，配置全失效
现象：虚拟化平台迁移虚拟机后，网卡名从 ens33 变成 ens38，原 ifcfg 文件全部作废，网络不通。
原因：麒麟的 udev 规则按 MAC 地址绑定网卡名。虚拟机迁移后虚拟网卡的 MAC 变了，规则匹配不上。
解决：删掉/etc/udev/rules.d/70-persistent-net.rules里旧 MAC 的行，重写 ifcfg 文件，NAME、DEVICE改成新的接口名，重启 NetworkManager。
5.2 现象：系统时间每次重启都漂移回过去
现象：date命令校完时间，当时显示正常，重启后又变回差 8 小时甚至几天前。
原因：只改了系统时间，没同步硬件时钟。麒麟默认硬件时钟按 UTC 处理，但某些国产主板的 RTC 在关机时仍写入本地时间，双系统环境下更混乱。
解决：执行hwclock --systohc，把当前系统时间写入硬件时钟。再用timedatectl确认RTC in local TZ: no或与否，根据实际环境固定一种策略，不要每次开机都靠 chrony 硬拉。
5.3 现象：软件源替换后报 GPG key 错误
现象：配置好本地源后执行dnf install，报Public key for xxx.rpm is not installed，即使gpgcheck=1也无法安装。
原因：本地源的 repo 文件里gpgkey指向外网公钥地址，内网环境下载不到。
解决：要么把公钥文件拷到本地并用rpm --import导入，要么在本地源上设gpgcheck=0。内网环境用本地 ISO 做源时gpgcheck=0是安全的，不建议在生产外网源上照抄。
5.4 现象：用 CentOS 的 rpm 包强制装进麒麟，把依赖搞崩了
现象：为了装某个工具，从 CentOS 仓库下了 rpm，用rpm -ivh --nodeps强制装上，随后yum和apt全部报依赖错误，系统里其他软件相继崩溃。
原因：CentOS 和麒麟虽然都是 Linux，但动态库版本和包管理数据库格式不同。强装 rpm 会把麒麟的 dpkg 数据库状态和系统库版本搞乱。
解决：不要混用发行版二进制包。如果必须用，先dpkg -l记录当前库版本，装完出问题后立即卸载，再用apt-get -f install修复。最保险的是去麒麟官网或源里找同名软件，找不到就换方案，别硬刚。
5.5 现象：systemd 服务报add: Invalid argument，服务起不来
现象：自己写的启动脚本在 CentOS 上跑得好好的，复制到麒麟上就报add: Invalid argument，服务状态显示 failed。
原因：脚本是 Windows 下编辑的，带有 CRLF 换行符。systemd 解析 ExecStart 时把\r当成参数尾带字符，导致参数错误。
解决：
sed -i 's/\r$//' /etc/systemd/system/xxx.service systemctl daemon-reload systemctl start xxx写服务文件时始终用 Linux 换行符。传文件时用dos2unix或直接在 Linux 下编辑，这是个小问题，但花过的人才知道有多扎心。
6. 进阶：把“麒麟系统修复助手”和基线检查做成开机自检
最后一章不写安装教程，写一个我每次交付麒麟服务器前都会做的事：用“麒麟系统修复助手”加一份简易基线检查脚本，把常见隐患在一次巡检中暴露出来。麒麟系统自带的“修复助手”是个图形化修复工具，能处理软件源异常、引导问题、网络配置错乱等常见故障。命令行层面，我更信任自己的脚本，因为基线检查的结果需要留档。
#!/bin/bash # kylin-health-check.sh # 检查麒麟服务器关键项，输出 PASS/WARN/FAIL echo "=== [1/5] 时间同步 ===" systemctl is-active chronyd >/dev/null 2>&1 && echo "PASS: chronyd is running" || echo "WARN: chronyd not active" echo "=== [2/5] 防火墙状态 ===" systemctl is-active firewalld >/dev/null 2>&1 && echo "PASS: firewalld running" || echo "WARN: firewalld disabled" echo "=== [3/5] SSH root 登录 ===" if grep -Eq '^PermitRootLogin\s+(yes|prohibit-password)' /etc/ssh/sshd_config; then echo "WARN: root login permitted" else echo "PASS: root login restricted" fi echo "=== [4/5] /boot 剩余空间 ===" BOOT_USE=$(df /boot | awk 'NR==2 {print $5}' | sed 's/%//') [ "$BOOT_USE" -lt 80 ] && echo "PASS: /boot usage $BOOT_USE%" || echo "FAIL: /boot usage high" echo "=== [5/5] 磁盘分区只读检测 ===" mount | grep -E 'on / .*ro' && echo "FAIL: root mounted read-only" || echo "PASS: root writable"这个脚本的价值在于把巡检固化成“售后交付前必跑一遍”的动作，而不是等出了问题再到处敲命令查状态。每台机器交付时把 stdout 重定向到/var/log/kylin-health-check.log，留档备查。后续出问题时，先看这份日志，比在聊天记录里翻聊天消息可靠得多。
我处理过一台数据库服务器，业务方反复报“日志时间错乱”，远程排查了半小时没结论，后来上机一看，chronyd 服务压根没启动。这台机器是同事安装时手动关了服务，之后就再没检查过。从那以后，我把这个脚本放进了系统安装后的“标准动作”清单，每次交付都跑一遍再签字。你也可以把这里的检查项扩展成自己的基线标准，比如加磁盘 IO、内存阈值、关键服务状态，但核心思路是一样的：把“常见问题”从被动排障变成主动巡检。
希望帮到你。
本文还有配套的精品资源，点击获取
