Headless NoMachine Setup?

ARM
1

After starting this thread ( Remote Desktop Server: Best choice from official repo or AUR on Raspberry Pi 4 (4 GB RAM)? ), I installed nomachine from the AUR on @0n0w1c 's recommendation, and had no issues with it while I also had a monitor plugged into the Pi.

I’m presently trying to get nomachine to work with no display plugged in. It’s supposed to run in headless mode without any issue, but it appears to be unable to start Xorg, and therefore cannot start LightDM.

TL;DR: nomachine does not start its own Xorg server as its documentation indicates it is supposed to, thus LightDM never starts, thus XFCE cannot start, so there’s no desktop to connect to.

TL;DR 2: I know I could install the xf86 dummy driver and trick the machine into thinking there’s a physical device connected to get it to start Xorg, but the nomachine documentation indicates that should not be necessary, so I’d love to try to get it working as the developers apparently intended.

Put another way:

  1. The modesetting driver doesn’t load, as the system does not find any physical screens to connect to.
  2. Xorg does not see any displays to connect to, so it doesn’t start.

I’m using this tutorial here:
https://wiki.archlinux.org/index.php/NoMachine#Headless_server

In particular, these two bits:

Headless server
If no X server is running on the server, NoMachine starts its own X server (DISPLAY :0) and tries to run a /etc/X11/Xsession script to get the user into the default DE. This fails in Arch Linux (you get only a black screen) because an Xsession script does not exist.

To resolve this issue, edit the key DefaultDesktopCommand in /usr/NX/etc/node.cfg. E.g. for MATE desktop environment:

DefaultDesktopCommand “/usr/bin/mate-session”

Separate NoMachine X session in parallel with existing X session
In default setup, the Free edition of NoMachine connects the client directly to an existing X session on the remote computer, even if it runs the X Display Manager only. This may be unwanted, because no other user may use the target computer locally at the same moment and because any person with physical access to the target computer can see on the physical display, what the remotely connected user is doing.

However, it is possible to setup NoMachine to check only for a particular DISPLAY, e.g. DISPLAY :10 and it will ignore the existing X session on DISPLAY :0 (standard setup in Arch Linux) and start a new virtual session for the remotely connecting user.

To do so, edit the key PhysicalDisplays in /usr/NX/etc/node.cfg:

PhysicalDisplays :10

I followed these directions, except I used the following command to try to start XFCE.

DefaultDesktopCommand “dbus-launch --exit-with-session /usr/bin/startxfce4 &”

AvailableSessionTypes unix-remote,unix-console,unix-default,unix-application,physical-desktop,shadow,unix-xsession-default

This doesn’t work. Xorg is failing to start, so it doesn’t surprise me it can’t start XFCE. If Xorg can’t start, LightDM doesn’t start, and so there’s nothing for XFCE to sit on.

Any ideas?

1 Like
2

Can you share some more information about your setup? Drivers? Display Manager? Desktop Manger?

nomachine works fine for me with default settings, but there can be issues with nvidia drivers…

3

Thanks, @SimpleTechGuy . I’m on a Raspberry Pi running the standard Manjaro ARM XFCE image, so there’s not a lot of room for variation.

Display Manager: LightDM on top of Xorg
Desktop Environment: XFCE
Driver: It’s supposed to load the mode setting driver. Right now it’s not doing that, since the Xorg server is not starting correctly.

4

ahh, I’ve never used arm version, does it come with the mhwd utility? If it’s anything like the regular version then you might try using the video-linux drivers. Right now for me it’s the only thing that really seems to work out of the box (nvidia not working for me, never tried it with the modesetting drivers from mhwd).

This should give you video-linux drivers

mhwd -a pci free 0300

Also you might want to make sure you don’t have any other display drivers installed.

If you need modesetting and have an Intel chip then you can go to your /etc/X11/mhwd.d/ or /etc/X11/xorg.d/ (note sure which one is the right location, probably the xorg.d folder) and create a file 20-intel.conf. For modesetting just put this in the file and save. This really helped me with screen tearing.

Section "Device"
   Identifier   "Intel Graphics"
   Driver       "modesetting"
EndSection

After that reboot.

Then just to be sure you don’t have any messed up config files anywhere complete remove nomachine:

sudo pacman -Rsn nomachine

then reinstall nomachine (I use yay, or whatever you’re using to get aur files). Make sure you redownload the newest version and not use the one in cache just in case.

yay -S nomachine

For this I have:

DefaultDesktopCommand /usr/bin/startxfce4

A couple of notes:
…I do have a TV plugged into the machines, but the TV is off (I think the power cord to the tv is unplugged too)… Not sure if this is somehow tricking the system or not. I know there was also some posts about purchasing a dongle which basically accomplishes the same thing as the dummy drivers (which I never had any success with the dummy drivers myself either)
…There might be something that needs to be done to LightDM (maybe PAM related)… I really can’t remember but someone else might have input on that.

