verschiedene UEFI-taugliche Linux-bootloader

Hier ist die Work-in-Pogress Zone für alles Nichtallgemeine sondern Konkrete an Vorarbeiten für die kommenden UEFI-Wiki-Artikel
Forumsregeln
Alles was konkrete Vorarbeiten zu den geplanten UEFI bezogenen Wiki-Artikeln angeht und keine allgemeine Infos sondern eben genauere Arbeitsschritte, detaliertere Anleitungen, aufgetauchte Probleme, Workarounds um eben diese etc. darstellt bitte hier reinsetzen.

verschiedene UEFI-taugliche Linux-bootloader

Beitragvon Robi » Do 12. Feb 2015, 22:17

Neben Grub2 gibt es unter Linux noch eine Reihe weiterer Bootloader bzw Pre-Loader mit denen man UEFI-booten könnte.
ELILO , rEFInd , Grub(Legacy) , Gummiboot , Shim ,.......

Wir sollten sie sauber charakterisieren und ihre Eigenschaften, Vor- und Nachteile gegenüberstellen und Howtos vorstellen wie man diese Bootloader installieren und konfigurieren kann.

Auch Bootloader und Möglichkeiten speziell für CD/DVD Floppy USB ..... in dieses Thema
alles rund um Netzwerkboot machen wir etwas später seperat

Alles zu diesem Thema in diesen Thread

robi
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Re: verschiedene UEFI-taugliche Linux-bootloader

Beitragvon Robi » So 22. Feb 2015, 15:18

Test: Booten des Kernels direkt von UEFI mittels efi boot stub ohne Verwendung eines Bootmanagers

kernel zImage und bzImage können bei der Erstellung so als PE/COFF image präpariert werden und somit direkt vom UEFI startbar gemacht werden.
Dazu muss bei der Konfiguration CONFIG_EFI_STUB enabled sein, ( Bei Opensuse default)

Test:
es wurde unter Opensuse ein eigener Kernel als bzImage kompiliert. Module, Firmware, das bzImage und die system.map auf die VM kopiert, depmod ausgeführt und mittels mkinitrd eine initrd passend zum Kernel erstellt.
(Das kompilieren eines Kernels dafür ist aber gar nicht notwendig, da der default bei Opensuse verwendete vmlinuz ebenfalls funktioniert. es sollte nur mal mit einem bzImage versucht werden, das bei Opensuse so default nicht in den Paketen vorhanden ist.)

das bzImage wurde nach /boot/efi/efi/opensuse/bzImage.efi kopiert
das initrd nach /boot/efi/efi/opensuse/initrd

Booten dieses Kernels aus der UEFI Shell kein Problem
Code: Alles auswählen
Shell> fs1:
FS1:\> cd efi\opensuse
FS1:\efi\opensuse\> bzImage.efi initrd=\efi\opensuse\initrd

bootet problemlos

auch unter dem OVMF "Boot Maintenance Manager" und "Boot Options" und " Add Boot Option" eine funktionierende Konfiguration namens "kernel" zu erstellen die den Kernel dann mit dem "Boot Manager" direkt bootet, erwies sich noch relativ einfach.

allerdings sieht die Konfiguration in Linux unter dem efibootmgr schon recht kompliziert aus, und sowas dort per Hand zu erstellen, scheint ziemlich kompliziert zu werden. (Booteintrag 9)
Code: Alles auswählen
linux-emw6:~ # efibootmgr -v
BootCurrent: 0009
Timeout: 0 seconds
BootOrder: 0008,0007,0000,0001,0002,0003,0006,0004,0005,0009
Boot0000* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0001* EFI DVD/CDROM 1       ACPI(a0341d0,0)PCI(1,1)ATAPI(0,0,0)
Boot0002* EFI Floppy    ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0003* EFI Floppy 1  ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0004* EFI Hard Drive        ACPI(a0341d0,0)PCI(1,1)ATAPI(0,1,0)
Boot0005* EFI Network   ACPI(a0341d0,0)PCI(3,0)MAC(00163e624f00,1)
Boot0006* EFI Internal Shell    MM(b,900000,10fffff)
Boot0007* opensuse      HD(1,800,4e000,f890c477-ded1-4b69-bc85-0c1f307940f6)File(\EFI\opensuse\grubx64.efi)
Boot0008* opensuse-secureboot   HD(1,800,4e000,f890c477-ded1-4b69-bc85-0c1f307940f6)File(\EFI\opensuse\shim.efi)
Boot0009* kernel        ACPI(a0341d0,0)PCI(1,1)ATAPI(0,1,0)HD(1,800,4e000,f890c477-ded1-4b69-bc85-0c1f307940f6)File(\EFI\opensuse\bzImage.efi)i.n.i.t.r.d.=.\.e.f.i.\.o.p.e.n.s.u.s.e.\.i.n.i.t.r.d...


