☰

Kernel direkt von UEFI booten

tag-icon • tag-icon arch-linux kernel boot uefi
Kernel direkt von UEFI booten

Ich möchte Arch Linux direkt von UEFI booten.

Meine Idee ist, mit dem Tool einen Boot-Eintrag zu erstellen efibootmgr. Ich habe diesen Befehl verwendet:

efibootmgr --create --label "arch-test" --loader /vmlinuz-linux --unicode 'root=PARTUUID=f2083749-8bbc-570b-ab3b-e79d72fa08ac rw initrd=\initramfs-linux.img' --verbose

ich folgtedie Arch Wiki-Seite auf EFISTUBund ich habe den Eintrag erstellt, aber beim Versuch, davon zu booten, bleibt das System in einem sehr frühen Boot-Stadium mit dieser Meldung hängen:

VFS: unable to mount root fs on unknown-block(0,0)

PS: Ich möchte, dass dies als Notfall-/Rettungstool funktioniert. Das letzte systemdUpgrade hat den Bootmanager (systemd-boot) zerstört und meine Maschine unbrauchbar gemacht. Ich konnte mein System dank eines externen Live-USB wiederherstellen. Ich möchte dies in Zukunft VERMEIDEN!

Aktualisierung:
1. mit oder ohne/Schrägstrich oder Backslash, davor initrdist egal
2. mit sowohl UUIDals auch versucht PARTUUID, nichts ändert sich
3. mein /bootist an, /dev/sda1währendWurzelzu /dev/sda3
4. und /bootist ESP, sowie

    # fdisk -l /dev/sda
    [...]
    Disklabel type: gpt
    [...]

    Device         Start       End   Sectors   Size Type
    /dev/sda1       2048   2099199   2097152     1G EFI System
    /dev/sda2    2099200  18874367  16775168     8G Linux swap
    /dev/sda3   18874368 104857599  85983232    41G Linux filesystem
    [...]
    # minfo -i /dev/sda1 :: | grep 'disk type'
    disk type="FAT32   "

  1. nach Ihren Kommentaren habe ich versucht,UEFI-Shell. Ich habe diese Option auf dem neuesten Stand belassen, da mein Rechner keine interne UEFI-Shell hat (Ist es möglich?). Wie auch immer, ich habe:

    • heruntergeladen vonAbonnieren
    • platziert Shell.efiin/boot/EFI/Boot/

    • hat einen Eintrag hinzugefügt mit

      efibootmgr --create --label "TIANO-0" --loader /EFI/Boot/Shell.efi --verbose

    • neu gestartet in diese Shell, ich tippte fs0:undvmlinuz-linux root=/dev/sda3

    • was zum selben Fehler führt:

      VFS: unable to mount root fs on unknown-block(0,0)

  2. es sieht so aus, als ob initrdes obligatorisch ist (zumindest für Arch Linux);
    der Befehl vmlinuz-linux initrd=initramfs-linux.img root=/dev/sda3macht die Magie

  3. mein System ist ein Dell XPS 9343 Laptop und ich habe festgestellt, dass es an einem Fehler leidet: EFISTUB kann nicht gebootet werden, gemeldet auf ArchWikiHier.
    Ich denke, das erklärt dieVersagender (erstgenannten) richtigen Vorgehensweise!
    Die ArchWiki-Seite schlägt auch einen Workaround vor, aber im Moment habe ich es selbst ausprobiert.

Antwort1

   -l | --loader NAME
              Specify a loader (defaults to \\elilo.efi)

Ein Kernel mit EFI-Stub ist noch immer keinLader. Um vom BIOS zu booten, muss es ein EFI-Anwendung. Alle Bootloader haben die Endung .EFI. Ich denke, es ist möglich, einen Kernel in ein solches direkt bootfähiges Objekt umzuwandeln, aber normalerweise wird einer der Bootloader gestartet (mit oder ohne Auswahlmöglichkeit).

Aber Sie könnenUEFI-Shell(auf modernen Systemen) als interaktiver Bootloader. Das ist perfekt zum Testen. Sie aktivieren es wie ein Boot-Gerät im BIOS, cdauf fs0:, das ist das ESP, und dann können Sie

fs0:> bzImage root=/dev/sda3

Ich habe vor ein paar Tagen gerade ein erstes bzImage kompiliert. Zuerst vergaß ich CONFIG_EFI_STUB und die UEFI-Shell behandelte den Kernel wie eine Nicht-Binärdatei. Eine zweite Version bootete, ohne initrd=. Außer EFI_STUB=y habe ich einfach ein paar Optionen ausgeschaltet und die Standardeinstellungen beibehalten.

