这类国产 ARM 架构一体机的安装，最怕的不是技术难，而是“想当然”。我头一回接手时，脑子里全是 x86 那套流程：插盘、开机、按 F11、选 U 盘、下一步下一步，半小时收工。结果真到现场，机器点亮之后一路卡：引导菜单里认不到虚拟光驱、阵列卡配完系统盘顺序错乱、装完重启直接掉进 UEFI Shell、网卡驱动在安装器里只认出来一半。那天从下午两点折腾到凌晨，最后发现问题出在一个固件小版本上。所以这篇国产 ARM 架构一体机安装笔记，我按“从开箱到跑通业务”的真实顺序写一遍，把带外管理、固件核对、RAID 配置、操作系统部署、平台适配这几个环节里容易翻车的地方都摊开说，适合第一次接触 ARM64 服务器、或者从 x86 转过来做交付的朋友照着抄。

1. 先把这台机器看明白：一体机到底“一体”在哪

1.1 拆开“一体机”三个字：硬件、固件、软件栈三层结构

很多人对“一体机”的理解停留在“厂商打包卖的一台服务器”，这个理解不算错，但会让你在安装时漏掉一半的工作量。我习惯把它拆成三层看：最底下是硬件层，包括主板、CPU 板、内存板、阵列卡、网卡、电源和风扇模组；中间是固件层，包含 BIOS/UEFI 固件、BMC 管理固件、阵列卡固件、网卡固件，这一层是 ARM 平台上差异最大的部分；最上面是软件栈层，通常预置了虚拟化平台、容器平台或者云管组件，出厂时可能已经烧好镜像，也可能给你留一张“部署引导盘”。

这三层对应三种完全不同的操作方式。硬件层靠上架、接线、加电；固件层靠带外管理口进去改配置；软件栈层才轮到我们熟悉的装系统、配网络、跑验证。新手最容易犯的错，是一上来就抱着键盘显示器去装系统，把固件层完全跳过。ARM 平台的固件行为和 x86 差别很大，尤其是引导项管理、PCIe 枚举顺序、设备树传递这几块，不先在固件层把地基打平，后面装十遍系统也是白搭。

我一般会在动手之前先做一件事：把机器型号、CPU 型号、内存容量与通道分布、硬盘位数量与类型、网卡型号与端口数、阵列卡型号、电源功率，全部抄在一张纸上或者记在文档里。这张纸在后面配 RAID、算容量、对固件版本的时候会反复用到，比任何自动化工具都靠谱。

1.2 为什么 x86 那套流程不能照搬过来

x86 平台上，引导流程基本是 UEFI 固件 → 引导管理器 → 操作系统加载器，中间环节标准化程度很高，各家主板的行为差异不大。ARM64 服务器虽然也用 UEFI 规范，但实际实现里多了不少厂商自定义的部分，加上 CPU 核心数多、NUMA 节点划分复杂、PCIe 控制器和网卡绑定关系不固定，安装器在探测硬件时出错概率明显更高。

我踩过最典型的一次：安装器在图形界面里只识别到两块网卡，实际机器上有四块。换到 x86 上这种事几乎不会发生，但在 ARM 平台上，很可能是某两块网卡挂在同一个 PCIe 桥下面，固件没有正确下发资源，或者安装器自带的驱动版本比固件老。这种问题的解法不在操作系统里，而在固件层——要么升级固件，要么在固件里调整 PCIe 资源分配策略。

还有一个隐性差异是内核版本门槛。ARM64 服务器的很多外设驱动是后合入主线的，内核版本太低就会出现“硬盘认不到”“网卡不工作”“风扇转速读不出来”这类看似硬件故障、实则是驱动缺失的问题。我的经验线是：通用发行版尽量用 5.10 以上的长期支持内核，国产化操作系统镜像则看厂商给出的兼容清单，清单里写支持哪个内核分支就用哪个，别自己乱换。

1.3 开工前必须备齐的信息清单

正式动手前，我建议先把下面这张表填满。空着的项就是风险点，填不出来的项先去问供应商或者查随机文档，别到了机房再打电话。

