openSUSE Leap 15.6: Bootloader-Update scheitert - invalid EFI

Das Computersystem enthält
Windows 11 auf /dev/nvme0, mit einer EFI-Bootpartition auf /dev/nvme0n1p1 (FAT) und openSUSE Leap 15.6 auf /dev/nvme1,

wobei allerdings auf /dev/nvme1n1p1 ebenfalls ein /boot Subverzeichnis angelegt wurde. Secure Boot ist aktiviert.

Der funktionierende Bootloader hat Leap 15.6 und Windows 11 im Bootmenü. Will man jedoch den Bootloader via yast2 aktualisieren, kommt die Fehlermeldung “invalid EFI”.
Die Zielvorstellung wäre, ein automount für Boot-Partition /dev/nvme0n1p1 in Linux einzurichten, sodass der grub2-Bootloader-Eintrag /boot auf /dev/nvme1n1p1
überflüssig wird aber potentielle Interferenz verschiedener Boot-Partitionen vermieden wird.
Es ist allerdings unklar, wie der Fehler “invalid EFI” zu beheben ist und welches Risiko besteht, wenn man in /etc/fstab Änderungen vornimmt, da das System dann möglicherweise nicht mehr bootbar ist.

ein entsprechender Eintrag in /etc/fstab wurde inzwischen vorgenommen. Booten funktioniert weiter. Als nächstes wäre zu testen, ob ein Bootloader-Update immer noch scheitert…

Auch hier:
in /boot sind Dateien überflüssig und für mich fehlt z. B. die initrd.
siehe auch die letzten Beiträge zum Thema Auflösung:

Leider mir zu hoch.

Poste einmal:
cat /etc/fstab

localhost:~ # cat /etc/fstab
UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /                       btrfs  defaults                      0  0
UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /var                    btrfs  subvol=/@/var                 0  0
UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /root                   btrfs  subvol=/@/root                0  0
UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /opt                    btrfs  subvol=/@/opt                 0  0
#UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
#UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=2fb86973-07c0-470e-9bdb-37f05cb051fb  /home                   xfs    defaults                      0  0
UUID=71a43985-274c-44fe-b7e4-da5d4388545e  swap                    swap   defaults                      0  0
UUID=2842-C2C7                             /boot                   vfat   defaults

Hier wurde die letzte Zeile eingefügt, um die Boot-Partition nvme0n1p1 auf /boot einzubinden, und zwei Zeilen weiter oben auskommentiert, die zuvor gültig waren.

Geändert hat sich am Problem, dass der Bootloader nicht aktualisiert werden kann, dadurch nichts…

Ja aber /boot sollte nicht vfat sein.
Das sollte /boot/efi sein…

Bei mir (allerdings ohne btrfs sondern mit ext4):

stephan@linux64:~> cat /etc/fstab
UUID=53d51072-1db6-4412-9955-0ccd307a2993  /          ext4  defaults      0  1
UUID=06a79156-d6da-448b-beb6-c178f954d065  /mnt/1TB   ext4  data=ordered  0  2
UUID=862e2a5f-f4e8-49f9-9e36-b1d18ef95bc7  /mnt/2TB   ext4  data=ordered  0  2
UUID=eef4a3cb-a588-4567-8121-e632578e1048  /home      ext4  data=ordered  0  2
UUID=5C93-DB36                             /boot/efi  vfat  utf8          0  2
UUID=40b208a5-8a0a-4eca-8948-fe42610ebca0  swap       swap  defaults      0  0

Wie man das bei dir macht, muss dir aber jemand anderes sagen.

1 Like

ok, danke, das kann ich natürlich versuchen, den mount-point auf /boot/efi zu ändern.

Bit du nicht verwirrt?
Man braucht ein EFI Partition (fvat) wenn man EFI booted.
Um es auch während des Laufens eines Linux Systems benutzen zu können wird das meistens auf /boot/efi eingehängt.

Ob man ein separates Dateisystem für /boot braucht hängt von allerhand Sachen ab. Das ding wird natürlich beim booten des Linux Systems benutzt und dan später in /boot eingehängt. Es sol ein Linux Typ wie ext2/3/4 sein.

Wenn du das so schlicht sagst klinkt das als ob du das einfach so mal in das schon installierte System gemacht hast. Wenn das aber vorgher nicht so war ist jetz nich darin was vorher in das Btrfs Dateisystem auf / war (und noch immer ist) .

Wo sind die denn? Wenn du nicht Alles zeigst was cat /etc/fstab herausgibt ist das fast Betrügerei.

vfat benutzt eigentlich keine Rechte, aber in /boot liegen Linux Dateien.

