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 的完整定位过程。本案例同时存在两个问题eMMC APP 分区的 EXT4 journal 曾损坏通过e2fsck修复文件系统修复后仍不能正常启动最终确认关键原因是 UEFI EFI VariableRootfsStatusSlotA状态异常。最终通过把RootfsStatusSlotA写回正常值恢复启动没有重刷系统。重要结论EXT4 journal 损坏是真实存在且需要修复的问题但它不是文件系统修复后仍持续进入 Recovery Boot 的最终原因。最终决定启动路径的是RootfsStatusSlotA状态。2. 环境信息项目信息硬件Jetson AGX Orin 64GB软件JetPack 6.xL4T/bootloader 版本36.4.3系统盘内置 eMMCAPP/rootfs/dev/mmcblk0p1其他存储NVMe作为数据盘使用故障表现无法进入正常系统进入 L4T Recovery Boot/initrd shell3. 初始故障现象最初日志显示 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 /mntinitrd 随后检查了 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...最终进入精简 shellOTA 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 journal4.1 确认分区身份blkid /dev/mmcblk0p1现场输出确认该分区是 eMMC 上的 APP/ext4 分区/dev/mmcblk0p1: UUIDca4c58ab-5ff4-4631-acd2-15c7acc72a04 BLOCK_SIZE4096 TYPEext4 PARTLABELAPP PARTUUID0029b431-c4d6-4e87-9c39-655c211b5b3adumpe2fs显示 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: 256M4.2 只读检查e2fsck-fn/dev/mmcblk0p1关键输出Warning: skipping journal recovery because doing a read-only filesystem check. Free blocks count wrong (1967876, counted2022267). Free inodes count wrong (3145235, counted3145225).-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-0000p3701-0005-nv.dtb INITRD /boot/initrd APPEND ${cbootargs} root/dev/mmcblk0p1 rw rootwait rootfstypeext4 ...4.4 阶段结论EXT4/JBD2 journal 异常已修复eMMC APP 分区可以正常挂载rootfs 与extlinux.conf均完整。然而重启后设备仍未进入正常系统说明还有第二层故障。5. 第二阶段识别为 L4T Recovery Boot重启后的完整日志出现以下关键信息L4TLauncher: Attempting Recovery Bootkernel 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 shell6. BootChain、UEFI Variable 与 A/B 状态排查当前 recovery initrd 非常精简nvbootctrl、hexdump、od等命令可能不存在。实际系统中的工具位于已挂载 rootfs/tmp/rootfs/usr/sbin/nvbootctrl必要时可绑定虚拟文件系统后进入 chrootmount--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 均为 normalQSPI/UEFI 并非整体损坏不需要直接重刷 QSPI、bootloader 或整套 eMMCBoardRecoveryBoot曾被怀疑但对应文件随后不存在且删除该变量并不是本案例最终修复方法排查应聚焦 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-38e696380cb98.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\ofRootfsStatusSlotA-781e084c-a330-417c-b678-38e696380cb9\bs8syncchattr 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 状态值。完成后执行syncreboot8.3 为什么要使用chattrefivarfs 中的变量文件可能带 immutable 属性。直接覆盖时可能出现Operation not permitted因此写入前使用chattr -i临时解除 immutable写入并同步后再以chattr i恢复保护。9. 已排除项与证据检查项结论依据PCIe/NVMe 硬件正常NVMe 正常枚举并能挂载NVMe 是否为系统 rootfs否NVMe 中无/boot/extlinux/extlinux.conf现场为数据盘eMMC/GPT正常mmcblk0p1至p15存在APP 分区可识别EXT4 journal曾损坏已修复出现 JBD2 checksum/recovery failede2fsck修复后可正常挂载APP/rootfs 内容正常标准根目录、kernel、initrd、DTB、extlinux 配置均存在extlinux.conf正常明确指向/dev/mmcblk0p1BootROM/UEFI/kernel/initrd正常均已运行到 recovery initrd shellBootloader A/B slot正常当前/活动 slot 均为 Aslot 0/1 均为 normalUEFI NVRAM 整体损坏排除efivarfs 可见大量 BootChain、BootOrder 和 L4T 变量BoardRecoveryBoot非最终根因变量路径随后不存在最终修复未依赖它QSPI/bootloader 重刷不需要写回RootfsStatusSlotA后恢复启动最终关键故障RootfsStatusSlotA异常写入正常值后成功恢复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 和 extlinuxmkdir-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 variablesmount-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. 注意事项修改 EFI variables 有风险变量名、GUID、字节长度和内容必须准确。本案例命令适用于现场出现的 GUID781e084c-a330-417c-b678-38e696380cb9其他设备应先用ls确认实际文件名。不要对已经挂载的 ext4 分区运行可写e2fsck。e2fsck -n只做只读检查不会修复发现的问题。nvbootctrl的 bootloader slot 状态与RootfsStatusSlotA/B的 OS/rootfs 状态不是同一概念。recovery initrd 工具集可能非常精简缺少nvbootctrl、hexdump或od并不代表系统 rootfs 中也没有这些工具。先执行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恢复为正常状态。