Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 Description of problem: I have several Dell 670n workstations. All of them installed fine from 2 sets of Fedora Core 4 CDs. All but one that is. This last machine doesn't want to install. I am unable to do: - Graphical Install - Text Based Install - CD Checksum - Emergency Repair - Graphical Install with noprobe option - Text Install with noprobe All of these bring me to the same state. It starts to boot, but eventually spews out an inifinite number of: release_dev: tty3: read/write wait queue active! It appears to happen after a line that has ide1 on it. I have tried replacing the media and CD/DVD reader with no difference. I am able to run memtest86. So far no reported errors, but I have 4GB to test. Version-Release number of selected component (if applicable): Fedora Core 4 base version of install How reproducible: Always Steps to Reproduce: 1. Insert FC4 install disk 1 2. Install with linux, liunx text, linux noprobe, linux text noprobe, linux repair Actual Results: See install start to boot, but then inifinite loop of this message: release_dev: tty3: read/write wait queue active! Expected Results: Proceed to normal installation screen. Additional info: System has SCSI disk. Has dual Pentium processors with Hyper Threading turned on. (System is just like the others purchased from Dell in same batch that work fine) I am able to reboot with ctrl-alt-del when this happens. I can also remove the CD with the CD-reader eject button.
Thinking about this more over the weekend, I'm not cerain if this is an anaconda issue or a kernel booting issue. I suppose I never get fully booted into anaconda.
Are you trying to install the x86-64 release ? (The bug is filed against i386) The reason I ask, is that for x86-64 I believe we use the SMP kernel for installs. If so, things to try.. - booting with maxcpus=1 - booting with acpi=off It smells like a race in the tty layer to me, so limiting the install to a single CPU is probably the best behaviour. For future releases, we should probably make sure the installer always starts up with 1 cpu is isolinux.
I tried your suggestions. It appears that the acpi=false option does the trick. The maxcpus=1 does not. I have 2 Intel Xeon processors with hyper threading and probably EM64T. I am definitely an SMP system. I didn't realize that it's not considered an i686 system anymore. Thanks for your help, -Dan
so, if you do the install with acpi disabled, and then run yum update, it'll grab the latest updates, including a newer kernel. Can you see if that one then boots without the acpi disabled ?
Unfortunately, I cannot do what you requested. The system installed is in a secure environment. However, using our SNARE enabled 2.6.12 kernel, it seems like we need the acpi=off still on boot. Otherwise, nash hangs forever (waited over 15 minutes). Normally, nash hangs for 2 minutes and then proceeds for us.
Ok, given the inability to debug this further, I'll close this bug, as you have the acpi=off workaround. Thanks.