Bug 64827 - Installer hangs when probing for monitor type.- need to handle ddcprobe dying gracefully
Summary: Installer hangs when probing for monitor type.- need to handle ddcprobe dying...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
: 66165 (view as bug list)
Depends On:
Blocks: 64996
TreeView+ depends on / blocked
Reported: 2002-05-13 08:45 UTC by Werner Maes
Modified: 2007-04-18 16:42 UTC (History)
11 users (show)

Clone Of:
Last Closed: 2002-06-12 23:21:18 UTC

Attachments (Terms of Use)
patched anaconda which skips ddcprobe (18.07 KB, text/plain)
2002-05-13 19:03 UTC, Michael Fulbright
no flags Details
Patched anaconda that disables probing and starting an X server upon install (16.38 KB, text/plain)
2002-05-28 20:29 UTC, tgeier
no flags Details
tgeier's patched anaconda, reformatted for Unix (15.81 KB, patch)
2002-05-28 22:25 UTC, Joshua Penix
no flags Details | Diff
Traceback file generated during install using no-X patched anaconda (48.24 KB, text/plain)
2002-05-28 22:32 UTC, Joshua Penix
no flags Details
Patch to packages.py to allow kudzu to be run in "safe" mode (664 bytes, patch)
2003-01-24 01:23 UTC, Greg Bailey
no flags Details | Diff

Description Werner Maes 2002-05-13 08:45:16 UTC
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):

How reproducible:

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

Additional info:

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:
Trace/breakpoint trap

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
inserted /tmp/raid0.o
inserted /tmp/reiserfs.o
load module set done.
After this the system hangs completely.

Comment 1 Werner Maes 2002-05-13 09:20:35 UTC
My probleem SEEMS a lot like the problem described in Bug 64759.
Maybe it's same cause.


Comment 2 Michael Fulbright 2002-05-13 19:02:21 UTC
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.

Comment 3 Michael Fulbright 2002-05-13 19:03:05 UTC
Created attachment 57128 [details]
patched anaconda which skips ddcprobe

Comment 4 Werner Maes 2002-05-14 08:31:58 UTC
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?

Comment 5 Michael Fulbright 2002-05-14 20:47:01 UTC
I'm sorry, be sure to save the attachment as 'anaconda', and make sure it is
mode 0755.

Comment 6 Joshua Penix 2002-05-14 23:02:17 UTC
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
difference either.

Comment 7 Bishop Clark 2002-05-14 23:17:24 UTC
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
today's efforts.  

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.

Comment 8 Werner Maes 2002-05-15 06:57:22 UTC
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? :)

Comment 9 Bishop Clark 2002-05-15 15:30:26 UTC
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
in between.  

Me, I'm not sure.  I can't easily find an ML here that's not being used for
builds or whatnot.

Comment 10 Joshua Penix 2002-05-15 21:29:03 UTC
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).

Comment 11 Need Real Name 2002-05-23 14:07:56 UTC
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?

Comment 12 Michael Fulbright 2002-05-23 19:32:42 UTC
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.

Comment 13 Joshua Penix 2002-05-23 20:56:08 UTC
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.

Comment 14 Jon Knight 2002-05-28 17:37:47 UTC
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.

Comment 15 tgeier 2002-05-28 19:53:02 UTC
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.

Comment 16 Bishop Clark 2002-05-28 20:08:02 UTC

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-)

Comment 17 tgeier 2002-05-28 20:29:37 UTC
Created attachment 58788 [details]
Patched anaconda that disables probing and starting an X server upon install

Comment 18 Joshua Penix 2002-05-28 21:11:08 UTC
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.

Comment 19 tgeier 2002-05-28 21:23:26 UTC
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
you got.

Comment 20 Joshua Penix 2002-05-28 22:25:43 UTC
Created attachment 58792 [details]
tgeier's patched anaconda, reformatted for Unix

Comment 21 Joshua Penix 2002-05-28 22:31:17 UTC
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.

Comment 22 Joshua Penix 2002-05-28 22:32:19 UTC
Created attachment 58793 [details]
Traceback file generated during install using no-X patched anaconda

Comment 23 Werner Maes 2002-05-29 10:21:28 UTC
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  jpenix@projectdesign.com.

Comment 24 tgeier 2002-05-29 13:14:49 UTC
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.

Comment 25 Jon Knight 2002-05-29 17:49:35 UTC
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... ;-)

Comment 26 Need Real Name 2002-05-30 13:30:08 UTC
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.

Comment 27 bill@Freightgate 2002-06-12 23:21:13 UTC
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!!  

Comment 28 Michael Fulbright 2002-06-21 04:44:08 UTC
I will be adding a boot time option to skip the ddc probe in the future.

Comment 29 Jeremy Katz 2002-06-21 20:40:45 UTC
*** Bug 66165 has been marked as a duplicate of this bug. ***

Comment 30 Michael Maraist 2002-06-28 20:42:49 UTC
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 
post-install stage.

Comment 31 Need Real Name 2002-07-08 15:42:49 UTC
Why is this marked as closed?  The fix only works for upgrades, not new
installs..  :(

Comment 32 Werner Maes 2002-07-09 15:51:53 UTC
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.


Comment 33 bill@Freightgate 2002-07-09 16:03:14 UTC
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

Comment 34 Need Real Name 2002-07-25 03:53:46 UTC
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.

Comment 35 Adam McKay 2002-07-29 13:13:11 UTC
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.

- Adam

Comment 36 Need Real Name 2002-08-01 16:53:35 UTC
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...

Comment 37 Brian Freeman 2002-08-01 22:37:30 UTC
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
vi /etc/modules.conf
   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.

Comment 38 Martin Rheumer 2002-08-29 02:00:27 UTC
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 ).

Comment 39 Brian Freeman 2002-10-05 02:02:34 UTC
Fails the same on 8.0
Why do we bother reporting?

Comment 40 Petri T. Koistinen 2002-10-05 14:35:59 UTC
This fix didn't make into 8.0 version, 8.1 should have possibility
to skip the ddc probe. See bug 64996.

Comment 41 Dennis DeDonatis 2002-10-07 19:06:54 UTC
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.

Comment 42 Michael Fulbright 2002-12-20 17:38:25 UTC
Time tracking values updated

Comment 43 Greg Bailey 2003-01-24 01:20:57 UTC
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
"anaconda" script.

I'll attach a diff for packages.py as an attachment, even though it's trivial...

Comment 44 Greg Bailey 2003-01-24 01:23:35 UTC
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.

Comment 45 Dennis DeDonatis 2003-04-09 14:31:45 UTC
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.

Comment 46 Dave Weis 2003-09-21 20:23:37 UTC
FYI, I also added nousb nousbstorage on an 1850R with 9 and it works fine.

Note You need to log in before you can comment on or make changes to this bug.