grub-loader in / boot / efi / EFI können keine Windows-booten, /boot/efi/EFI/ubuntu/grubx64.efi kann, grub installiert das nicht
518
littlenoodles
Ich verwende Ubuntu 18.04 (kubuntu, aber wer zählt) auf einem Dual-Boot-System. Das Grub-Menü war immer in der Lage, Windows 7 zu booten, aber plötzlich funktioniert der Fenstereintrag in Grub nicht mehr. Wenn ich im Grub-Menü Fenster auswähle, wird der Bildschirm schwarz und es passiert nichts. Ich kann Windows weiterhin direkt vom Startmenü meines Systems aus starten, wenn ich schnell genug am Abzug bin, um das aufzurufen. Aber mit meinem Grub-Setup ist etwas passiert.
Ich habe versucht, 'sudo update-grub' auszuführen, was den Test erfolgreich wiederholen konnte, aber das Verhalten ist das gleiche.
Ich habe Secure Boot nicht aktiviert (sehe es nicht einmal als Option in meinem BIOS), und ich habe Windows 7 vollständig heruntergefahren (kein Ruhezustand oder Schlafmodus).
Mehr Info:
Ich habe auch den Bootmanager "refind" auf diesem Computer installiert. Wenn ich ihn in der Startreihenfolge umschalte, kann er Windows 7 oder grub booten. Das Refind-Menü zeigt jedoch mehrere Einträge für Ubuntu. Mit dem ersten wird EFI / Boot / fbx64.efi und mit dem zweiten EFI / Boot / bootx64.efi gestartet. Keiner von diesen kann Windows booten. Wenn ich einen von ihnen auswähle und ubuntu von dort aus starte, wird ubuntu wieder an die erste Position in der BIOS-Startreihenfolge des BIOS gesetzt - und ich bin wieder da, wo ich angefangen habe.
Aber wenn ich in Refind auf den Ubuntu-Eintrag für /ubuntu/Boot/grubx64.efi gehe, ist nicht nur das Booten von Ubuntu oder Windows 7 möglich, sondern auch, dass Refind oben in meiner Startreihenfolge oben steht. Dieses Problem scheint also darauf zurückzuführen zu sein, dass die neuen efi-Module in / EFI / Boot abgelegt wurden und zum Standard-Grub-Loader wurden. Ich weiß nicht, was fbx64 ist, aber soll es der primäre Bootloader von Grub sein? Wenn nicht, wie bekomme ich grubx64.efi als Standard? Geht es nur darum, das Modul grubx64.efi in / EFI / Boot zu kopieren? Ist das sicher - müsste ich es bootx64.efi umbenennen, damit es mit dem übereinstimmt, was da ist?
Hier ist was in meinem / boot / efi ist (das ganze Zeug von Ubuntu scheint vom 13. September um 09:39 datiert zu sein - vermutlich das letzte Mal, dass Ubuntu Grub aktualisiert hat). Bootx64 entspricht der Größe von Shimx64 - Ich brauche den Shim-Bootloader nicht. Könnte das Ubuntu-Update fälschlicherweise das dort kopiert haben ?:
Hier ist eine weitere Falte. Diese BOOTX64.CSV-Datei nennt shimx64.efi als 'Boot-Eintrag für ubuntu': ** shimx64.efi, ubuntu ,, Dies ist der Boot-Eintrag für ubuntu. ** Und ich habe überprüft, dass Boot / bootx64.efi die gleiche Datei ist Ubuntu / Shimx64. Auch hier habe ich keinen sicheren Start aktiviert und sollte den Shim-Bootloader nicht verwenden - aber ubuntu hat es trotzdem als Standard festgelegt. Bei der Erstinstallation war das nicht der Fall - nur bei dem Update vom 13. September.
littlenoodles vor 5 Jahren
0
Ich habe gerade ein weiteres Update für grub2 erhalten (11. Oktober 2018) und es wurde erneut shimx64.efi als Standard-Bootloader installiert. Ich habe dies vor dem Booten dieses Mal überprüft, sodass ich die Datei BOOTX64.CSV patchen konnte, bevor sie Probleme verursachte. Dies scheint jedoch ein Ubuntu-Fehler zu sein. Ich frage mich, warum es nicht mehr Menschen betrifft.
littlenoodles vor 5 Jahren
0
2 Antworten auf die Frage
0
littlenoodles
Die Antwort gefunden (oder zumindest eine Erklärung dafür, was passiert). BOOTX64.CSV wird vom EFI-Ladeprogramm "Fallback" verwendet, wenn der EFI VRAM-Eintrag beschädigt wurde. Und der Fallback-Loader weist den EFI-VRAM-Eintrag auf den Namen der CSV-Dateien als Standard-Loader - in meinem Fall shimx64.efi. Wenn ich also das EFI-System den falschen Eintrag für "Ubuntu" -Shim ausführen lasse, wird es an der Spitze der Liste neu installiert.
Ich weiß nicht, wie mein VRAM bei der Verwendung des Fallbacks beschädigt wurde, aber deshalb bleibt es bestehen, wenn ich versuche, das Problem zu beheben. Der Link unten beschreibt diesen Vorgang, falls Sie interessiert sind.
Ich habe mich schon früher mit Problemen beschäftigt. Was ich immer tun musste, war von Ubuntu Live USB zu booten, ein Paket namens Boot-Repair (oder so ähnlich, mein Speicher ist scheiße) zu installieren und damit die Liste der Dinge zu "erneuern", die GRUB im Wesentlichen sieht.
Weitere Informationen zum Boot-Repair-Paket finden Sie unter: https://help.ubuntu.com/community/Boot-Repair (Beachten Sie, dass Sie zum Installieren und Ausführen dieses Programms root sein müssen, da es sich um den Bootloader kümmert).
Stellen Sie sicher, dass Sie die obige Webseite vollständig lesen, da dies den Prozess wesentlich besser erklärt als ich. Bitte lassen Sie mich wissen, wenn dies hilft.
Ich weiß es nicht. Boot-Repair scheint das Booten von MBR zu beheben, und mein System verwendet EFI. Grub auf meinem System funktioniert - es ist nur so, dass ein paar EFI-Bootloader vorhanden sind, und der falsche wird standardmäßig ausgeführt, wenn ich 'Ubuntu' zuerst in der BIOS-Startreihenfolge meines BIOS stelle. Im Moment verwende ich nur refind, womit ich den funktionierenden grub64.efi-Loader wählen kann. Es ist nur ärgerlich, das tun zu müssen, wenn der 'Ubuntu'-Loader funktionierte. Ich hatte gehofft, jemand könnte mir sagen, ob es sicher ist, den "guten" Bootloader an den "Standard" -Ordner zu kopieren - und zu kommentieren, warum ein Grub-Update mein Boot-Setup überhaupt geändert hat.
littlenoodles vor 5 Jahren
0