Unable to boot after upgrading to Ubuntu 16.04 on Jetson TK1

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

Hi there,

I totally missed this forum before attempting to upgrade my Jetson TK1 board from Ubuntu 14.04 to 16.04… so I treated it like any other Ubuntu upgrade and ran…

sudo apt-get update
sudo apt-get upgrade
sudo do-release-upgrade

Now it won’t boot anymore, on start-up it will show an error

Failed to start Load Kernel Modules
See ’systemctl status systemd-modules-load.service’ for details

And then show a cursor on top-left of the screen and hangs.

How can I fix this?

I only found the following article after it happened:
https://devtalk.nvidia.com/default/topic/1036457/jetson-tk1/how-to-successfully-update-jetson-tk1-to-ubuntu-16-04/

Thanks!

Daniel

2

Unfortunately you will need to flash the unit again. The Ubuntu mechanism for upgrade does not understand boot requirements, and would also fail to use the NVIDIA-specific drivers needed for direct hardware access (e.g., even if it worked, then there would be no more CUDA and no more hardware accelerated OpenGL). You could clone the rootfs if you want to save what you have (the clone can be loopback mounted on a host PC, examined, copied, so on).

If interested in cloning, then see:
http://elinux.org/Jetson/Cloning

3

Thanks for prompt reply. I’ll try cloning and flashing the unit. I have never done it before. Quick questions:

  • Can I use VMWare Fusion running Ubuntu as the host machine?
  • Is the flashing instructions from “step to step for flash JETSON TK1 ?” still valid? It’s been almost 3 years since that answer was posted.
4

VMs are not supported, but some people do get them to work. The problem is that during flash the recovery mode Jetson will repeatedly disconnect and reconnect from USB, and a VM tends to fail to keep ownership of the device (the parent o/s tends to interfere). If you can get around that through configuration, then you can use a VM. You will find many threads on these forums about different VMs.

The TK1 is basically end of life other than maintenance. You can still purchase third party TK1 devices, e.g., from Toradex, but these are the only available TK1s. The instructions are still valid.

Do note that JetPack is only a front end for other installation details. The actual flash is a combination of the “driver package” and “sample root filesystem”. If you were to use JetPack to flash, then JetPack would download those two packages, unpack them, run apply_binaries.sh, and then flash. The optional packages which JetPack installs are a separate step from flash and occur after flash has completed and ssh is available. You can manually flash on command line, and then at a later date add additional packages through JetPack (you’d need to deselect flash).

I mention this because the latest JetPack for a TK1 is JetPack3.0:
https://developer.nvidia.com/embedded/jetpack-3_0
…and this would install L4T R21.5, but there is a patch update L4T R21.8. Major L4T release changes are incompatible with the “optional packages” of other releases, but the packages you can install from JetPack3.0 are compatible with L4T R21.5 through R21.8.

If you are interested in command line, then the various releases are listed here, and within each release you can get documentation for flashing and other details:
https://developer.nvidia.com/embedded/linux-tegra-archive

Should you flash on command line you will find the same problems with a VM which would also be found using JetPack in a GUI environment, but you could flash from other distributions, e.g., from Fedora (some oddball distributions enable some ext4 64-bit extensions by default, and you might need to edit to exclude those, but most distributions do not enable 64-bit ext4 extensions as a default and will all work without effort).

The use of command line goes something like this:

  1. Download driver package and sample rootfs (usually a “tar xvfj package.tar.bz2”).

  2. Unpack the driver package as a regular user (usually an “sudo tar xvfj package.tar.bz2”).

  3. cd to the “Linux_for_Tegra/rootfs/” directory and unpack the sample rootfs with sudo.

  4. cd back to “Linux_for_Tegra/”.

  5. Run “sudo ./apply_binaries.sh”. From now on the flash software is set up and you can flash as many times as you want without repeating the previous steps.

  6. Put the TK1 in recovery mode, connect the micro-B USB cable, verify you see the recovery mode TK1 with any output from “lsusb -d 0955:7140”. Flash:
    sudo ./flash.sh jetson-tk1 mmcblk0p1

