Debian auf UEFI - GPT, MBR, BIOS, Grub, Secure Boot, Win 8

[Bachsau]

Ein reines EFI kann per Spezifikation nur mit GPT-Partitionen umgehen und startet einen Bootloader, der in einer FAT-Partition als Datei hinterlegt ist.

Falsch. Die Spezifikation schreibt vor, dass EFI auch von MBR-Partitionierten Datenträgen booten können muss. Zu diesem Zweck wird aber nicht der MBR-Benutzt, sondern ebenfalls eine darauf angelegte FAT-Partition, für die sogar eine eigene Partitionskennung festgelegt wurde, und die den EFI-Bootloader enthält.

[maledora4]

Wer lesen kann, ist klar im Vorteil.
Ich kann nicht erkennen, was bei NAB falsch sein soll. Er schreibt genau das, was Du versuchst richtig zu
stellen.

http://de.wikipedia.org/wiki/UEFI
http://de.wikipedia.org/wiki/GPT-Partition
http://feitel.indeedgeek.de/2012/10/mbr_vs_efi/

[Celica]

Hallo,

zunächst einmal herzlichen Dank für die super Zusammenfassung.

Ich bin gerade dabei meinen neuen Rechner (s. hier: http://debianforum.de/forum/viewtopic.php?f=15&t=146271 ) zusammen zu bauen und stehe somit am WE (wenn nicht`s dazwischen kommt vor der Installaation von Wheezy.
Das Thema UEFI und Secure Boot hat mit schon bei der Auswahl des Mainboards beschäftigt und Nerven gekostet.

Ich habe mich also nun für das ASUS P8Z77-V LX entschieden was naturgemäß mit einem UEFI kommt, aber wohl (ich werde es erfahren) ohne Secure Boot (was sich aber hätte wohl auch abschalten lassen).

Nun gehe ich davon aus, dass Wheezy mittlerweile in der Lage ist eine Installation unter UEFI zu bewerkstelligen.

Da lediglich nur ein Betriebssystem auf meinem Rechner installiert wird und das ausschließlich Debian sein wird, stelle ich mir eigentlich den einfachsten Fall einer Linux Installation vor.

Habe ich richtig verstanden das wenn ich (U)EFI einsetzen möchte und das ohne den BIOS-Kompatibilitätsmodus, dann muss ich zwingend eine GPT-Partition verwenden.

Ich rate jedoch, wenn man sich für GPT entscheidet, am Anfang zwei Partitionen extra unterzubringen. Eine 1024 KB Partition für Grub, wie unter "Squeeze" beschrieben. Und eine 250 MB FAT Partition für EFI-Bootloader. Wenn ihr beide habt, könnt ihr später ohne viel Ärger zwischen EFI-Boot und BIOS-Boot hin- und herspringen.

In die FAT-Partition wird dann "grub-efi" installiert ?

Kann der Debian Installer überhaupt entsprechend Partitionen unter GPT erstellen ?

In meinem System wird eine SSD mit 60 GB für alles außer der /home Partition untergebracht sein. Dafür habe ich eine 1TB HDD vorgesehen. Also habe ich zwei SATA-Platten im System.

Habt Ihr hierzu noch Tips wie ich am besten die SSD Partioniern sollte (sind ja jetzt reichlich Partitionen möglich .

Mir ist auch noch nicht klar was Debian Wheezy bei der Installation machen wird.
Kann ich davon ausgehen das das der Installer sich den gangbaren Weg, (U)EFI oder aber BIOS-Boot (BIOS-Kompatibilitätsmodus) aussuchen wird und dann entsprechend alles selber bestimmt ?
Normalerweise habe ich das alles selber in die Hand genommen bei meinen früheren Installationen, sprich keine geführte Partitionierung bzw. Installation.

Was muss ich hier beachten ?
Wo sind Fallstricke bei der Installation ?

Bei dem Einfachstfall meiner Installation habe ich die Hoffnung das nicht so viele Probleme auftreten werden.

Habe ich das so grundsätzlich richtig verstanden und könnt Ihr mir noch ein paar Tips geben ?

Ich werde ein

Netzinstallations-Images (typischerweise 240–290 MB), nicht-freie CD-Images mit Firmare

verwenden, da bei dem ASUS Board das OnBoard LAN ohne freie Firmware daher kommt.
Muss ich hier noch etwas beachten ?

[JTH]

Hi,
ich habe letztens meinen Laptop aus Interesse mit reinem UEFI-Boot neu aufgesetzt. Ich habe dabei zwar das aktuelle Netinstall-Image für Testing benutzt, aber der Debian-Installer kommt mit UEFI wie du geschrieben hast schon seit Wheezy zurecht. Probleme hatte ich dabei keine.

Bei der geführten Partitionierung wird die notwendige EFI-Systempartition automatisch angelegt (mit rund 500MB – bei mir sind davon im Moment 144KB belegt). Auf dieser Partition installiert grub-efi dann einen Bootloader, mit dem die UEFI-Firmware umgehen kann. Eine weitere kleine Partition für Grub brauchst du für reines UEFI-Booten nicht.

Wenn du manuell partitionieren willst, erstellst du einfach eine EFI-Systempartition und markierst sie als Bootpartition (ist das überhaupt notwendig?). Bei mir wurde grub-efi dann automatisch richtig installiert.

Wie oben von Bachsau geschrieben ist GPT nicht umbedingt notwendig, aber es spricht doch nichts dagegen, oder? Wenn du ohne BIOS-Kompatibilitätsmodus bootest, verwendet der Installer eine GPT zum Partitionieren.

Zu Secure Boot hab ich letztens gelesen, dass Microsoft anscheinend bei für Windows zertifizierter Hardware (was die meiste Hardware wohl sein wird) sogar außer bei Tablets fordert, dass Secure Boot abschaltbar sein muss. [1] Dürfte also hoffentlich keine Probleme machen.

Die Aufteilung auf Partitionen ist Geschmackssache, ich lege meist jeweils eine für /, Swap (für Suspend-to-Disk) und /home an.

Bei der Partitionierung der SSD musst du eigentlich auch nicht mehr viel beachten, der Installer richtet Partitionen von alleine geeignet aus. noatime ist als Mount-Option aber empfehlenswert, um die Menge der Schreibzugriffe etwas zu verkleinern.

Viel Erfolg

[1] https://www.happyassassin.net/2014/01/2 ... work-then/

[Bachsau]

Generell würde ich aber immer dazu raten, die Partitions-Struktur vorher anzulegen, z.B. mit Gparted Live. Bei den Installern weiß man nie, womit man es zu tun bekommt und was sie bieten. Deshalb mache ich meine Layouts lieber selbst.

Tatsächlich sollte es auch möglich sein, einen EFI-Boot von einer MBR-Partitionierten Platte durchzuführen, wobei dann auch in dieser Strukter eine EFI-Systempartition mit Typecode 0xEF anzulegen wäre. Ob das sinnvoll ist, sei mal dahin gestellt. Ich werde bei der neuinstallation meines Netbooks im April den umgekehrten Weg wählen, und das BIOS von einer GPT booten lassen.

Kann ich davon ausgehen, dass der Installer sich den gangbaren Weg, (U)EFI oder aber BIOS-Boot (BIOS-Kompatibilitätsmodus) aussuchen wird?

Du kannst davon ausgehen, dass er den Weg wählt, mit dem er selbst aufgerufen wurde. Wenn du die Installations-DVD im EFI-Modus startest, wird es eine EFI-Installation. Im anderen Fall eine BIOS-Installation. Das solltest du in deinem Setup-Tool vorher richtig einstellen, wobei ich persönlich auf veraltete Emulationen verzichten würde. Ich habe neulich auf einem BIOS-System mit EFI-Emulation einen WHS 2011 installiert. Das ging ziemlich perfekt.

[Lohengrin]

b) BIOS-Boot von GPT
Die GPT enthält als ersten Sektor noch immer einen MBR. Im MBR steht ein winziger Bootloader und die Partitionstabelle ... eh ... nein ... die Partitionstabelle steht jetzt ja am Anfang der GPT. Der MBR der GTP enthält trotzdem noch eine Partitionstabelle ... diese enthält genau eine einzige Partition, die den gesamten Rest aller GPT-Partitionen einschließt. Das dient zum Schutz der GTP, dementsprechend heißt dieser MBR in der GPT auch "protective MBR". Aber egal ... was uns ja interessiert ist das Booten ... und das geht wie bisher auch ... der MBR wird gelesen, der Bootloader ausgeführt und lädt im Fall von Grub hoffentlich die Stage 2 und alles läuft wie gewohnt weiter.

c) BIOS-Boot vom MBR
Auch das ist mit EFI im BIOS-Kompatibilitätsmodus problemlos möglich. Ob MBR oder GTP, das hat ja nicht das EFI zu entscheiden, sondern euer Partitionierungsprogramm. Und das geht wie gewohnt ... der MBR wird gestartet, denn Grub ... alles beim Alten.

