wiki-Artikel über UEFI

[jph]

Ich muss es noch mal wiederholen: ihr diskutiert teils im Kreis über Möglichkeiten und Feinheiten, die m.E. für eine Standard-Debian-Installation gem. Anleitung nicht relevant sind.

Welche Zielgruppe soll die Grafik erreichen? Den Anfänger, der sich vor einer erstmaligen Debian-Installation (die er wahrscheinlich nah am Standard durchführen wird) informieren möchte? Oder einen Experten, der sich unabhängig von einem konkreten Installationsvorhaben über alle möglichen Feinheiten informieren möchte?

@TomL, du als Urheber dieser Grafik solltest diese Pflöcke einschlagen. Du musst die Grenzen dessen, was du mit der Grafik erklären willst, setzen. Ansonsten wird sie dir immer weiter zerredet.

Edit: ich würde in der Abbildung anstelle von „EFI-Legacy“ den Begriff „EFI-CSM“ verwenden. Das ist der Begriff, den ich für den emulierten BIOS-Boot per MBR kenne. (Intel will CSM übrigens bald einstellen: https://www.heise.de/newsticker/meldung ... 90747.html. Der Artikel verwendet den bescheuerten und falschen Begriff „UEFI-BIOS“, bitte nicht nachmachen. )

[TomL]

Ich muss es noch mal wiederholen: ihr diskutiert teils im Kreis über Möglichkeiten und Feinheiten, die m.E. für eine Standard-Debian-Installation gem. Anleitung nicht relevant sind.

Ja, es wird permanent versucht, alten runtergetropften Pudding erneut an die Wand zu nageln... dabei ist doch längst alles gesagt und die Grafik als unzureichend erkannt. Ich kann aber nix dafür, dass permanent Leute beweisen müssen, dass sie es besser wissen... ...

@TomL, du als Urheber dieser Grafik solltest diese Pflöcke einschlagen. Du musst die Grenzen dessen, was du mit der Grafik erklären willst, setzen. Ansonsten wird sie dir immer weiter zerredet.

Ja, das würde ich doch gerne machen... aber ich weiss nicht wie. Das, was ich eigentlich damit aussagen wollte, habe ich doch imho deutlich beschrieben. Es hift doch aber nix, wenn die Leute nicht lesen, sondern nur ein Bild mir ihrer eigenen Erwartungshaltung abgleichen, und weil sie's damit allein nicht kapieren, dann loslegen... selbst auf die Gefahr hin Dinge zu thematisieren, die sich aus dem Text heraus eigentlich ausschließen lassen würden. Es scheint doch so sein, dass den Text keine Sau interessiert. Der einzige wirksame Pflock wäre es also, das Bild komplett zu entfernen. Und wenn ich eine Möglichkeit sehen würde, den vielen unnötigen Postings zum Bild damit nicht die Grundlage zu entziehen, hätte ich das längst gemacht.

So... Ich habe jetzt zumindest aus meinen Postings alle Verweise auf das eine Posting referenziert.... dann findet mans wenigstens nicht ohne Text.
Da, wo es zitiert wurde, kann ich es leider nicht ändern... schade....

Edit: ich würde in der Abbildung anstelle von „EFI-Legacy“ den Begriff „EFI-CSM“ verwenden.

Ich bin jetzt unsicher, ob mit "Abbildung" meine Grafik gemeint ist... aber in meiner Grafik beziehe ich mich auf die Firmware des Boards, die einmal BIOS sein kann, oder eben UEFI. Deswegen ist das auch unter den PC positioniert. Und Legacy betrachte ich lediglich als Feature von UEFI, das zumindest auf unseren betroffenen Maschinen sowohl aktiviert als auch deaktiviert werden kann. Die Details, dass es mal aktiviert ist und mal nicht und welche Auswirkung das hat, sollte eigentlich aus dem Text hervorgehen.

[Lohengrin]

Siehe UEFI Spec 2.5 S. 114f. Punkt 5.2.1:
Ein UEFI bootet dann von der durch 0xEF gekennzeichneten ESP.
ESPs sind ausdrücklich auch für MBR Partitionen definiert.

Interessant. Ich habe mir die Spec 2.7 heruntergeladen, aber wegen 2575 Seiten nicht gelesen, nur kurz reingeschaut, und meine nun Folgendes.
UEFI ohne CSM gibt zu jeder MBR-Partition, die 0xEF ist, von einem Datenträger, der nicht GPT ist, falls diese Partition Bootcode enthält, die Möglichkeit, das zu starten. Um Bootcode aus einem MBR zu starten, braucht man CSM.

[owl102]

aber ein solcher Stick startet definitiv nicht, weil er keine ESP hat.

Auf Wechseldatenträgern (wie CD, DVD, USB-Stick, ...) braucht UEFI nicht zwingend eine ESP. Steht aber auch im Wiki.

(Ansonsten würde das Debian-ISO auch gar nicht vom USB-Stick im UEFI-Modus booten, was es aber tut.)

[TomL]

aber ein solcher Stick startet definitiv nicht, weil er keine ESP hat.

Auf Wechseldatenträgern (wie CD, DVD, USB-Stick, ...) braucht UEFI nicht zwingend eine ESP. Steht aber auch im Wiki.

Das ist bezogen auf den Zusammenhang (!!!) (ich betone "Zusammenhang", ich wiederhole "Zusammenhang") meiner Aussage schlichtweg falsch. Der wird nicht starten! Ich kann kurzerhand auf meinem Debian-PC mit einem einzigen Click verhindern, dass das installierte Debian von der SSD startet.... und zwar in dem ich CSM-Legacy deaktiviere. Ab dem Moment startet der PC OHNE Abfrage sofort den eingesteckten Stick oder gar nicht, wenn ich den Stick abziehe.
Die Boot-SSD:

Code: Alles auswählen

gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present

Das bedeutet, das UEFI (Legacy disabled) sucht jetzt NUR nach einem präsenten GPT/ESP. Genau das gleich gilt für das von mir beschriebene Beispiel, mit dem der Stick aus gleichem Grund NICHT bootet... schlichtweg deshalb, weil er gar nicht gesucht wird.

(Ansonsten würde das Debian-ISO auch gar nicht vom USB-Stick im UEFI-Modus booten, was es aber tut.)

Ja, das ist ja auch selbstverständlich.... das folgende ist ein Debian-Boot-Stick... wer will, sieht einen Unterschied zur obigen SSD... aber dieser Zustand hat nix mit dem zu tun, worauf sich meine Aussage oben bezieht, in der ich für den USB-Stick GPT: present (beachte Zusammenhang!!!) ausgeschlossen habe.

Code: Alles auswählen

gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Der nächste bitte...... ... ich bin jetzt sicher, ihr wollt mich nur ärgern..... ... und ich fall auch noch drauf rein...

[Lohengrin]

aber ein solcher Stick startet definitiv nicht, weil er keine ESP hat.

Auf Wechseldatenträgern (wie CD, DVD, USB-Stick, ...) braucht UEFI nicht zwingend eine ESP. Steht aber auch im Wiki.

Im Wiki steht einerseits

Zusätzlich zu den Booteinträgen im NVRAM gibt es auch noch einen speziellen Pfad von dem normalerweise auch ohne entsprechenden Booteintrag gebootet werden kann, den sogenannten „Removable Media Path“, der auf den üblichen 64 Bit-Systemen zum Beispiel »EFI/BOOT/BOOTX64.EFI« lautet.

und andererseits steht da

"Legacy-Modus" oder "CSM" oder "MBR" in den Einstellungen der Firmware aktivieren und erhält so die Möglichkeit, auch zusätzlich von Datenträgern mit Bootcode im MBR zu booten.

Was startet denn dieser Removable Media Path? Den Bootcode aus dem MBR des Sticks?
Ist das ein Bootloader, der auf der internen Platte des Computers ist, und den Bootcode aus dem MBR des USB-Sticks aufruft, also ein Chainloader? Dann ist das zweite aus dem Wiki mindestens missverständlich, und CSM taugt nur dazu, dem zu startenden System den Zugriff auf UEFI zu verwehren.

[TomL]

Was startet denn dieser Removable Media Path? Den Bootcode aus dem MBR des Sticks?

Ich glaube, dass die Frage nicht sinnvoll ist, weil es bezogen auf USB-STicks eigentlich nur zwei primäre Möglichkeiten gibt, die auch weitestgehend immer zu gleichen Ergebnissen kommen, dd schreibt für Debian-Images MBR UND GPT, WinDiskImage schreibt für Windows-Images GPT und Protective MBR (wenn ich das mit dem Prot. MBR richtig in Erinnerung behalten habe). Nur Rufus als Exot kann auch NUR GPT schreiben, was bei UEFI unproblematisch ist, bei BIOS wird der Stick nicht booten.

Ich vermute, der Removable Media Path bezieht sich auf die Grub-Installation auf Festplatten oder SSDs zu installierender Systeme.... denn da gibts ja unzählige Möglichkeiten und Varianten, wie z.B. owl mehr als einmal erklärt hat. Ich glaube, dass das ganze Thema eigentlich keine neuen wichtige Erkenntnisse bringen kann... man sollte sich vertrauensvoll den Defaults hingeben... und lediglich bei Dual-Boot-Systemen mit einem UEFI-Board Legacy/CMS disablen. Für Single-OS-Installationen ist für den Normaluser selbst das egal.
https://wiki.debian.org/UEFI#Force_grub ... media_path

[owl102]

Was startet denn dieser Removable Media Path? Den Bootcode aus dem MBR des Sticks?

UEFI startet /EFI/BOOT/BOOTX64.EFI von der ersten (FAT32/ISO9660-)Partition.

Was dann EFI/BOOT/BOOTX64.EFI weiter macht, ist sein Bier. (In der Regel wird es aber ein Bootloader sein. Im Falle des Debian-Installations-USB-Sticks ist es Grub.)

Ist das ein Bootloader

Das ist eine EFI-Anwendung. Die kann machen was sie will. Das ist aber mit ESP genauso, man kann jede EFI-Anwendung in die ESP werfen, einen Booteintrag ins NVRAM eintragen und UEFI wird das starten, auch wenn die EFI-Anwendung TETRIS.EFI heißt.

Das war aber auch schon beim BIOS so, das hat sich auch nicht darum gekümmert, ob es einen Bootloader oder Tetris startet, es hat einfach stur-doof den Code im MBR ausgeführt.

der auf der internen Platte des Computers ist, und den Bootcode aus dem MBR des USB-Sticks aufruft, also ein Chainloader?

Man könnte auf die Idee kommen, eine EFI-Anwendung zu schreiben, die das macht. Praktisch scheitert das aber daran, daß der Bootcode im MBR 16-Bit Code ist und BIOS-Funktionen aufruft.

und CSM taugt nur dazu, dem zu startenden System den Zugriff auf UEFI zu verwehren.

CSM führt den Bootcode im MBR aus und stellt diesem Code BIOS-Funktionen zur Verfügung.

[Lohengrin]

Was startet denn dieser Removable Media Path? Den Bootcode aus dem MBR des Sticks?

UEFI startet /EFI/BOOT/BOOTX64.EFI von der ersten (FAT32/ISO9660-)Partition.

Was dann EFI/BOOT/BOOTX64.EFI weiter macht, ist sein Bier. (In der Regel wird es aber ein Bootloader sein. Im Falle des Debian-Installations-USB-Sticks ist es Grub.)

Also wird etwas geladen, das als Datei auf einer Partition des Sticks liegt. Ist diese Partition nicht die ESP auf dem Stick, um die es geht?
Muss diese Partition 0xEF sein, damit der Removable Media Path sie findet? Findet er auch MBR-Partitionen mit FAT32, wenn auf dem Stick kein GPT ist?

[owl102]

... ich bin jetzt sicher, ihr wollt mich nur ärgern.....

Nö. (Zumindest ich nicht.)

Und aus der Diskussion über deine Graphik ist die Tabelle von jph [1] entsprungen, und die würde ich in den UEFI-Artikel einbauen, sobald das Fragezeichen geklärt ist. Also war sie doch zu was gut.

[1] viewtopic.php?f=36&t=168051&start=45#p1158782

[owl102]

Also wird etwas geladen, das als Datei auf einer Partition des Sticks liegt. Ist diese Partition nicht die ESP auf dem Stick, um die es geht?

Hmmm, ich fürchte, damit hast du recht, die einzige Partition auf dem Stick ist die ESP.

Muss diese Partition 0xEF sein, damit der Removable Media Path sie findet?

Müsste ich nachlesen und ausprobieren, bevor ich (wieder) was falsches schreibe... Es ist schon einige Zeit her, daß ich die UEFI-Spezifikation überflogen habe, und die Grenze zwischen "Wissen" und "Man glaubt zu wissen" ist doch immer dünner als man denkt...

Findet er auch MBR-Partitionen mit FAT32, wenn auf dem Stick kein GPT ist?

AFAIK ja. Aber: Siehe oben.

[TomL]

Und aus der Diskussion über deine Graphik ist die Tabelle von jph [1] entsprungen, und die würde ich in den UEFI-Artikel einbauen,

Ja, absolut. In den beiden Absätzen fehlt allerdings jeweils ein Wort... und das kann entweder "ist" oder "wird" sein. Was meine ich damit? Ich wende das nur mal auf den ersten Absatz an:

Original:
Installationsmedium per BIOS oder EFI-CSM gebootet:
GRUB: in erste Sektoren (inkl. MBR) installiert

1. Variante
Installationsmedium per BIOS oder EFI-CSM gebootet:
GRUB: wird im ersten Sektoren (inkl. MBR) installiert (Aus Sicht des Installationsziels: Bootloader auf der Festplatte)

2. Variante
Installationsmedium per BIOS oder EFI-CSM gebootet:
GRUB: ist im ersten Sektoren (inkl. MBR) installiert (Aus Sicht des Installer-Mediums USB-Stick: Bootloader auf dem USB-Stick)

Und wenn die Tabelle alle 4 Aussagen einzeln enthielte, stimmt sie inhaltlich mit der Grafik überein.... aber das ist imho nicht notwendig. Mit der jetzigen Formulierung müsste ich allerdings raten, was gemeint ist.

[Lohengrin]

1. Variante
Installationsmedium per BIOS oder EFI-CSM gebootet:
GRUB: wird im ersten Sektoren (inkl. MBR) installiert (Bootloader auf der Festplatte)

2. Variante
Installationsmedium per BIOS oder EFI-CSM gebootet:
GRUB: ist im ersten Sektoren (inkl. MBR) installiert (Bootloader auf dem USB-Stick)

Ich schlage vor stattdessen, wenn es mehrdeutig wird, Installer-MBR und Ziel-MBR zu verwenden.

[jph]

Ja, absolut. In den beiden Absätzen fehlt allerdings jeweils ein Wort... und das kann entweder "ist" oder "wird" sein.

Das kann ich aufklären: da gehört ein „wird“ hin. Diese Tabelle soll zeigen, wie der Debian-Installer GRUB installiert. Genau so sind auch die Angaben zum Partitionierungsschema zu verstehen: Debian-Installer wird eine DOS-Partitionstabelle einrichten etc.

Was da vorher gewesen sein mag, wird vom Debian-Installer ignoriert und überschrieben, wenn man – und das war meine Annahme – bei einer Standardinstallation gemäß Anleitung „gesamte Festplatte verwenden“ auswählt.

Gute Nacht!

[Lohengrin]

Nur Rufus als Exot kann auch NUR GPT schreiben, was bei UEFI unproblematisch ist, bei BIOS wird der Stick nicht booten.

Der lässt den MBR weg, schreibt also das, was nach LBA 1 gehört, nach LBA 0 ?
Das wäre gegen den Standard, braucht UEFI gemäß Spec nicht zu verstehen. Wenn es UEFI trotzdem versteht, hat man Glück gehabt.

[owl102]

Installationsmedium per BIOS oder EFI-CSM gebootet:
GRUB: in erste Sektoren (inkl. MBR) installiert
Partitionierung < 2 TB: DOS
Partitionierung > 2 TB: ?

Ich bin endlich dazu gekommen, das mit einer 8TB-Platte auszuprobieren, Das Ergebnis war wenig überraschend:

Installationsmedium per BIOS oder EFI-CSM gebootet:
GRUB: in erste Sektoren (inkl. MBR) installiert
Partitionierung < 2 TB: DOS
Partitionierung > 2 TB: GPT mit Protective MBR

[atarixle]

Danke für diesen Artikel.
Er ist zwar einige Debian-Versionen alt, aber dennoch wahrlich interessant und erleuchtend.

Auch beantwortet er mir Fragen, die mir eines meiner Laptops aufgeworfen hatte.

Apple's MacBook1,1 zum Beispiel zeigt mir niemals das installierte debian an. Und mein HP Elitebook bootet Linux nur, wenn ich im UEFI den Boot-Pfad manuell eintrage.