Beiträge von Arnulf zu Linden

Zitat von Coburg-M

Phenom 2 Kiste.

Früher waren die meisten PCs nicht mehr sinnvoll nutzbar, bevor sie kaputt gingen. Heute gehen die PCs kaputt, bevor sie nicht mehr sinnvoll nutzbar sind.

Vor 'n paar Wochen seilte sich auf Arbeit auch ein Sockel-AM2+-Brett final ab, wobei der Rest, u.a. ein Phenom II X4 945, 4× 2 GiB DDR2 PC-800 und eine 120 GB SATA-SSD das überlebten. Das DVD-RW-Laufwerk aus der Kiste wanderte letzte Woche in eine andere Kiste (Sockel-AM3+), in der das zuvor verbaute DVD-RW-Laufwerk seinen letzten Gang angetreten hatte.

Henry Mancini: "The Pink Panther Theme"

Ray Anthony: "Dragnet"

Du Folterknecht, du!
Das arme Paulchen – und der arme Am5x86-P75

Wenn Helligkeit der wichtigste Parameter ist, kommt der ViewSonic zum Hyundai. Wenn Kontrast der wichtigste Parameter ist, kommt der Hanns.G zum Hyundai.

Generell ist es nicht trivial bei Dual-Monitor-Setups mit zwei unterschiedlichen Monitoren ein befriedigendes Gesamtergebnis zu erzielen. Wenn man da keinen Zufallstreffer landet, geht das Gefummel mit Helligkeit und Gammakorrektur los.

Für ein befriedigendes Gesamtergebnis ist im konkreten Fall eine Grafikkarte mit zwei DVI-D-Ausgängen oder zwei (idealerweise baugleiche) Grafikkarten mit jeweils einem DVI-D-Ausgang erforderlich. Vergiss VGA! Das ist nur was für Röhrenmonitore. Auf einem Flachbildschirm liefert VGA gerne mal Pixelmatsch. Zudem ist es technisch total hirnrissig, das digitale Grafiksignal durch einen D/A-Wandler zu jagen, dann das störanfällige Analogsignal durch das VGA-Kabel zum Flachbildschirm zu schicken, nur um es dort wieder durch einen A/D-Wandler zu jagen.

ANTHRAX - Caught In A Mosh

Rammstein: Sonne (Klavierbearbeitung)

Gleich mal die Noten geordert, denn wenn das auf 'm Klavier geht, dann sollte das auch auf der Orgel …

Zitat von Sje

Mein Gigabyte GA-970A-DS3P 2.1 AM3+ hat keine Probleme mit USB-Tastaturen.

Mit USB-Tastatur kein Zugriff auf 's BIOS (Sockel AM3+):
Gigabyte GA-970-UD3
MSI 990FXA-GD80

Zitat von Sje

Der Phenom II X6 1100T soll auf ein Gigabyte GA-770T-UD3P 1.0.

Jetzt wird es skurril.
Mein anderer Phenom II X6 1100T steckt auf einem Gigabyte GA-MA770-UD3 rev. 1.0, also einem Vorgänger zu Deinem GA-770T-UD3P. Auf Sockel-AM2+ ist der Phenom II X6 1100T die Krone der Schöpfung.

Zitat von Sje

Das Asus M4A785T-M spinnt schon ein bißchen, […] mit einer USB-Tastatur kommt man nicht ins BIOS.

Das Theater kenne ich von diversen Sockel-AM3+-Brettern, also neueren als Deinem. Für 's Büro-Umfeld ist das aber durchaus ein "Feature".

Zitat von Sje

Ausserdem kommt der Phenom II X6 noch auf ein anderes Mainboard, den das Asus M4A785T-M läuft zwar mit dem X6, aber so besonders ist das nicht.

Auf was für 'n Brett soll der denn drauf?

Hier steckt ein Phenom II X6 1100T auf einem Asus M5A78L-M USB3. Das scheint quasi ein Nachfolger von Deinem Brett zu sein und ist 'n ziemlicher Mülleimer: USB 3.0 nur am Heck über zwei USB-A-Buchsen verfügbar, SATA nur bis 3.0 GB/s, nur ein PCIe x1-Steckplatz – und das bei Sockel-AM3+. Hab 's auch nur am Start, weil 's damals ein Arbeitskollege entsorgen wollte. Dein Brett ist von der Ausstattung her ja noch karger, aber passt als Sockel-AM3 wenigstens zum Phenom II X6.

Auch in zwei anderen Punkten ähneln sich unsere beiden Systeme:

1. In Deinem werkelt eine NVIDIA GeForce GTX 650 Ti, in meinem eine NVIDIA GeForce GTX 750 Ti.
2. Beide Systeme sind mit der Hälfte des maximal möglichen RAM bestückt, Deines mit 8 GiB = 4× 2 GiB DDR3 (max. 16 GiB mögl.), meines mit 16 GiB = 4× 4 GiB DDR3 (max. 32 GiB mögl.) – habe keine 4× 8 GiB DDR3 rum liegen, sonst wären die drin.

