☰

RODEN

tag-icon • tag-icon boot grub2 grub kexec
RODEN

Ich habe eine Anwendung, bei der ich Linux booten, automatisierte Skripts ausführen und dann automatisch Windows booten muss. Kann ich Kexec verwenden, um Grub auszuführen?

Ein weiterer Anwendungsfall wäre das Booten eines Linux-Kernels, um den Mikrocode des Prozessors zu aktualisieren, und anschließend kexecdas Booten von Windows mit GRUB oder Syslinux – da der Mikrocode einen vollständigen Neustart nicht übersteht.

Ich habe gehört von grub4dos(Link (nicht verfügbar),archivierte Version), aber es scheint nicht mehr angeboten zu werden. Gibt es also eine Möglichkeit, es mit GRUB2 zu tun?

Ich bräuchte grundsätzlich ein ladbares Image von GRUB für kexec. Ich habe versucht, die gefundenen Images in diesem zu ladenErläuterung, aber sie scheinen nicht zu funktionieren. Danke für alle Hinweise.

Hinweis: Gefundendieser Beitragaus dem Jahr 2014, in dem es hieß, dass dies in kexec noch nicht implementiert sei.

Antwort1

Dies scheint unter Windows möglich zu sein kexec, ist aber bestenfalls experimentell (und nicht ausreichend getestet).

RODEN

Es ist nicht möglich, kexecGrub core.imgallein zu verwenden (da es kein kompatibles Binärformat zu haben scheint), siehe auchdieser Fehlerbericht auf LaunchpadDer genannte Fehler ist dennoch reproduzierbar:

kexec -l /boot/grub2/i386-pc/core.img

Laut kexec --helpwerden derzeit folgende Typen unterstützt:

elf-x86_64
multiboot-x86
multiboot2-x86
elf-x86
bzImage64
bzImage
beoboot-x86
nbi-x86

Wenn Sie einen anderen Loader laden möchten, muss dieser in einem dieser Formate vorliegen oder die Kompatibilität muss hinzugefügt werden. Ich bin nicht sicher, welches Format GRUB verwendet – ein einfacher fileBefehl erzeugt nur dies:

/boot/grub2/i386-pc/core.img: data

Erstellen eines bootfähigen GRUB-Image

Derzeit scheinen diese Möglichkeiten zu bestehen:

lnxboot

lnxboot.imgwäre ein Linux kernel x86 boot executeable bzImage. Es scheint als Kernel geladen werden zu sollen:

Sie können grub2.bin dann von syslinux/isolinux/pxelinux/lilo oder jedem anderen Bootloader laden, der den Linux-Kernel unterstützt.

Kexec lädt es, stürzt aber bei der Ausführung ab:

kexec -l /usr/lib/grub/i386-pc/lnxboot.img --initrd=/boot/grub2/i386-pc/core.img --debug

Außerdem scheint beim Laden ein Problem aufzutreten (erste Zeilen der Debug-Ausgabe):

Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /usr/lib/grub/i386-pc/lnxboot.img of 65536 bytes failed
[...]

Grub4Dos

Ein kurzer Blick auf Grub4Dos:

# file grub.exe
grub.exe: Linux kernel x86 boot executable bzImage, version \353kHdrS\003\002, RO-rootFS, Normal VGA

Dies sollte bedeuten, dass es kompatibel ist. Für mich war es keine Option, da es sich um eine veraltete Software handelt.

Ich habe es jedoch geschafft, grub4dosdurch Herunterladen 0.4.4vonQuelleschmiedeund dann ausführen:

kexec -l grub.exe
kexec -e

Unkonfiguriert greift es nach einiger Zeit auf die Grub-Shell zurück. Wenn Sie verwenden möchten gru4dos, müssen Sie nur die cmdlineIhren Anforderungen entsprechende Anpassungen vornehmen.Dieser Threadsollte weiterhin gelten.

Windows

Kexec'ing Windows scheint kein Einzeiler zu sein, aber eswurde schon einmal gemacht.

Die meisten Arbeiten in dieser Richtung scheinen verbunden zu sein mit derLinuxBootProjekt.Github

Ich fand dieseFolienso gut wie dasGitHub-Repository. Dies scheint das im Artikel erwähnte Projekt zu sein, das dafür gesorgt hat, dass es funktioniert.

Es scheint möglich zu sein, aber es ist viel Arbeit (und es ist keine „produktionsreife“ Lösung verfügbar – zumindest habe ich noch keine gefunden). Leider scheint es nicht viel Dokumentation für LinuxBoot zu geben, also müssen Sie vielleicht die Entwickler fragen. Vielleicht gibt es bereits eine einfachere Möglichkeit, dies zu tun.

Antwort2

Der Grund, warum Kexec in Windows so schwierig und kompliziert ist, liegt darin, dass der interne Designmechanismus von Kexec eine Unvollkommenheit aufweist: Er geht davon aus, dass alle OS-Bootloader das OS-Kernel-Image auf ähnliche Weise laden, was eindeutig nicht der Fall ist. Beispielsweise müssen einige OS-Kernel-Images ab einem bestimmten Speicheradressoffset geladen werden, einige Betriebssysteme erfordern möglicherweise das Laden zusätzlicher Dateien (die Treiberinformationen enthalten) neben dem OS-Kernel-Image usw. Da wir keine Kontrolle darüber haben, wie ein Betriebssystem sein Kernel-Image lädt oder sein Kernel-Image in einer zukünftigen Version laden wird, wird die aktuelle Art des Kexec-Einsatzes in ein anderes Betriebssystem/einen anderen Kernel auf lange Sicht nicht sehr gut funktionieren.

