I have updated my sources.list, apt update, apt upgrade, apt dist-upgrade. Then I get an error, which doesn’t go away with the suggested --fix-broken command. Here is what I get:
# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up nvidia-l4t-kernel (5.10.120-tegra-35.4.1-20230801124926) ...
Using the existing boot entry 'primary'
Info. Active boot storage: nvme0n1
Info. Legacy mode: true
Starting kernel post-install procedure.
Starting legacy update procedure.
ERROR. Procedure for kernel update FAILED.
Cannot install package. Exiting...
dpkg: error processing package nvidia-l4t-kernel (--configure):
installed nvidia-l4t-kernel 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)
It seems that the command that fails in the post-install is a call to /usr/sbin/nv_bootloader_payload_updater. If I try to call this directly I get this:
That tells me to download the QSPI image from a linked web page, but that page now refers to JetPack 6, not JetPack 5, and the archived JetPack 5 page doesn’t seem to have a QSPI image download that I can see. (Am I missing something?)
I hesitate to upgrade to JetPack 6 because it is only a “preview” and I would prefer stability over latest features. I note that the JetPack 6 preview doesn’t support “OTA” (i.e. apt) updates to future versions.
Is there any chance of upgrading to JetPack 5 by following the instructions that I linked to above?
The image is for 35.1, so I’m not sure if it works with 35.4.1; maybe not.
As long as you have a Ubuntu host PC, the safest way is still use SDK Manager to flash the device; that way, you can make sure version of QSPI bootloader and OS on SD cards are matched.
I’m currently downloading the SD card image - very slowly, over my amazingly-slow internet connection. However I realise that it is likely too large for the SD card that I currently have, which is 16 GB, and I don’t seem to have a larger one.
Remember that I have an NVMe SSD attached. So, I’m contemplating whether I can use the boot partitions from the new SD image and the root filesystem from NVMe.
I think this has a chance of working, but where does the kernel command line indicating the root device come from? How do I change it from mtdblk0p1 to nvme0n1p1? Is that hidden one of the other partitions in the SD image, like kernel-bootctrl, or something? (Another option would be NFS root.)
I also see that in my current old SD image there is a 105MB partition called RECROOTFS; is that a recovery root filesystem? If I create an SD card image with a truncated main root filesystem, can I boot with this recovery filesystem and get a prompt?
the easiest way would still be flashing with SDK Manager.
I understand, but please believe I’m not completely mad! I’m limited by e.g. having a Debian ARM, not Ubuntu, Linux host system that may or may not be able to run SDK Manager, and not having enough free disk space anyway. So I could, for example, install Ubuntu in a VM on my Mac, but then I would need to get USB forwarding to work.
You cannot mix bootloader and rootfs coming from different L4T releases.
The root FS on the NVMe drive is already upgraded to r35.4 using apt - but hasn’t been rebooted yet. If that is broken in some way, I could copy the FS from the new SD image to a new partition on the NVMe drive.
Any idea about where on the SD card image the kernel command line comes from?
Basically, flashing the new QSPI image from within the old system and then restarting with the JetPack 5 SD image does work.
It took me longer than it should have because:
I only had a 16 GB SD card, and the new image is slightly larger. So I decided to “hack” the image down to below 16 GB; I mounted it on another system and removed 3 GB of /usr/local/cuda stuff that I don’t need currently. But then, although I know in principle how to shrink the filesystem and partition, I managed to get it subtly wrong.
Then the network wasn’t working… and it took me an embarrassingly long time to realise that this wasn’t a missing kernel module or incompatible device tree, but rather than I hadn’t plugged the ethernet cable back. Ooops.
It took me a long time to discover where in UEFI I could add kernel command line arguments (i.e. root=/dev/nvmexxx). It’s in a sub-menu called “NVIDIA Resources”, or somesuch.
So I think that I now have functional system! Yay! Of course I haven’t tested everything yet so I may still discover bugs.