Wo ist der Unterschied zwischen den beiden? Ich verstehe es einfach nicht.

Der erste Block der Festplatte ist der MBR. Wenn auf der Platte GPT ist, dann ist der MBR der protective MBR vom GPT.
Bei Bios-Boot liegt der Stage1 von Grub im MBR. Dann kommt noch ein Stage1_5, der weiß, wie das Dateisystem, auf dem Stage2 von Grub liegt, zu lesen ist. Und dann wird Stage2 von Grub geladen.

Der Stage1 kann auch am Anfang einer Partition liegen. Wenn man von einem Grub Stage2 aus Chainloader auf diese Partition macht, wird ein anderer Grub geladen. Ist b) das Laden eines Grub, wo dessen Stage1 am Anfang einer GPT-Partition ist?

[Bachsau]

Nein, "c" beschreibt den althergebrachten Startvorgang auf einem normalen MBR, "b" beschreibt wie GRUB auf einem normalen BIOS-Rechner den Boot von einer GPT partitionierten Platte regelt. Im Prinzip besteht dabei kein Unterschied im Ablauf des Bootvorgangs, außer dass die Stage1_5 bei GPT-Platten in einer eigenen Partition abgelegt wird, da der sonst freie Bereich direkt hinter dem MBR hier für die GPT verwendet wird.

