Beiträge von Arnulf zu Linden

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.

Zitat von Blue

Was haste zuerst installiert?

Beide OS waren zuvor auf einer SATA SSD installiert mit MBR & BIOS boot & LILO. Dann wurde nach GPT & UEFI boot & GRUB2 konvertiert. Anschließend wurden beide OS auf die NVMe SSD transferiert. Beide OS liefen danach zunächst von der NVMe SSD, Slackware64 15.0 läuft davon weiterhin (tippe gerade damit). Das einzig nachvollziehbare, was zwischenzeitlich passierte, war ein Ersatz des 1000Base-T NIC durch ein 2.5GBase-T NIC. Der PC greift über diesen NIC nicht auf das Internet zu. Der Internetzugriff erfolgt über den onboard NIC im anderen LAN.

Auf der NVMe SSD im Arbeitsrechner sind Windows 10 pro 64-Bit und Slackware64 15.0 im Dualboot installiert. Bestiefelt wird das Ganze mit UEFI boot und GRUB2. Anfangs lief auch alles, aber mittlerweile startet Windows 10 in einen BSOD "Inaccessible boot device" error 0x0000001.

Ist diese Win10-Inst. noch mit vernünftigem Aufwand rettbar oder ist eine Neuinst. auch im Hinblick auf den Aufwand die bessere Wahl?

Weder zur Rettung noch zur Neuinst. (Dualboot-Szenario, s.o.) finde ich brauchbares im Internet. Entweder suche ich falsch oder es gibt schlicht nix dazu.

@Rettung:
Was ist dafür zu tun? Verfügbar sind ein Win10-Installer-USB-Stick (mit media creation tool erstellt, recht aktuell mit 21H2), die installierten OS (s.o.), Slackware64 15.0 Installer DVD+R (enthält Live-System) und ein Knoppix 9.1 USB-Stick.

@Neuinstallation:
Geht das überhaupt auf der NVMe SSD unter folgenden Bedingungen?
UEFI boot = enabled (Start von NVMe SSD geht sonst gar nicht auf dem Brett)
Secure boot = disabled (ist zwingend!)
GRUB2 bleibt "erste Instanz", von dort aus Dualboot

Dann wird im Zusammenhang mit NVMe & Windows 10 auch eine "System Reserved Partition" mit der Größe 16 MB erwähnt. Wird die gebraucht und wenn ja wofür? Falls die gebraucht wird, muss die an einer bestimmten Stelle liegen oder kann die ans Ende der NVMe SSD, was vom Aufwand her am einfachsten zu bewerkstelligen wäre?

Wenn das mit Windows 10 auf NVMe SSD alles zu kompliziert bzw. wegen secure boot nicht möglich ist, bliebe als Fallback die Inst. auf einer SATA-SSD, wofür eine 120 GB (im äußerten Notfall eine 500 GB) Crucial MX500 verfügbar wäre.

Zitat von Ijarsin

Dann noch die BIOS-Grenzen, da scheint das BIOS des PDC 4L aber etwa 4GB zu unterstützen (Cylinder 4-stellig, also 9999 (oder unterstützt es dann eigentlich doc nur 1023, statt der Eingabe in dem Feld? Jedenfalls zeigt es auch die berechnete Größe >4GB an).
[…]
Mich würde in diesem Zusammenhang wegen der 504MB Partition interessieren,

Das BIOS vieler 486er, insbesondere der älteren ohne PCI-Bus zeigt die Festplattengeometrie und die daraus resultierende Kapazität im Rahmen der Möglichkeiten (hier max. C,H,S = 9999,16,63) zwar korrekt an, die 1024-Zylinder-Grenze (C,H,S = 1024,16,63) besteht aber trotzdem. Mehr Infos zu diesem leidigen Thema findest Du hier.

Zitat von Ijarsin

Es wird aber angeboten zu komprimieren

Vergiss das mit einem 80486DX2-50, wenn Du nicht die Langsamkeit entdecken möchtest.

Zitat von Ijarsin

Nächste Frage: Wie verträgt sich DiskManager DDO mit Grub, weil ich eventuell (nur Test und interessehalber Core Plus 13 und AOSC/Retro dort installieren möchte.

Setups mit GRUB (oder LILO) und DDO sind nicht trivial und entsprechend risikobehaftet. Das DDO landet im MBR. GRUB und LILO schreiben standardmäßig ebenfalls ihren first stage loader in den MBR. Beides geht nicht. Core Plus 13 und AOSC/Retro sagen mir nix, aber wenn letztlich ein Linux-Kernel gestartet werden soll, geht das von DOS aus mit loadlin. Dazu wird unter DOS ein Bootmenü in der config.sys (MS-DOS) mit entsprechenden Einträgen erstellt.

Zitat von Ijarsin

Das BIOS unterstützt aber nicht das Booten von CDROM, und bei 1GB ist der DDO eigentlich nicht nötig, würde aber auch gerne als Slave eine 20GB DDO-Platte anschließen, die von keinem System auf der 1GB Platte erkannt wird, da kein DDO im Bootsektor.

Bei 1 GB ist das DDO wahrscheinlich schon nötig, siehe oben. Eine 20 GB HDD in so einer Kiste will überlegt sein. Es kann passieren, dass der IDE-Controller diese HDD schlicht nicht nimmt. Manchmal geht es, wenn im BIOS dafür manuell C,H,S = 1024,16,63 eingestellt wird.
MS-DOS 6.22 & WfW 3.11 können diese Kapazität bei weitem nicht voll nutzen. Win95 OSR 1.x dürfte auch Probleme haben. Erst Win95 OSR 2.x, das FAT32 unterstützt, kann diese Kapazität voll nutzen. Der Linux-Kernel kann diese Kapazität voll nutzen.
⇒ Eine 20 GB HDD in diesem System hat nur Sinn, wenn auch Win95 OSR 2.x oder Linux installiert werden.

Museumsrechner mit Asus M2N-E drin:
AMD Phenom X4 9850 HD985ZXCJ4BGH → AMD Phenom II X4 945 HDX945WFK4DGM
Laut CPU support list geht nicht mehr.