Bug 218181

Summary: Anaconda fails to switch to GUI install mode.
Product: Red Hat Enterprise Linux 5 Reporter: Roger L. Olson <obc>
Component: xorg-x11-drv-nvAssignee: Adam Jackson <ajax>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: urgent Docs Contact:
Priority: medium    
Version: 5.1CC: bskeggs, w.soo, xgl-maint, zephod, zimon
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-17 21:15:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
xorg.conf.old, xorg.conf (modified for gui), Xorg.0.log.old, Xorg.0.log (GUI working)
none
Xorg.0.log
none
GUI not working in F11
none
The log when X was working in Fedora 10
none
difference of the two: working and non working X log files none

Description Roger L. Olson 2006-12-02 19:49:51 UTC
Description of problem:Anaconda fails to enter GUI install after video card probe.
Version-Release number of selected component (if applicable):


How reproducible:Always

Steps to Reproduce:
1.Boot from CD (I use "linux nofb" option).
2.Follow normal install steps.
3.
  
Actual results:After video card is probed and correctly identified, screen
blanks when switching to GUI mode causing monitor to generate an "Out of Range"
error message.

Expected results:Switch to GUI mode to complete install out of the box as RHEL4
does.

Additional info:Tried the appropriate kernel options and still no go for GUI
install.  Necessites "text" only install, manually editing xorg.conf to use the
"vesa" driver and entering monitor data initially before startx will enter GUI mode.
HW: Gigabyte P4 Titan GA-81848P MB, Gigabyte Geforce 6600 AGP8x (GV-N66256DP).

Similar to bug rpts 21409, 214121 for Fedora Core 6 but with different
consequences.  Attached Xorg.0.log and xorg.conf following text install and
after modified to enable GUI interface.

Comment 1 Roger L. Olson 2006-12-02 19:49:51 UTC
Created attachment 142669 [details]
xorg.conf.old, xorg.conf (modified for gui), Xorg.0.log.old, Xorg.0.log (GUI working)

Comment 2 Roger L. Olson 2006-12-02 20:36:22 UTC
First noticed this with FC5 then FC6 and now with RHEL5B2

Comment 3 Adam Jackson 2006-12-11 20:05:46 UTC
Can you attach the X log from starting with the 'nv' driver and the stock
xorg.conf please?

Comment 4 Adam Jackson 2006-12-11 20:07:49 UTC
nm, missed it in the attachment, you already did.

it looks like you just don't have working DDC, that's unpleasant.  are you using
a kvm?

Comment 5 Roger L. Olson 2006-12-11 23:58:12 UTC
Good call!  Yes I am using a KVM, an older one.  I can bypass and try a
reinstall if beneficial?

Comment 6 Adam Jackson 2006-12-15 18:00:25 UTC
Yes, please do.

Comment 7 Roger L. Olson 2006-12-17 03:24:00 UTC
Bypassing KVM install results:  No joy.  Same problem, monitor generates an "out
of range" error.

Observation:  Installed RHEL5B2 x86_64 on AMD platform using basic same video
card (PCI-e instead of AGP8x) and all proceeds well throgh KVM.  HW: Asus
A8N32-SLI Delux and Gigabyte GeForce 6600 PCI-e (GV-NX66256DP).

Comment 8 W.Soo 2007-03-01 03:15:33 UTC
I've encountered this using An ASUS 7100GS Nvidia card on a Asus P5B
motherboard.  The problem was noticed on FC6 and then RHEL5 Beta 2.  To work
around the problem, I rebooted into single user mode and editing
/etc/X11/xorg.conf and added the Modes option to the Screen section -> Display
subsection.

        SubSection "Display"
                Depth    24
                Modes    "1280x1024"
        EndSubSection


Comment 9 Matěj Cepl 2007-10-31 21:47:14 UTC
Reporter, sorry for letting this bug rottening for so long. Could you please try
to reproduce this issue with the released version of RHEL?

Comment 10 Roger L. Olson 2007-11-01 04:26:51 UTC
Yes I will although I did install v. 5.1 beta with the same problem.  Since my
last comments, I have made several other observations which I hope might prove
useful and sorry for not being more astute on my initial report:

1) I am going through a KVM analog VGA connection rather than DVI although
bypassing the KVM and still using the VGA connection yielded the same results.

2) With RHEL v. 4, Fedora 4 and prior, Anaconda gave up on the probe and gave me
the "vesa" driver which allowed me to continue with the install in graphic mode
whereas RHEL v. 5 and Fedora 5 on up force me to use the nv driver.

3) It appears the nv driver itself just doesn't work with this card (nv43 as I
recall) since I just tried using it with the xorg.conf fully populated with the
appropriate refresh rates and resolutions for the monitor and got the usual "Out
of Range" monitor notice upon relogin.


Comment 11 Matěj Cepl 2007-11-01 12:16:28 UTC
Reporter, could we get /var/log/Xorg.0.log from running with DVI directly
connected, please?

Comment 12 Roger L. Olson 2007-11-05 00:29:31 UTC
Created attachment 247691 [details]
Xorg.0.log

Comment 13 Roger L. Olson 2007-11-05 00:36:27 UTC
Comment on attachment 247691 [details]
Xorg.0.log

Bingo, success finally :)

Conditions:
1) Direct DVI connection between the NV43 card and the Viewsonic VX900-2 LCD.
2) Fresh install of RHEL v.5 official release.

Log was generated directly from the install.

Comment 14 zephod 2008-12-10 05:00:46 UTC
I have just run into this problem while using anaconda via preupgrade attempting to upgrade from F8 to F9. As I understand it, the Xorg.conf file is no longer used. See the thread "Preupgrade/Anaconda problem - 3rd time a charm?" on the Fedora list.

[root@steve ~]# rpm -qa | grep anaconda
anaconda-yum-plugins-1.0-1.fc8

[root@steve ~]# rpm -qa | grep hal
hal-cups-utils-0.6.13-2.fc8
hal-libs-0.5.10-5.fc8
hal-0.5.10-5.fc8
hal-info-20080607-2.fc8
hal-devel-0.5.10-5.fc8

I have an nvidia 8800 video card an a generic LCD 19" monitor.

Comment 15 zephod 2008-12-23 14:54:35 UTC
Is any work being done on this bug?

F8 will reach EOL in 15 days (01/07/09)and I want to upgrade to F9 ASAP but I will stay at F8 to help diagnose this issue if I know someone is working it.

Comment 16 zephod 2009-01-03 15:41:48 UTC
Tried, in separate attempts, adding 'nomodeset' and 'vga=ask' to the kernel boot line but got the same results.

4 days left.

Comment 17 Matěj Cepl 2009-01-31 21:13:19 UTC
(In reply to comment #16)
> Tried, in separate attempts, adding 'nomodeset' and 'vga=ask' to the kernel
> boot line but got the same results.
> 
> 4 days left.

We really don't care about bugs in F8; so just go ahead with upgrading (I would actually suggest F10 — it seems to be quite stable), and if you can reproduce the bug with that, please file A NEW BUG (this one is against RHEL, and we would like to keep RHEL bugs separate from Fedora ones) and attach /var/log/Xorg.*.log and /etc/X11/xorg.conf (if you have any, I would suggest not having one, actually) to it.

Comment 18 Matěj Cepl 2009-01-31 21:14:17 UTC
Now, Roger, can you reproduce this bug with RHEL? Does comment 13 mean, that you cannot reproduce this bug anymore with RHEL?

Comment 19 Roger L. Olson 2009-02-04 03:08:05 UTC
Yes, the bug is still reproducible with RHEL using the before described hardware setup.  In summary, comment 13 was a report made to describe test results obtained from a requested change in my monitor to video card interface setup; namely going from a VGA to a DVI connection.

Using the VGA connection, the bug is consistently reproduced as originally submitted when installing RHEL v 5.0 and 5.1 thereby requiring a text only install and a manual xorg.conf modification to get X to start properly when completed.  Switching to a DVI connection however, the problem is resolved and a new install proceeds in graphical mode normally and as anticipated.

It appears to me that one of the reasons this issue has occurred is because Anaconda seems to favor the "nv" driver after probe during install of RHEL 5.x vs the "vesa" driver selection previously favored with RHEL 4 and earlier.  A second issue appears to be related to obtaining the DDC information necessary to populate xorg.conf properly for the "nv" driver to work correctly with my monitor/video card when using the VGA interface.

However, even with the "vesa" driver selection as in the earlier RHEL version installs, I still had to add "Modes 1280x1024" to my xorg.conf to get the proper native resolution for my monitor which does seem to suggest the last sentence in the paragraph above is likely true.

Although I am using a KVM switch (VGA), that does not appear to be an issue since the bug is still reproduced with a direct VGA connection.  I hope this helps some :).