Ich glaube NAB wollte mit seinem Beitrag nur verdeutlichen, dass GPT nicht vom BIOS unterstützt werden muss, um davon starten zu können. Es lädt einfach nur die ersten 512 Bytes der Festplatte in den Speicher, und führt sie aus. Wenn der darin enthaltene Code, in diesem Fall GRUB Stage1, dann die GPT lesen kann, ist alles in Ordnung.

Ein EFI-System dagegen benutzt diese ersten Bytes der Platte überhaupt nicht zum Start, sondern liest die Startsequenz (bei GRUB die Stage1) aus einer Datei auf einer speziellen FAT32-Partition. Diese Partition kann sich sowohl auf einer mit GPT, als auch einer mit MBR partitioniertem Platte befinden. Eine Stage 1_5 entfällt.

[Lohengrin]

Ein EFI-System dagegen benutzt diese ersten Bytes der Platte überhaupt nicht zum Start, sondern liest die Startsequenz (bei GRUB die Stage1) aus einer Datei auf einer speziellen FAT32-Partition. Diese Partition kann sich sowohl auf einer mit GPT, als auch einer mit MBR partitioniertem Platte befinden. Eine Stage 1_5 entfällt.

Funktioniert das Folgende?
Man nehme ein Mainboard mit EFI und BIOS-Kompatibilitätsmodul, eine Festplatte mit altlastiger Partitionierung, auf einer Partition FAT32 und auf dieser den Stage2 unter dem Namen /EFI/boot/bootx64.efi .
Was passiert, wenn es mehr als eine Partition mit FAT32 gibt?

[Maik aus MS]

Hallo, kleine Nachfrage:

Allerdings erlaubt die GPT bis zu 128 Partitionen und Partitionsgrößen über 2GB

Muss es nicht so sein:

Allerdings erlaubt die GPT bis zu 128 Partitionen und Partitionsgrößen über 2TB

Ansonsten ein sehr guter Beitrag!! Das die Efi-Partition in FAT sein muss gefaellt mir auch nicht.

Maik

[dirk11]

Hallo, kleine Nachfrage:

Allerdings erlaubt die GPT bis zu 128 Partitionen und Partitionsgrößen über 2GB

Muss es nicht so sein:

Allerdings erlaubt die GPT bis zu 128 Partitionen und Partitionsgrößen über 2TB

Und wo genau ist jetzt ein Unterschied zwischen den beiden identischen Zitaten?

[Ozelot]

GB != TB

Erster!

O

[Bachsau]

Funktioniert das Folgende?
Man nehme ein Mainboard mit EFI und BIOS-Kompatibilitätsmodul, eine Festplatte mit altlastiger Partitionierung, auf einer Partition FAT32 und auf dieser den Stage2 unter dem Namen /EFI/boot/bootx64.efi.

