LINBO: Win10 von KVM nach KVM: Fehler 0xc000000e

Michael · 23. Dezember 2020 um 19:46

Hi.
Ich habe ein Win10-Image unter Proxmox/KVM, das als Master-Image dienen soll. Das konnte ich bisher häufig erfolgreich auf „echte“ Hardware klonen. Im Gerätemanager sind natürlich alle Treiber da…

Heute dann dies:
Eine neue VM unter Proxmox angelegt und ein ganz neu hochgeladenes LINBO-Image auf die neue VM geklont. Und siehe da: Win10 bootet nicht mehr. Stattdessen erscheint der Code 0xc000000e „Der PC/das Gerät muss repariert werden“ (winload.exe).

Ich finde es seltsam, dass das erscheint, wenn ich auf identische (virtuelle) Hardware klone??? Das dürfte doch keinen Unterschied machen!?? Der gleiche Fehler trat neulich schon mal auf, als ich auf ein Lenovo X220 Tablet klonen wollte – da hatte ich es noch auf fehlende Treiber im Vergleich zur virtuellen Hardware geschoben. Aber so wie es jetzt aussieht, steckt doch etwas anderes dahinter?

Wer hat eine gute Idee?
VG,
Michael

dorian · 23. Dezember 2020 um 20:10

Hi Michael,

Ich hatte das Problem auch schon oft, Windows halt… Das ist sehr frustrierend und scheint machmal einfach so aus dem blauem Himmel zu kommen, was da genau bei Windows falsch läuft weiß ich leider nicht.

Bei mir hat aber immer geholfen, von einer Windows installer CD zu booten und dann über die Reparatur Optionen folgende Befehle auszuführen:

bootrec /rebuildbcd
bootrec /fixmbr
bootrec /fixboot

(Hoffe ich hab mich nich vertippt)

Danach neues Image erstellen, dann ging es auf der selben Hardware meistens.
Bei unterschiedlicher Hardware kommt man aber leider meist nich um unterschiedliche Images herum , da hilft nur eins: Linux.

Viele Grüße
Dorian

Michael · 23. Dezember 2020 um 20:12

Hallo Dorian.
Ja. Dieser Lösungsweg ist mir bekannt – aber dann ist natürlich leider LINBO/GRUB wieder weg, was natürlich in diesem Fall kontraproduktiv ist.
Dass das jetzt aber auf absolut identischer Hardware auftritt, ist doch nicht nachvollziehbar, oder?

Viele Grüße,
Michael

dorian · 23. Dezember 2020 um 20:15

Hallo Michael,

Nachvollziehbar ist das nicht, nein, aber ich hatte es auch genau so schon

VG
Dorian

Michael · 24. Dezember 2020 um 09:58

Hallo.
Jetzt wird es noch seltsamer:
Ich habe die Win10.ISO gestartet, um auf eine Rettungskonsole zu gelangen.
Als ich die Befehle von oben eingeben wollte, erschien allerdings dies:

Laufwerk C: ist also überhaupt nicht (mehr) da bzw wurde nicht neu angelegt. Ich hatte den Client ganz neu gemacht und auch neu partitioniert & formatiert. (Hintergrund war eigentlich, dass ich prüfen wollte, ob damit auch das GRUB-Menu + Icons richtig dargestellt werden.)

Nun stellt sich heraus, dass die Formatierung von Laufwerk C: offenbar daneben gegangen ist?! Dann ist ja auch kein Wunder, dass sich das Image nicht übertragen lässt.

Kann es sein, dass dieser Effekt auch mit der im Nachbarthread diskutierten Label-Problematik zusammenhängt??

Die start.conf.win10grub sieht meiner Meinung nach richtig aus:

# LINBO start.conf Beispiel mit
# Windows 10 auf Partition 1 (NTFS)
# Cache auf Partition 2
# Daten auf Partition 3
# Festplatte 160G

