Ich habe in letzter Zeit mit Debian herumprobiert, da es mir als der logischste Schritt erschien, nachdem ich meine Linux-Reise mit Ubuntu begonnen hatte (ich mag Unity wirklich nicht und es stört mich, GNOME parallel dazu zu installieren, da ich Unity nicht vollständig deinstallieren kann, ohne viele der übrigen Desktop-Funktionen durcheinander zu bringen). Eine Sache hat mich während der Installation immer gestört, nämlich die Option, GRUB zu installieren.
Meiner Ansicht nach sollte dies nicht erforderlich sein und es sollte einfach direkt zum Kernel gebootet werden, wie dies bei Ubuntu und Windows der Fall ist, anstatt dass ich einen auswählen muss und meine Auswahl immer dieselbe ist – die Standardoption.
Während der Installation lautet der Erklärungstext zu dieser Option etwa so: „Wir müssen Debian bootfähig machen“ – was der Hauptgrund dafür ist, warum ich zögere, „Nein“ auszuwählen. Ich möchte auf jeden Fall, dass es bootet! Ich könnte mir die Zeit nehmen und sehen, was passiert, wenn ich „Nein“ auswähle, aber ich denke, es wäre klug, Sie alle zuerst zu fragen.
Ist es sicher, bei der Installation von GRUB „Nein“ auszuwählen? Lässt sich Debian auch dann booten, wenn es nicht installiert ist? Wenn es sicher ist, „Nein“ auszuwählen, gibt es bei dieser Option irgendwelche Nachteile?
Antwort1
Ähm... wie soll ich es sagen. Debian ist eine Linux-Distribution, die auf einem Computer läuft, aber um sie in einen lauffähigen Zustand zu bringen, benötigt man einen Bootloader. Die Distribution läuft im Grunde auf GRUB oder einem anderen Bootloader, bis sie lauffähig ist. Sie können Syslinux als Alternative zu GRUB verwenden.
Antwort2
Um die akzeptierte Antwort zu erweitern …
Wenn ein x86-PC startet, wird seine CPU im 16-Bit-Realmodus ausgeführt und führt den im BIOS gespeicherten Code aus. Nachdem das BIOS POST und die Erstkonfiguration durchgeführt hat, liest es die ersten 512 Bytes vom Anfang der Bootdiskette und überträgt die Ausführung dorthin – der ursprüngliche Code eines Bootloaders soll den Rest erledigen.
Betrachten Sie nunwas ist Rest. Im einfachsten Fall sollte der Bootloader in der Lage sein, das Image des Kernels zu finden, zu laden und die Ausführung dorthin zu übertragen. Der ältere de-facto-Standard-Linux-Loader, lilo, führte eine zusammenhängende Karte aller Sektoren, auf denen der Kernel gespeichert war. Doch seitdem hat sich das Bild ziemlich verändert: Es kamen mehr Dateisysteme in Gebrauch, es wurde üblich, den Kernel auf einem RAID-Gerät oder einer logischen LVM-Festplatte oder einem Stapel dieser zu speichern. Computer begannen, mehr steckbare Festplatten zu haben, was eine beliebige Reihenfolge ihrer Initialisierung und damit Probleme bei der Benennung bedeutet. Nun bedenken Sie, dass heutzutage die Einführung eines generischen Systems auf Linux-Basis einige früh verfügbareBenutzerbereichTools, die auf der sogenannten „initrd“ (Initial RAM Disk) bzw. „Initramfs“ (Initial RAM Filesystem) gespeichert sind, sodass der Bootloader tatsächlich nicht nur den Linux-Kernel, sondern auch ein passendes Initramfs dafür lädt.
Die Aufgabe des Bootloaders besteht also darin:
- Bootstrap selbst – diese 512 Bytes können sinnvollerweise nur etwas Komplizierteres finden und laden.
- Entdecken und initialisieren Sie alle Ebenen, die für den Zugriff auf das Boot-Dateisystem (das Dateisystem, das den Kernel und sein Initramfs enthält) erforderlich sind.
- Laden Sie alles und übertragen Sie dann die Steuerung an den Kernel.
Bedenken Sie nun, dass die meisten Leute es nützlich finden, diesen Prozess irgendwie visualisieren und steuern zu können. Daher muss der Bootloader in der Lage sein, eine Art Menü anzuzeigen und anzupassen, was geladen wird und wie. Die Möglichkeit, einen alternativen Kernel zu laden, könnte ebenfalls ein Bonus sein (ein neuer Kernel, der aus dem Repository der Debian-Sicherheitsupdates installiert wird, entfernt beispielsweise nie den vorhandenen Kernel – dieser wird vielmehr beiseite gelegt und ist zum Booten verfügbar, wenn in einem neuen eine Regression gefunden wird).
Wie man also sieht, ist es nicht sinnvoll, diese Funktionalität direkt in den Kernel zu integrieren, es sei denn, wir haben es mit einer Art eingebettetem System mit sehr engen Speicher-/Speicherplatzanforderungen zu tun, bei dem niemand kontrolliert, wie der Kernel geladen wird. Dies gilt umso mehr, als der Bootloader ein von Natur aus stark von der Hardwareplattform abhängiges Softwareteil ist. Aus diesem Grund gibt es den Bootloader, und auf einem generischen System ist die Notwendigkeit, einen zu verwenden, im Grunde unumgänglich.