企业官网建设流程全解析

Jetson AGX Orin 64GB / JetPack 6.x 进入 L4T Recovery Boot 的故障排查与修复

1. 文档目的

本文记录一次 Jetson AGX Orin 64GB（系统安装于 eMMC、JetPack 6.x / L4T 36.4.3）无法正常进入 Ubuntu，反复进入 L4T Recovery Boot/initrd shell 的完整定位过程。

本案例同时存在两个问题：

1. eMMC APP 分区的 EXT4 journal 曾损坏，通过e2fsck修复；
2. 文件系统修复后仍不能正常启动，最终确认关键原因是 UEFI EFI VariableRootfsStatusSlotA状态异常。

最终通过把RootfsStatusSlotA写回正常值恢复启动，没有重刷系统。

重要结论：EXT4 journal 损坏是真实存在且需要修复的问题，但它不是文件系统修复后仍持续进入 Recovery Boot 的最终原因。最终决定启动路径的是RootfsStatusSlotA状态。

2. 环境信息

3. 初始故障现象

最初日志显示 eMMC APP 分区的 EXT4 journal 恢复失败：

mount /dev/mmcblk0p1 /mnt JBD2: Invalid checksum recovering data block 0 in log JBD2: recovery failed EXT4-fs (mmcblk0p1): error loading journal Failed to mount /dev/mmcblk0p1 on the /mnt Failed to run "mount_ota_work_partition /dev/mmcblk0p1 /mnt"

initrd 随后检查了 NVMe，但 NVMe 上没有 Jetson 系统所需的启动配置：

mount /dev/nvme0n1p1 /mnt EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode Warning: the /mnt/boot/extlinux/extlinux.conf is not found on /dev/nvme0n1p1, umount it...

最终进入精简 shell：

OTA work directory is not found on internal and external storage devices bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell

这说明启动过程已运行到 Linux kernel/initrd 阶段，但未切换到正常 Ubuntu rootfs。

4. 第一阶段：确认并修复 EXT4 journal

4.1 确认分区身份

blkid /dev/mmcblk0p1

现场输出确认该分区是 eMMC 上的 APP/ext4 分区：

/dev/mmcblk0p1: UUID="ca4c58ab-5ff4-4631-acd2-15c7acc72a04" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="APP" PARTUUID="0029b431-c4d6-4e87-9c39-655c211b5b3a"

dumpe2fs显示 superblock 基本正常，并启用了 journal；但这并不代表 journal 内容本身没有损坏：

Filesystem features: has_journal ... needs_recovery ... metadata_csum Filesystem state: clean Journal features: journal_incompat_revoke journal_64bit journal_checksum_v3 Total journal size: 256M

4.2 只读检查

e2fsck-fn/dev/mmcblk0p1

关键输出：

Warning: skipping journal recovery because doing a read-only filesystem check. Free blocks count wrong (1967876, counted=2022267). Free inodes count wrong (3145235, counted=3145225).

-n只检查、不修改，因此发现的问题仍会保留。

4.3 执行可写修复

确保/dev/mmcblk0p1未挂载后执行：

e2fsck-f/dev/mmcblk0p1

按提示修复 journal、free block count 和 free inode count。修复完成后，APP 分区可以正常挂载：

EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode

同时可检查 rootfs 和启动配置：

mkdir-p/tmp/rootfsmount/dev/mmcblk0p1 /tmp/rootfsls/tmp/rootfsls/tmp/rootfs/boot/extlinuxcat/tmp/rootfs/boot/extlinux/extlinux.conf

现场确认：

• rootfs 目录完整；
• /boot/Image、/boot/initrd和 DTB 路径存在；
• /boot/extlinux/extlinux.conf存在；
• root=/dev/mmcblk0p1配置正确。

关键配置如下：

LABEL primary MENU LABEL primary kernel LINUX /boot/Image FDT /boot/dtb/kernel_tegra234-p3737-0000+p3701-0005-nv.dtb INITRD /boot/initrd APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 ...

4.4 阶段结论

EXT4/JBD2 journal 异常已修复，eMMC APP 分区可以正常挂载，rootfs 与extlinux.conf均完整。然而重启后设备仍未进入正常系统，说明还有第二层故障。

5. 第二阶段：识别为 L4T Recovery Boot

重启后的完整日志出现以下关键信息：

L4TLauncher: Attempting Recovery Boot

kernel command line 也不是extlinux.conf中的/dev/mmcblk0p1，而是：

