Arch Linux ARM 是一个优秀的轻量级 Linux 发行版，广泛运行在树莓派、Orange Pi 等嵌入式设备上。然而，由于其滚动更新的特性，用户在执行
pacman -Syu
升级系统后，偶尔会遇到设备无法启动的问题。这通常是因为内核更新后引导配置未同步，或者 initramfs（初始 RAM 磁盘）生成失败导致的。
本文将详细指导你如何诊断和修复 Arch Linux ARM 升级后无法启动的问题。我们将从准备工作开始，逐步深入到引导加载器（Bootloader）和内核的修复步骤。整个过程假设你手边有一台另一台 Linux 电脑（可以是 Ubuntu、Debian 或另一台 Arch Linux）和读卡器（用于读取 SD 卡或 eMMC 存储）。
1. 准备工作：挂载 Arch Linux ARM 分区
当你的 ARM 设备无法启动时，最直接的修复方法是将其存储介质（通常是 SD 卡）插入到另一台电脑上，手动修复引导文件。
1.1 硬件准备
无法启动的 Arch Linux ARM 设备
（如树莓派）。
读卡器
和
SD 卡
（如果设备使用 SD 卡启动）。
一台运行 Linux 的电脑
（笔记本或台式机均可）。
1.2 插入并识别设备
将 SD 卡插入电脑，打开终端，使用
lsblk
命令查看磁盘标识符。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 238.5G 0 disk
├─sda1 8:1 0 512M 0 part /boot
└─sda2 8:2 0 238G 0 part /
sdb 8:16 1 29.7G 0 disk <-- 这通常是你的 SD 卡
├─sdb1 8:17 1 200M 0 part <-- /boot 分区 (FAT32)
└─sdb2 8:18 1 29.5G 0 part <-- Root 分区 (ext4)
注意
：请根据输出结果确认 SD 卡的设备名，例如
/dev/sdb
或
/dev/sdc
。下文统一假设为
/dev/sdX
。
1.3 挂载分区
Arch Linux ARM 通常有两个关键分区：
Boot 分区
：通常是 FAT32 格式，存放内核（
Image
或
zImage
）、设备树（
.dtb
）和引导配置文件。
Root 分区
：通常是 ext4 格式，存放系统文件。
我们需要将这两个分区挂载到当前系统的某个目录下（例如
/mnt
）。
# 创建挂载目录
sudo mkdir -p /mnt/arch/boot
sudo mkdir -p /mnt/arch/root
# 挂载 Boot 分区 (假设是 /dev/sdb1)
sudo mount /dev/sdb1 /mnt/arch/boot
# 挂载 Root 分区 (假设是 /dev/sdb2)
sudo mount /dev/sdb2 /mnt/arch/root
2. 修复引导加载器 (Bootloader)
引导加载器是系统启动的第一步。在 ARM 设备上，最常见的是
U-Boot
。升级后，U-Boot 环境变量可能丢失，或者 U-Boot 本身被降级/损坏。
2.1 检查 Boot 分区内容
进入挂载的 Boot 目录，查看是否存在必要的引导文件。
cd /mnt/arch/boot
ls -l
你应该看到类似
Image
(内核)、
initramfs-linux.img
(初始内存盘) 以及以
.dtb
结尾的设备树文件。如果这些文件丢失或损坏，系统将无法启动。
2.2 重新安装 U-Boot (以树莓派为例)
如果你使用的是树莓派，Boot 分区是 FAT32 格式，且由 GPU 上的 ROM 代码直接读取。如果升级导致
bootcode.bin
或
start.elf
损坏，你需要重新安装固件。
方法 A：在当前电脑上操作（推荐）
如果挂载的 Root 分区中还有旧的包缓存，或者你可以访问 Arch Linux ARM 的仓库，可以尝试重新提取包。
# 进入挂载的 Root 分区的包缓存目录
cd /mnt/arch/root/var/cache/pacman/pkg
# 查找并解压树莓派固件包 (例如 raspberrypi-bootloader 和 raspberrypi-firmware)
# 假设你找到了 raspberrypi-bootloader-xxx.pkg.tar.zst
sudo tar -I zstd -xvf raspberrypi-bootloader-xxx.pkg.tar.zst -C /mnt/arch/boot --no-same-owner
方法 B：使用
pacman
在 chroot 环境中修复（更彻底）
这需要我们在挂载的系统上模拟运行环境，详见第 4 节。
3. 修复内核与 Initramfs
最常见的升级后无法启动原因是：
内核更新了，但 initramfs 没有生成，或者生成的 initramfs 缺少必要的驱动模块
。
3.1 理解问题
内核 (Kernel)
：
/boot/Image
或
/boot/zImage
。
Initramfs
：一个临时的根文件系统，包含挂载真正根文件系统所需的驱动（如 SD 卡驱动、文件系统驱动）。
设备树 (DTB)
：描述硬件布局的文件。
如果升级后内核版本变了（例如从 6.1 升级到 6.6），但
/boot
下的
initramfs
还是旧版本的配置，或者旧版本的
initramfs
对应的内核被删除了，系统就会卡在 “Waiting for root device” 或直接 Kernel Panic。
3.2 手动检查 Initramfs
在挂载的 Boot 目录下，检查内核和 initramfs 的时间戳是否匹配。
cd /mnt/arch/boot
ls -lh
如果看到
Image-6.6.12-arch1-1
但
initramfs-linux.img
的时间戳很旧，或者根本没有
initramfs
，这就是问题所在。
3.3 强制重新生成 Initramfs
我们可以通过
chroot
环境进入该系统，然后运行
mkinitcpio
命令来重新生成。
4. 终极解决方案：chroot 环境修复
这是最推荐的方法，因为它能模拟设备启动后的环境，确保所有依赖都被正确处理。
4.1 准备 Chroot 环境
我们需要绑定挂载系统目录，以便 chroot 能正常工作。
# 继续在当前电脑的终端操作
cd /mnt/arch
# 绑定挂载必要的系统目录
sudo mount --bind /dev root/dev
sudo mount --bind /proc root/proc
sudo mount --bind /sys root/sys
sudo mount --bind /run root/run # 某些操作需要 /run
4.2 进入 Chroot
使用
arch-chroot
（如果安装了
arch-install-scripts
）或标准
chroot
。
# 如果没有 arch-chroot，使用标准 chroot
sudo chroot root /bin/bash
进入后，你的终端提示符可能会变化，你现在拥有了 Root 权限。
4.3 重新生成 Initramfs
在 chroot 环境中，运行以下命令：
# 重新生成 initramfs
mkinitcpio -P
命令解释
：
mkinitcpio
：Arch Linux 生成初始 RAM 磁盘的工具。
-P
：对所有预设（Preset）运行。这通常会处理
/etc/mkinitcpio.d/
下定义的内核版本。
输出示例
：
如果看到
==> Starting build: 6.6.12-arch1-1
，说明正在为当前安装的内核生成镜像。如果报错提示缺少模块，你需要检查
/etc/mkinitcpio.conf
中的
HOOKS
配置。对于 ARM 设备，通常需要
systemd
或
base
、
udev
、
autodetect
、
modconf
、
block
、
filesystems
、
keyboard
等 Hook。
4.4 重新安装内核 (可选)
如果
mkinitcpio
失败，或者内核文件本身损坏，可以尝试重新安装内核。
# 更新源并重新安装内核
pacman -Syu linux-aarch64
注意：在 chroot 环境中，如果你的网络不通，需要检查
/etc/resolv.conf
。可以复制宿主机的 resolv.conf：
# 在宿主机终端执行（不要在 chroot 里）
cat /etc/resolv.conf > /mnt/arch/root/etc/resolv.conf
4.5 修复引导配置 (Bootloader Config)
U-Boot 通常需要一个
extlinux/extlinux.conf
文件来定位内核。
检查
/boot/extlinux/extlinux.conf
是否存在且内容正确：
cat /boot/extlinux/extlinux.conf
标准内容示例：
LABEL Arch Linux ARM
KERNEL /Image
APPEND root=/dev/mmcblk0p2 rw rootwait initrd=/initramfs-linux.img
关键点
：
KERNEL
：指向内核文件路径。
APPEND
：包含
root=
参数（指定根分区设备）和
initrd=
参数（指定初始内存盘）。
注意
：在 chroot 环境中，
/boot
是挂载的路径，但 U-Boot 是在设备上运行的，所以路径通常相对于 Boot 分区根目录。
如果文件丢失，可以手动创建：
mkdir -p /boot/extlinux
nano /boot/extlinux/extlinux.conf
填入上述内容（根据你的实际分区号修改
mmcblk0p2
）。
4.6 退出 Chroot 并卸载
修复完成后，安全退出。
# 在 chroot 环境中
exit
# 卸载绑定目录
sudo umount -R /mnt/arch
5. 常见问题排查 (Troubleshooting)
如果上述步骤完成后设备仍然无法启动，请检查以下几点：
5.1 根分区 UUID 变更
如果你的
/etc/fstab
使用的是 UUID 挂载根分区，而你最近对分区进行了调整，UUID 可能会变。
修复方法
：
在 chroot 环境中，编辑
/etc/fstab
：
nano /etc/fstab
确保
UUID=
与当前分区匹配。你可以使用
blkid
命令在宿主机上查看 SD 卡分区的 UUID：
sudo blkid /dev/sdb2
5.2 内核模块不匹配
某些 ARM 板（如全志 H3/H6 或瑞芯微 RK3399）需要特定的内核模块或固件（firmware）。
修复方法
：
在 chroot 环境中安装必要的固件包：
pacman -S linux-firmware
如果是特定板子的固件（如树莓派），确保安装了：
pacman -S raspberrypi-firmware
5.3 降级内核 (如果新内核有 Bug)
如果确认是新版本内核导致的硬件不兼容（例如 WiFi 模块无法加载），你可以尝试降级。
方法
：
进入 chroot 环境。
查看 pacman 缓存中的旧内核：
ls /var/cache/pacman/pkg/linux-aarch64*
安装旧版本：
pacman -U /var/cache/pacman/pkg/linux-aarch64-6.1.63-1-aarch64.pkg.tar.zst
再次运行
mkinitcpio -P
。
重启。
6. 总结
Arch Linux ARM 升级后无法启动虽然令人沮丧，但通常不是灾难性的。只要你的 SD 卡数据没有物理损坏，通过
挂载分区 -> Chroot -> 重新生成 Initramfs
的流程，90% 的问题都可以解决。
核心步骤回顾
：
挂载
：将 SD 卡的 Boot 和 Root 分区挂载到电脑。
Chroot
：使用
mount –bind
和
chroot
进入系统环境。
修复
：运行
mkinitcpio -P
修复内核镜像，检查
/boot/extlinux/extlinux.conf
引导配置。
重启
：拔出 SD 卡，放回 ARM 设备启动。
希望这篇指南能帮你快速恢复系统！如果遇到特定硬件的报错，建议查阅 Arch Linux ARM 官方 Wiki 或相关硬件社区。