[gelöst] Kernel für AMDGPU Cezanne - AMD Zen 3 (Ryzen)

[Christina]

Hi susejunky,

beide PCs sind identisch:
UEFI (Secure) Boot
kein RAID oder LVM
nur 1 Datenträger: PCIe SSD Samsung SSD 980 1TB
Partitionen (gerade eben per eMail bekommen)

lsblk -o +fstype
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT FSTYPE
sr0          11:0    1  1024M  0 rom             
nvme0n1     259:0    0 931,5G  0 disk            
├─nvme0n1p1 259:1    0   100M  0 part /boot/efi  vfat
├─nvme0n1p2 259:2    0    16M  0 part            
├─nvme0n1p3 259:3    0   300G  0 part /Windows   ntfs
├─nvme0n1p4 259:4    0   619M  0 part            ntfs
├─nvme0n1p5 259:5    0    20G  0 part /          ext4
├─nvme0n1p6 259:6    0     2G  0 part [SWAP]     swap
└─nvme0n1p7 259:7    0 608,8G  0 part /home      xfs

keine Verschlüsselung

Die / Partition (nvme0n1p5) habe ich vom 1. PC auf den 2. PC übertragen.
Wie installiere ich jetzt den Bootloader Grub2, nachdem openSUSE Leap per System-Rescue-CD (findroot) gestartet ist?

Ich befasse mich zum 1. Mal mit UEFI. Mein jetziger PC hat das nicht.
Und zu UEFI-Boot habe ich noch eine Idee: Könnte ich auch einfach das Verzeichnis "opensuse" in /boot/efi/EFI/ vom 1. PC in ein tar sichern und auf dem 2. PC wieder entpacken? Wird dann Grub2 bereits gefunden und gestartet?

tar cvf ~/boot_efi_openSUSE.tar /boot/efi/EFI/opensuse

Vielen Dank schon mal & Guten Rutsch!
Christina

 

[josef-wien]

Zum Grundsätzlichen: https://linux-club.de/forum/viewtopic.php?p=797058#p797058

Interpretiere ich Dich richtig, daß beide PC funktionieren und Du nach einer Lösung für künftige Fälle Ausschau hältst?

Nach Deiner ursprünglichen Aktion fehlten zwei Dinge: die Eintragung im UEFI-Boot-Menü und die Einrichtung eines Boot-Managers auf der EFI-Systempartition. Beides hat Deine Aktion mit YaST erledigt.

Näheres zu GRUB2-EFI muß Dir susejunky liefern, ich verwende das nicht. Aber meines Wissens teilt GRUB2-EFI seine Dateien auf die EFI-Systempartition und die Linux-Systempartition auf, sodaß mehr als das Verzeichnis aus ersterer kopiert und vermutlich die Menü-Datei angepaßt werden muß. Außerdem ist dann die Eintragung im UEFI-Boot-Menü manuell zu erzeugen.

Bis jetzt fällt mir kein Grund ein, warum die initrd neu erstellt werden mußte. So nebenbei sei angemerkt, daß die von den Distributionen fabrizierten initrd aus zwei zusammengehängten initrd besteht (die erste enthält nur den Microcode für die CPU, die zweite "das Übliche"). Mit dem Auspacken dieses Doppel-Archivs habe ich mich noch nicht beschäftigt (bei mir steckt der Microcode im Kernel), zur Anzeige für Vergleichszwecke sollte es ein Programm wie lsinitrd geben.

 

[susejunky]

Hallo Christina,

... Die / Partition (nvme0n1p5) habe ich vom 1. PC auf den 2. PC übertragen.
Wie installiere ich jetzt den Bootloader Grub2, nachdem openSUSE Leap per System-Rescue-CD (findroot) gestartet ist?
...
Könnte ich auch einfach das Verzeichnis "opensuse" in /boot/efi/EFI/ vom 1. PC in ein tar sichern und auf dem 2. PC wieder entpacken? Wird dann Grub2 bereits gefunden und gestartet?

im Prinzip könntest Du den Inhalt des Verzeichnisses /boot/efi/EFI/openSUSE von PC1 auf PC2 übertragen ABER ...

wenn ich Dich richtig verstanden habe, dann hast Du PC2 "manuell" partitioniert und nur den Inhalt des "/"-Verzeichnis von PC1 auf PC2 übertragen. Die UUIDs auf PC2 sind somit andere als auf PC1.

