基于 RK3588 的 ARM 架构 ITX 主机搭建指南：系统选型和配置优化

这篇文档，应该是目前你能够找到的 RK3588 相关，最全面的设备系统选型和配置优化的内容了，希望能够帮到有类似需求的你。

写在前面

在《近期家用设备（NUC、群晖、光猫、交换机、机柜）散热升级记录》这篇文章最后的一张图片中，除了展示了机柜中网络相关的设备新的运行环境，图片中还包含了去年年末 11 月购入的 4 台 M2 Mac Mini 组成的 Linux（Ubuntu）集群。

这套集群在去年上机柜后，陆续将机柜内的 x86 服务都进行了接管。不仅颜值出众，能耗比远胜初代 M1 和过往的 x86 设备，而且连续安静稳定运行四个月，让我一度想继续在机柜中增加同类（同款）设备。

但在两个月前，Asahi Linux 社区的灵魂人物 Hector Martin（Marcan）发布了《Resigning as Asahi Linux project lead》，宣布离开 Asahi Linux 社区。虽然社区里还有七名成员，但缺少了核心成员后，作为用户不得不考虑一些备份方案。我的需求其实很简单，但并不容易实现：需要原生的 ARM 设备来运行 Linux 系统环境。

经过调研和试错后，我最终选择了 RK3588 开发板的变体方案：使用 RK3588 ITX 主板，自建一台 ARM 主机。

在对比了多个品牌后，我选择了 Radxa 的主板 ROCK 5 ITX+（技术规格）。整体成本 2000 元出头，正好用上个月出售 HPE Gen10 Plus 的回血设备预算覆盖，不需要新增预算。

如果你的使用环境与本文及后续相关文章不太一致，我个人不推荐购入这块主板。因为在折腾过程中，我发现这台设备有很多不够成熟的地方：包括官方系统镜像、社区系统镜像、社区引导系统、官方开源项目的构建产物、官方文档内容、官方论坛用户反馈处理等等…

不过，许多问题都是可以解决的，最终我花了一天多时间完成了这台设备的系统搭建和后续运行规划。就目前状态来说，在明确需求的情况下，还是蛮值的。

完整的设备运行状况是：日常运行 10 瓦左右的 8 核 ARM 主机，运行内存 32GB，存储使用两条 2TB 的 SSD，原生搭载了 2 个 2.5GB 千兆网口。

没有选择的选择

为什么说上面的需求不好实现呢？因为想要找到类似 M2 Mac Mini 这类既小巧又安静，还有超高能耗比的设备，最简单的方法是选择 M3、M4 芯片的升级款设备，但这些设备不能原生运行 Linux。（Asahi Linux 支持遥遥无期）

那么假如拿 macOS 做全年无休的 Linux 家用服务器呢？macOS 早期将各种服务器套件聚合在 macOS Server 软件包中，但随着系统发展，一些组件被内置到系统中，其他的许多功能被陆续废弃。在 “About macOS Server 5.7.1 and later” 公告发布后，2022 年 4 月 21 日起，苹果开始停止 macOS Server 相关软件，2024 年 10 月 29 日彻底关闭了这款软件的支持。这也从某种程度上说明，用 macOS 做测试、App 构建以外的服务，可靠性可能会进一步降低。

而选择 M1 的话，则要面对初代工艺和产品设计问题带来的功耗、发热问题，以及机器中硬盘写入严重放大、磁盘寿命明显受影响的问题。我买过、用过不止两台 M1 设备，M2 刚推出时就迫不及待地将所有 M1 都更新成了 M2，当换掉 M1 之后，许多问题都自然的解决了，所以我不想再购入麻烦，即使它能够和 M2 设备一样安装 Linux 操作系统。

那么，除此之外还有哪些相对低功耗的ARM设备可选呢？树莓派 5 其实是个不错的选择，官方文档资料、社区资源都非常丰富，但不计算溢价的情况下，它有四个硬伤：

