which suggests the issue is more likely at the filesystem/directory-access or metadata level seen by UEFI, rather than a simple device-detection problem
I agree with this deduction, but the problem is that we have never identified where the issue lies, let alone the root cause. Furthermore, we cannot guarantee that this problem will not reappear in the future, which makes us extremely anxious
I mean the Secure Boot and UEFI Secureboot.
We would need the clear steps to reproduce the issue on the devkit so that we can do further check.
The issue may be relating to the NVMe SSD itself.
As you are using the old r35.4.1, we would strongly suggest updating to the latest r35.6.4 or r36.5 which should include all patches.
Well, as described below,
“In L4T R35.x some UEFI support began, but it was still somewhat custom and used a custom kernel source tree with significant out-of-tree content. In L4T R36.x (the most recent L4T at this time) the installation has become a full UEFI and uses the mainline Linux kernel.”
Should I only use r35.6.4 if we haven’t upgraded the rootfs
I tried installing UEFI r35.6.4, but it seems the result is the same as r35.4.1
MobaXterm_COM4USB-SERIALCH340COM4_20260709_110921.txt (97.2 KB)
[Bds]Booting UEFI PC SN740 NVMe WD 256GB 243543809801 1
Have you gotten another NVMe SSD to verify?
Do you have the devkit to reproduce the similar issue?
We have purchased new Samsung NVME SSD to attempt to reproduce the same issue.
Well, we also suspect that the issue may be caused by the file system enabling advanced features such as 64bit, flexix_bg, and metadata_csum for the reason:
“Old UEFI Ext4Dxe has strict group inode counter validation, long-term frequent file create/delete makes bg_itable_unused mismatch bitmap, Linux kernel ignores mismatch but UEFI rejects inode”. But the problem is that we have repeatedly compared the faulty NVME SSD with the normal NVME SSD, and have not found any conclusive evidence yet
Thank you for the detailed troubleshooting work and hex dump analysis. Your cross-board testing and UEFI diagnostics have effectively isolated the issue to the WD SN740 or filesystem metadata level.
To help narrow down the root cause, please provide results for these three specific tests:
-
Samsung NVMe SSD Testing: Test your affected Jetson Orin NX boards with the Samsung 980 Pro or Samsung 990 Pro SSDs you mentioned purchasing. Do these boards boot successfully with the Samsung drives, or do they exhibit the same “Access Denied” error?
-
WD SN740 Firmware Version: Check and report the firmware version of the affected WD SN740 drives using
nvme-clior similar tools (e.g.,sudo nvme id-ctrl /dev/nvme0 | grep fr). -
eMMC Storage Behavior: If you have access to other Jetson boards with eMMC storage, test whether the same “Access Denied” error occurs when using eMMC instead of NVMe on those boards.
Your hypothesis about ext4 advanced features (64bit, flex_bg, metadata_csum) is worth investigating in parallel. These results will help determine whether the issue is specific to the WD SN740 hardware, its firmware, or the interaction between the UEFI Ext4Dxe driver and certain filesystem metadata configurations.
What’s the test result with Samsung NVMe SSD?
Your hypothesis is possible, but not proven. Please clone the failing NVMe image to the new SSD unchanged:
- Error follows the clone → investigate ext4 metadata / UEFI compatibility.
- Error disappears → investigate the original NVMe hardware, firmware, or PCIe/power.
Please also share the results of the following commands and full serial console log.
sudo e2fsck -f -n /dev/<rootfs-partition>
sudo tune2fs -l /dev/<rootfs-partition>
sudo dumpe2fs -h /dev/<rootfs-partition>
- Samsung NVMe SSD Testing——If we replace the NVMe SSD with a new one, it can definitely start up normally. Because we have conducted multiple tests before, the issue was following the NVMe SSD. Replacing the “faulty” board with a new normal NVMe SSD will enable normal startup. Currently, we have not encountered the same issue with our new Samsung NVMe SSD
- WD SN740 Firmware Version:——The result is
[root@localhost ~]# nvme id-ctrl /dev/nvme0 | grep fr
fr : 73103012
frmw : 0x14
or
[root@localhost ~]# nvme id-ctrl /dev/nvme0 | grep fr
fr : 73914108
frmw : 0x14
[root@localhost ~]#
3. We have no Jetson boards with eMMC storage now, just saw someone discussing the same issue, and they were using eMMc
you mean：
- insert the bad NVME SSD into the linux PC board, then
dd if=/dev/nvme0n1p1 of=/home/ssd/nvme0n1p1.img bs=4M status=progress conv=sync,noerror - insert the new NVME SSD into the linux PC board, then
dd if=/home/ssd/nvme0n1p1.img of=/dev/nvme0n1p1 bs=4M status=progress conv=sync,noerror - insert the new NVME SSD into the Jetson boards, confirm if the same issue occurs
Yes, that’s why we think the issue is specific to WD SN740.
Copying only nvme0n1p1 is not enough, because that tests only the rootfs data and not the whole SSD, so to really check whether the problem is in the SSD itself or in the disk contents, you should clone the entire nvme0n1 disk to a new SSD and test again.
We found that the eMMC on AGX Orin is also from WD so that there may be firmware related issue from WD storage. It was resolved by the firmware update for eMMC on AGX Orin.
Please also check with your vendor for the updated firmware for your WD SN740.
I will redo the test according to the above suggestion, but currently, after formatting the root file system partition of a NVMe SSD, I copied the root file system from the bad NVMe SSD and inserted the new NVMe SSD into the Jetson board, which resulted in the same problem.
Could you clarify if the “bad NVMe SSD” refers to the WD SN740, and the “new NVMe SSD” refers to the Samsung NVMe SSD?