Fragen zu GPT - Grub - Grub2 - EFI

[Karl Heinz]

Hallo,

auf einem Detachable habe ich Android in der x86 Variante in einer Virtual-Box installiert. Die Installation hat einwandfrei funktioniert, wirft allerdings ein paar Fragen auf. Es wäre prima, wenn Ihr mir hier kurz weiterhelfen würdet.

• Bevor ich mit der eigentlichen Installation beginnen kann wähle ich "Create/Modify partitions" im Bootmenü des ISO-Images. Hier kommt dann zunächst die Frage: "Do you want to use GPT". Damit ist wohl die GUID-Partitionstabelle gemeint siehe hier: https://de.wikipedia.org/wiki/GUID_Partition_Table. Diese Partitionstabelle kann ich aber nicht in den Zusammenhang mit "Create/Modify partitions" bringen. Zum Erstellen und/oder modifizieren von Partitionen ist eine Partitionstabelle doch nicht relevant, diese wird doch auf den jeweiligen Partitionen erstellt. Wie sollte ich demnach die Frage "Dou want to use GPT" beantworten und warum?

• Nachdem ich nun eine Partition über "Create/Modify partitions" erstellt habe werde ich folgendes gefragt: "Do you want to install Grub?" Ist wohl der Bootloader, habe "Ja" angelickt sonst wäre das System ja nicht in der Lage zu booten. Ist das so richtig erklärt.

• Nachdem ich die Frage "Do you want to install Grub?" mit "Ja" beantwortet habe kommt folgende Frage: "Do you want to install EFI/Grub2? Hier verstehe ich nicht was gemeint ist. Erst werde ich nach Grub und dann nach Grub2 gefragt. Sollte ich hier auch mit ja bestätigen? Falls ja wären ja zwei Bootloader installiert (Grub und Grub2). Das macht doch eigentlich keinen Sinn oder? Entweder Grub oder Grub2 beides ist doch eigentlich quatsch bzw. garnicht möglich. Laut Installtionsumgebung kann man aber beides intallieren, Grub und Grub2.

• Was ist mit dem EFI vor Grub2 gemeint. EFI ist ja sozusagen ein erweitertes BIOS hat aber nichts mit dem Bootloader sprich Grub2 zu tun. In dem Kontext die Frage was der Präfix EFI vor Grub2 zu bedeuten hat?

[Der Martin]

Moin,

auf einem Detachable habe ich Android in der x86 Variante in einer Virtual-Box installiert.

ich habe mal gehört, dass es auch ein Android für x86 gibt, kenne es aber nicht wirklich. Ich hoffe, dass du keine spezifischen Fragen dazu hast. ;-)

• Bevor ich mit der eigentlichen Installation beginnen kann wähle ich "Create/Modify partitions" im Bootmenü des ISO-Images. Hier kommt dann zunächst die Frage: "Do you want to use GPT". Damit ist wohl die GUID-Partitionstabelle gemeint siehe hier: https://de.wikipedia.org/wiki/GUID_Partition_Table.

Ja, richtig.

Diese Partitionstabelle kann ich aber nicht in den Zusammenhang mit "Create/Modify partitions" bringen. Zum Erstellen und/oder modifizieren von Partitionen ist eine Partitionstabelle doch nicht relevant, diese wird doch auf den jeweiligen Partitionen erstellt.

Nein. Die Partitionstabelle ist ja quasi das Master-Inhaltsverzeichnis des Datenträgers, eine Liste der Partitionen darauf mit ihren wesentlichen Eckdaten (Partitionstyp, Startsektor, Endsektor, woraus sich dann die Größe ergibt). Man muss sich daher ganz zu Beginn, wenn man eine jungfräuliche Platte zum ersten Mal partitioniert, für eines der beiden Schemata entscheiden. Entweder das alte Format (meist als "MSDOS" oder so bezeichnet, weil es mit DOS damals eingeführt wurde), oder das neue GPT. Worin die Vorteile von GPT liegen, habe ich bis heute nicht verstanden; ich nutze daher aus Tradition immer noch das MS-DOS-Partitionsschema. Der einzige mir bekannte Vorteil von GPT ist die Unterstützung von Festplatten jenseits von 2TB, was mit dem alten MBR-Konzept nicht mehr geht. So große Platten hatte ich aber noch nicht ...