1. 树莓派的 IO 接口和其他“派”一样丰富，但 PCIe 性能和扩展性比较局限，通常只能接一个 NVMe 磁盘，社区爱好者们更多使用 USB 方案连接外置磁盘。
2. 第五代派的功耗和发热稍高，配件厂商甚至推出了塔式散热器来解决这个小巧控制板子的散热问题。且不论能耗比问题，单是有效计算设备本体之外浪费的空间和缺乏好看机箱这点，就足够让我犹豫不决。
3. 设备最高内存容量只有 16GB，如果用它来运行服务，需要像 Mac Mini 集群一样横向扩展数量来增加内存资源。而前面提到的发热问题，让我顾虑颇多。
4. 第五代树莓派的供电也很有挑战性，如果购置多台设备，需要配置多个 5V5A 的插头，我不希望机柜里增加很多“累赘”电源，也不想为此购入 POE 交换机，毕竟这类设备都有额外的噪音和散热问题需要处理。

那么，除了树莓派和Apple Mac Mini 之外，想要做到安静、低功耗、能耗比相对突出，我还有哪些选择呢？

其实，就只有市场上供给资源接近无限的手机设备，或者市场上相对充裕的搭载了 Rockchip RK35xx 芯片的 ARM 开发板了。

这两种设备我都进行了调研和折腾，这篇文章里，我们主要来聊聊 RK3588。

设备硬件组装

因为目前机箱还没有到货，所以我只对主板部分进行了组装。

由于 RK3588 采用了类似手机的 SoC 设计，CPU 和内存等核心组件都直接焊接在主板上，我们只需要安装散热器、无线网卡和硬盘这些外围设备即可。

主板使用 60 瓦的 DC 适配器供电，这意味着我们不用担心电源风扇噪音的问题。即使在极限满载状态下，最大功耗也只有 60 瓦，相当省电。在一般使用情况下，功耗会稳定在 10 瓦左右。适配器包装内还贴心地附带了多种国际标准插头，很方便用户使用，这让我想起了早年购买 MacBook 时附赠的电源配件。

主板上有一个 RTC 电池安装槽，不确定是因为我太心急想早点拿到主板，物流使用了顺丰空运，所以包装里没附带电池，还是原装就不含电池。如果有朋友也打算入手这款主板，建议提前准备一颗 CR1220 纽扣电池。我刚好手头有一个 RTC 单片机配件带电池，正好派上了用场。CPU 散热器安装通常需要涂抹硅脂，但官方提供了两片散热硅脂贴，只需撕掉塑料膜直接贴上就可以了，非常方便。

配套的风扇价格只有 40 块钱，所以我对它的做工没有太高要求。不过如果厂商能推出一个通用散热底座，让用户可以更换不同尺寸的风扇，可能会更好。因为设备一般运行时的温度不高，所以风扇低速转动时几乎没有声音。但是，当用户调试设备的时候，风扇控制程序会失效，散热器里内嵌风扇的设计会产生严重的风切噪音，这个设计从用户体验角度来看，真的很糟糕。（导致我一度完全不想调试这块主板的虚拟化相关的部分）

无线网卡方面，我购买了厂商套餐中推荐的同款，占用了配件支出的一半，由于暂时没有进行测试，就不多做评价了。

硬盘方面，我翻了翻之前的库存，虽然黑色贴纸的固态会更配这个黑色主板，但我最终选择使用了两条 2T 的 Intel 660P。尽管这款固态本身速度不算快，但考虑到主板的硬盘接口速度只有 PCIe 3.0x2，算下来还是绰绰有余的，物理限速还能带来更低的使用温度，不产生不必要的散热成本。

系统引导盘方面，我没有选择使用主板自带的 64GB eMMC，而是在 TF 卡槽安装了一块 64GB 的致态 TF 卡，这样更容易备份和进行维护。

如果你计划将其用作 NAS，可以考虑购买名称中不带“Plus”的版本，那款主板上配有 4 个 SATA 接口。而 Plus 版本则支持直接使用两条 NVMe SSD，一条支持 2280 规格，另一条支持 2280 / 22100 规格。

整块主板的设计和做工都不错，但在安装硬盘时，我发现 2280 那个位置即使使用厂家提供的短螺丝，也无法将硬盘拧紧。幸好家里还有螺丝垫圈的库存。建议厂商在后续产品包装中能够提供几个螺丝垫片，避免用户安装完硬盘后发现硬盘松动的问题。

将所有配件都装到主板上之后，我们就可以开始折腾软件部分了。

系统选择

