A boot error occurs after installing gnome. I created an Ubuntu bootable USB to initialize the TX2 and try to reboot, but this is not possible

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
,
1

We purchased the Nvidia JETSON TX2 Developer kit and installed gnome to drive the Velodyne LiDAR 80-VLP-16-A on the self-driving robot car Clearpath Jackal.
After that, when Jackal powers on, a boot error appears every time and ‘[FAILED] Failed to start Light Display Manager.’ and ‘[FAILED] Failed to start Snappy daemon.’ appears.
And like an infinite loop, it is automatically moved to tty1 and tried to solve it with various commands, but the screen flickers and is unstable without being able to type commands in the tty related window. (It is unstable even if we open tty2, tty3, etc.)
Even if we wait a long time for the tty to stabilize and run GUI by entering the command sudo startx’, it does not work normally, such as only the background screen and black screens that can perform other functions.
Open a terminal (the terminal screen looks black at this time, but I just typed in the command) and type ‘sudo dpkg-reconfigure ubuntu-desktop’, the wallpaper turns black and the icons are visible. But the wifi connection doesn’t work and it doesn’t work properly.

To solve this problem, we thought that initialization was the best way to solve this problem, but it was impossible to access it.
To solve this, we created an Ubuntu bootable USB. However, even if we plugged the created USB directly into the jackal, Ubuntu was not reinstalled, so I tried to open the BIOS window. We pressed F2/F10/Delete, etc., but the BIOS window does not appear. In the meantime, Jackal freezes and restarts, but the BIOS cannot be opened.

How do I reset Ubuntu boot USB to TX2 and reinstall Ubuntu? Which button do I need to press to open the BIOS window to make the USB recognized? If I have to enter a command, it takes a long time and is difficult to get out of the tty and open the terminal, so I am curious about any other method other than entering the command.

2

I think you’ll need to flash with a new install (you could clone first if you want to know what was there), and I cannot provide a fix. However, you might be interested in some information on the topic.

Embedded systems do not have a BIOS/UEFI. Most of the non-rootfs partitions are essentially the content of the PC’s analogous CMOS content. The bootloader itself is something “other than” GRUB, because one has to present a standardized boot environment from a PC motherboard to allow that bootloader. A TX2 uses U-Boot as the final boot stage, but there are other early boot stages. Opening the BIOS is impossible because none exists.

If you really want to debug this, then you probably need to provide a serial console boot log. See:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/

In terms of some other software being installed for a GUI causing problems, then this is often because that package overwrote the NVIDIA-supplied hardware accelerated versions of direct rendering software.

Conversely, if something in X itself was overwritten to use a different GPU access library, then it absolutely must be of the correct ABI release. Upgrading X in such a way that it uses a different ABI release for graphics will cause the NVIDIA libraries to stop working.

In some cases the issue is just overwriting a symbolic link, and this can be fixed by putting the symbolic link back in. Details may change depending on your release version. In most case NVIDIA libraries in the “/usr/lib/aarch64-linux-gnu/tegra*/” location will be left alone, but content somewhere in “/usr/lib/xorg/” will be overwritten. For your case I can’t tell you which file to look at, but odds are fairly high that if X itself was not changed in release version, then one of the files somewhere under “/usr/lib/xorg/” could be fixed by replacing the generic version with a symbolic link to the “tegra/” version.

Because this is not a PC with a BIOS the instructions for booting to non-eMMC content differs depending on hardware and release version. You’d end up flashing again to set up external boot in some cases, but if you look at the documents specific to your release, then you might see a way to set up the first partition of your USB SATA drive to boot from that. Basically it would be a copy of a default rootfs install going to the partition, but the “/boot/extlinux/extlinux.conf” would be modified very slightly.

Right now I would suggest that you must have a serial console cable and be able to get a serial console boot log if you want to continue to debug. Otherwise, if you value the content on the drive, then you want a clone. The clone can be examined, edited, flashed as a substitute to the generic rootfs, so on. Clone information can change depending on release, and you do need a lot of hard drive space (think about 35GB per clone, and if you copy it to the location used to flash it, then another 30GB or so). If you want to know more about clones, then just ask, but be sure to say which JetPack/SDKM/L4T release you are using. Also state if this is a custom carrier board or the development kit.

Note that a serial console works before Linux ever loads, and works in Linux even when a large part of it has crashed and burned. If for example all you needed was to change a symbolic link, but the GUI does not work, the text console does not work, and ssh does not work, then very likely serial console would still work.