Wie sollte ich demnach die Frage "Dou want to use GPT" beantworten und warum?

Gute Frage. Ich persönlich würde mit Nein antworten, weiß aber nicht, ob mir damit nicht irgendwelche Vorzüge entgehen.

• Nachdem ich nun eine Partition über "Create/Modify partitions" erstellt habe werde ich folgendes gefragt: "Do you want to install Grub?" Ist wohl der Bootloader, habe "Ja" angelickt sonst wäre das System ja nicht in der Lage zu booten. Ist das so richtig erklärt.

Ja.

• Nachdem ich die Frage "Do you want to install Grub?" mit "Ja" beantwortet habe kommt folgende Frage: "Do you want to install EFI/Grub2? Hier verstehe ich nicht was gemeint ist. Erst werde ich nach Grub und dann nach Grub2 gefragt. Sollte ich hier auch mit ja bestätigen?

Wenn du Partitionen im GPT-Format angelegt hast, AFAIK ja. GRUB ohne EFI-Unterstützung kann nicht von Platten mit GPT booten.

Falls ja wären ja zwei Bootloader installiert (Grub und Grub2). Das macht doch eigentlich keinen Sinn oder? Entweder Grub oder Grub2 beides ist doch eigentlich quatsch bzw. garnicht möglich. Laut Installtionsumgebung kann man aber beides intallieren, Grub und Grub2.

Ich vermute, das ist ein Missverständnis, bin mir da aber auch nicht sicher. Ich nehme an, dass die erste Frage nach GRUB eher allgemein gemeint war (ob überhaupt), und die zweite Frage spezifisch auf die EFI/GPT-taugliche Variante.

• Was ist mit dem EFI vor Grub2 gemeint. EFI ist ja sozusagen ein erweitertes BIOS hat aber nichts mit dem Bootloader sprich Grub2 zu tun. In dem Kontext die Frage was der Präfix EFI vor Grub2 zu bedeuten hat?

Ein EFI-BIOS enthält selbst eine Art Bootloader bzw. kann mit einem softwaremäßig installierten Bootloader kooperieren. Dazu braucht man dann neben dem EFI-BIOS eine GPT-Partitionierung und den GRUB in der EFI-kompatiblen Variante.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

Entweder das alte Format (meist als "MSDOS" oder so bezeichnet, weil es mit DOS damals eingeführt wurde),

Viel geläufiger sind die Bezeichnungen Bios-Schema oder MBR.

oder das neue GPT. Worin die Vorteile von GPT liegen, habe ich bis heute nicht verstanden; ich nutze daher aus Tradition immer noch das MS-DOS-Partitionsschema. Der einzige mir bekannte Vorteil von GPT ist die Unterstützung von Festplatten jenseits von 2TB, was mit dem alten MBR-Konzept nicht mehr geht. So große Platten hatte ich aber noch nicht ...

• unbegrenzt viele Partitionen (naja, außer man benutzt Windows, dann nur 128)
• eindeutige Adressierbarkeit über GUIDs, egal an welchem Port die Platte hängt (/dev/sda1 vs /dev/sdb1 wenn man die Platte an den zweiten SATA-Port hängt, z.B.)
• 64 Bit für die Adressierung und damit Tabellen über fast 10 Zetabyte
• Redundanz: GUID hat eine Backup-Tabelle, falls durch bit rot die erste kaputt geht
• Prüfsummen für die Tabelle
• im Gegensatz zu MBR standardisiert (MBR ist ein De-Facto-Standard)
• Versioniert
• benennbare Partitionen (36 Zeichen)