Note that you need a lot of disk space. The image alone will end up taking about 16GB of host PC disk space, and other content means you probably should have about 22GB of space before you consider unpacking packages.

1 Like
5

Thank you so much for the details! I will probably find a physical machine with Ubuntu to do it then, just to make the process a bit smoother.

6

Hi @linuxdev - Would you have any recommendations for which laptop to use as Jetson TK1 host machines? I understand I just need a PC that runs 64-bit Ubuntu 14.04 but…

Reason I ask is that I just realised it’s not actually a simple task to parallel install Ubuntu on my MacBook Pro, and I foresee more problems with trying to install an old Ubuntu version (14) on a new hardware (2019 MBPs).

I did find an old laptop that could install Ubuntu 14.04 and then I realised I actually need 64 bit machine for the host, but mine is 32 bit.

7

You are correct that it just needs to be an x86_64 or amd64 compatible system. I’ve even used a little dual core Atom laptop (don’t laugh too hard…I did remote display to my desktop PC running Fedora, and the Atom is 64-bit) for flash under JetPack/SDKM.

If you are sticking to the TK1, then you do probably want to run Ubuntu 14.04 (though I don’t know if 16.04 works differently or not…I went straight from 14.04 in the 32-bit days to 18.04 later on without trying 16.04).

There have been some really rare cheap laptops or NUCs which had USB issues, but as mentioned, this is quite rare. Most anything will work. If the screen is too small, then you can scale the GUI of JetPack down, or do ssh to the laptop with remote forwarding to a computer with a larger monitor.

I couldn’t swear that a 32-bit i386/i486/i586/i686 would not work, but there are all kinds of issues you could run into with this. If you happen to already have one it wouldn’t hurt to try, but if you are making a purchase, then I would suggest sticking to 64-bit.

8

Hi @linuxdev again - I’m glad to report that I was able to use a 32-bit machine as a host to flash the Jetson TK1! And then I followed How to successfully update Jetson TK1 to Ubuntu 16.04 to upgrade Ubuntu from 14 to 16, that also worked! Thanks for your help!

Question… I flashed using R21.5 (mainly because I saw someone did it in this blog post and provided detail instructions: Flashing Jetson TK1. The following steps will provide… | by Ailurus Fulgens | Medium ) and I want to follow the simplest setup to confirm that my host machine works. Now that I confirmed it’s working, I don’t mind to flash it again with R21.8. However I’m wondering if it would make any difference since I’m going to upgrade to Ubuntu 16 anyway? As in… would the upgrade overwrite any fixes/benefits brought in between R21.8 and R21.5, since they’re all based on Ubuntu 14?

2nd question… I think I want to install the additional packages that JetPack 3.0 offer, in particular I think it would make the wifi work (is it?) So I want to ask if I should attempt to run the JetPack and install the optional packages before or after the Jetson TK1 Ubuntu 16 upgrade?

Thank you!

9

I’m not positive, but I think the majority of patches going from R21.5 to R21.8 were security related. I have no idea how much of that was from NVIDIA-specific content, versus Ubuntu content.

In the case of NVIDIA-specific content, then those files probably still remain once upgraded to Ubuntu 16.04 (and would most likely be security upgrades). These files would still be relevant since they would not be provided by Ubuntu.

Some of those files may be from Ubuntu packages as well, and any 16.04 upgrade would replace those. In this case there would be no reason to upgrade to R21.8 prior to migrating. I suspect though that not all of that content is part of Ubuntu, and so my advice would be to bite the bullet and use R21.8 prior to the upgrade.

I do not know if those additional/optional NVIDIA content will work after upgrade. It is possible that you will lose that content. On the other hand, you can always reflash if it fails. My personal preference would be to add the package prior to the migration, but there is no way to know if they will work after migration unless you actually test and find they work. Understand that 32-bit went into maintenance only mode long ago, and that although those packages will work up to “R21.8”/“Ubuntu 14.04 LTS” that there is no guarantee of compatibility once upgraded (there are a lot of dependencies tying releases of optional packages to the rest of the operating system).