能否发挥这块主板的性能，主要看是否能够选择到合适的系统和软件，来应对和解决我们的使用需求。

目前这块主板主要支持运行五类系统，但并不是每一类都支持得非常好。我们从官网文档和官方赞助的主要开源项目为例，分别来聊聊这些系统。

方案一：厂商提供的 Linux 系统镜像 (RSDK)

我们可以在 radxa-build/rock-5-itx/releases 找到厂商提供的几个不同版本的系统镜像，包括几个历史镜像。在厂商文档的下载资料页面中，厂商推荐的是下面两个版本：

• ROCk 5 ITX (Kernel 5.10): Radxa ROCK 5 ITX Debian11 b6
• ROCK 5 ITX (Kernel 6.1): Radxa ROCK 5 ITX Debian12 b3

我测试安装过一次 “ROCK 5 ITX (Kernel 6.1): Radxa ROCK 5 ITX Debian12 b3” 这个镜像（去年 11 月下旬发布）。但是遇到了和社区许多用户一样的问题：官方提供的默认账号密码有问题，无法登录系统。

为了研究是哪里出了问题，我翻阅了相关开源项目的代码，最终决定应该避开这个方案。

首先，我们在 radxa-build 这个发布系统镜像的项目中查看构建配置文件，能够看到镜像是依赖另外一个厂商的开源组织账号 RadxaOS-SDK/rsdk 构建的，虽然项目中没有配置默认的账号密码，但是在SDK 项目的核心配置（rsdk/build/mod/packages/categories/core.libjsonnet#L77 ）中，能够看到有一个 rsetup-config-first-boot 动作。我们根据这个动作线索继续翻找项目，能够在另外一个厂商的开源项目组织中发现 radxa-pkg/rsetup/ 这个项目。通过在项目中层层翻找，能够发现默认情况下，厂商其实为用户创建了两个默认账户（radxa-pkg/rsetup/config/before.txt），一个是 radxa（add_user radxa radxa），另外一个是 rock（add_user rock rock），这两个账号的密码和用户名是一致的。如果程序运行正确，那么我们应该是可以使用这两个账号登录系统的。

不过，在浏览了一圈上面提到的三个项目，我发现目前几乎没有做覆盖流程功能的测试覆盖。个人观点，作为普通用户，使用官方提供的系统镜像（SDK）来作为日常使用系统，应该是有比较大的运行稳定性风险的，尤其是我们继续长时间使用，并跟随厂商发布版本进行迭代升级。虽然有很多方法可以解决上面提到的账号问题，但难免后续还会出现其他问题。避开这个方案，直觉上能够节约大量时间。

方案二：使用 armbian 操作系统

“Why is Radxa giving up on software support?”，这篇帖子是厂商 Radxa 的社区用户的吐槽。作为花钱购买 Radxa 主板的用户，表示很有同感。

似乎厂商也意识到了自己在软件方面的能力和团队欠缺，于是采取了一个聪明的策略——通过“Platinum support”的方式，“氪金”支持了 armbian 开源项目。因此，我购买的这块主板获得了 armbian社区构建的八个系统镜像。

有了厂商的支持，用户现在能够安装 armbian 社区最新的镜像，这些镜像是在今年 2 月 21 日构建的“Desktop images with Armbian Linux v6.12”。如果我们选择安装 Cinnamon 桌面环境的 Debian 12 镜像，设备的 MESA / VPU 功能都可以正常使用。

我之前写过一些 armbian 相关的文章，参考《快速构建稳定的 Armbian 系统：玩客云折腾速通指南（二）》的“Armbian 系统基础配置和 Docker 安装”章节，可以很快完成系统的基础配置。

稍作设置后，整个操作系统运行起来非常流畅。两块NVMe SSD磁盘的识别和使用也一切正常。当然，风扇运转的声音也非常小。（下文中我会分享如何安装使用，这里就不展开了）

方案三：虚拟化方案（ESXi ARM）、ARM 64 PVE 等

我最初购买这块主板的目标之一，是想测试它能否作为 ARM 虚拟化系统来使用。当然，即使不能运行专用的虚拟化系统，作为 ARM Linux Docker 主机也能满足我的需求，上文（方案二）已经实现啦。

ESXi 官方发布和维护的 ARM 虚拟化系统（ESXi-ARM Fling），随着公司并购结束后，已重新恢复了迭代更新。