Wenn du das BIOS-Kompatibilitätsmodul nutzt, brauchst du dich um all das nicht mehr zu kümmern. Dann passiert nichts anderes, als würdest du ein Board mit BIOS verwenden, deshalb heißt es ja Kompatibilitätsmodul.

Nur bei einem Umstieg auf den EFI-Boot müsstest du Grub wohl neu installieren, und dafür eine EFI-Systempartition einrichten. Ich kann keine Angaben dazu machen, was man sonst noch frickeln kann.

Was passiert, wenn es mehr als eine Partition mit FAT32 gibt?

Wie ich schon schrieb, handelt es sich nicht um irgendeine FAT32-Partition. Diese ist in der Partitionstabelle nicht als FAT32-Dateisytem gekennzeichnet sondern als EFI-Systempartition. Dass sie auf FAT32 basiert ist dabei eher ein "detail" des Standards. Der Standard erlaubt genau eine solche Partition pro Datenträger, auf der mehrere Bootloader abgelegt sein können. Udisks zeigt solche Partitionen normalerweise nicht an, und mountet sie auch nicht automatisch. Auch unter Windows ist sie versteckt. Normale FAT32-Partitionen mit irgendetwas drauf kannst du haben, soviele du willst.

Dass die Efi-Partition in FAT sein muss gefaellt mir auch nicht.

Tja, die Leute vom UEFI-Forum werden sich da schon was bei gedacht haben. FAT32 ist simpel, leicht zu implementieren, offen und kann von allen Systemen gelesen werden. Eine solche Partition ist in der Regel nur wenige MB groß, und eigentlich nicht dafür vorgesehen, dort weitere Nutzdaten abzulegen. Sie bietet die Möglichkeit mehrere Bootloader beliebiger Größe auf standardisierte Weise parallel zu verwenden. Das ist ein deutlicher Fortschritt zur Rohdaten-Speicherung von x86 Maschinencode im MBR. Was stört dich daran?

[Maik aus MS]

Ich glaube FAT32 ist nicht ganz Lizenzfrei. Mein Gedankengang war auch das man ein Dateisystem nimt was auch
die Option nur Lesen bietet. Ob das praktikabel ist weiss ich nicht. War halt nur so ein Gedanke.

Maik

[Lohengrin]

Funktioniert das Folgende?
Man nehme ein Mainboard mit EFI und BIOS-Kompatibilitätsmodul, eine Festplatte mit altlastiger Partitionierung, auf einer Partition FAT32 und auf dieser den Stage2 unter dem Namen /EFI/boot/bootx64.efi.

Wenn du das BIOS-Kompatibilitätsmodul nutzt, brauchst du dich um all das nicht mehr zu kümmern. Dann passiert nichts anderes, als würdest du ein Board mit BIOS verwenden, deshalb heißt es ja Kompatibilitätsmodul.

Ich will nur wissen, ob man EFI-Boot ohne GPT machen kann. Wie ich auf so eine verrückte Idee komme? Du hast mich auf die Idee gebracht.

Ein EFI-System dagegen benutzt diese ersten Bytes der Platte überhaupt nicht zum Start, sondern liest die Startsequenz (bei GRUB die Stage1) aus einer Datei auf einer speziellen FAT32-Partition. Diese Partition kann sich sowohl auf einer mit GPT, als auch einer mit MBR partitioniertem Platte befinden. Eine Stage 1_5 entfällt.

Übrigens Danke für deine Hilfe. Jetzt habe ich wohl verstanden, was da gespielt wird.

[dirk11]

Tja, die Leute vom UEFI-Forum werden sich da schon was bei gedacht haben. FAT32 ist simpel, leicht zu implementieren, offen und kann von allen Systemen gelesen werden.

Das einzige, woran die dabei gedacht haben dürften, ist ihr persönlicher Geldbeutel, in dem das Bakshish verschwunden ist. FAT32 ist weder lizenzfrei noch simpel noch leichter als andere zu implementieren. Und nein, es kann auch nicht von allen Systemen gelesen werden.
Zitat:
"In the EFI FAT32 specification[21] Microsoft specifically grants a number of rights, which many readers have interpreted as permitting operating system vendors to implement FAT."
Die haben ein paar Rechte abgegeben, damit es implementiert wird. Schlauer Zug.

[smutbert]

Funktioniert das Folgende?
Man nehme ein Mainboard mit EFI und BIOS-Kompatibilitätsmodul, eine Festplatte mit altlastiger Partitionierung, auf einer Partition FAT32 und auf dieser den Stage2 unter dem Namen /EFI/boot/bootx64.efi.

