🚨 Linux Error Guide: 'No signal' — Restore Console and Video Output

Overview

You plug a monitor into a Linux server — perhaps to debug a box that will not come up on the network — and instead of a login prompt you get the display’s own on-screen message:

No signal

This message comes from the monitor, not from Linux. It means the panel is receiving no valid video signal on the selected input. On a desktop that usually points at a cable or GPU problem, but on servers the causes are broader: the machine may be genuinely headless with no GPU, the kernel may have handed the console to a serial port instead of the screen, or the framebuffer driver may have failed to initialize the graphics hardware. Understanding where Linux is sending its console output is the key to getting a usable prompt back.

Symptoms

• The monitor reads No signal, No input, or Check signal cable and may drop into standby, even though the server is powered on and fans are spinning.
• The system is otherwise alive: it responds to ping, SSH works, or the disk activity light shows boot progress.
• POST or firmware splash may briefly appear, then the screen goes dark once the kernel takes over — a classic sign the kernel switched to a mode the monitor rejects, or redirected the console to serial.
• Nothing appears on any tty; Ctrl+Alt+F2 through F6 produce no change.
• On rack servers with IPMI/iDRAC/iLO, the remote virtual console shows output while the physical VGA port stays blank.

Common Root Causes

1. Headless server with no or minimal GPU. Many servers have only a rudimentary onboard VGA controller (ASPEED, Matrox) or none at all, and the OS was provisioned to use a serial console instead of the display.
2. Wrong output port. The GPU has several connectors (HDMI, DisplayPort, VGA, DVI) and the active output does not match the one your cable is plugged into.
3. Framebuffer / DRM driver not initialized. Kernel mode setting (KMS) failed for the GPU, so no framebuffer console is created and the port stays dark.
4. Kernel selected an unsupported video mode. The mode negotiated at boot is out of the monitor’s range, so the panel refuses the signal.
5. Console directed to serial. The kernel command line contains console=ttyS0 without console=tty0, so all boot and login output goes to the serial port, leaving the screen blank by design.

Diagnostic Workflow

If you can still reach the box over SSH or a serial console, start by reading the kernel command line to see where the console was pointed:

cat /proc/cmdline
# BOOT_IMAGE=/vmlinuz console=ttyS0,115200 console=tty0 nomodeset ...

The order matters: the last console= entry receives the interactive login prompt, while all listed consoles receive kernel messages. If you see only console=ttyS0 with no console=tty0, the screen was never meant to show a prompt.

Next check whether the graphics driver bound at all. The DRM subsystem logs its progress to the kernel ring buffer:

dmesg | grep -i drm
lspci | grep -i vga
ls -l /sys/class/drm

If /sys/class/drm contains connector entries like card0-HDMI-A-1, inspect their status to learn which port the kernel believes is connected:

for c in /sys/class/drm/card*/card*/status; do echo "$c: $(cat $c)"; done
# .../card0-HDMI-A-1/status: connected
# .../card0-DP-1/status: disconnected

Confirm a getty is actually running on the virtual terminal so that, once video works, you will get a login prompt:

systemctl status getty@tty1

To force a predictable text console when a GPU driver is misbehaving, add nomodeset (disables KMS and falls back to basic framebuffer) or explicitly enable the screen console. Edit the GRUB defaults, then regenerate the boot config for your distribution:

sudoedit /etc/default/grub
# GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200 nomodeset"

# Debian/Ubuntu:
sudo update-grub
# RHEL/Fedora/SUSE:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Placing console=tty0 last makes the local screen the interactive console; keeping console=ttyS0,115200 earlier preserves serial logging. Reboot to apply.

If the machine is truly headless, connect over its serial port from another Linux host. Use screen or minicom at the matching baud rate:

sudo screen /dev/ttyS0 115200
# or
sudo minicom -D /dev/ttyS0 -b 115200

On enterprise servers, the out-of-band management controller (IPMI SOL, iDRAC, iLO) provides the same serial console over the network without any physical cable, which is usually the fastest path to a prompt.

Example Root Cause Analysis

An engineer racks a new 1U server, boots it, and the attached VGA monitor shows No signal after the firmware splash disappears. The server answers ping, so the OS clearly booted.

They connect to the BMC’s Serial-over-LAN console and log in. cat /proc/cmdline shows console=ttyS0,115200 with no console=tty0 — the cloud image this server was provisioned from is tuned for serial-only headless operation, so the kernel never lit the VGA console on purpose. systemctl status getty@tty1 confirms no getty was ever spawned on the local terminal.

Because the team wants both serial logging and a usable local screen for on-site work, they edit /etc/default/grub to set GRUB_CMDLINE_LINUX="console=ttyS0,115200 console=tty0", run update-grub, and reboot. The VGA port now shows a login prompt, while serial logging continues for remote debugging. The No signal message was not a hardware fault at all — the console had simply never been directed to the screen.

Prevention Best Practices

• Standardize on dual console settings (console=ttyS0,115200 console=tty0) in your golden images so both serial and local screen work everywhere.
• Document each server’s primary access method (IPMI/iDRAC/iLO IP and credentials) so a blank screen never means a truck roll.
• For GPU-equipped hosts, note which physical port is the active output and label the cable accordingly.
• Keep nomodeset as a known-good GRUB fallback entry for hosts where a KMS driver update breaks video.
• Test serial and virtual console access before you need it, not during an outage.

Quick Command Reference

cat /proc/cmdline                       # where is the console directed?
dmesg | grep -i drm                     # did the GPU/KMS driver initialize?
lspci | grep -i vga                     # what graphics hardware exists
ls -l /sys/class/drm                    # enumerate connectors
cat /sys/class/drm/card0-*/status       # connected vs disconnected ports
systemctl status getty@tty1             # is a login prompt running on tty1?
sudoedit /etc/default/grub              # set console= and nomodeset
sudo update-grub                        # Debian/Ubuntu regenerate config
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/SUSE regenerate config
sudo screen /dev/ttyS0 115200           # attach to serial console
sudo minicom -D /dev/ttyS0 -b 115200    # alternate serial client

Conclusion

No signal is a message from the monitor, not from Linux, and on servers it rarely means a dead cable. Work out where the kernel is sending its console: read /proc/cmdline, check the DRM driver and connector status, and confirm a getty is running. Most cases resolve by adding console=tty0 back to the kernel command line, falling back to nomodeset, or simply using the serial/BMC console that the headless image was designed for. With dual-console images and documented out-of-band access, a blank screen becomes a minor inconvenience rather than a blocker.