---------------------PS: EDIT-----------------------
hab jetzt doch noch herausgefunden wie das mittels efibootmgr anzulegen wäre :)

Code: Alles auswählen
efibootmgr -c -d /dev/sda -p 1 -L neuerkern -l \\EFI\\opensuse\\bzImage.efi -u initrd=\\efi\\opensuse\\initrd


Code: Alles auswählen
-c                   #neuer Eintrag anlegen
-d /dev/sda      #ist das Device das die EFI-Partition hat
-p 1                 #ist die Partitionsnummer der EFI-Partition (eventuell überflüssig wenn nur ein FAT auf der Platte)
-L  neuerkern   #Name des Booteintrages
-l  \\EFI\\opensuse\\bzImage.efi          #die zu bootende Datei, in unserem Fall der umbenannte Kernel (Achtung \\ verwenden)
-u  initrd=\\efi\\opensuse\\initrd             #die Optionen mit denen der Kernel gestarte werden soll in diesem Fall die initrd die auch auf der EFI-Partition sitzen muss. Scheinbar müssen diese im UTF-16 Format dort in die Bootvariablen geschrieben werden, desshalb die Option -u , ohne -u würden Optionen in ASCII geschrieben.

Heraus kommt dieser Booteintrag
Code: Alles auswählen
Boot000A* neuerkern     HD(1,800,4e000,f890c477-ded1-4b69-bc85-0c1f307940f6)File(\EFI\opensuse\bzImage.efi)i.n.i.t.r.d.=.\.e.f.i.\.o.p.e.n.s.u.s.e.\.i.n.i.t.r.d...
der auch problemlos funktioniert und praktischerweise auch nach dem Anlegen gleich als erster in der Reihenfolge steht.
------------END PS: EDIT---------




In der UEFI-Shell sieht es etwas anders aus allerdings nicht einfacher und es fehlen auf dem ersten Blick auch die zusätzlichen Optionen, Hier wird sowas auf dem ersten Blick also auch nicht viel einfacher.
in der UEFI-Shell zeigte sowohl "bcfg boot dump" als auch "bcfg boot dump -v" die zusätzlichen Optionen nicht mit an.
Code: Alles auswählen
Option: 00. Variable: Boot0008   
  Desc    - opensuse-secureboot
  DevPath - HD(1,GPT,F890C477-DED1-4B69-BC85-0C1F307940F6,0x800,0x4E000)/\EFI\opensuse\shim.efi
  Optional- N
Option: 01. Variable: Boot0007   
  Desc    - opensuse
  DevPath - HD(1,GPT,F890C477-DED1-4B69-BC85-0C1F307940F6,0x800,0x4E000)/\EFI\opensuse\grubx64.efi
  Optional- N
Option: 02. Variable: Boot0000   
  Desc    - EFI DVD/CDROM
  DevPath - PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
  Optional- N
Option: 03. Variable: Boot0001   
  Desc    - EFI DVD/CDROM 1
  DevPath - PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
  Optional- N
Option: 04. Variable: Boot0002   
  Desc    - EFI Floppy
  DevPath - PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
  Optional- N
Option: 05. Variable: Boot0003   
  Desc    - EFI Floppy 1
  DevPath - PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
  Optional- N
Option: 06. Variable: Boot0006   
  Desc    - EFI Internal Shell
  DevPath - MemoryMapped(0xB,0x900000,0x10FFFFF)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
  Optional- N
Option: 07. Variable: Boot0004   
  Desc    - EFI Hard Drive
  DevPath - PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
  Optional- N
Option: 08. Variable: Boot0005   
  Desc    - EFI Network
  DevPath - PciRoot(0x0)/Pci(0x3,0x0)/MAC(00163E624F00,0x1)
  Optional- N
Option: 09. Variable: Boot0009   
  Desc    - kernel
  DevPath - PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,GPT,F890C477-DED1-4B69-BC85-0C1F307940F6,0x800,0x4E000)/\EFI\opensuse\bzImage.efi
  Optional- N


das Problem mit dem Kopieren von Ausgaben der UEFI-Shell hier ins Forum habe ich derzeit so gelöst, das ich mittels Umleitung die Ausgabe der Shell-Befehle in eine Datei schreibe, und dann von Linux aus auslese und hier her kopiere. Umleitung mit Umleitungszeichen ">a"

auf der Shell
Code: Alles auswählen
Befehl >a dateiname.txt


im gebooteten Linux dann anschließen auslesen
Code: Alles auswählen
cat /boot/efi/dateiname.txt


Ist dieser Booteintrag dann einmal vorhanden braucht man nur unter /boot/efi/..... die beiden Dateien, Kernel und initrd auszutauschen, (selber Namen natürlich) und schon kann man eine andere Kernelversion direkt mittesl UEFI booten.

robi
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Re: verschiedene UEFI-taugliche Linux-bootloader

Beitragvon Robi » So 1. Mär 2015, 19:20

Test Grub-0.97

Der Quellcode von grub legacy wird schon seit langen nicht mehr gewartet und die Vewendbarkeit seit Jahren nur mit immer mehr Patches aufrechterhalten.
Es gibt massenweise Patche, auch für die Unterstützung von GPT und EFI. Unter Suse sind keine ernsthaften Bemühungen zu erkennen den alten grub UEFI-tauglich zu erhalten. Patche und Pakete in diese Richtung sind vor allem aus der Umgebung von Fedora-Redhat-CentOs zu finden.

Mein Versuch mit Hilfe von Fedora Patchen ein Paket für OS13.1 zu bauen, brachte nach vielen Stunden aber bei 64bit mehr oder weniger nur ernüchternde Erkenntnisse, und zeigte genau wo die Probleme mit diesem Code liegen. massenweise int und char* -to-pointer- ohne cast und umgekehrt, Haufenweise Assembler nur für 32Bit CPUs und und und und und. Die vorhanden Patches zum Teil untereinander nicht kompatibel und und und. Alles mehr oder weniger Schott. Nur 2 Alternativen entweder neuschreiben oder ganz vergessen.

Fazit: Möglich, das noch die eine oder andere Distibution derzeit noch einen UEFI fähigen grub legacy anbietet, eine Zukunft dafür gibt es nicht mehr. Es ist leider an der Zeit uns von unserem guten alten GRUB endgültig zu verabschieden.
Aber soweit sind wir noch lange nicht :D

Auf der unter OVMF laufenden VM mit Opensuse 13.1 (Voraussetzung /boot ist auf ext? und nicht etwa btrfs)
folgende 2 Pakete von Fedora17 downloaden grub und grub-efi
diese beide Pakete mit ark öffnen und aus dem ersten alle Dateien unterhalb /usr/share/grub/x86_64-redhat/ nach /boot/grub kopieren (eventuelle Dateien die dort eventuell von Suse sind, eiskalt überschreiben, ist ein Testmaschine)

aus der zweiten die /boot/efi/EFI/redhat/grub.efi an genau diese Stelle in unser System kopieren.

aus der ersten noch unter /usr/share/doc/grub-0.97 die menu.lst und diese unter /boot/efi/EFI/redhat/ kopieren und als grub.conf umbenennen.
Ich habe wie folgt die grub.conf geändert.
Code: Alles auswählen
default 0
timeout 8

# das geht bei fedora eventuell anders. glaube das war dort eine .gz und keine cpio ????
# gfxmenu (hd0,2)/boot/message

title openSUSE 13.1 UEFI mit grub-0.97
    root (hd0,2)
    kernel (hd0,2)/boot/vmlinuz root=/dev/sda3   resume=/dev/sda2 splash=silent quiet showopts
    initrd (hd0,2)/boot/initrd


Jetzt versuchen wir gleich mal einen Booteintrag aus Linux heraus dafür zu erstellen, wenn der nicht passt, dann können wir das booten ansonsten über die UEFI-Shell versuchen
Code: Alles auswählen
efibootmgr -c -d /dev/sda -p 1 -L grublegacy -l \\EFI\\redhat\\grub.efi