root=/dev/initrd rw rootwait

随后进入：

Root device found: initrd Mount initrd as rootfs and enter recovery mode

因此可以确认：

• 这不是 USB Force Recovery/RCM 模式；
• BootROM、UEFI、Linux kernel 和 initrd 都已工作；
• L4TLauncher 主动选择了 Recovery Boot；
• 系统没有使用extlinux.conf的正常 primary entry；
• 故障重点应转向 UEFI/L4T 的 OS chain/rootfs 状态，而不是继续修复 ext4。

启动路径可概括为：

BootROM → MB1/MB2 → UEFI → L4TLauncher ├─ 正常：加载 APP → switch_root → Ubuntu └─ 故障：Recovery Boot → root=/dev/initrd → recovery shell

6. BootChain、UEFI Variable 与 A/B 状态排查

当前 recovery initrd 非常精简，nvbootctrl、hexdump、od等命令可能不存在。实际系统中的工具位于已挂载 rootfs：

/tmp/rootfs/usr/sbin/nvbootctrl

必要时可绑定虚拟文件系统后进入 chroot：

mount--bind/dev /tmp/rootfs/devmount--bind/dev/pts /tmp/rootfs/dev/ptsmount--bind/proc /tmp/rootfs/procmount--bind/sys /tmp/rootfs/syschroot/tmp/rootfs /bin/bash

排查早期曾出现：

Error: read variable BootChainFwCurrent failed! Error: invalid current bootloader slot: return(-22) Invalid current slot found: -22 (normally this means all slots are corrupted).

但在正确挂载并访问 EFI variables 后，最终得到：

Current version: 36.4.3 Capsule update status: 0 Current bootloader slot: A Active bootloader slot: A num_slots: 2 slot: 0, status: normal slot: 1, status: normal

/sys/firmware/efi/efivars中也能看到关键变量：

BootChainFwCurrent-781e084c-a330-417c-b678-38e696380cb9 BootChainOsCurrent-781e084c-a330-417c-b678-38e696380cb9 L4TDefaultBootMode-781e084c-a330-417c-b678-38e696380cb9 RootfsStatusSlotA-781e084c-a330-417c-b678-38e696380cb9 RootfsStatusSlotB-781e084c-a330-417c-b678-38e696380cb9

这组证据说明：

• UEFI runtime 和 efivarfs 可用；
• bootloader slot A/B 均为 normal；
• QSPI/UEFI 并非整体损坏；
• 不需要直接重刷 QSPI、bootloader 或整套 eMMC；
• BoardRecoveryBoot曾被怀疑，但对应文件随后不存在，且删除该变量并不是本案例最终修复方法；
• 排查应聚焦 OS chain/rootfs 状态变量。

注意：nvbootctrl的 bootloader slot “normal”不等于RootfsStatusSlotA一定正常。两者属于不同状态层，不能据此前者排除后者。

7. 最终根因

最终根因为：

UEFI EFI VariableRootfsStatusSlotA状态异常，导致 L4TLauncher 把 OS Chain A 判定为不可正常启动，从而选择 Recovery Boot。即使/dev/mmcblk0p1的 EXT4 journal 已修复、rootfs 可以正常挂载、extlinux.conf配置正确，异常的 Slot A rootfs 状态仍会阻止正常启动。

因此，本案例需要处理的是：

RootfsStatusSlotA-781e084c-a330-417c-b678-38e696380cb9

而不是：

• 重刷 eMMC；
• 格式化 APP 分区；
• 修改 NVMe；
• 删除BoardRecoveryBoot；
• 切换 bootloader slot；
• 把 EXT4 修复当作全部修复完成。

8. 最终成功修复命令

8.1 前提

在 L4T recovery shell 中确认 efivarfs 已挂载，并进入 EFI variable 目录：

mount|grepefivarmount-tefivarfs none /sys/firmware/efi/efivars/cd/sys/firmware/efi/efivars/

如果挂载命令提示已经挂载，可忽略该提示。

确认目标文件存在：

ls-lRootfsStatusSlotA-781e084c-a330-417c-b678-38e696380cb9

8.2 写回 Slot A 正常状态

以下是本案例最终验证成功的完整命令，必须保持字节内容、文件名和顺序正确：

