EFI-Einstellungen, die über efibootmgr festgelegt wurden, werden nach dem Neustart ignoriert

Es wird ein Fehler angezeigt, der sicherlich nicht mit Secure Boot zusammenhängt. Ich habe mehrere Vorschläge, aber das Problem ist garantiert nicht behoben:

• Aktualisieren Sie Ihre Firmware - Wenn sich der Fehler in der Firmware befindet, kann das Problem durch eine Aktualisierung behoben werden. Erkundigen Sie sich beim Hersteller des Computers (oder des Motherboards) nach Updates. (Sie werden wahrscheinlich als "BIOS-Updates" bezeichnet, obwohl Ihre Firmware eigentlich kein BIOS ist.) Starten Sie nach dem Update einen Neustart in Linux und versuchen Sie es erneut.
• Setzen Sie Ihre Firmware auf die Standardeinstellungen zurück. Manchmal werden die EFI-Boot-Manager-Listen beschädigt, was zu den von Ihnen beschriebenen Symptomen führt. Das Zurücksetzen aller Firmware-Einstellungen auf ihre Standardwerte im Setup-Dienstprogramm kann dieses Problem beheben. Leider werden bei diesem Schritt alle aktiven Boot-Manager-Einträge entfernt. Sie müssen daher möglicherweise ein Notfall-Tool (z. B. meinen rEFInd-Boot-Manager auf einem USB-Laufwerk oder eine CD-R) verwenden, bis Sie Ihre funktionierenden Einträge neu erstellen.
• Nicht verwendete Boot-Manager-Einträge löschen - Das Löschen nicht verwendeter Boot-Manager-Einträge (mit der -BOption "to" efibootmgr) kann auch beschädigte Einträge umgehen. Versuchen Sie es efibootmgralleine oder efibootmgr -vfür eine ausführlichere Ausgabe, um doppelte oder unerwünschte Einträge zu finden. (Beachten Sie, dass die Firmware beim Neustart möglicherweise automatisch neu erstellt wird. Dies kann beispielsweise bei Netzwerkstartoptionen oder beim Starten externer Medien der Fall sein.)
• Verwenden Sie ein anderes Tool, um den Starteintrag zu erstellen. Manchmal efibootmgrfunktioniert dies nicht, aber ein Tool in einem anderen Betriebssystem (wie bcdeditoder EasyUEFI in Windows) oder das bcfgTool in einer EFI-Shell erledigt die Aufgabe. Daher können Sie diese Tools anstelle von verwenden efibootmgr.
• Fallback-Dateiname verwenden - Der Fallback-Dateiname ( EFI/BOOT/bootx64.efiauf x86-64-Systemen) kann verwendet werden, wenn nichts anderes funktioniert. Dieser Dateiname ist jedoch normalerweise der letzte, den ein Computer zu booten versucht. Wenn Sie bereits über einen anderen Namen (wie den Windows-Bootloader EFI/Microsoft/Boot/bootmgfw.efi) booten, müssen Sie möglicherweise eine Sicherungskopie erstellen, den gewünschten Bootmanager / -Loader in den Standard-Boot-Standard umbenennen und den neuen Bootloader neu konfigurieren booten Sie denjenigen, den er als seinen neuen Namen verwendet. Dies ist im besten Fall ein Jongliervorgang, und nicht alle EFI-Bootloader für Linux können mit einem anderen EFI-Programm verkettet werden, sodass sie möglicherweise nicht ordnungsgemäß funktionieren. (Ich kann mich nicht daran erinnern, wenn SYSLINUX ein anderes EFI-Programm verketten kann.)
• Wechseln Sie zu BIOS / CSM / Legacy-Booten - Die meisten EFIs bieten ein Compatibility Support Module (CSM), mit dem sie Boot-Loader im BIOS-Modus starten können. So können Sie einen Boot-Loader im BIOS-Modus für Linux installieren, CSM aktivieren und auf diese Weise booten. Wenn Sie ein anderes Betriebssystem Dual-Boot, obwohl, müssen Sie installieren seinen BIOS-Bootloader - Modus, auch, und dies erforderlich machen kann von GPT zu MBR - Partitionierung ändern. Insgesamt ist dieser Ansatz wahrscheinlich etwas schmerzhaft; Bei einigen EFIs (meistens alte aus dem Jahr 2011 oder darüber) ist dies möglicherweise der beste Ansatz.
• Senden Sie den Computer für eine Rückerstattung zurück - Wenn alles andere fehlschlägt und sich der Computer innerhalb seiner Rückgabefrist befindet, können Sie ihn für einen funktionierenden zurückgeben. Tatsächlich empfehle ich diesen Ansatz, wenn möglich, vor einer der beiden vorhergehenden Optionen. Wenden Sie sich in diesem Fall an den Hersteller, um ihm mitzuteilen, warum Sie den Computer zurückgegeben haben. EFIs hatten seit dem ersten Tag gravierende Fehler, und einige Hersteller haben sie nur langsam behoben, zum Teil, weil ihre Kunden sich nie beschweren, so dass die Hersteller nicht erkennen, wie ernst die Fehler sind.

