GRUB 2: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
K (Buildsystem: /etc/grub.d: 40_custom keine System-Updates)
K (Die Kommandozeile)
 
(68 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{UnderConstruction}}--[[Benutzer:Gehrke|Gehrke]] ([[Benutzer Diskussion:Gehrke|Diskussion]]) 22:26, 27. Nov. 2013 (CET)
+
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen [[BIOS]], aber nicht die zunehmend weiter verbreiteten [[UEFI]]-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.}}
  
 
GNU GRUB (GRand Unified Bootloader)
 
GNU GRUB (GRand Unified Bootloader)
  
 
=Abgrenzung zu 'GRUB Legacy'=
 
=Abgrenzung zu 'GRUB Legacy'=
''GRUB 2'' ist eine vollständige Neuentwicklung des alten [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.
+
''GRUB 2'' ist eine vollständige Neuentwicklung des Vorgängers [[GRUB Legacy]]. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, [[OpenSUSE]] beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.
  
 
Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.
 
Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf '''Kompatibilität zum Vorgänger verzichtet'''.
Zeile 30: Zeile 30:
 
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
 
*Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
 
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)
 
*Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)
*<Was ist mit crypted Devices?!?>
 
<ToDo>
 
  
 
==Unterschiede zu 'GRUB Legacy'==
 
==Unterschiede zu 'GRUB Legacy'==
Zeile 39: Zeile 37:
 
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
 
:*Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
 
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).
 
*Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. [[#Konfiguration]]).
<ToDo>
 
  
 
=Installation=
 
=Installation=
Analog zum Vorgänger wird zur Installation das Script 'grub-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel die erste Festplatte 'sda'):
+
{{Lückenhaft|Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das [[MBR]]-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise [[GPT]] werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.}}
 +
 
 +
Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der [[MBR]] der ersten Festplatten 'sda'):
 
<pre>
 
<pre>
# grub-install /dev/sda
+
# grub2-install /dev/sda
 
Installation finished. No error reported.
 
Installation finished. No error reported.
 
</pre>
 
</pre>
 +
Alternativ können auch Partitionen ausgewählt werden.
  
<ToDo>
+
Unter [[OpenSUSE]] ist alternativ zu verwenden:
 +
*yast2 bootloader
 +
 
 +
{{Box Achtung||Dieser Schritt überschreibt möglicherweise [[Bootmanager]] anderer Systeme!}}
  
 
=Konfiguration=
 
=Konfiguration=
<ToDo>
 
==Boot-Einträge manuell ändern==
 
Manchmal will oder kann man nicht das komplette Setup von GRUB persistent ändern. Wenn das System beispielsweise infolge von Konfigurationsfehlern gar nicht mehr bootet oder der komplette Konfigurationszyklus zu lange dauert oder schlicht etwas ausprobiert werden soll, dann macht es Sinn, die Einträge manuell zu editieren.
 
 
Dies kann erreicht werden durch Drücken von 'E' während der Anzeige des Boot-Menüs. Die zu diesem Zeitpunkt selektierte Zeile wird dann in einen kleinen Editor geladen und kann dort überarbeitet werden. Mit der Tastenkombination <Strg>-<X> wird der geänderte Eintrag dann gestartet.
 
 
Die auf diesem Wege durchgeführten Änderungen sind nicht persistent.
 
  
 
==Die Kommandozeile==
 
==Die Kommandozeile==
Zeile 63: Zeile 59:
  
 
Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.
 
Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im ''Rescue Mode'' beliebige Systeme manuell gestartet werden.
 +
 +
Direkt angesteuert werden kann die Kommandozeile innerhalb des [[#Der Editor|Editors]] mit den Tasten 'Ctrl-C' oder 'F2', Verlassen funktioniert via 'ESC'.
 +
 +
==Der Editor==
 +
[[Bild:GRUB2-editor.png|right|thumb|300px|Der GRUB2-Editor (Beispiel)]]''GRUB2'' verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.
 +
 +
In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Parameter mitzugeben oder den Runlevel zu verändern.
 +
 +
Ein weiterer möglicher Anwendungsfall ist das schnelle Ausprobieren von Konfigurationsänderungen ohne Gefahr zu laufen, das System dauerhaft in einen Fehlerzustand zu versetzen (nicht persistente Änderung).
 +
 +
Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei ''grub.cfg'' in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den angepassten Parametern.
 +
 +
Die Änderungen sind einmalig und werden nicht persistiert!
  
 
==YaST: boot loader==
 
==YaST: boot loader==
Zeile 95: Zeile 104:
 
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
 
*00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub ([[#Default-Konfiguration: /etc/default/grub|Default-Konfiguration]]).
 
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.  
 
*10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.  
*20_linux_xen:  <ToDo>
+
*20_linux_xen:  Für den Hypervisor [[Xen]] sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
 
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
 
*20_memtest86+: Aufnahme von [[memtest]] in das Bootmenü.
*20_ppc_terminfo: <ToDo>
+
*20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
 
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
 
*30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
 
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
 
*40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
 
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
 
*41_custom: Einbindung der Datei /boot/grub/custom.cfg
*90_persistent: <ToDo>
+
*90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems '''nicht''' überschrieben.
 
 
  
<ToDo>
+
Siehe auch: [[#Konfiguration neu generieren]]
  
 
==Module laden==
 
==Module laden==
Zeile 138: Zeile 146:
 
</pre>
 
</pre>
  
<ToDo>
+
In der Konfiguration können Module über den Befehl ''insmod'' geladen werden. Ein Beispiel für die [[#Die Kommandozeile|Kommandozeile]]:
 +
<pre>
 +
  insmod mdraid1x
 +
</pre>
  
 
==Boot Password setzen==
 
==Boot Password setzen==
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk).
+
Diese Funktionalität ist sinnvoll geworden, weil durch die [[#Erweiterte Funktionalitäten|erheblich ausgeweitete Funktionalität]] schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von ''GRUB2'' nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.
Des weiteren besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme nur bestimmten Usern zu ermöglichen.
+
 
 +
Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche '''physischen Zugang''' zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise [[dm-crypt]].
 +
Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.
 +
 
 +
Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im [[BIOS]] einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen.
 +
Einige Anwendungsfälle wurden beispielsweise [http://www.linux-club.de/viewtopic.php?f=90&t=118585 hier] diskutiert.
 +
 
 +
===Authentifizierung===
 +
Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten [https://de.wikipedia.org/wiki/Kryptologische_Hashfunktion Passwort-Hash] zu verwenden, welcher mit einem angemessenen [https://de.wikipedia.org/wiki/Salt_%28Kryptologie%29 Salt] versehen ist (um Angriffen mit [https://de.wikipedia.org/wiki/Rainbow_Table Rainbow-Tables] abwehren zu können).
 +
 
 +
Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.
  
<ToDo>
+
Aufruf für Password '123':
 +
<pre>
 +
# grub2-mkpasswd-pbkdf2
 +
Enter password:
 +
Reenter password:
 +
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
 +
</pre>
 +
Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.
 +
 
 +
Weitere Optionen:
 +
<pre>
 +
# grub2-mkpasswd-pbkdf2 -?
 +
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]                                                                 
 +
Generate PBKDF2 password hash.                                                                                     
 +
                                                                                                                   
 +
  -c, --iteration-count=NUM  Number of PBKDF2 iterations                                                           
 +
  -l, --buflen=NUM          Length of generated hash                                                             
 +
  -s, --salt=NUM            Length of salt                                                                       
 +
  -?, --help                give this help list                                                                   
 +
      --usage                give a short usage message                                                           
 +
  -V, --version              print program version                                                                 
 +
                                                                                                                   
 +
Mandatory or optional arguments to long options are also mandatory or optional                                     
 +
for any corresponding short options.
 +
</pre>
 +
 
 +
Siehe auch: [https://de.wikipedia.org/wiki/PBKDF2 PBKDF2 (Wikipedia)]
 +
 
 +
===Authorisierung===
 +
Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':
 +
<pre>
 +
set superusers="root"
 +
</pre>
 +
Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur [[#Kommandozeile|Kommandozeile]] nur den entsprechenden Usern erlaubt.
 +
 
 +
Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:
 +
<pre>
 +
password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
 +
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E
 +
</pre>
 +
 
 +
Anwendugsbeispiele:
 +
 
 +
''Windows XP'' wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:
 +
<pre>
 +
menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]
 +
</pre>
 +
 
 +
Dieser Eintrag kann aufgrund des Parameters ''unrestricted'' von allen Benutzern gestartet werden:
 +
<pre>
 +
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]
 +
</pre>
 +
Ausgrenzung aller User, nur 'root' darf das Starten:
 +
<pre>
 +
menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]
 +
</pre>
 +
 
 +
Falls weder der Parameter ''unrestricted'' noch ''users'' gesetzt ist, dann wird als User 'root' verwendet.
 +
 
 +
Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das [[#Buildsystem: /etc/grub.d|automatische Build]]. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.
  
 
==Konfigurationsdatei: /boot/grub2/grub.cfg==
 
==Konfigurationsdatei: /boot/grub2/grub.cfg==
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden darf, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird!
+
Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber '''nicht manuell editiert''' werden sollte, weil sie vom [[#Buildsystem: /etc/grub.d|Buildsystem]] generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.
  
Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB legacy]] bekannte Datei 'menu.lst'.
+
Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von [[GRUB Legacy]] bekannte Datei 'menu.lst'.
  
 
==Konfiguration neu generieren==
 
==Konfiguration neu generieren==
Zeile 164: Zeile 244:
 
done
 
done
 
</pre>
 
</pre>
 +
Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.
 +
 +
==Abhängigkeit zum Patch-Prozess==
 +
Die Einträge ''initrd'' und ''linux'' in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die ''initrd'' neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.
  
 
=Grundsätzliche Boot-Methoden=
 
=Grundsätzliche Boot-Methoden=
Zeile 189: Zeile 273:
  
 
=Anwendungsfälle=
 
=Anwendungsfälle=
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen aufgezeigt werden.
+
An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit ''GRUB 2'' aufgezeigt werden:
 
+
*[[Standardeintrag Bootmenü ändern (GRUB2)]]
<TODO: später auslagern>
+
*[[Umgang mit redundanten Laufwerken (GRUB2)]]
 
+
*[[Start von ISO-Image auf der Festplatte (GRUB2)]]
==Anwendungsfall: Standardeintrag ändern==
+
*[[Bootloader wiederherstellen]]
Es gibt zwei Möglichkeiten, den Standardeintrag zu verändern, um beim unbeaufsichtigten Starten ein bestimmtes System vorauszuwählen.
 
===Änderung GRUB_DEFAULT in /boot/grub2/grub.cfg===
 
<pre>
 
GRUB_DEFAULT=n
 
</pre>
 
Das hat den Nachteil, dass bei einer geänderten Reihenfolge möglicherweise das falsche System vorbelegt ist.
 
 
 
Alternativ kann dort auch der Name in 'menuentry' eingetragen werden. Welche Einträge sind vorhanden?
 
<pre>
 
# grep ^menuentry /boot/grub2/grub.cfg | cut -d "'" -f2
 
openSUSE 13.1
 
openSUSE 12.3 (x86_64) (on /dev/mapper/system-os2)
 
openSUSE 12.3 CUSTOM (x86_64) (auf /dev/mapper/system-os2)
 
</pre>
 
Hinweis: Der letzte wurde manuell hinzugefügt. Dieser soll als Default ausgewählt werden.
 
 
 
<pre>
 
GRUB_DEFAULT="openSUSE 12.3 CUSTOM (x86_64) (auf /dev/mapper/system-os2)"
 
</pre>
 
 
 
Im Anschluss muss der Prozess [[#Konfiguration neu generieren|Konfiguration neu generieren]] durchgeführt werden.
 
 
 
===Änderung über den Namen 'menuentry' (GRUB_DEFAULT=saved)===
 
Wenn die Option 'GRUB_DEFAULT=saved' gesetzt ist, dann kann die Vorauswahl über den Namen in einer separaten Konfigurationsdatei getroffen werden.
 
 
 
Beispiel: Änderung auf einen selbst erzeugten Eintrag (CUSTOM).
 
 
 
Vorher:
 
<pre>
 
# grep 'GRUB_DEFAULT=' /etc/default/grub
 
GRUB_DEFAULT=saved
 
 
 
# cat /boot/grub2/grubenv
 
# GRUB Environment Block
 
saved_entry=openSUSE
 
</pre>
 
 
 
<pre>
 
# grub2-set-default "openSUSE 12.3 CUSTOM (x86_64) (auf /dev/mapper/system-os2)"
 
</pre>
 
 
 
Überprüfung:
 
<pre>
 
# grub2-editenv list
 
saved_entry=openSUSE 12.3 CUSTOM (x86_64) (auf /dev/mapper/system-os2)
 
</pre>
 
 
 
Vorteil: Eine Änderung der Reihenfolge hat keinen Einfluss auf die Vorbelegung.
 
 
 
In diesem Fall ist es nicht notwendig, den Prozess [[#Konfiguration neu generieren|Konfiguration neu generieren]] durchzuführen.
 
 
 
*[http://raftaman.net/?p=1334 Change GRUB2 default boot target (raftaman.net)] {{englisch}}
 
  
 
=Links=
 
=Links=
Zeile 255: Zeile 287:
 
*[[GRUB Legacy]]
 
*[[GRUB Legacy]]
  
[[Category:Bootmanager]]
+
[[Kategorie:Bootmanager]] [[Kategorie:Security]]

Aktuelle Version vom 18. November 2015, 14:52 Uhr

Höhe=24px Dieser Artikel oder Abschnitt ist noch unvollständig und weist folgende Lücken auf:

Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme mit herkömmlichen BIOS, aber nicht die zunehmend weiter verbreiteten UEFI-Systeme. Diese Technologie und ihre Implikationen auf GRUB2 sollte in zukünftigen Versionen das Artikels berücksichtigt werden.
Hilf LinuxClubWiki, indem du ihn erweiterst und ihn jetzt vervollständigst!


GNU GRUB (GRand Unified Bootloader)

Abgrenzung zu 'GRUB Legacy'

GRUB 2 ist eine vollständige Neuentwicklung des Vorgängers GRUB Legacy. Seit 2009 wird es in größeren Distributionen als Standard eingeführt, OpenSUSE beispielsweise vollführte diesen Schritt mit Release 12.2 im Herbst 2012.

Um eine Reihe neuer Funktionalitäten anbieten zu können, haben sich die Entwickler für eine radikale Neu-Implementierung entschieden. Es gibt dementsprechend bis auf den Namen kaum Gemeinsamkeiten und bewusst wurde auf Kompatibilität zum Vorgänger verzichtet.

Die aktuelle Version kann beispielsweise so abgefragt werden:

# rpm -qv grub2
grub2-2.00-39.1.3.x86_64

# grub2-install -v
grub2-install (GRUB2) 2.00

Erweiterte Funktionalitäten

  • Script-gesteuerte, dynamischere Konfiguration
  • Unterstützung von mehr Dateisystemen wie beispielsweise ext4, HFS+, NTFS (vollständige Liste)
  • Direkter Zugriff auf LVM und RAID-Devices möglich
  • Steuerung über ein graphisches Terminal (besonders Rescue Mode) und graphisches Menüsystem gegeben
  • Mehrsprachigkeit inklusive der Einträge
  • Zusätzliche Unterstützung für weitere Systemsoftware neben PC BIOS: PC EFI, PC coreboot, PowerPC, SPARC, MIPS Lemote Yeeloong
  • Support für Boot via Netzwerk über tftp (PXE)
  • Zugriff über serielle Konsole möglich (vor allem Embedded Devices)
  • Boot Password möglich
  • Start von LiveCD ISO-Images direkt von der Festplatte möglich
  • Unterstützung von weiteren Plattformen neben x86 (z.B. PowerPC)
  • Einführung eines Modells zur Erzeugung von angepassten Layouts (Themes)

Unterschiede zu 'GRUB Legacy'

An dieser Stelle werden die Unterschiede zu GRUB Legacy hervorgehoben:

  • In Grub 2 existiert die stufenweise Reihenfolge in den Einzelphasen ('Stage 1', 'Stage 1.5', 'Stage 2') nicht mehr.
  • In der Konfiguration werden Partitionen ebenfalls über Zahlen adressiert, aber die Nummerierung beginnt mit 1 (und nicht 0).
  • Hinweis: Das gilt aber nur für Partitionen, nicht für Festplatten. Festplatten werden mit 'hdX' benannt und X beginnt bei 0!
  • Die Konfiguration wurde komplett umgestellt. Wo früher eine einzelne Datei (menu.lst) zu editieren war, gibt es heute ein komplettes Konfigurationssystem aus vielen Dateien mit eigener Struktur und eigenem Build-System, welches die eigentlichen Konfigurationsdateien generiert (s. #Konfiguration).

Installation

Höhe=24px Dieser Artikel oder Abschnitt ist noch unvollständig und weist folgende Lücken auf:

Im aktuellen Zustand beschreibt dieser Artikel ausschließlich Systeme, welche das MBR-Partitionierungsschema verwenden. Andere Schemata wie beispielsweise GPT werden hier derzeit nicht behandelt. Da GPT-Partitionierung zunehmend an Verbreitung gewinnt, sollte dies in zukünftigen Versionen das Artikels berücksichtigt werden.
Hilf LinuxClubWiki, indem du ihn erweiterst und ihn jetzt vervollständigst!


Analog zum Vorgänger wird zur Installation des Boot-Sektors das Script 'grub2-install' verwendet. Als Parameter wird das Ziel-Device angegeben (im Beispiel der MBR der ersten Festplatten 'sda'):

# grub2-install /dev/sda
Installation finished. No error reported.

Alternativ können auch Partitionen ausgewählt werden.

Unter OpenSUSE ist alternativ zu verwenden:

  • yast2 bootloader
Achtung:

Dieser Schritt überschreibt möglicherweise Bootmanager anderer Systeme!


Konfiguration

Die Kommandozeile

GRUB2 verfügt über eine eingebaute Shell, welche unter anderem TAB-Completion beherrscht. Diese kann entweder direkt angesteuert werden oder wird angezeigt, wenn es Probleme mit einer invaliden Konfiguration gibt.

Hier können die selben Befehle verwendet werden, die in der Konfiguration möglich sind. Damit können beispielsweise im Rescue Mode beliebige Systeme manuell gestartet werden.

Direkt angesteuert werden kann die Kommandozeile innerhalb des Editors mit den Tasten 'Ctrl-C' oder 'F2', Verlassen funktioniert via 'ESC'.

Der Editor

Der GRUB2-Editor (Beispiel)

GRUB2 verfügt auch über einen eingebauten Editor. Dieser erlaubt es, einen ausgewählten Boot-Eintrag zu verändern. Dies kann sehr nützlich sein in Situationen, in denen die aktuelle Konfiguration nicht zu einem sauber gebooteten System führt - beispielsweise bei einem defekten Grafikkartentreiber infolge eines missglückten Updates.

In solchen Fällen ist es manchmal hilfreich, beim Start bestimmte Kernel-Parameter mitzugeben oder den Runlevel zu verändern.

Ein weiterer möglicher Anwendungsfall ist das schnelle Ausprobieren von Konfigurationsänderungen ohne Gefahr zu laufen, das System dauerhaft in einen Fehlerzustand zu versetzen (nicht persistente Änderung).

Dieser Editor wird aufgerufen, indem in der Anzeigephase von GRUB2 ein Eintrag ausgewählt und dann die Taste 'E' gedrückt wird. Daraufhin wird genau dieser betreffende Eintrag aus der aktuellen Datei grub.cfg in einen Editor geladen und kann dort verändert werden. Für die Steuerung des Editors gibt es eine Handvoll Tastenkürzel, welche unter dem Editor kurz aufgeführt werden. Mit 'ESC' verwirft man die Änderungen und kommt zur Auswahl zurück, mit 'Ctrl-X' oder 'F10' bootet man das System mit den angepassten Parametern.

Die Änderungen sind einmalig und werden nicht persistiert!

YaST: boot loader

OpenSUSE-typisch kann man einige Einstellungen auch in der Systemverwaltung YaST unter System / boot loader vornehmen.

Default-Konfiguration: /etc/default/grub

Globale Grundeinstellungen (Timeout, Standard-Eintrag, Layout...) werden hier definiert.

/etc/sysconfig/bootloader

Diese Datei enthält Konfigurationsoptionen, welche von der perl-bootloader library verwendet werden. Dies passiert dann, wenn eine Konfiguration über YaST durchgeführt wird oder ein neuer Kernel installiert wird.

Diese Datei ist openSUSE-spezifisch. Die Optionen hier werden auch nicht ausschließlich für GRUB 2 verwendet, sondern auch bei anderen supporteten Bootmanagern.

Buildsystem: /etc/grub.d

Das Buildsystem ist eine Sammlung von Scripten. Ein Nummernpräfix sorgt für eine Abfolge in definierter Reihenfolge (bei '00' beginnend):

# ls -l /etc/grub.d
-rwxr-xr-x 1 root root  7649 Jul 31 11:48 00_header
-rwxr-xr-x 1 root root 10535 Jul 31 11:48 10_linux
-rwxr-xr-x 1 root root 11019 Jul 31 11:48 20_linux_xen
-rwxr-xr-x 1 root root  1802 Jul 31 11:49 20_memtest86+
-rwxr-xr-x 1 root root  2596 Jul 31 11:48 20_ppc_terminfo
-rwxr-xr-x 1 root root 10132 Jul 31 11:48 30_os-prober
-rwxr-xr-x 1 root root   489 Jul 11 15:04 40_custom
-rwxr-xr-x 1 root root   216 Jul 31 11:48 41_custom
-rwxr-xr-x 1 root root  1259 Jul 31 11:49 90_persistent
-rw-r--r-- 1 root root   483 Jul 31 11:48 README

Dieses Beispiel stammt aus einer OpenSUSE-Installation (Release 12.3). Andere Distribution liefern geringfügig andere Scripten aus. Es können diesem Schema entsprechend auch eigene Scripte hinzugefügt werden.

Bedeutung der Standard-Scripten:

  • 00_header: Initialisierung des Systems anhand der Einträge in /etc/default/grub (Default-Konfiguration).
  • 10_linux: Hier wird versucht, alle validen Kernel zu finden. Aus diesen wird dann das Bootmenü generiert.
  • 20_linux_xen: Für den Hypervisor Xen sind dedizierte Kernel notwendig. Hier wird die notwendige Parametrisierung hierfür durchgeführt.
  • 20_memtest86+: Aufnahme von memtest in das Bootmenü.
  • 20_ppc_terminfo: <ToDo: Funktionalität noch beschreiben>
  • 30_os-prober: Suche nach weiteren Bootladern sowie weiteren installierten Betriebssystemen. In einem Multi-Boot-Kontext werden hier Einträge beispielsweise für Windows oder parallele Linux-Installationen generiert.
  • 40_custom: Eigene Booteinträge können hier manuell hinterlegt werden. Dieses Script wird bei System-Updates nicht überschrieben.
  • 41_custom: Einbindung der Datei /boot/grub/custom.cfg
  • 90_persistent: Teile aus der aktuellen grub.cfg können hier rein kopiert werden. Dieser Inhalt wird bei einem erneuten Durchlauf des Build-Systems nicht überschrieben.

Siehe auch: #Konfiguration neu generieren

Module laden

GRUB 2 bietet direkten Zugriff auf bestimmte Ressourcen wie beispielsweise LVM, RAID oder diverse Dateisysteme. Dieser Zugriff wird über Module implementiert, welche per 'insmod' bei Bedarf geladen werden können.

Unter OpenSUSE liegen diese Module (architekturabhängig) unter:

# tree -d /usr/lib/grub2/
/usr/lib/grub2/
├── i386-pc
└── x86_64-efi

Verfügbare Module (nur x86_64-efi):

 # ls -r --format=commas *.mod
zfsinfo.mod, zfscrypt.mod, zfs.mod, xzio.mod, xnu_uuid.mod, xnu.mod, xfs.mod, videotest.mod, videoinfo.mod, video_fb.mod, video_cirrus.mod, video_bochs.mod, video.mod,
usbtest.mod, usbserial_pl2303.mod, usbserial_ftdi.mod, usbserial_common.mod, usbms.mod, usb_keyboard.mod, usb.mod, uhci.mod, ufs2.mod, ufs1.mod, udf.mod, true.mod, trig.mod,
time.mod, tga.mod, tftp.mod, testload.mod, test_blockarg.mod, test.mod, terminfo.mod, terminal.mod, tar.mod, squash4.mod, sleep.mod, sfs.mod, setpci.mod, setjmp.mod,
serial.mod, search_label.mod, search_fs_uuid.mod, search_fs_file.mod, search.mod, scsi.mod, romfs.mod, relocator.mod, reiserfs.mod, regexp.mod, reboot.mod, read.mod,
raid6rec.mod, raid5rec.mod, probe.mod, priority_queue.mod, png.mod, play.mod, pbkdf2.mod, pata.mod, password_pbkdf2.mod, password.mod, parttool.mod, part_sunpc.mod,
part_sun.mod, part_plan.mod, part_msdos.mod, part_gpt.mod, part_dvh.mod, part_bsd.mod, part_apple.mod, part_amiga.mod, part_acorn.mod, ohci.mod, odc.mod, ntfscomp.mod,
ntfs.mod, normal.mod, nilfs2.mod, newc.mod, net.mod, multiboot2.mod, multiboot.mod, msdospart.mod, mmap.mod, minix_be.mod, minix3_be.mod, minix3.mod, minix2_be.mod, minix2.mod,
minix.mod, minicmd.mod, memrw.mod, memdisk.mod, mdraid1x.mod, mdraid09_be.mod, mdraid09.mod, lzopio.mod, lvm.mod, luks.mod, lssal.mod, lspci.mod, lsmmap.mod, lsefisystab.mod,
lsefimmap.mod, lsacpi.mod, ls.mod, loopback.mod, loadenv.mod, loadbios.mod, linuxefi.mod, linux.mod, ldm.mod, keystatus.mod, keylayouts.mod, jpeg.mod, jfs.mod, iso9660.mod,
iorw.mod, http.mod, hfsplus.mod, hfs.mod, hexdump.mod, help.mod, hello.mod, hdparm.mod, hashsum.mod, halt.mod, gzio.mod, gptsync.mod, gfxterm.mod, gfxmenu.mod, gettext.mod,
geli.mod, gcry_whirlpool.mod, gcry_twofish.mod, gcry_tiger.mod, gcry_sha512.mod, gcry_sha256.mod, gcry_sha1.mod, gcry_serpent.mod, gcry_seed.mod, gcry_rmd160.mod,
gcry_rijndael.mod, gcry_rfc2268.mod, gcry_md5.mod, gcry_md4.mod, gcry_des.mod, gcry_crc.mod, gcry_cast5.mod, gcry_camellia.mod, gcry_blowfish.mod, gcry_arcfour.mod,
functional_test.mod, fshelp.mod, font.mod, fixvideo.mod, fat.mod, extcmd.mod, ext2.mod, exfctest.mod, exfat.mod, elf.mod, ehci.mod, efinet.mod, efi_uga.mod, efi_gop.mod,
echo.mod, dm_nv.mod, diskfilter.mod, datetime.mod, datehook.mod, date.mod, cs5536.mod, cryptodisk.mod, crypto.mod, crc64.mod, cpuid.mod, cpio_be.mod, cpio.mod, configfile.mod,
cmp.mod, chain.mod, cat.mod, bufio.mod, btrfs.mod, bsd.mod, boot.mod, blocklist.mod, bitmap_scale.mod, bitmap.mod, bfs.mod, backtrace.mod, ata.mod, at_keyboard.mod,
appleldr.mod, aout.mod, all_video.mod, ahci.mod, afs.mod, affs.mod, adler32.mod, acpi.mod

In der Konfiguration können Module über den Befehl insmod geladen werden. Ein Beispiel für die Kommandozeile:

  insmod mdraid1x

Boot Password setzen

Diese Funktionalität ist sinnvoll geworden, weil durch die erheblich ausgeweitete Funktionalität schon vor dem Start des OS potentiell Zugriff auf schützenswerte Daten erfolgen kann (möglicherweise auch über das Netzwerk) oder nicht gewünschte Systeme gebootet werden können. Es besteht auf diesem Wege die Möglichkeit, das Starten ausgewählter Systeme oder anderer Eigenschaften von GRUB2 nur bestimmten Usern zu ermöglichen. Hierzu ist ein Authentifizierungsmechanismus und ein simples Usermangagement vorgesehen.

Hinweis: Die hier vorgestellten Mechanismen bieten keinen wirksamen Schutz vor Angreifern, welche physischen Zugang zu einem System haben sowie über ausreichend Zeit, Gelegenheit und über das notwendige KnowHow verfügen. Sollte der Angriff dem Datenbestand gelten, dann könnten die Festplatte auch ausgebaut und in einem anderen Computer eingelesen werden. Gegen solche Angriffe hilft nur eine ausreichende physikalische Sicherung und/oder eine Verschlüsselung der Daten mit ausgereiften kryptographischen Verfahren wie beispielsweise dm-crypt. Auch sollte erwähnt werden, dass hierdurch naturgemäß die Administration erschwert wird, insbesondere im Fall, dass ein System aus irgendwelchen Gründen gar nicht mehr bootet und repariert werden muss.

Gleichwohl kann das hier beschriebene Verfahren sehr wohl in bestimmten Kontexten zu einem höheren Maß an Sicherheit führen. Oftmals geht es in der IT-Sicherheit auch 'nur' darum, Hürden aufzubauen um schwächere Angriffsszenarien abdecken zu können oder Kombinationen von Sicherheitslücken zu entschärfen. So kann es durchaus sinnvoll sein, das Booten von externen Medien (USB-Stick, Netzwerk...) in Kombination mit entsprechenden Einträgen im BIOS einem Administrator vor zu behalten oder bestimmte installierte Betriebssysteme auf ausgewählte User einzugrenzen. Einige Anwendungsfälle wurden beispielsweise hier diskutiert.

Authentifizierung

Es besteht die Möglichkeit, die Passwörter in Klartext in der Konfiguration zu hinterlegen. Viel sicherer ist es aber, anstatt von Klarttext-Passworten einen kryptographisch gesicherten Passwort-Hash zu verwenden, welcher mit einem angemessenen Salt versehen ist (um Angriffen mit Rainbow-Tables abwehren zu können).

Hierzu wird das Kommando 'grub2-mkpasswd-pbkdf2' verwendet. Es generiert einen Password-Hash, welcher an den geeigneten Stellen eingetragen werden kann.

Aufruf für Password '123':

# grub2-mkpasswd-pbkdf2
Enter password: 
Reenter password: 
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249

Folgende Aufrufe mit dem selben Password rufen immer andere Hashes hervor, was auf das Salting zurückzuführen ist.

Weitere Optionen:

# grub2-mkpasswd-pbkdf2 -?
Usage: grub2-mkpasswd-pbkdf2 [OPTION...] [OPTIONS]                                                                  
Generate PBKDF2 password hash.                                                                                      
                                                                                                                    
  -c, --iteration-count=NUM  Number of PBKDF2 iterations                                                            
  -l, --buflen=NUM           Length of generated hash                                                               
  -s, --salt=NUM             Length of salt                                                                         
  -?, --help                 give this help list                                                                    
      --usage                give a short usage message                                                             
  -V, --version              print program version                                                                  
                                                                                                                    
Mandatory or optional arguments to long options are also mandatory or optional                                      
for any corresponding short options.

Siehe auch: PBKDF2 (Wikipedia)

Authorisierung

Zu erst wird die Liste der User definiert, welchen root-Zugriff zugebilligt werden soll. In diesem Beispiel einfach nur der User 'root':

set superusers="root"

Wenn diese Umgebungsvariable gesetzt ist, wird der Zugang zur Kommandozeile nur den entsprechenden Usern erlaubt.

Als nächstes wird das Password mit den vorher generierten Password-Hashes den Usern zugeordnet:

password_pbkdf2 root grub.pbkdf2.sha512.10000.DD2DF79436A5F2CA4F7363030C6C1555A7263BD692A61AAAE2847EDEF9D12B25EBBD0791EA875CBD1726D90DE9E99644BC4A630637D615AA42C06C19C26A6DC8.C68EC9D01A2DFCBEB2B36FDF6836290E8DB6F50B2BD85932AF7E6BEC8E4AC9A5BB4F027EF906AFD97FC2DC2A38745F5CA63DCC1E05049DC3CA12DC5336647249
password_pbkdf2 user1 grub.pbkdf2.sha512.10000.C3FFA2E95A6F933C562CFEFAFF86EE4BBE50FA20BD0575080C364D7EB37DE9CA6D7BDC58DB853EF00ECEB97376B1B7F50E051853A7DDBD917F201D58617397C1.6E29B095569E5BABD4380C47B61210F63D6F9156DA6D43C8D5F8AEAC88C7146C6C58A373C3CF4326D4B9F9CD50DDE4D890A0BDFC3E69EF5B42D5B2C09CA8086E

Anwendugsbeispiele:

Windows XP wird als unsicher eingestuft und sollte - wenn überhaupt - nicht in unsicheren Netzen eingesetzt werden. Um das sicherzustellen, wird dieses Recht nur dem besonders vertrauenswürdigen User 'user1' (oder implizit 'root') zugestanden:

menuentry 'Windows XP (Achtung: kein Support mehr - unsicher)' --users user1 [...]

Dieser Eintrag kann aufgrund des Parameters unrestricted von allen Benutzern gestartet werden:

menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop' --unrestricted [...]

Ausgrenzung aller User, nur 'root' darf das Starten:

menuentry 'openSUSE 12.3, with Linux 3.7.10-1.11-desktop (recovery mode)' --users '' [...]

Falls weder der Parameter unrestricted noch users gesetzt ist, dann wird als User 'root' verwendet.

Hinweis: Derzeit gibt es noch keine Integration des Usermanagements in das automatische Build. Die oben genannte Konfiguration muss also manuell in den Custom-Bereich eingetragen werden.

Konfigurationsdatei: /boot/grub2/grub.cfg

Dies ist die Hauptkonfigurationsdatei, welche wie oben beschrieben aber nicht manuell editiert werden sollte, weil sie vom Buildsystem generiert wird! Es gibt System-Prozesse, welche genau das veranlassen, beispielsweise bei einem Kernelupdate. Manuelle Änderungen an dieser Datei würden spätestens da überschrieben.

Diese Datei wird beim eigentlichen Systemstart ausgewertet und bestimmt somit, welche Systeme zur Ausführung gelangen . Sie ersetzt die von GRUB Legacy bekannte Datei 'menu.lst'.

Konfiguration neu generieren

Um Konfigurationsänderungen zu aktivieren, muss abschließend das Kommando 'grub2-mkconfig' aufgerufen werden. Bei erfolgreicher Abarbeitung wird die Hauptkonfigurationsdatei neu generiert:

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-3.11.6-4-desktop
Found initrd image: /boot/initrd-3.11.6-4-desktop
Found linux image: /boot/vmlinuz-3.7.10-1.16-desktop
Found initrd image: /boot/initrd-3.7.10-1.16-desktop
Found openSUSE 12.3 (x86_64) on /dev/mapper/system-os2
done

Im Falle von Syntax-Fehlern wird die Zieldatei nicht neu geschrieben. So wird sichergestellt ist, dass immer eine valide Konfiguration für den Systemstart vorliegt.

Abhängigkeit zum Patch-Prozess

Die Einträge initrd und linux in dieser Konfiguration unterliegen einer gewissen Dynamik. Es gibt eine Abhängigkeit zwischen den im Verzeichnis /boot liegenden Image-Dateien und der Konfiguration. So gibt es Anwendungsfälle, in welchen im Rahmen eines Systemupdates (Patch-Prozess) diese Images neu generiert werden (beispielsweise die initrd neu geschrieben wird). Um den Code des geänderten oder neuen Images auch nutzen zu können, wird vom Update-Prozess explizit auch die GRUB-Konfiguration neu generiert.

Grundsätzliche Boot-Methoden

GRUB 2 kennt zwei grundsätzliche Methoden, Betriebssysteme zu booten:

  1. Direktes Booten: Bei Betriebssystemen nach 'Multiboot Specification' wird diese Methode verwendet. Das sind hauptsächlich Open Source-Systeme.
  2. Chain Loading: Wird hauptsächlich bei nicht freien Betriebssystemen angewendet, für die es keinen nativen Support gibt.

Direktes Booten (Multiboot Specification)

Es gibt eine Spezifikation namens 'Multiboot', welche einen sauberen Multi-Boot-Betrieb zwischen unterschiedlichen Betriebssystemen zum Inhalt hat. Auf diesem Wege ist direkte Ansteuerung der installierten Systeme durch einen einzigen BootManager möglich.

Betriebssysteme mit Multiboot-Support: GNU/Linux, FreeBSD, NetBSD, OpenBSD, ...

Siehe: Multiboot Specification (GNU)

Chain Loading

Bei nicht quelloffenen Betriebssystemen gibt es fast immer keinen Support für direktes Booten. An diesen Stellen wird 'chain loading' verwendet, wobei hier der vorgeschaltete Boatloader (GRUB2) den Staffelstab an den nachgeschalteten (z.B. Windows) weitergibt:

menuentry "Windows" {
	insmod chain
	insmod ntfs
	set root=(hd0,1)
	chainloader +1
}

Anwendungsfälle

An dieser Stelle sollen Anleitungen zu ausgesuchten Anwendungsfällen im Zusammenhang mit GRUB 2 aufgezeigt werden:

Links