这张表看着啰嗦，但它能挡掉八成“装到一半发现不对”的尴尬。尤其是镜像架构这一条，我真的见过有人拿着 x86_64 的 ISO 往 ARM 机器上怼，然后抱怨“启动就报错”。

2. 上架与带外管理：先把“看不见的机器”点亮

2.1 硬件上架那些容易被跳过的细节

一体机通常比较重，满配十来块盘加双电源，两个成年人抬比较稳。上架时导轨要先在机柜立柱上固定好，再把机器滑进去，不要两个人一左一右硬抬——机柜侧板一碰就是一道划痕，而且容易把后面的线缆压住。

风道方向必须确认。这类机器一般分前进风后出风和前出风后进风两种配置，随机文档里会写明。装反了的后果是硬盘温度长期偏高，跑重载业务时风扇狂转，噪音大不说，硬盘寿命也受影响。判断方法很简单：看风扇模组上的箭头标识，或者看机器面板上的气流示意贴纸。

线缆走线我有个习惯：电源线走一侧，网线走另一侧，管理网线和业务网线物理分开，用不同颜色的线或者贴标签区分。听起来是小事，但当你半夜被告警叫醒、要在昏暗的机柜里找哪根是管理口的时候，这个习惯能救命。另外，双电源一定要接到两个不同的配电回路，这是基本功，别嫌麻烦。

2.2 带外管理口初始化：网络规划先想清楚

带外管理口是这台机器在操作系统没起来之前唯一的入口，必须第一个配通。默认地址通常印在机器标签上或者随机文档里，拿到之后用网线直连笔记本，把笔记本配成同网段，浏览器打开管理地址就能进登录页。

第一次登录要改密码、配时间同步、配管理网 IP。管理网我建议单独划一个管理 VLAN，不要和业务网混在一起，理由有三个：一是安全边界清晰，管理口暴露在业务网里风险太大；二是避免业务网广播风暴影响带外管理；三是后续批量做固件升级、日志采集的时候，管理网独立会方便很多。

IP 规划上，我一般按“机柜号 + 位置号”编址，比如管理网段用 10.10.x.0/24，第三段对应机柜，第四段对应 U 位。这样后面新增机器不用翻表格，看地址就知道机器在哪。时间同步这块，把管理口指向内网的时间服务器，顺手把时区设对，不然后面看 BMC 日志的时间戳全是错位的，排查问题时特别难受。

配完之后一定要做两件事：拔掉直连网线，改用管理网访问一次，确认能从网络侧登录；然后在管理界面里找到“用户管理”，把默认账号之外再加一个自己的运维账号。默认账号留着的风险不用多说。

2.3 固件版本核对与升级顺序

这一步是我认为整篇笔记里最值得反复强调的地方。ARM 平台的固件耦合度比 x86 高，UEFI 固件、BMC 固件、阵列卡固件、网卡固件之间往往有版本配套关系，单独升其中一个可能反而出问题。

核对方法是在带外管理界面里找“固件信息”或者“系统信息”页面，把四个固件的版本号记下来，然后和厂商发布的配套版本表对比。如果没有配套表，就去查版本发布说明，看每个版本修了什么、依赖什么。

升级顺序我一般按这个来：

1. 先升 BMC 固件。BMC 是带外管理的基础，版本太老可能不支持新固件的升级包格式。
2. 再升 UEFI/BIOS 固件。这一步会重启，升级过程中绝对不要断电，也别手贱去按重启键。
3. 然后升阵列卡固件。阵列卡固件升级通常在操作系统里做，或者在 UEFI 的阵列卡配置界面里做。
4. 最后升网卡固件。网卡固件升级往往需要重启才能生效。

注意：固件升级期间，带外管理界面可能会短暂失联，这是正常现象，不要反复刷新页面或者强行断电。升级包上传完成后，进度条走完之前，机器风扇可能会全速运转，噪音很大，也是正常的。

