I have a situation of a linux board , that shares a display with other systems via kvm style switch. It is normal for these boards to come on line, and NOT have an active route to the display monitor. When X starts on boot or power outage, it fails to succeed due to it not being able to probe the monitor settings.

I have a valid xorg.conf file, but it tries to auto probe the monitor. If there is NO monitor attached, i get an error in /var/log/X11 log that states...

"no screen found" and it aborts the startup.

Is there a way to force X to honor the settings in xorg.conf, and NOT probe the monitor ?

I have tried several settings, but happy to start over with new recommendations if anyone has had success doing this.

I have an intel Johnstown board (atom n270) with built in intel i910 graphics processor. I use the xserver-xorg-intel driver from debian package. I can post xorg.conf and x11 logs if required.

the downside with manually launching startx is it may very well not have a human around during it's reboot to time it accordingly. If it occurs w/o the monitor available, it will fail. We need to assume the monitor will not be online.

Checkout NoDDC from here : http://www.x.org/archive/X11R6.8.1/doc/rendition5.html

You can try writing a manual modeline to define a screen working mode (resolution and hz) manually or use the vesa driver which might be less capable of autodetection (unsure about that)

In many Linux distros, runlevel 3 suggested by the previous poster boots to a command line, not to X, and runlevel 4 boots to the GUI.

Others (such as Debian) boot to a GUI unless the login display manager is actually uninstalled. Then they boot to a command line. (I know that about Debian only because I looked it up a couple of days ago.) X can be started from the command line by typing startx.

If you are booting to a non-GUI runlevel
and X is being started manually,
and there is no human around to start it,
then it could not start and fail.

It shouldn't launch at all until someone logged on and started it.

(If someone tries to start X over an remote connection, you have a human problem, not a computer problem.)

A personal story: I used to have a couple of Slackware machines connected to a KVM (Slackware boots to the command line by default, not to the GUI). I could reboot them over ssh, sometimes from hundreds of miles away, and they came up fully functional.

One of them was my webserver (I used to self-host) and the remote access was sometimes vital to my ability to be annoying in public.

Then, when I was physically with them, I could turn on the monitor, select the machine I wanted, log in, issue startx, and have full GUI functionality.

Based on this experience, I second Heidelberg's suggestion.