From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description of problem: Attemping to install the AMD64 version onto a Shuttle SN85G4 mini PC with an nforce3 150 chipset. The CD boots, then hangs just after the ide0 and ide1 lines. I'm installing off of a Sony DW-U10A DVD-RW drive, onto a parallel ATA Western Digital WD800JB drive. I have the SATA off in bios. On Shuttle's German web site (http://de.shuttle.com/linux.htm) they suggest doing: linux ide0=0x1f0 ide1=0x170 hde=noprobe hdg=noprobe for the boot. This does not work in my case, however: linux ide0=0x1f0 ide1=0x170 hda=noprobe hdb=nobrobe hdc=noprobe hdd=noprobe hde=noprobe hdf=noprobe hdg=noprobe hdh=noprobe hdi=noprobe hdj=noprobe gets it to the point where it says /sbin/loader and then it hangs. WS 32-bit boots fine. Is there a work around? I'd like to install 64-bit linux on this machine... Version-Release number of selected component (if applicable): Red Hat Enterprise WS 3 update 1 How reproducible: Always Steps to Reproduce: 1. Boot off the RHE 3 install CD 2. 3. Actual Results: Hang after ide0 and ide1 lines Expected Results: Boot to install program. Additional info:
Some more info: linux hda=noprobe hdb=noprobe hdc=noprobe hdd=noprobe hda=14593,255,63 hdc=cdrom Will boot the AMD64 disc into the installer, but then it complains about no having a Red Hat install CD in the drive. (At this point, I believe it is finding neither the cdrom or hda.) At this point, I'm going to install 32-bit RHE WS 3 and wait for a newer release.
If you could get a serial dump of the failed boot sessions that would help us a lot. Please attach the log to this bug report.
Created attachment 97801 [details] Serial boot logs for several test cases This is a serial boot log for the following cases: Red Hat Enterprise WS 3 update 1 32-bit linux text console=ttyS0,9600n81 Red Hat Enterprise WS 3 update 1 64-bit linux text console=ttyS0,9600n81 Red Hat Enterprise WS 3 update 1 64-bit linux text console=ttyS0,9600n81 hda=noprobe hdb=noprobe hdc=noprobe hdd=noprobe hda=14593,255,63 hdc=cdrom In addition I've made some comments in the text describing the some other permutations.
This looks like it could be a similar problem to one seen on Fedora in Bug 109017. I'll try applying the same fix that was used there.
Yes! So much pain, yet so simple. Booting with: linux acpi=no boots on the install disk. I assume I can go ahead with the install at this point? Or, if you need someone to test a new iso... :) Thanks
For now, it sounds like this is a good workaround for you. I still want to try the "real" fix. You'll have to make sure the "real" kernel boots with the same parameter otherwise the reboot-after-install will hang as well.
Yep, I'm up and running. If you don't have hardware to replicate the error, I'd be happy to test the new kernel.
This is a known issue, and the upstream "solution" is nothing more than a workaround; it automatically detects that it is being run on a suspect NVidia or VIA chipset and specifies "noapic" automatically. I may add this check for the next update. There is no vendor-supported fix for this issue. For now, this workaround is being documented in a release note. I am resolving this bug as CURRENTRELEASE.