From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 Description of problem: Attempting to stall redhat 8.0 on a Compaq server (PL1600 6/500. pII 500 mhz, 512 megs of ram). Select NFS install, use the extra net driver disk to pick the thunderlan chip, dhcp succeeds, start anaconda, probe vidio card successfully, probe monitor fails, install locks. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Start install, select NFS 2.Choose card from extra network card driver disk (thunder lan) 3.anaconda starts 4."Probing for video card: Cirrus Logic GD544x" 5."Probing for monitor type: Unable to probe" 6. Box locks up. Actual Results: Hard lock up. <ctrl><alt><del> doesn't restart. Have to hard power off. Expected Results: Begin the install. Additional info: Last lines I see from the install screen (<alt><F1>): ---------------------------------------------------------------- Running anaconda, the Red Hat Linux system installer - please wait... Probing for video card: Cirrus Logic GD544x Probing for monitor type: Unable to probe ---------------------------------------------------------------- Last few lines I see from the detail screens (<alt><F3>): ---------------------------------------------------------------- * NFS install method detected, will use RH/ * Running anaconda script /usr/bin/anaconda * Probing for video card: Cirrus Logic GD544x * ddcprobe returned bogus values: ID: None Name: None HorizSync: None VertSync: None * Probing for monitor type: Unable to probe ---------------------------------------------------------------- Last line I see from the other detail screen (<alt><F4>): (it's the standard boot line for the 'paraport lp0' paralel port detection. It mentions nothing about the monitor)
Does it work if you boot with 'linux skipddc'?
No. Booting with "linux skipddc" doesn't change the behavour.
Has there been any further progress on this bug? Is there any information I can provide? I'd really like to get redhat onto this thing for testing purposes... The 'linux skipddc' command given to 'grub' doesn't affect the behavior at all.
I have the exact same problem with an proliant 1850R
I have the exact same problem in a Proliant 1600. Is there any resolution/direction to follow? I have tried to install both RH8.0 and RH 7.3 with the same results. The skipddc has no affect on the results.
Same here with another Compaq 1850R... I think the monitor is actually loading, but whatever comes after it is giving the trouble. I see the monitor probe, then a carrage return to a blank line and the machine is locked up. I flashed the machine bios to the latest update.. still no luck.. round and round.. No listed version of installing works. I bought this machine to test RH 8.0 in prep for taking it to prime time.... awefully rocky start. For grins, I tried RH 7.2 and it installed perfectly. So, what gives?
I too have this issue with a Proliant 1600. Any progress? It's been nearly a month since the last post.
I've tried to use a ks.cfg file to get around this with no luck. Even though the file is read to /tmp per <f>3, Anaconda still tries to probe and hangs. I editied the 7.2 anaconda-ks.cfg for this. It lock up so solid that I even have to reboot the NFS server. ks.cfg line: xconfig --card "Cirrus Logic GD544x" --videoram 1024 --hsync 31.0-72.0 --vsync 50.0-120.0 --resolution 800x600 --depth 16
I installed RH 8.0 on a Proliant 3000 and then removed the drives and put them into my Proliant 1850R. It runs fine. While doing the install on the 3000, I noted that just after the monitor probe (which also failed on the 3000), the install continued probing for a mouse. I think the problem is with the detection of the mouse or possibly the ps2 port for the mouse. Go figure? This has always worked before... what could have changed? Maybe additional probe functions for a USB mouse are conflicting? I think this is the key to the problem though, even though the last thing we see is the monitor probe
That could be, but then what's the point of using the ks.cfg like I did if anaconda isn't really going to use it? It does have a config line for the mouse. I more suspect that it's something with how the BIOS is called or something with the CPU code in the compiled kernel, however I am no expert. I just suspect that it's at a lower level than anaconda at this point.
I had the same problems. I tried 2 graphics cards, 4 monitors, disabling enet, serial, LPT, to no avail. On a hunch, I updated the Proliant 1600 BIOS from a 1998 version to a 2000 version. This time it worked except for the mouse. I just skipped the X window config until after the install. When I rebooted after the install, Kudzu recognized the mouse during boot. Everything is fine so far. You can find the Proliant BIOS upgrade at this link: http://h18023.www1.hp.com/support/files/server/us/download/9343.html Let me know if this works for anyone else.
I forgot to say that it was Red Hat 8.0 that I sucessfully installed.
I just tried the bios update. The problem has not changed. FYI: Mandrake can't install either, but debian can.
I do not have access to this hardware to investigate further.
It has been reported that a workaround is to boot with 'linux nousb' to disable USB support during the install. Apparently on this hardware the usb mouse support was hanging the system. It was also mentioned that 'noamp' could help in some cases.
FWIW, I have a bunch of Proliant 1600R servers, and couldn't install reliably any of Red Hat Linux 7.3, 8.0 or 9 either. On some servers 7.3 installed (not on the first try, though), so I just swapped drives between servers to get them all installed... long and painful. When I had a whole batch where 7.3 just wouldn't install, I gave up and installed 7.0 (no problems whatsoever) which I then upgraded using yum. But... I just now installed Fedora Core 2 without a hitch on one of them, so it seems the problem (kernel or anaconda or...) is gone now.