Wenn Du den Inhalt von /boot/efi/EFI/openSUSE von PC1 auf PC2 kopierst müsstes Du auf PC2 die Datei /boot/efi/EFI/openSUSE/grub.cfg anpassen:

search --fs-uuid --set=root UUID-DER-ROOT-PARTITION-PC2

Aber ich hatte auch schon Installationen, bei denen die Root-UUID fest in der Datei /boot/efi/EFI/openSUSE/grubx64.efi codiert war. Dann nutzt eine Anpassung von /boot/efi/EFI/openSUSE/grub.cfg nichts.

Aber selbst wenn eine Anpassung von /boot/efi/EFI/openSUSE/grub.cfg funktioniert, wird PC2 damit sehr wahrscheinlich noch nicht starten, da kein Eintrag im NVRAM des UEFIs von PC2 auf diesen Bootloader verweist.

In aller Regel scannen UEFIs beim Systemstart (Einschalten oder HW-Reset) alle Datenträger nach ESPs und darin enthaltenen Bootloadern. Drückt man beim Systemstart eine spezielle Taste (F1-F12, ESC, Entf, ... siehe Handbuch der verwendeten Systemplatine) so zeigt das UEFI eine Liste der gefundenen Bootloader, man kann einen auswählen und diesen starten. Wenn das funktioniert kann man dann mit

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "openSUSE" --loader \\EFI\\opensuse\\grubx64.efi

den openSUSE Bootloader im NVRAM eintragen und mit

efibootmgr -o nnnn,mmmm

die Startreihenfolge festlegen.

Aber ich bin der Meinung es wäre besser, den Bootloader auf PC2 neu zu installieren.

Sehr wahrscheinlich ist das auch möglich, wenn Du das System auf PC2 mit System-Rescue-CD (findroot) startest. Da ich jedoch noch nie mit System-Rescue-CD (findroot) gearbeitet habe, beschreibe ich Dir nachfolgend die Vorgehensweise, die ich in solchen Situationen einsetze:

• Starte ein Linux-LIVE- oder Rescue-System (im UEFI-Startmodus!) Deiner Wahl (z.B. das Rescue-System des openSUSE-Installationsmediums) auf PC2.
• Öffne eine Konsole und führe als Benutzer "root" die folgenden Befehle aus:
  1. mount /dev/nvme0n1p5 /mnt
  2. mount /dev/nvme0n1p1 /mnt/boot/efi
  3. mount -o bind /dev /mnt/dev
  4. mount -o bind /sys /mnt/sys
  5. mount -o bind /proc /mnt/proc
  6. mount -o bind /run /mnt/run
  7. chroot /mnt
  8. grub2-install
  9. grub2-mkconfig -o /boot/grub2/grub.cfg
  10. dracut -f
  11. exit
  12. efibootmgr -v
  Befehl 10 ist eigentlich nicht erforderlich sondern dient nur zur Absicherung.
  
  Befehl 12 dient nur dazu, dass Du kontrollieren kannst, ob der openSUSE Bootloader im NVRAM des UEFI eingetragen wurde und in der Bootreihenfolge an erster Stelle steht.

Das Alles funktioniert jedoch nur, wenn

• die Partition /dev/nvme0n1p1 von PC2 eine ESP ist und ausreichend Platz bietet.
• /dev/nvme0n1p1 das Root-Dateisystem beinhaltet.
• die Pakete grub2 und grub2-x86_64-efi auf PC2 installiert sind.

Viele Grüße und guten Rutsch in das neue Jahr

susejunky

 

[Christina]

Zum Grundsätzlichen: https://linux-club.de/forum/viewtopic.php?p=797058#p797058
Interpretiere ich Dich richtig, daß beide PC funktionieren und Du nach einer Lösung für künftige Fälle Ausschau hältst?

Genau. Ich möchte wissen, was das Modul "YaST2-Bootloader macht", wenn ich auf [ OK ] klicke. So bin ich unabhängig davon.

wenn ich Dich richtig verstanden habe, dann hast Du PC2 "manuell" partitioniert und nur den Inhalt des "/"-Verzeichnis von PC1 auf PC2 übertragen. Die UUIDs auf PC2 sind somit andere als auf PC1.