经过一番折腾，我成功在这块主板上运行了 ARM 版本的 ESXi（最新版 ESXi-Arm Fling 2.1 Refresh，基于 ESXi 8.0U3c 代码）。但当虚拟化系统运行起来后，相信你会和我一样，不会在上面运行任何需要长期稳定的程序，甚至不会想拿它来做测试系统。

那么，使用 ESXi 会遇到哪些问题和麻烦呢？

不论是进行安装，还是安装后的加载，ARM ESXi 在这块主板上所需时间都非常长，而且还会出现初始化失败完全卡死的情况。由于 ESXi 是非开源软件，系统加载过程中无法获取调试信息，只能完全靠运气。另外，只有最新版本的 ESXi 才能加载和安装，老版本的 ESXi 使用 7.x 版本代码，无法引导安装。

在安装过程中，可能会遇到以下几个问题：

1. 如果不使用 USB 网卡，主板板载的两个 2.5GB 网口在安装阶段无法被识别，系统无法安装。
2. 如果不使用 U 盘扩展存储，主板板载的 PCIe SSD 在安装阶段是无法使用和识别的。
3. 如果插上大容量（500GB）的 U 盘，在安装阶段会直接报错。
4. 即使上面的问题都规避掉了，还是会触发“CPU 核心不匹配”、“软件委托异常接口不支持”、“JumpStart 插件启动失败”等问题。（部分错误可忽略）

在规避掉上述所有问题后，我用一只库存的 16GB U 盘完成了系统安装。

完成安装后，待机画面会出现一些“花屏”现象，一度让我以为是 HDMI 接口出了问题，还好后续更换系统进行了验证，确认只是软件问题。

除了常规安装和验证外，我还尝试了使用之前《快速构建和安装干净的 ESXi 8 镜像指南》文章中提到的方法完善 ARM ESXi 安装镜像，或在安装完成后为系统添加额外的 NVMe 硬盘补丁、网卡补丁，来解决这些问题。但无论是 ARM 版 ESXi 为追求体积而删减了必要的重新构建组件，还是之前的补丁对消费级硬盘的兼容性太差，即便完成了安装，我们也无法像使用 x86 系统那样便捷地使用 ESXi。

除了 ESXi，Proxmox（PVE）也是我们常用的虚拟化系统。不过，在 PVE 官方社区帖子“Proxmox on aarch64 (arm64)”中，我们可以看到虽然相比 ESXi 没有官方支持，但社区中的用户已经折腾出了能够运行的方案。

• 其中最受好评的方案，目前停留在上一代 PVE 系统版本：pimox/pimox7。
• 另一个社区方案 jiangcuo/Proxmox-Arm64 在迭代两年后归档停止更新，取而代之的是另一个“野心更大”的项目：jiangcuo/Proxmox-Port，它将 Proxmox 作为上游，项目本身提供各种非 x86 设备的支持：飞腾、Radxa、树莓派、晶晨、鲲鹏、安培、苹果 M 系芯片等。

目前社区中的 issue 反馈和处理情况不太理想，或许等主机折腾完毕后，我会更换主板上的存储卡和硬盘，进行一些测试和反馈。

方案四：ARM Windows

去年的时候，我分享过几篇和 ARM 设备、Windows 相关的文章：《MacBook Pro 原生安装 Ubuntu 24.04 ARM 版》、《把 Windows 装进 Docker 容器里》、《安卓手机运行 Windows 操作系统：一》。除了文章开头提到的 Mac Mini Linux 集群之外，文章里提到的 ARM Linux MacBook 我也使用了很长的时间，体验非常不错。在这个 ARM Linux 环境中，我还像上面提到的手机设备那样尝试运行过 Windows 系统。

虽然目前 Windows on ARM 缺少很多软件支持，但作为轻度使用或者尝鲜体验，还是可以接受的。

在“手机运行 Windows”这篇文章中，我提到过一个社区项目 edk2-rk3588。如果想要在 RK3588 主板上运行 Windows，同样需要使用他们提供的开源 UEFI 固件：edk2-porting/edk2-rk3588。

有意思的是，和上面厂商“氪金支持” armbian 一样，这个项目的厂商也很聪明地“氪金支持”了：在项目首页明晃晃地列为 Platinum 赞助商，低成本换取了生态支持，为后续可能性画了一张大饼（干的漂亮）。