我遇到过一回阵列卡固件升级中断，原因是升级包放在了一个网络共享路径上，中途网络抖了一下。从那以后我所有固件升级包都先下载到本地，用带外管理的虚拟介质上传，不依赖任何网络共享。

2.4 远程控制台与虚拟介质的实战用法

带外管理里的远程控制台是整个安装过程的主力工具。Java 和 HTML5 两种模式我都用过，现在优先选 HTML5，不用装插件，浏览器直接开，剪贴板共享和本地镜像挂载也支持得不错。

虚拟介质挂载 ISO 的时候有个细节：文件要放在本地磁盘，别放在网络盘或者移动硬盘上，读取速度跟不上会导致安装器加载到一半卡死。镜像文件也不要放在路径里有中文或者空格的目录，某些实现处理不了。挂载之后，在远程控制台里重启机器，按提示键进引导菜单，就能看到虚拟光驱设备。

还有一个高频问题：挂载了 ISO，但引导菜单里看不到。这通常不是没挂上，而是引导模式设置不对。在固件设置里确认“引导模式”是 UEFI 而不是 Legacy，同时确认“外置设备引导”是开启状态。ARM64 服务器基本只支持 UEFI 引导，Legacy 选项要么没有，要么开了也没用。

3. 存储与 RAID：装系统前最该花时间的一步

3.1 RAID 级别怎么选，容量怎么算

一体机常见的盘位配置是前面板十来个 3.5 寸或者 2.5 寸盘位，外加后置两块系统盘。我的常规做法是系统盘和数据盘物理隔离：两块小容量固态做 RAID1 装系统，剩下的大容量盘做数据盘阵列。

RAID 级别选择上，我按业务类型分：

容量计算的算法要讲清楚，不然容易被标称容量忽悠。厂商标的 3.84TB 是十进制，换算成二进制大约是 3.49TiB。RAID5 的可用容量是（盘数 − 1）× 单盘容量，10 块盘就是 9 × 3.49 ≈ 31.4TiB。RAID10 是盘数 ÷ 2 × 单盘容量，10 块盘就是 5 × 3.49 ≈ 17.4TiB。这些数字要提前算好写进交付文档，别等装完了客户问“怎么只有这么点空间”才想起来解释。

还有写惩罚这个概念值得提一句。RAID5 每写一次数据要读旧数据、读旧校验、算新校验、写新数据、写新校验，实际写盘次数是逻辑写的四倍。所以写密集场景用 RAID5，性能会被拖得很难看，宁可牺牲容量上 RAID10。

3.2 阵列卡配置的实操路径

阵列卡配置有两个入口：一个是开机时按提示键进阵列卡自带的配置界面，另一个是从带外管理进 UEFI 设置，在里面找阵列卡配置项。我一般用后者，因为远程就能操作，不用守在机器前面。

进配置界面之后，先把所有物理盘的状态看一遍，确认都是“未配置”或者“就绪”状态。如果某块盘显示“故障”或者“外来配置”，先清除外来配置再继续，不然阵列建不起来。

建阵列的步骤大同小异：选中物理盘 → 创建虚拟盘 → 选 RAID 级别 → 设置条带大小 → 设置读写策略 → 初始化。条带大小我一般选 256KB 或者 512KB，跑虚拟化和数据库都够用；如果业务是大量小文件读写，可以降到 64KB 或 128KB。

注意：初始化方式要选“快速初始化”，不要选“完全初始化”。完全初始化会把整块盘写一遍零，十块盘能跑几个小时，纯属浪费时间。快速初始化只重建元数据，几秒钟就好。

建完阵列之后，回到引导设置里确认引导顺序，把系统盘对应的虚拟盘放在第一位。这一步经常被忽略，结果系统装在了数据盘上，重启之后进了数据盘的引导扇区，怎么也起不来。

3.3 系统盘与数据盘分离的实践理由

有人图省事，把系统也装在数据盘阵列里，或者干脆用单盘装系统。我的态度很明确：系统盘必须独立，而且必须做 RAID1。