Die durchgereichte Crucial CT120M500SSD1 macht meinem System schon einigermaßen Beine trotz nur SATA 3.0 GB/s.

Zitat von Sje

Mein "Testaufbau" für einen Phenom II X6 1100T:

Der Bildlink ist kaputt: "Server not found".

Hast Du den Phenom II X6 gnadenlos brutal übertaktet?
Nominell hat der 3,3 GHz für sechs Kerne, die 3,7 GHz sind max. turbo für max. drei Kerne.

Mit einer SSD drin für das Betriebssystem wird 'n Schuh draus. Dass muss bei so einem alten System keine "high end" sein. Da reicht 'ne "Durchgereichte" aus einem anderen System oder was schlichtes, z. B. "Patriot Burst 120 GB", die in so alten Kisten vernünftige Leistung für 'n schmalen Taler liefert.

Das Thema ist jetzt hoffentlich durch, beide Betriebssysteme laufen wieder. Das letzte Windows-Update hat dann noch mal irgendwie auf der efi-Partition rumgemüllt, sodass Linux nicht mehr startete und das mit etwas Gewalt unter Einsatz der Slackware64 15.0 Install DVD wieder gerichtet werden musste. Jetzt tippe ich aber wieder auf der Slackware64 15.0.

Denkbar, dass eben dieses Update zuvor das Windows schredderte. Allerdings hatte dieses Windows auch schon einiges hinter sich gehabt, weshalb es vielleicht einfach nicht mehr wollte. Soweit anhand der Bestände auf der Datenhalde nachvollziehbar wurde seinerzeit Version 1903 installiert. Zwischendurch wurde dann das Sockel-AM3+-System mit FX-8350 drauf durch ein Sockel-AM4-System mit Ryzen 7 5800X drauf ersetzt.
Nicht zu einer Windows-Autolyse führen dürfen allerdings so triviale Dinge wie Austausch von Grafikkarte, Ethernetkarte oder Massespeichern, denn der PC ist nun mal ein "offenes System".

Zitat von clik!84

Ich habe zu Testzwecken mal aus Spaß die 21H2 mal neu installiert in VMware. Der erste Start ging gut, der 2. kommt nur das Windows Logo+der Kreis. Die Version ist Crap anscheinend.

Hier gab es im Zuge der Treiberinstallationen jetzt schon mehrere erfolgreiche Neustarts auf realer Hardware. Vielleicht kabbelt sich Windows 10 pro 64-Bit 21H2 nur speziell mit VMware.

Zitat von clik!84

Starte von Stick und wähle Computerreparatur aus. Versuche es damit.
Wirkt manchmal wahre Wunder.
Starthilfe oder Updates deinstallieren meine ich.
oder bootrec /fixboot

Bringt alles nix!

Zitat von Blue

Wenn wir das lösen, gäb es endlich mal ein Lösungsansatz im Netz, neuinstallieren kann ja jeder?

Dann ist es nicht verwunderlich, dass alle Suchen dazu ins Leere liefen. Und das wird auch so bleiben, denn die Hängepartie wird jetzt beendet werden:
RettungNeuinstallation

So wichtig ist mir ein proprietäres Betriebssystem, dass Stand heute eh nur noch ca. 3½ Jahre wird online gehen dürfen, nun auch wieder nicht, als dass ich da noch wer weiß was an Zeit rein stecken werden. Wirtschaftlichkeit spielt hier zwar keine Rolle, aber auch meine Freizeit ist begrenzt.

Zitat von Blue

um das dingens nachher lauffähig zu kriegen, vermute mal nicht das ein einfaches dd da die Lösung ist.

Das "lauffähig kriegen" nach dem Klonen erfolgte mit dem Win10-USB-Stick, von dem aus das mit bcdboot bestiefelt wurde. Es lief nach der Klonaktion einige Tage.
Und dann ging es auf einmal nimmer. Die einzigen nachvollziehbaren Änderungen gegnüber dem Zustand unmittelbar nach der Klonaktion waren der Ersatz des 1000Base-T NIC durch ein 2.5GBase-T NIC und irgendwelche Windows-Updates.

Auf allen anderen zwischenzeitlich von MBR auf GPT umgestellten Systemen, bei denen Windows 10 auch jeweils geklont wurde, um die SSD sauber neu zu partitionieren, traten diese Probleme bisher nicht auf. Allerdings laufen in allen diesen Systemen nur SATA-SSDs. Das Problem ist nur bei dem derzeit einizgen System mit NVMe-SSD aufgetreten.

Zitat von clik!84

Du könntest mit diskpart die Efi-Partition formatieren

Was sollte das bringen? bootx64.efi startet ja.

Zitat von clik!84

Und was ist mit Bootrec.exe?

