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: Always 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) 3. Actual Results: System hangs completely. output: 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: 800*600*16 ... 640*480*-16m 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.
My probleem SEEMS a lot like the problem described in Bug 64759. Maybe it's same cause. Werner
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" Output: 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 mode 0755.
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.
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.
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 in between. 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.
tgeier, 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 you got.
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 jpenix.
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: 394a395 > 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.
Why is this marked as closed? The fix only works for upgrades, not new installs.. :(
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. Werner
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(mousehw.shortDescription()+'\n') else: 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
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 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 reboot All was well at this point. My solution is based on a solution created by Paul Hamm. Linuxboy
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 ). All 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 "anaconda" script. 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.