不过，查看 WOA 项目中（worproject/Rockchip-Windows-Drivers#hardware-support-status），我们能看到 RK3588 主板的 ARM Windows 支持程度目前还不太理想。

所以，除了试玩之外，暂时不建议进行安装和使用。

方案五：Android 操作系统

官方提供了 Android 镜像，目前网上有很多人使用 Android 虚拟化方案来“玩游戏”，不过我没有这个需求，就没有折腾。

如果你感兴趣，可以参考官方 Android 安装文档来折腾。系统的安装部分，可以参考下文的方案，来节约时间。

初始化主板

不论你从哪里购买的主板，我都建议先进行一次初始化，这样可以避免在系统安装过程中因为环境问题浪费时间。

编译或安装 rkdeveloptool 工具包

rkdeveloptool 是 Rockchip 的 USB 芯片烧录工具，为了简单快速地完成主板初始化，我们需要编译或安装这个工具。

我们可以参考这篇文章（Linux 用户），或者这篇文章（macOS 用户），或者这篇文章（Windows 用户）。

我使用的环境是 macOS，依次执行下面的命令后，就能得到 rkdeveloptool 的可执行文件：

# 安装依赖
brew install automake autoconf libusb pkg-config git wget
# 下载程序代码
git clone https://github.com/rockchip-linux/rkdeveloptool
# 切换工作目录
cd rkdeveloptool
# 进行一些可选的补丁操作
# https://github.com/rockchip-linux/rkdeveloptool/pull/73 已经被合并，不再需要打补丁
# wget https://patch-diff.githubusercontent.com/raw/rockchip-linux/rkdeveloptool/pull/73.patch
# https://github.com/rockchip-linux/rkdeveloptool/pull/85 被 https://github.com/rockchip-linux/rkdeveloptool/pull/57 替代，也不需要再打补丁
# wget https://patch-diff.githubusercontent.com/raw/rockchip-linux/rkdeveloptool/pull/85.patch
# git am *.patch
# 进行程序的编译构建
autoreconf -i
./configure
make -j $(nproc)
# 将程序扔到能被 SHELL 直接发现和调用的目录
cp rkdeveloptool /opt/homebrew/bin/

清空 eMMC（系统和应用） 和 SPI Flash（引导和固件） 存储数据

开源项目指向的官方 Wiki 中有不少陈旧信息，这里我参考并使用官网文档中的“Clear eMMC or SPI Flash”的内容，并做了一些调整。

如果你和我一样，希望使用 TF 卡来替代主板上的 eMMC，提升可维护性和灵活性，或者想重新安装纯净的新系统，而不是对原有主板上的“硬盘”（eMMC）进行数据覆盖，那么我们首先需要对磁盘进行“初始化”。

使用命令创建一个大小为 64MB 的空文件（zero.img），在后面的步骤中，用来覆盖擦除原始数据。

# dd if=/dev/zero of=./zero.img bs=1M count=64

64+0 records in
64+0 records out
67108864 bytes transferred in 0.026600 secs (2522889624 bytes/sec)

找一根能够激活 OTG 功能的数据线，将数据线的 Type-C 接口连接到主板靠近电源的位置，将 USB-A 接口连接到我们的刷机设备（我使用的是笔记本）上，然后按住主板的“Maskrom”按钮，插电，开机。

如果你在主板上安装了散热器和风扇，当你听到持续不断的风扇噪音时，大概率就是进入了刷机模式（Maskrom Mode）。我们可以通过上面编译或安装的 rkdeveloptool 程序来进行验证（使用 ld 命令）：

# rkdeveloptool ld

DevNo=1	Vid=0x2207,Pid=0x350b,LocationID=1	Maskrom

当我们看到类似上面的日志时，就说明主板处于可"刷机"的状态了。我们需要下载 loader/rock-5a/rk3588_spl_loader_v1.15.113.bin 引导程序，然后将它烧录到主板中。

