hangs at first boot at "waiting for unattended-upgr to exit"

Hi all,

my nano hangs at first boot at “waiting for unattended-upgr to exit”

Pressing cancel ends up in bootable system, so I guess no harm done.
I did have to remove some apt locks afterwards.

Anyone with similar issues?

Gr. Pim

I disable unattended upgrades. The very first time the Jetson boots it has a lot of upgrades to perform, and this takes a long time (after that it doesn’t take as long).


Is there a way to make sure the update is disabled before running the first install? I know how to do this in vanilla Ubuntu, but the Nano
seems to have customized first install screens.

If you download everything first and don’t actually flash, then you can edit the “Linux_for_Tegra/rootfs/etc/apt/apt.conf.d/20auto-upgrades” prior to resuming flash. That edit should stick around until the sample rootfs is unpacked again (I’m not sure when this rootfs update is triggered).

NVIDIA might want to consider adding that edit to the apply_binaries.sh step, but excluding the edit from sha1sum (and not doing any kind of blacklist on the package owning “/etc/apt/apt.conf.d/20auto-upgrades”). This would make sure unattended upgrades does not get in the way during install. That line should be edited to:

APT::Periodic::Unattended-Upgrade "<b>0</b>";

I had the same issue today and yesterday, so reading pimpim’s suggestion I cancelled. Oddly, it did not immediately result in a bootable system. Instead it brought me back to the beginning of the install where I set my keyboard layout, locale, and created a new user (again). Now that the system has booted I have two users. RN I am unsure of the state this image is in and am going to re-flash, and disable unattended upgrades before install as suggested.

I have had the same issue as well. What I found was that if I was connecting to a network on the initial startup screen and cancelled the first automatic unattended upgrade that the OS would not be happy. Bottom line cancelling is not a good idea. It appears that the auto-updater is already hard at work downloading and upgrading OS modules even while the rest of the Nano is still configuring itself. Cancelling during this period of time seems to leave the Nano in an undefined state with many broken updater links.

The first time through I thought I would cancel the auto-updater and then once the OS was running do the sudo apt-get update and upgrade in the terminal. Well long story short, I was plagued with issues wherein the problem reporting tool kept kicking in with detected OS issues even after I did a sudo apt-get update.

So the second time through (with a re-flashed SD) card, I did NOT connect to a network. The Nano booted up and was able to start the wireless afterwards and then do the updates / upgrades.

I found on my third time through that when I connected to the network on the initial startup and I let the auto update run it’s full course, I was presented a regular login screen but this took some time before I saw it. In my case about 40 minutes on a pretty fast network (155 Mbps download speed). Your mileage may vary. It would have been helpful to have some sort of a progress bar or to see the details to make sure something hasn’t stalled.

There is a details action on the updater but mine was grayed out and did nothing when clicked.

@nanojet55, you are correct. Auto update will run the moment the Jetson boots. In future flashes I personally plan to edit the rootfs and disable auto update before the flash ever starts. Or as an alternative, simply flash and don’t install extra packages until after the Jetson has had time to update.

Removing network access during the first boot is one way to keep the Jetson from knowing it needs upgrades, but I don’t know if there would be other issues (e.g., setting timestamps of files incorrectly for some date in the future…known as “martians”).

Package update is somewhat like a SQL operation. There are things needing rollback if something fails (without regard to failure by bug or via user cancellation). Even rollback takes time, and sometimes leaves the system unbootable.

If you download packages through SDKM, but don’t flash, then you have a chance to edit the auto update file in “rootfs/etc/apt/apt.conf.d/20auto-upgrades” before restarting flash as per #4.

Changing that auto upgrade to disabled during the “apply_binaries.sh” step might be a good option for NVIDIA. Having the package database locked out by an automatic update that takes an hour is going to be frustrating. You could in fact repackage “Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2” to include the “20auto-upgrades” file with auto turned off, and this would do the right thing every time (this is part of what apply_binaries.sh unpacks into the sample rootfs). Conversely, a mechanism could be put in place which understands being locked out and patiently waits while telling the end user what it is waiting for.


Is this issue resolved?

@wayne, it seems to be an intermittent issue for me. I’ve taken to unplugging Ethernet on first boot. I accidentally replicated last week when I forgot to do so.

Maybe unattended upgrades could be enabled on the second boot. It always seems to run at the worse times even on x86.

Hi pimpim,

Do you resolve this issue?

Hi all,

I just saw this discussion while trying to find a solution for exactly the same problem I had. Please note that “Waiting for unattended upgr to exit” DOES NOT mean the Jetson was frozen. Even those guys who primarily connected the Jetson board to the Internet through Wi-Fi or Ethernet, DON’T WORRY at all, just be patient for almost 30-45 minutes. The updater is updating the packages on the Jetson while they are in blind mode and NVIDIA did not provide the detail tracker for them, but it does not mean that it is hanged or frozen!
After the time elapsed for almost 45 minutes, the Jetson board will restart automatically and you’ll be able to see the main green page. This was my own experience in this regard. Hope it can help.


Yes this window takes a lot in my case it takes me about 25 minutes and then it restarts without problems.
The first time I thought that if it had been freeze but I waited and at the end the process finishes correctly


I am currently on 1st boot. Flashed my SD card, plugged it into the nano and proceeded with initial setup. I plugged in a waveshare wifi module before boot and it allowed me to connect to wifi during start. After that was done, I am currently having the same issue with stuck on “Waiting for unattended upgr to exit” it has been over an hour and now I get “[failed] Failed to start nv-oem-config-gui.service”

Anyone have any help?

Update: waited about 10 more mins. Restarted twice on its own and now it allowed for me to log in. Does this seem to be normal for it to hang up like this and then re boot correctly by itself?

Unattended upgrades will take a very long time. This is why I disable it before I flash since it interrupts the install process (often for longer than an hour). First boot should work the first time you can get to the login prompt.