理由很实在。系统盘上跑的是操作系统、日志、临时文件，写操作频繁但容量需求不大，用两块固态做镜像，性能和可靠性都够。数据盘专注业务数据，两者 IO 互相不干扰。如果系统盘和数据盘混在一起，业务高峰期的写压力会直接拖慢系统响应，日志写不进去的时候，服务会莫名其妙卡死。

另外，系统盘独立还带来一个好处：重装系统时不用动数据盘。只要安装时选对目标盘，把系统盘的两个虚拟盘重新分区格式化，数据盘的阵列完全不受影响。这个特性在做系统升级、版本回退的时候特别省事。

4. 操作系统安装：从引导到分区落地

4.1 镜像准备与校验

ARM64 版本的镜像和 x86 版本文件名通常只差一个架构标识，下载时容易点错。我的做法是先确认镜像文件名里带 aarch64 或者 arm64 字样，下载完之后立刻算一次校验值：

# 计算镜像校验值 sha256sum server-image-aarch64.iso # 与官方公布的校验值对比，输出 OK 才算通过 cat server-image-aarch64.iso.sha256

校验这一步别跳过。我遇到过一次镜像在下载过程中损坏，安装器跑到一半报“介质校验失败”，当时以为是硬件问题，查了两个小时才回头算校验值。

除了校验值，还要看镜像的引导方式。ARM64 镜像必须是支持 UEFI 引导的版本，有些老镜像只做了传统引导，挂上去之后引导菜单里压根不出现。判断方法是在镜像的引导目录里看有没有 EFI 引导文件，没有的话就换镜像。

4.2 UEFI 引导与安装器参数

挂载虚拟光驱、重启机器、进引导菜单，选中虚拟光驱那一项。如果安装器界面能正常起来，说明引导没问题，接下来是安装参数。

图形安装器第一步一般是语言和键盘布局，接着是安装目的地选择。这里有个 ARM 平台特有的现象：安装器可能把阵列卡上的虚拟盘识别成多个设备，或者把同一块盘的多个路径都列出来。判断方法是看容量和型号，同一个容量出现两次的，八成是同一块盘的多路径。

进安装目的地界面后，选“自定义分区”，不要用自动分区。自动分区在 ARM 平台上偶尔会算出奇怪的分区布局，尤其是 UEFI 引导分区给得太小，后面升级内核时塞不进去。

4.3 分区方案与 LVM 规划

我常用的分区方案是这样的（以两块 480GB 固态做 RAID1、可用约 447GiB 为例）：

swap 的大小有讲究。如果机器内存是 256GB，swap 给 32GiB 就够了，因为这类机器基本不会真的用到交换空间，它的作用更多是应急兜底。给太大反而浪费宝贵的固态空间。

/var 单独分区是我强烈建议的。容器运行时、系统日志、软件包缓存全在 /var 下面，业务跑起来之后这个目录涨得飞快。如果和根分区放一起，涨满了整个系统就卡死，连登录都难。

如果要上 LVM，可以在分区时把剩余空间做成卷组，后面按需划逻辑卷：

# 查看块设备与分区情况 lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT # 查看卷组信息 vgs lvs # 新建逻辑卷（示例：给业务数据划 500G） lvcreate -L 500G -n data vg_data mkfs.xfs /dev/vg_data/data

LVM 的好处是后期扩容方便，业务数据涨了直接 lvextend 加 xfs_growfs，不用停机重装。代价是多一层映射，极少数 IO 敏感场景会有微小损耗，但一般的虚拟化和容器业务根本感知不到。

4.4 安装完成后的第一轮体检

系统装完重启，第一件事不是急着装业务软件，而是做一轮基础体检。我按这个顺序过：

# 1. 确认内核版本和架构 uname -r uname -m # 应该输出 aarch64 # 2. 确认 CPU 核心数与 NUMA 拓扑 lscpu | head -30 numactl -H # 3. 确认内存总量与可用量 free -h # 4. 确认硬盘识别情况 lsblk nvme list 2>/dev/null # 如果是 NVMe 盘 # 5. 确认网卡识别情况 ip link show ethtool -i eth0 # 看驱动名和固件版本 # 6. 查内核日志里的硬件报错 dmesg -T | grep -iE "error|fail|warn" | head -40