ls -al /boot/ | grep -i initrd
lrwxrwxrwx  1 root root       33 28. Jan 18:47 initrd -> initrd-6.4.0-150600.23.30-default
-rw-------  1 root root 25592808 28. Jan 18:50 initrd-6.4.0-150600.21-default
-rw-------  1 root root 69138932 28. Jan 18:50 initrd-6.4.0-150600.23.30-default
-rw-------  1 root root 69108429 28. Jan 18:50 initrd-6.4.0-150600.23.33-default

VIELEN DANK, DAS WAR DIE LÖSUNG !
Habe die Partition /nvme0n1p1 bei /boot/efi in fstab eingehängt, und der Bootloader läßt sich nun aktualisieren.

QStandardPaths: runtime directory '/run/user/1001' is not owned by UID 0, but a directory permissions 0700 owned by UID 1001 GID 100
MESA: error: ZINK: vkEnumeratePhysicalDevices failed (VK_ERROR_INITIALIZATION_FAILED)
MESA: error: ZINK: failed to choose pdev
glx: failed to create drisw screen
failed to load driver: zink
Run command: /usr/bin/nohup /usr/sbin/yast2 bootloader > /var/log/YaST2/nohup.out 2>&1 &

Die Fehlermeldung bezüglich screen, zink… könnte auch in Zusammenhang stehen mit dem Problem der geringen Bildschirmauflösung (siehe anderen Beitrag).

P.S.:
Das sind die zwei auskommentierten Zeilen:

#UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
#UUID=09ab4e15-af0d-4ceb-b0e8-b7cc2d50e196  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0

Bekommst du nun auch eine /boot/initrd ?

Ja, jetzt sieht alles normal aus:

ls -al /boot
insgesamt 205540
drwxr-xr-x 1 root root     1252 20. Jan 14:58 .
drwxr-xr-x 1 root root      144 20. Jan 14:41 ..
-rw-r--r-- 1 root root   272754 12. Jun 2024  config-6.4.0-150600.21-default
-rw-r--r-- 1 root root   272931 10. Jan 09:22 config-6.4.0-150600.23.33-default
drwxr-xr-x 5 root root     4096  1. Jan 1970  efi
drwxr-xr-x 1 root root       98 29. Jan 18:03 grub2
lrwxrwxrwx 1 root root       33 20. Jan 14:45 initrd -> initrd-6.4.0-150600.23.33-default
-rw------- 1 root root 65968198 21. Jan 14:24 initrd-6.4.0-150600.21-default
-rw------- 1 root root 65975789 21. Jan 14:24 initrd-6.4.0-150600.23.33-default
-rw-r--r-- 1 root root  1600305 10. Jan 09:41 symtypes-6.4.0-150600.23.33-default.gz
-rw-r--r-- 1 root root   362703 12. Jun 2024  symvers-6.4.0-150600.21-default.gz
-rw-r--r-- 1 root root   365153 10. Jan 09:40 symvers-6.4.0-150600.23.33-default.gz
-rw-r--r-- 1 root root      484 12. Jun 2024  sysctl.conf-6.4.0-150600.21-default
-rw-r--r-- 1 root root      484 10. Jan 09:40 sysctl.conf-6.4.0-150600.23.33-default
-rw-r--r-- 1 root root  7674911 12. Jun 2024  System.map-6.4.0-150600.21-default
-rw-r--r-- 1 root root  7637476 10. Jan 09:37 System.map-6.4.0-150600.23.33-default
-rw-r--r-- 1 root root 15970492 12. Jun 2024  vmlinux-6.4.0-150600.21-default.gz
-rw-r--r-- 1 root root 15947878 10. Jan 09:44 vmlinux-6.4.0-150600.23.33-default.gz
lrwxrwxrwx 1 root root       34 20. Jan 14:45 vmlinuz -> vmlinuz-6.4.0-150600.23.33-default
-rw-r--r-- 1 root root 14191584 12. Jun 2024  vmlinuz-6.4.0-150600.21-default
-rw-r--r-- 1 root root       65 12. Jun 2024  .vmlinuz-6.4.0-150600.21-default.hmac
-rw-r--r-- 1 root root 14173664 10. Jan 10:12 vmlinuz-6.4.0-150600.23.33-default

Gut, auch schon neu gestartet?
wenn ja, dann weiter im anderen Beitrag.

reboot folgt.

Ich verstehe nicht warum du die da herausschmeisst. Das sind subvols deines / btrfs Dateisystems. Das ist entweder dein EFI partition, sonst noch was das beim Boot benutzt wird.

Es ist mir sowieso rätselhaft was du versuchtst zu erreichen. Aber was du jezt alles machts kann nicht viel Gutes bringen.

Kommentar siehe nachstehend

kann ich natürlich rückgängig machen, wenn das ein Fehler war.

Wenn auch du nicht weißt warum du das gemacht hast ist es wirklich ein Fehler.