So oder ähnlich funktioniert das tatsächlich gelegentlich. Wie sich das System verhält hängt maßgeblich von der EFI-Implementation ab. Das BIOS-Kompatibiltätsmodul hat damit aber meistens nichts zu tun.

Bei manchen Systemen geht es gar nicht, manchmal ist es wichtig dass der Partitionstyp stimmt (ef00 für efi Systempartition) und manchmal reicht ein spezieller Pfad und Dateinname auf einem beliebigen vom EFI lesbaren Dateisystem (bei manchen Systemen kann das auch durchaus HFS+ oder NTFS sein). Ich hab mit einer handvoll Systemen mit unterschiedlichen Firmwareversionen schon einige Kombinationen dieser Verhaltensweisen erlebt…

[Bachsau]

Ich will nur wissen, ob man EFI-Boot ohne GPT machen kann. Wie ich auf so eine verrückte Idee komme? Du hast mich auf die Idee gebracht.

Sowas verrücktes würd' ich niemals tun.
Aber ja, es geht. Für einen echten EFI-Boot brauchst du nur eine FAT32-Partition mit der Kennung 0xEF, auf der du die Bootloader installieren kannst. Allerdings verstehe ich den Sinn nicht ganz: Hast du EFI, kannst du auch GPT verwenden. Es hat ja keine Nachteile. Sinnvoll ist eigentlich nur der umgekehrte Weg, GPT mit einem BIOS zu verwenden, um in den Genuss von 2+TB Platten und mehr als 4 Partitionen zu kommen.

Tatsächlich hat @smutbert Recht, dass manche Systeme noch allerlei Pfusch fressen, aber wenn man nicht ganz bescheuert ist, hält man sich an den Standard.

Ich glaube FAT32 ist nicht ganz Lizenzfrei.

De facto schon.

Mein Gedankengang war auch das man ein Dateisystem nimt was auch die Option nur Lesen bietet.

Wie meinst du das? Man kann FAT32 read-only mounten, wie jedes andere Dateisystem auch.

[smutbert]

Genau ro als Mountoption funktioniert bei (fast) jedem Dateisystem. ich habe dagegen die EFI System Partition so in der fstab:

Code: Alles auswählen

UUID=xyz	/boot/efi	vfat	noatime,dmask=077,fmask=177	0	0

Das resultiert in nur für root les- und schreibbaren Dateien, Verzeichnisse haben für root zusätzlich noch das Ausführen-Recht - ein normaler Nutzer hat auf der ESP meiner Meinung nach weder lesend und schon gar nicht schreibend etwas verloren.

[Lohengrin]

Für einen echten EFI-Boot brauchst du nur eine FAT32-Partition mit der Kennung 0xEF, auf der du die Bootloader installieren kannst.

Muss ein EFI einen alten MBR verstehen können? Wenn das EFI nur GPT kann, wird es an dem alten MBR verrecken und die Partition mit FAT32 nicht finden.

Allerdings verstehe ich den Sinn nicht ganz:

Ich auch nicht. Es ist, wie gesagt, eine verrückte Idee.

[Bachsau]

Muss ein EFI einen alten MBR verstehen können? Wenn das EFI nur GPT kann, wird es an dem alten MBR verrecken und die Partition mit FAT32 nicht finden.

Der Standard sagt ja. Ohne Kompatibilitäts-Modul ist kein Start in BIOS-Manier möglich. Die MBR-Partitionstabelle muss ein UEFI-System aber genau so verstehen können, wie eine GPT. Sonst wäre es auch reichlich zwecklos, eine Kennung für EFI-Systempartitionen im MBR-Schema zu definieren, oder?

[Lohengrin]

Sonst wäre es auch reichlich zwecklos, eine Kennung für EFI-Systempartitionen im MBR-Schema zu definieren, oder?

Stimmt. Die UEFIs haben einen EFI-Boot ohne GPT geplant. Haben die auch einen Grund genannt, warum man so etwas Verrücktes tun sollte?

Ich finde es gut, dass die 2TiB-Grenze nicht durch Frickelei sondern durch Neumachen überwunden wurde. Aber warum holt man sich dann so viele Altlasten rein?
Da ist nicht nur die Möglichkeit EFI-Boot mit altem MBR zu machen. Man wird auf FAT32 verpflichet und bei den Partitionsnamen auf UTF-16LE.

