Zu meinen Aufgaben gehört es, die Computer, die in unseren Produkten mit Windows-Betriebssystemabbildern (Embedded und OEM) ausgeliefert werden, mit einer Wiederherstellungspartition zu konfigurieren. Ich habe Clonezilla Live mit GRUB2 verwendet, um diesen Prozess zu implementieren. Dies funktionierte unter Windows XP/Embedded Standard 2009 einwandfrei. Unter Windows 7 und aufgrund der Änderungen am Boot-Manager würde ich davon ausgehen, dass dies bei allen neueren Betriebssystemen als Vista nicht funktioniert. Das aktuelle Systemabbild, das ich zu konfigurieren versuche, sieht wie folgt aus:
/dev/sda1, ntfs, PRIMARY, 62,5 GiB, 3,15 GiB, 59,35 GiB, keine Flags
/dev/sda2, ntfs, RESTORE, 4,00 GiB, 1,74 GiB, 2,26 GiB, versteckt
/dev/sda3, fat32, CLONEZILLA, 4,00 GiB, 115,22 MiB, 3,89 GiB, versteckt
/dev/sda4, ext4, BOOT, 1,00 GiB, 53,91 MiB, 970,09 MiB, Boot
/dev/sda1 enthält Windows 7 OEM (versiegelt), dev/sda2 enthält ein auf Clonezilla basierendes Wiederherstellungsimage (versiegelt)
/dev/sda MBR ist GRUB2-Bootloader
Ich kann GRUB2 problemlos laden und das Windows 7-Image wiederherstellen. Windows 7 kann ich jedoch nicht booten und erhalte den Fehler 0xc0000225. Update: Nachdem ich den Bootsektor wie unten beschrieben geändert hatte, um den Startabschnitt von sda1 mit dem MBR in Einklang zu bringen, verschwand der Fehler 0xc0000225 und ich erhielt den Fehler 0xc000000e, wobei die Datei winload.exe dem Benutzer gemeldet wurde. Diese Datei ist jedoch vorhanden und intakt, soweit ich dies über andere Dienstprogramme feststellen kann.
Informationen aus Meierfrankenfelds und Hulselmans Bootinfoscript zeigen Probleme mit sda1 (Bootsektor zeigt sda1 bei Sektor 411648 gegenüber fdisk, das 2048 anzeigt) und sda3 (Bootsektor zeigt sda3 bei Sektor 0 und fdisk, das 164628480 anzeigt). Ich bin mir nicht sicher, was ich an dieser Stelle ändern muss oder welches Tool dafür das beste ist. Ein Hex-Editor reicht mir, wenn ich eine gute Beschreibung des Aufbaus von BCD und Grub2 MBR hätte. Update: Ich habe den Bootsektor endlich aktualisiert, um eine Übereinstimmung mit fdisk für sda1 zu erreichen.
Bevor ich die Maschine versiegelte und /dev/sda3 und /dev/sda4 hinzufügte, führte ich die Windows 7-Bootpartition mit /dev/sda1 zusammen. Sie startete neu und funktionierte einwandfrei.
Ich habe versucht, die von Microsoft bereitgestellten BCD-Materialien durchzulesen und sichergestellt, dass die Windows-Boot-Manager- und Loader-Objekte auf die richtige Partition verweisen (sie hatten eine custom=xyz-Syntax verwendet, die auch nicht funktionierte).
Diese Wiederherstellung hat in der Vergangenheit gut funktioniert, da ich den Wiederherstellungsprozess vollständig automatisieren konnte, was für unseren Endbenutzer von entscheidender Bedeutung ist. Eine Wiederherstellungsdiskette ist hier keine Option.
Ich habe bestätigt, dass BCD Partition=C: verwendet, um auf das Gerät/Betriebssystemgerät/Bootmgr-Gerät zu verweisen.
Ich konnte also bestätigen, dass der MBR vorhanden und intakt ist, dass der VRB auf sda1 vorhanden und intakt ist und dass die Dateien $MFT und $MFTMirr an der im VBR angegebenen Position vorhanden sind, wie vom Tool istat (nicht lstat) in Sleuthkit bestätigt. Die im obigen Fehler referenzierte Winload-Datei ist an der Position vorhanden, die mir vom Dienstprogramm fls sleuthkit angegeben wurde, und stimmt mit der Dateigröße anderer Installationen überein.
Alternativ: Wenn Sie ein OEM sind und einen Wiederherstellungsprozess teilen möchten, der in einer Verbraucher-/Embedded-Umgebung gut funktioniert, würde ich mich auch über Ihr Feedback freuen. Vielen Dank.
Antwort1
Klingt, als ob es Probleme beim Hinzufügen dieser Partitionen in der Mitte gab. Welchen Partitionseditor haben Sie verwendet? Das Testdisk-Programm, das auf der LiveCD von PartedMagic.com und Hiren zu finden ist, hat für mich einige Partitionsprobleme und Dual-Boot-Probleme auf einigen Maschinen behoben. Ich würde die Annahme, dass „bcd verwendet Partition=C:“ das bedeutet, was Sie denken, noch einmal überprüfen, da es viel mehr von der GUID abhängt.