reboot und siehe da, :D :D :D
die VM kommt mit dem grub-efi-0.97 von Fedora17 wunderbar hoch. Jetzt nur noch irgendwie gfxmenu zum laufen bringen. und fertig.

robi
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Re: verschiedene UEFI-taugliche Linux-bootloader

Beitragvon Robi » Mo 2. Mär 2015, 01:23

Test elilo auf opensuse 13.1

elilo wird per default bei einer Installation auf UEFI von Suse nicht mit installiert.
Installation einfach "zypper in elilo"

Im Paket sind neben sehr dürftigen Manpages und den (einigermaßen hilfreichen) normalen Paketdokumentationen nur 3 Dateien,
das efi-binary /usr/lib64/efi/elilo.efi
und 2 Perlscripte /sbin/elilo und /sbin/eliloalt

Die Doku zeigt, es handelt sich hier durchaus um einen guten und für viele Fälle ausreichenden modernen Bootloader. Unter anderem Möglichkeit einer vernünftigen Auswahl, einer alternativen Konfiguration wenn "default" zB nach einem remote Kernelupdate mal in die Hose geht, und auch Netzwerkboot möglich, sowie auch das manulles booten möglich.

Nach dem lesen der gesamten Doku und der Suche im Netz bin ich dann auch dahinter gekommen es muss ein Konfigurationsdatei /etc/elilo.conf erstellt werden. Syntax analog dem alt bekannten lilo also meine selbst erstellte mit 2 Bootoptionen.
Code: Alles auswählen
default=kernel-org
#chooser=testmenu
#message=textmenu-message.msg

image=bzImage-3.11.10-4-desktop
        label=kernel-3.11.10
        initrd=initrd-3.11.10-4-desktop
        read-only
        root=/dev/sda3
        append="resume=/dev/sda2 splash=silent quiet showopts"

image=vmlinuz-3.11.6-4-desktop
        label=kernel-org
        initrd=initrd-3.11.6-4-desktop
        read-only
        root=/dev/sda3
        append="resume=/dev/sda2 splash=silent quiet showopts"


Als nächstes das /sbin/elilo Script versucht. Doku dazu wenig hilfreich, ein Blick in das Script, (Na ja, eigentlich ein gutes Beispiel wie man Script eigentlich nicht schreiben sollte)
erstmal als Test
elilo --refresh-EBM -v -t (Option -t = Test, also nicht scharf) prüft die Konfigdatei und zeigt in welchem Verzeichnis unter EFI dieses Script gerne arbeiten würde.
Das Ganze dann nochmal ohne "-t " macht auch nicht viel mehr, es legt nur das Verzeichnis
/boot/efi/EFI/SuSE/ an und meckert das dort das elilo.efi binary nicht vorhanden ist. :D
Also muss man das manuell dort hin kopieren.
Also kopieren und den Befehl nocheinmal. und jetzt macht dieses Script wirklich etwas und legt mittels efibootmgr einen Booteintrag für den elilo mit dem Namen "SUSE Linux Enterprise" an, :shock: :shock: :shock: :shock: :shock: :shock:
Dieser UEFI-Booteintrag wird auch gleich an die erste Stelle geschoben also versuchen wir mal einen reboot. Und dieses startet dann auch elilo.efi und sagt doch frech, keine config-Datei unter \efi\SuSE zu finden.
Spätestens an dieser Stelle habe ich mir gedacht, was das Script /sbin/elilo denn dann überhaupt für einen Sinn macht, wenn man doch alles per Hand machen muss. Wahrscheinlich würde aber dieses Script bei einem Kernelupdate ausgeführt und nen Haufen Unsinn anstellen. Mein Vorschlag ohne mit diesem Scipt weiter herumzuexperimentieren, umbenennen oder gleich löschen, sowas kann kein Mensch wirklich gebrauchen.
Also erstmal wieder booten und die /etc/elilo.conf nach /boot/efi/efi/suse/ kopieren.
und noch einmal rebooten.
:o :shock: :? :x :cry: funktioniert leider nicht, Schnell durfte ich feststellen, das Ding funktioniert zwar, aber es kann erstmal nur den Kernel und die Initrd finden, wenn diese sich in einem FAT-Dateisystem befindet. Das macht natürlich erstmal gar keinen Sinn diese sensiblen Dateien dann auch noch in ein FAT zu legen, wenn noch nicht einmal das Script in der Lage war die "elilo.conf" oder "elilo.efi" dort rüber zu kopieren, wie will ich dort meinen Kernel und vor allem meine Initrd unter Kontrolle behalten.
Also es müssen im UEFI erst noch Treiber für das Dateisystem geladen werden, damit UEFI und somit auch elilo dann den Kernel und die Initrd im ext4 (oder was auch immer) Dateisystem auch finden kann.

