Dist uopgrade fails on l4t-bootloader

I tried a dist upgrade to LTS 4.4
The booloader configuration failed - which I think will mean a failure to boot.
Has anyone else seen this?

Setting up nvidia-l4t-bootloader (32.4.2-20200408182156) …
Starting bootloader post-install procedure.
ERROR. Procedure for bootloader update FAILED.
Cannot install package. Exiting…
dpkg: error processing package nvidia-l4t-bootloader (–configure):
installed nvidia-l4t-bootloader package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

Upgrading the release using the default Ubuntu mechanisms will cause a failure since that software has no knowledge of the boot requirements. You will need to flash the system again (you could clone first if you have something valuable there). To upgrade from Ubuntu 18.04 LTS to another release will probably require using JetPack/SDK Manager, which currently does not support newer releases.

The instructions seems to indicate it’s possible to upgrade OTA using the apt mechanism now


In the newest releases this should be the case. However, if the dist upgrade is not to 18.04, then I still suspect it would fail since the NVIDIA packages (especially related to boot) may not have 20.04 compatibility (and NVIDIA must supply those if there is hope of booting). NVIDIA would have to comment on dist upgrade to Ubuntu 20.04 (earlier this wasn’t around so even if it should work nobody would have tested it).

I think I’m trying to do the same as @hearnsj, that is going from 32 to 32.4 without creating a new SD card. Seems there should be a way to replace the bootloader on the jetson, but I haven’t figured out how. If I try to run /var/lib/dpkg/info/nvidia-l4t-bootloader.postinst manually, I can see the command to upload the bootloader.

$ sudo /usr/sbin/l4t_payload_updater_t210 /opt/ota_package/t21x/bl_update_payload

SPEC: 3448-300---1-0-jetson-nano-qspi-sd-mmcblk0p1
Compatible SPEC: 3448-300---1--jetson-nano-qspi-sd-mmcblk0p1

[R]eading 65,536 bytes of /dev/mtdblock0 at offset 4,128,768
[R]eading 65,536 bytes of /dev/mtdblock0 at offset 4,128,768
[R]eading 65,536 bytes of /dev/mtdblock0 at offset 4,128,768
VER number: 0
[R]eading 65,536 bytes of /dev/mtdblock0 at offset 4,128,768
[R]eading 65,536 bytes of /dev/mtdblock0 at offset 4,063,232
VER_b number: 0
[R]eading 65,536 bytes of /dev/mtdblock0 at offset 4,063,232
blob ver number: 320402

Error. Version number is corrupted. Exiting…

I can see the current bootloader version as follows:

$ sudo /usr/sbin/l4t_payload_updater_t210 --ver
SPEC: 3448-300---1-0-jetson-nano-qspi-sd-mmcblk0p1
Compatible SPEC: 3448-300---1--jetson-nano-qspi-sd-mmcblk0p1

1 Like

This might work, but I have no experience actually testing this.

Bypassing the skip old version check worked and it updated the bootloader without issue

        def _skip_check_old_ver(self):
        # if the version <= 32.2, there doesn't have VER_b or CRC32 yet,
        # should skip version check
        return True

Thankyou @bryanegge I might give this a go.
To be honest the instructions to just flash a new card are annoying. At home I have a physical laptop running Fedora/windows 10 dual boot and another laptop running Windows 10
Both of these are high spec laptops.
Last time I installed a Nano I had to boot a laptop with a USB stick containing Ubuntu, then run the flash utility. Which worked.

I would use the Windows Subsystem for Linuc but this does not seem to be compatible with the Nvidia tools, at least on WSL 1 which I am stuck at till my laptop gets an upgrade of the windows build.

I use Fedora most of the time as well. Sometimes I have a small laptop with Ubuntu 18.04 remote display to Fedora when I must use JetPack/SDK Manager.


…I think this might be an issue with Windows subsystem being an emulation without the full functionality of actual Linux (perhaps loopback issues, perhaps filesystem compatibility, so on…not sure).

Your solution worked for me, thanks for digging into it. :)

How do you incorporate this code to the update?

–nvm I found the line in /usr/sbin/l4t_payload_updater_t210