ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

麒麟系统命令行更新指南:从apt到内核维护的完整实践

麒麟系统命令行更新指南:从apt到内核维护的完整实践 1. 为什么我坚持用命令行更新麒麟系统用鼠标点开图形化的更新管理器等进度条跑完看似是最省事的路子但真在生产环境里维护过一批麒麟系统之后我越来越倾向打开终端敲命令。不是说图形界面不能用而是命令行带来的可控性和出错后的可诊断性是图形工具给不了的。举一个很真实的场景我维护的一台麒麟 V10 服务器某天例行更新时图形更新工具卡在“正在检查软件包”就不动了点哪儿都没反应连取消按钮都是死的。我切换到命令行执行ps aux一看后台的 apt 进程已经把 dpkg 锁拿住了图形工具傻等锁释放自己却没有输出任何有效日志。这种时候你根本不知道它卡在哪一步只能干瞪眼。换做命令行同样的情况可以做到完全透明每一步执行了什么、从哪个源拉取、哪些包需要升级、依赖是否冲突终端里都会一条条打出来。就算中间出了错错误码也能直接告诉我们下一步往哪个方向查。另一个更实际的场景是很多机房里的麒麟服务器根本没有接显示器管理员全程靠 SSH 登上去操作这种情况下图形更新工具连打开的机会都没有命令行是唯一的通道。如果你是刚接触麒麟系统不久、之前习惯用 Windows 或桌面化 Linux 的开发者这篇文章就是写给你的我会从最基础的版本确认开始一直到更新失败后的完整排查链路全部基于我自己在实际环境中用命令行维护银河麒麟系统的经验尽量做到每一步都有依据、有说法不只是扔几条命令给你复制。2. 动手之前先确认三件事别急着敲命令很多人在终端里出问题不是因为命令敲错了而是压根没搞清楚自己面前这台麒麟系统属于哪个分支、什么架构、软件源是什么状态。这三个基础信息没确认后面执行任何更新命令都有可能南辕北辙。2.1 确认发行版分支和版本号麒麟不是一个“版本号”能概括的麒麟系统在市面上最常见的两个系列一个是银河麒麟Kylin一个是中标麒麟NeoKylin其中银河麒麟又分桌面版和服务器版不同版本锁定的包管理方式也略有差异。我见过不少人拿网上随便搜来的命令去跑结果系统反馈“找不到命令”或者“没有可用的软件包”原因往往就是版本搞混了。在终端里执行这几条命令先把家底摸清楚cat /etc/os-release这是最直接的输出里会写明系统的 NAME、VERSION、ID 等信息。以银河麒麟 V10 桌面版为例输出可能类似NAMEKylin VERSIONV10 IDkylin VERSION_IDV10再配合麒麟特有的内核发布说明命令可以拿到更细节的内核和系统构建信息nkversnkvers是麒麟系统自带的小工具会打印操作系统发布版本、内核版本、硬件平台等一串信息执行完你就能对自己的系统有一个整体判断。2.2 确认 CPU 架构避免更新包对不上号这一步非常容易忽略但对麒麟系统来说又特别重要。因为麒麟同时支持 x86、ARM鲲鹏/飞腾、龙芯、申威等多种架构不同架构的软件源和二进制包是完全不一样的。我遇到过一位同事在一台飞腾 ARM 处理器的主机上照搬 x86 架构的配置去配软件源结果apt update之后一堆 404 报错软件包列表刷不出来。在终端里看一眼架构uname -mx86_64 表示 Intel/AMD 的 64 位架构aarch64 表示 ARM 64 位架构如鲲鹏、飞腾mips64el 对应龙芯sw_64 对应申威确认架构之后再去核对软件源地址中的架构路径是否匹配就基本不会踩这个坑。2.3 检查软件源状态擅自换 Ubuntu 源等于给自己挖坑麒麟 V10 桌面版的底层确实和 Ubuntu 有很深的血缘关系默认的 apt 软件源也是从/etc/apt/sources.list和/etc/apt/sources.list.d/目录读取的。但要特别注意麒麟定制过的软件包和 Ubuntu 官方仓库的版本号体系并不完全一致盲目把软件源改成 Ubuntu 源短时间可能看不出问题一段时间后执行apt upgrade时极容易出现依赖关系崩溃。正确做法是先查看当前软件源确认有没有被人为改动过。cat /etc/apt/sources.list ls /etc/apt/sources.list.d/正常的麒麟系统默认源指向的是麒麟官方仓库或授权镜像站域名里一般带有kylinos字样。如果发现源地址已经被改成某个陌生域名或者明显是 Ubuntu 官方源建议在更新前先改回麒麟官方源。服务器版的麒麟 V10 有的采用了 yum/dnf 体系软件源位置在/etc/yum.repos.d/目录下查看方式类似。ls /etc/yum.repos.d/这一步花不了两分钟但能避免后面更新过程中出现大量莫名其妙的 404 和依赖报错。我一直把它当作更新前的固定检查项。3. 麒麟系统命令行更新的标准流程确认完系统版本、架构、软件源状态就可以进入正式更新流程了。这里我以最普遍的 apt 体系的银河麒麟桌面/服务器版为例完整梳理一遍我日常执行的标准流程每一步都会说明命令在做什么、为什么要分步走。3.1 第一步sudo apt update 到底在做什么sudo apt update这条命令的真正作用是刷新软件源索引也就是让系统重新拉取软件仓库里的包列表本地并不做任何软件包的升级操作。它会对比本地缓存的 Packages 文件与远端仓库的版本把最新的可用软件包信息同步下来。很多新手把apt update和apt upgrade当成一回事这是最常见的误解。update只是更新索引upgrade才是真正执行升级。记住一个类比update像你打开外卖 App 刷新商家列表upgrade才是真正下单把菜送到家。执行完apt update注意观察结尾部分的输出。正常情况下会显示Reading package lists... Done如果某个源连接失败会明文提示Failed to fetch并给出具体的 URL 和错误原因这就是排查的信号。3.2 第二步先看再动用 apt list --upgradable 做体检更新索引之后先别急着升级先用这条命令看看当前系统里有多少软件包可以升级apt list --upgradable输出会列出所有可升级的软件包及新版本号。这一步的目的有两个一是心里有数知道这次更新涉及的包范围有多大二是提前发现异常比如某些不应该频繁升级的系统底层包突然出现了大版本跳跃就需要留意是不是软件源出了问题。我习惯把这些可升级包扫一遍关注点主要放在内核相关包linux-image 开头、系统库libc、ssl 等和当前正在用的核心服务上。如果这些包的变化幅度超出了预期我会先查清楚原因再继续。3.3 第三步apt upgrade 和 full-upgrade 的差别以及我推荐的命令组合常规升级执行sudo apt upgrade这条命令会把所有已安装软件包升级到软件源里的最新版本但有一个重要原则它不会主动安装新依赖包或者移除已安装的包。也就是说如果某个升级需要额外安装一个新依赖而当前系统里没有apt upgrade会跳过这个软件包的升级把它留在“被保留”的状态。那什么时候用full-upgrade旧命令写法是dist-upgradesudo apt full-upgradefull-upgrade会在升级过程中更激进地处理依赖关系必要时会自动安装新依赖包也会自动移除与新版本冲突的旧包。连续跨版本升级、或者遇到大量软件包版本跳跃时full-upgrade的成功率更高但带来的动作也更大那些自动移除的包如果没有心理预期容易被吓一跳。我个人的推荐组合是日常更新走apt upgrade输出信息干净动作克制够用遇到长时间没更过、版本滞后很多的系统直接用apt full-upgrade一次性把依赖理顺。还有一种情况要用到apt --with-new-pkgs upgrade它会在有限范围内允许安装新的必要依赖适合那种只想升级又不想太激进的中庸场景。3.4 第四步服务器版麒麟的 yum/dnf 更新命令如果你的麒麟 V10 服务器版走的是 RPM 体系更新命令则是另一套sudo yum update或者新版系统使用 dnfsudo dnf updateyum/dnf 体系和 apt 最大的差异在于它默认的update命令已经包含了依赖解析和必要的安装/移除动作一条命令基本能覆盖日常更新需求。执行前也可以用yum check-update先列出可更新的包类似前面说的apt list --upgradable。3.5 更新完一定要重启并确认关键服务状态很多人跑完更新就以为万事大吉了其实内核升级、系统库升级往往需要重启才能真正生效。更新完成后的重启和状态确认我建议遵循这样的顺序sudo systemctl reboot重启后先确认内核版本是否符合预期uname -r再检查关键服务是否正常运行比如 sshd、数据库等systemctl status sshd systemctl status mysqld这一步看似多余但确实有系统更新后某些服务因为依赖库版本变化而启动失败的案例。服务状态确认没问题这次系统更新才算真正走完。4. 更新中翻车的四个高频场景和完整排查链路命令行更新最大的价值体现在出错的时候。这里我把这几年维护麒麟系统踩过的高频坑整理一遍每一条都附上完整的排查思路不直接跳过过程给结论。4.1 dpkg 锁错误多半是残留进程但也可能是无人值守更新在跑执行sudo apt upgrade时终端突然弹出这类报错是最常见的高频问题E: 无法获得锁 /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: 无法锁定管理目录(/var/lib/dpkg/)是否有其他进程正占用它原因很好理解同时有两个进程想操作 dpkg 数据库系统只允许一个持有锁。我的排查链路是这样的第一步看是哪个进程占用了锁ps aux | grep -i apt如果发现有残留的apt或dpkg进程卡在那里优先让它自己结束等几秒钟再用ps确认。如果进程已经僵死再考虑杀掉sudo kill -9 进程PID第二步排查是不是 unattended-upgrades 无人值守更新在后台自动运行。麒麟系统默认可能启用了这个服务它会在后台悄悄执行安全更新这个过程中你再去跑apt upgrade就会撞锁。看它的状态systemctl status unattended-upgrades如果确实在运行要么等它跑完要么临时停掉服务再继续手动更新sudo systemctl stop unattended-upgrades处理完锁建议顺手清理一下可能残留的锁文件。但要记住直接删除锁文件是下策只有在确认没有任何 apt/dpkg 进程在跑的情况下才建议这么做sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/apt/lists/lock sudo rm /var/cache/apt/archives/lock4.2 依赖关系崩了--fix-broken 与 dpkg --configure -a 的正确顺序更新过程中如果中途断电、网络断开、或者手动杀掉了 apt 进程最容易出现一类后续症状再执行任何 apt 操作时提示你“有损坏的软件包”或者“依赖关系不满足”典型报错是You might want to run apt --fix-broken install to correct these.遇到这种情况不要慌也不用重装系统按顺序执行两步操作第一步先修 dpkg 的配置状态。很多依赖错误的根源是更新中断后某些包停留在“半配置”状态sudo dpkg --configure -a第二步让 apt 自己修复损坏的依赖关系sudo apt --fix-broken install这两条命令的执行顺序是有讲究的。dpkg --configure -a是先把残留的半配置状态理顺让 dpkg 数据库回到一个能被 apt 正常读取的状态然后apt --fix-broken install才能在此基础上解析并安装缺失的依赖、移除冲突的包。修完之后再看一眼有没有残留的rc状态包。rc表示包已经删除但配置文件残留在系统里一般不影响更新但会影响洁癖。可以这样查看并清理dpkg -l | grep ^rc sudo dpkg -P $(dpkg -l | grep ^rc | awk {print $2})4.3 软件源慢到像死机超时处理与镜像切换的正确姿势麒麟系统默认的软件源在某些网络环境下访问速度很慢apt update卡在某个源半天不动很容易让人误以为系统死机了。我的经验是先判断是整体慢还是个别源慢sudo apt update -o Acquire::http::Timeout10 -o Acquire::Retries0这里给 apt 设置了超时上限和重试次数如果某些源超过 10 秒连不上就直接跳过并报错整个更新流程不会被一个慢源拖死。这只是排查手段定位到具体是哪个源慢之后更好的解决方案是更换为更快的镜像源。以银河麒麟 V10 桌面版为例可以编辑/etc/apt/sources.list把默认源地址替换成访问更快的镜像站。这里有一个关键原则优先使用麒麟官方镜像或者明确标注支持麒麟系统的镜像站。直接拿 Ubuntu 的源来用我在第二节已经说过是给自己挖坑。切换源之后别忘了重新执行sudo apt update确认索引刷新成功后再升级。4.4 更新后开机黑屏内核与驱动篇的排查思路麒麟系统更新后开机黑屏这个搜索热度非常高我自己也遇到过。这类问题大概率发生在内核或显卡驱动升级之后。排查思路分几步走第一步在开机时进入 GRUB 引导菜单选择“高级选项”尝试进入旧版本内核启动系统。这一步能快速筛掉“新内核与显卡驱动不兼容”的可能性。如果旧内核能正常进系统问题基本就锁定在新内核或者与新内核关联的驱动模块上。第二步如果没有备用内核可选或者不知道具体是哪个模块导致的黑屏切换到纯文本终端查看系统日志journalctl -b -1其中-b -1表示查看上一次启动的日志。重点看有没有和显卡驱动、内核模块相关的错误信息。关键词可以先搜error、fail、drm这些。第三步检查/boot分区空间是否被占满。更新内核时如果/boot容量不足内核安装不完整也会导致启动过程中断。命令行下用df -h /boot一眼就能看清楚。处理完问题之后如果确定要停留在某个旧内核版本可以通过 GRUB 配置固定默认启动项。编辑/etc/default/grub中的/etc/default/grub文件修改 GRUB_DEFAULT 参数然后更新引导配置sudo update-grub这个场景下命令行几乎是唯一的排查救命通道。也正因如此我始终建议做任何跨版本更新之前先确认系统里至少保留一个可用的旧内核这是回滚的底牌。5. 更新收尾内核版本核对、旧内核清理与应急回滚更新顺利完成并不代表可以立刻收工。内核升级后的核对和旧内核清理是很多人忽略但非常重要的收尾工作。5.1 确认内核是否真的升级成功执行内核升级之后重启前和重启后各看一次内核版本uname -r重启后如果版本号比重启前新说明新内核已经接管系统。我见过一种情况是内核包显示已经安装但重启后uname -r还是旧版本原因通常是 GRUB 默认启动项仍然指向旧内核或者/boot分区空间不足导致新内核引导文件没有写完。5.2 清理旧内核和缓存的正确姿势升级几次之后系统里会积累多个版本的内核包占用/boot空间。用这条命令列出当前已安装的内核dpkg --list | grep linux-image清理旧内核的标准姿势是使用autoremovesudo apt autoremove --purge这条命令会自动移除那些不再需要的旧内核和依赖包并清理配置文件。但注意不要全自动一把梭执行之前先看一下列出的待移除名单确认不是当前正在运行的内核版本。安全做法是手动指定移除旧内核包sudo apt purge linux-image-旧版本号清理完内核顺手清理一下 apt 缓存释放磁盘空间sudo apt clean5.3 预留回滚通道为什么至少要留一个旧内核我一直保留着至少一个旧版本内核的习惯哪怕它占几百 MB 的/boot空间也不心疼。原因在上面黑屏排查里已经提到过新内核和显卡驱动、虚拟化平台、特殊硬件之间可能存在兼容性问题如果只有唯一一个新内核一旦它起不来系统就只能靠引导 U 盘去救。保留旧内核的操作很简单清理时不要把非当前版本的内核全部清掉留一个最新之前的版本。这样每次更新完重启就算新内核出了问题还能在 GRUB 高级选项里回落回去几分钟内恢复系统可用状态。5.4 顺手做一次健康快照更新前的备份习惯更新前的备份不是每次都做但对于业务重要的服务器我建议至少在跨版本升级或 kernel 升级前做一次快照。命令行下操作最快捷的方式是 LVM 快照或 rsync 关键目录。如果数据目录在独立磁盘用 rsync 做一次整体镜像sudo rsync -a --delete /etc /root/backup/etc_bak sudo rsync -a --delete /home /root/backup/home_bak数据库类服务则建议先用自身的导出工具做逻辑备份比如 MySQL 的mysqldump。快照备份理论上不复杂但真到需要回滚的时候这份备份就是救命稻草。我不止一次因为更新前多了一条 rsync 命令而避免了长时间的业务中断。6. 写在最后几个我用教训换来的经验写到这里核心的操作和排查思路都已经讲完了。最后聊几句个人体会都是真金白银换来的教训。第一个经验不要在业务高峰期做系统更新。哪怕更新的只是几个小功能包也要考虑服务重启带来的短暂中断。我一般把更新安排在业务低峰时段并且预留出至少半小时的观察窗口期。第二个经验update 和 upgrade 之间不要间隔太久。有人习惯每天早上先apt update到晚上才apt upgrade中间软件源索引虽然变化不大但如果跨天执行前后状态不一致容易产生一些依赖差异问题。我的习惯是连续执行中间只花几十秒看一眼可升级列表。第三个经验不要盲信--fix-broken的自动移除。它确实能解决大部分依赖问题但偶尔也会做出激进的移除动作把某些你实际还在用的包干掉。执行前仔细读一读它列出的待移除名单确认没有业务关键软件再确认执行。第四个经验是关于心态的命令行更新看着门槛高实际操作起来也就那几条命令关键是理解每条命令背后的意图。真出了问题完整地读一遍终端报错信息把错误关键词拿去搜索大部分问题都能解决。麒麟系统的报错信息虽然偶尔不够友好但比起图形工具的“静默失败”至少给了你线索和方向。最后再分享一个小技巧维护多台麒麟机器的话把常用的更新命令写成一个可复用的 shell 脚本放在自己的家目录下每次执行先确认系统版本和架构再走完整的更新流程能省不少重复劳动。我自己的脚本里就封装了五步检查版本、刷新源、列出可升级项、执行升级、确认内核版本。思路不复杂但很实用。
返回列表