• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Gelöst OpenSUSE 15.6 - Kein UEFI Start

Liebe Linux-Gemeinde,

durch einen Fehler meinerseits musste ich mein System neu installieren. In Bios des Rechners steht der Menuestart auf Uefi, die erste Partition ist die Vat-Partition mit Efi Boot.
Aber bein Starten meldet sich immer Windows. Was habe ich falsch gemacht, was kann ich posten?

LG Uwe
 
Hast Du Linux im UEFI-Modus installiert?

Kannst Du das installierte Linux über das Installationsmedium starten? Wenn ja, als root: efibootmgr -v
 
Code:
localhost:~ # efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 2001,0006,0000,2002,2003
Boot0000* opensuse-secureboot   HD(1,GPT,5d55d54c-d3b4-4448-9251-44f4238b3c8a,0x50a80000,0x35c52000)/File(\EFI\opensuse\shim.efi)
Boot0001* USB HDD: Intenso Basic Line   PciRoot(0x0)/Pci(0x1a,0x0)/USB(0,0)/USB(0,0)/HD(1,MBR,0x7bedac11,0x108,0x2274)RC
Boot0003* MATSHITADVD-RAM UJ8E2Q                BBS(CDROM,,0x500)................-...........A......#..............................y,........A...............
..........
Boot0004* LITEON IT L8T-128L9G                  BBS(HD,,0x500)................-...........A......B..............................n,........A..................
.......
Boot0005* INTENSO SSD                           BBS(PCMCIA,,0x500)................-...........A......R..............................e,........A..............
...........
Boot0006* Windows Boot Manager  HD(2,GPT,a2c0531c-b445-47ef-9f99-67ae11f8109a,0x12c800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C
.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC
localhost:~ #

Boot0001* USB HDD: Intenso Basic Line -> das ist mein USB-Stick mit der Installation, wie ich derzeit OpenSuse starte.
BootOrder: 2001,0006,0000,2002,2003 - Diese Reihenfolge ist der Fehler- oder?
 
Zuletzt bearbeitet:
Im Beitrag 4 läuft Linux im UEFI-Modus. Du hast zwei EFI-Systempartitionen. Das ist zwar formal zulässig, aber in 99,9 % aller Situationen nicht sinnvoll (und die verbleibenden 0,1 % sollten wissen, was sie tun).

Sage Deinem UEFI(-Bootmenü), daß es opensuse-secureboot starten soll. Wenn der Eintrag Dein neu installiertes Linux startet (und keine Leiche vom alten System ist), dann mache das dauerhaft.

Ansonsten starte noch einmal über das Installationsmedium, richte im laufenden System GRUB-2 korrekt ein, und führe dann noch einmal efibootmgr -v aus.
 
Ich habe kein Altsystem auf meinem Laptop, aber sage mir bitte wo ich in mein UEFI-Bootmenue bekomme, über Yast?
 
Hallo Uwe,

wenn du den Bootloader von Microsoft nicht auf shim.efi umgeleitet hast (wird z.B. hier beschrieben), dann wird wohl in dieser Konfiguration immer Windows (zuerst) geladen.
Solltest du diese Umleitung machen wollen, wird vermutlich ein zweiter "Windows Boot Manager"-Eintrag im BIOS erscheinen. Also nicht verwirren lassen.

Ansonsten müsste die Bootreihenfolge so aussehen: BootOrder: 2001,0000,0006,2002,2003

So müsstest du zum GRUB-Bootmenü kommen.
 
Welche Taste Du nach dem Pieps-Ton einige Sekunden lang drücken mußt, um ins UEFI bzw. UEFI-Bootmenü zu kommen, hängt von Deinem UEFI ab und sollte im Handbuch beschrieben sein (bei mir sind es Entf bzw. F8). Da Boot0001 nicht in der Bootreihenfolge aufscheint, mußt Du Deinem UEFI irgendwie gesagt haben, diesen Eintrag zu starten, und dort sollte es auch die Möglichkeit geben, Boot0000 auszuwählen, aber bei der Vielzahl von schlechten UEFI-Implementierungen kann das bei Dir anders sein.

Auch wenn Dein "Altsystem" durch die Neuinstallation nicht mehr vorhanden ist, kann das bei der Eintragung opensuse-secureboot hinterlegte Programm noch auf das "Altsystem" zeigen. Niemand außer Dir kann sagen, wie Du bei der Neuinstallation vorgegangen bist.

An BeastXXL: Dein link mag für bestimmte UEFI sinnvoll sein, bei anderen UEFI mag die Anleitung kontraproduktiv wirken. Die Bootreihenfolge zu ändern, ohne sich zu vergewissern, daß Boot0000 funktioniert, kann dazu führen, daß Windows bis auf weiteres nicht mehr startet.
 

susejunky

Moderator
Teammitglied
Hallo @Uwe.Lü ,

um Dir weiterhelfen zu können, wäre es hilfreich noch ein paar Informationen zu Deinem System zu haben.

Könntest Du bitte noch die Ergebnisse folgender Befehle:
Code:
blkid
Code:
lsblk -f
Code:
parted -l
(als "root" in einer Konsole ausgeführt) zeigen?

Viele Grüße

susejunky
 
Hier ist die Ausgabe der Befehle

Code:
localhost:~ # blkid
/dev/sdb4: UUID="9f9735b9-e4a6-46f7-b827-457f085137f7" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="c711ac06-dc4d-4502-ba47-809d4309b919"
/dev/sdb2: UUID="c472fff9-680a-444c-9d64-d821476f53d3" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="2adc0e0c-018d-4550-802f-591c8b4e836e"
/dev/sdb5: UUID="85009b08-9852-4f45-9382-e4a31f37b540" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="2f30ce99-b206-4b28-b022-0aef30e32a4d"
/dev/sdb3: UUID="0624806a-28be-464f-9093-8468e0f0a9e8" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="fd6cfd80-9bd3-43bb-8a1d-78fe82655d24"
/dev/sdb1: UUID="4526-9B20" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5d55d54c-d3b4-4448-9251-44f4238b3c8a"
/dev/sdb8: UUID="66f6b907-e0a3-42de-ad1f-dfd7f75d2fcd" TYPE="swap" PARTUUID="59ce1bd3-18e1-44b3-8130-486c91cbb25c"
/dev/sdb6: UUID="89b5857e-0d5d-4b2e-9c36-0df766cb74a3" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="d839b535-4803-4b56-9018-be6026de6d0f"
/dev/sda4: BLOCK_SIZE="512" UUID="44B2C4F0B2C4E80E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="99cdf8ab-d91c-42c5-ad6e-7de70c4b7049"
/dev/sda2: UUID="B4BC-7E7E" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="a2c0531c-b445-47ef-9f99-67ae11f8109a"
/dev/sda5: BLOCK_SIZE="512" UUID="683A8D453A8D116C" TYPE="ntfs" PARTUUID="f9f649d9-782b-408c-9752-01abf74f66e6"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="b532b45b-bdf8-471b-9a32-9ee47c087bc7"
/dev/sda1: LABEL="RECOVERY" BLOCK_SIZE="512" UUID="D00CE4590CE43BDA" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="2c6c0be8-7850-4979-b8b9-a7d4e02ab
380"
Code:
localhost:~ # lsblk -f
NAME   FSTYPE FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                              
├─sda1 ntfs         RECOVERY D00CE4590CE43BDA                                    
├─sda2 vfat   FAT32          B4BC-7E7E                                           
├─sda3                                                                           
├─sda4 ntfs                  44B2C4F0B2C4E80E                                    
└─sda5 ntfs                  683A8D453A8D116C                                    
sdb                                                                              
├─sdb1 vfat   FAT32          4526-9B20                               430G     0% /boot/efi
├─sdb2 xfs                   c472fff9-680a-444c-9d64-d821476f53d3  279.8G     2% /var
├─sdb3 xfs                   0624806a-28be-464f-9093-8468e0f0a9e8  465.8G    14% /home
├─sdb4 xfs                   9f9735b9-e4a6-46f7-b827-457f085137f7    1.7G    56% /opt
├─sdb5 xfs                   85009b08-9852-4f45-9382-e4a31f37b540  379.1M    15% /tmp
├─sdb6 xfs                   89b5857e-0d5d-4b2e-9c36-0df766cb74a3    622G     3% /
└─sdb8 swap   1              66f6b907-e0a3-42de-ad1f-dfd7f75d2fcd                [SWAP]
sr0
Code:
localhost:~ # parted -l
Model: ATA LITEON IT L8T-12 (scsi)
Disk /dev/sda: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system  Name                          Flags
 1      1049kB  630MB  629MB   ntfs         Basic data partition          hidden, diag
 2      630MB   735MB  105MB   fat32        EFI system partition          boot, esp
 3      735MB   752MB  16.8MB               Microsoft reserved partition  msftres
 4      752MB   127GB  127GB   ntfs         Basic data partition          msftdata
 5      127GB   128GB  722MB   ntfs                                       hidden, diag


Model: ATA INTENSO SSD (scsi)
Disk /dev/sdb: 2048GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 5      1049kB  538MB   537MB   xfs
 6      538MB   691GB   690GB   xfs
 8      691GB   693GB   2147MB  linux-swap(v1)        swap
 1      693GB   1155GB  462GB   fat32                 legacy_boot, msftdata
 2      1155GB  1462GB  307GB   xfs
 3      1462GB  2044GB  582GB   xfs
 4      2044GB  2048GB  4295MB  xfs


localhost:~ #

Edit: ICODE nach CODE umgesetzt. Bitte zum Einfügen von Codeausgaben die Code-Tags </> verwenden. Lg Christina, Moderatorin
 
Zuletzt bearbeitet von einem Moderator:
Code:
1      693GB   1155GB  462GB   fat32                 legacy_boot, msftdata
Über Yast habe ich die Partion 1 auf Boot/EFI umgestellt, Jetzt startet OpenSUSE wie gewohnt.
 

susejunky

Moderator
Teammitglied
Hallo @Uwe.Lü ,

aufgrund der nachfolgenden Informationen

Code:
localhost:~ # efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 2001,0006,0000,2002,2003
Boot0000* opensuse-secureboot HD(1,GPT,5d55d54c-d3b4-4448-9251-44f4238b3c8a,0x50a80000,0x35c52000)/File(\EFI\opensuse\shim.efi)
...
Boot0006* Windows Boot Manager HD(2,GPT,a2c0531c-b445-47ef-9f99-67ae11f8109a,0x12c800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C
.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
...
localhost:~ #
Code:
localhost:~ # blkid
...
/dev/sdb1: UUID="4526-9B20" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5d55d54c-d3b4-4448-9251-44f4238b3c8a"
...
/dev/sda2: UUID="B4BC-7E7E" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="a2c0531c-b445-47ef-9f99-67ae11f8109a"
...
Code:
localhost:~ # lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
...
├─sda2 vfat FAT32 B4BC-7E7E
...
sdb
├─sdb1 vfat FAT32 4526-9B20 430G 0% /boot/efi
...
vermute ich, dass es in Deinem System momentan 2 ESPs gibt (sda2 und sdb1).

sda2 wurde wahrscheinlich von MS Windows angelegt. sdb1 könnte bei der Neu-Installation von openSUSE entstanden sein. Allerdings verstehe ich nicht warum diese Partition 430GB groß ist (wenn sie tatsächlich eine ESP ist).

Wenn Du risikofreudig bist, kannst Du versuchen die Bootreihenfolge im NVRAM Deines UEFIs wie folgt (als "root" auszuführen) zu ändern:
Code:
efibootmgr -o 0000,0006,2001,2002,2003
Wenn Du sicher gehen willst, dass sdb1 tatsächlich eine nutzbare ESP ist, dann zeige bitte die Ergebnisse von
Code:
mount
Code:
ls -alR /boot/efi

Viele Grüße

susejunky

NACHTRAG
Da war ich wohl zu langsam :(
NACHTRAG ENDE
 
Über Yast habe ich die Partion 1 auf Boot/EFI umgestellt, Jetzt startet OpenSUSE wie gewohnt.
Dann muß aber auch die UEFI-Bootreihenfolge geändert worden sein. Was zeigt jetzt: efibootmgr -v

P. S. Eine 462 GB (430 GiB) große Partition als EFI-Systempartition zu mißbrauchen, ist keine sinnvolle Vorgangsweise.
 
Code:
localhost:~ # efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0000,0001,0006,2001,2002,2003
Boot0000* opensuse-secureboot   HD(1,GPT,5d55d54c-d3b4-4448-9251-44f4238b3c8a,0x50a80000,0x35c52000)/File(\EFI\opensuse\shim.efi)
Boot0001* HDD1: INTENSO SSD     PciRoot(0x0)/Pci(0x1f,0x2)/Sata(5,0,0)/HD(1,GPT,5d55d54c-d3b4-4448-9251-44f4238b3c8a,0x50a80000,0x35c52000)RC
Boot0003* MATSHITADVD-RAM UJ8E2Q                BBS(CDROM,,0x500)................-...........A......#..............................y,........A.........................
Boot0004* LITEON IT L8T-128L9G                  BBS(HD,,0x500)................-...........A......B..............................n,........A.........................
Boot0005* INTENSO SSD                           BBS(PCMCIA,,0x500)................-...........A......R..............................e,........A.........................
Boot0006* Windows Boot Manager  HD(2,GPT,a2c0531c-b445-47ef-9f99-67ae11f8109a,0x12c800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC
localhost:~ #

Die boot-Reihenfolge ist schon zu Beginn so eingestellt gewesen.
 

susejunky

Moderator
Teammitglied
Hallo @Uwe.Lü ,

Code:
localhost:~ # efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0000,0001,0006,2001,2002,2003
... localhost:~ #

Die boot-Reihenfolge ist schon zu Beginn so eingestellt gewesen.
Hmmm ...
Code:
localhost:~ # efibootmgr -v
BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 2001,0006,0000,2002,2003
...localhost:~ #

BootOrder: 2001,0006,0000,2002,2003 - Diese Reihenfolge ist der Fehler- oder?
wie passt das zusammen ??? Definiere "zu Beginn".

Für Alle, die hier mitlesen und eventuell nach einer Lösung für ein identisches Problem suchen, wäre es hilfreich, wenn Du genauer beschreiben würdest, was Du genau getan hast (z.B. welches YaST-Modul Du verwendet hast, wie Du welche Änderungen konkret vorgenommen hast, ...), um Dein Problem zu lösen.

Vielen Dank und viele Grüße

susejunky
 
Die Eintragung Boot0001 enthält jeweils ein anderes Medium und ist wie von susejunky erwähnt im Beitrag 4 nicht in der Bootreihenfolge vorhanden. Entweder ist das UEFI darauf trainiert, auf der EFI-Systempartition des jeweils angegebenen Mediums eine passende Datei *.EFI zu suchen und auszuführen, oder es existiert auch auf dem im Beitrag 14 angegebenen Medium eine Datei /EFI/BOOT/BOOTX64.EFI (das im Beitrag 4 verwendete Installationsmedium enthält eine solche Datei). Die Ausgaben
Code:
mount
Code:
ls -alR /boot/efi
wären nützlich.

Ob die Eintragung Boot0000 gültig oder eine Leiche ist, wissen wir immer noch nicht.

In Summe ist das alles eine undurchsichtige Angelegenheit, die durch ihre 2 EFI-Systempartitionen noch komplizierter und vermutlich irgendwann zu weiteren Problemen führen wird.
 
Ich habe über YaST - Partitionierer sbd1 entprechend bearbeitet.
Die Partition sda2 scheint von einer voran gegangenen Installation zu sein, wenn es nicht eine Windows Partition ist.
Mein Laptop hat 2 Platten sda1 Liteon IT L8T-12 - > Windows 11
und sdb2 Intenso SSD - OpenSuSE
Mein Bios ist so eingestellt, das die Intenso SSD zuerst gestartet wird.
 

susejunky

Moderator
Teammitglied
Hallo @Uwe.Lü ,

Ich habe über YaST - Partitionierer sbd1 entprechend bearbeitet.
was muss man sich unter "entsprechend bearbeitet" vorstellen?

Dass der YaST-Partitionierer die Boot-Reihenfolge im NVRAM des UEFIs verändert, wäre mir neu.

Die Partition sda2 scheint von einer voran gegangenen Installation zu sein, wenn es nicht eine Windows Partition ist.
Es ist in der Tat sehr wahrscheinlich, dass sda2 eine von MS Windows angelegte ESP ist.

Mein Bios ist so eingestellt, das die Intenso SSD zuerst gestartet wird.
Die von Dir gezeigten Ausgaben belegen, dass Dein UEFI als erstes versuchen sollte /dev/sdb1/boot/efi/EFI/opensuse/shim.efi zu laden.

Allerdings verhalten sich UEFIs meist so, dass sie - wenn ein Bootloader nicht geladen werden kann (z.B. weil nicht vorhanden) - nach anderen ladbaren Bootloadern suchen (z.B. /EFI/BOOT/BOOTX64.EFI).

Die von @josef-wien und mir nachgefragten Informationen würden helfen, den tatsächlichen Startverlauf näher zu untersuchen.

Viele Grüße

susejunky
 
was muss man sich unter "entsprechend bearbeitet" vorstellen?
Das ich im Yast/System und Patitionierer mir die Eigenschaften von sdb1 angesehen habe und diese dem Mountpoint /boot/efi zugewiesen habe. Diese stand auf legacy.
Hier die Ausgaben:
Code:
localhost:~ # mount
/dev/sdb6 on / type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=4096k,nr_inodes=2027782,mode=755,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=3259952k,nr_inodes=819200,mode=755,inode64)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=24658)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/sdb4 on /opt type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/sdb3 on /home type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/sdb2 on /var type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
systemd-1 on /home/uwe/Projekte type autofs (rw,relatime,fd=48,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=26714)
systemd-1 on /home/uwe/Scanner type autofs (rw,relatime,fd=54,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=26716)
/dev/sdb1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1629972k,nr_inodes=407493,mode=700,uid=1000,gid=100,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
//Server01/Daten on /home/uwe/Projekte type cifs (rw,relatime,vers=default,cache=strict,username=uwe,uid=1000,noforceuid,gid=0,noforcegid,addr=192.168.2.50,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,x-systemd.automount,_netdev)
//Server01/Scanner$ on /home/uwe/Scanner type cifs (rw,relatime,vers=default,cache=strict,username=uwe,uid=1000,noforceuid,gid=0,noforcegid,addr=192.168.2.50,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1,x-systemd.automount,_netdev)
portal on /root/.cache/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
gvfsd-fuse on /root/.gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
localhost:~ #
Code:
localhost:~ # ls -alR /boot/efi
/boot/efi:
total 100
drwxr-xr-x 4 root root 32768 Jan  1  1970 .
drwxr-xr-x 4 root root  4096 Jun 18 12:06 ..
drwxr-xr-x 4 root root 32768 Jun 13 11:12 EFI
drwxr-xr-x 2 root root 32768 Jun 18 08:53 System Volume Information

/boot/efi/EFI:
total 128
drwxr-xr-x 4 root root 32768 Jun 13 11:12 .
drwxr-xr-x 4 root root 32768 Jan  1  1970 ..
drwxr-xr-x 2 root root 32768 Jun 13 11:12 boot
drwxr-xr-x 2 root root 32768 Jun 13 11:12 opensuse

/boot/efi/EFI/boot:
total 1984
drwxr-xr-x 2 root root  32768 Jun 13 11:12 .
drwxr-xr-x 4 root root  32768 Jun 13 11:12 ..
-rwxr-xr-x 1 root root 852456 Jun 18 13:39 MokManager.efi
-rwxr-xr-x 1 root root 965672 Jun 18 13:39 bootx64.efi
-rwxr-xr-x 1 root root  90640 Jun 18 13:39 fallback.efi

/boot/efi/EFI/opensuse:
total 4160
drwxr-xr-x 2 root root   32768 Jun 13 11:12 .
drwxr-xr-x 4 root root   32768 Jun 13 11:12 ..
-rwxr-xr-x 1 root root  852456 Jun 18 13:39 MokManager.efi
-rwxr-xr-x 1 root root      58 Jun 18 13:39 boot.csv
-rwxr-xr-x 1 root root     345 Jun 18 13:39 grub.cfg
-rwxr-xr-x 1 root root 2074624 Jun 18 13:39 grub.efi
-rwxr-xr-x 1 root root  155648 Jun 18 13:39 grubx64.efi
-rwxr-xr-x 1 root root  965672 Jun 18 13:39 shim.efi

/boot/efi/System Volume Information:
total 128
drwxr-xr-x 2 root root 32768 Jun 18 08:53 .
drwxr-xr-x 4 root root 32768 Jan  1  1970 ..
-rwxr-xr-x 1 root root    76 Jun 18 08:53 IndexerVolumeGuid
-rwxr-xr-x 1 root root    12 Jun 18 08:53 WPSettings.dat
localhost:~ #
 
Aus Beitrag 14:
Code:
BootCurrent: 0001
BootOrder: 0000,0001,0006,2001,2002,2003
Boot0000* opensuse-secureboot   HD(1,GPT,5d55d54c-d3b4-4448-9251-44f4238b3c8a,0x50a80000,0x35c52000)/File(\EFI\opensuse\shim.efi)
Boot0001* HDD1: INTENSO SSD     PciRoot(0x0)/Pci(0x1f,0x2)/Sata(5,0,0)/HD(1,GPT,5d55d54c-d3b4-4448-9251-44f4238b3c8a,0x50a80000,0x35c52000)RC
Es wurde nicht die erste Eintragung aus der Bootreihenfolge gestartet, sondern die zweite. Entweder hast Du beim Systemstart die Bootreihenfolge gezielt übersteuert, oder das UEFI konnte die erste Eintragung nicht ausführen und hat daher die zweite versucht und dabei Erfolg gehabt. Warum das INTENSO-Medium in Beitrag 4 nicht aufscheint und warum das LITEON-Medium in beiden Fällen nicht als Medium mit einer EFI-Systempartition aufscheint, kann höchstens der UEFI-Hersteller beantworten (die Eintragungen Boot0003 bis Boot0005 bestreffen aus meiner Sicht den "BIOS-Modus").

Zum Beitrag 19: Die Datei /boot/efi/EFI/opensuse/shim.efi hat zwar dieselbe Größe und denselben Zeitstempel wie die laut Beitrag 14 ausgeführte Datei /boot/efi/EFI/boot/bootx64.efi, aber hier müßte geprüft werden, ob die beiden Dateien identisch sind.

Nach diesen logischen Schlußfolgerungen ziehe ich mich einmal zurück, denn zur Klärung dieser undurchsichtigen Situation ist auch Wissen über openSUSE und dessen Automatismen notwendig.
 
Oben