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

[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?

[Bachsau]

Wenn die Platte MBR formatiert ist, sollte es gehen. Aber das ist schon sehr speziell. An deiner Stelle würde ich einfach auch Debian auf BIOS installieren, wenn du ohnehin über GRUB booten willst. Im Prinzipt bietet dir UEFI keine Vorteile. Die andere Möglichkeit wäre, auf GPT umzuwandeln und eine Boot-Partition anzulegen. Ich schätze der Bootloader lässt sich dann mit der Systemstartreparatur einer Windows-CD installieren.

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.

Trotzdem ist es doch sinnvoller eine effiziente Methode einer ineffizienten vorzuziehen. ASCII ist wirklich eine sinnlose Altlast, noch dazu in einem Anwendungsfeld, das vorher überhaupt nicht existierte. Es wird also niemand jemals versuchen, eine UEFI-Tabelle als ASCII zu interpretieren.

[smutbert]

Sollte grundsätzlich funktionieren. Mit refit/refind ist das ja nichts besonderes und Grub sollte das genauso können.

Allerdings habe ich keine Idee, wie sich ein Legacy-Windows auf einer GPT-partitionierten Platte "fühlt". Anders herum könnte man auch auf altmodisch partitionierten Datenträgern eine EFI Systempartition anlegen und im UEFI-Modus davon starten. In der c't haben sie übrigens in einem Artikel empfohlen, falls möglich alle Betriebssysteme auf einem Rechner entweder im UEFI oder im BIOS-Modus zu starten und nicht zu mischen, auch wenn es normalerweise funktioniert.

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?

Hier läuft ein amd64-Debian perfekt auf einem 32-bittigen EFI, mit grub-efi-ia32 statt grub-efi/grub-efi-amd64. Probleme haben ältere Kernel verursacht (<3.4). Was in der Konstellation allerdings (grundsätzlich?) nicht funktioniert ist das ändern der EFI-Variablen, zB das Erstellen von Booteinträge.

[Bachsau]

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.

Ich würde sagen, das ist so gewollt und auch gut so, damit eine einmal angelegte Partition ihre Kennung behält. Abgesehen davon, dass es deinen Ordnungssinn stört, kann ich da keine Sauerei erkennen. Probleme gibt es auch nicht. Eine Partition wird von Block bis Block definiert. Ihre Nummer kommt aber aus dem Eintrag in der Partitions-Tabelle. Wenn es dich aber dennoch so stört, kannst du das mit gdisk ganz einfach wieder sortieren lassen.

Allerdings habe ich keine Idee, wie sich ein Legacy-Windows auf einer GPT-partitionierten Platte "fühlt".

Das geht definitiv nicht, weil der BIOS-Loader von Windows GPT nicht lesen kann. Wenn er das durchziehen will, muss die Platte auf jeden Fall beim MBR-Schema bleiben. GRUB2 kann auch alles mögliche emulieren oder man kann auf eine hybride Tabelle setzen. Das ist aber alles mehr Gefrickel als es wert ist.

[JuergenPB]

Ich habe einen Rechner aus dem Supermarkt (HP Pavilion 500-319ng). Es war ein Windows 8.1 vorinstalliert.
Die Windowspartition habe ich zuerst einmal verkleinert (hat jetzt 39GB); zudem gibt es noch eine Partition mit „Windows RE Tools“ (1023MB) und eine mit „Recovery Image“ (13GB). Und natürlich noch eine EFI (360MB) und eine kleine Windows-Sonderpartition „msftres“ (128MB). Keine Ahnung wofür letztere gut ist.
Debian (testing) habe ich danach auf dem Rest (ca 2 TB; und 7GB swap) installiert.

Grub hat sich auch schön eingenistet, allerdings mußte ich im BIOS einmalig die Bootreihenfolge so verschieben, daß zuerst Grub startet und nicht ein Windows-Boot-Manager. - Warum der Boot-Manager heißt, wenn man damit nichts managen kann, ist mir schleierhaft.

Problem:
Jedesmal wenn ich Windows starte ist die BIOS Einstellung wieder verstellt. D.h. es startet jetzt immer sofort Windows und nicht Grub. Nach dem letzten Windowsstart verschwand gar die Auswahl des Grub aus der Bootreihenfolge ganz. — Wann lernt Micro$oft eigentlich, daß es Anwender gibt, die selbst entscheiden wollen, was laufen soll?
Ich habe mir dann notgedrungen ein Reparaturprogramm (boot repair disk) aus dem Netz gefischt, das mir dann Grub repariert hat.

In jedem Fall ist das ärgerlich.

[Bachsau]

Diese verpfuschten Supermarkt-Rechner würde ich ohnehin erstmal komplett platt machen und selbst neu einrichten. Erst Windows, dann Linux. Wenn Windows immer wieder als Standard eingestellt wird, prüf mal im Setup, ob du Schreibzugriffe auf den NVRAM blockieren kannst. Vielleicht kannst du auch bei Windows in den Systemeigenschaften was umstellen.

Die msftres ist komplett überflüssig. Microsoft reserviert sich hier Speicher "für zukünftigen Gebrauch", wofür wissen sie offensichtlich selbst noch nicht. Die Partition ist leer. 7 GB Swap ist übrigens maßlos übertrieben. Mehr als 4 GB macht eigentlich keinen Sinn, egal wieviel RAM du hast.

Warum der Boot-Manager heißt, wenn man damit nichts managen kann, ist mir schleierhaft.

Kann man schon, aber nur Microsoft-Systeme. Was anderes gibt es ja in deren Augen auch nicht. Er kann "sogar" Chainloading, wenn du genug frickelst.

[JuergenPB]

Diese verpfuschten Supermarkt-Rechner würde ich ohnehin erstmal komplett platt machen und selbst neu einrichten. Erst Windows, dann Linux. Wenn Windows immer wieder als Standard eingestellt wird, prüf mal im Setup, ob du Schreibzugriffe auf den NVRAM blockieren kannst. Vielleicht kannst du auch bei Windows in den Systemeigenschaften was umstellen.

Wenn der Computer mit einer Windows-Installations-CD/DVD ausgeliefert worden wäre, hätte ich das vermutlich auch so gemacht. Es wurden aber gar keine Datenträger mitgeliefert. Um Windows also nicht ganz wegzuwerfen oder anzufangen irgendwelche .iso zu basteln, habe ich es drauf gelassen.
Windows brauche ich derzeit für genau zwei Anwendungen: Elster-Formular (das soll aber inzwischen auch unter wine halbwegs laufen) und meinen Negativ-/Diascanner. Für letzteren kann ich allerdings auch das Windows 8.1 nicht gebrauchen… das läuft nur unter XP, wie ich inzwischen weiß.
Ich will mal schauen, ob die Programme nicht auch in einer Virtual-Box laufen. Wenn ja, dann kann das Windows wirklich in die Tonne.

Im Setup kann man nichts dergleichen einstellen. Und Windows 8.1 ist für mich ein Buch mit sieben Siegeln. Dagegen waren XP und alle seine Vorgänger einfach und übersichtlich. (Die Nachfolger von XP habe ich nicht näher kennengelernt.)

Die msftres ist komplett überflüssig. Microsoft reserviert sich hier Speicher "für zukünftigen Gebrauch", wofür wissen sie offensichtlich selbst noch nicht. Die Partition ist leer. 7 GB Swap ist übrigens maßlos übertrieben. Mehr als 4 GB macht eigentlich keinen Sinn, egal wieviel RAM du hast.

Wer ich mir für's nächste Mal merken. — Aber frisst ja kein Brot.

[NAB]

Ich würde sagen, das ist so gewollt und auch gut so, damit eine einmal angelegte Partition ihre Kennung behält. Abgesehen davon, dass es deinen Ordnungssinn stört, kann ich da keine Sauerei erkennen. Probleme gibt es auch nicht. Eine Partition wird von Block bis Block definiert. Ihre Nummer kommt aber aus dem Eintrag in der Partitions-Tabelle. Wenn es dich aber dennoch so stört, kannst du das mit gdisk ganz einfach wieder sortieren lassen.

Das stört nicht nur meinen Ordnungssinn, sondern auch den einiger UEFIs, wie ich kurz über deinem Zitat schrieb:

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.

Das kommt genau dann zum Tragen, wenn man nachträglich noch eine FAT-Partition in die GTP quetschen will, für den EFI-Loader, und die Partition dann ganz am Anfang ist, aber trotzdem nicht die erste.

Danke für den Tipp mit gdisk, das hätte ich mal vorher wissen sollen :-/

[JuergenPB]

Ich hänge hier nochmal eine Frage an. Inzwischen habe ein paar „chirurgische Eingriffe“ in die Platten-Partitionierung vorgenommen. Die Windows 8-Partitionen habe ich gelöscht; etwas hin und her geschoben so daß ich nun habe:
- sda1: EFI
- sda2: eine kleine ext4 (40GB), das hat sich beim Löschen so ergeben
- sda6: eine große ext4 (1,8TB) mit Debian
- sda3: Swap (3.95GB)
Ich war mir nicht sicher, ob es sicher gewesen wäre, die Debian-Partition um die 40GB „nach unten“ zu vergrößern. Deswegen habe ich die 40GB belassen. Da liegen nun verschiedene VirtualBox-Betriebssysteme (DOS, XP, Haiku,…) drauf.

Aber nur zur eigentlichen Frage — Auf der EFI-Partition habe ich verschiedene Verzeichnisse:

Code: Alles auswählen

-── EFI
│   ├── Boot
│   ├── debian
│   └── HP
│       ├── BIOS
│       │   ├── Current
│       │   ├── New
│       │   └── Previous
│       ├── BiosUpdate
│       ├── HP Support Framework
│       │   └── Logs
│       ├── SystemDiags
│       └── SystemRecovery
├── SYSTEM
└── System Volume Information

Es war auch noch ein /microsoft Verzeichnis da, aber das habe ich einfach mal gelöscht.

Nun befindet sich in /boot eine boot64x.efi und in /debian eine grubx64.efi.
Im BIOS habe ich „debian“ als erste Startoption angegeben.
Brauche ich überhaupt die /boot/boot64x.efi ?

Was ist mit dem Rest? Braucht man das? Ich will halt vermeiden, daß mir da irgendwas zwischenfunkt, weil der Rechner sich mit Windows verheiraten will, welches ich im geklaut habe. Zumindest das Wort „SystemRecovery“ läßt mich Schaudern.

[smutbert]

efi/boot/bootx64.efi ist der Dateiname den viele UEFI-Implementationen zum booten anbieten, wenn es entweder gar keinen UEFI-Booteintrag gibt oder wenn man das UEFI-eigene Bootmenü aufruft. Auf den Macs, die ich kenne, kann man zum Beispiel keine UEFI-Booteinträge anlegen und da ist diese Datei die einfachste Möglichkeit im UEFI-Modus zu booten.

Wenn es also einen Booteintrag gibt, der auf die efi/debian/grubx64.efi verweist, wirst du die bootx64.efi nicht brauchen, andernfalls ist die bootx64.efi womöglich eine Kopie davon und du brauchst sie. Um das zu überprüfen kannst du

Code: Alles auswählen

# efibootmgr -v

aufrufen. Existiert ein Booteintrag namens debian wurde er wohl von grub-install angelegt und verweist auf die grubx64.efi, normalerweise sieht man in der Ausgabe des Befehls sogar den Pfad zur grubx64.efi.

[JuergenPB]

Wenn es also einen Booteintrag gibt, der auf die efi/debian/grubx64.efi verweist, wirst du die bootx64.efi nicht brauchen, andernfalls ist die bootx64.eif womöglich eine Kopie davon und du brauchst sie. Um das zu überprüfen kannst du

Code: Alles auswählen

# efibootmgr -v

aufrufen. Existiert ein Booteintrag namens debian wurde er wohl von grub-install angelegt und verweist auf die grubx64.efi, normalerweise sieht man in der Ausgabe des Befehls sogar den Pfad zur grubx64.efi.

Code: Alles auswählen

BootOrder: 0000,0001,0002,0012,0003,0004,0005
Boot0000* debian        HD(1,800,b4000,1873d1d3-d345-47d2-bb58-6bcb6de0f966)File(\EFI\debian\grubx64.efi)
Boot0001* USB Floppy/CD Vendor(b6fef66f-1495-4584-a836-3492d1984a8d,0500000001)..BO
Boot0002* USB Hard Drive        Vendor(b6fef66f-1495-4584-a836-3492d1984a8d,0200000001)..BO
Boot0003* UEFI:CD/DVD Drive     BIOS(81,0,00)
Boot0004* UEFI:Removable Device BIOS(82,0,00)
Boot0005* UEFI:Network Device   BIOS(83,0,00)

Da wird der bootx64.efi gar nicht aufgeführt.

Identisch sind die beiden Dateien nicht:
bootx64.efi vom 27.04.2014 hat 1,5MB
grubx64.efi von heute hat 117kB

Ich will einfach vermeiden, daß mir da irgendein anders Programm der grub unterm Hintern wegzieht.



Nebenbei: Mein Problem mit dem Filmscanner hat sich auf traurige Weise gelöst. Er lief zu meiner Freude in der VirtualBox unter XP problemlos und dann brach am Scannerschlitten ein Nippel (den man sonst nie sieht und niemals durch die Lasche ziehen muß) ab. Damit hat er nur noch Schrottwert.