24GRUB
Das Programm GRUB ist ein sogenannter Bootloader. Es wird als erstes Programm nach dem Einschalten des Rechners gestartet. Bei BIOS-Rechnern können Sie nun in einem Menü zwischen Linux und Windows wählen. Bei EFI-Rechnern spielt diese Wahlfunktion keine große Rolle mehr, GRUB übernimmt aber auch dort die Aufgabe, Linux an sich zu starten und diverse Parameter an den Kernel zu übergeben.
Bei allen aktuellen Distributionen kommt die GRUB-Version 2 zum Einsatz. Diese Version steht im Mittelpunkt dieses Kapitels. Auf älteren Langzeitdistributionen werden Sie fallweise noch auf die GRUB-Version 0.97 legacy stoßen, z.B. in RHEL 6 bzw. CentOS 6. Deswegen gehe ich am Ende des Kapitels auch auf diese Version noch kurz ein.
24.1Grundlagen
GRUB steht für Grand Unified Bootloader. Seit 2012 ist GRUB in der Version 2.0 verfügbar. Die Vorgängerversion hat die merkwürdige Bezeichnung GRUB 0.97 legacy. Der Zusatz legacy weist darauf hin, dass diese Version schon seit Jahren nicht mehr weiterentwickelt wird. Und die Versionsnummer 0.97 macht klar, dass Version 1.0 nie erreicht wurde.
Die für GRUB 2 notwendigen Dateien sind oft über mehrere Pakete verteilt: Bei Debian und Ubuntu enthält grub-common plattformunabhängige Konfigurationsdateien und Kommandos, und grub-pc enthält die BIOS-spezifischen Dateien. Für Rechner, die statt des BIOS auf EFI setzen, ist statt grub-pc das Paket grub-efi-amd64 oder grub-efi-ia32 erforderlich. Zu guter Letzt enthält grub-rescue-pc eine IMG- und eine ISO-Datei, um ein GRUB-Rescue-System auf einem USB-Stick oder einer CD zu speichern. Das ermöglicht es im Notfall, GRUB vom USB-Stick zu starten und dann durch die manuelle Eingabe von GRUB-Kommandos bzw. durch die Veränderung der vorgesehenen Menüeinträge das System zu starten.
Fedora hat die Filetierung in unzählige Pakete vermieden: grub2 enthält GRUB für BIOS-Rechner, und grub2-efi enthält die EFI-kompatible Version. Für die Aktualisierung der GRUB-Konfiguration nach Kernel-Updates sorgen die Fedora-spezifischen Scripts des Pakets grubby.
GRUB 2 setzt unabhängig von der Distribution die Installation des Pakets os-prober voraus. Das gleichnamige Kommando sucht auf allen erreichbaren Partitionen nach Betriebssystemen. Das Ergebnis von os-prober fließt in das automatisch erzeugte GRUB-Menü ein.
EFI-Systemstart
Bevor die Einzelheiten der GRUB-Installation und -Konfiguration behandelt werden, ist es sinnvoll, sich ein Bild davon zu machen, was während des Boot-Vorgangs passiert. Der Startprozess unterscheidet sich stark, je nachdem, ob auf Ihrem Rechner ein traditionelles BIOS oder das modernere EFI läuft.
Das Extensible Firmware Interface (EFI) vereinfacht die Parallelinstallation mehrerer Betriebssysteme. Während das BIOS grundsätzlich nur die Installation eines Betriebssystems vorsah und jede Parallelinstallation einen Bootmanager voraussetzte, unterstützt EFI von sich aus die Installation mehrerer Betriebssysteme: Jedes Betriebssystem kann seinen eigenen Bootloader in ein eigenes Verzeichnis innerhalb der EFI-Partition speichern.
Beim Start des Rechners sucht EFI automatisch den Bootloader des Default-Betriebssystems und führt ihn aus. Als Default-Betriebssystem gilt in der Regel das zuletzt installierte Betriebssystem. Wird während des Rechnerstarts eine spezielle Tastenkombination gedrückt, zeigt das EFI ein Menü aller Bootloader an. Dort können Sie das Default-Betriebssystem einstellen.
In Kombination mit EFI muss GRUB also nur noch Linux starten. Die zweite Funktion von GRUB, nämlich die Auswahl zwischen verschiedenen Betriebssystemen, ist im Zusammenspiel mit EFI eigentlich entbehrlich. Weil sich das GRUB-Menü aber als praktisch erwiesen hat, wird es weiterhin oft angezeigt. Daraus ergeben sich die Startwege, die in Abbildung 24.1 durch gestrichelte Linien angedeutet sind.
Abbildung 24.1Boot-Vorgang für drei Betriebssysteme mit BIOS, EFI und UEFI Secure Boot
Es gibt für EFI- und für BIOS-Rechner unterschiedliche Varianten von GRUB. Die Installationsprogramme gängiger Distributionen kümmern sich automatisch darum, die richtige Version zu installieren. Das setzt allerdings voraus, dass das Installationsprogramm im EFI-Modus und nicht im BIOS-Modus ausgeführt wird! (Manche Mainboards unterstützen beide Varianten.)
Der GRUB-Code wird bei EFI-Rechnern nicht in den MBR installiert, sondern in ein Verzeichnis der EFI-Partition. Dabei handelt es sich um eine spezielle Partition mit einem VFAT-Dateisystem. Die Partition muss durch eine spezielle UID markiert sein: 0xEF (MBR) bzw. C12A7328-F81F-11D2-BA4B-00A0C93EC93B (GPT).
Wenn Sie Partitionen manuell mit parted einrichten, müssen Sie die EFI-Partition mit dem Flag esp kennzeichnen (EFI System Partition, set n esp on). Außerdem müssen Sie sicherstellen, dass die EFI-Partition im Verzeichnis /boot/efi in das Linux-Dateisystem eingebunden wird. (Die Installationsprogramme der meisten Linux-Distributionen kümmern sich selbst um diese Details. Zu den Ausnahmen zählt Arch Linux, wo an dieser Stelle Handarbeit erforderlich ist.)
Microsoft empfiehlt, die EFI-Partition als erste Partition auf der Festplatte einzurichten, obwohl der EFI-Standard dies nicht verlangt. Die Partition muss nicht besonders groß sein, ca. 100 bis 200 MByte reichen.
Zum eigentlichen Start von Linux muss der Bootloader die Linux-Kerneldatei in den Speicher laden und ausführen. Die Kerneldatei hat normalerweise den Dateinamen /boot/vmlinuz. Der letzte Buchstabe z weist darauf hin, dass der Kernel komprimiert ist. Der Bootloader muss also in der Lage sein, eine vollständige Datei aus einem Linux-Dateisystem zu laden.
An den Kernel werden meist einige Parameter übergeben, mindestens aber einer: der Device-Name der Systempartition (z.B. root=/dev/sda3). Damit weiß der Kernel, welches die Systempartition ist. Sobald der Kernel läuft, gibt er die Kontrolle an das Init-System weiter. Dieses Programm ist für die Initialisierung von Linux zuständig und wird in Kapitel 25, »Das Init-System«, ausführlich beschrieben. Es kümmert sich beispielsweise darum, alle Netzwerkdienste zu starten.
Der Linux-Kernel ist modularisiert. Das bedeutet, dass der Kernel an sich nur relativ elementare Funktionen enthält. Zusatzfunktionen zum Zugriff auf bestimmte Hardware-Komponenten, zum Lesen und Schreiben verschiedener Dateisysteme etc. befinden sich dagegen in Modulen, die bei Bedarf aus dem Dateisystem geladen werden und den Kernel so erweitern.
Damit der Startprozess gelingt, muss der Kernel auf die Systempartition zugreifen können. Falls diese Partition in einem Dateisystem vorliegt, das der Kernel nicht direkt unterstützt, oder wenn sich die Partition auf einer SCSI-Festplatte befindet, für die der Kernel keinen Hardware-Treiber enthält, so tritt ein Henne-Ei-Problem auf: Der Kernel kann nicht auf das Dateisystem zugreifen und daher die Module nicht laden, die er benötigen würde, um Dateien des Dateisystems zu lesen ...
Die Lösung des Problems besteht darin, dass der Bootloader nicht nur den Kernel lädt, sondern auch eine sogenannte Initrd-Datei. Dabei handelt es sich um eine spezielle Datei, die alle für den Startprozess erforderlichen Kernelmodule enthält. Die Datei steht dem Kernel vorübergehend als RAM-Disk zur Verfügung, d.h., der Kernel kann die erforderlichen Module unmittelbar nach dem Start von der RAM-Disk laden. (Initrd ist die Abkürzung für Initial RAM Disk.) Die Initrd-Datei hat üblicherweise den Dateinamen /boot/initrd oder /boot/initrd.gz. Die meisten Distributionen stellen Werkzeuge zur Verfügung, um eine zum Kernel passende initrd-Datei zu erzeugen.
Wenn in diesem Buch von »Software-Installation« die Rede ist, dann ist damit üblicherweise die Installation eines Programmpakets auf der Festplatte gemeint. In diesem Kapitel gelten allerdings andere Regeln: Mit der »Installation von GRUB« wird der Prozess bezeichnet, den GRUB-Startcode in die EFI-Partition zu schreiben und einige EFI-Parameter zu verändern. Außerdem werden GRUB-Konfigurations-Scripts im Verzeichnis /etc/grub.d/ ausgeführt. Diese Scripts erstellen die eigentliche GRUB-2-Konfigurationsdatei /boot/grub2/grub.cfg.
UEFI Secure Boot
Die EFI-Erweiterung Secure Boot hat den Boot-Prozess nochmals komplizierter gemacht. Wenn diese EFI-Erweiterung aktiv ist, startet das EFI nur solche Programme, die mit einem dem EFI bekannten Schlüssel signiert sind. Die meisten Mainboards kennen aber nur einen einzigen Schlüssel – den von Microsoft! Glücklicherweise bietet Microsoft für Linux-Distributoren und andere Unternehmen einen Signierdienst an. Damit ist es prinzipiell möglich, einen Bootloader so signieren zu lassen, dass EFI bereit ist, diesen zu starten.
Allerdings sind mit dem Signierdienst Auflagen verbunden: Die Teilnehmer müssen sich dazu verpflichten, das zu startende System gegen Manipulationen abzusichern, sodass Secure Boot seinem Namen gerecht wird und keine Schad-Software lädt, sondern nur den originalen Linux-Kernel der jeweiligen Distribution.
Um den mit dem Microsoft-Schlüssel signierten Code möglichst klein zu halten, haben sich die Distributoren dazu entschlossen, einen Zwischenschritt einzulegen: Das EFI startet zuerst das signierte Programm Shim. Die einzige Aufgabe dieses winzigen Programms ist es, die Signaturkette sicherzustellen und GRUB zu starten. GRUB setzt dann wie bisher den Boot-Prozesses fort (siehe Abbildung 24.1 rechts).
Wie Tabelle 24.1 zeigt, haben Fedora, SUSE und Ubuntu die Secure-Boot-Anforderungen unterschiedlich interpretiert. Bei Fedora ist in Shim außerdem ein Fedora-eigener Schlüssel eingebaut. Damit kann überprüft werden, dass der zu startende GRUB-Bootloader nicht modifiziert wurde. Anschließend überprüft auch GRUB die Signatur des Kernels und der Kernel die Signatur jedes zu ladenden Moduls. Analog gehen auch SUSE- und Red-Hat-Distributionen vor.
Ganz ähnlich sieht der Prozess auch bei Ubuntu aus, allerdings ist dort die Signatur des Kernels optional, und Module werden gar nicht überprüft. Debian bis einschließlich Version 8 sowie diverse andere Distributionen unterstützen Secure Boot noch gar nicht. Ein Start ist hier nur möglich, wenn im EFI die Secure-Boot-Funktionen deaktiviert werden.
|
Komponente |
Fedora |
SUSE |
Ubuntu |
|---|---|---|---|
|
Shim |
Microsoft-Signatur |
Microsoft-Signatur |
Microsoft-Signatur |
|
GRUB |
Fedora-Signatur |
SUSE-Signatur |
Ubuntu-Signatur |
|
Kernel |
Fedora-Signatur |
SUSE-Signatur |
Ubuntu-Signatur (optional) |
|
Kernelmodule |
Fedora-Signatur |
SUSE-Signatur |
– |
Tabelle 24.1Signaturkette des Secure-Boot-Verfahrens von Fedora, SUSE und Ubuntu
Die Fedora- und SUSE-Entwickler argumentieren damit, dass nur ihre sehr exakte Befolgung der Secure-Boot-Vorgaben sicherstellt, dass die Vertrauenskette zu keinem Zeitpunkt durchbrochen werden kann. Aus den strengen Secure-Boot-Implementierungen von Fedora und openSUSE ergeben sich aus Linux-Sicht leider dramatische Einschränkungen:
-
Die Kernelmodule der NVIDIA- und ATI/AMD-Grafiktreiber können nicht geladen werden. Da diese Module direkt von NVIDIA bzw. AMD kompiliert sind, ist es unmöglich, sie mit dem Schlüssel zu signieren, der nur den Fedora-Entwicklern vorliegt. Dieselbe Einschränkung gilt natürlich auch für alle anderen Kernelmodule von proprietären Hardware-Treibern.
-
Es ist nicht ohne Weiteres möglich, einen eigenen Kernel zu kompilieren und einzurichten. Auch dieser Kernel muss ja signiert werden, den dazu erforderlichen Schlüssel hat aber nur der Distributor. Ein Ausweg aus diesem Dilemma ist das von SUSE entwickelte Verfahren Machine Owner Keys (MOK). Damit wird in Shim zusätzlich zum SUSE-Schlüssel ein weiterer, von Ihnen selbst zur Verfügung gestellter Schlüssel hinterlegt. Ein selbst kompilierter Kernel und dessen Module können dann ebenfalls mit diesem Schlüssel signiert werden. Das MOK-Konzept haben inzwischen auch andere Distributionen aufgegriffen.
-
GRUB kann nur dann eine andere Linux-Distribution starten, wenn diese mit demselben Schlüssel signiert ist.
-
Der Ruhemodus (suspend to disk) funktioniert nicht.
-
Die Kernel-Funktionen kexec und kdump können nicht genutzt werden.
Am einfachsten umgehen Sie diese Einschränkungen, indem Sie Secure Boot deaktivieren. Ubuntus etwas laxerer Umgang mit Secure Boot ist aus Anwendersicht deutlich bequemer.
Wogegen schützt Secure Boot?
Secure Boot soll verhindern, dass bereits beim Boot-Prozess Schad-Software geladen wird, die sich in der Folge allen weiteren Sicherheitsmaßnahmen, wie z.B. Viren-Scannern, entzieht. Derartige Angriffe hat es in den letzten Jahrzehnten so gut wie nie gegeben, nicht unter Windows, und schon gar nicht unter Linux. Salopp formuliert: Secure Boot schützt Sie vor einer Gefahr, die es gar nicht gibt.
Die Sicherheitsprobleme, die Windows und vereinzelt auch Linux in den vergangenen Jahren plagten, waren durchweg Fehler in einzelnen Anwendungsprogrammen – sei es nun im Internet Explorer oder im Apache Webserver. Diese Probleme wird es wohl weiterhin geben. Secure Boot ändert daran nichts.
Wenn Sie sich für die technischen Details der Implementierung von Secure Boot unter Linux interessieren, können Sie hier weiterlesen:
http://mjg59.dreamwidth.org/12368.html
http://lwn.net/Articles/523367
http://fedoraproject.org/wiki/Features/SecureBoot
https://en.opensuse.org/openSUSE:UEFI
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP3
https://www.suse.com/communities/conversations/uefi-secure-boot-details
https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html
http://web.dodds.net/vorlon/wiki/blog/SecureBoot_in_Ubuntu_12.10
BIOS-Systemstart
Nach dem Einschalten eines BIOS-Rechners wird das Basic Input Output System initialisiert. Während dieses Vorgangs erscheinen meist ein paar Systemmeldungen auf dem Bildschirm. Anschließend lädt das BIOS den Inhalt des ersten Sektors der ersten Festplatte in den Speicher und führt diesen Code aus. Dieser spezielle Sektor der Festplatte heißt Master Boot Record (MBR).
Der Kampf um den Master Boot Record
Es gibt nur einen MBR, aber möglicherweise mehrere Betriebssysteme auf Ihrer Festplatte. Das birgt natürlich Konfliktpotenzial! Sowohl bei Linux- als auch bei Windows-Installationen wird der MBR überschrieben. Während GRUB auch Windows starten kann, nimmt Windows leider keine Rücksicht auf Linux. Deswegen müssen Sie nach einer Windows-Installation GRUB reparieren, wofür Sie am besten ein Live- oder Notfallsystem verwenden. Besser ist es, zuerst Windows und dann Linux zu installieren! Sollte bei einer späteren Windows-Installation der MBR mit GRUB überschrieben werden, finden Sie in den weiteren Abschnitten Notfalltipps.
Wenn auf einem Rechner Windows installiert ist, befindet sich im MBR ein winziges Programm. Es sucht die als »aktiv« gekennzeichnete Partition und führt dann den Windows-Bootloader aus, der sich im Boot-Sektor dieser Partition befindet. Falls auf dem Rechner mehrere Windows-Versionen installiert sind, können Sie im Windows-Bootloader zwischen diesen Versionen wählen.
Wenn auf dem Rechner auch Linux installiert ist, wird der MBR üblicherweise durch den Code des Linux-Bootloaders GRUB ersetzt. GRUB kann dann wahlweise Linux starten oder in den Windows-Bootloader verzweigen (siehe Abbildung 24.1).
Eine alternative Vorgehensweise besteht darin, den MBR nicht anzurühren, GRUB in den Boot-Sektor der Linux-Systempartition zu installieren und diese Partition als »aktiv« zu markieren. Diese Vorgehensweise würde zwar den MBR-Konventionen entsprechen, ist aber weniger robust und deswegen nicht mehr gebräuchlich. Sie ist zudem inkompatibel mit manchen Dateisystemen, z.B. mit XFS.
Der MBR ist nur 512 Byte groß – zu klein, um das gesamte Bootloader-Programm zu speichern. Deswegen enthält der MBR gerade so viel Code, um den Rest des Bootloaders von der Festplatte zu laden. Dementsprechend ist der GRUB-Code in zwei oder drei Teile zerlegt: stage1 befindet sich im MBR und hat die Aufgabe, die ersten Sektoren von stage1_5 oder stage2 zu laden. stage1_5 enthält Zusatzcode für den Zugriff auf Dateien in verschiedenen Dateisystemen. stage2 enthält schließlich den eigentlichen Bootloader.
Sobald der Bootloader läuft, erscheint ein Menü mit einer Auswahl aller Betriebssysteme, die bei der GRUB-Konfiguration definiert wurden. Mit den Cursortasten können Sie nun das gewünschte Betriebssystem auswählen und dann mit (¢) starten. Oft ist GRUB so eingestellt, dass nach einer gewissen Zeit ein Betriebssystem automatisch gestartet wird.
Wenn GRUB einmal läuft, verläuft der eigentliche Linux-Start exakt wie auf einem EFI-Rechner: GRUB lädt den Kernel und startet diesen, wobei es die Initrd-Datei und Kernelparameter übergibt.
Auf einem BIOS-Rechner wird bei der Installation von GRUB der GRUB-Startcode in den Boot-Sektor einer Festplatte oder SSD geschrieben. Die weitere Konfiguration erfolgt wie bei einem EFI-Rechner durch die Datei /boot/grub2/grub.cfg.
Initrd-Dateien
Linux verwendet einen modularisierten Kernel. Viele Zusatzfunktionen – z.B. für die Ansteuerung einer SCSI-Karte, für den Zugriff auf bestimmte Dateisysteme, RAID-Verbunde oder LVM-Partitionen – befinden sich nicht direkt im Kernel, sondern in Modulen. Beim Systemstart ist das aber problematisch: Wie soll der Kernel ein Modul laden, wenn er noch gar nicht in der Lage ist, auf das Dateisystem zuzugreifen? Deswegen werden die für den unmittelbaren Start erforderlichen Module in eine Initial RAM Disk verpackt. Die entsprechende Initrd-Datei übergibt GRUB an den Kernel (Schlüsselwort initrd in der GRUB-Konfigurationsdatei).
Der Kernel und die Initrd-Datei werden im Verzeichnis /boot gespeichert. Die Initrd-Datei muss Kernelmodule enthalten, deren Version exakt mit der Version des Kernels übereinstimmt. Aus diesem Grund muss jedes Mal, wenn ein neuer Kernel installiert oder selbst kompiliert wird, auch eine dazu passende Initrd-Datei erstellt werden. Bei einem Kernel-Update erledigt das das Update-Programm. Wenn Sie den neuen Kernel dagegen selbst installieren, müssen Sie sich auch um die Initrd-Datei selbst kümmern.
Die Bezeichnung »Initrd-Datei« ist bei den meisten aktuellen Distributionen eigentlich falsch: Es handelt sich in Wirklichkeit um initramfs-Dateien, deren Aufbau etwas weiter unten beschrieben wird. Weil aber sowohl die GRUB-Optionen als auch die Kommandos zum Erzeugen der Dateien den Begriff initrd nutzen und der Kernel die Datei trotz der falschen Bezeichnung korrekt interpretiert, bleibe ich in diesem Buch ebenfalls bei dieser Bezeichnung – gewissermaßen wider besseres Wissen.
Die Initrd-Datei ist nicht immer zwingend erforderlich: Wenn Ihr Kernel alle Komponenten enthält, die während des Boot-Prozesses erforderlich sind, gelingt der Start auch ohne Initrd-Datei. Dazu muss der Kernel aber entsprechend kompiliert sein – und genau das ist bei den meisten Distributionen nicht der Fall.
Bedauerlicherweise ist die Erzeugung von Initrd-Dateien nicht standardisiert. Jede Distribution verwendet ihre eigenen Werkzeuge. Die Initrd-Dateien enthalten nicht nur Kernelmodule, sondern auch Scripts zur Hardware-Initialisierung und unter Umständen ein minimales Rescue-System, sodass Rettungsarbeiten selbst dann durchgeführt werden können, wenn das Einbinden der Systempartition nicht gelingt.
Unter Debian und Ubuntu ist zur Erzeugung und Administration der Initrd-Dateien das Script update-initramfs vorgesehen. Im einfachsten Fall geben Sie einfach nur die Option -u an, um die Initrd-Datei der aktuellsten installierten Kernelversion zu aktualisieren. Wenn Sie die Initrd-Datei für eine andere Kernelversion aktualisieren möchten, geben Sie die Versionsnummer mit -k an. -k all aktualisiert die Initrd-Dateien für alle installierten Kernelversionen.
Mit den Optionen -c bzw. -d erzeugt update-initramfs eine neue Initrd-Datei bzw. löscht eine vorhandene Initrd-Datei. In diesem Fall ist die Angabe der Kernelversion durch -k zwingend erforderlich.
Hinter den Kulissen greift update-initramfs auf das Script mkinitramfs zurück, um Initrd-Dateien zu erzeugen. Die Basiskonfiguration erfolgt in /etc/initramfs-tools/initramfs.conf sowie durch die Dateien in /etc/initramfs-tools/conf.d. Darüber hinaus werden der Initrd-Datei alle in /etc/initramfs-tools/modules aufgezählten Module hinzugefügt (ein Modul pro Zeile).
mkinitramfs erzeugt in der Standardkonfiguration mit MODULES=most in initramfs.conf ziemlich große Initrd-Dateien mit unzähligen Kernelmodulen. Sollten Sie mkinitramfs direkt aufrufen, müssen Sie zumindest den Namen der neuen Initrd-Datei übergeben (Option -o). Wenn die Initrd-Datei nicht für die aktuelle Kernelversion erzeugt werden soll, geben Sie zusätzlich die gewünschte Version an:
Fedora, RHEL/CentOS sowie SUSE/openSUSE verwenden dracut zur Erzeugung der Initrd-Datei. dracut wird bei jedem Kernel-Update automatisch ausgeführt. Das Kommando dracut berücksichtigt die Einstellungen aus /etc/dracut.conf. Um für einen selbst kompilierten Kernel 4.3.1 in der Datei /boot/vmlinuz-4.3.1 manuell eine Initrd-Datei zu erzeugen, führen Sie das folgende Kommando aus:
Dracut erzeugt kompakte Initrd-Dateien, die nur solche Kernelmodule enthalten, die im laufenden Betrieb aktiv sind. Das kann nach Hardware-Erweiterungen zu Boot-Problemen führen. Aus diesem Grund gibt es für das Rescue-System eine spezielle Initrd-Datei mit viel mehr Modulen. Falls der gewöhnliche Boot-Prozess nach einem Hardware-Umbau scheitern sollte, booten Sie das Rettungssystem und führen dann das folgende Kommando aus:
Wenn eine Distribution ein Kernel-Update durchführt und sich dadurch der Name der Kerneldatei ändert, muss auch die GRUB-Menüdatei entsprechend geändert und eine zum neuen Kernel passende Initrd-Datei erzeugt werden. Alle gängigen Distributionen erledigen diese Aufgaben im Rahmen der Update-Verwaltung automatisch, sodass beim nächsten Neustart des Rechners automatisch der neue Kernel verwendet wird. Bei vielen Distributionen gibt es für den alten Kernel weiterhin einen GRUB-Menüeintrag, damit bei Update-Problemen eine Möglichkeit besteht, das System mit dem alten Kernel weiterzunutzen.
Initrd-Dateien werden intern als initramfs-Dateien dargestellt. Die Initrd-Datei ist eine komprimierte Archivdatei (cpio-Datei), die aus diversen Verzeichnissen und Dateien zusammengesetzt ist. Wenn Sie sich den Inhalt des Archivs ansehen möchten, gehen Sie so vor: