Red Hat Bugzilla – Bug 64827
Installer hangs when probing for monitor type.- need to handle ddcprobe dying gracefully
Last modified: 2007-04-18 12:42:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)
Description of problem:
When I try to install RH 7.3 the system hangs completely after the probe of
the monitor type. It doesn't matter whether I choose graphical or text install.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Start installation of RH 7.3 on Compaq Proliant 1600 server with a Dell
Monitor D1025HE using CD1
2.Choose either graphical or text install (makes no difference)
Actual Results: System hangs completely.
Running anaconda - please wait
Probing for video card: Cirrus Logic GD544x
Probing for monitor type: Unable to probe
After this the system hangs completely.
Expected Results: Full installation of RH7.3
The monitor gave no problems with 7.1 and 7.2
If I run ddcprobe I get (when starting with linux rescue):
VESA 2.0 detected
OEM Name: Cirrus Logic GD-5446 VGA
Memory installed: 16 * 64k blocks= 1024kb
Supported standard modes:
On another console I get (during installation)
looking for video cards requiring agpgart module
found video card controller unknown
modules to insert raid0,...,lvm-mod
load module set done.
After this the system hangs completely.
My probleem SEEMS a lot like the problem described in Bug 64759.
Maybe it's same cause.
Could you make a blank ext2 floppy and put the anaconda file in the attachment
on it, then boot the installer with 'linux updates'? This anaconda skips the
ddcprobe, perhaps it will help.
Created attachment 57128 [details]
patched anaconda which skips ddcprobe
I put the anaconda file on a ext2 disk and started with "linux updates"
The installation program asks for the driver update disk.
"reading for anaconda updates"
But then installation stops "exec: no such file or directory".
The exec command is part of the anaconda file.
How can I fix this?
I'm sorry, be sure to save the attachment as 'anaconda', and make sure it is
I am having the very same problem. Hardware is also a Compaq ProLiant 1600
(model 6/400 to be exact).
Took the anaconda patch and applied it, but it did not solve the problem.
I suspect the probe for the monitor *is* happening correctly - it's the next
step that's locking the machine. I tried a 7.2 install, and that went
successfully. During that install, I noticed that the next thing probed after
the monitor appears to be the mouse. I have tried the 7.3 install with and
without mice, and also tried disabling the PS/2 mouse port in the Compaq's BIOS.
None of these changes helped.
Another peculiarity - during the install kernel bootup, it appears that it's
detecting a USB controller (UHCI), but then complains that it doesn't have an
IRQ. This machine does not appear to have a USB port at all, and there is no
mention of USB resources in the Compaq BIOS.
Is it possible that Anaconda is attempting to scan the USB bus for a mouse? I
also tried passing 'nousb' to the installer, but that didn't seem to make a
At the risk of sound too redundant, let me Me Too this one. My ProLiants (1850s
and 1600s) can (and do) run RH62-72 inclusive, but RH73 install goes remarkably
sour for a point release. Upon seeing this error (one that's very similar to an
older caldera installer bug) on my ProLiants, I started swapping in different
monitors and trying different units.
The bad news was that all the compaq units failed with varying RAM, different
monitors, random mice and keyboards, with or without the (masterview) KVM,
15-17" vid (17 had no red gun, but I got a good test).
This same hardware runs RH62-72 inclusive, in various tortured configurations,
so a success with RH72 on a system that 73 hates isn't a big surprise after
It's not a media thing, because it's an FTP install.
But that's all the data I could gather today, in between compiles .. and
recompiles.. .. and recompiles.
Well, I can confirm now that the anaconda patch does not solve the problem.
I've also tried installing RH 7.3 on an Compaq Proliant ML 350 server and this
worked without any problems !
So what to do next? :)
would it be useful to run a hwcheck on the ML and ProLiants, and see if there's
significant difference, or is there a lot of confidence that it's the ddcprobe?
A comparison may show something interesting that CPQ did between PL and ML
series, that may be relevant - like, did they change the Vid as well as the Eth
Me, I'm not sure. I can't easily find an ML here that's not being used for
builds or whatnot.
I don't have much confidence that it's the ddcprobe, seeing as how booting into
7.3's rescue mode and running ddcprobe works just fine.
Yes, there are significant differences between the ProLiant 1600's and the
ML350's . My 1600 that isn't getting along with RH7.3 has a TI ThunderLan
onboard NIC and the previously mentioned Cirrus GD-5446 video card. Our more
recent ML350s are equipped with a Compaq NC3163 FastEthernet NIC and an ATI Rage
XL video system (onboard).
I would like to add a "me too", Red Hat 7.3 will not install on my Compaq
Proliant 1850R. The symptoms are identical to those reported earlier in this bug
report, except for the fact that my monitor was detected correctly during the
monitor detection phase.
One thing that strikes me odd is that the USB Mass Storage Device is registered
once, then deregistered, then the compaq drive array is registered, then the USB
Mass Storage Device is registered again, and that is the last line of output on
VT 4 before lock-up. Perhaps it is realted to USB, is there any way to disable
usb during install?
Ah the usb-storage trickery you're seeing is to support USB floppy. We unload
it so the floppy is not /dev/sda.
You can boot with 'nousb nousbstorage' and see if that helps.
Tested the above suggestion - typed "linux nousb nousbstorage" at the CD boot
prompt - and it did not help. ProLiant 1600 still locks after the monitor probe.
We've tried Redhat 7.3 on one of our Compaq 1850R servers with the same failures
as other folk are apparently having. We've tried using the hacked anaconda,
booting with only one ThunderLAN
ethernet card in, booting from CD-ROM (thus with no tlan module loaded so its
not the Ethernet card) and copying the 7.2 anaconda into a 7.3 netstg1.img .
All failed. The only slightly successful boot was to boot from a 7.3 CD-ROM and
select "linux rescue". That ran anaconda but then dumped us straight into a
shell. The good news was that we could see the existing 7.2 filesystem on the
Smart Array 3200 so the cpqarray module seems to be working OK as well.
A workaround for this is to take the patched anaconda and remove
the code pertaining to probing and starting the X server for the
graphical install, then starting the install with "linux text updates".
This was tested on two Compaq Proliant 1850R's, both in an attempt
to upgrade from 7.2 to 7.3. Both upgrades were successful.
Of course, graphical installs are disabled using this method, but
the appropriate hardware modules were found and loaded at the very
beginning of the upgrades and no other problems were experienced.
I can supply a diff for this if needed.
Good catch, imho. I, for one, would love that diff. Heck, gimme a usable
anaconda image so that I can just burn it to floppy and go.
Should we ask why the X detection routes for a graphical install are affecting a
text mode install? Nah, it's a monday enough as it is. 8-)
Created attachment 58788 [details]
Patched anaconda that disables probing and starting an X server upon install
Hmm... I can't get the new anaconda patch (#58788) to work. I create the update
floppy, run 'linux text updates' and then feed it the floppy. It reads the new
anaconda script, but then errors out:
exec: No such file or directory
install exited abnormally
I did not have this problem with the earlier anaconda attachment - the installer
took that update just fine (tho it didn't solve the probing problem).
Suggestions? I only see one instance of 'exec' in the entire anaconda script,
and it appears to be the same one that is in the original.
My apologies, folks, I'm doing all this at a client site and had to
upload the attachment on a Windows box (as is plain to see) I also
should have just named it `anaconda', so be sure it is renamed to
that and set mode 0755; jpenix, that might be your problem, though
I tested the install using a non 0755 file and a mangled name, and
both times, it froze like usual instead of giving the error message
Created attachment 58792 [details]
tgeier's patched anaconda, reformatted for Unix
Ah hah - Windows was the problem (what's new? ;). Your anaconda file was
formatted for DOS (CR/LF), and apparently the RH installer doesn't like that. I
ran it through vim and rewrote it as a standard Unix file, and then the
installer took it. See attachment above.
Now, on to the next problem - I have now successfully entered the RedHat install
program on my ProLiant 1600. However, after going through the setup interview,
the installer crashes just before it goes off to format the drives and install
my packages. Attached is the ANACDUMP.TXT file that the installer created. The
problem seems to be related to X.
I'd be interested if anyone else can take the newest anaconda patch and
successfully complete an install.
Created attachment 58793 [details]
Traceback file generated during install using no-X patched anaconda
I can confirm that in my case the newest anaconda patch does not work. I haven't
included traceback file generated during install because it's quite similar to
the one created by email@example.com.
I wonder if what I did only works on an 1850R, I don't know the
exact differences in the hardware between that and the other
Proliant models, though there is enough similar between them to
cause anaconda to freeze. Perhaps taking the original patch and
only removing or modifying the probing code (lines 380 to 402) and leaving all
the X code intact would work; I was just using trial and error once
I got the idea to modify the code, and the attachment is what worked in my
particular situation. This definitely isn't an elegant solution,
but perhaps it can lead to something that will work for everyone.
I'm afraid that the hacked version didn't work on our 1850R when I tried
it this morning. As an interesting datapoint, I grabbed one of the Mandrake CDs
that we'd been given for an installfest and gave that a spin. It too locks up
on the machine (after claiming to probe the serial port). So RedHat 7.3 isn't
alone in blowing up during installs on this machine.
I knew we should have bought some no-name Taiwanese clone instead of these
expensive Compaq servers... ;-)
I just tried the patched anaconda on my Compaq Proliant 1850R, and it froze as
before. What is odd is I tried to add some debugging output statements to the
anaconda (outputting to stderr), and I could not see my output statements on
bootup. I do not know if stderr is outputting to /dev/null, another terminal, or
the install is simply not loading my anaconda (yes, it's on an ext2fs floppy
named /anaconda mode 0755). Any more help would be appreciated.
I too have a Proliant 1850-R having the same problems.
I downloaded the above attachment(id=58792) on a ext2 formatted
diskette and named it anaconda. I typed 'linux test updates' and put
in the disk and the text install worked great!!
I will be adding a boot time option to skip the ddc probe in the future.
*** Bug 66165 has been marked as a duplicate of this bug. ***
I have a Proliant 1850-R. I properly installed attachment(id=58792).
I typed 'linux test updates' and had the same problem as jpenix.
I'm doing a fresh installation, not an upgrade. I've selected a bare
server install (no X) with max firewall.
I then reverted to the original with the change:
> if 0:
This avoids the Null variables issue that causes the crash. Unfortunately
this lets me get through an entire installation then locks the machine in the
Why is this marked as closed? The fix only works for upgrades, not new
You're absolutely right. I tried the proposed patch on a Compaq Proliant 1600
(fresh install) but I still have the same problem. So in fact, this issue has
not been solved completely yet.
If the people who are complaining are in the same postion I was, they just want
to get V7.3 installed. As I mentioned above, I have a Proliant 1850r and it
worked for me. All you need to do is 1st install V7.2 then proceed with the
instructions above. It works just fine. Sure it's a bit of a pain but it is a
work-around. Hope this helps...bill
FYI: I had the exact same problem with an 1850R and also thought it was
X/video related. After scouring mailing lists, I found that if I disabled the
onboard network card (use Compaq's SmartStart for Servers CDROM), a fresh
install of 7.3 worked fine without a patched anaconda. After the install
finished, I re-enabled the network card. Red Hat 7.2 works fine without
having to disable the network card.
I was having this same problem with an 1850R. After trying the suggestions
contained in this bug report, I was unable to install or upgrade to RedHat 7.3
(freezing right after the monitor probe on both the original install/upgrade
and the first anaconda file offered in this report and terminating abnormally
with the second anaconda file offered in this report). The following fixed
the problem for me and allowed me to get past the lockup:
In the first anaconda file attached to this bug report, I commented out the
following (mouse probe is right after the monitor probe):
if not os.environ.has_key('DISPLAY') or flags.setupFilesystems:
sys.stdout.write(_("Probing for mouse type: "))
mousehw.probe (frob = 1)
sys.stdout.write(_("Skipping mouse probe.\n"))
Notes: Due to a flaky CD-ROM, I used bootnet.img for an ftp install and
drvnet.img (with the tlan driver), the modified anaconda (chmod 755) on an
ext2 formatted floppy, and 'linux text updates' from the boot install prompt.
I didn't try to do an install (upgrade from RedHat 7.2), but I suspect that
would also work. YMMV.
I was having this same problem with an 1850R.
I did solve my installation problem...
In bios I turned off / VGA RESOURCES / All the COM Ports and LPT/ and the
AUX 'mouse port' /
I am assuming that it was the COM/AUX mouse/ port that was the issue...
The installation flew past the point where it got stuck
and said there was no mouse detected
And asked to install in TEXT mode. I answered yes
And the installation continued.... :)
I just finished installing and everything works great...
Fortunately I dont need a mouse or X11 on this box...
I had the 64827 problem doing a fresh install on an 1850R.
Disabling the NIC, video card and mouse did not resolve the problem.
The patched anaconda file is not appropriate as this is not an upgrade.
A search of the web turned up a list server message saying that all 7.3
installs fail with NCR/Symbios53c8xx SCSI cards like the ones in the 1850r and
that the install works with the motherboard SCSI disabled.
I disabled both internal SCSI cards and installed with my RAID 1 array
connected to an Adaptec that I had in the parts box.
Once the install was done, I did the following steps:
remove the Adaptec
enabled the motherboard SCSI cards using the smartstart CD
booted from the 7.3 CD with "linux rescue"
chroot /mnt/sysimage bash
edit scsi_hostadapter sym53c8xx and add a scsi_hostadapter1 sym53c8xx
mv /boot/initrd.2.4.18-3.img initrd.2.4.18-3.img.orig
mkinitrd /boot/initrd.2.4.18-3.img 2.4.18-3
All was well at this point.
My solution is based on a solution created by Paul Hamm.
After Spending the last 3 days on this.
The problem was fixed on my PL1600R.
Remove the items
from the BIOS, especially the inbuilt SYMCR SCSI
and the mouse. ( I think it was the mouse ).
now installs perfectly. ( Install not Upgrade ).
Fails the same on 8.0
Why do we bother reporting?
This fix didn't make into 8.0 version, 8.1 should have possibility
to skip the ddc probe. See bug 64996.
8.0 works on an 1850r if I pass nousb and nousbstorage and no other parameters.
The parameter skipddc was added to 8.0, but it doesn't help.
Time tracking values updated
I have an 1850R with the same problem. Following Adam McKay's instructions
(comment #35), I was able to complete the package installation step, only to
have the machine lock up hard on the post installation step.
I discovered that modifying packages.py so that "kudzu" is invoked with the "-s"
(safe) argument enabled the post installation step to complete! I copied my
modified packages.py file onto the same "updates" disk alongside the modified
I'll attach a diff for packages.py as an attachment, even though it's trivial...
Created attachment 89558 [details]
Patch to packages.py to allow kudzu to be run in "safe" mode
This patch allows the post installation stage to complete successfully in my
1850R as opposed to locking up solid.
9 works on an 1850r if I pass nousb and nousbstorage and no other parameters.
If I don't pass those, 9 hangs, just like 8 did.
FYI, I also added nousb nousbstorage on an 1850R with 9 and it works fine.