• Nachdem ich die Frage "Do you want to install Grub?" mit "Ja" beantwortet habe kommt folgende Frage: "Do you want to install EFI/Grub2? Hier verstehe ich nicht was gemeint ist. Erst werde ich nach Grub und dann nach Grub2 gefragt. Sollte ich hier auch mit ja bestätigen?

Wenn du Partitionen im GPT-Format angelegt hast, AFAIK ja. GRUB ohne EFI-Unterstützung kann nicht von Platten mit GPT booten.

Das stimmt nicht, aber EFI ist empfehlenswert: einerseits ist BIOS eine aussterbende Technologie und andererseits ist die BIOS-Emulation nicht immer bugfrei. Mit EFI ist insgesamt weniger Probleme zu erwarten.

Falls ja wären ja zwei Bootloader installiert (Grub und Grub2). Das macht doch eigentlich keinen Sinn oder? Entweder Grub oder Grub2 beides ist doch eigentlich quatsch bzw. garnicht möglich. Laut Installtionsumgebung kann man aber beides intallieren, Grub und Grub2.

Ich vermute, das ist ein Missverständnis, bin mir da aber auch nicht sicher. Ich nehme an, dass die erste Frage nach GRUB eher allgemein gemeint war (ob überhaupt), und die zweite Frage spezifisch auf die EFI/GPT-taugliche Variante.

Das ist richtig, es wird hier gefragt, ob die EFI-Variante genutzt werden soll.

LG,
CK

[Der Martin]

Moin Christian,

Entweder das alte Format (meist als "MSDOS" oder so bezeichnet, weil es mit DOS damals eingeführt wurde),

Viel geläufiger sind die Bezeichnungen Bios-Schema oder MBR.

stimmt, MBR wird auch oft verwendet; die Bezeichnung BIOS-Schema ist mir dagegen noch nicht begegnet.

oder das neue GPT. Worin die Vorteile von GPT liegen, habe ich bis heute nicht verstanden;

• unbegrenzt viele Partitionen (naja, außer man benutzt Windows, dann nur 128)
• eindeutige Adressierbarkeit über GUIDs, egal an welchem Port die Platte hängt (/dev/sda1 vs /dev/sdb1 wenn man die Platte an den zweiten SATA-Port hängt, z.B.)
• 64 Bit für die Adressierung und damit Tabellen über fast 10 Zetabyte
• Redundanz: GUID hat eine Backup-Tabelle, falls durch bit rot die erste kaputt geht
• Prüfsummen für die Tabelle
• im Gegensatz zu MBR standardisiert (MBR ist ein De-Facto-Standard)
• Versioniert
• benennbare Partitionen (36 Zeichen)