Wenn Du den Inhalt von /boot/efi/EFI/openSUSE von PC1 auf PC2 kopierst müsstes Du auf PC2 die Datei /boot/efi/EFI/openSUSE/grub.cfg anpassen:

SWAP auf PC2 hatte ich per "mkswap -c -uuid {UUID-PC1} -L Linux_swap /dev/nvme0n1p6" angelegt.
Die UUID der / Partition PC1 sichert FSArchiver ebenfalls. / auf PC2 hat die selbe UUID. https://www.fsarchiver.org/

(…)

Das Alles funktioniert jedoch nur, wenn

• die Partition /dev/nvme0n1p1 von PC2 eine ESP ist und ausreichend Platz bietet.
• /dev/nvme0n1p1 das Root-Dateisystem beinhaltet.
• die Pakete grub2 und grub2-x86_64-efi auf PC2 installiert sind.

Vielen Dank! Das war sehr schön ausführlich.

Übrigens legt WinXI auf einer leeren Festplatte eine 100 MiB große ESP an, openSUSE Leap (als Vorschlag) aber 550 MiB.
Warum, das weiß ich nicht. Ich habe es bei den 100 MiB belassen und es genügt.

Das Root-Dateisystem " / " liegt auf /dev/nvme0n1p5 (nicht auf /dev/nvme0n1p1).

Noch ein gutes neues Jahr Euch beiden!

 

[josef-wien]

Zur Sicherheit auch hier eine Anmerkung zu den verwendeten Universally Unique Identifier:
- jede Partitionentabelle hat eine (PTUUID)
- jede Partition hat eine (PARTUUID)
- jedes Dateisystem hat eine (schlampig UUID genannt)
Linux-Distributionen verwenden üblicherweise die Dateisystem-UUID. Das UEFI verwendet die PARTUUID, um die EFI-Systempartition anzusprechen. Daher ist die Eindeutigkeit innerhalb des jeweiligen Typs wichtig.

Ich habe mir einmal

System-Rescue-CD (findroot)

in einer virtuellen Maschine kurz angeschaut (länger ging nicht, da offenbar auf Grund des Altersunterschieds zwischen Kernel und Xorg die Maus streikte). Der Mechanismus, wie der ganz normal mit /sbin/init (das von der System-Rescue-CD nur dann gefunden wird, wenn es keine Verknüpfung mit vollem Pfad ist) beginnende Systemstart dazu veranlaßt wird, die Kernel-Module der System-Rescue-CD zu verwenden, ist mir vorläufig nicht klar (==> siehe Nachtrag). Vorteil gegenüber der von susejunky beschriebenen "konventionellen" Methode ist, daß die Punkte 1 bis 7 und 11 entfallen und in der gewohnten grafischen Oberfläche gearbeitet werden kann.

Nachtrag: Nach kurzer Analyse der Log-Dateien stelle ich fest, daß es unzählige Meldungen

FATAL: Could not load /lib/modules/5.10.87-1-lts/modules.dep: No such file or directory

gibt, d. h. alle ab /sbin/init zu ladenden Module werden nicht geladen (und somit viele Dienste nicht zur Verfügung gestellt). Die geladenen Module dürften alle aus der initrd der System-Rescue-CD stammen. Für eine 08/15-Installation sollte das zur Systemreparatur reichen. Wie gut Funktionen wie RAID, LVM, LUKS usw. unterstützt werden, werde ich nicht untersuchen.

 

[susejunky]

Hallo Christina,

... Ich möchte wissen, was das Modul "YaST2-Bootloader macht", wenn ich auf [ OK ] klicke.

je nach Situation macht das YaST-Bootloader-Modul noch mehr als das, was ich hier beschrieben habe.

... Das Root-Dateisystem " / " liegt auf /dev/nvme0n1p5 (nicht auf /dev/nvme0n1p1).

Das war mein (Kopier)Fehler !

Viele Grüße und alles Gute im neuen Jahr

susejunky

 

[Christina]

1. mount /dev/nvme0n1p5 /mnt
2. mount /dev/nvme0n1p1 /mnt/boot/efi
3. mount -o bind /dev /mnt/dev
4. mount -o bind /sys /mnt/sys
5. mount -o bind /proc /mnt/proc
6. mount -o bind /run /mnt/run
7. chroot /mnt
8. grub2-install
9. grub2-mkconfig -o /boot/grub2/grub.cfg
10. dracut -f
11. exit
12. efibootmgr -v

