I've been distro-hopping with a purpose, though not one others here may have considered. (I'd post screenshots if I could get both installation and networking up at the same time. I'm sure you've seen screenshots of Quirky 7 April 64.)
Recently, I built a machine with 8-cores I had no excuse for. ("But the used parts were so cheap!")
It has a Gigabyte GA-970A-DS3P rev. 1.0 motherboard with an AMD 8320 processor. There is a rev. 2.0 board, so I'm guessing this one is not suitable for overclocking. It seems OK if I stick to specs. Some distros are more tolerant than others. I'm not worried by problems which show up with high-performance video cards; I don't play games. I'm even willing to downgrade to an old GeForce card which is very stable.
I checked basic reliability by using it to compute Pi to 5,000,000,000 decimal places.
I'm using this as a testbed for problems we have with installing on newer machines with a UEFI bios and GPT disks.
At the moment I'm booting from either an SSD small enough to use a conventional MBR or a flash drive. I have terabytes of rotating storage. As much as possible, I would like to dedicate resources on this machine to computational tasks, not eye candy or compatibility. For this reason I've been running BarryK's Quirky 7.
An unexpected problem cropped up when the gigabit Ethernet using a RT8169 chip repeatedly failed to connect, on a line my other machine uses all the time. I've even connected two 50' CAT5 cables end-to-end to go directly from my router to the machine without using the powerline adapter I typically use.
After I traced the problem to an error reported in the dmessage, we decided it must be a kernel issue, because this did not show up with BarryK's April 64 Quirky 7.0.4.1, which has a 3.19.2 kernel. I've now found the same problem in a distro with a 4.0x kernel.
Even stranger, when I stuck in an old Netgear PCI card with a 100 Mb/s Ethernet interface it had a problem in networking with the same distros that failed on the RT8169. I'm now looking for a problem in initialization and DNS handling.
(One discovery I've made is that some distros ignore having the built-in interface disabled in the BIOS. This is a problem for people who get a buggy chip, and need to work around with a separate card.) I may need to tweak PCI bus latency.
I've concluded that BarryK's networking is simply more robust than some very popular distributions, and I'm trying to track down the offending code, and the reason it is in so many distros. Most distros with automatic network setup have no GUI for problematic machines, and for debugging you go directly to CLI tests which vary between distros. Simply telling me which interfaces are available, and asking which I want to configure, without demanding CLI skills specific to the distro, is a big help. Quirky 7 is also the fastest and least resource hogging.
My standard vanilla heavyweight Linux is Linux Mint 17.2 "Rebecca". This installed on this machine, but had the Internet fail, even when it claimed this was connected. Ubuntu 15.04 ran into some problem which prevented easy installation, and I'm not enough of a guru to get around it easily. The Fatdog 700/701 I'm using at the moment on an older machine is the one which had the dmesg showing network problems during boot. (On a recent attempt it failed to boot from DVD to a live desktop, probably because of video. I can work around this, but that still leaves networking.)
The distro with the latest kernel which installed properly was Sparky Linux 4.0, a rolling-release based on Debian unstable. It also had the network problem. Similar problem with Sabayon 15.06, another rolling release.
The 64-bit version of Vector Linux, VLocity 7.1, had multiple problems which stopped me from installing. After experimenting with it I had a boot failure in which it appeared the processor clock was set to 4.0 GHz. That processor is only rated for 3.5 GHz. It might be tweaked carefully to get to 4.0 GHz, but I am not trying. Reset the BIOS and it booted without problems.
I've used the distros which installed themselves properly to get a working bootloader, while waiting for BarryK's version that handles that problem itself.
This machine may have buggy I/O, depending on how you use it, but there is an enormous range of behavior between different distros. On most, tracking the problem down looks like an ordeal.
Added: now posting from April 64 Quirky 7.0.4.1 booted from SSD on that machine. I used Sparky linux 4.0 to install a bootloader (grub2) then added a custom menuentry using clues from the alternate Grub4Dos entry suggested by Barry to get the uuid. This was originally 40_custom in /etc/grub.d; moved to 7_custom after checking that it worked to put Quirky at the top of the list.
Code: Select all
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "Quirky April64 7.0.4.1 frugal in sda2 dir april64-7.0.4.1"{
set root='(hd0,2)'
search --no-floppy --fs-uuid --set c02f47ec-bc89-4742-af5e-97f54efa5769
linux /april64-7.0.4.1/vmlinuz
initrd /april64-7.0.4.1/initrd.q
}
Naturally, I had to run update-grub from a root console within Sparky linux to execute the update scripts. This strikes me as a problem if you are trying to recover a damaged installation.
Still not a clue as to why this machine seems solid while running Quirky, and problematic while running other distros.