Na gut, aber manches davon gilt nicht ausschließlich für GPT. Die eindeutige Adressierbarkeit über GUIDs zum Beispiel habe ich auch bei meinen MBR-partitionierten Platten (da wird die GUID vermutlich im Startsektor jeder einzelnen Partition vermerkt); auch theoretiscch unbegrenzt viele Partitionen kann man mit GPT durch das Daisy-Chaining von erweiterten Partitionen haben (ja, ist 'ne Krücke, aber trotzdem); die mögliche Größe weit über 2TB erwähnte ich ja schon.

Wenn du Partitionen im GPT-Format angelegt hast, AFAIK ja. GRUB ohne EFI-Unterstützung kann nicht von Platten mit GPT booten.

Das stimmt nicht

Okay, es geht. Wusste ich nicht, scheint mir aber auch recht umständlich zu sein.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

Die eindeutige Adressierbarkeit über GUIDs zum Beispiel habe ich auch bei meinen MBR-partitionierten Platten (da wird die GUID vermutlich im Startsektor jeder einzelnen Partition vermerkt);

Das wäre mir neu, glaube nicht, dass das stimmt; aber es gibt die Möglichkeit, einem Dateisystem eine GUID zu geben (genauer gesagt machen das moderne Dateisysteme von Haus aus).

auch theoretiscch unbegrenzt viele Partitionen kann man mit GPT durch das Daisy-Chaining von erweiterten Partitionen haben (ja, ist 'ne Krücke, aber trotzdem);

Du meinst mit MBR. Naja, das ist aber wirklich sehr theoretisch. Spätestens ab der dritten Ebene geht dann der Überblick flöten, und es wird auch immer fehleranfälliger gegen bit rot.

Wenn du Partitionen im GPT-Format angelegt hast, AFAIK ja. GRUB ohne EFI-Unterstützung kann nicht von Platten mit GPT booten.

Das stimmt nicht

Okay, es geht. Wusste ich nicht, scheint mir aber auch recht umständlich zu sein.

Geht eigentlich, idR nimmt es einem ja der Installer ab. Aber besonders sinnvoll finde ich das auch nicht.

LG,
CK

[Der Martin]

Hi,

Die eindeutige Adressierbarkeit über GUIDs zum Beispiel habe ich auch bei meinen MBR-partitionierten Platten (da wird die GUID vermutlich im Startsektor jeder einzelnen Partition vermerkt);

Das wäre mir neu, glaube nicht, dass das stimmt; aber es gibt die Möglichkeit, einem Dateisystem eine GUID zu geben (genauer gesagt machen das moderne Dateisysteme von Haus aus).

okay, wo genau diese GUID gespeichert wird, war jetzt bloß eine Mutmaßung; ich sehe aber bei meinen Mint-Installationen (und auch früher bei Ubuntu), dass nach der Installation die Partitionen in der fstab alle mit GUIDs adressiert sind. Mit Kommentaren wie etwa "/boot was on /dev/sda1 during installation".
Aber stimmt, mit diesem GUIDs werden eigentlich die Dateisysteme identifiziert, nicht die Partitionen, auch wenn das an Wortklauberei grenzt.

auch theoretiscch unbegrenzt viele Partitionen kann man mit GPT durch das Daisy-Chaining von erweiterten Partitionen haben (ja, ist 'ne Krücke, aber trotzdem);

Du meinst mit MBR.

Natürlich, sorry.

Naja, das ist aber wirklich sehr theoretisch. Spätestens ab der dritten Ebene geht dann der Überblick flöten, und es wird auch immer fehleranfälliger gegen bit rot.

Früher[tm], noch zu Zeiten von Windows 98, war ich mal ein Freund von kleinen, dafür entsprechend vielen Partitionen. Da habe ich das selbstverständlich so organisiert.

Ciao,
 Martin

[Christian Kruse]

Hallo Martin,

Aber stimmt, mit diesem GUIDs werden eigentlich die Dateisysteme identifiziert, nicht die Partitionen, auch wenn das an Wortklauberei grenzt.

Nein, das ist ein wichtiger Unterschied :) bei Partitionen mit GUIDs muss das OS nichts von dem Dateisystem wissen, um die Partition identifizieren zu können. Bei GUIDs für Dateisysteme schon. Spätestens wenn man mit mehreren Betriebssystemen arbeitet kann das wichtig werden. Ausserdem bleibt bei GPT die GUID gleich wenn man das Dateisystem ändert oder neu erstellt.

LG,
CK

[Karl Heinz]

auf einem Detachable habe ich Android in der x86 Variante in einer Virtual-Box installiert.

ich habe mal gehört, dass es auch ein Android für x86 gibt, kenne es aber nicht wirklich. Ich hoffe, dass du keine spezifischen Fragen dazu hast. ;-)

Keine spezifischen aber eine Allgemeine :-)

Auf dem Detachable möchte ich weg von Windows 10 (wie auf dem Desktop PC schon geschafft) hin zu Mint.