因为当 RK 芯片处于 Maskrom 模式时，芯片内部存储器（如 eMMC 或 SPI Flash）无法被直接访问。为了让芯片可以接受后续的刷机、写入镜像、擦除操作等命令，必须先将一个小的引导程序（Loader）写入芯片内部 RAM，让临时引导芯片进入一种可以与烧录工具通信的状态。这个 rk3588_spl_loader_v1.15.113.bin程序就负责初始化芯片内部RAM和外部接口，提供与烧录工具的通信协议，以及允许后续对芯片的存储器（如eMMC或SPI）进行读写、擦除操作。

下载好这个 SPL (Secondary Program Loader) 引导程序文件后，我们使用 db 命令（download bootloader）对主板进行操作：

# rkdeveloptool db rk3588_spl_loader_v1.15.113.bin

Downloading bootloader succeeded.

在建立好通讯链路之后，我们使用 wl 命令（write LBA）将之前准备好的空白文件，写入芯片指定的逻辑块地址（Logical Block Address，简称 LBA），稍等片刻，内部储存器就会被恢复为干净、空白的状态：

# rkdeveloptool wl 0 zero.img

Write LBA from file (100%)

接下来，我们使用 ef 命令（erase flash）来完成 SPI Flash 引导存储整片芯片数据擦除，也进行全部填零重置：

# rkdeveloptool ef

Erasing flash complete.

最后，我们可以选择执行 rd 命令（reboot device），完成设备的硬件重启。

# rkdeveloptool rd

Reset Device OK.

在进行硬件重启之前，我们可以考虑刷入新的引导系统，或者 Linux 操作系统到主板的存储芯片中。

如果你想体验上面提到的 UEFI 固件，可以在下载 rock-5-itx_UEFI_Release_v1.0.1.img 文件后，执行命令：

# rkdeveloptool wl 0 /Users/soulteary/Downloads/rock-5-itx_UEFI_Release_v1.0.1.img

Write LBA from file (100%)

将 UEFI 刷到主板中，再执行 rd 命令，重启硬件设备。

如果完成 UEFI 固件的刷机，重启设备后，将能够看的类似 x86电脑设备一样的启动引导画面。当然，这个固件项目应该还需要持续的开发和迭代，目前的版本中，设备风扇控制无效，部分 BIOS 选项对于安装 ESXi 似乎也是无效的。

在《五十元内的轻量服务器：玩客云折腾速通指南（一）》文章的“快速构建你的 u-boot 程序”中，我介绍过如何快速构建 uboot，或许后面我会尝试也为这块主板定制一个引导程序。

安装和优化系统

受限于篇幅，这篇文章中，我们先聊五个最基础也是多数人都建议调整的部分。

刷写系统到 TF 卡中

上文中提到过我为什么会选择 TF 卡来存放系统：灵活、维护成本极低。

我们使用多次推荐过的 Balena Etcher，将我们下载或构建好的系统镜像刷入 TF 卡。然后将卡插入主板的卡槽，上电启动后进行系统配置，就能够完成基础的系统安装。

armbian 操作系统中的磁盘配置

Armbian 系统的内核版本比较新，默认情况下就能够识别出我们使用的磁盘。相比较使用图形化界面进行 SSD 磁盘重置，我更推荐使用命令行。

初始化磁盘的方法，在《NUC 折腾笔记 - Linux 系统篇》中“配置数据盘”中有提及过。唯一的差别是需要将 SATA 磁盘设备名称换成 /dev/nvme0n1p1 和 /dev/nvme1n1p1。

实际配置的时候，我们可以先通过命令或许磁盘设备名称：

# rock-5-itx:~:# fdisk -l | grep nvme

Disk /dev/nvme1n1: 1.86 TiB, 2048408248320 bytes, 4000797360 sectors
/dev/nvme1n1p1       2048 4000794623 4000792576  1.9T  7 HPFS/NTFS/exFAT
Disk /dev/nvme0n1: 1.86 TiB, 2048408248320 bytes, 4000797360 sectors
/dev/nvme0n1p1       2048 4000797326 4000795279  1.9T  7 HPFS/NTFS/exFAT

按照上面文章进行初始化后，我们再次查看磁盘，状况如下：

# rock-5-itx:~:# fdisk -l | grep nvme

Disk /dev/nvme1n1: 1.86 TiB, 2048408248320 bytes, 4000797360 sectors
Disk /dev/nvme0n1: 1.86 TiB, 2048408248320 bytes, 4000797360 sectors

