Why would I want to do that? Long story. The short of it...

I have a couple of low end Intel NUCs on which I have installed Ubuntu Mate 20.04 beta (yes beta but everything I have tested so far works great). I plan to run them headless. I will access them as needed with VNC. I installed x11vnc and configured it to start as a service with systemd. So far so good. I can connect using vinagre on my CentOS 7 workstation. And then I disconnected the monitor

My remote connection displays a resolution of about 800x600. More research lead me to the package xserver-xorg-video-dummy which I installed. I then edited /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

Next I added an /etc/X11/xorg.conf file which sets the resolution which I desire. Actually I just copied and example I found in some documentation. I can now boot and connect to a display with a resolution of 1680x1050 (the values in the sample config file). Life was good but then I connected a monitor

The monitor displays an Intel NUC splash screen after bootup. I can Ctrl-Alt-F1 to get to a terminal so all is not lost. Based on my experimentation removing nomodeset from the grub parameter options (and of course running update-grub) has no effect. If I leave nomodeset, rename my xorg.conf and reboot I get the expected display on the connected monitor. If I must, for diagnostic/repair purposes attach a monitor and boot the system I can boot once, from the terminal rename xprg.conf and boot a second time to the desired gui. But that is not elegant.

Is there an option I can add to the boot command line interactively to either ignore the xorg.conf or disable the dummy display created by xserver-xorg-video-dummy?

TIA,

Ken

Hmmm …… currently you're running headless - with a monitor.

If you're serious about being headless, remove the monitor. And why run X at all?

1 members found this post helpful.

I think this is just a wrong approach (but probably I'm wrong). Something similar happened to me. I think X will not be started at all if no display present (=when you disconnect your monitor).
In such cases vinagre cannot connect because there is no X session to connect to.
I don't really know which vncserver you have and how did you configure it, but there is a way to start X when a vnc client connected Obviously it depends on the vnc server itself. There is no need to modify boot parameters at all.
I want to make it work too, but currently I can't tell you the solution.

Actually I configured both systems with monitors attached, put the first one into its "production" location (stacked with a couple of other mini PCs) and booted it headless. That is when I found the resolution issue. I have been experimenting with both that one and the other which is on the bench with a monitor attached as I worked through the resolution fix. Thus I noticed the problem with an attached monitor. As I stated, I might at some point need to temporarily attach a monitor to a NUC which is configured with the dummy monitor etc.

This NUC needs to run a gui as it will be used as a BitTorrent client using transmission-gtk. The second NUC will be a gateway, firewall, router, VPN sharing box. It will probably be run without a GUI. Currently I have Rapsberry Pi3B+ boxes serving these functions.

Ken

transmission works without gui, using a remote web client. see transmisison-daemon

Thanks pan64,

I was going to save the rest of the story for another thread but...

I have been using VNC for at least 20 years. I still have no real idea what I am doing or how the configuration works. The x11vnc server allows viewing and interaction with the "console" of the computer just as if I was sitting at the physical machine. I use this on my wife's PC so when she calls out "how do I ..." I can ssh to it and run x11vnc as root then share the display. The other way, which I have always preferred, is to make believe I am connecting to a "real" computer (i.e. a mainframe), invoke my own X session and do my thing independent of what ever else is happening on the console.

On the Raspberri Pi computers I am running Ubuntu Mate 18.04 and vnc4server. The Pi's runs in multi-user (character) mode. I have a script on the Pi which I can call over an ssh connection to launch the vnc X session. That allows me to set the resolution. The total mystery in this approach is the ~/.vnc/xstartup script. This is created when vnc4server is created. It does NOT work. I have created a working xstartup by tweaking various examples I have found. I have never found a decent reference to explain what the various lines really mean.

I use the same approach on 3 CentOS 7 file servers. In their case, even though they are set to default to the multi-user target I find that if I connect from vinagre without running the script to create the desired X sesson, they present a lower resolution graphical display. I think the hardware and OS vendors are trying to make it too easy to run a gui I have not tried adding the nomodeset option to the servers.

Back to the NUCs... Ubuntu Mate 20.04 does not offer vnc4server. The option is TigerVNC. I was not able to get this running and it had no xstartup script. I tabled that for later investigation and fell back to x11vnc which will serve the purpose. I guess I need to 1) take the dog out for our afternoon walk as it is somewhat sunny but with 30 - 40 mph wind gusts and it is supposed to rain later this afternoon and 2) setup a test environment and figure out how to run TigerVNC.

Ken

Thanks again pan64,

I have read about the transmission service. However, my normal practice is to 1) connect to a VPN 2) launch Firefox 3) Locate the item I am looking for 4) Use the magnet link to bring the torrent into Transmission 5) close Firefox and let the torrent run.

This works well (and I have a job running in background which checks for the presence of the VPN connection once per second and will killall transmission-gtk if the VPN drops. Never mind why

Ken

Did you check if Xvfb works for you?
I made a trick: when I click on a magnet link (in firefox) a shell script will be started which will pass everything to the transmission daemon (on another headless RPi server).

If Usenet would come back to life there would be no need for BitTorrent

Because you are using Intel GPUs, you have available what I normally consider a misfeature, but for your needs it should amount to a plus. Instead of using xorg.conf, put the mode you wish used on the kernel cmdline in the form video=wXh. AFAICT, it's supposed to apply only on the vtty framebuffers. However, only when using the Intel DDX (particularly excluding the modesetting upstream default DDX normally preferred for most Intel GPUs), X will inherit the mode thus specified. With all other DDX, Xorg will ignore cmdline video=. When you wish to boot with it not used, delete it from or misspell it via the E key at the Grub menu.

Thanks mrmazda,

I will look into that option.

Ken