Aber es stimmt, dass die meisten Distributionen Kernel haben, dienichthaben die grundlegenden Blockgerätetreiber – sie benötigen die initrd=IMAGEOption.

Als Bootloader verwende ich die Uefi Shell. Das ist zwar nicht super elegant, aber sehr simpel und flexibel. Und als Notfalllösung halte ich das für perfekt, da die Uefi Shell fest eingebaut ist, während ein Bootloader auf einer Partition gelöscht werden kann.

Das ist vonDokumentation/efi-stub.txt

> Passing kernel parameters from the EFI shell
> --------------------------------------------
> 
> Arguments to the kernel can be passed after bzImage.efi, e.g.::
> 
>     fs0:> bzImage.efi console=ttyS0 root=/dev/sda4

Ich habe dieselbe Uefi Shell-Eingabeaufforderung fs0:>, habe aber festgestellt, dass alle üblichen Distributionen EFI_STUB-Kernel haben und der Name überhaupt keine Rolle spielt. Am gebräuchlichsten ist „vmlinuz“ (= Loader für ein komprimiertes vmlinux).

Wenn Sie die Optionen ".efi" und "console=" weglassen, bleibt Folgendes übrig:

fs0:> bzImage root=/dev/sda4

Das ist derselbe minimale Boot-Befehl, außer dass ich Folgendes habe sda3: Uefi Shell startet das bzImage über stub, der Kernel wird entpackt und gestartet und die integrierten Module erkennen die SATA-Festplatte. Wenn das root=Gerät nicht gültig ist, kommt es zu dieser VFS: unable to mountPanik.

Ich konnte ein bzImage (oder vmlinuz oder ...) nicht direkt vom BIOS aus starten, wie ein grub64.EFI.

UEFI - Anwendungen (Wikipedia):

Neben dem Laden eines Betriebssystems kann UEFI auch UEFI-Anwendungen ausführen, die als Dateien auf der EFI-Systempartition liegen. Sie können über die UEFI-Befehlsshell ausgeführt werden.durch den Bootmanager der Firmwareoder durch andere UEFI-Anwendungen. UEFI-Anwendungen können unabhängig vom Systemhersteller entwickelt und installiert werden.

Ein Typ einer UEFI-Anwendung ist ein Betriebssystemlader wie GRUB, rEFInd, Gummiboot und Windows Boot Manager, der eine Betriebssystemdatei in den Speicher lädt und ausführt. Ein Betriebssystemlader kann auch eine Benutzeroberfläche bereitstellen, über die eine andere auszuführende UEFI-Anwendung ausgewählt werden kann. Dienstprogramme wie die UEFI-Shell sind ebenfalls UEFI-Anwendungen.

Dies bestätigt meine Ansicht, dass sich die UEFI-Shell zwischen dem Firmware-Bootloader und dem Kernel befindet.

Gentoo hat ähnliche Beispiele; sie bestehen darauf, den Kernel mit der Endung .EFI zu benennen.

Wenn aus irgendeinem Grund ein Initramfs benötigt wird, kann es entweder in den Kernel eingebettet oder als separate Datei verwendet werden.

...

Einige UEFI-Implementierungen jedochscheint die Übergabe von Parametern nicht zu unterstützenvom NVRAM zum EFI-Stub-Kernel.

Antwort2

Es scheint, dass einige ältere Maschinen mit älterer UEFI-Firmware keine Befehlszeilenargumente an EFI-Binärdateien übergeben (wie etwa ein EFISTUB-fähiger Linux-Kernel). Dies macht es unmöglich, wichtige Parameter wie root=und initrd=beim Booten an den Kernel zu übergeben.

Ich habe genau das gleiche Verfahren verwendet, um den Kernel direkt von UEFI zu booten (genauer gesagt das unterhttps://wiki.debian.org/EFIStub, aber ich habe es tatsächlich auf Ubuntu gemacht) auf zwei verschiedenen Maschinen. Auf meinem drei Jahre alten ASrock-Motherboard funktionierte es einwandfrei. Auf meinem elf Jahre alten Dell-Laptop ignoriert es einfach die Kernel-Befehlszeilenargumente.

Wenn Ihre Firmware also keine Befehlszeilenargumente unterstützt, haben Sie möglicherweise Pech gehabt. Ich werde es weiter versuchen und einen Folgebeitrag posten, wenn ich eine Problemumgehung finde.

verwandte Informationen