Headless OS

Is it possible to install Ubuntu without a UI (headless) on the Jetson Nano? Also, is it possible to boot over the network?

+1

You can modify the root filesystem image prior to flashing. In that way you could pre-configure user accounts and any other system setup.

nice idea

Seems like this should be a standard configuration for an SBC, but when I tried:

systemctl set-default multi-user-target

the system wouldn’t event boot.

So why not?
Has anyone got this thing to boot to the command line and if so how?

+1

Made some progress here. Was able to get it to not boot to GUI, but also, it still doesn’t boot to a terminal on the display, which is fine for my application (I’m using SSH), but for anyone reading this DO NOT DO THIS UNLESS YOU HAVE ALREADY CONFIRMED YOU CAN LOG IN USING SSH. because you won’t be able to use your display as a terminal anymore. The main reason I wanted no GUI was to save what little memory I could and right now, I’ve got the memory USED to less than 500M. Here’s what I did:

  1. boot to GUI and open a terminal.
  2. run:
sudo systemctl enable multi-user.target
sudo systemctl set-default multi-user.target
  1. now reboot and connect using SSH

  2. OK we’ve cut out quite a bit of memory, but wait there’s more.

  3. kill stuff we don’t care about:
    whoopsie - sends UBUNTU crash stats
    unattended-upgrades - dowloads and notifies about upgrades
    modemmanager - handles cell modems and mms messages

    you can kill these and many more packages using the syntax of (where whoopsie is the package):

sudo apt --simulate purge whoopsie

which simulates the kill beforehand to see what happens and what packages will be affected.
and then

sudo apt purge whoopsie

to actually kill the doomed package.

  1. now reboot again and voila, you have linux using lesss than 500M

DISCLAIMER: It’s possible doing this will make your system NOT boot at all, so if I was you I’d make a backup of anything you care about before doing this. And NO I don’t how to recover if your system won’t boot.

If anyone knows how to make the display work as a console (like you could do in grub, if it was supported), please let me know.

1 Like

You can create your own file system that without GUI. Have a check to Ubuntu org to know how to build a file system for ARM.
For the boot over network please have a reference to the doc
https://docs.nvidia.com/jetson/l4t/Tegra%20Linux%20Driver%20Package%20Development%20Guide/getting_started.html#wwpID0E02B0HA

In case anyone is still looking for a better answer, here is what I did:

  1. Make sure you have a backup
  2. Make sure you have ssh enabled (on the card image it is, but make sure…)
  3. sudo vi /boot/extlinux/extlinux.conf
  4. at the end of the APPEND line, after the rootwait, add 3. The line now looks like:
    APPEND ${cbootargs} rootfstype=ext4 root=/dev/mmcblk0p1 rw rootwait 3

That’s it. Nano will now boot to text console on the hdmi display!!! Yay!

You can cycle through virtual consoles with ctrl-alt-F(1-whatever), This will even work to let you pop in and out of X. Not sure why the first is hung, maybe related to dri and text mode.

I think we were looking for a way to boot without the X environment to get more memory.

1 Like

Yeah, but he was saying the display was dead after turning off xorg and that’s probably just a hung tty from some wonky dri interaction with the console driver. but putting it in another run level works too.

Just FYI, there is a difference between booting without a GUI and booting without X. If you remove X, then much of the CUDA software which relies on this as a kind of glue between the GPU driver and CUDA will fail.

The GUI environment is when X runs a window manager and you plug in a monitor. You can run a virtual X server without a window manager and without a monitor and have CUDA use this and not care that the monitor and environment are “fake” and without GUI components. This is what virtual X servers are for (and you’ll keep the ability to use CUDA).

The GPU does not have its own memory, and so anything CUDA will use memory. You might see some tools listing that as X consuming the memory…which isn’t a bad thing if the X using that memory is CUDA and not a desktop manager.

This is slightly inaccurate. The x has two parts, server and client (which is misleading as the server runs on the client and client runs on the server…)
By booting into runlevel 3 we prevent the server environment from starting. You can still ssh -X to the jetson and have grapgics run on your screen.
Also, the gpu has its own (very fast) memory, 4gb in nano case.

Oh and this has nothing to do with cuda (well, not much), but mostly system resources in general

How were you able to boot into runlevel 3 / multi-user.target by chance? I’ve tried switching just now as I usually do with Ubuntu and it’s not working because systemd can’t find the unit files. An earlier poster reported the method working. @Nvidia, has support for this been removed?

edit: it appear this works:

sudo systemctl isolate multi-user.target

edit: only

sudo systemctl enable multi-user.target

wasn’t working. What I get for not reading the comments on the answer.

My method involved changing the boot file. Please look a few comments ago. It works better i think

Aha. I see what you did there. You added a 3 to the kernel flags to request runlevel 3. I think I prefer the systemd method if it’s all the same to you. I can’t find the file you edited on my Ubuntu desktop and it’s confusing for me to remember two ways to do things. Usually if i edit kernel flags I use /etc/default/grub, but I guess that isn’t what’s used on Jetson.

YMMV :)
Both works I guess.
Happy headlessing… Who needs graphics when you have VI?

:syntax on

is not so bad :)