5

Thanks for your reply.

The ARM version is very different. There’s no mwhd, for one thing, which makes a lot of the wiki’s hardware troubleshooting guides kind of sketch for this kind of install.

The only driver I have installed at the moment, since I don’t actually have a monitor plugged in, is the dummy video driver. It’s just enough to get the Xorg server to think there’s something plugged in and start up.

The Pi does not use an Intel, AMD, or Nvidia graphics subsystem.

I’m concerned about this output from inxi -Fazy:

Graphics:
  Device-1: bcm2711-vc5 driver: vc4_drm v: N/A bus ID: N/A chip ID: brcm:gpu 
  Device-2: bcm2711-hdmi0 driver: N/A bus ID: N/A chip ID: brcm:soc 
  Device-3: bcm2711-hdmi1 driver: N/A bus ID: N/A chip ID: brcm:soc 
  Display: server: X.org 1.20.10 driver: N/A note: display driver n/a 
  tty: 255x63 
  Message: Advanced graphics data unavailable in console for root.

It looks like it’s not loading any graphics driver right now.

I did uninstall nomachine–I’m not confident I didn’t change something that made it not work, so I’m going to try starting over there. I’m not sure, but from reading the official forums I got the sense that headless operation is not well supported on the Pi.

This has already wasted hours for me today, so I’m pretty frustrated. I just want a GUI for the random occassions when I need to use certain configuration tools that don’t have easy command line equivalents. Like, I really need to get at timeshift so I can fix my snapshot schedule, but lol.

6

Sorry I couldn’t be of more help. That arm stuff is a bit over my head…

Have you looked at x2go or X forwarding over SSH? X forwarding might be just what you need. Or if you have a secure connection to the machine (vpn or local network) you might be able to use xhost

And don’t feel alone messing with nomachine headless, that’s what I’ve been doing all day today too, trying to get nvidia drivers to work… that’s how I found your post lol…

1 Like
7

No need to apologize. I appreciate your help.

x2go or SSH forwarding would be ideal. However, my client machine (a Mac) makes that difficult, as the local X server/client packages are ancient and not compatible with the latest Mac OS. I’m waiting for them to update, then I’ll try it again…

The most aggravating part of all of this is I don’t even need a GUI except for like, 30 minutes a week.

I want to use the Pi to run micro services like Pi-Hole and a few other things.

Mostly I’d just like to be able to pull up nomachine so I can tell timeshift to stop spending half the day taking snapshots of a system that barely changes, and figure out why deja-dup isn’t working at all.

But instead I’ve sat here now for hours screwing with Xorg, which has suddenly forgotten how to load display drivers … or … something.

8

Gotcha… Well another option might be to spin up a linux vm on the mac and use that for shh forwarding? But I just tried to run timeshift with ssh forwarding and it didn’t work… so that might not be an option either…

Anyway, good luck to you bro. Hope you get it figured out!

10

Oh, just had one other thought… Seems like you’re having a different issue alltogether, but just in case you should make sure you have xorg-xauth install for headless access:

xorg-xauth: allows logging into a headless machine
11

Update:

I got very mad, reinstalled nomachine from the command line, rebooted the Pi, and everything worked perfectly.

Well, the screen is stretched bizarrely and looks terrible, and performance needs to be tweaked, but I can actually remotely log into the my desktop.

Running a portscan on the server, I can see there’s now:

  1. an X11 port open, which is new; and
  2. a DNP port, which also wasn’t there before.

I have no idea, but it seems reinstalling it without a monitor hooked up allowed it to open some ports it needs for headless mode.

I’m still getting this from inxi, which seems a nonsensical result. @Darksky might have more insight on why this says there’s no driver loaded, yet display works.

Graphics:
Device-1: bcm2711-vc5 driver: vc4_drm v: N/A bus ID: N/A chip ID: brcm:gpu
Device-2: bcm2711-hdmi0 driver: N/A bus ID: N/A chip ID: brcm:soc
Device-3: bcm2711-hdmi1 driver: N/A bus ID: N/A chip ID: brcm:soc
Display: server: X.org 1.20.10 driver: N/A note: display driver n/a
tty: 255x63

Given how frustrated I was when I tried it again just now, I’ve got a sinking suspicion I fixed it with the power of the dark side. (Or, you know, giving a fresh auto-configuration-on-install a chance to work.)

1 Like
12

Man I can’t tell you how many times I’ve done that… LOL … Excellent work, glad you were able to get access. Now just don’t ever touch it again and it should work forever! hahaha

1 Like
13