[Bachsau]

Was hat das mit Altlasten zu tun, wenn man eine gewisse Kompatibilität wahren will? Es gibt möglicherweise Fälle wo kein Bedarf an GPT besteht, die aber auf Tools angewisen sind, die damit nicht umgehen können. MBR zu implementieren dürfte auch ein vergleichsweise geringer Aufwand sein.

FAT32 ist wie schon gesagt simpel und leicht zu implementieren. Auch wenn es der persönlichen Meinung mancher Menschen widerspricht, ändert das nichts an den Fakten. Für den Zweck, ein paar Bootloader auf einer kleinen Partition zu speichern sind die meisten anderen Dateisysteme völlig Überladen, mit Features wie Rechteverwaltung, Journaling, komplexen B-Trees und Inodes. FAT32 ist klein und funktional.

UTF16 ist immer dann sinnvoll, wenn definierte Unicode-Bezeichnungen in einer Liste möglichst effizient gefunden werden sollen. Es erfüllt dann automatisch die Funktion einer Hashtable.

Ich habe wirklich keine Ahnung, was euch alle so sehr daran stört. Ihr müsst dem FAT32-System weder wichtige Daten anvertrauen, noch stellt die Speichermethode für Partitionsnamen irgendein Problem dar. Es stimmt zwar, dass Microsoft vieles an UEFI beeinflusst hat, aber deshalb ist es nicht per se schlecht. Gerade ihr Festhalten an "Altlasten" ist auch ein Grund, warum viele Menschen mit Windows sehr zufrieden sind: Wärend man bei Linux meist gezwungen ist, auf aktuellen Distributionen aktuelle Software zu verwenden, können die meisten für Windows 95 entwickelten Programme auch unter Windows 8 noch verwendet werden. So sehr ich Linux mag, könnte man sich bei der Abwärtskompatibilität von Windows noch eine Scheibe abschneiden. Allerdings ist es auch ausgerechnet Windows, welches EFI-Starts von MBR-Platten bislang nicht unterstützt.

[Lohengrin]

FAT32 ist wie schon gesagt simpel und leicht zu implementieren. Auch wenn es der persönlichen Meinung mancher Menschen widerspricht, ändert das nichts an den Fakten. Für den Zweck, ein paar Bootloader auf einer kleinen Partition zu speichern sind die meisten anderen Dateisysteme völlig Überladen, mit Features wie Rechteverwaltung, Journaling, komplexen B-Trees und Inodes. FAT32 ist klein und funktional.

Es fehlen symbolische Links. Und das Ignorieren von Groß-Klein-Schreibung ist böse.
Warum hat man nicht ext2 genommen? Ist das so viel komplizierter zu implementieren als FAT32?
Was ist eigentlich genau mit der Lizenz? Besteht die Gefahr, dass jemand, der FAT32 für UEFI benutzt, etwas an Microsoft zahlen muss?

UTF16 ist immer dann sinnvoll, wenn definierte Unicode-Bezeichnungen in einer Liste möglichst effizient gefunden werden sollen. Es erfüllt dann automatisch die Funktion einer Hashtable.

UTF-16LE kann nicht alle Unicode-Zeichen darstellen, weil es inzwischen mehr als 65536 davon gibt. Außerdem ist es keine Erweiterung von ASCII. Das effiziente Finden spielt, weil es nur wenige Partitionen gibt, keine Rolle.
Als UEFI definiert wurde, gab es schon lange UTF-8. Vllt kommt ja bald GPT Version 2 heraus, wo statt UTF-16LE UTF-8 verwendet wird.

Gerade ihr Festhalten an "Altlasten" ist auch ein Grund, warum viele Menschen mit Windows sehr zufrieden sind: Wärend man bei Linux meist gezwungen ist, auf aktuellen Distributionen aktuelle Software zu verwenden, können die meisten für Windows 95 entwickelten Programme auch unter Windows 8 noch verwendet werden.

Ich habe hier einige Spiele, die auf Windows 98 gelaufen haben, aber auf Windows XP nicht mehr laufen. Leider kriege ich es nicht hin, in Virtualbox Windows 98 laufen zu lassen.

Allerdings ist es auch ausgerechnet Windows, welches EFI-Starts von MBR-Platten bislang nicht unterstützt.

