Die IBM DeathStar waren zwar schon damals nicht gerade die Flüsterer unter den HDDs, aber wenn Du die jetzt zwei Räume weiter hörst, dürfte entweder EOL zeitnah bevorstehen, oder das Gehäuse schwingt mit.
Der eine oder andere "Brummkreisel" lässt sich mit solchen Dingern zähmen:
Schon mal Ideen für Karfreitag sammeln, Orgelvorspiel der Art "hart – schwer – langsam".
Sind ein paar schöne Maschinchen dabei. Kann man nur hoffen, dass da ein Großteil davon ein neues Zuhause findet
In der Lausitz sollte sich doch ein schönes Zuhause dafür finden … 
Und wahrscheinlich ist heute ein stabilerer Betrieb als damals mit damaligen BIOS, Treiber und Speicher möglich.
Auf dem System¹ mit einem der beiden vorhandenen K7S5A drin, das in einem Miditower steckt, laufen nach der Frischelkokur auf dem Brett Slackware 14.2 mit Kernel 4.19.303 und seit ein paar Stunden auch Windows XP home SP3 + unofficial SP4 stabil. Als Windows-Treiber werden für IDE, AGP und Ethernet die letzten verfügbaren Treiber von SiS verwendet. Für Sound funktioniert der Treiber von SiS allerdings nicht, dafür geht es mit dem Treiber von Elitegroup für dieses Brett. Auch der Ati-Treiber für die Radeon X1050 funktioniert. Ansonsten stecken nur zwei PCI-Karten mit USB 2.0 und IEEE1394a drin, die auch unter Windows XP aus der Tüte laufen. Auf dem Brett ist ein modded BIOS, das "honeyX BIOS" installiert. Das stammt von damals und bietet gegenüber dem letzten Hersteller-BIOS Unterstützung für den Athlon XP2600+, und vor allem schaltet es den IO APIC frei, wodurch acht weitere IRQ verfügbar werden. Leider läuft in dem System nur noch ein Athlon XP2400+, da sich der ursprünglich verbaute Athlon XP2600+ vor einigen Jahren ohne erkennbaren äußeren Einfluss final abseilte und die Kramkiste keinen Athlon XP2600+ mehr hergibt.
Alles in allem vermute ich, dass der "heute stabilere Betrieb" dieses Bretts nur durch eine Frischelkokur erreicht werden kann, also nicht an irgendwelcher für diese Hardware grundsätzlich geeigneter Software hängt.
¹System:
Aber in solchen Momenten wünscht man sich nen Gerätemanager mit nen Ausrufezeichen.
Nach über 20 Jahren mit Linux als hauptsächlich genutztem Betriebssystem auf dem eigenen Arbeitsrechner wünscht man sich keinen Gerätemanager, sondern einfach einen ordentlichen syslog in /var/log, der in Form menschenlesbarer Dateien (ASCII charset only) in englischer Sprache vorliegt.
Das ist wohl auch schon so 'n Generationending. Mein erster Computer kam noch mit DOS daher. Da war dann ein Jahrzehnt später die Linux-Console nicht sooo hart gewöhnungsbedürftig.
Wenn es denn eine Aussagekräftige Fehlermeldung gegeben hätte. Ne Reparatur Konsole einblenden mit dem Tipp über die Konsole 5 Seiten logs selbst zu checken.
Was meinst Du mit "Reparatur Konsole"? Starten X & GUI und poppt dann ein Konsole-Fenster auf, was eher unüblich wäre, oder startet X gar nicht erst und Dir wird ganz normal ein Konsole-login angeboten, was bei Problemen sinnvoll ist? Der Begriff "Reparatur Konsole" ist mir in 20+ Jahren mit Linux noch nie begegnet.
Linux startet immer erst mal in die Konsole. Bei einem Distro-Kernel, der notwendigerweise mit "late KMS" konfiguriert ist, kommt zunächst die einfache Text-Konsole, dann wird KMS durch Laden der zur GPU passenden Module angeschmissen, und erst danach kommen X & GUI.
Und den syslog zu lesen ist jetzt auch nicht zu viel verlangt. Das mag unübersichtlich erscheinen, aber es wird wenigstens nix versteckt, wodurch eine strukturierte Fehlersuche ermöglicht wird und man sich nicht irgendwelchen Systemreparaturtools oder Wiederherstellungswerkzeugen auf Gedeih und Verderb ausliefern muss.
Das Lesen des syslog lässt sich, wenn man grob ahnt, woran es gerade hängt, oftmals mit dmesg und grep abkürzen.
Wenn nach dem Wechsel von SATA-SSDs Startprobleme auftreten, besteht eine gewisse Wahrscheinlichkeit, das etwas im ATA-Subsystem (IDE, SCSI, SATA) klemmt.
dmesg | grep -i ata
kann dann schon erste Hinweise liefern, bei NVMe-SSDs entsprechend
dmesg | grep -i nvme
FSTAB kontrollieren viele. Also ich auch. Ach, da steht ja noch die 512er als zweites Laufwerk drin. #auskommentiert. Plötzlich rennt alles wieder. Was hat sich da nur geändert?
Geändert hat sich, dass Linux nach dem Auskommentieren nicht länger versucht, auf die zweite, abgestöpselte SSD zuzugreifen. Es ist auch völlig richtig, das Linux stur die /etc/fstab abarbeitet. Woher soll Linux denn ohne Änderung der /etc/fstab durch den Admin wissen, dass die zweite SSD absichtlich abgestöpselt wurde, versehentlich abgestöpselt wurde – SATA-Steckverbinder sind Schlabberkram – oder kaputt gegangen ist? In Deinem Fall weist Dich das Verhalten von Linux darauf hin, dass Du etwas Wichtiges vergessen hast, nämlich unmittelbar nach dem Klonen die /etc/fstab auf dem Klon anzupassen.
Bei Linux hast Du sehr viel mehr Kontrolle über das Betriebssystem als bei Windows. Dieser Vorteil ist natürlich auch eine Herausforderung …
Hätte erwartet das wie bei Windows nicht gefundene Hardware ignoriert wird...
Bloß nicht!
Stell Dir mal ein System mit mehreren SSDs (oder in ollen Kisten HDDs) drin vor, von denen eine, auf die nur selten vom Benutzer zugegriffen wird, die Verbindung zum SATA-Controller verloren hat oder kaputt gegangen ist. Da möchte man schon vom Betriebssystem eine Fehlermeldung bekommen, anstatt dass das einfach unter den Teppich gekehrt wird.
nehme ich ja normalerweise die originalaktivierung. Aber bei xp und vista ist das halt tödlich nervig.
Soweit mir bekannt ist die "Originalaktivierung" bei Windows XP gar nicht mehr möglich, womit das nicht mehr legal aktiviert werden kann.
Besonders hartnäckiger Fall:
System mit AsRock K7Upgrade-600 drin, weitere Eckwerte: AMD Sempron 3300+; 2 GiB RAM = 2× 1 GiB DDR1 PC-400 CL3; Ati Radeon 9600Pro (AGP 8×); IDE-HDD; 2× SATA-HDD; IDE-DVD-RW; FDD 3½″ 1,44 MB; FDD 5¼″ 1,2 MB; 420 W ATX 1.x Chinaböller; ATX-Miditower.
Schon vor längerer Zeit wurden vier Blähkos 3300 µF 10 V durch 3300 µF 16 V ersetzt. Danach lief das System überhaupt erstmal, aber meist erst nach dem zweiten Startversuch. Der erste Startversuch endete meist mit BIOS error beeps. Also wurden noch die vier Elkos 1500 µF 6,3 V durch 1500 µF 10 V ersetzt. Im fliegenden Aufbau mit anderem Netzteil und ohne Laufwerke startete das System nun zuverlässig. Wieder im Gehäuse eingebaut: Eingeschaltet – geht nicht. 
Also mal die Spannungen vom Netzteil gemessen: +4,89 V auf + 5 V sind zwar noch erlaubt aber doch etwas knapp. Alle Laufwerke abgestöpselt: +4,96 V auf + 5 V. Da könnte also der eine oder andere Elko im Netzteil sein Lebensdauerende erreicht haben. Da es ein ATX 1.x ist, das auch die −5 V raus haut, dürfte eine Frischelkokur lohnen, denn ATX 1.x Netzteile gibt es neu nicht mehr.
Anderes Netzteil rein, dass unlängst eine Frischelkokur bekam: Eingeschaltet – geht nicht.
Brett wieder raus, fliegender Aufbau: Startet zuverlässig.
Dann mal im fliegenden Aufbau das Brett senkrecht entsprechend der Einbaulage im Gehäuse gestellt: Eingeschaltet – geht nicht.
Dann mal bei senkrechter Position des Bretts Kraft auf die Grafikkarte ausgeübt, und bei Druck auf die Grafikkarte Richtung Brett startete es. Wieder im Gehäuse eingebaut war das reproduzierbar.
Ende vom Lied: Das Brett sitzt nach dem Einbau "zu tief" im Gehäuse, wodurch die Grafikkarte nicht tief genug im AGP-Slot steckt. Nach dem Aufbocken des Bretts um ca. 2 mm mit Unterlegscheiben, bei zwei Löchern möglich zwischen Bolzen und Gehäuseblech, bei den anderen vier Löchern mangels Bolzen nur möglich mit Kunststoffunterlegscheiben zwischen Brett und Auflagepunkten im Gehäuse, läuft das System endlich so, wie es soll, also stabil nach dem ersten Einschalten.
Das kann man ja korrigieren.
In der englischsprachen WP habe ich das ergänzt, und deutschsprachige Artikel zu IT … let's switch to English language. 
Notfalls auf 100 FSB oder 112 laufen lassen und den Multi verändern?
Das BIOS erlaubt keine Einstellung des Multiplikators.
Wenn die Suchmaschine gefüttert wird mit: sis 730 133 problem
kommt als ein Treffer:
und damit ist klar, dass das mit 133/133/33 nicht funktionieren kann. 
Ein Athlon XP 2400+ läuft auf dem Brett nicht, auch nicht mit 100/100/33. Es startet zwar, friert dann aber bei memtest86+ im ersten Durchlauf ein. Somit bleibt es beim Athlon XP 2200+, der @ 112/112/34 mit mageren 1,512 GHz läuft.
Die deutschsprachige WP ist zu SiS-Chipsets 'n Totalausfall. In den beiden für den SiS 730 relevanten Artikel in der englischsprachigen WP wurde obiger Link als Referenz hinzugefügt. Da stand vorher nämlich, dass der SiS 730 133 MHz FSB unterstützt, was aber real wohl erst ab stepping B1 der Fall sein dürfte.
Besonders ärgerlich: Das Tauschen aller 20 auf dem Brett vorhandenen, optisch unauffälligen, grünen Luxon-Zeitbomben, was in diesem Fall alle Elkos ≥ 470 µF betraf, war wahrscheinlich völlig unnötig, da dadurch keine Verbesserung erreicht wurde.
Jetzt nach dem Elko-Tausch:
memtest86+ 5.3.1b
Nach Deinem Hinweis:
memtest86+ 4.3.6: schmeißt @ 133/133/33 bei Test #6 Fehler, läuft @ 112/112/34 fehlerfrei durch
memtest86+ 7.2.0: schmeißt @ 133/133/33 bei Test #7 Fehler, läuft @ 112/112/34 fehlerfrei durch
Damals vor dem Elko-Tausch:
memtest86+ 5.0.1
Hatte mal fälle das neuere oder ältere Versionen Fehler produzierten, was wohl Software bedingt war..
Das hatte ich nur mal bei Hardware aus dem Mesozoikum, Dunstkreis 386…486.
Und dann laufen ältere Version u.U. nicht korrekt auf sehr neuer Hardware, wobei hier das Fehlerbild von "friert irgednwann ein" bis "startet nicht" reicht. Auf x86_64 sollte es nach meiner Erfahrung Version 6 64-Bit sein.
Thread-Exhumierung:
Alle Elkos ≥ 470 µF wurden getauscht: Immer noch der gleiche Mist.
Mit Einstellung 112/112/34 MHz läuft es stabil, mit 133/133/33 MHz, was der Athlon XP2200+ und die beiden 512 MiB SDRAM PC-133 Riegel können und auf anderen Brettern auch liefern, schmeißt memtest86+ reproduzierbar bei Test #7 weiße Schrift auf rotem Grund. Selbst maximal konservative RAM-timings schaffen keine Abhilfe.
Gibt es da noch irgendeine Chance, das Brett stabil mit 133 MHz FSB in Gang zu kriegen?
zwei Kleinigkeiten:
K7S5A […] lief nur mit Linux noch stabil, da RAM Errors und badmem-flag gesetzt war. Schuldig waren die Elkos beim RAM Slot ca..
Dieser Hinweis in Kombination mit der Tatsache, dass nach der ersten Runde Elkotausch auf einem K7S5A das onboard-100Base-TX (SiS 900) nach Jahren wieder funktioniert, führte dazu, dass am Wochenende auf beiden K7S5A alle Elkos ≥ 1000 µF getauscht wurden.
Vor dem Elkotausch durften bei beiden K7S5A keine aggressiven RAM timings eingestellt werden, also etwa für "DDR PC-400 CL3"-Riegel CL2 @ FSB266, was auf vielen anderen Brettern problemlos läuft. Die beiden K7S5A liefen nur mit den "setup defaults" (Timing Setting Mode = Normal; SDR/DDR CAS Latency = SPD). nach dem Elkotausch laufen beide K7S5A mit aggressiven RAM timings. Gesteckt sind auf beiden K7S5A je 2 GiB RAM = 2× 1 GiB DDR PC-400 CL3. Im BIOS wurden nun gesetzt Timing Setting Mode = Ultra; SDR/DDR CAS Latency = 2T. memtest86+ wurde auf beiden K7S5A nach jeweils drei fehlerfreien Durchläufen beendet.
Am onboard USB 1.1 funktioniert nun auch wieder eine USB-Maus. Vor dem Elkotausch war daran nicht zu denken. Es ging nur mit einer PS/2-Maus oder einer USB-Maus an einer PCI USB 2.0 Karte.
Löten an 4-layer-PCB ist nach wie vor sehr nervig, aber für den ollen Kram gibt es ja keinen Ersatz mehr oder nur noch zu Mondpreisen.
PcChips M810D
Vor einiger Zeit verabschiedete sich USB partiell mit einem kleinen Rauchwölkchen. Da muss es wohl 'n Kurzen beim Anschluss eines Kartenlesers gegeben haben. Seitdem waren die vier Heck-USB-Anschlüsse, die zwei der drei auf dem Brett verfügbaren USB-Ports entsprechen, und der mit einem Pärchen dieser Anschlüsse shared Pinheader, an den der Kartenleser angeschlossen worden war, tot. Linux (lspci, lsusb, cat /proc/interrupts) zeigte die USB-Ports aber weiterhin korrekt an. Also mal 'n self-powered-hub angeschlossen und der wurde von Linux ebenfalls erkannt. Eine daran angeschlossene USB-Maus funktionierte. Das legte die Vermutung nahe, das nur die +5 V an den Heck-USB-Anschlüssen nicht mehr funktionierten, D+ und D- hingegen schon.
Nach dem Einlöten einer selbstrückstellenden Sicherung (60 V; 0,5 A hold; 1,0 A trip), was durch Nutzung des +5 V-Pins des shared Pinheaders und eines nicht genutzten Lötstützpunktes auf dem Brett, an dem die +5 V vom Netzteil anliegen, sogar auf der Bauteilseite des Bretts möglich war, funtkionieren die vier Heck-USB-Anschlüsse wieder.
Warum alle vier Heck-USB-Anschlüsse, also zwei USB-Ports auf einer +5 V-Leitung liegen, erschließt sich mir allerdings nicht. Eigentlich sollte doch jeder USB-Port seine eigene, im Falle von USB 2.0 mit jeweils 0,5 A abgesicherte +5 V-Leitung haben.
Elko-Tausch auf einem der beiden mit Blähkos belasteten Asus A7N8X-E Deluxe:
3300 µF 6,3 V → 3300 µF 10 V (8 Stk.)
Beim Ausbau des Bretts fiel noch ein 820 µF 6,3 V RM 3,5 auf, der auf halb acht hing. Kann natürlich auch durch die Elko-Pest verursacht worden sein, sah aber eher nach der Folge eines rein mechanischen Ereignisses aus. Jedenfalls fiel die Entscheidung, auch diesen und einen baugleichen Elko zu ersetzen. 820 µF ist jetzt aber noch so gängig, als dass man diesen Wert inna Kramkiste liegen hätte. Also wurde am Nachmittag die witterungsbedingt unvermeidliche Fahrradtour um eine Schleife zum letzten Elektronikbauteilehöker in H verlängert. Der hatte nur 820 µF 25 V RM 5,0, aber egal. Auf dem Brett befinden sich in der Nähe dieser beiden Elkos weder Stecker noch Slots noch Kühler. Und RM 3,5 scheint eh gerade auszusterben.
Kolateralschaden:
Für den Tausch von fünf der acht 3300 µF musste der Prozessorkühler runter. Beim Abnehmen oder wieder aufsetzen des Kühlers, oder einfach nur so, hat sich der Athlon XP 3200+ AXDA3200DKV4E sehr wahrscheinlich final abgeseilt. Lüfter drehen, aber kein POST, keine error beeps …
Mit dem letzten Athlon XP 3200+ AXDA3200DKV4E aus der Kramkiste läuft die Kiste, gerade rödelt memtest86+. Das sieht also nicht gut aus für den anderen Athlon XP 3200+, eine letzte Chance auf 'nem anderen Brett bekommt er aber noch, bevor dessen Beisetzung eingeleitet wird.
Nachtrag:
Auf 'nem anderen Brett kommt mit dem Prozessor auch nix mehr. Der ist hin!
Wie wäre es mit der Veröffentlichung vom Quellcode von MS Xenix 1.00 oder MS OS/2 1.00? Oder noch besser: Dem BASIC für den Altair 8800?
Ist schon klar: Du hast die dazu passenden Maschinen zu Hause stehen und möchtest OSS drauf laufen lassen. 