That’s the truth. LOL. Back away slowly, and don’t blink.

But. It’s not working at 60 fps, which bothers me, and the Vulkan drivers aren’t loading.

Neither of these impacts my immediate goal of being able to use the admin utilities, but I’m technically not done. :stuck_out_tongue: I’m certainly done until the lack of 60fps or 3D acceleration becomes a problem, though. :stuck_out_tongue:

1 Like
14

I believe you are now our resident expert for nomachine on arm. Keep up the good work! :slight_smile:

15

Hi there, I’m new to Manjaro on ARM and would like to know how to install NoMachine.
I have the OS installed on my pi 4 atm! My other pi allows me to use nomachine without fuss on a different OS! Could you advise which file and method I should be using?

Thanks

16

You will need to activate the AUR repository and install nomachine 7.1.3-1. I use pamac-manager to install packages from the AUR.

17

I believe you are now our resident expert for nomachine on arm. Keep up the good work!

#andThenWeWereDoomed

One oddity I’m continuing to run into–and this may be a client issue–is that NoMachine does not remember my screen size settings when I open a new session, and defaults to the largest possible setting. I can manually change it to 1080p, but it’s a bit annoying.

Hi there, I’m new to Manjaro on ARM and would like to know how to install NoMachine.
I have the OS installed on my pi 4 atm! My other pi allows me to use nomachine without fuss on a different OS! Could you advise which file and method I should be using?

I’m not sure if pamac-manager is the same as just using pamac from the command line, but you’ll want to check out the instructions here, in any case, to get a handle on the language of pamac.
https://wiki.manjaro.org/index.php/Pamac

If you’re using the default GUI Pamac tool, you’ll need to go into the settings and enable the AUR, as @0n0w1c notes.

I used the Pamac CLI instructions and searched for “nomachine,” using the AUR search tag, and then built it. Read the wiki instructions carefully and you should be fine.

One thing: decide up front if you’re going to go headless (no physical display) or use the machine with a monitor plugged in. On build/install, NoMachine runs an auto-config script I do not entirely understand, but the tl;dr is that if you let it auto-config for a plugged in monitor, it will never work headless until you uninstall it completely via pamac and reinstall it with the build command.

EDIT: @vindikator , if you get this working, could you please let us know if you needed to install the extra/xf86-video-dummy 0.3.8-4 package as a pre-requisite? I already had this installed on my system, but I’m curious if the auto-configuration will fire correctly without it installed. It should, as nomachine has no mechanism for installing it for you, for what I can tell, and the nomachine docs mention it only as a fallback when the built-in X server thing doesn’t work.

18

So, I wanted to try something different. Some issues:

  1. As noted above: vulkan was not working in the previous config, and openGL performance was noticeably degraded vs. remoting via nomachine into a device with a monitor plugged in.
  2. I don’t really like having to tinker with dummy drivers to get graphics working. It’s not hard, but it’s also fairly impenetrable, and can create issues that aren’t always easy to troubleshoot. (e.g., @Strit looked into installing the dummy driver and adding the hardware configuration file for the fake dummy monitor as part of the default install to make headless installs easier, but it crashed under some circumstances and wasn’t suitable.)
  3. With this config, nomachine absolutely refused to remember what screen size I wanted it to use. It defaulted to a screen size slightly bigger than my monitor’s actual resolution, and when I tried to lock it in place, acted unstable.
  4. With the dummy plug in place, Xorg should always start, whether I’m using VNC, nomachine, or something else.

Experiment: I bought an HDMI dummy plug and an HDMI-to-Micro-HDMI adapter to hang off the actual HDMI0 port. The idea being that the Pi should see the dummy plug as an actual 4K monitor, and correctly start Xorg.

  1. Uninstall nomachine. No idea if this is necessary, but in all honesty I wanted to see what the autoconfiguration script would do with the physical dummy plug.

  2. Uninstall the dummy driver and delete its configuration file in /etc/X11/… LightDM failing to start, as usual, tipped me off to the problem. I had to uninstall the dummy driver and delete the config file for the dummy monitor.

  3. Xorg correctly starts with the device plugged into the Pi. No software trickery needed. Here’s the output from inxi -Fazy via SSH. Sidenote: I don’t remember seeing that particular driver before, or the chip ID. Is that new stuff with the latest Manjaro/5.11 kernel update?

    Graphics:
    Device-1: bcm2711-hdmi0 driver: vc4_hdmi v: N/A bus ID: N/A
    chip ID: brcm:fef00700
    Device-2: bcm2711-hdmi1 driver: vc4_hdmi v: N/A bus ID: N/A
    chip ID: brcm:fef05700
    Device-3: bcm2711-vc5 driver: vc4_drm v: N/A bus ID: N/A chip ID: brcm:gpu
    Display: server: X.org 1.20.10 driver: modesetting alternate: fbdev
    tty: 255x63
    Message: Advanced graphics data unavailable in console for root.

  4. Use your favorite AUR tool to build nomachine. If you’ve never used AUR before, you’ll need to enable it in the GUI package manager, or just use the CLI: pamac build nomachine. You may get an error about CUPS support not being enabled. I’ve not set up a printer on this machine, so I have no idea if that would go away if there was a printer installed.

  5. Reboot

  6. Check to see if the nxserver service is running. A running nxserver should look like this.

