Red Hat Bugzilla – Bug 501921
X fails to start with monitor unplugged
Last modified: 2018-04-11 06:23:35 EDT
Description of problem:
X fails to start when the monitor is unplugged.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start in runlevel 3.
2. Unplug the monitor.
3. Run startx.
X fails to start with "no screens found" error.
It should start and, if possible, it should detect when the monitor is plugged in and set the correct resolution. Otherwise it could store the last working resolution or fall back to a sane default. Sorry, not really sure of which would be the best approach to get it working.
It's a default installation from Fedora 11 Snapshot 1 until today.
The graphics card is an ATI Radeon 9200 PRO (RV280).
Created attachment 344938 [details]
/var/log/Xorg.0.log when the monitor is plugged
Created attachment 344939 [details]
/var/log/Xorg.0.log when the monitor is unplugged
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I've tried a machine with an Intel graphics card and I've got the same result. Should I open another bug for the Intel driver or may be it's related to X server or something else independent of the driver?
For me worked fine with kernel 2.6.29 but broke with 2.6.30. Works fine when I boot with the older kernel.
Actually I now see that it only worked under 2.6.29 because the Plymouth graphical boot set the mode sucessfully. Under 2.6.30 the Plymouth graphical boot fails if no monitor is attached and just hangs. With 2.6.29 the Plymouth boot worked with no attached monitor. If nomodeset is added to the the grub kernel line for 2.6.29, then startx will fail unless a monitor is attached. So if Plymouth just worked without an attached monitor, startx would probably work.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command
yum upgrade --enablerepo='*-updates-testing'
Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
I've tried with the nightly live CD compose desktop-i386-20091105.16.iso and I'm still having the same problem. I'm attaching some logs.
Created attachment 368122 [details]
Xorg.0.log with monitor unplugged
Created attachment 368123 [details]
Xorg.1.log with monitor unplugged
Created attachment 368124 [details]
Xorg.2.log with monitor unplugged
Created attachment 368125 [details]
Xorg.3.log with monitor unplugged
Created attachment 368126 [details]
Xorg.4.log with monitor unplugged
Created attachment 368128 [details]
Xorg.5.log with monitor unplugged
Created attachment 368129 [details]
dmesg with monitor unplugged
Created attachment 368130 [details]
Created attachment 368131 [details]
Xorg.0.log with monitor unplugged and nomodeset
Created attachment 368132 [details]
dmesg with monitor unplugged and nomodeset
Created attachment 368134 [details]
Xorg.0.log with monitor unplugged and drm.debug=1
Created attachment 368136 [details]
dmesg with monitor unplugged and drm.debug=1
Created attachment 368137 [details]
/var/log/messages with monitor unplugged and drm.debug=1
Created attachment 368138 [details]
Xorg.0.log with monitor unplugged, drm.debug=1 and nomodeset
Created attachment 368139 [details]
dmesg with monitor unplugged, drm.debug=1 and nomodeset
Created attachment 368140 [details]
/var/log/messages with monitor unplugged, drm.debug=1 and nomodeset
By the way, in all tests X failed to start and there was no xorg.conf file.
Response to comment #7. Upgraded to update-testing and same failure on boot with no monitor attached. Also tried Fedora 12 beta desktop (desktop-i386-20091104.16.iso) which also failed at same point. Failure happened on 2 Dell PCs with integrated Intel video adapters (one is an Intel 82845G/GL/GE/PE/GV). Last kernel that worked (allowing boot without attached monitor) was 126.96.36.199-188.8.131.52.fc11. None of the 2.6.30's work. I can take my updated PC and boot back to the 2.6.29 kernel and boot is fine with no monitor attached. The servers with non-intel video adapters boot fine with no monitor (at least the ones I have).
Alex, Ted are you using Intel GPU or RADEON/ATI/AMD GPU ? According to log it's intel. Also what do you expect X to do if there is no screen ? Which resolution do you want it to pick ?
Intel. I do have an xorg.conf file with several screens defined with different resolutions. Boot into initlevel 3, then run startx (under Telnet) to bring up X. One can specify the screen to use as a startx parameter. This works on all other display adapters, and used to work with Intel pre 2.6.30 kernel, even without an xorg.conf. With this kernel and Intel display adapter, cannot even boot (even into level 3) unless a monitor is attached, though it doesn't have to be powered on.
When I reported the bug it was with a Radeon GPU, but the lasts log are from an Intel one (I no longer have the Radeon machine at hand).
About what to do when there is no screen attached, I'm not sure at all. If it's possible, I think X should start and when a monitor is plugged, set the correct resolution for it. Otherwise, it should fall back to a safe resolution, may be 800x600 or better 1024x768. But I think there should be some better reasoning behind this decision than my inspiration.
Fixed in F13.