Testabbruch für heute.
So es geht weiter. Ein UEFI-Treiber für ext4 ist schnell gefunden der ext4 aus dem rEFInd funktioniert prächtig. (lesen ext2 + ext3 + ext4, Einschränkung ext4 < 16TB, also keine 64Bit-Filesystem-Unterstützung bei ext4)
erstmal aus der UEFI-Shell mit "load" laden. Dann muss man aber im Simple-Chooser von elilo erstmal erkunden was elilo dem Dateisystem jetzt für einen Namen zugewiesen hat. ( bei mir atapi2) Dann kann man die elilo.conf entsprechend ändern.

Meine fertige und jetzt auch funktionierende elilo.conf
Code: Alles auswählen
prompt
timeout=40
default="kernel-3.11.10"

# Konfiguration fuer den Textmenu-Chooser
#----------------------------------------
#chooser=textmenu
#message=textmenu-message.msg
#f1=general.msg
#f2=params.msg
#-----------------------------------------

image=atapi2:/boot/bzImage-3.11.10-4-desktop
        label="kernel-3.11.10"
        initrd=atapi2:/boot/initrd-3.11.10-4-desktop
        read-only
        root=/dev/sda3
        append="resume=/dev/sda2 splash=silent quiet showopts"

image=atapi2:/boot/vmlinuz-3.11.6-4-desktop
        label="kernel-org"
        initrd=atapi2:/boot/initrd-3.11.6-4-desktop
        read-only
        root=/dev/sda3
        append="resume=/dev/sda2 splash=silent quiet showopts"

Das laden des Treibers mittels UEFI-Shell ist aber langweilig und für den automatischen Betrieb wenig brauchbar, also den Treiber im UEFI-BIOS-Menu eingetragen. Startet jetzt bei jedem Boot der VM automatisch.

Per default startet nur der default Eintrag aus der Config. Man kann aber aus der Shell mit Optionen irgendwas anderes auch booten, oder auch einen Chooser starten ("elilo -p") der dann alle in der Config eingetragenen zur Auswahl stellt und auch Möglichkeiten der manuellen Eingabe von Kernel und Optionen hat. Davon gibt es 2 , den Simpel der ist sehr gewöhnungsbedürfig, der 2 ist ein Text-Menu. ähnlich dem was wir von früher von verschiedenen Booloadern kennen. benötigt ein paar Konfigurationsdateien. (deren Beispiele natürlich auch im OpenSusepaket nicht enthalten sind)

Den Alternativen Booteintrag habe ich jetzt nicht ausprobiert, das ist ehr was als Alternative für remote-Administration oder Netzboots mittels elilo.

mein Fazit für elilo:
Netter kleiner Bootloader aber nur für 08-15 Linux, Nicht nur der Name erinnert an den LILO, leider bei der Dateisystemunterstützung komplett von UEFI-Treibern abhähngig, (was in Punkto Sicherheit gleich große Löcher in den Käse boren kann,) nicht ganz einfach zu konfigurieren, für den unerfahrenen User weniger bis gar nicht zu empfehlen, Da die Eintragungen in der Config manuell erfolgen und damit praktischer Weise auch nicht den kompletten HW-Path in der Konfig eingetragen ist, wird man schnell Probleme bekommen, sobald man an der Hardware und den Partitionen rumschraubt. Das Ganze hat wenig und auch noch ehr schlechte OpenSuse Unterstützung.

robi
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Beitragvon Robi » Di 3. Mär 2015, 17:52

Test : rEFInd an Opensuse 13.1

