UEFI bios update stuck after debian based update to 5.1.2 from 5.1.1

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

I just tried the debian based update procedure on my Jetson Xavier NX and there seems to be an issue. After following the steps described in the document and doing the power cycle, the UEFI bios starts up, shows an upgrade progress bar, which gets to 11% and then stops, seems to reboot to the normal UEFI bios startup screen, which then boots into Ubuntu. But when it gets there I get a GUI that tells me that in order to complete the update process, I have to reboot.
When I do this I again get the UEFI update screen, which gets to 11% etc.
This seems to loop around forever, so I assume that there is an issue with the UEFI update side of things.
Does anybody have any information how to complete the upgrade process to Jetpack 5.1.2 successfully.

This is on a Jetson Xavier NX dev kit with the system booting from an NVME SSD, not the SD card.

I previously installed Jetpack 5.1.1 via SDK Manager, but I was loath to follow this route again as it should also update via the Debian route.

BTW: The date for the used UEFI bios on the UEFI bios screen shows a march date. I assume that this means that it is still running the old UEFI bios, not the new one.

Update: Just tried to do the update using SDK Manager and now I have a different issue: The installation seems to ignore the size of my SSD (250GB) and install itself in a 14 GB root partition, closely followed by some system level partitions and then a 235ish GB unused space section. This then leads to issues with installing the additional packages. Nothing that I do in SDK manager seems to change this behavior (its the latest available version). I can’t remember having this issue with the 5.1.1 install that I also had to do with SDK Manager (after the debian install messed up the update from 5.0 to 5.1.1, if I remember correctly).

Does anybody know how we can get SDK Manager to use the full capacity of the SSD?

Update 2: Just to check that I’m not crazy, I just reinstalled Jetpack 5.1.1 on the Jetson Xavier NX devkit and that one does fully utilize the SSD’s capacity. So there seems to be an issue in the Jetpack 5.1.2 scripts used by the SDK Manager that causes this underutilization of capacity.

Hopefully NVIDIA will patch this in the near future.

Update 3: if I now use the debian based update procedure, I’m back again to my original problem (of infinite UEFI update attempts that fail at 11%)

3

Hi pieterjan.kuyten,

Are yous using the devkit with eMMC or SD module?
It seems the SD module one but you don’t put SD card inside?

Could you help to share the full update logs after you run sudo apt dist-upgrade?

I will check this internally and get back to you.

4

Hi KevinFFF,

  1. its the SD version and I don’t have the SD card in the reader. I wanted the speed and size of an SSD, so I added a Samsung 970 Evo Plus 250 GB in the NVME slot. Before boot from NVME SSD became available via NVIDIA I used the JetsonHacks method to boot from SSD. But since every Jetpack update that was released came with a lot of hassle with that method, I switched to the official one as soon as that became available.
  2. I’d be happy to provide them, if you can tell me where to find them
  3. Would be appreciated, because the new UEFI BIOS fixes a bug that blocks access to the UEFI setup, which the new one solves, but I don’t want to sacrifice 230 GB of storage just so that I can access the UEFI setup.
5

Could you try to put a SD card in slot but still use SDKM to flash into your NVMe?

After you run this command ,there should be many logs showed on your serial console to indicate it’s doing upgrade. Please share these logs for further check.

Actually, you could also enlarge the size of NVMe SSD after boot up into the system.
Or refer to the following workaround.
JetPack 5.1.2/L4T 35.4.1 is now live - #9 by kayccc

6

Hi KevinFFF,

I also added a comment about my problems to the release message of JetPack 5.1.2 and another moderator (after first telling me to make a specific post about my issues, which is this one) answered there with the following suggestion:

— start of suggestion —

kayccc

By further investigating, the root cause is that the layout used to flash external device is changed to “flash_l4t_t194_nvme.xml” from “flash_l4t_external.xml” in “nvsdkmanager_flash.sh” for T194 device.

This only affects the customer who is using SDKM to flash device on T194 device. For customers who use initrd flash to flash device, there is no effect.

For the customers who want to extend the size of APP partition on external device for T194 device, here is the workaround:

Flashed the device. If customer has flashed device before, skip this step.
Find the “nvsdkmanager_flash.sh” under “~/nvidia/nvidia_sdk//Linux_for_Tegra/” and replace the “flash_l4t_t194_nvme.xml” with “flash_l4t_external.xml”
Re-flash the device

— end of suggestion —

After a bit of extra work to find the script (since the path was not completely correct) I’m now trying out this suggestion.

Regarding your 3th remark, I thought about that too, but the root partition is placed at the start of the SSD and then is followed by a number of partitions that Disks and other partition management tools don’t know the type of, followed by the remainder of the unused space. None of these tools allow me to move the unknown type partitions backwards, so I can’t extend the root partition.

7

Yes, I saw that, please try with that workaround if it could help in your case.

8

Hi KevinFFF,

After a bit of trial and error (first I discovered that I needed to change the xml file at two locations and then I discovered that I needed to start the creation of the flash image over again, but with the modified script file in place during creation, which I achieved by starting that process, pausing it a.s.a.p, editing the script file for the xml filename and then unpausing the process), I’ve now managed to get the JetPack 5.1.2 update to use the total capacity of the SSD.

So the workaround above works. But it would be nice if future updates would include this fix (or a fix) for this capacity issue be default!

BTW: the issue regarding the terminal not working that I posted for 5.0.2 is still present. The solution in that post still works, but a permanent fix would also be welcome!

9

Thanks for your updates.
Yes, the fix should be included in the later release, I will keep tracking about this issue.

10

Well, thanks a lot for this post and everyone who’s been tinkering to solve the issue

In my case it was only not being able to extend partition size after flashing. in fact the APP Partition Size dialog doesnt even appear in the post-install without the workaround. after a couple days battling myself with gparted, this worked out…

somehow I got it done on my first attemp but I must admit its not very well explained:

1 Open SDK Manager
2 Plug your device via USB
3 Setup installation and get everything downloaded/installed UNTIL you get the next pop up window for flashing configuration (pic below)
4 Go to the folder mentioned. This is in your host PC under “~/nvidia/nvidia_sdk/Jetpack_5.1.2_Linux_JETSON_NX_TARGETS/Linux_for_tegra/”
5 Find the script “nvsdkmanager_flash.sh” and search for .xml links to files. You’ll read something like “flash_l4t_t194_nvme.xml” and needs to be replaced for “flash_l4t_external.xml” in the three places in the script.
6 Save and close the script file
7 Go back to the flash pop up. Fill it accordingly (Im flashing to USB)
8 Go on with the installation.

After flashing, the board gets rebooted and runs the post OEM installation config for language, keyboard, etc, and now APP Partition Size window too

Thanks for being active and solving issues. Issues in Jetson boards are really frustrating and nothing common to usual Linux issues

20230818_194450
20230818_1944501920Ă—1440 151 KB

1 Like
12

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.