Der universellere/kompatiblere Weg (wie ich vorschlage) zum Kexec in ein anderes Betriebssystem istLaden Sie den Bootcode des Real-Mode-Bootsektors, beenden Sie den geschützten Modus und springen Sie dann direkt in den Einstiegspunkt des Real-Mode-Bootcodes. Dies ist die universellste Methode, da der Realmodus-Bootsektor-Bootcode eines Betriebssystems immer ab jeder Speicheradresse geladen werden kann. Auf diese Weise bootet das BIOS (verschiedene Computerhersteller erstellen unterschiedliche BIOS) in ein Betriebssystem (es sei denn, ein Betriebssystem möchte nicht, dass ein anderes BIOS es installiert oder bootet, z. B. Apple, das proprietäre Einschränkungen für das Laden von Bootsektor-Bootcodes auferlegen kann). Auf diese Weise können wir immer in jedes Betriebssystem booten, unabhängig davon, wie sein Bootcode sein Betriebssystem-Kernel-Image lädt, einfach weil wir seinen eigenen Bootsektor-Bootcode direkt ausführen. Darüber hinaus führt dieser Modus zu keiner Verlangsamung, da der Bootsektor-Bootcode klein und daher schnell zu laden ist und der Unterschied beim Laden einer großen Kernel-Image-Datei im Realmodus gegenüber dem geschützten Modus nicht sehr groß ist.

Dies zu erreichen ist jedoch eine große Herausforderung, da:

  1. Bei allen modernen Betriebssystemen wird der Realmodus-Speicher durch einige Deskriptortabellen oder Seitentabelleneinträge überschrieben, sobald sie vom Realmodus in den geschützten Modus wechseln. Es gibt also kein Backup. Realmodus-Bootcodes verwenden jedoch BIOS-Interrupts, um auf Hardware-E/A zuzugreifen. Ohne Wiederherstellung der ursprünglichen Realmodus-Speicherzuordnung können sie daher keine Kernel-Image-Datei von der Festplatte laden. Dieses Problem ist knifflig, aber lösbar. Wir können einen speziellen Linux-Bootloader installieren, der vor dem Wechsel in den geschützten Modus einen Speicher-Snapshot erstellt. Dies muss nur einmal für alle Mal auf einer Maschine durchgeführt werden.

  2. Nicht alle Prozessoren unterstützen die Rückkehr vom geschützten Modus in den Realmodus. Moderne Prozessoren sind aus Kosten- und Effizienzgründen für die Produktion so konzipiert, dass sie in ein Betriebssystem booten (vom Realmodus in den geschützten Modus wechseln) und nicht aus einem Betriebssystem ausbooten (vom geschützten Modus in den Realmodus zurückkehren). Daher ist das Verhalten bei der Rückkehr vom geschützten Modus in den Realmodus nicht gut getestet und daher weitgehend undefiniert. Da dieses Verhalten bei jedem Modell unterschiedlich ist, gibt es keine Kontrolle und somit keine Garantie dafür, bei welchen Marken/Modellen von Prozessoren es korrekt funktioniert.

  3. Nur Intel X86-Prozessoren verfügen über Realmodus und geschützten Modus (da sie eine sehr frühe Phase der Legacy-Technologie durchlaufen haben). Daher ist der Mechanismus des Neustarts vom Bootsektor für verschiedene Prozessorarchitekturen unterschiedlich und beinhaltet nicht unbedingt die Rückkehr vom geschützten Modus in den Realmodus, sondern kann einige andere Wechsel in den Betriebszuständen des Prozessors beinhalten.

Dennoch sollte es grundsätzlich funktionieren, wenn alles richtig gemacht wird. In Zukunft sollte Linux die Möglichkeit haben, per Kexec direkt von jeder Festplatte aus auf jede gemountete bootfähige Partition zuzugreifen (die aber nicht unbedingt als bootfähig markiert sein muss, da jede Festplatte nur eine Partition haben kann, die als bootfähig markiert ist, sonst meldet das BIOS einen Fehler und verweigert den Start), ohne einen vollständigen Hardwareneustart durchführen zu müssen, der viel langsamer ist. Dies bringt mehr Licht und Hoffnung in Linux ^_^

Antwort3

Sie müssen Grub installiert und das Linux-System als Standard-Boot installiert haben.

Erstellen Sie auf dem Linux-System einen Crontab-Eintrag wie diesen:

@reboot /do/some/stuff

Dabei ist /do/some/stuff ein Skript, das die von Ihnen gewünschten Aufgaben ausführt. Fügen Sie am Ende des Skripts Folgendes hinzu:

#!/bin/bash
#
# Do something here

sudo grub2-once "Windows"
sudo reboot

Anschließend sollte ein Neustart in Windows durchgeführt werden, vorausgesetzt, das Grub-Menüelement für Windows ist „Windows“.

Beim nächsten Neustart wird zu Linux zurückgekehrt und das Gleiche passiert.

Antwort4

kexeckönnte funktionieren, wenn Sie diese beiden Grub-Images kombinieren: lnxboot.imgund core.img, wie ...

cat lnxboot.img core.img > your-kexec-able.img

Es lohnt sich, das zu versuchen.

BEARBEITEN:

Nachdem ich mir die Bilder angesehen habe, lnxboot.imagesieht es eher wie eine „ELF“ aus als lnxboot.img, also probieren Sie das auch aus.

BEARBEITEN:

Offensichtlich gefallen mir die /boot/grub2/i386-pc/xxx.img-Images nicht kexec. Warum also nicht versuchen, grub-mkimageein paar andere Formate zu generieren und zu sehen, was funktioniert? Laut der Manpage -O, --format=FORMATwerden eine ganze Reihe anderer Formate unterstützt. Vielleicht versuchen Sie es mit diesem x86_64-xenFormat.

verwandte Informationen