refind kommt ursprünglich ehr aus der Mac OS X Welt ist aber für Linux genauso gut geeignet. Bei Opensuse gibt es default keine Pakete, (ein paar sind in den User-home von OBS aber auch vorhanden) braucht man aber nicht, Es reicht vollkommen das Standard-binär-paket als zip. Aktuelle Version 0.8.7 downloaden, entpacken und reinschauen. Benötigt wir zum Installieren nur das install.sh Script. die beiden anderen Scripte (eines zum konfigurieren des aktuellen Systems und eines zum verschieben der refind Dateien auf die UEFI-Partition) werden automatisch dabei mit ausgeführt, das mkrlconf.sh könnte jederzeit verwendet werden, um aus jedem enventuell sonst noch vorhanden anderen Linuxsystem auf der Kiste eine refind config Datei in das entsprechende /boot zu schreiben, bzw nach Umzug oder Plattentausch das anzupassen) damit werden dann auch die richtigen Kernelparameter verwendet wenn man nur den nackten Kernel zum booten in refind bootet. Beim booten eines Kernels hat man dann damit auch über F2 noch zusätzlich die Auswahl auch in den SingleUserMode uÄ. zu booten.

install.sh ausführen, und fertig. rebooten und staunen.

rEFInd sucht alles mögliche bootbare ob EFI oder MBR basierend, LinuxKernel, Windows-Bootloader und auch sonstigen UEFI-Applikatione die es finden kann. Dabei werden auch per default einige nützliche Tools gesucht und gegebenenfalls gefunden wie EFI-Shell MokManager Speichertest .....
Das alles wird dann im Bootmanager schön mit passenden Icons angezeigt und kann von dort gestartet werden. Es werden so alle möglichen Bootmanager angezeigt, die sich auf der Kiste befinen, ob nun auf einer CD/DVD irgendwo in einem der MBR einer Platte oder alle gefunden UEFI-Bootloader sowie auch Kernel die es irgendwo findet. Und das alles automatisch, ohne das man das konfigurieren müsste. Bildschirmschoner möglich, Icons für reboot und ausschalten und BIOS-Setup .... Ein echter Überflieger wenn man viele Bootloader im System hat, oder sonstwie die Überblick verloren hat wie man alles seine Systeme starten kann.

Mit der Konfigurationsdatei refind.conf kann man das Aussehen und die Funktionen gegebenenfalls auch noch anpassen.
refind bringt einige an UEFI-Treibern für unterschiedlliche Dateisysteme mit (ext2 ext4 btrfs hfs iso9660 ntfs reiserfs), bei mir hat er nur ext4 installiert, die anderen lassen sich aber jederzeit auch manuell in das entsprechende drivers Verzeichnis kopieren und werden dann auch automatisch von refind gefunden, (mit der Konfigdatei ließen sich auch andere Verzeichnisse mit Treibern noch durchsuchen lassen)

Fazit nach etwas Rumspielerei:
Idealer Bootloader für jemanden der viele Bootloader und sonstige EFI-Applikationen auf dem System hat. unkomplizierte Installation und keine Konfiguration notwendig. Geeignet ( aber von mir noch nicht getestet, die ganzen Secureboot und KEY Problemematiken und Tests kommen später) auch in Verbindung mit Windows und Secureboot.

robi
Zuletzt geändert von Robi am Do 14. Mai 2015, 00:48, insgesamt 2-mal geändert.
Robi
 
Beiträge: 68
Themen: 10
Registriert: So 15. Feb 2015, 16:02

Re: verschiedene UEFI-taugliche Linux-bootloader

Beitragvon gehrke » Mi 6. Mai 2015, 07:20

Ein paar erste HInweise zu GRUB2/EFI:

Unter OpenSUSE wird der Loader bei der Installation des OS und bei späterer Konfiguration durch den User (entweder manuell oder via YAST) über das Shell-Script 'grub2-install' durchgeführt, welches als einfache Textdatei eingesehen werden kann.
Da wird zum einen der erste Teil des Loaders im EFI-Format auf die ESP geschrieben. Hierzu wird das Binary 'grub2-mkimage' verwendet, wofür es auch eine manpage gibt.
Zum anderen wird hier auch der EFI-BootManager via 'efibootmgr' entsprechend parametrisiert.
http://www.youtube.com/watch?v=PpUrMk3g_og (Angriff auf die Freiheit von Ilija Trojanow / Juli Zeh) - let’s encrypt
Benutzeravatar
gehrke
 
Beiträge: 118
Themen: 1
Registriert: Mo 23. Dez 2013, 21:53


Zurück zu Workspace

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron