Bei der Auswahl von Komponenten für einen Rechner sollte man nicht nur wegen Linux auf ein paar Dinge achten.
Boards
Die Mainboardauswahl ist nur von daher ein Thema, dass man darauf achten sollte, dass evtl. vorhandene Onboard-Komponenten (Sound, LAN, SCSI, EIDE) auch von Linux unterstützt werden.
Ein Board sollte sorgfältig ausgewählt werden und nicht an der falschen Stelle sparen! Wenn diese wichtige Komponente nichts taugt, hat man nur Ärger (auch, aber nicht ausschliesslich, mit Linux).
CPUs
AMD- und Intel-CPUs funktionieren beide gut.
Wer Dir weismachen will, dass nur Intel funktioniert und AMD zu "inkompatibel" ist, ist entweder schlecht informiert oder Händler, der nur Dein Bestes will (= Dein Geld 
).
Bei Athlons wird gerade drüber diskutiert, ob mem=nopentium auf der Kernelkommandozeile zu empfehlen ist oder nicht. Bis das geklärt ist, sollte man das besser machen, schaden tut es nicht.
RAM-Module
Bei RAM-Modulen sollte man auf gute Qualität achten.
Instabile Systeme liegen oft in schlechten RAM-Modulen begründet. Auch wer beim Kompilieren öfters mal "Signal 11" sieht, sollte seine RAM-Module prüfen.
memtest86 ist ein gutes Tool zum Speicher testen - SuSE 7.3 hat dies auch im LILO-Startmenü drin. http://www.memtest.org/ memtest V1.11 bietet noch mehr Informationen.
SCSI-Controller
Mickrige ISA-Billigadapter, die div. Scannern beiliegen: Finger weg! Lieber nen kleinen PCI-Adapter von z.B. Symbios, der tut stressfreier und belastet die CPU deutlich weniger.
EIDE-Controller
- HPT370A-basierende ATA100-Karten/onboard-Controller werden gut unterstützt
- Promise PDC2065 eigentlich auch, hatte aber einmal Stress mit ner GF3
- die "üblichen" onboard-EIDEs von Intel/VIA/etc. tun in aller Regel auch gut
RAID-Controller
SCSI
Mylex AcceleRaid 160 funktioniert problemlos (kompatibel zu DAC960 Treiber - schon seit Ewigkeiten Bestandteil des LinuxKernels)
allerdings: RedHat Versionen bis 7.3 haben einen kleinen Bug der erfolgreich verhindert, das root-fs auf das Raid zu legen
- ist aber leicht korrigierbar
siehe hierzu https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62206
IDE
Festplatten
IDE, SCSI, USB - alles kein Problem.
Linux kann übrigens auch dann auf Festplatten zugreifen, wenn sie dem BIOS gar nicht bekannt sind. Das ist besonders dann nützlich, wenn man eine NeueFestplatte einbaut, die vom BIOS nicht erkannt wird, weil wiedermal eine Größenbeschränkung überschritten wurde (z.B. 32GiB).
Man braucht lediglich ein vom BIOS erkanntes Laufwerk zum Booten (Diskette, Festplatte, CD-ROM etc.).
Tipps
Da die Haltbarkeit von Festplatten leider immer kürzer wird, empfiehlt sich die Verwendung der SmartMonTools, damit lässt sich der S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology)-Status der Platte abfragen. Ebenso kann ein Selbsttest aktiviert werden. (Bei RedHat ist eine etwas ältere Version im Paket kernel-utils enthalten.)
Mit hdparm lassen sich Parameter der Festplatte einstellen, z.B. Write-Cache oder Übertragungsmodus. Auch für Hotswapping wird es benötigt.
Frage: Ich habe mir bei ebay eine IBM SCSI UW HDD (DDRS...) gebraucht gekauft. Sie hat zwei Tage lang funktioniert und heute bekomme ich solche Meldungen:
scsi0: MEDIUM ERROR on channel 0, id 12, lun 0, CDB: 0x28 00 00 d4 7d 0a 00 00 78 00 Info fld=0xd47d70, Current sd08:20: sns = f0 3 ASC=11 ASCQ= 0 Raw sense data:0xf0 0x00 0x03 0x00 0xd4 0x7d 0x70 0x18 0x00 0x00 0x00 0x00 0x11 0x00 0x00 0x80 scsidisk I/O error: dev 08:20, sector 13925744 scsi0: MEDIUM ERROR on channel 0, id 12, lun 0, CDB: 0x28 00 00 d4 7d 70 00 00 02 00 Info fld=0xd47d70, Current sd08:20: sns = f0 3 ASC=11 ASCQ= 0 Raw sense data:0xf0 0x00 0x03 0x00 0xd4 0x7d 0x70 0x18 0x00 0x00 0x00 0x00 0x11 0x00 0x00 0x80 scsidisk I/O error: dev 08:20, sector 13925744 dd: /dev/sdc: Input/output error
jedesmal wird ein anderer sektor angegeben.
das ist genau das, was da steht: ein medium error, also ein Fehler auf dem Speichermedium. Möglicherweise also schlechte Sektoren, Headcrash. o.ä. - war die Platte gut verpackt und die Verpackung in gutem Zustand, als Du sie bekommen hast?
zweimal bisher auch einen "parity" error.
das wiederum ist ein Problem auf dem SCSI-Bus: die Daten wurden nicht richtig übertragen und das fiel wegen einem Paritaetsfehler auf (zus. zu den 8 oder 16 Datenbits wird bei SCSI auch ein Kontrollbit mit über das Kabel übertragen
bei den anderen beiden platten am bus tritt der fehler nicht auf. der fehler tritt mit hoher wahrscheinlichkeit auf, wenn man große mengen liest: dd if= /dev/sdc of=/dev/null beim normalen arbeiten in den letzten zwei tagen (partitionieren, mke2fs, debian installieren, kernel kompilieren, lilo installieren,...) trat der fehler nicht auf. zum ersten mal, als ich heute einen größeren tree auf eine partition auf dieser platte kopieren wollte.
kann Zufall sein. Klemme die Platte einzeln und richtig terminiert an den SCSI-Bus und teste dann nochmal
Wenn die Platte irreparabel (ich meinte damit software-mäßig irreparabel, wenn sich das irgendwie, z.b. durch ein (low level) format, korrigieren lässt. wäre das ok für mich) beschädigt ist, müsste ich das sehr schnell wissen.
wenn eine Platte zus. zu den sog. factory defects (die nicht nach aussen erscheinen) auf einmal noch weitere Defekte nach aussen zeigt, dann ist was faul.
ich habe gemerkt, dass das scsi kabel geknickt war. zusammen mit dem "parity error" lässt mich das auf ein kabel problem hoffen. wie kann ich das unkompliziert testen?
- anderer rechner controllor
- anderes kabel (falls ich eines finde)
wenn Du ein Kabel-Problem hast, wäre das das Logischste
- weniger geräte am scsi bus (zur zeit 3, normalerweise +internes cd-rom, eventuell +externe geräte (tape, CD-Writer))
vor allem, wie interpretiere ich die ergebnisse (die fehler treten sporadisch auf)
- das ist auch wichtig, um Unverträglichkeiten / zu hohe Last am Bus auszuschließen
wenn das gerät defekt ist, muss ich dem verkäufer erklären, wie _er_ (ich nehme an win user) den fehler reproduzieren kann. er behauptet, die platte sei fehlerfrei und den eindruck machst sie auf den ersten blick auch.
Drucke einfach die Fehlermeldungen aus dem Log ihm aus und die Bootmeldungen von Linux, das ist zwar strengenommen kein Beweis, sollte aber reichen. Wichtig ist, dass Du Fehler bei Dir (Controller, Kabel, Terminierung, Unverträglichkeit mit anderen Devices) ausschließen kannst. Von IBM gibt es auch einen Plattentest namens DFT, den kannst ja auch mal drüberlaufenlassen.
danke im vorhinaus -- JanKorger