Update auf 2004 mit Fehler 0x8024a205

[Dabbelju]

Hatte schon einen Kommentar im Artikel hinterlassen undein freundlicher User antwortete gleich mit einem Link. Leider funktioniert dies nicht bei meinem NUC NUC8I7BEH2 mit 8GM RAM. Ich poste mal die Fehlermeldung und hoffe auf Hilfe.

Der Rechner ist erst einige Monate alt und wurde selbstredend nach dem Kauf neu installiert. Sämtliche updates liefen bisher ohne Probleme durch. Als Laufwerk C ist ein Transcend MTS800 M.2 SSD 128GB eingebaut.

2004 fwhler.PNG

[Tante Google]

[moinmoin]

Wenn ich die Fehlermeldung richtig deute, braucht das Update eine GPT-formatierte Platte. Du hast aber MBR für das normale Bios.

[DK2000]

Deute das genau umgekehrt, aber wie auch immer, macht kleinen Sinn, wenn das Setup aus de laufenden Windows heraus gestartet wird.

Ein Screenshot der Datenträgerverwaltung mit aufgesogener Spalte "Status" wäre interessant. Eventuell auch die Logs, wobei ich gerade nicht genau weiß, an welcher Stelle im Setup über das Windows Update diese Meldung kommt. Gehe aber mal von der C:\$Windows.~BT\Sources\panther\setupact.log aus.

[Dabbelju]

Dank an euch.

Genau das habe ich auch nicht richtig verstanden, was in dem Link aus den Kommentaren beschrieben wurde, MBR oder GPT?

Datenträgerverwaltung.PNG

Auch mit dem letzten Eintrag: "C:\$Windows.~BT\Sources\panther\setupact.log aus" kann ich nicht so richtig was anfangen.

Die setupact.log grad gefunden. Kein Zugriff ....

[DK2000]

Das ist auf jeden Fall MBR, aber sehr durcheinander alles. Und es fehlt der untere Teil der Ansicht.

Partition 2 und 3 scheinen nutzlos zu sein, Partition 4 ist Wiederherstellung.

C: ist in dem Falle die kombinierte System-/Startpartition, es fehlt also die separate Systempartition. Sollte aber nicht stören, theoretisch.

Und D ist Aktiv, was auch zu Problemen führen kann.

Packe mal die setupact.log mit 7zip oder so und hänge die mal hier an. Mich würde da interessieren, was da genau stört.

[Dabbelju]

Ok, vielen Dank. Hier sind die Daten

Datenträgerverwaltung2.PNG

setupact.log

UEFI.png

[DK2000]

Da ist aber mächtig etwas schief gelaufen bei der letzten Neuinstallation. DIe Installation läuft im UEFI Modus auf MBR Datenträger, was so nicht sein darf, weswegen es zu einem Hardblock kommt. Keine Ahnung, wie man so etwas hin bekommt:

Code: Alles auswählen

2020-05-28 10:44:42, Info                  CONX   CHostIsUEFICompliantChecker invoked.
2020-05-28 10:44:42, Info                  CONX   ConX::Compatibility::CSystemAbstraction::HostIsUEFIFirmware: Host is UEFI.
2020-05-28 10:44:42, Info                  CONX   ConX::Compatibility::CSystemAbstraction::HostIsUEFIDiskLayout: Detected system partition NT path: [\Device\HarddiskVolume1]
2020-05-28 10:44:42, Info                  CONX   ConX::Compatibility::CSystemAbstraction::HostIsUEFIDiskLayout: Constructed system volume NT path: [\\?\GLOBALROOT\Device\HarddiskVolume1]
2020-05-28 10:44:42, Info                  CONX   ConX::Compatibility::CSystemAbstraction::HostIsUEFIDiskLayout: Detected boot disk number: [0]
2020-05-28 10:44:42, Info                  CONX   ConX::Compatibility::CSystemAbstraction::HostIsUEFIDiskLayout: Boot disk does not have ESP partition.
2020-05-28 10:44:42, Info                  CONX   ConX::Compatibility::CSystemAbstraction::HostIsUEFIDiskLayout: Boot disk does not have MSR partition.
2020-05-28 10:44:42, Info                  CONX   ConX::Compatibility::CSystemAbstraction::HostIsUEFIDiskLayout: Boot disk does not have UEFI disk layout.
2020-05-28 10:44:42, Info                  CONX   CHostIsUEFICompliantChecker: checked HostIsUEFICompliant, found HardBlock.

Das zu reparieren, wird schwierig, da man einerseits den Datenträger vom MBR auf GPT konvertieren muss un danach die Partitionen Neu anordnen muss bzw, die jetzige C: Partition (System/Start) wieder zu System (ESP) und Start machen muss. Und natürlich die $MSR anlegen. Das Ganze sollte am Ende so aussehen:

Partition 1: 100MB (EFI Systempartition/ESP)/FAT32
Partition 2: 16MB ($MSR)/kein Dateisystem
Partition 3 :xxGB (Startpartition)/NTFS
Partition 4: 1GB (Wiederherstellung)/NTFS

Kennst Du Dich mit so etwas aus? Oder Kennst Du jemand, der sich damit auskennt? Einfach ist das nicht. Falls nicht, ist da eventuell eine Neuinstallation nach Löschen von Disk 0 der einfachere Weg. Desk 1 (Daten) bleibt unberührt.

Aber solange diese seltsame Sache da auf Disk 0 vorhanden ist, beliebt es beim Hardblock. Das lässt sich so nicht umgehen.

[Dabbelju]

Vielen Dank

Wie das passierte weiß ich tatsächlich nicht. Eigentlich bin eher kein Novize in Sachen PC. Hatte aber auch nicht explizit nachgeschaut, ob die Installation korrekt ist. Windows lief bisher nach jeden upgrade.

Könnte Laufwerk C löschen und ein MR img aufspielen. Würde dies das Probem lösen?

[Dabbelju]

Ich würde gern nochmal auf das Thema zurückkommen. Der Rechner ist neu installiert und dabei auf GPT umgestellt. Das 2004 ist aktiv.

Ein zweiter Rechner, der auch auf MBR steht, hat bisher noch kein update gesehen. Dennoch muss ich den wohl auch auf GPT umstellen. Daher meine Frage. Ist es möglich, die partition zu löschen, auf GPT umzustellen und dann ein Backup mit Macruim aufzuspielen? Oder stellt MR wieder auf MBR zurück.

[moinmoin]

Glaube kaum, dass das funktionieren wird. Da dürfte dann Macrium streiken.

Aber warum musst du auf UEFI umstellen? Per Inplace bekommst du es auch nicht hin?

[Dabbelju]

Inplace hab ich bisher noch nicht probiert. Der Rechner bootet in UEFI, ist eben auf MBR eingestellt. Und wie es scheint, sollte/muss das auf GPT stehen wenn auf 2004 geupdatet wird, so zumindest im Intelforum.

[Manny]

Theoretisch - bei einem Inplace - dürfte dir das nix bringen, da dann das Inplace trotzdem auf die MBR "aufgespielt" wird. Testmäßig - wenn du ein entsprechendes SystemImage ( GPT) hast -kannste es mal probieren, den Fall so hatte ich eigentlich aber selber noch nicht. Ansonsten bleibt wirklich nur das betreffende System / Datenträger auf GPT vorzubereiten und dann ein Clean Install machen