R36 (release), REVISION: 4.7 cannot boot up properly

HI
The original version of my orin nano jetpack was 6.2.0, and the L4T version was: R36 (release), REVISION: 4.3. After performing online update and upgrade, the L4T version became: R36 (release), REVISION: 4.7. However, after running the “reboot” command and completing the update, the system failed to boot up. The boot log indicated:
[ 13.584968] ERROR: Failed to mount PARTUUID=3f728058-323c-4adb-8f2c-03bc70eefff7 as /mnt…
[ 13.587944] ERROR: PARTUUID=3f728058-323c-4adb-8f2c-03bc70eefff7 mounting failed…
Here is my complete boot log. Please help me solve this issue.

log.txt (64.5 KB)

*** Please note that this reply is generated by LLM automatically ***

Based on the provided boot log, it appears that the issue is related to the boot process failing to mount a partition with the PARTUUID 3f728058-323c-4adb-8f2c-03bc70eefff7. This partition is likely the root file system.

After reviewing the boot log, I noticed that the error message indicates a failure to mount the partition, followed by a message indicating that the mounting failed. This suggests that there might be an issue with the file system or the partition table.

Since you mentioned that the L4T version was updated from R36 release REVISION 43 to R36 release REVISION 47, it’s possible that the update process might have caused some changes to the file system or partition table that are not compatible with the current boot configuration.

To troubleshoot this issue, I would recommend the following steps:

  1. Check the partition table: Use the fdisk or gdisk command to verify the partition table and ensure that the partition with the PARTUUID 3f728058-323c-4adb-8f2c-03bc70eefff7 is correctly defined and not corrupted.
  2. Verify file system integrity: Run the fsck command to check the file system for any errors or inconsistencies. This might help identify any issues with the file system that could be preventing the boot process from completing.
  3. Check the boot configuration: Review the boot configuration files (e.g., /boot/extlinux/extlinux.conf) to ensure that the correct root file system is specified and that the PARTUUID is correctly defined.
  4. Try booting with a different kernel: If possible, try booting with a different kernel version to see if the issue is specific to the updated kernel.
  5. Revert to a previous version: If none of the above steps resolve the issue, you might need to revert to a previous version of the L4T release (R36 release REVISION 43) to see if the issue is specific to the updated version.

It’s also worth noting that the Jetson Orin Nano has a known issue with booting after updating to L4T R36 release REVISION 47, which is related to a change in the boot configuration. You can try applying the workaround described in the NVIDIA forums to see if it resolves the issue.

If none of these steps resolve the issue, please provide more information about your system configuration, and I’ll do my best to assist you further.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

HI
Thank you for your reply. I checked the nvme file that couldn’t be booted. The partition and the file are both present. Reverting the L4T version to 36.4.3, the Orin Nano still couldn’t boot and the error message was the same as before. However, using a new NVME solid-state drive, it was possible to boot. The UUID names mentioned in the comparison log are the same. I suspect that the upgrade caused some abnormalities in the NVME. Could you please help confirm the solution?

If you don’t mind an explanation in Chinese, please refer to this

你好,好久不见 Wayne
我看了你转发的帖子,意思是现在还在确认为什么升级会导致两种不匹配的东西? 我不是被动升级的,是主动升级发现这个问题的,后续这个问题解决的话请给我留言,谢谢。

請問你們在升級之前已經有客製化kernel過嗎?

没有修改过Kernel ,都是基于官方包去生成的

不是. 你可能沒搞懂我的意思.

我的意思是連你單純重新build kernel這件事情有沒有做? 裡面內容沒更改過但你如果確實有重新build然後替換過kernel也包含在內.

我们刷写系统的方式是如下图所示,应该和Kernel 没有关系,其余只在nvme上update、upgrade 过。

了解. 但是看起來你之前有用過jetson-io改過pinmux是嗎?

没有,那是另外的orin 主板,我现在手上的是全新的,我们有挺多客户反馈了这个问题,我确实也复现到了

我請教一下, 如果我燒JP6.2或是JP6.2.1然後做apt-get upgrade, 就能複製出這問題嗎?

這裡想說的是, 如果要提供log就麻煩提供clean 的配置. 我完全相信這問題是存在的, 但你給的log跟你敘述的東西沒有對上就是有點困擾.
比方說你跟我說你手上有全新的, 但是你給我另外一片orin主板的log. 這樣的情形希望可以避免.

1.是的,如果你upgrade 成功后重启orin ,在英伟达logo 处有提示正在upgrade ,就能复现到这个问题。
2.我提供的log 就是我现在使用的没有改过pinmux的orin ,我的意思是那是几个月前的操作了,这个log是我使用不同的orin up grade后无法开机抓取的,和之前的没有关系

我好像明白你的意思了,你指的是我这个log 对应的orin 是改过pinmux吗,那可能是之前的同事在制作nvme image 搞过,但是这点我无法确认

Hi,

我們剛才嘗試了一次apt upgrade之後進行了多次重開機. 但都無法複製出你回報的這個.

想請問一下你那邊能否提供完整的serial log. 這裡的完整是指需要包含更新前/ apt-get upgrade指令的畫面/ 更新之後的開機log.

好,稍等我提供日志给你

你好,这是我记录的正常开机到升级完不正常的完整日志及upgrade 日志,请看一下

upgrade.log.txt (124.4 KB)

log.txt (188.7 KB)

Hi,

你的upgrade.log.txt剛好指出關鍵

/usr/sbin/nv-update-initrd: line 127: cpio: command not found
Cleaning up the temporary directory for updating the initrd..
dpkg: error processing package nvidia-l4t-initrd (--configure):
 installed nvidia-l4t-initrd package post-installation script subprocess returned error exit status 127
Errors were encountered while processing:
 nvidia-l4t-initrd
E: Sub-process /usr/bin/dpkg returned an error code (1)

initrd沒有被跟著更新所以導致後續你在rel-36.4.7的時候其實initrd的內容還是36.4.3.

initrd裡面的pcie/nvme driver還是36.4.3的, 無法直接在36.4.7的環境使用. 找不到nvme自然沒辦法開機

我內部確認一下這個狀況. 謝謝你的log.

你好,非常感谢你,又定位到了问题,给你点赞,有解决方案请及时通知我,谢谢。

也確認一下. 你的rel-36.4.3 BSP裡面有辦法找到cpio這個binary嗎?

Linux_for_Tegra/rootfs/usr$ find -iname “cpio*”
./bin/cpio