Mainboardwechsel: Manjaro nicht mehr im UEFI auswählbar

[H1ldegunst]

Hallo zusammen,

ich habe kürzlich mein Asus X370 C6H durch ein MSI B550 Gaming Edge Wifi ersetzt.
System ist ein Dualboot mit Manjaro und Windows 10. Manjaro ist dabei mit LUKS verschlüsselt und liegt zusammen mit der Bootpartition auf einer SSD, /home und Win 10 liegen jeweils auf eigenen SSD. (Screenshot siehe Anhang)

Leider kann ich nun im Uefi als Bootpriorität nur Ubuntu (Überbleibsel einer alten Installation) und Win10 auswählen. Manjaro lässt sich nur über den Umweg über einen Manjaro-Live-USB und die manuelle Auswahl des Bootloaders starten. Dann kann ich wie gewohnt über GRUB Manjaro mit verschiedenen Kernelversionen und Windows auswählen.

Wie kriege ich Manjaro jetzt wieder ins Uefi? Liegt das an der Verschlüsselung? Muss ich da noch etwas im UEFI einstellen?

efibootmgr gibt folgendes aus:

Spoiler

BootCurrent: 0007
Timeout: 1 seconds
BootOrder: 0000,0005,0007,0008,0003,0006
Boot0000* Windows Boot Manager
Boot0003 Hard Drive
Boot0005* ubuntu
Boot0006 USB KEY
Boot0007* UEFI: ADATA USB Flash Drive 1100
Boot0008* UEFI: ADATA USB Flash Drive 1100, Partition 2

Fast Boot gibts im UEFI nicht, Secure Boot ist deaktiviert.

Bevor ich (mal wieder) was zerschieße, dachte ich, ich frage hier um Hilfe, bevor ich Manjaro neu installiere.
Braucht ihr noch weitere Infos?

 

[Ray519]

Die EFI-Booteinträge sind im BIOS selbst gespeichert, da hast du Glück gehabt, dass der Windows Bootloader von alleine aufgetaucht ist.

Je nach BIOS kann man dort manuell Eintäge hinzufügen, in dem man mit einer Art-Filebrowser den richtigen EFI-Bootloader suchen geht und dem einen Namen gibt.

Alternativ einfach mit efibootmgr wieder anlegen. (Bei den Secure-Boot fähigen Distros die ich bisher gesehen habe, war der Bootloader üblicherweise shimx64.efi)

Ob und wie Manjaro Optionen bietet um den Bootloader neu zu installieren, kann ich dir nicht sagen, da ich das noch nicht verwendet habe.

 

[lokon]

Manjaro basiert auf Arch.
Also ist zB GRUB - UEFI im Arch-Wiki relevant, oder https://wiki.archlinux.org/index.php/Arch_boot_process#UEFI
und andere Einträge.

Installation von Grub, refind oder systemd-boot funktioniert eigentlich lt. Beschreibung im Wiki - wichtig ist das die efivarfs vorhanden sind und die richtigen Pfade/Mounts stimmen - es hilft wenn zB Fallback und eine UEFI-Shell installiert ist auf der boot/ESP Partition.

sudo find /boot -iname "*.efi*"
/boot/EFI/systemd/systemd-bootx64.efi
/boot/EFI/BOOT/BOOTX64.EFI
/boot/EFI/memtest/BOOTX64.efi
/boot/EFI/memtest/BOOTIA32.efi
/boot/shellx64.efi

UEFI-Shell: hier , Memtest UEFI App von der offiziellen BootCD , Fallback (BOOTX64-gleiche shell wie "normaler" Start) und "normaler" Start (systemd-bootx64.efi)

 

[lokon]

Als Ergänzung zu den Pfaden/Mounts und den Einträgen im UEFI:

• Es kann UEFI "Bugs" geben [1]
• "defaults" (Shell, Fallback) sollten vorhanden sein
• innerhalb UEFI-Shell kann mit bcfg das Menü editiert werden
• die UEFI-Shell ist eine Kommandozeilenumgebung und hat integrierte Hilfe, kann "Applikationen" (memtest oder OS-Bootloader) einfach Ausführen und die erkannten Laufwerke auflisten: efibootmgr hat evtl Einträge leicht falsch angelegt -> UEFI "Bugs"
• der "Pfad" im UEFI Eintrag zum Bootloader ist nicht korrekt (efibootmgr -v zeigt das detaillierter)
• bei einem Verschieben von SATA (meist /dev/sda) auf NVME (/dev/nvme0n1) ändert sich der Hardwareanschluss d.h. UEFI muss angepasst werden
• bei NVME Geräten gibt es "Namespaces" (zB nvme0n1p1 <- Gerät 0 , Namespace 1, Partition 1 , bei mehreren nvme slots dann nvme1n1p1 nvme2n1p1....)

- Je nach Distribution/Bootloader sollten die Pfade und Unterverzeichnisse korrekt sein damit bei der Installation bzw. Upgrade von Kernel die richtigen Dateien geändert werden:

-> Kernel auf EFI-Partition ( zB bei obigen beispiel von mir -> /boot ist /dev/nvme0n1p1 eine EFI (ESP) Partition, dh FAT32)
-> /boot ist im "rootfs" (...ext4/ evtl. verschlüsselt) und Unterverzeichnis /boot/efi ist ESP Partition (FAT32) -> kernel liegt im rootfs, die Pfade der EFI Anwendungen sind länger: /boot/efi/shellx64.efi , boot/efi/EFI/memtest/*.efi ... ; der "Bootloader" von Linux - refind/grub-efi/systemd-boot muss dann mit der verschlüsselten Partition umgehen können, wenn von dort der Kernel geladen wird
-> /boot und /efi getrennt -> /efi/shellx64.efi , /efi/EFI/memtest/*.efi zB
Pfade sind zb auch hier ein Thema

[1] zB Probleme mit der Art der Formatierung der ESP Partition - im Standard ist FAT12/FAT16/FAT32 möglich.

The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system

UEFI 2.6 S.587 - da gibt es evtl. Bugs bzgl. FAT12/FAT16, Partitionsgröße, Clustergröße , "minimale Größe" ... : mir ist soetwas passiert afaik wegen indirekt 512->4K als sector size ; (dieser Bugreport geht zB auf Größen von ESP ein)

UEFI ist vielleicht nicht "schön" - aber es ist immerhin etwas besser "definiert" - das Booten erfolgt nicht von Software "irgendwo" im MBR außerhalb von angelegten Partitionen - und kann beliebig überschrieben werden; es ist ja kein "benutzter" Platz, sondern der Bootcode ist eine Datei.