Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
GRUB2 - GPT - BIOS Boot Partition
104 views
Skip to first unread message
Thomas Wildgruber
Jan 11, 2013, 5:15:42 PM1/11/13
to
Hi Group,
um Grub2 korrekt auf einer GPT formatierten Festplatte zu installieren, bin
ich den Empfehlungen gefolgt und habe eine BIOS Boot Partition angelegt
(BIOS basiertes System). Laut diversen Tutorials wird hier der Stage 2
Bootlaoder untergebracht.
Grub2 allerdings bringt den Stage 2 Bootloader laut Spezifikation aber in
/boot/grub/core.img unter, was im normalen Dateisystem liegt. Jetzt habe
ich den Inhalt der BIOS Boot Partition mit dem Inhalt der Datei
/boot/grub/core.img verglichen und dieser ist tats�chlich identisch
(zumindest was die ersten 512 Byte angeht):
---snip---
# dd if=/boot/grub/core.img bs=1 count=512 | hexdump
0000000 5652 1bbe e881 0139 bf5e 81f4 8b66 832d
0000010 087d 0f00 e284 8000 ff7c 7400 6646 1d8b
0000020 8b66 044d 3166 b0c0 397f 0845 037f 458b
0000030 2908 0845 0166 6605 5583 0004 04c7 0010
0000040 4489 6602 5c89 6608 4c89 c70c 0644 7000
0000050 c750 0444 0000 42b4 13cd 820f 00af 00bb
0000060 eb70 6666 458b 6604 c009 850f 0097 8b66
0000070 6605 d231 f766 8834 0a54 3166 66d2 74f7
0000080 8804 0b54 4489 3b0c 0844 797d 048b 442a
0000090 390a 0845 037f 458b 2908 0845 0166 6605
00000a0 5583 0004 548a c00d 06e2 4c8a fe0a 08c1
00000b0 8ad1 0c6c 525a 748a 500b 00bb 8e70 31c3
00000c0 b4db cd02 7213 8c46 8ec3 0a45 c158 05e0
00000d0 4501 600a c11e 03e0 c189 ff31 f631 db8e
00000e0 f3fc 1fa5 23be e881 0057 8361 087d 0f00
00000f0 2485 83ff 0cef 16e9 beff 8125 42e8 5a00
0000100 00ea 0082 be00 8128 36e8 eb00 be06 812d
0000110 2ee8 be00 8132 28e8 eb00 6cfe 616f 6964
0000120 676e 2e00 0d00 000a 6547 6d6f 5200 6165
0000130 0064 4520 7272 726f bb00 0001 0eb4 10cd
0000140 8a46 3c04 7500 c3f2 0000 0000 0000 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0002 0000 0000 0000 002e 0820
---snap---
---snip---
# dd if=/dev/sda1 bs=1 count=512 | hexdump
0000000 5652 1bbe e881 0139 bf5e 81f4 8b66 832d
0000010 087d 0f00 e284 8000 ff7c 7400 6646 1d8b
0000020 8b66 044d 3166 b0c0 397f 0845 037f 458b
0000030 2908 0845 0166 6605 5583 0004 04c7 0010
0000040 4489 6602 5c89 6608 4c89 c70c 0644 7000
0000050 c750 0444 0000 42b4 13cd 820f 00af 00bb
0000060 eb70 6666 458b 6604 c009 850f 0097 8b66
0000070 6605 d231 f766 8834 0a54 3166 66d2 74f7
0000080 8804 0b54 4489 3b0c 0844 797d 048b 442a
0000090 390a 0845 037f 458b 2908 0845 0166 6605
00000a0 5583 0004 548a c00d 06e2 4c8a fe0a 08c1
00000b0 8ad1 0c6c 525a 748a 500b 00bb 8e70 31c3
00000c0 b4db cd02 7213 8c46 8ec3 0a45 c158 05e0
00000d0 4501 600a c11e 03e0 c189 ff31 f631 db8e
00000e0 f3fc 1fa5 23be e881 0057 8361 087d 0f00
00000f0 2485 83ff 0cef 16e9 beff 8125 42e8 5a00
0000100 00ea 0082 be00 8128 36e8 eb00 be06 812d
0000110 2ee8 be00 8132 28e8 eb00 6cfe 616f 6964
0000120 676e 2e00 0d00 000a 6547 6d6f 5200 6165
0000130 0064 4520 7272 726f bb00 0001 0eb4 10cd
0000140 8a46 3c04 7500 c3f2 0000 0000 0000 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0023 0000 0000 0000 002e 0820
---snap---
Jetzt stelle ich mir die Frage, warum Grub2 (angeblich) auf diese Partition
besteht, wenn der gleiche Inhalt noch einmal im regul�ren Dateisystem zu
finden ist.
Thx & Bye Tom
--
"Manches Gewissen ist nur rein, weil es nie benutzt wurde" (Robert Lembke)
um Grub2 korrekt auf einer GPT formatierten Festplatte zu installieren, bin
ich den Empfehlungen gefolgt und habe eine BIOS Boot Partition angelegt
(BIOS basiertes System). Laut diversen Tutorials wird hier der Stage 2
Bootlaoder untergebracht.
Grub2 allerdings bringt den Stage 2 Bootloader laut Spezifikation aber in
/boot/grub/core.img unter, was im normalen Dateisystem liegt. Jetzt habe
ich den Inhalt der BIOS Boot Partition mit dem Inhalt der Datei
/boot/grub/core.img verglichen und dieser ist tats�chlich identisch
(zumindest was die ersten 512 Byte angeht):
---snip---
# dd if=/boot/grub/core.img bs=1 count=512 | hexdump
0000000 5652 1bbe e881 0139 bf5e 81f4 8b66 832d
0000010 087d 0f00 e284 8000 ff7c 7400 6646 1d8b
0000020 8b66 044d 3166 b0c0 397f 0845 037f 458b
0000030 2908 0845 0166 6605 5583 0004 04c7 0010
0000040 4489 6602 5c89 6608 4c89 c70c 0644 7000
0000050 c750 0444 0000 42b4 13cd 820f 00af 00bb
0000060 eb70 6666 458b 6604 c009 850f 0097 8b66
0000070 6605 d231 f766 8834 0a54 3166 66d2 74f7
0000080 8804 0b54 4489 3b0c 0844 797d 048b 442a
0000090 390a 0845 037f 458b 2908 0845 0166 6605
00000a0 5583 0004 548a c00d 06e2 4c8a fe0a 08c1
00000b0 8ad1 0c6c 525a 748a 500b 00bb 8e70 31c3
00000c0 b4db cd02 7213 8c46 8ec3 0a45 c158 05e0
00000d0 4501 600a c11e 03e0 c189 ff31 f631 db8e
00000e0 f3fc 1fa5 23be e881 0057 8361 087d 0f00
00000f0 2485 83ff 0cef 16e9 beff 8125 42e8 5a00
0000100 00ea 0082 be00 8128 36e8 eb00 be06 812d
0000110 2ee8 be00 8132 28e8 eb00 6cfe 616f 6964
0000120 676e 2e00 0d00 000a 6547 6d6f 5200 6165
0000130 0064 4520 7272 726f bb00 0001 0eb4 10cd
0000140 8a46 3c04 7500 c3f2 0000 0000 0000 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0002 0000 0000 0000 002e 0820
---snap---
---snip---
# dd if=/dev/sda1 bs=1 count=512 | hexdump
0000000 5652 1bbe e881 0139 bf5e 81f4 8b66 832d
0000010 087d 0f00 e284 8000 ff7c 7400 6646 1d8b
0000020 8b66 044d 3166 b0c0 397f 0845 037f 458b
0000030 2908 0845 0166 6605 5583 0004 04c7 0010
0000040 4489 6602 5c89 6608 4c89 c70c 0644 7000
0000050 c750 0444 0000 42b4 13cd 820f 00af 00bb
0000060 eb70 6666 458b 6604 c009 850f 0097 8b66
0000070 6605 d231 f766 8834 0a54 3166 66d2 74f7
0000080 8804 0b54 4489 3b0c 0844 797d 048b 442a
0000090 390a 0845 037f 458b 2908 0845 0166 6605
00000a0 5583 0004 548a c00d 06e2 4c8a fe0a 08c1
00000b0 8ad1 0c6c 525a 748a 500b 00bb 8e70 31c3
00000c0 b4db cd02 7213 8c46 8ec3 0a45 c158 05e0
00000d0 4501 600a c11e 03e0 c189 ff31 f631 db8e
00000e0 f3fc 1fa5 23be e881 0057 8361 087d 0f00
00000f0 2485 83ff 0cef 16e9 beff 8125 42e8 5a00
0000100 00ea 0082 be00 8128 36e8 eb00 be06 812d
0000110 2ee8 be00 8132 28e8 eb00 6cfe 616f 6964
0000120 676e 2e00 0d00 000a 6547 6d6f 5200 6165
0000130 0064 4520 7272 726f bb00 0001 0eb4 10cd
0000140 8a46 3c04 7500 c3f2 0000 0000 0000 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0023 0000 0000 0000 002e 0820
---snap---
Jetzt stelle ich mir die Frage, warum Grub2 (angeblich) auf diese Partition
besteht, wenn der gleiche Inhalt noch einmal im regul�ren Dateisystem zu
finden ist.
Thx & Bye Tom
--
"Manches Gewissen ist nur rein, weil es nie benutzt wurde" (Robert Lembke)
Burkhard Müller
Jan 11, 2013, 6:58:06 PM1/11/13
to
*Thomas Wildgruber* wrote:
> Hi Group,
>
> um Grub2 korrekt auf einer GPT formatierten Festplatte zu installieren, bin
> ich den Empfehlungen gefolgt und habe eine BIOS Boot Partition angelegt
> (BIOS basiertes System). Laut diversen Tutorials wird hier der Stage 2
> Bootlaoder untergebracht.
>
> Grub2 allerdings bringt den Stage 2 Bootloader laut Spezifikation aber in
> /boot/grub/core.img unter, was im normalen Dateisystem liegt. Jetzt habe
> ich den Inhalt der BIOS Boot Partition mit dem Inhalt der Datei
> /boot/grub/core.img verglichen und dieser ist tats�chlich identisch
> (zumindest was die ersten 512 Byte angeht):
[..snip..]
> Hi Group,
>
> um Grub2 korrekt auf einer GPT formatierten Festplatte zu installieren, bin
> ich den Empfehlungen gefolgt und habe eine BIOS Boot Partition angelegt
> (BIOS basiertes System). Laut diversen Tutorials wird hier der Stage 2
> Bootlaoder untergebracht.
>
> Grub2 allerdings bringt den Stage 2 Bootloader laut Spezifikation aber in
> /boot/grub/core.img unter, was im normalen Dateisystem liegt. Jetzt habe
> ich den Inhalt der BIOS Boot Partition mit dem Inhalt der Datei
> /boot/grub/core.img verglichen und dieser ist tats�chlich identisch
> (zumindest was die ersten 512 Byte angeht):
> Jetzt stelle ich mir die Frage, warum Grub2 (angeblich) auf diese Partition
> besteht, wenn der gleiche Inhalt noch einmal im regul�ren Dateisystem zu
> finden ist.
Backup?
> besteht, wenn der gleiche Inhalt noch einmal im regul�ren Dateisystem zu
> finden ist.
Sven Hartge
Jan 12, 2013, 6:18:11 AM1/12/13
to
Thomas Wildgruber <excp...@web.de> wrote:
> um Grub2 korrekt auf einer GPT formatierten Festplatte zu
> installieren, bin ich den Empfehlungen gefolgt und habe eine BIOS Boot
> Partition angelegt (BIOS basiertes System). Laut diversen Tutorials
> wird hier der Stage 2 Bootlaoder untergebracht.
> Grub2 allerdings bringt den Stage 2 Bootloader laut Spezifikation aber
> in /boot/grub/core.img unter, was im normalen Dateisystem liegt. Jetzt
> habe ich den Inhalt der BIOS Boot Partition mit dem Inhalt der Datei
> /boot/grub/core.img verglichen und dieser ist tatsächlich identisch
> um Grub2 korrekt auf einer GPT formatierten Festplatte zu
> installieren, bin ich den Empfehlungen gefolgt und habe eine BIOS Boot
> Partition angelegt (BIOS basiertes System). Laut diversen Tutorials
> wird hier der Stage 2 Bootlaoder untergebracht.
> Grub2 allerdings bringt den Stage 2 Bootloader laut Spezifikation aber
> in /boot/grub/core.img unter, was im normalen Dateisystem liegt. Jetzt
> habe ich den Inhalt der BIOS Boot Partition mit dem Inhalt der Datei
> (zumindest was die ersten 512 Byte angeht):
Die Datei /boot/grub/core.img wird dynamisch erzeugt und dann in den
Bereich nach dem MBR (bei MSDOS-PTs) bzw. in die BIOS Boot Partition
geschrieben.
Daher liegt die Datei dort auch herum, benutzt werden aber beim Booten
die Daten aus den o.g. Plätzen.
S°
--
Sigmentation fault. Core dumped.
Sieghard Schicktanz
Jan 11, 2013, 7:33:01 PM1/11/13
to
Hallo Thomas,
Du schriebst am Fri, 11 Jan 2013 23:15:42 +0100:
> um Grub2 korrekt auf einer GPT formatierten Festplatte zu installieren,
> bin ich den Empfehlungen gefolgt und habe eine BIOS Boot Partition
> angelegt (BIOS basiertes System). Laut diversen Tutorials wird hier der
Hast Du das nicht etwa mit einem _EFI_-basierten System verwechselt?
_Daf�r_ brauchtest Du eine (FAT-) Partition, die den EFI-Boot-Lader
aufnehmen kann. Das kann dann ein grub2 sein, der dort _vollst�ndig_
installiert sein mu�, damit er sich findet.
> Stage 2 Bootlaoder untergebracht.
>
> Grub2 allerdings bringt den Stage 2 Bootloader laut Spezifikation aber in
> /boot/grub/core.img unter, was im normalen Dateisystem liegt. Jetzt habe
Den bringt nicht "grub2" dort unter, sondern das Paket-Management Deiner
Distribution. Der installierte grub "wei�" von diesem Verzeichnis nichts.
> ich den Inhalt der BIOS Boot Partition mit dem Inhalt der Datei
> /boot/grub/core.img verglichen und dieser ist tats�chlich identisch
Das ist zu erwarten.
> (zumindest was die ersten 512 Byte angeht):
Die sind allerdings nicht aussagef�hig, aber das d�rfte auch f�r den Rest
gelten. _Eigentlich_ k�nntest Du nach der Installation des grub(2) das
Paket wieder l�schen. Allerdings m��test Du es dann bei jedem Upgrade wieder
installieren, falls sich dabei was an den in der Konfiguration
eingetragenen Angaben �ndern sollte.
> Jetzt stelle ich mir die Frage, warum Grub2 (angeblich) auf diese
> Partition besteht, wenn der gleiche Inhalt noch einmal im regul�ren
> Dateisystem zu finden ist.
So klarer? Achso, ja - GPT verlangt im allgemeinen EFI, und damit kommt
dieser Rattenschwanz 'rein, so da� Du Dich wohl oder �bel mit der daran
h�ngenden Ratte abfinden mu�t... ;->
--
(Weitergabe von Adressdaten, Telefonnummern u.�. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder �hnlichem)
-----------------------------------------------------------
Mit freundlichen Gr��en, S. Schicktanz
-----------------------------------------------------------
Du schriebst am Fri, 11 Jan 2013 23:15:42 +0100:
> um Grub2 korrekt auf einer GPT formatierten Festplatte zu installieren,
> bin ich den Empfehlungen gefolgt und habe eine BIOS Boot Partition
> angelegt (BIOS basiertes System). Laut diversen Tutorials wird hier der
_Daf�r_ brauchtest Du eine (FAT-) Partition, die den EFI-Boot-Lader
aufnehmen kann. Das kann dann ein grub2 sein, der dort _vollst�ndig_
installiert sein mu�, damit er sich findet.
> Stage 2 Bootlaoder untergebracht.
>
> Grub2 allerdings bringt den Stage 2 Bootloader laut Spezifikation aber in
> /boot/grub/core.img unter, was im normalen Dateisystem liegt. Jetzt habe
Distribution. Der installierte grub "wei�" von diesem Verzeichnis nichts.
> ich den Inhalt der BIOS Boot Partition mit dem Inhalt der Datei
> /boot/grub/core.img verglichen und dieser ist tats�chlich identisch
> (zumindest was die ersten 512 Byte angeht):
gelten. _Eigentlich_ k�nntest Du nach der Installation des grub(2) das
Paket wieder l�schen. Allerdings m��test Du es dann bei jedem Upgrade wieder
installieren, falls sich dabei was an den in der Konfiguration
eingetragenen Angaben �ndern sollte.
> Jetzt stelle ich mir die Frage, warum Grub2 (angeblich) auf diese
> Partition besteht, wenn der gleiche Inhalt noch einmal im regul�ren
> Dateisystem zu finden ist.
dieser Rattenschwanz 'rein, so da� Du Dich wohl oder �bel mit der daran
h�ngenden Ratte abfinden mu�t... ;->
--
(Weitergabe von Adressdaten, Telefonnummern u.�. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder �hnlichem)
-----------------------------------------------------------
Mit freundlichen Gr��en, S. Schicktanz
-----------------------------------------------------------
Sven Hartge
Jan 12, 2013, 8:51:26 AM1/12/13
to
Sieghard Schicktanz <Sieghard....@schs.de> wrote:
> Du schriebst am Fri, 11 Jan 2013 23:15:42 +0100:
>> um Grub2 korrekt auf einer GPT formatierten Festplatte zu
>> installieren, bin ich den Empfehlungen gefolgt und habe eine BIOS
>> Boot Partition angelegt (BIOS basiertes System). Laut diversen
>> Tutorials wird hier der Stage 2 Bootlaoder untergebracht.
> Du schriebst am Fri, 11 Jan 2013 23:15:42 +0100:
>> um Grub2 korrekt auf einer GPT formatierten Festplatte zu
>> installieren, bin ich den Empfehlungen gefolgt und habe eine BIOS
>> Boot Partition angelegt (BIOS basiertes System). Laut diversen
> Hast Du das nicht etwa mit einem _EFI_-basierten System verwechselt?
> aufnehmen kann. Das kann dann ein grub2 sein, der dort _vollständig_
> installiert sein muß, damit er sich findet.
Bei UEFI braucht es diese FAT-Partition.
Für BIOS braucht es diese bios_grub-Partition (Typ EF02), ohne
Dateisystem, wo GRUB seine Stage2 unterbringen kann, da bei der GPT nach
dem MBR kein Freiraum ist, wie er bei der MSDOS-PT existiert.
> So klarer? Achso, ja - GPT verlangt im allgemeinen EFI, und damit
> der daran hängenden Ratte abfinden mußt... ;->
Nope, eine GPT funktioniert wunderbar mit einem normalen BIOS. Der
Dummy-MBR sorgt dafür, dass das BIOS nicht meckert und der Rest vom
Bootloader findet sich dann in dem reservierten bios_grub-Bereich.
Thomas Wildgruber
Jan 12, 2013, 5:23:36 PM1/12/13
to
On Sat, 12 Jan 2013 14:51:26 +0100, Sven Hartge wrote:
>> So klarer? Achso, ja - GPT verlangt im allgemeinen EFI, und damit
>> So klarer? Achso, ja - GPT verlangt im allgemeinen EFI, und damit
>> kommt dieser Rattenschwanz 'rein, so da� Du Dich wohl oder �bel mit
>> der daran h�ngenden Ratte abfinden mu�t... ;->
>
> Nope, eine GPT funktioniert wunderbar mit einem normalen BIOS. Der
> Dummy-MBR sorgt daf�r, dass das BIOS nicht meckert und der Rest vom
> Nope, eine GPT funktioniert wunderbar mit einem normalen BIOS. Der
> Bootloader findet sich dann in dem reservierten bios_grub-Bereich.
Stage 1 befindet sich wohl immer noch im (protected) MBR wie ich das jetzt
rausgelesen habe, lediglich wird dort als Partiontype 0xEE (legacy MBR mit
GPT Header) oder 0xEF (natives GPT) angegeben...
Wenn das erkannt wird, springt der Bootloader an die n�chste Stelle (BIOS
Boot Partition oder EFI Partition) und l�dt Stage 2 des Bootloaders. Das
Einlesen der Partitionstabellen wird dann wohl (noch einmal?) vom OS
erledigt.
...wobei ich aber �ber das BIOS basierte System noch nicht dr�ber
rausgekommen bin. Morgen schaue ich mal ob ich ein EFI System in meiner
VMWare Geschichte virtualisieren kann. Ist wohl blo� eine Zeile in der
VMX-Datei.
Nochmal kurz zur�ck zu dem Inhalt sowohl in /boot/grub/core.img und auch in
der BIOS Boot Partition. Der eigentliche Bootloader befindet sich in der
Boot Partition und das core.img wird daraus generiert? Oder...?
Sven Hartge
Jan 12, 2013, 5:33:21 PM1/12/13
to
Thomas Wildgruber <excp...@web.de> wrote:
> Nochmal kurz zurück zu dem Inhalt sowohl in /boot/grub/core.img und auch in
geschrieben.
> Nochmal kurz zurück zu dem Inhalt sowohl in /boot/grub/core.img und auch in
> der BIOS Boot Partition. Der eigentliche Bootloader befindet sich in der
> Boot Partition und das core.img wird daraus generiert? Oder...?
Umgekehrt. core.img wird generiert und dann in die BIOS Boot Partition
> Boot Partition und das core.img wird daraus generiert? Oder...?
geschrieben.
Thomas Wildgruber
Jan 12, 2013, 5:35:55 PM1/12/13
to
On Sat, 12 Jan 2013 23:33:21 +0100, Sven Hartge wrote:
>> Nochmal kurz zur�ck zu dem Inhalt sowohl in /boot/grub/core.img und auch in
Thx & Bye Tom
--
"Sie wissen, wir leben im Zeitalter der Abk�rzungen. Ehe ist die Kurzform
f�r lateinische "errare humanum est" ("Irren ist menschlich")." (Robert
Lembke)
>> Nochmal kurz zur�ck zu dem Inhalt sowohl in /boot/grub/core.img und auch in
>> der BIOS Boot Partition. Der eigentliche Bootloader befindet sich in der
>> Boot Partition und das core.img wird daraus generiert? Oder...?
>
> Umgekehrt. core.img wird generiert und dann in die BIOS Boot Partition
> geschrieben.
Ah okay, dann h�tten wir das auch abgehakt... :-)
>> Boot Partition und das core.img wird daraus generiert? Oder...?
>
> Umgekehrt. core.img wird generiert und dann in die BIOS Boot Partition
> geschrieben.
Thx & Bye Tom
--
f�r lateinische "errare humanum est" ("Irren ist menschlich")." (Robert
Lembke)
Sieghard Schicktanz
Jan 12, 2013, 8:16:48 PM1/12/13
to
Hallo Sven,
Du schriebst am Sat, 12 Jan 2013 14:51:26 +0100:
> Bei UEFI braucht es diese FAT-Partition.
> F�r BIOS braucht es diese bios_grub-Partition (Typ EF02), ohne
Boot-Lader.
> Nope, eine GPT funktioniert wunderbar mit einem normalen BIOS. Der
> Dummy-MBR sorgt daf�r, dass das BIOS nicht meckert und der Rest vom
neuen Board gleich auf EFI und GPT umgestellt hab'... ;-)
(Aber 's war auch so noch genug Bastelei.)
Jedenfalls Danke f�r die weiterf�hrende Information!
Du schriebst am Sat, 12 Jan 2013 14:51:26 +0100:
> Bei UEFI braucht es diese FAT-Partition.
> Dateisystem, wo GRUB seine Stage2 unterbringen kann, da bei der GPT nach
> dem MBR kein Freiraum ist, wie er bei der MSDOS-PT existiert.
Ach so, das ist der Platzhalter f�r einen an fester Stelle eingetragenen
> dem MBR kein Freiraum ist, wie er bei der MSDOS-PT existiert.
Boot-Lader.
> Nope, eine GPT funktioniert wunderbar mit einem normalen BIOS. Der
> Bootloader findet sich dann in dem reservierten bios_grub-Bereich.
Da hab' ich ja eine ganze Menge Plattenbastelei vers�umt, wie ich mit dem
neuen Board gleich auf EFI und GPT umgestellt hab'... ;-)
(Aber 's war auch so noch genug Bastelei.)
Jedenfalls Danke f�r die weiterf�hrende Information!
Sieghard Schicktanz
Jan 12, 2013, 8:27:26 PM1/12/13
to
Hallo Thomas,
Du schriebst am Sat, 12 Jan 2013 23:23:36 +0100:
> Stage 1 befindet sich wohl immer noch im (protected) MBR wie ich das jetzt
> rausgelesen habe, lediglich wird dort als Partiontype 0xEE (legacy MBR mit
> GPT Header) oder 0xEF (natives GPT) angegeben...
Die "stage1" ist nichts anderes als ein Lader - _der_ Lader, der im MBR
sitzt - der einen fest eingetragenen Plattenbereich an eine feste Adresse im
Speicher schreibt und den dann ausf�hrt.
Das war mit dem alten Partitionierungsschema so und wird hier nicht anders
sein - _kann_ nicht anders sein.
> Wenn das erkannt wird, springt der Bootloader an die n�chste Stelle (BIOS
> Boot Partition oder EFI Partition) und l�dt Stage 2 des Bootloaders. Das
> Einlesen der Partitionstabellen wird dann wohl (noch einmal?) vom OS
> erledigt.
Nein, der eingelesene Bereich _ist_ bereits "stage2" (bei grub2). Die kann
dann selber autonom mit der Platte arbeiten - mu� sie bei GPT ja, weil das
BIOS das nicht unterst�tzt.
Du schriebst am Sat, 12 Jan 2013 23:23:36 +0100:
> Stage 1 befindet sich wohl immer noch im (protected) MBR wie ich das jetzt
> rausgelesen habe, lediglich wird dort als Partiontype 0xEE (legacy MBR mit
> GPT Header) oder 0xEF (natives GPT) angegeben...
sitzt - der einen fest eingetragenen Plattenbereich an eine feste Adresse im
Speicher schreibt und den dann ausf�hrt.
Das war mit dem alten Partitionierungsschema so und wird hier nicht anders
sein - _kann_ nicht anders sein.
> Wenn das erkannt wird, springt der Bootloader an die n�chste Stelle (BIOS
> Boot Partition oder EFI Partition) und l�dt Stage 2 des Bootloaders. Das
> Einlesen der Partitionstabellen wird dann wohl (noch einmal?) vom OS
> erledigt.
dann selber autonom mit der Platte arbeiten - mu� sie bei GPT ja, weil das
BIOS das nicht unterst�tzt.
Sven Hartge
Jan 13, 2013, 8:47:11 AM1/13/13
to
Sieghard Schicktanz <Sieghard....@schs.de> wrote:
> Hallo Sven, Du schriebst am Sat, 12 Jan 2013 14:51:26 +0100:
>> Bei UEFI braucht es diese FAT-Partition.
>> Für BIOS braucht es diese bios_grub-Partition (Typ EF02), ohne
> Hallo Sven, Du schriebst am Sat, 12 Jan 2013 14:51:26 +0100:
>> Bei UEFI braucht es diese FAT-Partition.
>> Dateisystem, wo GRUB seine Stage2 unterbringen kann, da bei der GPT
>> nach dem MBR kein Freiraum ist, wie er bei der MSDOS-PT existiert.
> Ach so, das ist der Platzhalter für einen an fester Stelle
>> nach dem MBR kein Freiraum ist, wie er bei der MSDOS-PT existiert.
> eingetragenen Boot-Lader.
Ja, die bios_grub-Partition ist der Ersatz für den Platz, der bei der
MSDOS-PT ungenutzt direkt zwischen MBR und 1. Partition liegt und der
bei der GPT so nicht existiert.
Thomas Wildgruber
Jan 13, 2013, 9:06:40 AM1/13/13
to
On Sun, 13 Jan 2013 02:27:26 +0100, Sieghard Schicktanz wrote:
>> Stage 1 befindet sich wohl immer noch im (protected) MBR wie ich das jetzt
>> rausgelesen habe, lediglich wird dort als Partiontype 0xEE (legacy MBR mit
>> GPT Header) oder 0xEF (natives GPT) angegeben...
>
> Die "stage1" ist nichts anderes als ein Lader - _der_ Lader, der im MBR
> sitzt - der einen fest eingetragenen Plattenbereich an eine feste Adresse im
> Speicher schreibt und den dann ausf�hrt.
> Das war mit dem alten Partitionierungsschema so und wird hier nicht anders
> sein - _kann_ nicht anders sein.
Aber _der_ Lader im MBR h�ngt doch immer noch vom verwendeten Bootloader
>> Stage 1 befindet sich wohl immer noch im (protected) MBR wie ich das jetzt
>> rausgelesen habe, lediglich wird dort als Partiontype 0xEE (legacy MBR mit
>> GPT Header) oder 0xEF (natives GPT) angegeben...
>
> Die "stage1" ist nichts anderes als ein Lader - _der_ Lader, der im MBR
> sitzt - der einen fest eingetragenen Plattenbereich an eine feste Adresse im
> Speicher schreibt und den dann ausf�hrt.
> Das war mit dem alten Partitionierungsschema so und wird hier nicht anders
> sein - _kann_ nicht anders sein.
ab? Grub2 schreibt da seinen eigenen (Ur-) Lader hin, oder?
>> Wenn das erkannt wird, springt der Bootloader an die n�chste Stelle (BIOS
>> Boot Partition oder EFI Partition) und l�dt Stage 2 des Bootloaders. Das
>> Einlesen der Partitionstabellen wird dann wohl (noch einmal?) vom OS
>> erledigt.
>
> Nein, der eingelesene Bereich _ist_ bereits "stage2" (bei grub2). Die kann
> dann selber autonom mit der Platte arbeiten - mu� sie bei GPT ja, weil das
> BIOS das nicht unterst�tzt.
ich das richtig verstanden habe) entpackt wird und eine Sammlung
Kernelmodule beinhaltet. Demnach sollte doch in Stage 1 irgendwas sitzen,
was Kenntnis davon hat und das core.img auspackt.
Das jetzt in der IT immer alles ein wenn und aber haben muss... ;-)
Sieghard Schicktanz
Jan 13, 2013, 8:05:28 PM1/13/13
to
Hallo Thomas,
Du schriebst am Sun, 13 Jan 2013 15:06:40 +0100:
> Aber _der_ Lader im MBR h�ngt doch immer noch vom verwendeten Bootloader
> ab? Grub2 schreibt da seinen eigenen (Ur-) Lader hin, oder?
Ja, sicher.
> Stage 2 bei Grub2 ist doch dieses omin�se /boot/grub/core.img, was (soweit
> ich das richtig verstanden habe) entpackt wird und eine Sammlung
> Kernelmodule beinhaltet. Demnach sollte doch in Stage 1 irgendwas sitzen,
> was Kenntnis davon hat und das core.img auspackt.
Nein - die "stage2" mu� das schon selber erledigen. Immerhin ist der
"stage1"-Lader ja nur ein paar hundert bytes gro� (maximal etwas �ber 400).
Da ist nicht viel mit Entpacken, der l�dt nur den n�chsten Lader und ruft
den auf. Der mu� dann selber daf�r sorgen, da� alles weitere richtig l�uft,
d.h. wenn der einen gepackten Teil enth�lt, dann mu� er den schon selber
auspacken.
> Das jetzt in der IT immer alles ein wenn und aber haben muss... ;-)
Wie hei�t's doch so sch�n: "Viele Wege f�hren nach Rom". Und wenn einer
1000km lang ist, dann gibt's auch einen, der 39000km hat. ;->
Du schriebst am Sun, 13 Jan 2013 15:06:40 +0100:
> Aber _der_ Lader im MBR h�ngt doch immer noch vom verwendeten Bootloader
> ab? Grub2 schreibt da seinen eigenen (Ur-) Lader hin, oder?
> Stage 2 bei Grub2 ist doch dieses omin�se /boot/grub/core.img, was (soweit
> ich das richtig verstanden habe) entpackt wird und eine Sammlung
> Kernelmodule beinhaltet. Demnach sollte doch in Stage 1 irgendwas sitzen,
> was Kenntnis davon hat und das core.img auspackt.
"stage1"-Lader ja nur ein paar hundert bytes gro� (maximal etwas �ber 400).
Da ist nicht viel mit Entpacken, der l�dt nur den n�chsten Lader und ruft
den auf. Der mu� dann selber daf�r sorgen, da� alles weitere richtig l�uft,
d.h. wenn der einen gepackten Teil enth�lt, dann mu� er den schon selber
auspacken.
> Das jetzt in der IT immer alles ein wenn und aber haben muss... ;-)
1000km lang ist, dann gibt's auch einen, der 39000km hat. ;->
0 new messages