after a reboot of my AGX Orin I saw this, Jetpack 5.1.3
Does a apt-update/apt-upgrade can trigger this ?
Is there a way this was automatic and not intended ?
Hi,
If the device cannot be flashed/booted, please refer to the page to get uart log from the device:
Jetson/General debug - eLinux.org
And get logs of host PC and Jetson device for reference. If you are using custom board, you can compare uart log of developer kit and custom board to get more information.
Also please check FAQs:
Jetson AGX Orin FAQ
If possible, we would suggest follow quick start in developer guide to re-flash the system:
Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation
And see if the issue still persists on a clean-flashed system.
Thanks!
Hi:
Seems like the issue mentioned in Here
Hi andresc4,
Are you using the devkit or custom board for AGX Orin?
Do you mean that you were using Jetpack 5.1.3(r35.5.0) and it triggers bootloader update after you run apt-update/apt-upgrade?
Please share the full serial console log for further check.
Hello Kevin,
I have both a custom board and a devkit. However, the issue I encountered was not board-related.
After performing the UEFI upgrade, my system stopped functioning due to software and driver compatibility issues associated with specific version dependencies. I was able to reflash the board and resume work, but I would like to avoid this issue in the final product.
I am unsure whether I performed an apt-update or apt-upgrade; it’s possible that I did, or it’s equally possible that I did not. My question is: What triggers the UEFI upgrade? Is it solely the result of an intended apt-update or apt-upgrade, or is it possible that the board initiated the upgrade automatically after being online for several days?
How can I prevent this from happening in the future? Would disabling repositories be a solution, or could I leave the repositories enabled and simply disable the upgrade process?
Thank you for your assistance.
Reading at your thread, its seems we have the same issue
Did the solution sugested by DaneLLL worked out for you?
Hi,
If you have your self-built kernel, please do apt-mark hold the packages:
nvidia-l4t-display-kernel nvidia-l4t-kernel nvidia-l4t-kernel-dtbs nvidia-l4t-kernel-headers nvidia-l4t-kernel-oot-headers nvidia-l4t-kernel-oot-modules
So the the kernel is not overwritten to default kernel. Updating other packages should be fine.
I would also like to know the cause of this behavior.
Normally, bootloader update would be trigger if you perform capsule update manually.
sudo apt upgrade would only upgrade for the minor release like r36.4.0 to r36.4.3.
Please provide the full serial console log when you hit the issue. And it would be great to provide the detailed steps to reproduce the issue so that we can verify and debug it locally.
Precisely, bootloader should be marked:
sudo apt-mark hold nvidia-l4t-bootloader
So, in my case, I marked all the packages started with nvidia-l4t, hence can prevent this situation. But the reply from DaneLLL didn’t mark it hold, so it will not do the trick.
Considering nvidia-l4t-bootloader needs other packages, please don’t hold all the nvidia-l4t packages if you want to reproduce this issue. You’ll need to:
sudo apt-mark unhold nvidia-l4t-*
sudo apt install nvidia-l4t-bootloader
sudo reboot
(packges list: apt-packages-list.txt (764 Bytes))
After rebooting, you should be able to see Update Progress when it boot into UEFI.
Hi Kevin,
I will have access to the equipment today. I will be logging all the steps carefully.
Could you kindly let me know which commands should be run to gather as much information as possible? I would also appreciate details on when the UEFI changes and whether the kernel image is updated at the same time.
Since we have a custom camera driver and hardware developed by a third-party company, a kernel mismatch could cause our entire system to fail. Therefore, we are keen to update as much of the system software as possible before making any changes to the kernel.
Thank you for providing the details. Were you able to update the software without modifying the UEFI or kernel image?
Hi Andresc:
Yes. sudo apt-mark hold nvidia-l4t-* will do the trick.
Please just share the full serial console logs and the steps to reproduce the issue.
You can also check if the command shared from jameskuo could help in your case.