Befehl 10 ist eigentlich nicht erforderlich sondern dient nur zur Absicherung.

Hi susejunky,

ich konnte das jetzt (auf einem der beiden PCs) mit dem Rescue-System des openSUSE Leap 15.3-Installationsmediums ausprobieren:
Alle Schritte bis auf dracut -f wurden ohne Fehlermeldung ausgeführt.

dracut: Cannot find modul directory /lib/modules/5.3.18-57-default/
dracut: and --no-kernel was not specified

Für den sehr neuen AMD Ryzen 5 5600G musste ich ja einen neueren Kernel installieren.
Siehe Post von @Sauerland: https://linux-club.de/forum/viewtopic.php?p=797383#p797383
Also ist wieder "--kver" nötig.

dracut -f --kver 5.15.12-lp153.3.ga77f415-default

Problem:
Nach dem Reboot kommt statt des Bootloaders Grub2 nur ein schwarzer Bildschirm mit einer Fehlermeldung ganz oben:

unaligned pointer 0x2a44
Aborted Press any key to exit._

Nach dem Drücken einer Taste startet sofort WinXI.
"Repariert" habe ich Grub2 wieder, per System-Rescue-CD (findroot) {Leap 15.3} und mit dem "YaST2 - Bootloader" -> [ OK ].

"YaST2 - Bootloader" macht also doch noch etwas mehr als die Schritte grub2-install, grub2-mkconfig oben.
Jetzt wird's knifflig.
Hast du eine Idee?
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 

Ich habe mir einmal

System-Rescue-CD (findroot)

in einer virtuellen Maschine kurz angeschaut (länger ging nicht, da offenbar auf Grund des Altersunterschieds zwischen Kernel und Xorg die Maus streikte). Der Mechanismus, wie der ganz normal mit /sbin/init (das von der System-Rescue-CD nur dann gefunden wird, wenn es keine Verknüpfung mit vollem Pfad ist) beginnende Systemstart dazu veranlaßt wird, die Kernel-Module der System-Rescue-CD zu verwenden, ist mir vorläufig nicht klar (==> siehe Nachtrag). Vorteil gegenüber der von susejunky beschriebenen "konventionellen" Methode ist, daß die Punkte 1 bis 7 und 11 entfallen und in der gewohnten grafischen Oberfläche gearbeitet werden kann.

System-Rescue-CD (findroot) hat einige Einschränkungen:
die Bildschirmauflösung ist nur 640×480 Pixel
das Samsung exfat-Kernelmodul steht nicht zur Verfügung

Ich habe dann ein USB-Thumbdrive mit FAT32 genommen und auch mit dieser Methode versucht, Grub2 von Hand zu installieren. Ein Vorteil von System-Rescue-CD (findroot) ist, dass ich eine Maus für Copy&Paste benutzen kann.
Die komplette Ausgabe ist etwas länger: https://paste.opensuse.org/view/simple/404649

Das Problem ist hier auch da:
Nach dem Reboot kommt statt des Bootloaders Grub2 nur ein schwarzer Bildschirm mit einer Fehlermeldung ganz oben:

unaligned pointer 0x2a44
Aborted Press any key to exit._

Nach dem Drücken einer Taste startet sofort WinXI.
"Repariert" habe ich Grub2 wieder, per System-Rescue-CD (findroot) {Leap 15.3} und mit dem "YaST2 - Bootloader" -> [ OK ].

 

[susejunky]

Hallo Christina,

... Hast du eine Idee?

mal sehen.

Verstehe ich das richtig:

• PC2 (den Du für Deine Freundin gebaut hast) lässt sich momentan nicht starten, sondern zeigt beim Start diesen Fehler
  
  
  

  unaligned pointer 0x2a44
  Aborted Press any key to exit._

• PC2 startet im UEFI-Modus und secureboot ist im UEFI eingeschaltet?

Wenn dem so ist, dann lade Dir bitte dieses openSUSE LIVE-System herunter. Damit steht Dir aktuelle Software und eine grafische Oberfläche zur Verfügung. Du kannst eine grafische Konsole nutzen und Informationen kopieren und hier (oder über paste.opensuse.org) zeigen.

