Der Bootvorgang mit Grub2

I

Ivi

Jungspund
Hi, in den Weites des Netzes habe ich ein paar Ablaugschemata für den Bootprozess gefunden, die ich in etwas so lesen: das Bios startet den MBR der Bootplatte, dieser lädt aus dem Volume Boot Record der aktiven Partition den Bootloader, welcher seinerseits den Kernel und ggf. weitere Sachen lädt und das OS startet. In diesen Übersichten wird der verborgene Bereich nie erwähnt.

In anderen heißt es, dass die boot.img in die ersten 446 Bytes des MBR und die core.img in den verborgenen Bereich geschrieben werden. Die core.img wurde per grub-mkimage aus dem Kernel-Image und weiteren Modulen gebaut und kann direkt auf das Dateisystem zugreifen und die Grub-Konfig sowie den Kernel laden. Hier wird der Volume Boot Record nicht erwähnt.

Es gibt weiterhin Anleitungen um Grub in den Startsektor der Partition und nicht der Festplatte zu installieren. Ich vermute hier ist VBR statt MBR (inkl. verborgener Bereich??) gemeint. Was soll das bringen? Da das Bios den MBR ausführt macht doch diese Methode nur Sinn wenn der BL im MBR (und evtl. im verborgenen Bereich??) Grub vom VBR starten kann. Sehe ich das richtig? Falls ich richtig liege müsste das ab Win8 gehen und es würde ausreichen den Win8-BL entsprechend abzuändern, dass er weiß wo Grub liegt. Was genau wird denn dann in den VBR kopiert. Wieder nur die boot.img? Wo ist dann die core.img?
 
Grundsätzlich wird grub in Stufen geladen (Stages) boot.img enthält den code für Stufe 1 core.img enthält den code für Stufe 2 und dann wird /boot gemountet und lädt Stufe 3 und das ganze bunte grafische Zeugs. Weil im MBR nur diese 446 Byte für den Bootloader zur Verfügung stehen und das ganze bunte Zeug keinen Platz hat. Die Nummerierung der Stages ist etwas abweichend.

Das andere nennt sich Chainloading. Ein Bootloader läd einen anderen. Hier der aus dem MBR den aus dem VBR.

Hierzu müsstest du grub (somit boot.img, core.img und den Inhalt von /boot) alle samt in die Partition installieren.

Wie was wohin macht grub-install dann automatisch, wenn du die Partition als Parameter angibst.

Dann kommts darauf an wie du den von Windows konfigurieren musst um den Bootloader zu laden.... das weiß ich nicht [emoji16]
 
Hallo

Falls ich richtig liege müsste das ab Win8 gehen und es würde ausreichen den Win8-BL entsprechend abzuändern, dass er weiß wo Grub liegt.

Das geht doch schon vor win8, also das du von win linux booten kannst.

mfg
schwedenmann
 
@ florian

Das ist leider nur das was ich in teils anderen Worten im Netz gefunden habe. Was wird denn in den MBR, in den verborgenen Bereich und in den VBR der Systempartition geschrieben?

Der VBR ist dich (außer bei 4Kn-Platten) auch nur 512 Bytes groß. Wenn boot.img, core.img und der Rest nicht in den MBR passen, wie soll das alles dann in den VBR passen? Mich würde interessieren was in diesem Fall wohin kommt.

@schwedenmann

Wusste ich nicht. Hätte nicht gedacht,dass MS sowas mal einbaut.
 
Angenommen du installierst es in den MBR

Boot.img > MBR
Core.img > Boot Partition
Rest > Boot Partition

VBR:
Boot.img > VBR
Core.omg > PartitionX
Rest > auch PartitionX

Boot.img läd core.img mit trivialen Treibern. Daher muss boot auch FAT sein. Core.img läd dann mehr Treiber nach um Root mounten zu können und läd den Rest aus Boot. Ich versteh dein Problem nicht [emoji12]
 
Hallo


Teilweise wird, bzw. kann man heute den MBR ja 2048byte groß machen, bzw. 2024 Byte frei klassen, vor der 1. Phys. Partition, dann ist genug Platz für grub2, denn im normalen MBR (448 +xy= 512byte) kann es bei grub2 eng werden. afaik läßt gparted z.B. 1024 oder 2048 byte vor der 1. Partition frei, bzw. läßt die 1. Partition eben erst bei Sektor xy anfangen und nicht bei 0. Wenn du UEFI undGPT benutzt, sieht das Gnaze wieder etwas abders aus.

Bei normaler Dos-Partitionstabell, MBR und ohne UEFI ist das gnaze trivial und du benbötigst ncoh nciht mal einen "größeren" MBR oder eine separate unformatierte "Bios-grub" Partition.


