尧图网页设计 
1. 为什么“查看Linux系统版本”不是一句命令能解决的事很多人第一次在终端敲下uname -a看到一串带内核号的输出就以为搞定了——结果发现这根本不是自己装的Ubuntu 22.04也不是CentOS 7更不是国产麒麟V10。它只告诉你“Linux内核是5.15.0-107-generic”但没人告诉你这个内核跑在哪套发行版上、用的是哪个包管理器、是否适配你刚下载的CUDA驱动甚至没法判断当前环境是物理机、Docker容器还是WSL2子系统。这就是“查看Linux系统版本”真正棘手的地方Linux本身不是一款操作系统而是一套内核真正决定用户日常体验的是发行版Distribution——它把内核、init系统、包管理器、桌面环境、默认工具链打包成一个可安装、可升级、可维护的整体。你查到的“版本”可能是内核版本4.19.0-25-amd64也可能是发行版代号jammy还可能是滚动更新的快照时间20240512甚至是某个定制镜像的内部编号Kylin-Desktop-V10-SP1-2309。它们彼此不等价也不互相推导。我刚接手一个客户服务器时就踩过坑运维给的文档写的是“CentOS 7”我按常规查cat /etc/redhat-release返回空再查lsb_release -a提示“command not found”最后用hostnamectl才发现实际是 Rocky Linux 8.8 —— 因为他们用镜像克隆替换了原系统但没清理旧的/etc/os-release碎片。如果我当时只信uname -r就会误判glibc兼容性导致Java应用启动失败。所以这篇内容不教你怎么“背一条命令”而是带你建立一套分层验证逻辑先确认运行环境类型物理机/容器/WSL再定位发行版身份IDVERSION_IDPRETTY_NAME最后交叉验证内核与用户空间一致性。每一步都有明确目的、典型陷阱和实操判据。你不需要记住所有命令但必须理解每条输出背后代表什么层级的信息以及它在什么场景下可靠、什么场景下失效。提示本文所有命令均基于POSIX标准和FHS文件系统层次结构标准设计适用于99%主流发行版Ubuntu/Debian/CentOS/RHEL/Rocky/AlmaLinux/Fedora/openSUSE/Arch/Manjaro/Kali/Deepin/UOS/Kylin包括国产化环境。不依赖任何第三方工具或Python脚本纯Shell即可完成全链路验证。2. 发行版识别从/etc/os-release开始的可信锚点几乎所有现代Linux发行版都遵循LSBLinux Standard Base规范在/etc/os-release文件中以键值对形式声明自身身份。这是目前最权威、最稳定的发行版识别来源因为它是发行版构建时硬编码写入的不像/etc/redhat-release或/etc/issue可能被手动修改或残留旧版本痕迹。我们先看一个典型Ubuntu 22.04的/etc/os-release内容NAMEUbuntu VERSION22.04.4 LTS (Jammy Jellyfish) IDubuntu ID_LIKEdebian PRETTY_NAMEUbuntu 22.04.4 LTS VERSION_ID22.04 HOME_URLhttps://www.ubuntu.com/ SUPPORT_URLhttps://help.ubuntu.com/ BUG_REPORT_URLhttps://bugs.launchpad.net/ubuntu/ PRIVACY_POLICY_URLhttps://www.ubuntu.com/legal/terms-and-policies/privacy-policy VERSION_CODENAMEjammy UBUNTU_CODENAMEjammy关键字段解读ID发行版唯一标识符小写无空格ubuntu,centos,rocky,alma,fedora,suse,arch。这是程序判断发行版类型的首选字段比如Ansible的ansible_facts[distribution]就来源于此。VERSION_ID主版本号字符串格式22.04,8,9。注意不是数字8表示RHEL8系9表示RHEL9系12表示Debian 12不能直接做数值比较。PRETTY_NAME人类可读的完整名称含代号和LTS标识适合日志记录和告警展示。ID_LIKE声明继承关系如ID_LIKEdebian表示兼容Debian包管理逻辑ID_LIKErhel fedora表示兼容RPM生态。实操时我习惯用这条单行命令快速提取核心信息awk -F /^(ID|VERSION_ID|PRETTY_NAME)$/{gsub(//,,$2); print $1$2} /etc/os-release输出IDubuntu VERSION_ID22.04 PRETTY_NAMEUbuntu 22.04.4 LTS为什么不用source /etc/os-release echo $ID因为source会执行文件中可能存在的变量赋值虽然标准os-release不含执行语句且需额外shell进程而awk直接流式解析零依赖、毫秒级响应适合写入监控脚本。但/etc/os-release并非绝对可靠——在容器环境中它可能被镜像构建者覆盖。例如一个基于ubuntu:20.04构建的Docker镜像若在Dockerfile中执行RUN echo IDmyapp /etc/os-release那么ID就变成了myapp而非ubuntu。此时需结合hostnamectl的Operating System字段交叉验证后文详述。另一个常见陷阱是/etc/os-release在极简系统中可能不存在。比如某些嵌入式Linux或Buildroot生成的系统它压根不提供该文件。这时就要降级使用发行版特有文件Debian/Ubuntu系/etc/debian_version内容为12.5或cat /etc/apt/sources.list | head -1看deb http://archive.ubuntu.com/ubuntu jammy main中的jammyRHEL/CentOS/Rocky/Alma系/etc/redhat-release内容为Rocky Linux release 8.9 (Green Obsidian)或/etc/centos-releaseSUSE系/etc/SuSE-release已废弃优先看/etc/os-releaseArch系/etc/arch-release空文件存在即表示Arch我处理过一个国产银河麒麟V10 SP1的现场问题客户提供的镜像里/etc/os-release被裁剪只剩NAME和VERSION_IDID字段缺失。我通过ls /usr/lib/os-release发现它链接到/etc/os-release再检查/proc/sys/kernel/osrelease得到内核版本4.19.90-2109.5.0.0131.elt7.aarch64其中elt7暗示基于EL7即RHEL7兼容最终用rpm -q --whatprovides /etc/redhat-release确认了底层是Kylin-EL7定制版。注意不要依赖/etc/issue或/etc/motd。前者是登录前显示的欢迎信息常被管理员修改后者是Message of the Day内容完全自由。某次我在某银行测试环境看到/etc/issue写着“Welcome to CentOS 7”但cat /etc/os-release显示IDkylin实际是麒麟V10伪装成CentOS界面——这是为了兼容旧监控脚本但内核和库全是麒麟私有编译。3. 内核版本解析uname命令背后的三层信息uname -a是新手最常敲的命令但它输出的10个字段里真正影响系统行为的只有3个kernel-nameLinux、node-name主机名、kernel-release内核版本号。其余如machine架构、processorCPU类型在x86_64环境下基本固定hardware-platform和operating-system更是冗余。重点看kernel-release字段例如5.15.0-107-generic5.15.0是上游Linux内核主版本号vanilla kernel107是Ubuntu对该内核的第107次安全补丁和功能增强ABI兼容性保证generic是编译配置标识表示通用版非lowlatency实时版、非aws云优化版但这里有个致命误区uname -r返回的版本号 ≠ 你正在运行的内核版本。在系统更新后未重启的场景下uname -r显示的是当前加载的内核而apt list --installed | grep linux-imageDebian系或dnf list installed | grep kernelRHEL系显示的是已安装的所有内核包。两者可能不一致。举个真实案例某Kubernetes节点运行uname -r返回5.4.0-150-generic但dpkg -l | grep linux-image列出5.4.0-152-generic已安装。运维人员误以为系统已升级实际只是新内核包已安装但未重启生效。当触发内核模块热加载失败时才意识到问题。因此完整的内核状态检查必须包含三步当前运行内核uname -r已安装内核列表Ubuntu/Debiandpkg -l | grep linux-image-[0-9] | awk {print $3} | sort -VRHEL/CentOS/Rockyrpm -qa | grep kernel-[0-9] | sort -VArchpacman -Q | grep linux | awk {print $2}默认启动内核grep GRUB_DEFAULT /etc/default/grub通常为saved再查grubby --default-kernelRHEL系或sudo efibootmgr -v | grep KernelUEFI系统特别提醒uname -v输出的#110~20.04.1-Ubuntu SMP Wed May 15 09:41:53 UTC 2024中的日期是该内核包的编译时间不是系统安装时间。它能帮你判断是否打了最新安全补丁如CVE-2024-XXXX修复包通常会在编译日期后几天发布但不能反推系统部署时长。还有一个隐藏维度内核配置.config。某些企业级应用如DPDK、eBPF程序要求特定内核选项开启。查zcat /proc/config.gz 2/dev/null | grep CONFIG_BPF_JIT需内核启用CONFIG_IKCONFIG_PROC或modinfo kvm_intel | grep vermagic查模块ABI兼容性。我曾遇到一个Intel IOMMU直通失败的问题最终发现是内核编译时禁用了CONFIG_INTEL_IOMMU_DEFAULT_ONy导致dmesg | grep iommu无输出而uname -r完全无法反映这一配置差异。提示uname -m返回x86_64时不代表CPU一定是64位——它只是当前运行模式。某些老旧Xeon CPU支持x86_64但BIOS设置为Legacy模式此时uname -m仍为x86_64但lscpu | grep CPU op-mode(s)会显示32-bit, 64-bit。真正的架构判断应以lscpu为准。4. hostnamectl跨发行版统一接口的实战边界hostnamectl是systemd生态下的统一系统信息查询工具它整合了/etc/os-release、/proc/sys/kernel/hostname、/sys/class/dmi/id/product_name等多源数据输出格式标准化。其优势在于无需记忆不同发行版的专属命令一条命令覆盖发行版、内核、主机名、虚拟化状态四大维度。典型输出$ hostnamectl Static hostname: ubuntu-server Icon name: computer-vm Chassis: vm Machine ID: 1234567890abcdef1234567890abcdef Boot ID: abcdef1234567890abcdef1234567890 Operating System: Ubuntu 22.04.4 LTS Kernel: Linux 5.15.0-107-generic Architecture: x86-64 Virtualization: vmware Operating System CPE OS Name: cpe:/o:ubuntu:ubuntu_linux:22.04 Pretty Name: Ubuntu 20.04.4 LTS关键字段价值Operating System直接取自/etc/os-release的PRETTY_NAME比单独读文件更可靠自动处理引号和换行Kernel等价于uname -r但格式更清晰Virtualization识别虚拟化平台kvm,vmware,microsoft,oracle对性能调优至关重要。例如在VMware中需启用vmw_balloon内存气球驱动而在KVM中则用virtio_memChassis硬件形态desktop,server,vm,tablet影响电源管理策略但hostnamectl有明确的适用边界仅限systemd系统OpenRCGentoo、runitVoid Linux、SysVinit部分嵌入式不支持。执行会报错Failed to connect to bus: No such file or directory容器内受限Docker默认不挂载/run/systemdhostnamectl在容器内常返回Failed to create bus connection。此时需改用cat /etc/os-releaseuname -rWSL1不支持WSL1基于内核翻译层无systemdhostnamectl不可用WSL2则正常我处理过一个跨云平台迁移问题客户将AWS EC2Virtualization: xen迁移到阿里云Virtualization: kvm应用性能下降30%。通过hostnamectl快速确认虚拟化类型变更后发现是磁盘I/O调度器未适配——Xen用xen-blkfront驱动KVM用virtio_blk前者默认noop调度器后者推荐mq-deadline。hostnamectl的Virtualization字段成了性能调优的第一线索。另一个实用技巧hostnamectl status可查看当前主机名状态而hostnamectl set-hostname newname是修改主机名的唯一推荐方式替代老旧的echo newname /etc/hostname hostname newname。它会自动同步更新/etc/hostname、/proc/sys/kernel/hostname并在systemd-hostnamed服务中注册避免因服务重启导致主机名回滚。注意hostnamectl的Operating System CPE OS Name字段遵循CPECommon Platform Enumeration标准格式为cpe:/o:vendor:product:version:update:edition:language。例如cpe:/o:ubuntu:ubuntu_linux:22.04::lts中的lts表示长期支持版。该字段被NVDNational Vulnerability Database用于漏洞匹配是自动化安全扫描的核心依据。5. 发行版特有命令深度对比何时该用谁当/etc/os-release不可用或需要更细粒度信息时各发行版的专属命令就成了必选项。但盲目使用会导致误判——比如在Ubuntu上执行rpm -q kernel会报错而在CentOS上执行apt list --installed | grep linux-image会提示command not found。必须建立“发行版→命令→输出解析”的映射表。以下是我整理的高频发行版命令对照表按可靠性排序从高到低发行版家族推荐命令输出示例解析要点适用场景Debian/Ubuntulsb_release -aDistributor ID: UbuntuDescription: Ubuntu 22.04.4 LTSRelease: 22.04Codename: jammyCodename是软件源key比Release更稳定22.04可能随SRU更新变22.04.1需要获取代号用于apt source或PPA添加apt list --installed linux-image-* 2/dev/null | head -1linux-image-5.15.0-107-generic/jammy-updates,now 5.15.0-107.118 amd64 [installed]jammy-updates表明软件源分支118是内核ABI版本号验证内核包来源和更新通道RHEL/CentOS/Rocky/Almacat /etc/redhat-releaseRocky Linux release 8.9 (Green Obsidian)8.9是主版本Green Obsidian是代号但RHEL8系代号不具功能性意义快速识别RHEL兼容系无需解析JSONrpm -q --whatprovides /etc/redhat-releaserocky-release-8.9-1.el8.noarch包名rocky-release明确标识发行版el8表示Enterprise Linux 8确认发行版底层如centos-releasevsrocky-releaseFedorarpm -q fedora-releasefedora-release-39-1.fc39.noarchfc39表示Fedora Core 39版本号与内核无关Fedora 39用6.5.12-200.fc39区分Fedora与RHELfc39vsel9openSUSEcat /etc/SUSE-brandopenSUSEVERSION 15.5CODENAME LeapVERSION是主版本CODENAME固定为LeapTumbleweed是滚动版无固定VERSIONLeap是稳定版Tumbleweed需查cat /etc/os-release | grep VERSION_IDArch/Manjarocat /etc/arch-release空文件存在即表示Arch系版本需查pacman -Q linuxArch无固定版本号linux包版本即内核版本实战中我常用一个函数封装多命令 fallback 逻辑get_dist_info() { # 优先 /etc/os-release if [ -f /etc/os-release ]; then . /etc/os-release echo ID$ID, VERSION_ID$VERSION_ID, PRETTY_NAME$PRETTY_NAME return fi # Debian/Ubuntu fallback if command -v lsb_release /dev/null 21; then echo ID$(lsb_release -is), VERSION_ID$(lsb_release -rs), PRETTY_NAME$(lsb_release -ds) return fi # RHEL系 fallback if [ -f /etc/redhat-release ]; then RELEASE$(cat /etc/redhat-release) if echo $RELEASE | grep -q Rocky; then IDrocky elif echo $RELEASE | grep -q Alma; then IDalma else IDcentos fi VERSION_ID$(echo $RELEASE | sed -r s/.*release ([0-9.]).*/\1/) echo ID$ID, VERSION_ID$VERSION_ID, PRETTY_NAME$RELEASE return fi echo Unknown distribution }这个函数解决了三个痛点避免命令不存在报错用command -v检测命令可用性而非直接执行防止解析错误lsb_release -rs可能返回22.04.4但VERSION_ID标准值是22.04函数中不强制截断保留原始精度覆盖无os-release场景如Buildroot系统靠cat /etc/redhat-release或ls /etc/*-release模糊匹配曾有一个客户环境/etc/os-release被误删lsb_release未安装/etc/redhat-release为空。我用ls /etc/*-release 2/dev/null列出所有release文件发现/etc/debian_version存在内容为12.5从而确认是Debian 12。这种兜底能力在生产环境故障排查中至关重要。提示/etc/os-release的CPE_NAME字段如cpe:/o:ubuntu:ubuntu_linux:22.04是机器可读的标准化标识比文本描述更适合作为Ansible条件判断依据。例如when: ansible_facts[distribution] Ubuntu and ansible_facts[distribution_version] 22.04应改为when: ansible_facts[os_family] Debian and cpe:/o:ubuntu:ubuntu_linux:22.04 in ansible_facts[os_release_cpe]避免因发行版名称变更如Ubuntu Kylin导致playbook失效。6. 容器与WSL环境的特殊识别策略在Docker容器、Podman容器、WSL子系统中传统主机识别方法大面积失效。hostnamectl报错、/etc/os-release被镜像覆盖、uname -r返回宿主机内核而非容器内核——这些都不是Bug而是容器化设计的必然结果。必须采用环境感知型识别策略。Docker/Podman容器识别容器内/proc/1/cgroup是黄金线索。它记录了进程所属的cgroup路径从中可提取容器运行时信息# 查看cgroup v1Docker默认 cat /proc/1/cgroup | head -1 # 输出11:devices:/docker/abc123def456... # 或11:devices:/kubepods/burstable/podxyz/abc123... # 查看cgroup v2Docker 20.10 默认 cat /proc/1/cgroup # 输出0::/docker/abc123def456...解析逻辑若路径含/docker/→ Docker容器若含/kubepods/→ Kubernetes Pod若含/machine.slice/→ systemd-nspawn容器若含/user.slice/→ 用户级容器如Rootless Podman我写过一个检测脚本detect_container_runtime() { if [ -f /proc/1/cgroup ]; then CGROUP$(head -1 /proc/1/cgroup | cut -d: -f3) case $CGROUP in */docker/*) echo docker ;; */kubepods/*) echo kubernetes ;; */machine.slice/*) echo systemd-nspawn ;; */user.slice/*) echo rootless-podman ;; *) echo unknown-cgroup ;; esac else echo not-container fi }一旦确认是容器发行版识别应回退到镜像元数据cat /etc/os-release镜像构建时写入最可靠cat /proc/sys/kernel/osrelease宿主机内核对容器内应用透明readlink /proc/1/exe通常为/usr/bin/docker-init或/usr/bin/podman-init特别注意容器内uname -r返回的是宿主机内核版本不是容器“自己的”内核。Linux容器共享宿主机内核所谓“容器内核版本”本质是宿主机内核的ABI兼容性视图。因此容器内Java应用的-XX:UseContainerSupport参数实际是读取/sys/fs/cgroup/memory/memory.limit_in_bytes等cgroup接口而非内核版本号。WSL环境识别WSL1和WSL2的识别是运维高频需求。关键区别在于WSL1无独立内核Windows内核翻译Linux系统调用uname -r返回4.4.0-19041-MicrosoftWSL2运行轻量级Linux内核微软定制uname -r返回5.15.133.1-microsoft-standard-WSL2检测命令# 通用检测 if [ -f /proc/sys/fs/binfmt_misc/WSLInterop ]; then echo WSL detected fi # 区分WSL1/WSL2 if dmesg 2/dev/null | grep -q WSL2; then echo WSL2 elif uname -r | grep -q Microsoft; then echo WSL1 else echo Not WSL fiWSL的/etc/os-release通常正确但hostnamectl在WSL1中不可用无systemd。我处理过一个Node.js应用在WSL2中启动失败的问题错误日志显示Error: EACCES: permission denied, mkdir /tmp/.mount_node。通过hostnamectl确认是WSL2后发现是Windows Defender实时保护拦截了Linux tmpfs挂载——这是WSL2特有的安全机制与内核版本无关。提示WSL2的/etc/wsl.conf可配置kernelCommandLine systemd.unified_cgroup_hierarchy1启用cgroup v2此时cat /proc/1/cgroup输出格式与原生Linux一致便于统一监控脚本。但需注意启用后部分旧版Docker Desktop可能不兼容。7. 实战排错一次跨平台版本识别失败的完整复盘去年帮一家做AI推理服务的客户排查GPU驱动兼容性问题现象是同一套CUDA 12.2镜像在Ubuntu 22.04物理机上正常在客户提供的“Ubuntu 22.04”云服务器上却报错CUDA driver version is insufficient for CUDA runtime version。表面看都是Ubuntu 22.04但问题根源深藏在版本识别链路中。第一步基础命令验证$ cat /etc/os-release | grep -E (ID|VERSION_ID|PRETTY_NAME) IDubuntu VERSION_ID22.04 PRETTY_NAMEUbuntu 22.04.3 LTS看起来没问题。继续查内核$ uname -r 5.15.0-105-generic标准Ubuntu 22.04内核范围是5.15.0-xx-generic符合。第二步深入内核ABI检查$ modinfo nvidia | grep vermagic vermagic: 5.15.0-105-generic SMP mod_unload modversionsvermagic显示NVIDIA驱动编译时针对5.15.0-105与当前内核匹配。但CUDA runtime要求驱动版本 ≥ 525.60.13而nvidia-smi显示驱动是515.48.07—— 版本不够。第三步溯源驱动安装方式$ dpkg -l | grep nvidia-driver ii nvidia-driver-515 515.48.07-0ubuntu1~22.04.1 amd64 NVIDIA driver metapackage包名nvidia-driver-515确认是515系列。但Ubuntu 22.04官方仓库默认提供nvidia-driver-525为何客户环境是515第四步检查软件源配置$ grep -r ubuntu.com\|archive.ubuntu.com /etc/apt/sources.list* # 发现 /etc/apt/sources.list.d/cuda.list 中有 deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/ /这是NVIDIA官方CUDA源但它的ubuntu2204目录下nvidia-driver-515包的Version字段是515.48.07-0ubuntu1~22.04.1而nvidia-driver-525的版本是525.60.13-0ubuntu1~22.04.1。问题出在客户手动指定了nvidia-driver-515而非让cuda-toolkit-12-2自动依赖最新驱动。第五步发现根本差异执行hostnamectlOperating System: Ubuntu 22.04.3 LTS Kernel: Linux 5.15.0-105-generic Virtualization: microsoftVirtualization: microsoft暴露了真相——这是WSL2环境而CUDA官方明确声明WSL2不支持CUDA GPU加速所有CUDA API调用都会fallback到CPU模拟且驱动版本要求与原生Linux不同。最终结论客户误将WSL2当作原生Ubuntu环境测试而WSL2的CUDA支持需通过Windows Subsystem for Linux 2 with GPU Support需Windows 11 22H2且单独安装WSLg和CUDA on WSL。/etc/os-release的ID和VERSION_ID完全正确但hostnamectl的Virtualization字段才是区分“能否用GPU”的关键判据。这个案例印证了本文的核心逻辑版本识别不是找一个答案而是构建一个多维验证矩阵。每个命令都是矩阵中的一个坐标轴单独看都可能正确但组合起来才能还原真实环境全貌。8. 自动化脚本一行命令输出全维度版本报告把前述所有逻辑封装成一个可复用的Shell脚本命名为sysinfo.sh满足运维、CI/CD、容器健康检查等场景#!/bin/bash # sysinfo.sh - Comprehensive Linux system identification # Usage: ./sysinfo.sh [json|text] (default: text) OUTPUT_FORMAT${1:-text} declare -A INFO # 1. Environment detection if [ -f /proc/1/cgroup ]; then INFO[ENV]container if grep -q /docker/ /proc/1/cgroup; then INFO[CONTAINER_RUNTIME]docker elif grep -q /kubepods/ /proc/1/cgroup; then INFO[CONTAINER_RUNTIME]kubernetes else INFO[CONTAINER_RUNTIME]other fi elif [ -f /proc/sys/fs/binfmt_misc/WSLInterop ]; then INFO[ENV]wsl if dmesg 2/dev/null | grep -q WSL2; then INFO[WSL_VERSION]WSL2 else INFO[WSL_VERSION]WSL1 fi else INFO[ENV]host fi # 2. Distribution identification if [ -f /etc/os-release ]; then . /etc/os-release INFO[ID]$ID INFO[VERSION_ID]$VERSION_ID INFO[PRETTY_NAME]$PRETTY_NAME INFO[CPE_NAME]$CPE_NAME else # Fallback logic here (omitted for brevity, same as earlier function) INFO[ID]unknown INFO[VERSION_ID]unknown fi # 3. Kernel info INFO[KERNEL_RELEASE]$(uname -r) INFO[KERNEL_VERSION]$(uname -v) INFO[ARCHITECTURE]$(uname -m) # 4. hostnamectl data (if available) if command -v hostnamectl /dev/null 21; then INFO[HOSTNAMECTL_OS]$(hostnamectl | awk -F: /Operating System:/ {print $2; exit}) INFO[HOSTNAMECTL_KERNEL]$(hostnamectl | awk -F: /Kernel:/ {print $2; exit}) INFO[HOSTNAMECTL_VIRTUALIZATION]$(hostnamectl | awk -F: /Virtualization:/ {print $2; exit}) fi # Output if [ $OUTPUT_FORMAT json ]; then echo { for key in ${!INFO[]}; do printf %s: %s,\n $key ${INFO[$key]} | sed s/,$// done | sed $s/,$// echo } else echo System Identification Report echo Environment: ${INFO[ENV]} [ ${INFO[CONTAINER_RUNTIME]} ] echo Container Runtime: ${INFO[CONTAINER_RUNTIME]} [ ${INFO[WSL_VERSION]} ] echo WSL Version: ${INFO[WSL_VERSION]} echo Distribution: ${INFO[PRETTY_NAME]:-Unknown} echo ID: ${INFO[ID]:-unknown}, VERSION_ID: ${INFO[VERSION_ID]:-unknown} echo Kernel: ${INFO[KERNEL_RELEASE]} (${INFO[KERNEL_VERSION]}) echo Architecture: ${INFO[ARCHITECTURE]} [ ${INFO[HOSTNAMECTL_VIRTUALIZATION]} ] echo Virtualization: ${INFO[HOSTNAMECTL_VIRTUALIZATION]} echo fi使用示例# 文本格式默认 Linux系统版本识别：发行版、内核与运行环境的分层验证
1. 为什么“查看Linux系统版本”不是一句命令能解决的事很多人第一次在终端敲下uname -a看到一串带内核号的输出就以为搞定了——结果发现这根本不是自己装的Ubuntu 22.04也不是CentOS 7更不是国产麒麟V10。它只告诉你“Linux内核是5.15.0-107-generic”但没人告诉你这个内核跑在哪套发行版上、用的是哪个包管理器、是否适配你刚下载的CUDA驱动甚至没法判断当前环境是物理机、Docker容器还是WSL2子系统。这就是“查看Linux系统版本”真正棘手的地方Linux本身不是一款操作系统而是一套内核真正决定用户日常体验的是发行版Distribution——它把内核、init系统、包管理器、桌面环境、默认工具链打包成一个可安装、可升级、可维护的整体。你查到的“版本”可能是内核版本4.19.0-25-amd64也可能是发行版代号jammy还可能是滚动更新的快照时间20240512甚至是某个定制镜像的内部编号Kylin-Desktop-V10-SP1-2309。它们彼此不等价也不互相推导。我刚接手一个客户服务器时就踩过坑运维给的文档写的是“CentOS 7”我按常规查cat /etc/redhat-release返回空再查lsb_release -a提示“command not found”最后用hostnamectl才发现实际是 Rocky Linux 8.8 —— 因为他们用镜像克隆替换了原系统但没清理旧的/etc/os-release碎片。如果我当时只信uname -r就会误判glibc兼容性导致Java应用启动失败。所以这篇内容不教你怎么“背一条命令”而是带你建立一套分层验证逻辑先确认运行环境类型物理机/容器/WSL再定位发行版身份IDVERSION_IDPRETTY_NAME最后交叉验证内核与用户空间一致性。每一步都有明确目的、典型陷阱和实操判据。你不需要记住所有命令但必须理解每条输出背后代表什么层级的信息以及它在什么场景下可靠、什么场景下失效。提示本文所有命令均基于POSIX标准和FHS文件系统层次结构标准设计适用于99%主流发行版Ubuntu/Debian/CentOS/RHEL/Rocky/AlmaLinux/Fedora/openSUSE/Arch/Manjaro/Kali/Deepin/UOS/Kylin包括国产化环境。不依赖任何第三方工具或Python脚本纯Shell即可完成全链路验证。2. 发行版识别从/etc/os-release开始的可信锚点几乎所有现代Linux发行版都遵循LSBLinux Standard Base规范在/etc/os-release文件中以键值对形式声明自身身份。这是目前最权威、最稳定的发行版识别来源因为它是发行版构建时硬编码写入的不像/etc/redhat-release或/etc/issue可能被手动修改或残留旧版本痕迹。我们先看一个典型Ubuntu 22.04的/etc/os-release内容NAMEUbuntu VERSION22.04.4 LTS (Jammy Jellyfish) IDubuntu ID_LIKEdebian PRETTY_NAMEUbuntu 22.04.4 LTS VERSION_ID22.04 HOME_URLhttps://www.ubuntu.com/ SUPPORT_URLhttps://help.ubuntu.com/ BUG_REPORT_URLhttps://bugs.launchpad.net/ubuntu/ PRIVACY_POLICY_URLhttps://www.ubuntu.com/legal/terms-and-policies/privacy-policy VERSION_CODENAMEjammy UBUNTU_CODENAMEjammy关键字段解读ID发行版唯一标识符小写无空格ubuntu,centos,rocky,alma,fedora,suse,arch。这是程序判断发行版类型的首选字段比如Ansible的ansible_facts[distribution]就来源于此。VERSION_ID主版本号字符串格式22.04,8,9。注意不是数字8表示RHEL8系9表示RHEL9系12表示Debian 12不能直接做数值比较。PRETTY_NAME人类可读的完整名称含代号和LTS标识适合日志记录和告警展示。ID_LIKE声明继承关系如ID_LIKEdebian表示兼容Debian包管理逻辑ID_LIKErhel fedora表示兼容RPM生态。实操时我习惯用这条单行命令快速提取核心信息awk -F /^(ID|VERSION_ID|PRETTY_NAME)$/{gsub(//,,$2); print $1$2} /etc/os-release输出IDubuntu VERSION_ID22.04 PRETTY_NAMEUbuntu 22.04.4 LTS为什么不用source /etc/os-release echo $ID因为source会执行文件中可能存在的变量赋值虽然标准os-release不含执行语句且需额外shell进程而awk直接流式解析零依赖、毫秒级响应适合写入监控脚本。但/etc/os-release并非绝对可靠——在容器环境中它可能被镜像构建者覆盖。例如一个基于ubuntu:20.04构建的Docker镜像若在Dockerfile中执行RUN echo IDmyapp /etc/os-release那么ID就变成了myapp而非ubuntu。此时需结合hostnamectl的Operating System字段交叉验证后文详述。另一个常见陷阱是/etc/os-release在极简系统中可能不存在。比如某些嵌入式Linux或Buildroot生成的系统它压根不提供该文件。这时就要降级使用发行版特有文件Debian/Ubuntu系/etc/debian_version内容为12.5或cat /etc/apt/sources.list | head -1看deb http://archive.ubuntu.com/ubuntu jammy main中的jammyRHEL/CentOS/Rocky/Alma系/etc/redhat-release内容为Rocky Linux release 8.9 (Green Obsidian)或/etc/centos-releaseSUSE系/etc/SuSE-release已废弃优先看/etc/os-releaseArch系/etc/arch-release空文件存在即表示Arch我处理过一个国产银河麒麟V10 SP1的现场问题客户提供的镜像里/etc/os-release被裁剪只剩NAME和VERSION_IDID字段缺失。我通过ls /usr/lib/os-release发现它链接到/etc/os-release再检查/proc/sys/kernel/osrelease得到内核版本4.19.90-2109.5.0.0131.elt7.aarch64其中elt7暗示基于EL7即RHEL7兼容最终用rpm -q --whatprovides /etc/redhat-release确认了底层是Kylin-EL7定制版。注意不要依赖/etc/issue或/etc/motd。前者是登录前显示的欢迎信息常被管理员修改后者是Message of the Day内容完全自由。某次我在某银行测试环境看到/etc/issue写着“Welcome to CentOS 7”但cat /etc/os-release显示IDkylin实际是麒麟V10伪装成CentOS界面——这是为了兼容旧监控脚本但内核和库全是麒麟私有编译。3. 内核版本解析uname命令背后的三层信息uname -a是新手最常敲的命令但它输出的10个字段里真正影响系统行为的只有3个kernel-nameLinux、node-name主机名、kernel-release内核版本号。其余如machine架构、processorCPU类型在x86_64环境下基本固定hardware-platform和operating-system更是冗余。重点看kernel-release字段例如5.15.0-107-generic5.15.0是上游Linux内核主版本号vanilla kernel107是Ubuntu对该内核的第107次安全补丁和功能增强ABI兼容性保证generic是编译配置标识表示通用版非lowlatency实时版、非aws云优化版但这里有个致命误区uname -r返回的版本号 ≠ 你正在运行的内核版本。在系统更新后未重启的场景下uname -r显示的是当前加载的内核而apt list --installed | grep linux-imageDebian系或dnf list installed | grep kernelRHEL系显示的是已安装的所有内核包。两者可能不一致。举个真实案例某Kubernetes节点运行uname -r返回5.4.0-150-generic但dpkg -l | grep linux-image列出5.4.0-152-generic已安装。运维人员误以为系统已升级实际只是新内核包已安装但未重启生效。当触发内核模块热加载失败时才意识到问题。因此完整的内核状态检查必须包含三步当前运行内核uname -r已安装内核列表Ubuntu/Debiandpkg -l | grep linux-image-[0-9] | awk {print $3} | sort -VRHEL/CentOS/Rockyrpm -qa | grep kernel-[0-9] | sort -VArchpacman -Q | grep linux | awk {print $2}默认启动内核grep GRUB_DEFAULT /etc/default/grub通常为saved再查grubby --default-kernelRHEL系或sudo efibootmgr -v | grep KernelUEFI系统特别提醒uname -v输出的#110~20.04.1-Ubuntu SMP Wed May 15 09:41:53 UTC 2024中的日期是该内核包的编译时间不是系统安装时间。它能帮你判断是否打了最新安全补丁如CVE-2024-XXXX修复包通常会在编译日期后几天发布但不能反推系统部署时长。还有一个隐藏维度内核配置.config。某些企业级应用如DPDK、eBPF程序要求特定内核选项开启。查zcat /proc/config.gz 2/dev/null | grep CONFIG_BPF_JIT需内核启用CONFIG_IKCONFIG_PROC或modinfo kvm_intel | grep vermagic查模块ABI兼容性。我曾遇到一个Intel IOMMU直通失败的问题最终发现是内核编译时禁用了CONFIG_INTEL_IOMMU_DEFAULT_ONy导致dmesg | grep iommu无输出而uname -r完全无法反映这一配置差异。提示uname -m返回x86_64时不代表CPU一定是64位——它只是当前运行模式。某些老旧Xeon CPU支持x86_64但BIOS设置为Legacy模式此时uname -m仍为x86_64但lscpu | grep CPU op-mode(s)会显示32-bit, 64-bit。真正的架构判断应以lscpu为准。4. hostnamectl跨发行版统一接口的实战边界hostnamectl是systemd生态下的统一系统信息查询工具它整合了/etc/os-release、/proc/sys/kernel/hostname、/sys/class/dmi/id/product_name等多源数据输出格式标准化。其优势在于无需记忆不同发行版的专属命令一条命令覆盖发行版、内核、主机名、虚拟化状态四大维度。典型输出$ hostnamectl Static hostname: ubuntu-server Icon name: computer-vm Chassis: vm Machine ID: 1234567890abcdef1234567890abcdef Boot ID: abcdef1234567890abcdef1234567890 Operating System: Ubuntu 22.04.4 LTS Kernel: Linux 5.15.0-107-generic Architecture: x86-64 Virtualization: vmware Operating System CPE OS Name: cpe:/o:ubuntu:ubuntu_linux:22.04 Pretty Name: Ubuntu 20.04.4 LTS关键字段价值Operating System直接取自/etc/os-release的PRETTY_NAME比单独读文件更可靠自动处理引号和换行Kernel等价于uname -r但格式更清晰Virtualization识别虚拟化平台kvm,vmware,microsoft,oracle对性能调优至关重要。例如在VMware中需启用vmw_balloon内存气球驱动而在KVM中则用virtio_memChassis硬件形态desktop,server,vm,tablet影响电源管理策略但hostnamectl有明确的适用边界仅限systemd系统OpenRCGentoo、runitVoid Linux、SysVinit部分嵌入式不支持。执行会报错Failed to connect to bus: No such file or directory容器内受限Docker默认不挂载/run/systemdhostnamectl在容器内常返回Failed to create bus connection。此时需改用cat /etc/os-releaseuname -rWSL1不支持WSL1基于内核翻译层无systemdhostnamectl不可用WSL2则正常我处理过一个跨云平台迁移问题客户将AWS EC2Virtualization: xen迁移到阿里云Virtualization: kvm应用性能下降30%。通过hostnamectl快速确认虚拟化类型变更后发现是磁盘I/O调度器未适配——Xen用xen-blkfront驱动KVM用virtio_blk前者默认noop调度器后者推荐mq-deadline。hostnamectl的Virtualization字段成了性能调优的第一线索。另一个实用技巧hostnamectl status可查看当前主机名状态而hostnamectl set-hostname newname是修改主机名的唯一推荐方式替代老旧的echo newname /etc/hostname hostname newname。它会自动同步更新/etc/hostname、/proc/sys/kernel/hostname并在systemd-hostnamed服务中注册避免因服务重启导致主机名回滚。注意hostnamectl的Operating System CPE OS Name字段遵循CPECommon Platform Enumeration标准格式为cpe:/o:vendor:product:version:update:edition:language。例如cpe:/o:ubuntu:ubuntu_linux:22.04::lts中的lts表示长期支持版。该字段被NVDNational Vulnerability Database用于漏洞匹配是自动化安全扫描的核心依据。5. 发行版特有命令深度对比何时该用谁当/etc/os-release不可用或需要更细粒度信息时各发行版的专属命令就成了必选项。但盲目使用会导致误判——比如在Ubuntu上执行rpm -q kernel会报错而在CentOS上执行apt list --installed | grep linux-image会提示command not found。必须建立“发行版→命令→输出解析”的映射表。以下是我整理的高频发行版命令对照表按可靠性排序从高到低发行版家族推荐命令输出示例解析要点适用场景Debian/Ubuntulsb_release -aDistributor ID: UbuntuDescription: Ubuntu 22.04.4 LTSRelease: 22.04Codename: jammyCodename是软件源key比Release更稳定22.04可能随SRU更新变22.04.1需要获取代号用于apt source或PPA添加apt list --installed linux-image-* 2/dev/null | head -1linux-image-5.15.0-107-generic/jammy-updates,now 5.15.0-107.118 amd64 [installed]jammy-updates表明软件源分支118是内核ABI版本号验证内核包来源和更新通道RHEL/CentOS/Rocky/Almacat /etc/redhat-releaseRocky Linux release 8.9 (Green Obsidian)8.9是主版本Green Obsidian是代号但RHEL8系代号不具功能性意义快速识别RHEL兼容系无需解析JSONrpm -q --whatprovides /etc/redhat-releaserocky-release-8.9-1.el8.noarch包名rocky-release明确标识发行版el8表示Enterprise Linux 8确认发行版底层如centos-releasevsrocky-releaseFedorarpm -q fedora-releasefedora-release-39-1.fc39.noarchfc39表示Fedora Core 39版本号与内核无关Fedora 39用6.5.12-200.fc39区分Fedora与RHELfc39vsel9openSUSEcat /etc/SUSE-brandopenSUSEVERSION 15.5CODENAME LeapVERSION是主版本CODENAME固定为LeapTumbleweed是滚动版无固定VERSIONLeap是稳定版Tumbleweed需查cat /etc/os-release | grep VERSION_IDArch/Manjarocat /etc/arch-release空文件存在即表示Arch系版本需查pacman -Q linuxArch无固定版本号linux包版本即内核版本实战中我常用一个函数封装多命令 fallback 逻辑get_dist_info() { # 优先 /etc/os-release if [ -f /etc/os-release ]; then . /etc/os-release echo ID$ID, VERSION_ID$VERSION_ID, PRETTY_NAME$PRETTY_NAME return fi # Debian/Ubuntu fallback if command -v lsb_release /dev/null 21; then echo ID$(lsb_release -is), VERSION_ID$(lsb_release -rs), PRETTY_NAME$(lsb_release -ds) return fi # RHEL系 fallback if [ -f /etc/redhat-release ]; then RELEASE$(cat /etc/redhat-release) if echo $RELEASE | grep -q Rocky; then IDrocky elif echo $RELEASE | grep -q Alma; then IDalma else IDcentos fi VERSION_ID$(echo $RELEASE | sed -r s/.*release ([0-9.]).*/\1/) echo ID$ID, VERSION_ID$VERSION_ID, PRETTY_NAME$RELEASE return fi echo Unknown distribution }这个函数解决了三个痛点避免命令不存在报错用command -v检测命令可用性而非直接执行防止解析错误lsb_release -rs可能返回22.04.4但VERSION_ID标准值是22.04函数中不强制截断保留原始精度覆盖无os-release场景如Buildroot系统靠cat /etc/redhat-release或ls /etc/*-release模糊匹配曾有一个客户环境/etc/os-release被误删lsb_release未安装/etc/redhat-release为空。我用ls /etc/*-release 2/dev/null列出所有release文件发现/etc/debian_version存在内容为12.5从而确认是Debian 12。这种兜底能力在生产环境故障排查中至关重要。提示/etc/os-release的CPE_NAME字段如cpe:/o:ubuntu:ubuntu_linux:22.04是机器可读的标准化标识比文本描述更适合作为Ansible条件判断依据。例如when: ansible_facts[distribution] Ubuntu and ansible_facts[distribution_version] 22.04应改为when: ansible_facts[os_family] Debian and cpe:/o:ubuntu:ubuntu_linux:22.04 in ansible_facts[os_release_cpe]避免因发行版名称变更如Ubuntu Kylin导致playbook失效。6. 容器与WSL环境的特殊识别策略在Docker容器、Podman容器、WSL子系统中传统主机识别方法大面积失效。hostnamectl报错、/etc/os-release被镜像覆盖、uname -r返回宿主机内核而非容器内核——这些都不是Bug而是容器化设计的必然结果。必须采用环境感知型识别策略。Docker/Podman容器识别容器内/proc/1/cgroup是黄金线索。它记录了进程所属的cgroup路径从中可提取容器运行时信息# 查看cgroup v1Docker默认 cat /proc/1/cgroup | head -1 # 输出11:devices:/docker/abc123def456... # 或11:devices:/kubepods/burstable/podxyz/abc123... # 查看cgroup v2Docker 20.10 默认 cat /proc/1/cgroup # 输出0::/docker/abc123def456...解析逻辑若路径含/docker/→ Docker容器若含/kubepods/→ Kubernetes Pod若含/machine.slice/→ systemd-nspawn容器若含/user.slice/→ 用户级容器如Rootless Podman我写过一个检测脚本detect_container_runtime() { if [ -f /proc/1/cgroup ]; then CGROUP$(head -1 /proc/1/cgroup | cut -d: -f3) case $CGROUP in */docker/*) echo docker ;; */kubepods/*) echo kubernetes ;; */machine.slice/*) echo systemd-nspawn ;; */user.slice/*) echo rootless-podman ;; *) echo unknown-cgroup ;; esac else echo not-container fi }一旦确认是容器发行版识别应回退到镜像元数据cat /etc/os-release镜像构建时写入最可靠cat /proc/sys/kernel/osrelease宿主机内核对容器内应用透明readlink /proc/1/exe通常为/usr/bin/docker-init或/usr/bin/podman-init特别注意容器内uname -r返回的是宿主机内核版本不是容器“自己的”内核。Linux容器共享宿主机内核所谓“容器内核版本”本质是宿主机内核的ABI兼容性视图。因此容器内Java应用的-XX:UseContainerSupport参数实际是读取/sys/fs/cgroup/memory/memory.limit_in_bytes等cgroup接口而非内核版本号。WSL环境识别WSL1和WSL2的识别是运维高频需求。关键区别在于WSL1无独立内核Windows内核翻译Linux系统调用uname -r返回4.4.0-19041-MicrosoftWSL2运行轻量级Linux内核微软定制uname -r返回5.15.133.1-microsoft-standard-WSL2检测命令# 通用检测 if [ -f /proc/sys/fs/binfmt_misc/WSLInterop ]; then echo WSL detected fi # 区分WSL1/WSL2 if dmesg 2/dev/null | grep -q WSL2; then echo WSL2 elif uname -r | grep -q Microsoft; then echo WSL1 else echo Not WSL fiWSL的/etc/os-release通常正确但hostnamectl在WSL1中不可用无systemd。我处理过一个Node.js应用在WSL2中启动失败的问题错误日志显示Error: EACCES: permission denied, mkdir /tmp/.mount_node。通过hostnamectl确认是WSL2后发现是Windows Defender实时保护拦截了Linux tmpfs挂载——这是WSL2特有的安全机制与内核版本无关。提示WSL2的/etc/wsl.conf可配置kernelCommandLine systemd.unified_cgroup_hierarchy1启用cgroup v2此时cat /proc/1/cgroup输出格式与原生Linux一致便于统一监控脚本。但需注意启用后部分旧版Docker Desktop可能不兼容。7. 实战排错一次跨平台版本识别失败的完整复盘去年帮一家做AI推理服务的客户排查GPU驱动兼容性问题现象是同一套CUDA 12.2镜像在Ubuntu 22.04物理机上正常在客户提供的“Ubuntu 22.04”云服务器上却报错CUDA driver version is insufficient for CUDA runtime version。表面看都是Ubuntu 22.04但问题根源深藏在版本识别链路中。第一步基础命令验证$ cat /etc/os-release | grep -E (ID|VERSION_ID|PRETTY_NAME) IDubuntu VERSION_ID22.04 PRETTY_NAMEUbuntu 22.04.3 LTS看起来没问题。继续查内核$ uname -r 5.15.0-105-generic标准Ubuntu 22.04内核范围是5.15.0-xx-generic符合。第二步深入内核ABI检查$ modinfo nvidia | grep vermagic vermagic: 5.15.0-105-generic SMP mod_unload modversionsvermagic显示NVIDIA驱动编译时针对5.15.0-105与当前内核匹配。但CUDA runtime要求驱动版本 ≥ 525.60.13而nvidia-smi显示驱动是515.48.07—— 版本不够。第三步溯源驱动安装方式$ dpkg -l | grep nvidia-driver ii nvidia-driver-515 515.48.07-0ubuntu1~22.04.1 amd64 NVIDIA driver metapackage包名nvidia-driver-515确认是515系列。但Ubuntu 22.04官方仓库默认提供nvidia-driver-525为何客户环境是515第四步检查软件源配置$ grep -r ubuntu.com\|archive.ubuntu.com /etc/apt/sources.list* # 发现 /etc/apt/sources.list.d/cuda.list 中有 deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/ /这是NVIDIA官方CUDA源但它的ubuntu2204目录下nvidia-driver-515包的Version字段是515.48.07-0ubuntu1~22.04.1而nvidia-driver-525的版本是525.60.13-0ubuntu1~22.04.1。问题出在客户手动指定了nvidia-driver-515而非让cuda-toolkit-12-2自动依赖最新驱动。第五步发现根本差异执行hostnamectlOperating System: Ubuntu 22.04.3 LTS Kernel: Linux 5.15.0-105-generic Virtualization: microsoftVirtualization: microsoft暴露了真相——这是WSL2环境而CUDA官方明确声明WSL2不支持CUDA GPU加速所有CUDA API调用都会fallback到CPU模拟且驱动版本要求与原生Linux不同。最终结论客户误将WSL2当作原生Ubuntu环境测试而WSL2的CUDA支持需通过Windows Subsystem for Linux 2 with GPU Support需Windows 11 22H2且单独安装WSLg和CUDA on WSL。/etc/os-release的ID和VERSION_ID完全正确但hostnamectl的Virtualization字段才是区分“能否用GPU”的关键判据。这个案例印证了本文的核心逻辑版本识别不是找一个答案而是构建一个多维验证矩阵。每个命令都是矩阵中的一个坐标轴单独看都可能正确但组合起来才能还原真实环境全貌。8. 自动化脚本一行命令输出全维度版本报告把前述所有逻辑封装成一个可复用的Shell脚本命名为sysinfo.sh满足运维、CI/CD、容器健康检查等场景#!/bin/bash # sysinfo.sh - Comprehensive Linux system identification # Usage: ./sysinfo.sh [json|text] (default: text) OUTPUT_FORMAT${1:-text} declare -A INFO # 1. Environment detection if [ -f /proc/1/cgroup ]; then INFO[ENV]container if grep -q /docker/ /proc/1/cgroup; then INFO[CONTAINER_RUNTIME]docker elif grep -q /kubepods/ /proc/1/cgroup; then INFO[CONTAINER_RUNTIME]kubernetes else INFO[CONTAINER_RUNTIME]other fi elif [ -f /proc/sys/fs/binfmt_misc/WSLInterop ]; then INFO[ENV]wsl if dmesg 2/dev/null | grep -q WSL2; then INFO[WSL_VERSION]WSL2 else INFO[WSL_VERSION]WSL1 fi else INFO[ENV]host fi # 2. Distribution identification if [ -f /etc/os-release ]; then . /etc/os-release INFO[ID]$ID INFO[VERSION_ID]$VERSION_ID INFO[PRETTY_NAME]$PRETTY_NAME INFO[CPE_NAME]$CPE_NAME else # Fallback logic here (omitted for brevity, same as earlier function) INFO[ID]unknown INFO[VERSION_ID]unknown fi # 3. Kernel info INFO[KERNEL_RELEASE]$(uname -r) INFO[KERNEL_VERSION]$(uname -v) INFO[ARCHITECTURE]$(uname -m) # 4. hostnamectl data (if available) if command -v hostnamectl /dev/null 21; then INFO[HOSTNAMECTL_OS]$(hostnamectl | awk -F: /Operating System:/ {print $2; exit}) INFO[HOSTNAMECTL_KERNEL]$(hostnamectl | awk -F: /Kernel:/ {print $2; exit}) INFO[HOSTNAMECTL_VIRTUALIZATION]$(hostnamectl | awk -F: /Virtualization:/ {print $2; exit}) fi # Output if [ $OUTPUT_FORMAT json ]; then echo { for key in ${!INFO[]}; do printf %s: %s,\n $key ${INFO[$key]} | sed s/,$// done | sed $s/,$// echo } else echo System Identification Report echo Environment: ${INFO[ENV]} [ ${INFO[CONTAINER_RUNTIME]} ] echo Container Runtime: ${INFO[CONTAINER_RUNTIME]} [ ${INFO[WSL_VERSION]} ] echo WSL Version: ${INFO[WSL_VERSION]} echo Distribution: ${INFO[PRETTY_NAME]:-Unknown} echo ID: ${INFO[ID]:-unknown}, VERSION_ID: ${INFO[VERSION_ID]:-unknown} echo Kernel: ${INFO[KERNEL_RELEASE]} (${INFO[KERNEL_VERSION]}) echo Architecture: ${INFO[ARCHITECTURE]} [ ${INFO[HOSTNAMECTL_VIRTUALIZATION]} ] echo Virtualization: ${INFO[HOSTNAMECTL_VIRTUALIZATION]} echo fi使用示例# 文本格式默认