Das war zu erwarten. Ich frage mich, ob ich auf einem Computer, den ich in ein paar Jahren aus einem Supermarkt kaufe, überhaupt noch etwas anderes als Windows installieren kann. Möglicherweise kann ich da SecureBoot abschalten, aber habe kein Bios-Boot mehr und kann deshalb nicht mehr einen Debian-Installer von USB starten.

[NAB]

Da schaue ich hier noch mal rein und stelle fest, es hat sich doch noch einiges getan ...

Falsch. Die Spezifikation schreibt vor, dass EFI auch von MBR-Partitionierten Datenträgen booten können muss. Zu diesem Zweck wird aber nicht der MBR-Benutzt, sondern ebenfalls eine darauf angelegte FAT-Partition, für die sogar eine eigene Partitionskennung festgelegt wurde, und die den EFI-Bootloader enthält.

Doch, doch, damit hat Bachsau völlig recht, und meine Formulierung ist falsch (ich geb zu, das war Absicht, sonst wär der Text noch viel länger geworden).

Laut Spezifikation "sollte" es gehen. Und es gibt in der Tat einen neuen MBR-Partitionstyp "EF", in den man eine FAT-EFI-Systempartition legen können soll. Laut Spezifikation soll ein EFI dann auch ohne GPT einen EFI-Boot mit dem Loader aus dieser FAT-Partition ausführen.

Allerdings ist in der Spezifikation nur von den 4 MBR-Standard-Partitionen die Rede, die beliebten Logischen Partitionen fallen weg. Die können dem EFI allerdings auch egal sein, solange das Betriebssystem sie erkennt. Man müsste dann also eine FAT-Partition in eine der ersten drei (primären) Partitionen quetschen, was zwar von den Zahlen her noch "MBR" ist, vom Schema her aber ein "MBR mit nur drei freien Partitionen".

Das eine Problem dabei ist: niemand nutzt es. Ich kenne kein System, das auf einer MBR-Platte einen EFI-Loader installiert. Man müsste sich sowas schon per Hand basteln. Und grub-efi müsste sich dann auf einer MBR-Platte zurechtfinden können ... ich weiß nicht, ob es das kann. Ich finde dazu nur alte Erfolgsberichte mit Linux auf Apple Macs mit viel Handarbeit, und verstehe nicht, warum die überhaupt eine MBR-Partitionierung genommen haben.

Das andere Problem dabei ist: es scheint nicht (richtig) implementiert zu sein. Zumindest blenden alle EFIs, die ich bisher so ausprobiert habe (was nicht sooo viele sind) sämtliche MBR-Platten aus dem Boot-Menü aus, sobald man die CSM-Module deaktiviert. Das ändert sich auch nicht, wenn man eine EFI-Bootpartition mit EFI-Loader hinzufügt. Das mag an den individuellen Bugs der EFIs liegen, aber verlassen kann man sich darauf nicht.
Oder um mal das Arch-Wiki zu zitieren:
"It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot."
https://wiki.archlinux.org/index.php/Un ... _Partition

Und ansonsten: man gewinnt dadurch nichts. Ein MBR-System mit BIOS-Boot kann man immer an einen anderen Rechner anschließen und dort booten, egal ob es ein EFI- oder ein BIOS-System ist. Bei einem MBR-System mit EFI-Boot hat man hingegen sozusagen die Nachteile aus beiden Welten vereint: man muss mit den Einschränkungen einer MBR-Partitionierung leben und ist auf ein unterstützendes EFI-Mainboard angewiesen und das Laden anderer BIOS-Boot-Systeme kann man auch knicken.

Also wer neugierig ist, darf damit gerne herumprobieren ... wenn es klappt, kann man damit ein EFI-Boot mit MBR-Partitionierung hinbekommen. Erfolgsmeldungen bitte hier rein!

Ach und wo ich gerade mal wieder mit Windows 8 herumgespielt habe ... mit gdisk scheint es ebenfalls möglich zu sein, eine MBR-Partitionstabelle in eine GPT umzuwandeln:
https://wiki.archlinux.org/index.php/GU ... MBR_to_GPT
Das befreit einen aber nicht von der Notwendigkeit, die Partitionen zusammenzuschieben und eine neue Partition für Grub oder EFI (oder beides) anzulegen. Das scheint mir der sinnvollere Weg zu sein, um Altsysteme mit MBR EFI-fitt zu machen, statt von seinen MBR-Partitionen noch eine abzuzwacken. (Bitte vorher unbedingt Backups machen!)

Muss es nicht so sein:

Allerdings erlaubt die GPT bis zu 128 Partitionen und Partitionsgrößen über 2TB

Da hast du natürlich völlig recht! Ich habe es korrigiert

Ich rate jedoch, wenn man sich für GPT entscheidet, am Anfang zwei Partitionen extra unterzubringen. Eine 1024 KB Partition für Grub, wie unter "Squeeze" beschrieben. Und eine 250 MB FAT Partition für EFI-Bootloader. Wenn ihr beide habt, könnt ihr später ohne viel Ärger zwischen EFI-Boot und BIOS-Boot hin- und herspringen.

Den Absatz muss ich auch noch mal überarbeiten.

Zum einen sind die zwei Partitionen natürlich nur dann sinnvoll, wenn man zwischen BIOS-Boot und EFI-Boot umschalten können will, was nur dann nötig ist, wenn es mit einem von beidem irgendwelchen Ärger gibt (zum Beispiel in Multi-Boot-Umgebungen).

Zum anderen habe ich gerade ein Mainboard mit Asrock EFI hier, das sich weigert per EFI-Boot zu booten, wenn die FAT-Partition nicht die erste Partition in der GPT ist. Mit Gigabyte war das kein Problem.

Lösen lässt sich das ganze übrigens, indem man zur SuperGrub2Disk greift ... davon gibt es inzwischen sogar ein EFI-Binary, das sich mit etwas Glück direkt vom USB-Stick booten lässt. Schafft man es, sein Debian damit zu booten, reicht ein "grub-install" und der Debian-Bootloader wird in das NVRAM des Mainboards eingetragen und lässt sich fortan als "grub" starten. (Bei einer Neu-Installation passiert das automatisch, ist also nichts, worüber man sich Gedanken machen muss, wenn man nicht gerade herumbastelt.)

Inzwischen habe ich mich auch mit "efibootmgr" näher angefreundet, dank der freundlichen Ubuntu-Dokumentation:
http://wiki.ubuntuusers.de/efibootmgr
(die Man-Page sollte man trotzdem mal lesen)
Damit kann man ausdrucksvollere Namen als "grub" in das Bootmenü des Mainboards eintragen, das Bootmenü sortieren, Bootloader von unterschiedlichen Festplatten (oder USB-Sticks) eintragen, oder den zweiten Bootloader seiner Raid1-Konfiguration im EFI hinterlegen. Eigentlich müsste es damit auch möglich sein, EFI-Loader von anderen FAT-Partitionen als der EFI-Systempartition in das Bootmenü zu schreiben ... das habe ich aber noch nicht getestet, und wie üblich dürfte es darauf ankommen, ob das Mainboard mitspielt.

Dabei ist mir noch aufgefallen, dass man seine GPT-Partitionstabelle (zumindest mit gparted) genau so versauen kann, wie das früher mit dem MBR der Fall war. Legt man auf einer leeren Festplatte erst eine Partition im hinteren Bereich der Festplatte an, so ist dieses die erste Partition (logisch, es gibt ja nur eine). Legt man danach noch eine weitere Partition im vorderen Bereich an, so ist und bleibt dieses die zweite Partition. Als ich also versucht habe, ganz an den Anfang der Festplatte noch eine FAT-Partition zu quetschen, war das dann trotzdem die Xte Partition, und nicht die erste.

Eigentlich müsste es leicht sein, die Partitionen umzunummerieren, aber ich habe kein idiotensicheres Programm dazu gefunden, und mein Risikobedürfnis war gering.

Und ganz unten an meinen Text habe ich noch einen Hinweis auf die neuen 32-Bit-UEFIs drangehängt - aber mir fehlt da selber der wirkliche Durchblick. Hat jemand Erfahrung damit, insbesondere unter Debian?

Ach, ehm ...

Ich habe hier einige Spiele, die auf Windows 98 gelaufen haben, aber auf Windows XP nicht mehr laufen. Leider kriege ich es nicht hin, in Virtualbox Windows 98 laufen zu lassen.

Guckst du mal hier:
http://ubuntuforums.org/showthread.php?t=774745
Nur dass bei kvm der Prozessor die 3D-Beschleunigung zu Fuß machen muss, aber für Virtualbox gibt's auch keine passenden 3D-Treiber.

[Lord_Carlos]

Mhh, mein windows 8.1 ist momentarn noch Legacy boot, also ohne UEFI.
Kann ich debian mit UEFI grub installieren und von da aus lagacy windows starten?