~]$ systemctl status nxserver

● nxserver.service - NoMachine Server daemon
Loaded: loaded (/usr/lib/systemd/system/nxserver.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2021-02-22 22:08:39 CST; 7min ago
Main PID: 442 (nxserver.bin)
Tasks: 38 (limit: 4246)
Memory: 155.2M
CGroup: /system.slice/nxserver.service
├─442 /usr/NX/bin/nxserver.bin --daemon
├─804 /usr/NX/bin/nxexec --node --user lightdm --priority realtime --mode 0 --pid 50
└─814 /usr/NX/bin/nxnode.bin

  1. Check to see if LightDM is running. It is.

But there’s a problem. Nomachine is not listening on port 4000 … or any other port. Obviously, it’s not going to work this way.

So, we’re almost there. I’m going to report back at some point this week if I figure out what’s wrong.
EDIT 1: nxd, which is absolutely necessary for remote access, is not enabled.

  1. Attempt to restart the whole nxserver. sudo /usr/NX/bin/nxserver --restart . If you’re lucky, you’ll get a message to the effect that nomachine is now listening for remote connections, and a port scan will show an open port on 4000 (“NoMachine NX Server remote desktop 7.1.3”).

  2. Now you should be able to connect. Set up the connection as normal. As far as the client is concerned, it’s never been to this server before.

  3. Set up the server. Use the client to pull up the server’s settings. Under the Ports section, make sure automatic startup is enabled. You’ll need to give it your password for this. Leave “advertise” enabled. Adjust Security to your preferences. There are some recommendations in here for headless users. Enable hardware acceleration under Performance. Under Updates, disable the automatic update installer. I have no idea what would happen if it tried to update itself without using AUR. Use AUR. You like AUR. There is only AUR.

  4. Nomachine will tell you to restart the server for changes to take effect. Click the words. It will restart.

  5. Send your good vibe energy into into manifesting a successful restart.

  6. Did it come back? Congratulations! You are victorious!

Outstanding Question: I have LightDM enabled and running, with XFCE. I’m not sure you need LightDM, but I think you do as with the hardware dummy plug inserted nomachine isn’t running its own X server. I think. Anyone have any thoughts on this?

This post is very long now. See next post for some results.

1 Like
19

Outcome. Overall, this is better, and gets rid of a lot of the performance degradation I was seeing before.

  1. glxgears is correctly locking to 60 Hz again, by default. It’s hovering around 59-60 FPS, capped at 60 FPS.
  2. picom (compositor) is correctly applying all compositor effects again. Whether you want them or not. But this was not working with the dummy driver.
  3. vkcube works. Vulkan works again.

For better or worse, this is now working just like it was when the Pi was plugged in with an actual physical HDMI connection to my TV.

Here’s inxi -Fazy from inside nomachine:

Graphics:
Device-1: bcm2711-hdmi0 driver: vc4_hdmi v: N/A bus ID: N/A
chip ID: brcm:fef00700
Device-2: bcm2711-hdmi1 driver: vc4_hdmi v: N/A bus ID: N/A
chip ID: brcm:fef05700
Device-3: bcm2711-vc5 driver: vc4_drm v: N/A bus ID: N/A chip ID: brcm:gpu
Display: x11 server: X.Org 1.20.10 compositor: picom v: git-dac85
driver: modesetting alternate: fbdev display ID: :0.0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2")
s-diag: 582mm (22.9")
Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 102
size: 480x270mm (18.9x10.6") diag: 551mm (21.7")
OpenGL: renderer: V3D 4.2 v: 2.1 Mesa 20.3.4 direct render: Yes

Bonus 1: If you shock your Pi because you dragged your feet on carpet, it will restart.

Bonus 2: This looks ridiculous and I’m not convinced it won’t eventually put enough stress on the HDMI plug to kill it.

69D070C6-0284-4745-9803-470EFD41A9CF_1_105_c
69D070C6-0284-4745-9803-470EFD41A9CF_1_105_c1024×768 197 KB
848924C6-1D5F-4881-81C2-5055F19A7D58_1_105_c
848924C6-1D5F-4881-81C2-5055F19A7D58_1_105_c1024×768 212 KB

3 Likes
20

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.