Vom Win10-USB-Stick gestartet, bootrec.exe /scanos schmeißt:
Anzahl der identifizierten Windows-Installationen "0"

Das war's dann wohl mit "Rettung". Sieht für mich sehr danach aus, dass Windows 10 sich autolysiert hat.

De Wind hett so 'n beten upbruust in Norddüütsland.

Zitat von Blue

Hätte jetzt spontan NTFS-Versionen im Verdacht […]

Geklont wurde mit dd (exakt gleich große Quell- und Zielpartition). Es gab keinerlei Zugriffe mit Linux auf Dateisystemebene (NTFS-3G, ntfs3) auf die Windows-Partition.

Zitat von Pain

Auch wenns für die meisten nix bringt, ich bin froh meinen wichtigen Krempel zumindest auf Infrastruktur zu wissen, die ich ganz oder zu großen Teilen selbst unter Kontrolle habe.

Du bist damit nicht allein!

Zitat von clik!84

Versuche den Windows Bootloader erneut zu installieren,

Das Problem ist schon ein paar Tage alt und einiges wurde schon durchgeeiert, bevor dieser Thread gestartet wurde.

Vom Win10-USB-Stick gestartet lässt sich der Windows-Bootloader neu installieren, \efi\boot\bootx64.efi wird erstellt. Im UEFI gibt es dann auch die Wahl zwischen GRUB oder Windows Bootloader, und auch GRUB nimmt den Windows-Bootloader mit auf. Wenn ausgewählt startet der Windows-Bootloader zunächst normal, aber das endet dann mit der eingangs genannten Fehlermeldung.

Obiges als "clean install", also zuvor alle alten von Windows generierten Einträge unter Linux von der efi-Partition entfernt: gleiches Resultat.

Mit diskpart die Laufwerksbuchstaben vor der Inst. des Windows-Bootloaders richtig zugewiesen, also nvme0n1p2 → C: (NTFS) und sda1 → D: (FAT32): gleiches Resultat.

obiges Szenario mit zuvor allen SATA-SSD/HHD abgestöpselt: gleiches Resultat.

Wenn alles dran hängt, sieht es so aus (Ausgabe auf Linux console):

root@workstation:/home/user# fdisk -l
Disk /dev/nvme0n1: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500P5PSSD8                            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6CB1B719-6B7F-4099-BA62-EB8AD48756C8


Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      2048   1026047   1024000   500M EFI System
/dev/nvme0n1p2   1026048 585936590 584910543 278.9G Microsoft basic data
/dev/nvme0n1p3 585936896 587038719   1101824   538M Windows recovery environment
/dev/nvme0n1p4 587038720 587563007    524288   256M Linux filesystem
/dev/nvme0n1p5 587563008 976773134 389210127 185.6G Linux filesystem




Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: CT2000MX500SSD1 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E7D7A452-EF8A-4BF5-AAC0-CDBD1F0662DC


Device     Start        End    Sectors  Size Type
/dev/sda1   2048 3907029134 3907027087  1.8T Microsoft basic data




Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000VX008-2E31
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F71000A9-4097-41EB-B93E-099408FD3FBA


Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 3907028991 3907026944  1.8T Linux filesystem




Disk /dev/sdc: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000VX008-2E31
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 75B666C8-A77F-4882-9EB7-94A5B2CD10DF


Device          Start        End    Sectors  Size Type
/dev/sdc1        2048 2147485695 2147483648    1T Linux filesystem
/dev/sdc2  2147485696 3907028991 1759543296  839G Linux filesystem

An 4. SATA-Port hängt das BD-ROM/DVD-RW-Laufwerk.

Vom Win10-USB-Stick aus wurde auch mal chkdsk auf nvme0n1p2 und sda1 los gelassen: jeweils keine Probleme gemeldet.

Eine weitere Recherche zu dieser ominösen "System Reserved Partition" aka "Microsoft Reserved Partition" ergibt, dass die nur dann zwingend benötigt wird, wenn BitLocker benutzt werden soll, was hier nicht passieren wird. Diese "System Reserved Partition" müsste vor der Windows-Partition liegen, was quasi eine komplette Neupartitionierung (bis auf die efi-Partition ganz am Anfang) erfordern würde. Beim Verzicht auf Bitlocker soll Windows 10 auch ohne diese "System Reserved Partition" installiert werden können.

Zitat von Playitlouder

Würde vorher mal Abgesicherter Modus dann Sata Treiber neu installieren oder Systemwiderherstellung probieren.

Da kommt es doch gar nicht hin. Die eingangs genannte Fehlermeldung bedeutet, dass der Windows-Bootloader nicht auf die Windows-Partition auf der NVMe SSD zugreifen kann.

Es wird vermutlich auf eine Neuinst. hinaus laufen, wobei vorher die dazu eingangs gestellten Fragen geklärt werden sollten.

Zur Ersparung weiterer Hinweise: aktuelles Backup der Nutzerdaten liegt vor.