(Arch) Linux Won't Install

I'm having trouble installing Arch Linux alongside Windows *whatever* on a Samsung 850 EVO SSD. I recognize this may be a better post for the Arch forums rather than reboot.pro, but quite frankly, I post on very few other forums anyway. And I believe this may be due to some anomaly with my hardware rather than with Arch itself.

 

I have 2 internal drives, the SSD, and a HDD in an optical caddy. Arch's /root partition will be on the SSD, with the /home and swap partitions on the HDD.

 

But I always get this error:

 

 

 

The most prominent things in this picture that stand out are "ATA bus error" (not sure what this means but I think it's related to one of my drives), and "failed command: write FPDMA queued". It always happens either after trying to format and mount my 2 partitions, or when using the "pacstrap -i /mnt base base-devel" command to try to download the necessary system files and write them to disk. The install commmences normally up until then, because no info is written to disk until the partition creation/mounting/downloading begins. Arch is a CLI-only installer, no point-and-click GUI. I've installed it many times before on different machines, so I'm confident I'm following the installation guide correctly (and reading it along the way to be sure).

 

I've also checked the hash of my ISO to ensure integrity, try booting it as an emulated USB and disc from my Note 4 via DriveDroid app. Creating a physical USB gives the same results. And the same USB works fine for installing Arch on a friend's Toshiba laptop. So I think this eliminates the source ISO as the cause.

 

I can install other Linux variants like Kali or Mint. But I get errors in the kernel log when booting Kali, (the text that flys by when booting, not sure what it's called), which seems to say something about the SSd's EFI partition having an invalid/incorrect number of sectors (it's 512MB MB in size), with the message "not automatically fixing this". Kali boots fine otherwise, but that message is troubling. There are also other Arch alternatives, the most prominent probably being ArchBang, that have a GUI installer, which are based on Arch with minimal changes, and installing it would probably work (it did before). But this isn't considered "pure", and Archers view these other distros as taking shortcuts. While I don't necessarily agree or disagree with some hardcore Arch users, I would rather build from the ground up for the learning experience than install a similar distro that does some of the work for me.

 

It makes no difference whether I install in native UEFI, UEFI DUET, or BIOS/MBR mode, I always get these errors when installing Arch or booting Kali. So I don't think this is related to firmware booting mode or partitioning. Both disks are standard GPT with an EFI partition, with multiple other partitions containing different filesystems for other OSes, storing data/files, etc.

 

Any help would be appreciated!

"ATA bus error" (not sure what this means

The kernel detected a increasing S.M.A.R.T UDMA_CRC_Error_Count.
http://lime-technolo...p?topic=30766.0

There is broken hardware still. Replace the motherboard.

 

The kernel detected a increasing S.M.A.R.T UDMA_CRC_Error_Count.

 

As much as I hate to say it, you're probably right. I'm not even using the SATA 3 BIOS hack I've mentioned before, I'm now using an otherwise stock BIOS that only has all the hidden menu items unlocked, but with no other modifications. So, my SATA speed is limited to SATA 2 now, I think. My model of laptop has (from my understanding), a manufacturing defect in the SATA controller (not just mine, but a whole bunch of laptops that were batch-manufactured a few years ago with the same problem). It was supposedly partially fixed (by either Dell or Intel, whoever makes the controller) with a feature called "B3-stepping", which my model has. Earlier releases of my model didn't have this fix. But many still reported SATA (3) issues, particularly with SSDs. And Dell artificially limited the SATA speeds for my model to SATA 2 as a partial fix (released in the form of BIOS updates). I've said all this before, just figured it would be worth restating. So...........I don't really think that replacing the mobo will fix anything. I took it to a technician recently, he kept it for almost 2 days, and found no issues with the hardware. (I'll elaborate in more detail in my "Autochk program not found when installing Windows 7" thread later.

 

I'm so fed up with this laptop that I will probably either end up selling it cheap (advertised as "for parts" or "as-is", with the issues disclosed). Or I may even put up a thread later on this forum, to donate it to anyone willing to pay the cost of shipping. I think it just wouldn't be right to sell a laptop when it has issues if you have no intention of giving full disclosure to the buyer. I'm not the most ethical/moral person around by a long shot, but I don't like being ripped off and try to avoid screwing others others over (unless I have a vendetta against them and think they deserve it).

Another random idea: set SATA 1 speed. Not a nice aolution, but this may run stable.
Does exist a SATA 1 BIOS?

I'm not aware of any SATA 1 BIOSes released by Dell. SATA 1 isn't a desirable alternative? Isn't that slower than the max speed of many HDDs? It would seem to defeat the point of having an SSD at all. I guess it's a last ditch alternative, is the best that can be said. Replacing the motherboard would cost well over half of what I paid, not counting a tech's labor costs.

 

There are some SATA settings in the BIOS, I'll snap a pic or two and post them.

Pics (to see all 5 just click on First, Second, Third, Fourth, Fifth above each one)

 

http://imgur.com/tre...Jusfe,HC2JxzU#0

 

They were around 4 MB each so I couldn't post them directly. Despite my phone's 15 megapixel rear camera, they were still a bit small and blurred, so I had to increase zoom/resolution and apply color filters to make them easier to read (blue on blue isn't the best choice since they don't contrast each other, but I wasn't thinking at the time).

I'm not aware of any SATA 1 BIOSes released by Dell. SATA 1 isn't a desirable alternative? Isn't that slower than the max speed of many HDDs? It would seem to defeat the point of having an SSD at all. I guess it's a last ditch alternative, is the best that can be said.

Not Dell, may be a third party created a BIOS already, given the suspected half broken hardware.

Yes, it's a last ditch alternative.
A SSD provide a shor file access time, that's the major difference.
Max transfer rate isn't that importand.
Booting a OS won't make a huge difference at SATA 1 speed.
Yes, benchmark shows a difference. And gaming load times will increase.

No, the current BIOS dosn't provide a option to set SATA speed.

Another last ditch alternative: try IDE mode.

I'm not even sure where to find such an alternative BIOS, except maybe bios-mods.com or TechInferno.

 

Won't running an SSD in IDE mode shorten its' lifespan? I'm not doing anything that would decrease that, since I plan to keep the SSD and put it in a laptop (Sager/Clevo) that is worthy of an SSD and will get max speeds. But if the only thing I stand to lose is speed and a slight performance hit, that's acceptable.

 

A few more ideas:

 

Instead of setting SATA/AHCI in BIOS, why not set RAID mode instead? RAID is a subset of AHCI/SATA and everything should work fine. I'm not actually RAIDing either drive anyway. But I have read that Windows won't enable Trim in RAID mode, even if there really is nothing bring RAIDed. True? I'm not sure it will make a difference regardless.

 

A better option (maybe): Put the SSD in the optical disc caddy and the HDD in the primary drive slot. Since ODD is limited to SATA 2, this may work. The only issue would be having to manually choose to boot from the ODD every time I power on (labelled as CD/DVD drive in BIOS, despite the HDD being there). Or maybe I could install a chainloader of some kind on the HDD in primary, which would chainload Windows on the SSD in ODD slot. My BIOS does have an option to set the boot order, but I can't change it, BIOS freezes up solid every time I try. No amount of flashing/reflashing has solved this. I think this will would be a better option than IDE, if it works, since I can still use AHCI. It may also bypass the possibly faulty/defective SATA controller of the primary slot, although of course HDD in primary will still be limited to SATA 2.  This will be my first choice for now.

AnonVendetta, on 13 Aug 2015 - 22:17, said:
Won't running an SSD in IDE mode shorten its' lifespan?

Some OS enable TRIM at IDE mode too. Windows 7 default driver should do this.
Run Samsung Magican Performance Optimization at NTFS partitions sometimes.

AnonVendetta, on 13 Aug 2015 - 22:17, said:
A better option (maybe): Put the SSD in the optical disc caddy and the HDD in the primary drive slot.

That's a good idea. ignore logic at current situation, because he true reason is unknown still.
Play random games. Yes, swap the drives.

I've now come to the conclusion that the system is completely screwed. I tried swapping the drives and installing 7 Ultimate from a clean, verified MSDN ISO. The system boots, upon reaching the desktop I immediately became suspicious and ran SFC /scannow................corrupt files found. I then wiped the partitions and starting sectors, restored from Dell recovery discs, ran SFC upon reaching desktop. Same results.

 

As for Arch, I changed the SATA mode to IDE then booted into Arch install USB. This time I got beyond mounting the partitions, then began the required system files. Then I got http://i.imgur.com/W74E67h.jpg .

 

UnrecovData ******** Handshk

Failed command: Write DMA EXT

Host bus error

 

Those are the main errors that stand out.

 

My laptop has a terminal illness, some kind of SATA controller problem, and I've now decided that the amount of money required to fix it will probably cost far more than what I paid the seller. Now I'm not sure what to do with it. I can only think of one thing, dig one of my 750GB HDDs out of the closet. I'll just put the SSD away for safekeeping for a few months and use HDDs for data and boot drives. If more issues arise even then, then it's either sell/donate it, or go chuck it off in my city's main river.

 

I just find it strange that the technician I took it to found no issues and said it was fine, even after 2 days of diagnostics. I'm going to report my findings to him. I'm sure he'll be shocked.

 

And before I forget, I can no longer access my BIOS *at all*, period, after change disk operation mode to IDE. Hammering down on F12 then selecting Setup results in a black screen with a white cursor in upper left corner (not blinking, no errors, it just hangs). I've left it like this for well over 15 mins and still stuck

I've now temporarily removed the SSD and swapped in 2 HDDs. I've also gone back to booting from MBR rather than UEFI (although I really dont think this was ever part of the problem in the first place). The end result is that no matter which slot each drive is in, these errors still appear. It makes no difference whether the disk operation mode is AHCI/SATA or IDE. The same issues appear regardless of whether I'm using TianoCore DUET or not. It has even happened in a VM when installing Arch to a virtual disk image. Replacing my current SATA cable is the only thing I havent tried, by my tech says my current cable seems fine, so I'm not going to burn more money on a replacement. All of this has further solidified my suspicion that a bad SATA connector on the mobo (or something related) is the root cause, and replacing either the connector or the mobo will far exceed the potential benefit.

 

I did manage to fix my soft-bricked BIOS by reflashing, but had to use some optional, advanced config parameters to clear the CMOS and ensure a full overwrite. I have had no significant issues since then, Windows 7 installed/booted fine afterwards, with no noted disk errors, corrupt system files, BSODs, errors, or other erratic behavior.

 

I gave up on installing Arch because of the errors listed in this topic, but did manage to install Kali. The install went fine but I'm still getting these kinds errors in the kernel text log when booting. Otherwise, updates and softwares have installed fine and no crashes. Next I will install Fedora.

 

But I'm wondering if these errors will have a longer-term impact on system stability, or an increased likelihood of file/filesystem corruption. Is there any reason to keep worrying about this? I suppose I'll simply have to be more vigilant. If Windows can remain stable under these conditions, then Linux should be able to handle things even better. These kinds of errors in Linux are probably just warning messages to remind me of potential problems, but it seems this wont stop me from running Linux altogether. The last thing I want to spend alot of time doing is constant sfc /scannow, chkdsk, and fsck in Linux.

 

If anyone has any other ideas I can try, short of replacing more hardware at a steep cost, please post here to let me know.