Problem Mint bietet keine Oberfläche die optimal für die Touchbedienung geeignet ist (Windows 10 schon im Kachelmodus). Demnach brauche ich etwas anderes für die Nutzung des Detachables ohne Tastatur (im Touch-Modus)

Die Ideallösung, eine reine Linux Lösung (Ubunutu Touch) scheidet aus, da noch zu wenig ausgereift und da es hier kaum Apps gibt.

Demnach bleibt nur Android x86 (mit Apple will ich nichts am Hut haben)

Demnach sieht meine Ideallösung wie folgt aus:

• Haut OS = Mint 18 (für die Nutzung mit Tastatur)
• Neben OS = Android x86er in einer Virtual-Box (für die Nutzung im Touch-Modus ohne Tastatur)

Meines Erachtens die optimale Lösung.

Wie seht ihr das? Stimmt Ihr mir zu?

PS: Denkt Ihr Ubunutu Touch wird auf absehbare Zeit so gut werden (vor allem bezogen auf die Anzahl der verfügbaren Apps) das es in der Praxis eine vollwertige Alternative zu Android wird?

[Der Martin]

Hallo,

Ich hoffe, dass du keine spezifischen Fragen dazu hast. ;-)

Keine spezifischen aber eine Allgemeine :-)

das könnte gerade noch klappen ...

Auf dem Detachable möchte ich weg von Windows 10 (wie auf dem Desktop PC schon geschafft) hin zu Mint.

Problem Mint bietet keine Oberfläche die optimal für die Touchbedienung geeignet ist (Windows 10 schon im Kachelmodus). Demnach brauche ich etwas anderes für die Nutzung des Detachables ohne Tastatur (im Touch-Modus)

Die Ideallösung, eine reine Linux Lösung (Ubunutu Touch) scheidet aus, da noch zu wenig ausgereift und da es hier kaum Apps gibt.

Demnach bleibt nur Android x86 (mit Apple will ich nichts am Hut haben)

Demnach sieht meine Ideallösung wie folgt aus:

• Haut OS = Mint 18 (für die Nutzung mit Tastatur)
• Neben OS = Android x86er in einer Virtual-Box (für die Nutzung im Touch-Modus ohne Tastatur)

Meines Erachtens die optimale Lösung.

Könnte sein, aber wenn Android in einer VM eingesperrt ist, kann es möglicherweise nicht auf die Touch-Hardware zugreifen. Das virtuelle System kann ja nur die Komponenten ansprechen und nutzen, die ihm das Hostsystem zur Verfügung stellt. Wenn also - nur mal als Beispiel - das Hostsystem keine USB-Unterstützung hätte, kann das Gastsystem auch nicht mit USB. Und ich denke, genau das könnte beim Touch der Fall sein.

Ich würde also an deiner Stelle nochmal sehr aufmerksam recherchieren und ggf. nachfragen, wie das mit Android x86 in einer VM aussieht. Falls meine Befürchtung mit der Touch-Unterstützung berechtigt ist, wäre eine Dual-Boot-Konfiguration wohl eine mögliche Ersatzlösung. Deutlich weniger komfortabel, weil man zum Wechsel immer das jeweils andere System booten muss ...

EDIT: Sorry, ich vergaß - du hast Android zwar schon in einer VM und weißt, dass es prinzipiell geht. Allerdings mit Windows 10 als Host, das ja selbst volle Touch-Unterstützung bietet, sie also auch an das Gastsystem "durchreichen" kann. Einer schnellen, oberflächlichen Recherche zufolge kann aber sogar Linux Mint mit Touchscreen arbeiten, obwohl die Erfahrungen wohl stark auseinandergehen. Das Problem liegt aber AFAIS nicht so sehr bei der hardwareseitigen Unterstützung, sondern darin, dass die typischen Mint-Desktops (Cinnamon und Mate) sich schlecht für Touch-Bedienung eignen.