[LINBO]                  # globale Konfiguration
Server = 10.16.1.1       # IP des Linbo-Servers, der das Linbo-Repository vorhaelt
Group = win10grub
# Achtung: Server und Group werden beim Workstationsimport automatisch gesetzt!
Cache = /dev/sda2        # lokale Cache Partition
RootTimeout = 60         # automatischer Rootlogout nach 600 Sek.
AutoPartition = no       # automatische Partitionsreparatur beim LINBO-Start
AutoFormat = no          # kein automatisches Formatieren aller Partitionen beim LINBO-Start
AutoInitCache = no       # kein automatisches Befuellen des Caches beim LINBO-Start
DownloadType = rsync     # Image-Download per torrent|multicast|rsync, default ist rsync
BackgroundFontColor = white         # Bildschirmschriftfarbe (default: white)
ConsoleFontColorStdout = lightgreen # Konsolenschriftfarbe (default: white)
ConsoleFontColorStderr = orange     # Konsolenschriftfarbe fuer Fehler-/Warnmeldungen (default: red)
SystemType = bios                   # moeglich ist bios|bios64|efi32|efi64 (Standard: bios fuer bios 32bit)
KernelOptions = dhcpretry=10        # Beispiele:
#KernelOptions = acpi=noirq irqpoll # LINBO Kerneloptionen (z. B. acpi=off), m. Leerz. getrennt
#KernelOptions = server=10.16.1.5   # Abweichende Linbo-Server-IP als Kerneloption gesetzt
                                    # falls gesetzt wird diese IP beim Workstationsimport verwendet

[Partition]              # Start einer Partitionsdefinition fuer ein Betriebssystem (Windows)
Dev = /dev/sda1          # Device-Name der Partition (sda1 = erste Partition auf erster Platte)
Label = windows          # Partitionslabel
Size = 70G               # Partitionsgroesse 30G, ist keine Einheit (M, G oder T) angegeben, wird kiB angenommen
Id = 7                   # Partitionstyp (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, ...)
FSType = ntfs            # Dateisystem ext4
Bootable = yes           # Bootable-Flag

[Partition]              # Start einer Partitionsdefinition, Cachepartition
Dev = /dev/sda2          # Device-Name der Partition (sda2 = zweite Partition auf erster Platte)
Label = cache            # Partitionslabel
Size = 30G               # Partitionsgroesse 30G
Id = 83                  # Partitionstyp (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, ...)
FSType = ext4            # Dateisystem ext4
Bootable = yes           # Bootable-Flag

[Partition]              # Definition der Swap-Partition
Dev = /dev/sda3          # Device-Name der Partition (sda3 = dritte Partition auf erster Platte)
Label = daten            # Partitionslabel
Size =                   # Partitionsgroesse (Rest der Platte)
Id = 7                   # Partitionstyp (83 = Linux, 82 = swap, c = FAT32, ...)
FSType = ntfs            # Dateisystem swap
Bootable = no            # Bootable-Flag

[OS]                       # Beginn einer Betriebssystemdefinition
Name = Windows 10          # Name des Betriebssystems
Version =                  # Version (unbenutzt, leer lassen)
Description = Windows 10   # Beschreibung
IconName = win10.png       # Icon fuer den Startbutton, muss unter /var/linbo/icons abgelegt sein
Image =                    # differentielles Image (Erweiterung .rsync, Verwendung nicht empfohlen)
BaseImage = win10.cloop    # Dateiname des Basisimages (Erweiterung .cloop)
Boot = /dev/sda1           # Bootpartition (unbenutzt, immer gleich Rootpartition)
Root = /dev/sda1           # Rootpartition, in die das BS installiert ist
Kernel = auto              # Windows: auto (LINBO & Grub erkennen die Startparameter automatisch)
Initrd =                   # Windows: leer
Append =                   # Windows: leer
StartEnabled = yes         # "Start"-Button anzeigen
SyncEnabled = no           # "Sync+Start"-Button anzeigen
NewEnabled = yes           # "Neu+Start"-Button anzeigen
Autostart = yes            # automatischer Start des Betriebssystems (yes|no)
AutostartTimeout = 3       # Timeout in Sekunden fuer Benutzerabbruch bei Autostart
DefaultAction = start      # Standardaktion bei Autostart: start|sync|new
Hidden = yes               # verstecke OS-Reiter (unbenutzte Option, auf "yes" lassen)

Seltsam, oder?
Viele Grüße,
Michael

dorian · 24. Dezember 2020 um 10:16

Hi Michael,
Ja, seltsam, hatte ich aber auch schon glaub ich.
Sieht die start.cobf genauso aus, wenn du auf dem client ein cat /start.conf ausführst?

Hast du mal probiert mit parted alle Partitionen zu löschen, dann Neustart und alles neu machen?

VG
Dorian

Michael · 24. Dezember 2020 um 10:29

Gerade gemacht – alle Partitonen runtergeworden und von gparted EINE einzige anlegen lassen. Danach nochmal „Partionieren —> Neu & Start“. Gleicher Effekt.
Ich könnte die Label auch mal ganz rausnehmen, wenn’s daran liegen sollte?!?