mfg
schwedenmann
 
@florian0285

es wird ja aber nicht immer eine separate bootpartition verwendet. Was wenn keine genutzt wird und grub in den mbr soll. Boot.img liegt im mbr. Und core.img? Welche rolle spielt in dieser konstellation?

zum anderen bsp. mit partition x meinst du die systempartition den linux?

@ schwedenmann

deswegen wird doch der mbr keine 2048kb groß. Der ist immer 512 byte groß, außer bei nativen 4k-platten. Du meinst wenn die erste partition bei sektor 2048 beginnt vergrößert sich der bereich zwischen mbr und partition (verborgener bereich). die frage ist weiterhin ob core.img, wenn keine bootpartition verwendet wird, in diesen verborgenen bereich geschrieben wird (standardmäßig).
 
Hallo

ob core.img, wenn keine bootpartition verwendet wird, in diesen verborgenen bereich geschrieben wird (standardmäßig).

ne, core.img wird in die /boot geschrieben, egal ob /boot auf separater Partition liegt oder nicht. Schau dir doch mal /boot an, odrt den ordner /grub/i386

Problem bei grub2 kann sein, das eben der MBR zu klein ist, grub2 ist eben zu grub1 fett geworden.

mfg
schwedenmann
 
Core.img liegt auf einer für boot.img erreichbaren Partition... Es ist egal ob boot root oder was auch immer. Sie muss nur bootbar sein und ein Filesystem haben mit dem der bootloader in Stage 1 klar kommt. Deshalb nimmt man i. R. eine FAT Partition am Anfang.

Partition X ist die Nummer der Partition, die je nach OS anders dargestellt wird. In Linux sdxX... meistens...

Dass Grub2 den MBR auf 2048KB erweitert wäre mir nicht aufgefallen. Im Prinzip wäre es aber denkbar. Man sollte bei dieser Lösung nur mögliche entstehende Kompatibilitätsprobleme im Hinterkopf behalten.
 
Hallo

ich habe gerade nochmal per gparted mein FS angeschaut, sda1 fängt bei mir bei Sektor 2048 an. Geparted läßt also von sich aus schon etwas Luft für grub zwischen MBR und 1. Partition.

mfg
schwedenmann
 
Ist aber schon seit Jahren Standard, dass die1. Partition bei Sektor 2048 beginnt. Windows XP z. B. ließ die noch bei 63 beginnen, was Alignmentprobleme bei emulierten 512 Byte-Sektoren mit such brachte. Der MBR ist dennoch nur 512 Bytes groß.

Wenn die core.img in einer für Stage 1 verfügbaren Partition liegt, kann es aber nicht die Systempartition sein. Diese kann ja auch ext4 sein. Ich interpretiere als Stage 1 jetzt mal das, was Grub2 in den MBR schreibt. Anders wäre es, wenn noch zusätzlicher Code zwischen MBR und 1. Partition liegt, der dann Module für den Zugriff auf das Dateisystem mitliefert. Ist dem so? Wie nennt sich das bei Grub2 dann?

Alle meine Ubuntuinstallationen wurde ohne Bootpartition erstellt. Da die core.img wie oben geschrieben im Systemverzeichnis liegt muss also noch "etwas" geben, neben boot.img im MBR und core.img in der Systempartition um den Zugriff auf die Systempartition zu gewährleisten. Weiß einer was das ist?
 
Hallo

neben boot.img im MBR und core.img in der Systempartition um den Zugriff auf die Systempartition zu gewährleisten.

Das dürften diese Dateien sein: in /boot/grub/i386-pc/jfs.mod, xfs.mod, zfs.mod, usw.
Deswegen braucht man Im Grunde keine separate /boot bei grub2, da dieser Bootloader mit diversen Dateisystem umgehen an, anders als grub1. Aber eine separate /boot kan aus anderen Gründen nützlich sein.

mfg
schwedenmann
 
Wie gesagt es ist nur Voraussetzung, dass grub stage1 auf die daten von stage 2 (eigentlich 1.5) zugreifen kann. Welches dateisystem das ist ist erstmal egal solange es unterstützt wird. In der Regel nimmt man einfach FAT.

Ja die 2048 sind mir nie aufgefallen [emoji16]
kommt vor [emoji12]
 

Ähnliche Themen

Sicherung der Systempartition inkl. Bootloader + ein paar Verständnisfragen

Linux "vergisst" Dateisystem?

Grub1 im MBR, Grub2 in Partition: Ubuntu Studio nicht mehr bootbar

Linuxinstalltion auf einem alten Notebook

Gespenstisch-Systeme starten nicht

Zurück
Oben