Hi,
recently I replaced HDD with samsung 500GB (SATA) on my Asus Z96S and added more RAM. Now I have problems installing linux, but Ididn’t have such before that. HDD set to ACHI (IDE doesn’t work also). Vista works fine.
Tried Ubuntu And OpenSuse 11.1. Instalation just hangs right after boot on first page. With Ubuntu I was able even to install after ten times of trying :), but results are the same, after the boot it freezes also.
I had no problems with default bios settings with a SATA hdd.
Try installing in failsafe mode.
When the splashscreen shows, press esc to get the boot messages for a clue.
In my BIOS I have only these options: set SATA as IDE or ACHI. Tried both of them. There is no option to leave it only as SATA.
Yesterday was trying Debian 5 live CD, noticed such error messages as “AHCI controller dead, very bad” and something UHCI_xx , didn’t noticed it porperly and it also hanged after boot.
Are you sure that your bios supports a drive of that size? IIRC that requires 48-bit LBA. You might check for a bios update.
It appears that pci=nomsi worked around the ahci problem. The kernel now seems to hang at talking to the USB controllers. So first, check the bios setup for a USB setting like “legacy”, and enable that if it is not. Also, if you are using an old USB mouse, try disconnecting that and then booting. If no help there, try adding this to Boot Options:
Turning of AHCI in your BIOS should fix the boot freeze.
SATA AHCI Mode
Common Options : Enabled, Disabled
Quick Review
AHCI is the acronym for the Advanced Host Controller Interface. It is a new interface specification that enables advanced SATA features like Native Command Queuing (NCQ) and hot-plugging.
Unless it is specifically enabled, the SATA controller will run in IDE emulation mode.
This BIOS feature controls the SATA controller’s AHCI functionality.
When enabled, the SATA controller's AHCI functionality is enabled.
When disabled, the SATA controller's AHCI functionality is disabled. The SATA controller will run in IDE emulation mode.
If your system hardware supports AHCI, you should enable AHCI, even if you do not intend to use features like hot-plugging. This is because switching from the IDE emulation mode to AHCI mode is often problematic. Before enabling AHCI for operating systems that do not have native AHCI support though, you should first load the proper device driver.
On the other hand, disabling AHCI support allows for maximum compatibility with older hardware. Even with the proper AHCI driver installed, it is possible for a system to crash while installing or booting up an operating system. Disabling this BIOS in such cases will normally resolve the issue.
Check out the following link for additional BIOS info:
This Wikipedia article Advanced Host Controller Interface elaborates on the above. Note the section on Windows compatibility issues - mentioned in passing in the above - caution is needed when switching this setting once the OS has been installed, depending on the OS version.
I suspect that freeing up the pci bus from message signal interrupts resolves the ahci problem. The other kernel arguments address the problem with the UHCI controller in your Intel chipset; if that is disabled it may affect USB 1.x only devices, and perhaps not even those. USB 2.0 devices all use the EHCI controller. It’s quite possible that the mobo may have a second controller device that uses OHCI instead of UHCI; OHCI supports USB 1.x.
Did you check in the bios for any USB settings like “legacy”? Or possibly another USB controller that can be enabled? And of course, try connecting the mouse to a different USB port if available.
And be sure to try nolapic, then noapic before using brokenmodules=uhci-hcd.
If the problem is the uhci, then the mouse is USB 1.x not 2.0. UHCI was known to have problems; it was only in Intel and Via chipsets - most motherboards support OHCI and EHCI (your mouse would work with OHCI, too).
Look at the kernel line in menu.lst. That noapic, nolapci, and brokenmodules=uhci_hcd are all there, tells me that you used all three at the same time when you booted into the installation, rather than one at a time. So do this to verify which of these is what is enabling you to get through the boot:
When the grub boot menu comes up, hit the Escape key. A pop-up will say that you are entering text mode; accept. Now the menu is a text list. Use the cursor keys to highlight that boot line, and hit the ‘e’ key. The screen will change and you will see the three lines you see in menu.lst above. Highlight the kernel line and press ‘e’ again. Now you are in a mini-text editor. Use the cursor keys to move on the line and the delete key to remove brokenmodules=uhci-hcd. Hit enter to save that line. Then hit ‘b’ to boot that (edited) stanza. If the machine boots, you will know that noapic or nolapic solved the problem. If the machine does not boot, you know it is brokenmodules=uhci-hcd that worked. If it was noapic or nolapic that solved the problem, then repeat these steps except remove both brokenmodules=uhci-hcd and noapic (leaving only nolapic) and boot. If that works, you have a final solution, that is, nolapic. If it does not, then repeat the steps once gain but this time remove nolapic and leave noapic which will work; by process of elimination you have determined noapic is what you need.
It is also possible that the problem is not with the uhci controller itself, but rather the mouse. So if the steps above show that the machine only boots with brokenmodules=uhci-hcd, then repeat the editing step above except delete all three (brokenmodules, nolapic, noapic) and disconnect the mouse before booting. If the machine boots all the way to the login, you know that the problem is with the mouse, not the controller.
Report back what you learned and we’ll go from there.
I forgot to mention that after solving problem with freezing at boot, Ubuntu was working correctly with my mouse. I installed OpenSuse 11.1 with the same boot options like Ubuntu and mouse is not working.
This is really beginning to sound like a hardware issue. I should have raised this as a possibility at the start, given that the behaviors began with adding a new disk & ram. Running memtest against the ram is strongly advised. Be sure to set it up to run the entire battery of tests for long enough - overnight. Check that the sticks are tightly seated. If the ram is DDR, be sure that the pair slots are correctly populated, and that matching sticks are paired. Also, some motherboards don’t like combining sticks with different CAS or voltage ratings.