printf"\x07\x00\x00\x00\x00\x00\x00\x00">/tmp/var_tmp.bin chattr-iRootfsStatusSlotA-781e084c-a330-417c-b678-38e696380cb9ddif=/tmp/var_tmp.bin\of=RootfsStatusSlotA-781e084c-a330-417c-b678-38e696380cb9\bs=8syncchattr +i RootfsStatusSlotA-781e084c-a330-417c-b678-38e696380cb9

这里写入的 8 字节为：

07 00 00 00 00 00 00 00

前 4 字节07 00 00 00是 efivarfs 文件所需的 EFI variable 属性；后 4 字节00 00 00 00是恢复后的 Slot A 状态值。

完成后执行：

syncreboot

8.3 为什么要使用chattr

efivarfs 中的变量文件可能带 immutable 属性。直接覆盖时可能出现：

Operation not permitted

因此写入前使用chattr -i临时解除 immutable，写入并同步后再以chattr +i恢复保护。

9. 已排除项与证据

10. 推荐的可复用排查流程

步骤 1：先区分 RCM 与 L4T Recovery Boot

若串口日志出现：

L4TLauncher: Attempting Recovery Boot root=/dev/initrd Mount initrd as rootfs and enter recovery mode

则设备已通过 BootROM、UEFI、kernel 和 initrd；这是 L4T Recovery Boot，不是 USB Force Recovery/RCM。

步骤 2：检查 APP 文件系统

blkid /dev/mmcblk0p1 e2fsck-fn/dev/mmcblk0p1

若需要修复，先确认分区未挂载，再执行：

e2fsck-f/dev/mmcblk0p1

步骤 3：验证 rootfs 和 extlinux

mkdir-p/tmp/rootfsmount/dev/mmcblk0p1 /tmp/rootfsls/tmp/rootfscat/tmp/rootfs/boot/extlinux/extlinux.conf

若 APP 可正常挂载且启动文件完整，但启动日志仍是root=/dev/initrd，不要继续把问题归因于 ext4。

步骤 4：检查 bootloader slot

/tmp/rootfs/usr/sbin/nvbootctrl dump-slots-info

若当前与活动 bootloader slot 正常，继续检查 EFI 中的 OS chain/rootfs 状态。

步骤 5：检查 EFI variables

mount-tefivarfs none /sys/firmware/efi/efivars/cd/sys/firmware/efi/efivars/ls-lRootfsStatusSlotA-*ls-lRootfsStatusSlotB-*ls-lL4TDefaultBootMode-*

本案例不具备hexdump、od等工具，因此通过按已验证格式直接写回 Slot A 正常状态完成恢复。

步骤 6：仅在低风险修复无效后考虑刷写

只有在以下情况得到证实后，才考虑 bootloader-only 或整机刷写：

• EFI variables 缺失且确认不是 efivarfs 未挂载；
• bootloader metadata 确实不可恢复；
• APP/rootfs 已不可修复；
• 正常状态写回后仍无法启动，并有进一步证据指向 QSPI/bootloader。

不要在证据不足时直接使用--erase-all，以免丢失 eMMC 数据。

11. 注意事项

1. 修改 EFI variables 有风险，变量名、GUID、字节长度和内容必须准确。
2. 本案例命令适用于现场出现的 GUID781e084c-a330-417c-b678-38e696380cb9；其他设备应先用ls确认实际文件名。
3. 不要对已经挂载的 ext4 分区运行可写e2fsck。
4. e2fsck -n只做只读检查，不会修复发现的问题。
5. nvbootctrl的 bootloader slot 状态与RootfsStatusSlotA/B的 OS/rootfs 状态不是同一概念。
6. recovery initrd 工具集可能非常精简，缺少nvbootctrl、hexdump或od并不代表系统 rootfs 中也没有这些工具。
7. 先执行sync再重启，避免 EFI variable 更新尚未持久化。

12. 最终结论

本次故障由两个连续问题构成：

异常掉电或更新异常（可能原因） ↓ EXT4/JBD2 journal 损坏 ↓ e2fsck 修复，APP/rootfs 恢复可挂载 ↓ 设备仍进入 L4T Recovery Boot ↓ 确认 kernel command line 为 root=/dev/initrd ↓ 排除 extlinux、rootfs、bootloader A/B 和 UEFI 整体损坏 ↓ 定位 RootfsStatusSlotA 状态异常 ↓ 写入 07 00 00 00 00 00 00 00 ↓ 恢复正常启动

最终有效修复不是重刷系统，也不是再次修复 EXT4，而是把RootfsStatusSlotA恢复为正常状态。