How do I start Ubuntu desktop?

I bought my first Jetson TK1 a month and a half ago. The first time I turned it on after connecting the HDMI, a keyboard, a mouse, speakers and network cable, it dropped me on the command line after logging in. I was hoping it would take me to the Ubuntu desktop. It didn’t. I read through enclosed direction - no help there. I typed “startx” at the command prompt. That just gave me a blank screen. Then I tried Alt-Ctrl-F1 through Alt-Ctrl-F7. I get six TTY screens but no desktop. That’s when I jumped online and began my research. After a few “sudo apt-get updates” and a “sudo apt-get upgrades”, that didn’t help either. Then I did a “NVIDIA-INSTALLER” and a “./install.sh” plus a reboot", well that didn’t work either. Finally I tried a 19.3.0 upgrade and I still cannot get to Ubuntu desktop.

I did some more research, watched a few YouTube videos, made a few adjustments and guess what - it still drops me at the command line! I was about ready to give up when I decided to buy another one because EVERYTHING I have read and have seen says just plug it in and turn it on and - BOOM! - you at the desktop. So I bought another Jetson TK1, brought it home and plugged it in and guess what? I get the command prompt. The new one goes back tomorrow.

What’s wrong with the Jetson TK1 that it won’t let me get to the Ubuntu desktop?

You probably should be able to just plug it in and have it work. Several people have had trouble with the HDMI cable itself. If you use any kind of adapter to older VGA, this is even more of a problem. What is your exact cable+monitor combination? Also, have you checked logs in /var/log/ ? Especially the Xorg log. Finally, does “sha1sum -c /etc/nv_tegra_release” show files are ok?

I have a two-month-old Samsung 24" wide-screen monitor that supports resolutions up to 1920 x 1080. The monitor supports both VGA and DVI. I have a HDMI-to-DVI cable that I used to get the video to the monitor.

“sha1sum -c /etc/nv_tegra_release” reports all 35 files as “OK”.

How do I “check” the /var/log/? What am I checking it for? What do I use to check it with? And the same goes for the Xorg log. I am not familiar with either one of these logs.

DVI to HDMI should work. Even so, people have had hit and miss luck on HDMI cables in general. If you have an alternate cable, be sure to check with that, but what you give so far seems like it should be ok.

/var/log has files in it which might provide clues. In particular, file /var/log/Xorg.0.log is specific to the graphics server. I personally tend to use “less” to view those files, e.g., “less /var/log/Xorg.0.log”.

There is one particular line in DVI and HDMI (but not analog VGA) which replies to the video card and video driver to tell it which modes are supported…if this line is not working for any reason, display will likely fail. This includes adapters which use only the analog features of DVI…sometimes a DVI to HDMI will skip this line. So you are interested in finding out if this line is connected in your current setup. This is the EDID information, and debug information is provided in package “read-edid”; the command to show if the EDID information is present:

read-edid | parse-edid

Find out if it replies with a known monitor setting or if it claims no EDID is found…the latter would be a symptom of the cable/adapter using only analog information.

I “lessed” out the /var/log/Xorg.0.log file and I, honestly, could not understand what it was attempting to tell me in the 100-200 lines it printed out on my screen.

I hooked my brand-new Asus 4K monitor with it direct-connection HDMI port. I got the same thing. Here’s what I see: after logging in, I type “startx” at the command line. I assume that’s what I’m supposed to type to start Ubuntu Desktop. (Please correct me if I’m wrong.) I see the NVidia logo flash across the screen momentarily. Then I get a desktop background picture with no icons, no bars, no nothing. I can use Alt-Ctrl-F1 to get back to the command line to shutdown.

At this point, do you think I should pursue the “read-edid” package installation or not?

Sounds like your libglx.so is corrupted.
https://devtalk.nvidia.com/default/topic/775070/embedded-systems/notice-on-apt-get-upgrade-libglx-so-corruption/
First… id check if it is by running this.

sha1sum -c /etc/nv_tegra_release

if it says something like… /usr/lib/xorg/modules/extensions/libglx.so failed, then this is the issue.

Id suggest first putting the bad package on hold with this.

sudo apt-mark hold xserver-xorg-core

then downloading the Linux 4 Tegra files with this…