Comment 20 zimon 2009-08-11 18:12:51 UTC
Using preupgrade in Fedora 10, to get upgraded to F11 failed.
Preupgrade installed all the packages it wanted and asked to reboot the machine.
I clicked "Reboot Now", so it rebooted.

In a boot up process the machine (anaconda, kernel, ???) went to the graphics mode (GUI) and both monitors thought it had unsupported settings and nothing sensible were on the screen. 

I guessed, when the hard drive LED was silent, it now maybe is asking the password for the root file system. So I gave it. After that hard disc was alive for awhile, but nothing came to the screens. Ctrl+alt+del didn't reboot the machine. After long wait, I used Alt+Sysrq+B to force the boot. It booted and went this time to the Grub-menu, where it showed both "Upgrade to Fedora 11 (Leonidas)" and "Fedora" (the old F10 system). Fedora 10 when chosen, booted fine, asked the root file system password and the system was as before but of course the upgrade to F11 was not succesfull.

Now preupgrade made all the checkings again and is asking to reboot the system and finish the upgrade process. Cannot do that, as I guess it tries to use GUI again.

In F10 I do not have xorg.conf file, but is correctly got from HAL (?).

This is a laptop, which has 1280x800 LVDS and 1280x1024 TMDS connected by a DVI-cable. Both displays work with normal F10 settings. Usually only TMDS is in use at home. When in mobile, LVDS works also, but after the boot I change the resolution of the display from 1280x1024 to 1280x800. 

The root partition is crypted by the method F10 installation provided when the system was installed one year ago or so. /boot partition is not crypted.

So, how to force this preupgrade/anaconda/* to stay in the text mode when it boots?
It doesn't give any prompt when if I now click the "Reboot Now"-button again.
Maybe add something to /etc/grub.conf ?  
There is also /boot/upgrade/ks.cfg file. Maybe something to there?

Comment 21 zimon 2009-08-15 00:16:47 UTC
Created attachment 357520 [details]
GUI not working in F11

Got the upgrading working by adding a line "text" in the ks.cfg file so it won't go to the GUI mode.

The system upgraded to F-11. After rebooted, it tried to go to the GUI mode (initlevel 5) again but neither LVDS- nor TMDS-monitor could show the resolution X was trying to use. Switching to VT2 and telling "telinit 3" got a working CLI-mode.

Xorg.0.log of the failed X-session is attached.

Comment 22 zimon 2009-08-15 00:29:39 UTC
Created attachment 357521 [details]
The log when X was working in Fedora 10

In Fedora 10 X (init level 5) was working fine. Didn't have xorg.conf then either. TMDS was working by default, but if this external monitor was disconnected, restarted X, the LVDS was working and was able to change the resolution from 1280x1024 to 1280x800 with the screen resolution tool from the GNOME Panel.

Comment 23 zimon 2009-08-15 00:33:59 UTC
Created attachment 357522 [details]
difference of the two: working and non working X log files

Difference (made by diff) of the working Xorg.0.log.old in F10 and the nonworking Xorg.0.log in Fedora 11.

(I don't know if this is HAL-, Xorg-, or Anaconda-bug; but anaconda got me in the trouble in the first place.)

Comment 24 Adam Jackson 2012-04-17 21:15:35 UTC
No further hardware enablement updates are planned for RHEL5's X stack.  If this issue is still present in RHEL6, please update the affected product version field and reopen this bug.

RHEL6 includes a completely new video driver for nvidia cards, so I expect if this still fails it'll at least be in fascinatingly new ways.