An update/update of JP 4.5.1 breaks the bootup to the Ubuntu Desktop

SBC: Nano 4GB B02
OS: JP 4.5.1

Ran into an interesting issue with JP 4.5.1. I originally had Jetcar software on a three WD robot chassis so I decided to do a clean install of JP 4.5.1, which installed without an issue, for another AI project.

After executing sudo apt-get update and sudo apt-get upgrade, the Nano 4GB would hang at startup and not get back to the desktop though I could SSH into the Nano. It looks like the Ubuntu 18.04 upgrade is breaking JP 4.5.1 desktop bootup.

Therefore I tried JP 4.6 and did an update and upgrade after the JP 4.6 install. The JP 4.6 desktop survived a reboot after the upgrade unlike JP 4.5.1.

apt-get upgrade will also re-install the BSP again to your board because apt source list has our OTA update serivce…

Which means your board will be re-installed again with jetpack4.5.1 OS.

Did you do any customization on your jetpack4.5.1 before hitting this issue? Even trying to boot from external disk is also one kind of customization.

Dumping a log from uart console may give more hint about what happened.

No. No customization whatsoever. Just rebooting from a fresh install of JP 4.5.1 after performing update/upgrade.

The question to be answered here is why update/upgrade does not affect JP 4.6 the same way?

Actually, jetpack4.5.1 has been released for months. But I didn’t hear someone who just hit boot issue by pure jetpack + apt upgrade. Most of apt upgrade issue come from customization.

Also, I can confirm that we ran apt upgrade on our jetpack 4.5.1 when this release came out. And it didn’t hit error.

We will try to reproduce this issue with jetpack4.5.1 again. To save your time, please dump the serial console log when you hit issue.

Comparing why JP4.6 didn’t happen this issue is a little pointless. That question is more like why a new software release does not have a bug happened on old release.
And the reason is possibly a obvious one because it is called “new release”…

Already moved on to JP 4.6 and I don’t want to have to burn a new SD card to troubleshoot JP 4.5.1.

The serial console as mentioned by @WayneWWW would provide more details about the failures at boot time, but as you’re able to ssh into the Jetson, it may just be an X server issue.
You may add

    Option      "ModeDebug"

into Device section of /etc/X11/xorg.conf and reboot, then post here the boot log from /var/log/Xorg.0.log that may tell what modes from your monitor have been found and accepted or rejected.
You may also post the EDID read from I2C for tegradc 0 (assuming first HDMI):

sudo cat /sys/kernel/debug/tegradc.0/edid

Ok, if you don’t want to debug this. How about we close this issue first? Since jetpack4.5 is already a old release, even if there is an issue, we would ask users to try jetpack4.6.

I think the issue here is the fact that I had previously installed Jetracer on this particular Nano and prior to that I had installed JP 4.5.1 and had experienced no issue with booting to the Ubuntu Desktop.

I believe, therefore, that installing Jetracer modified either the Nano kernel or the boot loader such that the subsequent removal of Jetracer and the installation of JP 4.5.1 would cause a boot up failure after an update/upgrade.

I have searched this form for this boot up issue and have not found any posts that are even vaguely similar to my issue. As I said above, I believe it is specific to the previous installation of Jetracer and then the subsequent installation of JP 4.5.1 on this Nano that is causing this issue.

Obviously JP 4.6 is immune to whatever the installation of Jetracer did to either the Nano kernel or boot loader as I was able to install and update/upgrade JP 4.6 and not have a boot up failure like I did with JP 4.5.1.

Yes, close this issue.

Just my suggestion here. If you want to have a fully re-flash board, you should use sdkmanager to install the whole BSP instead of using sdcard image. From your comment so far, it seems you are always using the sdcard image.

Sdcard image may lead to mislead bootloader version with kernel. It is theoretically wokring. But not validated in each release. If you need more detail about this, I could explain more.