第 6 步特别有用。很多硬件兼容性问题的第一条线索就在 dmesg 里，比如 AER 报错、PCIe 链路降速、SMMU 相关的告警。看到报错不用立刻慌，先记下关键字去查，但如果出现大量重复报错，说明固件或者驱动确实有问题。

5. ARM 平台特有的坑：内核、驱动与性能调优

5.1 内核版本与硬件兼容性的关系

ARM64 服务器的外设驱动合入主线的时间普遍比 x86 晚，这是客观事实。表现在实际使用中，就是老内核认不到新硬件。我建议在选镜像之前先去厂商的兼容性列表里查一下，列表里写支持哪些发行版和内核版本，就按那个来。

如果列表里没写，或者你手上的镜像版本比列表更新，装完之后要重点验证几件事：网卡能不能正常链路起来、硬盘能不能正常识别全、风扇转速和温度传感器能不能读到、阵列卡管理工具能不能装上。这四项有任何一项不正常，先怀疑驱动，别怀疑硬件。

内核参数上有几个和 ARM 平台相关度比较高的：

# 查看当前内核命令行 cat /proc/cmdline # 常见需要关注的参数（写在 /etc/default/grub 的 GRUB_CMDLINE_LINUX 里） # numa=on 启用 NUMA 感知 # iommu.passthrough=0 关闭 IOMMU 直通，虚拟化场景通常需要开着 # transparent_hugepage=madvise 透明大页策略，数据库场景常用

改完 grub 配置记得重新生成引导配置，不同发行版命令不一样，一般是grub2-mkconfig -o /boot/efi/EFI/xxx/grub.cfg或者update-grub，具体看你的系统。生成之前先备份原文件，这个不用我多说。

5.2 NUMA 拓扑与内存通道的实际影响

ARM 服务器核心数多，NUMA 节点划分比常见的 x86 双路机器复杂。有的机型是每个 CPU 一个 NUMA 节点，有的是按内存控制器划分，节点数可能到四个甚至八个。用numactl -H能看清楚每个节点的 CPU 范围和内存大小。

NUMA 带来的实际影响是跨节点访问内存延迟高。跑虚拟机或者数据库的时候，如果虚拟机的虚拟 CPU 和内存跨了节点，性能会明显下降。我的处理办法是在虚拟化平台上开启 NUMA 亲和性绑定，让虚拟机的 vCPU 和内存尽量落在同一个节点内。

内存插槽的分布也值得看一眼。这类机器一般每路 CPU 有多个内存通道，每个通道插槽数固定。如果内存没插满，要按文档推荐的方式分布，别全插在一边。插错通道的后果是内存带宽掉一半，跑内存密集型业务时性能差距非常明显。我见过一台机器，标称八通道，实际只跑出四通道的带宽，拆开一看内存全插在一侧的插槽上。

5.3 网卡固件与驱动的匹配问题

网卡是 ARM 平台上最容易出问题的一类外设。现象包括：链路起不来、速率协商不到标称值、大量丢包、中断分布不均。

排查顺序我一般这样走：

# 1. 看链路状态和协商速率 ethtool eth0 # 2. 看驱动版本和固件版本 ethtool -i eth0 # 3. 看收发包统计，重点看 drop 和 error ethtool -S eth0 | grep -iE "drop|error|miss" # 4. 看中断分布是否均衡 cat /proc/interrupts | grep eth0

如果第 3 步看到 drops 持续增长，先查是不是中断全压在同一个 CPU 核心上。ARM 平台的核心多，中断亲和性没配好的话，单核跑满而其他核闲着，网络性能上不去。可以用 irqbalance 服务，或者手动绑中断：

# 查看网卡中断号 grep eth0 /proc/interrupts # 手动把中断绑到指定核心（示例：绑到 8-15 号核） echo 8-15 > /proc/irq/<中断号>/smp_affinity_list