wget https://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/Tegra124_Linux_R19.3.0_armhf.tbz2

then extracting (just google tbz2 unzip)
and then copying the libglx.so and to fix the bad one.
do do that… use cp.

cp Linux_for_tegra/nv_tegra/nvidia_drivers/usr/lib/xorg/modules/extensions/libglx.so /etc/nv_tegra_release/

Or something to that effect.

PS: Id suggest installing the Grinch Kernel (https://devtalk.nvidia.com/default/topic/766303/embedded-systems/-customkernel-the-grinch-19-3-6-for-jetson-tk1/) because it (1) would fix the issue (still remember to hold that bad package) and (2) has drivers and a few more features and stuff. (and allows you to just the full 16gb or so of eMMC rather than the 8gb thats been partitioned.

Do you think somebody here in the forums might have understood something of it? Would it have made sense to attach the log to your post here?

Have you check the kernel logs (either through the serial cable or with “dmesg”) to see if there are some errors related to the matter? And in case you don’t understand what it is attempting to say, please attach the log to the post.

If you have “ubuntu-desktop” installed (I can’t remember if it’s pre-installed or automatically installed with the installer script in 19r3), you shouldn’t need to run “startx” as by default a graphical login manager is started on boot.

If you don’t have login manager starting up on boot and you run “startx” you get blank display as nothing else is started than the X.Org and it has black background by default.

He has already done sha1sum -c /etc/nv_tegra_release, and it was all Ok. Directly connecting the HDMI cable should also eliminate any cable adapter issues, although many HDMI cables are still suspect.

Some information might be in order though for new users…instructions tend to be outdated, and often refer to earlier versions of L4T. So far as I know, all versions have shipped with R19.2 pre-installed, including the graphics desktop…startx should not be required. Some of the steps in instructions are obsolete and should not be required from a running system. Possibly flashing to R19.3 would help.

The EDID program is for diagnostics and can only add information which helps, there is no risk for installing it. It is a basic step of figuring out what the X11 server is seeing. It would also be useful to see that X11 log; if you are using a serial console you should be able to record the entire bootup and perhaps paste logs here (note that in forums you can highlight your text and make it look like a code block with the upper right corner icon “</>”…useful for logs and quoting commands).

It is too early to know what is really going on without the above information. The cable still comes to mind as an issue, although lack of a HDMI-to-DVI adapter dramatically lessens this as a suspect. Any steps in documentation which were out of date could have actually caused issues as well, in which case flash is probably needed (this isn’t difficult and is a good idea anyway because of the number of issues fixed). Should flash have already been attempted, I would suspect failure from not running as root during flash or using a non-linux filesystem on host. There is also the possibility of actual hardware failure as well, but we need more information…especially the Xorg.0.log right after a clean boot and without running “startx” (pre-installed R19.2 and upgrade R19.3 both do this for you and no manual startx should be attempted).

If more information is needed on how to post logs, please ask…mention which serial console you are using from what host operating system.

Ok, guys, I’ve remained in the shadows long enough. My name is Jim Tomlinson. I work at Micro Center with 25 stores throughout the US. We sell the Jetson TK1 kits. About two years ago, I fell in love with the Raspberry Pi and wrote the Raspberry Pi class that is taught at all 25 Micro Center stores so our customers would know how to hook it up and use it. Over the last two years, I have added other electronic development boards to the class, including BeagleBone Black, pcDuino, Galileo, Propeller Board of Education and Matrix Mini PC. Now I am trying to add the Jetson TK1. Here is what you must understand – in all cases, these boards all suggest the first thing you should do is run “apt-get updates” and “apt-get upgrades”. So it was only natural that the first I do is execute those two commands with my new Jetson TK1. If that act screws up the video driver/library and the instructions in the box are outdated, then we are in trouble. How is the general populace going to get this board to work right out of the box? I have been trying to get this little board to boot to the Ubuntu desktop for a month and a half.

I would love to add this board to my class but before I can do that, I must be able to understand these problems I seem to be going through with this card. Also, I must be able to advise my customers as to how to get the board to work properly. So let us begin: First of all, why are you so concerned about my HDMI cable/connection to my monitor? Is the Jetson TK1 THAT sensitive to the HDMI cable and/or monitor? Or does the Jetson TK1 only support a limited number of resolutions and screen refresh rates?

Second, you had me check the /var/log/Xorg.0.log file? What is this file? What does it do? Why is it important? (I don’t every recall working with or looking at this file with any of the other half a dozen Linux/Ubuntu-based boards I have worked with.)

Third, you had me “sha1sum” check the nv_tegra_release driver/library. Is this what is corrupted if you do a “apt-get upgrades”? (Apparently I need to protect xserver-xorg-core from being updated/upgraded according to the reference forum article.) Also there was mention of a corrupt libglx.so file. The article when on to say “If you do have corrupted libglx.so, look in the Tegra124_Linux_R19.30.0_armhf.tbz2 archive you used when flashing L4T. It will be located at Linux_for_tegra/nv_tegra/nvidia_drivers/usr/lib/xorg/modules/extensions/libglx.so. Copy that over to the corresponding location on your Jetson.” What he failed to mention in the article was how to do that from the command line. Could you enlighten me, please?

Finally, and this is the most important point, can you help me develop the PROPER step-by-step procedures for starting up a brand-new Jetson TK1 for the first time, what should be seen and how you should update the software/firmware properly via the nVidia website (i.e. download 19.3.0 and burn it to a USB flash drive or SD Card, insert USB or SD and reboot system or something like that.) Can you help me with that? I think others would enjoy having those procedures published right here. What do you think?

There is a lot of incorrect information due to dated documents. The L4T distribution has been around for many years, and although L4T is often treated as “for Jetson”, Jetson is only the most recent newcomer. My tegra 3 development system was based on L4T many years back…even so, nVidia has never used L4T as a commercial end-user product…instead L4T is used as a means for hardware vendors and software developers to understand their technology and give developers a fast start. Expect parts of L4T to be excess baggage from other related products, in need of Jetson tweaking. I’ve actually turned in some suggested documentation changes to nVidia L4T maintainers, and I believe documentation will probably change in a near-future release (minor changes would be a great reduction in support workload).

In terms of video issues found on this forum, it seems to divide into one of two categories: Video cables which should work but do not, and OpenGL or other files related to video in graphics mode (this latter being the reason for starting this thread).
EDIT: https://devtalk.nvidia.com/default/topic/775070/embedded-systems/notice-on-apt-get-upgrade-libglx-so-corruption/

About OpenGL and related files: nVidia does not provide their proprietary hardware acceleration files in the same files as the linux distribution (L4T is Ubuntu for embedded). This probably is a great simplification of life for nVidia, but requires care in dealing with files of the same name and location as those in the wild of the Linux GPL world. Most of the time this is not a problem; in the case of the glue between X11 and accelerated graphics, libglx.so, it is possible for one single GPL package to overwrite this. Best solution would be if nVidia were to package its proprietary files as a .deb package…then a standard Ubuntu package would know it can use nVidia’s version, and that non-nVidia files are not allowed to overwrite nVidia files. Even so, L4T works with multiple nVidia hardware, and so doing this to simplify Jetson could complicate other hardware using L4T (or simply based on L4T). The current tar archive is not ideal, but there is only a single .deb package in all of their packages which would cause this problem.

HDMI video cables in general have been shown by actual users to be a significant cause of failure on Jetson. How much of this is Jetson versus cables I do not know. What is known is that HDMI has multiple versions and has evolved and changed significantly in recent years. The same cable which works in one case may fail when using a newer standard. This is the acid test…several people have swapped cables and things suddenly worked.

Something many people do not seem to realize about video in general is that your graphics cannot simply “work” without knowledge of monitor timings. The old VGA has signals available on most modern cable types (DVI, HDMI, etc), but when used as purely VGA, no data line exists which would allow the video card to query the monitor and ask the monitor what works for it. In the case of no automated query, a human user must manually inform the graphics subsystem what modes and timings to use. There can be common modes for VGA, and the graphics drivers might default to something common and the two will live happily ever after, but this is purely luck. The DDC/EDID (query) must exist and must be used for graphics and monitor to coexist without human intervention.

So the first test is to look at the logs and see if there is a complaint by the graphics driver and/or X11. If there is, then knowing the cable works for this version of HDMI is half of the testing. The sha1sum command will instantly tell us if the proper graphics glue is in place to use graphics, and the EDID software will tell us if the monitor is replying. If any one of these things fail, you could use the old phrase “the lights are on, but nobody is home.” In the case of all three of these working, but graphics failing, it is time to move on to RMA and hardware failure.

Additional information on “sha1sum -c /etc/nv_tegra_release”: nv_tegra_release is a list of fingerprints for nVidia-provided files. File names can be misleading, it’s nice to have fingerprints instead. It is probably good to do the apt-get upgrades, it is better to verify after this if something nVidia provided needs to be put back in place…something fingerprint checksums will answer.

As for “Tegra124_Linux_R19.30.0_armhf.tbz2 archive”, the nVidia files were combined into a tar file archive, and then compressed with bzip2. The name simplification/abbreviation to suffix “tbz2” was probably from the windows world, whereas mostly in linux it would have been a “.tar.bz2” suffix instead. Reversing means decompressing with bunzip2, followed by separating out files with tar. Pipes are a convenient way to leave the original untouched and still do this, e.g., to list:

bunzip2 < Tegra124_Linux_R19.30.0_armhf.tbz2 | tar --list

To actually unpack the file tree:

bunzip2 < Tegra124_Linux_R19.30.0_armhf.tbz2 | tar xv

Within that tree is the nVidia version of libglx.so. There are many ways to copy it to Jetson. One of them is to put it on a USB thumb drive or SD memory card; another is the ssh command “scp” to secure copy; you could even put it on a linux web server and use wget from Jetson. If you use linux scp is the most convenient, YMMV.

One final catch to all of this succeeding: Many of these files are system files and normally accessible only to root (or root authority under sudo). Failing to preserve file permissions during all of this would be the equivalent of doing only half of what is required, even when it looks like it was all done…there is only a thin line between a corrupt file and a file with permission denied.

Several threads have been created for information on parts of everything. A “check list” thread would be useful, but mostly it would need to be an index into other threads. General check list of knowledge:

  • How the documentation is wrong.
  • How the documentation is right.
  • About the version Jetson arrives with.
  • About boot loader options and flash.
  • About kernel versions and flash.
  • About "gotchas" during flash.

It seems current driver still has bug with 4K displays.
I’m using SE39UY04 4K display and there was noise on the desktop screen.
There was no noise in console screen and 1920x1080 display mode desktop screen.
I’m still not updated my system(using Tegra124_Linux_R19.2.0) after I got my Jetson tk1, but adding following line to /etc/rc.local solved my problems.

#Disable EMC scaling to avoid the 4K corruption
echo 0 > /sys/module/tegra12_emc/parameters/emc_enable

(/etc/rc.local is a script file executed when linux boot)

If you still don’t get desktop, 1920x1080 display mode might work.
This command add xrandr command to .xprofile file which is executed when Xorg start.

echo xrandr --output HDMI-0 --mode 1920x1080 >> .xprofile

When you try native display mode, remove above command from .xprofile or rm .xprofile file if there is no other command in the file.

Dear Linuxdev,

Thank you for your detail explanation and answers to my questions. My next day off is Friday and I will try then to implement some of the things you said I should check (re-examine the logs, execute a sha1sum and use edid).

I will also pick up a high quality HDMI cable at Micro Center tomorrow.

I will let you know the results but I still do not know how the get the log list from the Jetson TK1 boards and into this website.

Finally, to clarify an issue: I do not use the serial port or any other port to control or view the board remotely. I work with the board in the standalone mode.

Ignore everyone who says its the HDMI cable, yours is fine. You previously stated that it works and that things display on screen. You even go as far as to say,

The HDMI cable is fine (or HDMI-DVI cable if youre using that).
Your 50$ gold plated HDMI cables work just well as the 5 dollar one Ive had for the past 8 years.

Is this you stating the jetson said there was a corrupt file, or are you just reading this on the ‘article’?
If it is… in the post 5 thousand words up, there are instructions on that.

I thought the instructions were fairly clear. All commands were to be ran on the jetson (there was no mention of any other device), so there is no need to copy them ‘to’ the jetson.
That was said with this.

cp Linux_for_tegra/nv_tegra/nvidia_drivers/usr/lib/xorg/modules/extensions/libglx.so /etc/nv_tegra_release/
cp {source file} {destination folder}

Yes, i did leave out the unziping part, simply because I dont know those commands off the top of my head. Which is why i suggested you google them and exactly what to google.

If you need to get logs from the jetson to another PC, it would be suggested to… Use a Serial port to access the terminal. Connect it to the network and use ssh to access the terminal. install a software such as Shellinabox and access it through your web browser.

And on to the last point about creating a class for this board... the Jetson is a development board. Its not a finished, mass-market product. The raspberry pi, on the other hand, is. Someone who buys a Pi, might need these classes to use it, or to use it 'better'. But again, thats not what a Jetson is for. Its like teaching someone to ride a bike with a $4k racing bike when all they need is something with relatively round wheels.

Forgive my cliche, but its not meant for usage by joe-schmo thats walking on the street. It would be a hard sale for me to sell the Jetson to this ‘joe-schmo’ instead of a Pi. We could talk about how the Jetson is more powerful… But its also ~5x more expensive. Oh yes, the Jetson runs a variant of Ubuntu too, which according to Canonical, and is estimated to have 20 million users worldwide! But wait! Theres more! According to W3Techs, Ubuntu is used by 26.1% of all Linux Websites. And… Debian is first. Which is what the Pi runs (modified ofc) But waaait again! Debian was created from Ubuntu! Holy Jeeebus. That means that Ubuntu and its variants are the top 2 ranked Linux operating systems for websites!!! WAHHAAAAT?!

And on top of that (theres nothing really there), the Pi has accessories for people to purchase. Cases, Micro-controller shields, umm. (more stuff as i dont really know what else it has)
And what does the Jetson have? Well, its got its 192 cuda cores.

Well, To me it sounds like the software is all the same, right? So to me, hey, a 35$ Pi sure seems to beat out the 200$ Jetson.

But meh. Thats just my thoughts on people trying to swim in the middle of an ocean.

About the serial port…

This is simply the little DB-9 connector, and you can either connect a null modem DB-9 cable from it directly to your host, or if your host does not have a DB-9 serial connector, you can get a USB cable with a DB-9 at one end (and then connect null modem cable between that and Jetson). There are many free and good serial terminals, and it is just like a text-based network connection. This connector shows right from the moment power is on, whereas video requires a driver to be loaded and will not show useful information until remote network is able to log in. The HDMI (when working) will not show output until long after the serial port is giving useful information. Even better, you can record serial port output to a log file.

Some serial port programs are minicom, gtkterm, PuTTY. Settings 115200 8n1.

scp can be used to copy log files from one machine to another, or just copy and paste a page at a time.

Turpinator: I think you are selling the Jetson TK1 short. You stated “the Jetson is a development board. Its not a finished, mass-market product” is correct. I know that now - after I have purchased the board and played with it. But still…

The FIRST thing that attracted me to the board was all of the I/O pins! Over a hundred of them! And how many does Raspberry Pi - 17. Now let’s say I wanted to turn strings of Christmas lights on and off to Christmas music. The Raspberry Pi can handle 13 strings of lights; the BeagleBone Black can do 40 strings of lights; but the Jetson TK1 can probably be reprogrammed to handle 80 to 100 strings! Now we are talking! And it has a much more powerful processor. It can boot from eMMC, SD Card or mSATA SSD! Wow! Everywhere I look the Jetson TK1 impresses me.

And, no, I don’t want to hook it to a serial port so it can be controlled but another computer. To me, that is a step backwards as far as I’m concerned. I’d rather work directly on the board itself. Don’t ask me why - I just prefer it that way.

Linuxdex: I re-ran the “sha1sum -c /etc/nv_tegra_release” and it reported all is well (OK) with all entries (including libgllx.so).

How would I include my /var/log/Xorg.0.log into this reply windows? I looked at it again, and saw where it loaded libglx.so. No complaints other than a (WW) (warning) stating it is “Falling back to old probe method for NVIDIA”.

How do I load EDID on my Jetson board and run it?

With checksum ok, you know nVidia files are in place and software should function if other conditions are met.

Having libglx.so load means X11 itself started. Falling back to old probe method does not seem to be a problem, although it would be useful to see what it thinks your monitor’s information is.

You will probably have to use apt-get to install package “read-edid”. This provides get-edid, parse-edid, and edid-decode:

apt-get install read-edid

Once you have done the apt-get install of read-edid, run either one of these on a command line:

get-edid | parse-edid
get-edid | decode-edid

Mostly you are looking to find out if provided replies from the monitor are in a format the software understands…once in a great while a new monitor comes along that the edid software needs to update for parsing. If this works without error, then you know your combination of cable, software, and monitor/video pairing is good.

If networking is installed, it’s easy to just ssh via PuTTY (free) on windows and use it to copy and paste, or even use the “secure copy” (scp) in it to copy from Jetson to windows. You can plug in a thumb drive or SD card and copy to that…if auto mount is working it will show up under /media/ubuntu/something. Copy using sudo cp since log files are privileged. Be sure to “umount” the mount point before removing the drive.

I do highly recommend a serial null modem cable…it makes a great deal of information and access available.

linuxdev: Thank you the serial port explanation. I am sure there are a few people in our audience who truly appreciate it. As for me, I have been working with serial cables, ports and RS-232 signals as far back as 1976 when I hooked up my first Mits Altair 8800 computer to a Teletype machine. (I even remember what RS standards for in RS-232.)

I also worked at Intel Corporation when the first USB proposal came across my desk for review. I thought it was brilliant albeit too slow. I wrote a note back to the engineer who developed the proposal stating that I thought it would be better to boost the speed of data transfer rate up to 25 Mbps instead of the 12 Mbps. But, alas, they went with the slower speed because of the proposed equipment to the supported: keyboards and mice.

Anyway, if I need to review the start up messages, can’t I just “dmesg | less”? When I did that, I saw some interesting lines with hdmi information in them. So I ran “dmesg | grep hdmi” and saw where the hdmi_state_machine_set_state_1 when through five states then reset itself waiting for an HPD reassert. Would be happy to share this data with you if I could figure out an easy way to get it out of the Jetson TK1 and inserted into this little reply window on my PC.

Finally, I’ve noticed that 1 minute and 40 seconds after I login at the command line, an application starts running. It starts off with “* Starting early crypto disks…”. It goes on to say “* Setting up X socket directories…” and then “* speech-dispatcher disabled; edit /etc/default/speech-dispatcher”. What is that all about?

I’m not near my Jetson or linux host as the moment, so I have to go on memory. YMMV. This is a full linux distribution, not something cut back for this specific device. You’re seeing a bootup sequence with all kinds of capabilities, including testing of ones not enabled. I remember the speech dispatcher one, it’s just a service not yet set up. In addition to this, linux supports various forms of encryption, so it looks for encrypted disks…even if you didn’t add any. X11 in general uses a lot of socket type services, I don’t know which ones you are seeing, but this tends to be standard.

As for serial port…the ability to copy files over is why I keep mentioning it. When you log in from a serial port, your terminal can be told to log it all to a file on your host machine…anything you see in your session you can then copy and paste out of a log file on your host. Viewing dmesg would be the same in a serial terminal as having a copy on your host.

One thing to be clear about as more than just a serial port convenience is that serial terminals have access during boot, and is especially useful under u-boot (which has boot options like multiboot available). The operating system has not even started…you can still clearly see information about the health of the hardware…failure to start the linux kernel can be viewed and logged…none of this being visible under dmesg because linux has not even begun yet. Certain system failures can be dealt with under serial port as well, even when the rest of the system has crashed hard and painfully.

I dug out my Dell laptop that I loaded with Ubuntu 13.10. It also has a serial port on it, but I have no idea where I would find a null-modem serial cable. OMG, I haven’t used one of those in years so I guess I will have to buy one while I am at work tomorrow. (Had you every heard of Micro Center before? If you are in California they are very similar to Fry’s Electronics.)

Anyway, I will try to get my laptop hooked up the Jetson TK1 boards over this coming weekend and play with a bit to see what it has to offer. Does Ubuntu 13.10 have a built in serial port window I could open and watch the Jetson TK1 boot up in?

Finally, I tried to install read-edid but I get an error. Here is what I see on my screen:

sudo su -
root@tegra-ubuntu:~#apt-get install read-edid
Reading package lists… Done.
Building dependency tree
Reading state information… Done
E: Unable to locate package read-edid
roor@tegra-ubuntu:~#

Suggestions?