Noch eine winzige Feststellung: sowohl sda1 als auch sda2 haben das „Bootable“-Flag auf „yes“ gesetzt. Kann das ein Problem sein?

dorian · 24. Dezember 2020 um 10:33

Also ich lösche immer gleich alle. (sodass die Platte leer ist)

Also ich habe bei mir nur die Win-Partition auf bootbar gestellt, botte aber Linbo auch IMMER vom Netzwerk.

baumhof · 24. Dezember 2020 um 10:47

Hallo,

Hast du mal probiert mit parted alle Partitionen zu löschen, dann
Neustart und alles neu machen?
Gerade gemacht – alle Partitonen runtergeworden und von gparted EINE
einzige anlegen lassen. Danach nochmal „Partionieren —> Neu & Start“.
Gleicher Effekt.
Ich könnte die Label auch mal ganz rausnehmen, wenn’s daran liegen sollte?!?

ich glaube nciht daran, dass alle Probleme auf das label Problem
zurückgeführt werden können.
Dein Problem sieht nicht danach aus.

Noch eine winzige Feststellung: sowohl sda1 als auch sda2 haben das
„Bootable“-Flag auf „yes“ gesetzt. Kann das ein Problem sein?

das glaube ich nicht.

Versuch doch mal bitte folgendes:

client booten und nach Partitionieren neu+start bemühen.
wenn es dann icht geht:
client neustarten udn nochmal neu+start

LG

Holger

Michael · 24. Dezember 2020 um 11:14

Ich hatte extra EINE neue Partition erstellt und ein anderes Label genommen. Nach Neustart und erneutem „Partionieren“ ist aber alles richtig: Größe, Label, Cache – alles passt.
Zusätzlich habe unter LINBO -> Konsole die Partition /dev/sda1 gemounted um zu schauen, ob das Dateisystem richtig angelegt wurde. Das passt alles.

Michael · 24. Dezember 2020 um 11:19

Hab ich jetzt drei mal gemacht … LINBO legt die NTFS-Partition auf jeden Fall richtig an. Ich habe eine Datei unter LINBO auf sda1 angelegt – kein Problem. Dann kann ja nur etwas am Image nicht stimmen!? Aber dass C: nach einem „Neu & Start“ völlig verschwunden ist, hatte ich vorher so auch noch nicht !?!

Michael · 24. Dezember 2020 um 12:18

Vielleicht noch so?

„Da Sie offensichtlich Windows installiert haben, müssen Sie es mithilfe der folgenden Befehle entfernen und erneut aus der Liste erstellen:“


bcdedit /export c:\bcdbackup

attrib c:\\boot\\bcd -r –s -h

ren c:\\boot\\bcd bcd.old

bootrec /rebuildbcd

… wobei: ich kann ja auf Laufwerk C: gar nicht (mehr) zugreifen … dann kann der Befehl ja auch nicht funktionieren.

Michael · 25. Dezember 2020 um 11:29

Ich verstehe nicht, was da falsch läuft…
Meine Vorgehensweise war so wie immer:

Eine funkionierende Win10-VM gestartet – sie bootet ganz normal über LINBO.
Neustart --> LINBO: Image erstellt
Andere VM erzeugt --> LINBO: Partitionieren, (optional: Neustart), Neu + Start
Windows startet nicht ( Fehlercode 0xc000000e) und Laufwerk C: wird auch nicht mehr gefunden!
KALI-Live-CD (ISO) gebootet und geschaut, ob das Dateisystem richtig angelegt wurde:

Und siehe da: Es ist alles da! Windows selbst kann aber mit Hilfe der Rettungs-CD kein Laufwerk C: finden! WTF?

Hat einer eine gute Idee?
Weihnachtliche Grüße,
Michael

Michael · 25. Dezember 2020 um 16:43

Die Ursache ist gefunden … die virtuelle Hardware auf dem Proxmox-Host war’s ! Da war als Festplattencontroller „VirtIO SCSI“ eingetragen – also genau so wie es empfohlen wird! Dieser Treiber ist aber beim Start des ISOs nicht per default dabei, so dass auch Laufwerk C: nicht angezeigt werden kann!
Wenn man die virt Hardware unter Proxmox auf den default-LSI-Treiber und ide0 umstellt, geht es mit der Windows-10-ISO weiter — aber das kann jetzt noch etwas warten …

Übrigens: Etwas merkwürdig bleibt das Problem trotzdem, denn „Laufwerk“/Partition D: wurde oben ja direkt gefunden … liegt aber auf der gleichen virt. Hardware wie C: …