在挂载磁盘的时候，建议在 fstab 中设置 nofail 参数，避免配置失误或未格式化造成需要在启动的时候，进入恢复模式进行错误修正。

/dev/nvme0n1p1    /data0    ext4    defaults,nofail    0    2
/dev/nvme1n1p1    /data1    ext4    defaults,nofail    0    2

使用命令增加磁盘挂载点：

# rock-5-itx:~:# echo /dev/nvme0n1 /data0 ext4 defaults,nofail 0 0>> /etc/fstab

/dev/nvme0n1 /data0 ext4 defaults 0

# rock-5-itx:~:# echo /dev/nvme1n1 /data1 ext4 defaults,nofail 0 0>> /etc/fstab

/dev/nvme1n1 /data1 ext4 defaults 0

如果你对磁盘性能测试感兴趣，可以参考之前文章《NUC 折腾笔记 - 储存能力测试》中的方法进行测试。

关闭 armbian 系统中的 zram swap

因为我使用的主板有 32GB 内存，并且我的系统安装在 TF 卡上，所以我不需要，也不希望 SWAP 功能启用，它会影响整个设备的运行性能。

常规的停止 SWAP 方法，可以使用 swapoff 命令来停止 swap 服务：

sudo swapoff -a

然后，编辑 /etc/fstab 文件，删除 swap 相关内容。

但是，在 armbian 中，我们使用的 swap 类型是 zram swap，想要关闭这个服务，需要通过命令关闭 armbian-zram-config 服务。

sudo systemctl disable armbian-zram-config
sudo systemctl stop armbian-zram-config

完成上面的设置之后，重启即可让变更完全生效。重启后执行 free -h，将会看到：

Swap:          0B          0B          0B

此时 swap 已彻底永久关闭。

迁移 Docker 容器存储存储位置

默认情况下，Docker 会将数据存储在 /var/lib/docker/ 目录中，为了提高系统使用体验，我们可以将容器的数据保存在我们上面新创建并挂载的 SSD 磁盘中。

参考文章《迁移 Docker 容器储存位置》的方法进行处理即可。

完成设置之后，可以使用命令进行结果验证：

docker info | grep "Docker Root Dir"

不出意外，将收到类似下面的日志输出：

Docker Root Dir: /data0/docker

创建数据保存服务，避免数据丢失

在使用 armbian 提供的 radxa 镜像后，如果我们手动重启或断电，会发现经常出现数据丢失。

通过排查，发现是由于 armbian 默认的分区挂载参数中有一项：commit=120 参数。

# cat /etc/fstab

UUID=b1a28769-69fa-4474-a788-c7c6e25999b9 / ext4 defaults,noatime,commit=120,errors=remount-ro 0 1

/dev/nvme0n1p1    /data0    ext4    defaults,nofail    0    2
/dev/nvme1n1p1    /data1    ext4    defaults,nofail    0    2

tmpfs /tmp tmpfs defaults,nosuid 0 0

这个参数表示每 120 秒才强制提交一次缓存到磁盘，这可以提升性能，但一旦异常重启（如突然断电或不正确关机），就容易导致数据丢失或未保存。

想要解决这个问题，我们可以选择调整或去除 commit 参数，或者在计划重启的时候，手动、自动执行 sync 命令，让数据能够写入磁盘，完成保存。

sudo sync
sudo reboot

为了简化这类操作，并尽可能不影响默认情况的设备性能，我们可以创建一个“懒人保存”服务，当设备关闭或者重启的时候，自动执行 sync 操作：

sudo vim /etc/systemd/system/sync-on-shutdown.service

创建一个服务配置，在配置文件中写入下面的内容；

[Unit]
Description=Sync Filesystems on Shutdown
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target

[Service]
Type=oneshot
ExecStart=/bin/sync

[Install]
WantedBy=halt.target reboot.target shutdown.target

完成配置编写后，执行下面的命令，设置服务开机启动，让服务生效即可：

sudo systemctl enable sync-on-shutdown.service

其他

在完成了配置之后，顺带为这个 ARM Linux 配置了一套轻量好用的远程控制桌面。这篇文章已经写了很多内容了，或许在后续的文章中，可以展开聊聊。

最后

好了，这篇文章就先写到这里吧。

–EOF