Why My Ubuntu Server Would Not Boot Without a Monitor
Introduction
After a routine Ubuntu update and reboot, one of my homelab servers became unreachable whenever it was running without a monitor attached.
At first I assumed this was a simple networking issue. What followed was a troubleshooting journey involving NFS mounts, Docker dependencies, systemd service ordering, and ultimately a hardware quirk in an ageing Intel NUC.
This article documents the investigation and the fixes that were required before the server could reliably boot in a fully headless configuration.
The Symptom
Following a system update and reboot, my Ubuntu server became completely inaccessible via SSH whenever it was running headless (without a monitor attached).
If I connected an HDMI monitor and logged in locally, networking would suddenly begin working and SSH access would be restored.
At first glance this appeared to be a networking problem. In reality, several separate issues were contributing to the failure.
Issue 1: Network Storage Blocking the Boot Process
The first problem was caused by network file system (NFS) mounts defined in /etc/fstab.
My server stored media and data on a Synology NAS. These mounts were configured using traditional static mount options, which meant the operating system would wait indefinitely for the NAS to become available during boot.
If the network was not fully ready when Ubuntu attempted to mount the shares, the boot sequence could stall before important services such as SSH were started.
Original Problem
Example of a traditional static NFS mount:
192.168.1.100:/volume1/media /mnt/media nfs defaults,hard 0 0
Solution
I converted the mounts to use systemd automounts:
noauto,x-systemd.automount,x-systemd.mount-timeout=10,nofail
This allows Ubuntu to complete the boot process without waiting for the NAS. The shares are mounted automatically when first accessed.
Lesson Learned
Avoid making network storage a hard dependency during boot. If your NAS is unavailable, your server should still be able to start normally.
Issue 2: Docker and SSH Startup Timing
After fixing the storage issue, the server was still unreliable.
Docker had been configured with a systemd override using:
RequiresMountsFor=
This forced Docker to wait for specific storage paths before starting.
Once the NFS mounts became automounted rather than immediately available, Docker could no longer satisfy its startup requirements.
At the same time, Docker was creating multiple bridge interfaces while the physical network interface was still negotiating a connection.
This occasionally caused OpenSSH to start before the primary network interface was fully ready.
Solution
I removed the unnecessary Docker mount dependency and modified the OpenSSH service to wait for the network to become fully online.
Systemd override:
[Unit]
After=network-online.target systemd-networkd-wait-online.service
Wants=network-online.target systemd-networkd-wait-online.service
This ensured SSH would not start until the network was genuinely available.
Lesson Learned
Many boot issues are actually timing issues. Services may start successfully but become inaccessible because the resources they depend upon are not yet ready.
Issue 3: The Real Root Cause
Even after fixing the storage and service dependency issues, the server still refused to boot correctly when no monitor was attached.
At this point it became clear that the problem was occurring before Linux was even fully loaded.
The server hardware was an Intel NUC D3217IYE, released around 2012.
Older consumer hardware often contains BIOS routines that assume a monitor will always be connected. During the Power-On Self-Test (POST) process, some systems check for a valid display device before completing hardware initialization.
Without a display attached, the motherboard would either halt the boot process or fail to fully initialise components required for networking.
Discovery
The server worked perfectly whenever:
- A monitor was connected.
- An HDMI cable was attached to a display.
- The machine was rebooted while already connected to a monitor.
The issue only occurred when the machine started completely headless.
This pointed directly at a firmware-level hardware limitation rather than a Linux configuration issue.
The Permanent Fix
The final solution was surprisingly simple.
I purchased an inexpensive HDMI dummy plug, sometimes called an EDID emulator.
The device plugs into the HDMI port and pretends to be a real monitor.
Once installed, the BIOS detected a valid display during POST and completed the boot process normally every time.
The server has been able to reboot unattended ever since.
HDMI Dummy Plug
The device looks like a small HDMI adapter but contains circuitry that emulates a monitor's identification data.
For older mini PCs, Intel NUCs, and consumer motherboards used as servers, it can be an inexpensive solution to strange headless boot problems.
Key Takeaways
1. Avoid Static Network Mount Dependencies
For NAS storage, consider using:
noauto,x-systemd.automount,nofail
This prevents your entire server from becoming dependent on network storage during boot.
2. Review Service Dependencies
Applications that rely on network storage should wait for their storage locations to become available rather than assuming they already exist.
Docker containers can be configured to wait for required paths before starting.
3. Consumer Hardware Is Not Server Hardware
Desktop PCs, mini PCs, and older Intel NUCs are designed with the expectation that a monitor will be attached.
When repurposing consumer hardware as a homelab server, strange firmware limitations can sometimes appear.
4. Don't Ignore Hardware
After spending hours investigating Linux, systemd, Docker, networking, and storage, the ultimate solution turned out to be a £5 HDMI adapter.
Sometimes the simplest explanation really is the correct one.
Final Thoughts
This troubleshooting exercise reinforced an important lesson: complex problems often have multiple contributing causes.
In my case there were genuine issues with network storage mounts and service startup ordering. Fixing those improved the system, but they were not the root cause of the server's inability to boot headless.
The real culprit was a firmware limitation in ageing hardware.
If you have an older Intel NUC or mini PC that refuses to boot correctly without a monitor attached, an HDMI dummy plug may save you a considerable amount of troubleshooting time.