AKTUALISIEREN:

Hi, ich wieder,

Es begann wieder, daran zu arbeiten, nun wurde die .efi-Datei in das Windows-Äquivalent (bootmgfw.efi) umbenannt, das Efivar-Dateisystem wurde wie in der obigen Beschreibung erneut gemountet und der Uefi-Boot-Eintrag im VRAM durch Eingabe eingegeben

efibootmgr -c -d / dev / sda -p 4 -L "linuxmint_grub" -l "\ EFI \ linuxmint_grub \ bootmgfw.efi"

mit dem ESP auf / dev / sda, Partition 4.

Kein Booten funktioniert einwandfrei, der Efibootmgr-Eintrag bleibt hartnäckig, nur ein Nachteil: GRUB startet automatisch beim Booten, obwohl er ausgeschaltet ist. Scheint ein GRUB-Problem zu sein, das wird später behoben.

Prost und hoffe ich konnte helfen;)

Ich habe das gleiche Problem und versuche, einen Efi-Boot-Eintrag unter Intel NUC7I5BBNK und LinuxMint 18.3 mit auf / boot angehängtem ESP zu erstellen. Efibootmgr erstellt den Eintrag erfolgreich und dauerhaft, jedoch ist der Zugriff nicht möglich. Er wird nicht im visuellen EFI-Startmenü angezeigt. Der automatisch angezeigte Starteintrag im Intel BIOS zeigt nur, dass keine gültige Startpartition erkannt wurde. Ich fand auch die Bootreihenfolge, egal wie oft ich sie korrigiere, ist nicht beständig, ich werde versuchen, mit ihnen weiterzumachen

mount -o remount, rw -t efivarfs efivarfs / sys / firmware / efi / efivars

obwohl es bereits "rw" ist, wie von gezeigt

montieren | Grep Efivars

und versuche es noch mal. (Weitere Hinweise finden Sie unter https://wiki.gentoo.org/wiki/Efibootmgr ).

Es war nicht möglich, EFI-Variablen direkt aus dem UEFI-Visual-Bios-Menü auszuwählen. Ich kann sie vom erstellten Datei-Explorer aus sehen, aber nicht auswählen.

Eine weitere Option wäre die Installation von .efi-Variables im Secure Boot-Modus, der nicht mein Favorit ist. Vielleicht passt das besser zu meiner UEFI-Implementierung. Alle Installationen müssen benutzerdefiniert angepasst werden!

Zweitens versucht, EFI-Eintrag mit efibootmgr auf ASUS V3-371-KT51-Laptop zu installieren, funktionierte überhaupt nicht -> zeigt wirklich, wie es von der Maschine und der UEFI-Implementierung abhängt. Arbeitete (irgendwie) mit der manuellen Auswahl der .efi-Datei aus dem UEFI-Menü, jedoch nur im Secure Boot-Modus.

Die von einem anderen Beitrag vorgeschlagene bcfg-Methode ist nur für den direkten Start gedacht, was bedeutet, dass der Bootmanager vernachlässigt wird (EFISTUB, soweit ich weiß, nehmen Sie das nicht für selbstverständlich, überprüfen Sie dies bitte selbst: https: // wiki.archlinux.org/index.php/EFISTUB )

BTW: 3 offensichtliche Fehler: (1) -d steht für "disk", anders als "partition", was bedeutet, dass Sie es in "/ dev / sdb" ändern sollten, wenn Ihr ESP auf / dev / sdb (2) läuft. -p steht für die Partitionsnummer, in Ihrem Fall "3" (oder "2", abhängig davon, wie efibootmgr bzw. die UEFI-Implementierung zählt)

Also versuchen Sie das zu ändern.

(3) Zu guter Letzt konnte ich ein UEFI-Flashlaufwerk mit allen Kernel-, Initrd-Dateien und allen nicht zu bootenden Dateien booten, anders als in Ihrem vorgeschlagenen Verzeichnis / boot / EFI / syslinux. Dies ist der übliche Weg.

Hoffe das war hilfreich, viel Glück für dich und pass auf;)