Davon abgesehen klingt deine Idee eigentlich schlüssig.

PS: Denkt Ihr Ubunutu Touch wird auf absehbare Zeit so gut werden (vor allem bezogen auf die Anzahl der verfügbaren Apps) das es in der Praxis eine vollwertige Alternative zu Android wird?

Keine Ahnung. Ich weiß von Ubuntu Touch nicht mehr, als dass es existiert.

So long,
 Martin

[Karl Heinz]

Das Problem liegt aber AFAIS nicht so sehr bei der hardwareseitigen Unterstützung, sondern darin, dass die typischen Mint-Desktops (Cinnamon und Mate) sich schlecht für Touch-Bedienung eignen.

Du meinst wenn Cinnamon oder Mate im Host-System Touch-Bedienung nur unzureichend unterstützen dann wirkt sich diese unzureichende Unterstützung auch auf das Gast-System (Android bzw. Cynogenmod in der x86er Variante) aus, weil das Gast-System auf keinen Fall mehr bezogen auf die Touch-Screen-Unterstützung bieten kann als das Host-System?

Falls ja, könnte man ja vor dem Starten von Android flott in einen Desktop wechseln der Touch besser unterstützt und diese bessere Unterstützung dann auch besser an das Gast-System weitergeben würde? Denke ich da korrekt?

Gnome und Unity sollen sich ja für Touch ganz gut eignen.

[Der Martin]

Hallo,

Das Problem liegt aber AFAIS nicht so sehr bei der hardwareseitigen Unterstützung, sondern darin, dass die typischen Mint-Desktops (Cinnamon und Mate) sich schlecht für Touch-Bedienung eignen.

Du meinst wenn Cinnamon oder Mate im Host-System Touch-Bedienung nur unzureichend unterstützen dann wirkt sich diese unzureichende Unterstützung auch auf das Gast-System (Android bzw. Cynogenmod in der x86er Variante) aus, weil das Gast-System auf keinen Fall mehr bezogen auf die Touch-Screen-Unterstützung bieten kann als das Host-System?

nein, das meine ich überhaupt nicht. Es ist wichtig, zwischen der prinzipiellen Unterstützung einer Hardware-Komponente und der tatsächlichen Nutzung durch die Software zu unterscheiden.

Ich meinte, dass Mint meiner Kurz-Recherche zufolge wohl die nötigen Treiber und die Hardware-Unterstützung für Touch-Bedienung mitbringt, aber Cinnamon und Mate sich nicht besonders gut für Touch-Bedienung eignen (zumindest war das mein Eindruck aus einer Handvoll Aussagen).
Das heißt aber in der Konsequenz, dass ein Gastsystem in einer VM sehr wohl Touch-Unterstützung bekommen kann.

Falls ja, könnte man ja vor dem Starten von Android flott in einen Desktop wechseln der Touch besser unterstützt und diese bessere Unterstützung dann auch besser an das Gast-System weitergeben würde? Denke ich da korrekt?

Nein, der Desktop des Hostsystems hat nichts damit zu tun, welche Hardware dem Gastsystem zugänglich ist und welche nicht.

Gnome und Unity sollen sich ja für Touch ganz gut eignen.

Ist das so? Kann sein. Wäre für dein geplantes Setup aber irrelevant.

So long,
 Martin

[Christian Kruse]

Hallo Karl,

PS: Denkt Ihr Ubunutu Touch wird auf absehbare Zeit so gut werden (vor allem bezogen auf die Anzahl der verfügbaren Apps) das es in der Praxis eine vollwertige Alternative zu Android wird?

Nein, das denke ich nicht. Wo sollen die Entwickler her kommen, und was soll deren Incentive sein, um für Ubuntu Touch zu entwickeln? Das ist ein Nieschenprodukt. Meine Voraussage: lediglich Idealisten werden dafür entwickeln. Leider.

LG,
CK