如果第 2 步发现驱动版本明显偏老，或者固件版本和厂商配套表对不上，那就回到固件升级流程，把网卡固件刷到配套版本。刷完一定要重启再测，很多固件升级需要冷启动才生效。

5.4 装完系统后的性能基线测试

系统装完、驱动正常，我习惯跑一遍基线测试，把数据记下来。目的不是刷分，而是建立一个参照系，后面业务上线出问题时能对比。

我会测这几项：

• CPU 整数和浮点性能，用通用基准工具跑一遍，记录单核和多核成绩。
• 内存带宽，用流式读写测试，看是否达到理论带宽的合理比例。
• 磁盘顺序读写和随机读写，分别测系统盘和数据盘阵列。
• 网络吞吐和延迟，用两台机器对打，测 TCP 和 UDP。

这些数据写进交付文档，后面扩容或者换机型时有个对比依据。我吃过一次亏，客户反馈业务慢，查了半天发现是新机器内存只跑出一半带宽，原因是内存插法不对。如果装机时就测过基线，这个问题当天就能发现。

6. 常见问题与排查技巧实录

6.1 引导类问题：机器起不来怎么办

引导类问题在 ARM 平台上出现频率最高，我按现象分几类。

现象一：加电后屏幕无输出，带外管理能看到画面但远程控制台黑屏。这类问题先查显示输出配置，有些机器默认把显示输出到带外管理，需要手动切换。另外检查一下是不是在固件里关掉了板载显示。

现象二：进不了引导菜单，直接掉进 UEFI Shell。这通常是引导项丢失。在固件设置里找“引导管理”，手动添加引导项，路径指向系统盘的 EFI 分区。如果手动添加也不出现，检查系统盘的 EFI 分区是不是 FAT32 格式、里面有没有引导文件。

现象三：引导菜单里能看到设备，但选中后黑屏重启。这种情况九成是镜像架构不对，或者镜像本身不支持 UEFI 引导。换个镜像验证一下就能排除。

现象四：系统装完第一次重启正常，第二次重启就进不去。这往往是引导顺序被改了，或者阵列卡的引导盘顺序变了。进固件把系统盘设为第一引导项，再观察一次。

我的习惯是：每次改动引导配置之后，先做一次“保存并重启”，确认能正常进系统，再去做别的配置。改一堆东西再一起重启，出问题了根本不知道是哪一步导致的。

6.2 存储与网络类问题

存储类最常见的两个现象：一是阵列建好了但系统里看不到盘，二是能看到盘但容量不对。

第一个现象先查阵列状态是不是“正常”，如果阵列还在初始化或者降级状态，系统里是看不到的。第二个现象查单位换算，3.84TB 的盘在系统里显示 3.49TiB 是正常的，别以为是盘有问题。

网络类问题里，链路起不来先换线换口，排除物理层。物理层没问题就看固件和驱动版本，再看交换机侧的协商配置。有一回我遇到链路反复 up/down，最后发现是交换机端口配了固定速率而网卡是自协商，两边对不上。

6.3 排查速查表与几条避坑心得

最后分享几条我实打实踩出来的经验。

第一，固件先升再装系统，这个顺序不要颠倒。装完系统再升固件，很可能固件升级完引导项全乱，又得重装。

第二，装机前把所有固件版本拍照存档。后面出问题时，能第一时间确认是不是版本变动导致的，省掉大量猜测。

第三，镜像和固件包全部本地保存，别依赖网络共享。机房里网络抖一下，升级中断的代价可能是重刷固件。

第四，装完系统第一件事是配时间同步。日志时间戳不准，排查问题时能把人逼疯。

第五，性能基线一定要测，哪怕只是简单跑一遍，也比什么都没有强。我现在的习惯是每台机器交付前跑一次，数据存进文档，后面任何性能争议都有据可查。

这类 ARM 架构一体机用顺手之后其实很稳，前提是把固件层和存储层的地基打牢。真正花时间的从来不是装系统那半小时，而是前面那些看起来琐碎的版本核对、阵列配置和拓扑确认。把这些做扎实，后面跑业务的时候你会感谢当时多花的这几个小时。