Powercolor AX6870 1GBD5-2DH
switch to death 
Letztens lief die noch normal, heute die Kiste eingeschaltet, Pixelfehler und Zeichenfehler im Textmodus (BIOS, GRUB, Kernel boot), wenn KMS kommt, wird es dunkel und statt X & GUI kommt nur noch ein Muster aus hell- und dunkelblauen senkrechten Streifen. Im ohnehin gerade aufgebauten Sockel-AM2+-Testsystem kommt das gleiche Fehlerbild.
ich meine das selbst das einhängen einer festplatte in gparted mit einem "ja, ausführen" und einer damit verbundenen liste der aktion(en) quittiert werden muss... wer nach drei klicks noch nicht bemerkt was er da macht, der wird auch mit der kommandozeile, wenns hart auf hart kommt, seine paritionierung zersägen. :^(
"one click to death" geht doch viel schneller als das Eintippen der "richtigen" tödlichen Zeichenfolge. 
GParted
… ist für solch triviale Dinge nicht gedacht, denn damit kann man auch maximalen Schaden anrichten. GParted sollte man nur benutzen, wenn man genau weiß, was man tut.
Mit Hilfe dieser Anleitung und der entsprechenden Software wurden vorhin die "Asus HD7770-DC-1GD5" und eine "XFX R7 250X R7-250X-ZNJ V1.0" mit UEFI GOP ausgestattet. Beide Grafikkarten funktionieren nun wie erwartet, UEFI startet mit beiden Karten auch mit CSM = disabled.
Für die Durchführung der Vorgänge wurde ein Sockel-AM2+-System im fliegenden Aufbau mit Windows 10 pro 64-Bit und Slackware64-15.0 Dualboot missbraucht. Während GPU-Z zum VBIOS dump und GOP_Updater_v1.9.6.5.k_mod_v0.5.2 zur Integration des UEFI GOP in das VBIOS dump file ihre Arbeit verrichteten, wollte amdvbflash_win_5.0.567 den flash nicht ausführen. Daher wurde Linux in die fbconsole, also mit KMS und ohne X gestartet, wo dann amdvbflash_linux_4.71 seine Arbeit verrichtete.
weils ja keys ohne alles für 4 € gibt
Sind die brauchbar oder sind das welche der Sorte "legal?? – illegal?! – scheißegal!!".
AsRock 890FX Deluxe5:
Bleibt beim Start hängen, keine error beeps aus dem Lautsprecher, kein Bild. Die zweistellige 7-Segment-Anzeige bleibt bei "19" (0x19 = Pre-memory south bridge initialization is started) stehen. Grafikkarte und Speicherriegel liefen zuvor auf dem Brett und funktionieren auf einem anderen Brett. Prozessortausch FX 4100 statt FX 8350 brachte auch nix. UEFI (IC = DIP-8 gesockelt) reflash im flash programmer brachte auch nix.
Völlig überraschend kam das nicht, denn USB 3.0 war schon tot, als das Brett hier ankam. Jetzt könnte der Rest der Southbridge den letzten Gang angetreten haben.
Hier gibt's 'n paar verschiedene BIOS-Versionen für die ASUS Radeon HD 7770 mit 1 GB RAM:
https://www.techpowerup.com/vgabios/?archi…ize=1024&since=
Das habe ich schon längst durchgeeiert. Alle dort angebotenen VBIOS für die verschiedenen ASUS Radeon HD 7770 haben aber eine Gemeinsamkeit:
UEFI Supported: No
Gigabyte bot damals für einige Grafikkarten UEFI VBIOS als Ersatz für das werkseitige legacy VBIOS an. Anders als bei Mainboards sollte sich bei Grafikkarten also UEFI nachrüsten lassen.
Asus bietet für einige andere Modelle mit Radeon HD 7770 GPU das "ASUS VGA Card UEFI VBIOS update tool" an, das mit der vorliegenden Grafikkarte jedoch nicht funktioniert. Somit dürfte es wenn überhaupt nur mit einem modded VBIOS gehen.
Die vorliegende Grafikkarte wird auch als "ASUS Radeon HD 7770 DirectCU 1 GB" bezeichnet.
Hier liegt momentan ziemlich nutzlos eine an sich schöne AMD Radeon HD 7770 (Modell: Asus HD7770-DC-1GD5) rum. Eigentlich würde die sich gut auf dem Asus P8H77-M PRO (mit NVMe boot modBIOS; mit Intel Core i7 3770K und 32 GiB DDR3 PC-1600 drauf) machen, aber die Grafikkarte hat kein UEFI GOP im BIOS und zwingt das Brett immer in CSM, da das Brett für UEFI auf eine Grafikkarte mit UEFI GOP besteht. CSM ist allerdings voll die Moppelkotze, da für NVMe boot UEFI benötigt wird. Deshalb steckt momentan die Radeon R7 240 aus dem Sockel-AM3+-Testsystem auf dem Brett, was aber keine Dauerlösung ist.
Gibt es eine Möglichkeit, der Grafikkarte ein BIOS mit UEFI GOP zu verabreichen, oder ist das ein grundsätzliches Problem ähnlich wie bei Mainboards "ab Werk kein UEFI – niemals UEFI"?
Aber die können ändern welche Keys die zur Aktivierung zulassen, Serverseitig.
Mal sehen, ob das noch Gerichte beschäftigen wird. Je nachdem, was genau damals in den Verkaufsbedingungen stand, könnte das eine nachträgliche Änderung zum Nachteil des Kunden sein, was u.U. einen Verstoß gegen geltendes Recht darstellt.
Heute als defekt und damit zur Verschrottung aussortiert:
- Maxtor 6Y120L0 (3,5"-120-GB-IDE-Festplatte)
Die ist natürlich ärgerlich, denn 120 GB ist ja die maximale (damals) handelsübliche Kapazität für IDE-HDDs, die noch ohne LBA48 auskommt.
So kann man sich auch das eigene Grab schaufeln.
Anders als früher ist bei den meisten Linux-Distros die notwendige Software für einen Bürorechner inkludiert:
KDE 5 lässt sich so einstellen, dass es sich (bis auf wenige Kleinigkeiten und Admin-Tools) wie Windows 10 bedienen lässt. Dazu gibt es LibreOffice (Textverarbeitung, Tabellenkalkulation, Präsentation, Formeleditor, einfache Vektorgrafik, einfache Datenbank), gimp (Pixelgrafik), inkscape (Vektorgrafik, DTP), Firefox (Internet) und Thunderbird (E-Mail). Mehr braucht es im Büroalltag i.d.R. nicht.
Und anders als Windows 11 geht das alles auch ohne TPM 2.0 oder modernste Prozessoren.
Das technisch größte Problem beim Umstieg sehe ich bei diversem USB-Gerümpel, insbesondere ältere USB-only Drucker.
Ganz verschwinden wird Windows sicherlich nicht wegen diverser Spezialsoftware, die es jetzt und in absehbarer Zeit nur für Windows geben wird.
Was passiert zukünftig, wenn man aus einer ollen Kiste die SATA-SSD mit dem mit einem Win7-key aktivierten Win10 raus rupft und in eine neue Kiste implantiert, um da dann auf Win11 hochzuziehen? Dabei dürfte oftmals auch das Problem bestehen, dass von MBR BIOS-boot auf GPT UEFI-boot umgestellt werden muss, wobei in der neuen Kiste i.d.R. von der alten lahmen SATA-SSD auf eine neue NVMe-SSD umgezogen werden soll.
der VIA-Chipsatz erkennt SATA2/3 Festplatten nur wenn sie auf SATA 1 eingestellt bzw. gejumpert sind.
Soweit ich weiß haben SSD's in der Regel keine Möglichkeit auf SATA 1 beschränkt zu werden.
Das Problem ist der Via SATA 1.5 GB/s Controller. Der mag keine SSDs.
nen Celeron mit 2,4 GHz Sockel 478. Also wirklich was für die Tonne. IDE Festplatte
Die Dinger werden allmählich auch weniger. Wenn es noch funktioniert, ist es für die Tonne zu schade.
Die Sockel wurden häufiger gewechselt
Nun ja, AMD ließ den Sockel-A lange laufen, blieb aber wenigstens konsequent bei ia32 auf diesem Sockel. Den Sockel-775 für Intel-Prozessoren finde ich da noch viel chaotischer. Der ging mit ia32 Einkernern (Pentium 4) los und endete mit x86_64 Vierkernern (Core2 Quad). Kuddelmuddel pur.
zum Asus A7V:Laut Manual soll das Board 133 MHz FSB können
Nein!
Die beiden ersten Seiten in Deinem Anhang erwähnen "200 MHz FSB", was totaler Quatsch ist, denn einen mit 200 MHz getakteten FSB bieten erst die letzten Sockel-A-Bretter etwa mit dem "nvidia nForce2 400 Ultra" oder dem "Via KT 600" oder dem "SiS 741" Chipsatz drauf.
Gemeint ist bei dem A7V der "FSB200", der mit 100 MHz getaktet ist. Der Unsinn mit den 200 MHz rührt wahrscheinlich daher, dass beim Sockel-A mit jedem Takt zwei Signale übertragen werden.
Bei Sockel-A bedeuten für den FSB:
FSB200 = 100 MHz Takt
FSB266 = 133 MHz Takt
FSB333 = 166 MHz Takt
FSB400 = 200 MHz Takt
Die letzte Seite in Deinem Anhang stellt die Bustakte korrekt in MHz dar, und da finden sich tatsächlich für den FSB Einstellungen bis 133 MHz. Allerdings steht im Manual weiter unten auf der Seite:
WARNING! Frequencies other than the recommended CPU bus frequencies are
not guaranteed to be stable. Overclocking your processor is not recommended. It
may result in a slower speed and premature wearing of the processor.
Diese Warnung hast Du geflissentlich unterschlagen. Warum nur? 
Auf der zweiten Seite in Deinem Anhang steht nix von FSB266 oder 133 MHz oder der falschen Logik des Manuals folgend "266 MHz FSB".
beteiligte Hardware:
Die NVMe SSD wird von Linux problemlos erkannt und ist als Datenhalde nutzbar. Das UEFI hingegen zeigt die NVMe SSD gar nicht an, womit sie auch nicht als boot device gewählt werden kann.
Das, was auf dem Gigabyte GA-990XA-UD3 rev. 3.0 funktionierte, klappt bei der ThinkStation nicht. In das BIOS image lässt sich zwar der NVMe boot patch integrieren, aber flash scheitert dann an irgendwas:
18 - Error: Secure Flash Rom Verifiy fail.
Das Problem an sich ist bekannt, aber Lösungen werden keine präsentiert oder sind zu gut im www versteckt.
Bei der P300 ist das besonders ärgerlich, da die NVMe SSD mit PCIe 3.0 x4 läuft.
Notensatzrechner, sicherlich nicht "alltäglich", aber immer noch "produktiv" im Einsatz, weil ich immer noch zu faul bin, endlich mal auf das quelloffene musescore, das auf aktuellen x86_64-Linux-Distros läuft, umzusteigen (und zudem derzeit ein Druckertreiberproblem besteht):
Auf der Kiste läuft das Notensatzprogramm "capella 2000" (capella 3.0a-12) auf Windows XP. Zudem funktioniert der Druckertreiber für den Brother MFC-9142CDN auf Windows XP 32-Bit klaglos, was für den ebenfalls recht betagten und nur in 32-Bit verfügbaren 
Linux-Treiber auf aktuellem 64-Bit Linux leider nicht zutrifft.
Die im Vergleich zum übrigen System schlappe (und für Linux deutlich suboptimale) nvidia-Grafikkarte ergibt sich daraus, dass da keine Grafikheizung rein sollte, zumal mein Vorrat an leistungsstarken AGP-Grafikkarten recht übersichtlich ist. Eine Ati Radeon AGP ginge zusammen mit 3 GiB RAM nicht. Die GeForce 6200 stemmt die Monitorauflösung 1920×1200@24 bpp, was in diesem Einsatzszenario reicht.
Die Kapazität der zweiten verbauten SDD reicht derzeit als Datenhalde aus. Da der Rechner immer wieder mal bewegt wird, flog die HDD raus.