Bitte starte dieses LIVE-System auf PC2, öffne eine grafische Konsole, führe als Benutzer "root" die folgenden Befehle aus und zeige die vollständigen Ergebnisse (inkl. der von Dir eingegebenen Befehlszeile bis zur nächsten, leeren Eingabeaufforderung) hier im Forum:

efibootmgr -v

lsblk -f

lspci -k

Viele Grüße

susejunky

 

[Christina]

Verstehe ich das richtig:

Nein. Den Fehler habe ich beide Male mit YaST2 - Bootloader -> klick auf [ OK ] "repariert".

Ich möchte einfach nur GRUB2 auch ohne YaST auf einem UEFI-System (nach einem Klonen der /-Partition) installieren können. Wenn ich mal eine andere Distribution verwende, gibt es ja keinen YaST.

Bei meinem eigenen PC kann ich das leider nicht ausprobieren. Der ist 10 Jahre alt und hat nur so ein seltsames Hybrid-EFI.
Ich verwende da den alten BIOS-Boot. Später mal baue ich mir auch noch einen neuen PC zusammen, aber im Moment tut's der hier noch gut.
LG Christina

 

[josef-wien]

Hilft shim-install (https://www.suse.com/support/kb/doc/?id=000019909)? grub2-... hat ja "nur" grubx64.efi im UEFI-Boot-Menü eingetragen.

 

[susejunky]

Hallo Christina,

... Ich möchte einfach nur GRUB2 auch ohne YaST auf einem UEFI-System (nach einem Klonen der /-Partition) installieren können.

also eigentlich hätte mein Lösungsvorschlag das von Dir angestrebte Ergebnis liefern müssen.

Falls der von josef-wien gemachte Vorschlag (shim statt grubx64.efi zum Systemstart zu nutzen) das Problem nicht löst, sehe ich nur einen Weg , um weiter nach einer Lösung zu suchen:

Zurück auf "Start"; d.h. auf PC2

• alle Nicht-MS-Windows-Partitionen löschen.
• auf der ESP alle Verzeichnisse außer EFI/Boot und EFI/Microsoft löschen.
• mit gdisk (oder fdisk oder einem anderen geeigneten Werkzeug Deiner Wahl) die Linux-Partitionen ("/", SWAP, /home, ...) neu anlegen.
• das "/"-Verzeichnis von PC1 erneut einspielen.
• die UUIDs in der Datei /etc/fstab anpassen (mit Hilfe eines LIVE-Systems).

Und wenn dieser Zustand erreicht ist, alles Weitere Schritt-für-Schritt, interaktiv hier im Forum entwickeln. Mit PC2 im aktuellen Zustand noch weiter nach einer Lösung zu suchen, halte ich persönlich nicht für sinnvoll. Aber es liegt bei Dir, wie Du weiter vorgehen möchtest ...

Wenn Du den oben aufgezeigten Weg gehen möchtest, dann solltest Du PC2 wie oben beschrieben vorbereiten (Aber bitte keine weiteren Veränderungen/Anpassungen vornehmen!), Dir das von mir vorgeschlagene LIVE-System beschaffen und einen neuen Beitrag hier im Forum eröffnen ("Bootloader manuell installieren" o.ä.).

Anschließend mit Hilfe des LIVE-Systems in einer grafischen Konsole als Benutzer "root" die folgenden Befehle ausführen und die vollständigen Ergebnisse (inkl. der von Dir eingegebenen Befehlszeile bis zur nächsten, leeren Eingabeaufforderung) mit in den ersten Beitrag packen

efibootmgr -v

lsblk -f

blkid

lspci -k

Viele Grüße

susejunky

 

[Christina]

Hilft shim-install (https://www.suse.com/support/kb/doc/?id=000019909)? grub2-... hat ja "nur" grubx64.efi im UEFI-Boot-Menü eingetragen.

Ja, das war es.

/usr/sbin/shim-install --config-file=/boot/grub2/grub.cfg

Jetzt habe ich den notwendigen Boot-Eintrag: opensuse-secureboot
Der andere mit "opensuse" ist völlig überflüssig: Da kommt es nur zu der Fehlermeldung, wenn ich diesen Eintrag im Boot-Menü des Mainboards auswähle (UEFI-Setup).

unaligned pointer 0x2a44
Aborted Press any key to exit._

Noch zur Info: CSM (Compatibility Support Module) ist disabled, UEFI-Secure-Boot ausgeschaltet: OS Type [ Other OS ].

Mit eingeschaltetem Secure-Boot [ Windows UEFI mode ] lässt sich weder das Installationsmedium openSUSE Leap 15.3 noch SystemRescue 8.07 starten. Das installierte Leap 15.3 kann erst damit starten, wenn die Machine Owner Key (MOK) "enrolled" ist. (Ich lasse es bei [ Other OS ].)

$ efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0001,0000,0005
Boot0000* Windows Boot Manager	HD(1,GPT,5c32dd80-17c1-49e2-a861-55b30fd42cce,0x800,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.}...1................
Boot0001* opensuse	HD(1,GPT,5c32dd80-17c1-49e2-a861-55b30fd42cce,0x800,0x32000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0004* opensuse-secureboot	HD(1,GPT,5c32dd80-17c1-49e2-a861-55b30fd42cce,0x800,0x32000)/File(\EFI\OPENSUSE\SHIM.EFI)
Boot0005* UEFI:Network Device	BBS(131,,0x0)

Vielen Dank!

 

[josef-wien]

UEFI (Secure) Boot

Ich habe das als "mit secure boot" interpretiert. Dann ist der signierte SHIM.EFI notwendig und

Mit eingeschaltetem Secure-Boot [ Windows UEFI mode ] lässt sich weder das Installationsmedium openSUSE Leap 15.3 noch SystemRescue 8.07 starten. Das installierte Leap 15.3 kann erst damit starten, wenn die Machine Owner Key (MOK) "enrolled" ist.

die logische Konsequenz.

Ohne secure boot reicht GRUBX64.EFI aus. Nach der initrd haben wir nun das zweite Phänomen. Ich würde jetzt den Hauptspeicher gründlich mit memtest überprüfen (und auch eine defekte SSD nicht ausschließen).

P. S. Ich sehe Deine Entscheidung

OS Type [ Other OS ]

als die bessere Lösung.

 

[Christina]

Ohne secure boot reicht GRUBX64.EFI aus. Nach der initrd haben wir nun das zweite Phänomen. Ich würde jetzt den Hauptspeicher gründlich mit memtest überprüfen (und auch eine defekte SSD nicht ausschließen).

Das Mainboard ist bei beiden PCs das Asus TUF Gaming B550-Plus. Die aktuelle Firmware "BIOS 2423" ist installiert.
MemTest86 Free (Version 9.3 Build 1000) ist auf beiden PCs 4 Mal ohne Fehler durchgelaufen.
Der andere PC (Nr.1) bringt die selbe Fehlermeldung, wenn ich den Booteintrag "opensuse" statt "opensuse-secureboot" im Boot-Menü des Mainboards anklicke. (UEFI-Setup: OS Type [ Other OS ]).

unaligned pointer 0x2a44
Aborted Press any key to exit._

Den Starthänger bei

[ OK ] Found device Samsung SSD 980 1TB Linux_root
[ OK ] Reached Target Initrd Root Device

hatte ich nur ein einziges Mal: direkt nach dem Klonen der / Partition auf den 2.PC. dracut hat das behoben.
Alles andere war nur für mich zur Übung & Lerneffekt.
/usr/sbin/shim-install ist aber nur für openSUSE. Ich habe schon geschaut: Ubuntu verwendet etwas anderes.
 

P. S. Ich sehe Deine Entscheidung

OS Type [ Other OS ]

als die bessere Lösung.

Klar, mit aktiviertem Secure-Boot (UEFI-Setup: OS Type [ Windows UEFI mode ]) geht auf diesem PC außer WinXI & Leap 15.3 gar nichts mehr: kein MemTest, kein SystemRescue, kein Installationsmedium, …
CSM (Compatibility Support Module) lasse ich auf "disabled". Das habe ich für beide PCs überhaupt nicht gebraucht.

Vielen Dank nochmal an alle für die Hilfe!
LG Christina

 

[josef-wien]

Der andere PC (Nr.1) bringt die selbe Fehlermeldung, wenn ich den Booteintrag "opensuse" statt "opensuse-secureboot" im Boot-Menü des Mainboards anklicke.

Das ist auf jeden Fall sehr erfreulich. Damit fällt mir nur noch ein, daß GRUBX64.EFI bei diesem UEFI Probleme verursacht (und zur Feststellung, ob GRUB2 oder das UEFI schuld ist, kann ich nichts beitragen).

Zur Sicherheit: Schau nach, in welchem Paket die Datei grubx64.efi steckt, und prüfe das Paket mit:

rpm -V paketname

 

[Christina]

Zur Sicherheit: Schau nach, in welchem Paket die Datei grubx64.efi steckt, und prüfe das Paket

Ich finde diese Datei nicht in einem RPM. Wird sie vielleicht von GRUB2 selbst erstellt?

In diesem Thread bei dem Post hier https://linux-club.de/forum/viewtopic.php?p=767922#p767922 & ff geht es um eine EFI-Shell, die man als Datei nach /boot/efi/EFI/ kopiert und damit den Rechner startet. Ich würde es mal damit probieren.

Sind diese verlinkten Binaries z.B. "Shell.efi" noch aktuell? Der Thread ist ja schon über 6 Jahre alt.

 

[josef-wien]

grubx64.efi und shim.efi sind Programme, die vom UEFI ausgeführt werden. Ich kann mir schwer vorstellen, daß die bei openSUSE nicht in RPM-Paketen stecken.

Mit einer EFI-Shell solltest Du Dich erst beschäftigen, wenn Du selbst einen PC mit UEFI hast. Da steckt viel Lernarbeit dahinter.

Zu UEFI haben Robi & Co. damals https://linux-club.de/wiki/opensuse/UEFI verfaßt. Daneben betrachte ich http://www.rodsbooks.com/efi-bootloaders/ als Pflichtlektüre.

 

[susejunky]

Hallo Christina,

... Ich finde diese Datei nicht in einem RPM. Wird sie vielleicht von GRUB2 selbst erstellt?

soweit mir bekannt ruft grub2-install das Programm grub2-mkimage auf, um die erforderliche Bootloader-Datei (z.B. grubx64.efi) zu erstellen.

... In diesem Thread bei dem Post hier https://linux-club.de/forum/viewtopic.php?p=767922#p767922 & ff geht es um eine EFI-Shell, die man als Datei nach /boot/efi/EFI/ kopiert und damit den Rechner startet. Ich würde es mal damit probieren.

Sind diese verlinkten Binaries z.B. "Shell.efi" noch aktuell? Der Thread ist ja schon über 6 Jahre alt.

Bei meiner Desktop-Systemplatine (Marke MSI, aus dem Jahr 2014) stellt das UEFI eine eingebaute Shell zur Verfügung. Für mein Notebook konnte ich eine UEFI-Shell von der Internetseite des Herstellers herunterladen (dort, wo auch die UEFI-Aktualisierungen zur Verfügung gestellt wurden).

Inwieweit Du mit Deiner Systemplatine auch eine "beliebige" UEFI-Shell verwenden kannst, hängt von der "spezifikationstreue" des, auf Deiner Systemplatine verbauten, UEFIs ab.

Viele Grüße

susejunky

 

[josef-wien]

um die erforderliche Bootloader-Datei (z.B. grubx64.efi) zu erstellen

Na ja, warum soll man es einfach machen, wenn es auch kompliziert (und offenbar fehleranfällig) geht? Wenigstens schließe ich jetzt ein Hardware-Problem aus.

 

[susejunky]

Hallo josef-wien,

... Na ja, warum soll man es einfach machen, wenn es auch kompliziert (und offenbar fehleranfällig) geht?

An der Vorgehensweise, den Bootloader erst bei der Installation individuelle für die vorliegende Umgebung zu erstellen, kann ich nichts Negatives erkennen.

Auf meinem Desktop (2014, MSI-Systemplatine, secureboot abgeschaltet) lässt sich grubx64.efi problemlos zum Systemstart verwenden und das bereits seit mehreren Jahren. Diese Aussage bezieht sich sowohl auf die mit openSUSEs grub2-install, als auch auf die von mir "manuell" erstellten (aus den git-Quellen) grubx64.efi-Dateien.

... Wenigstens schließe ich jetzt ein Hardware-Problem aus.

Wenn "Hardware" jegliche Art von Firmware ausschließt, dann ist das auch meine Vermutung.

Was die UEFI-Firmware auf Christinas Systemplatine und/oder deren aktuelle Konfiguration anbelangt, bin ich mir da nicht sicher.

Viele Grüße

susejunky