• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

GRUB von MBR nach Boot-Partition verschieben

gehrke

Administrator
Teammitglied
Moin *,

ich habe ein System, bei welchem GRUB2 in den MBR von Platte X installiert wurde.

Nun möchte ich, dass dies auf die Boot-Partition (sdX1) verschoben wird. Wie kann ich das erreichen?

Erster Ansatz etwa so...

MBR-Eintrag löschen:
Code:
dd if=/dev/null of=/dev/sdX bs=446 count=1
GRUB in die Boot-Partition installieren:
Code:
grub-install /dev/sdX1

Würde das schon reichen? Muss ich noch was mit fdisk an den 'bootable'-Flags machen?
TNX


cu, gehrke
 

TomcatMJ

Guru
Also bei GRUb Legacy würde das in Kombination mit dem bootable-Flag für die beabsichtigte Partition die dann den Bootloader beheimaten sollte dann ausreichen. Mir fällt jetzt zumindest kein Grund ein warum das nicht auch für GRUB 2 gelten sollte ;)
Man darf halt nur nicht vergessen eine Partition mit Bootloader dann auch auf bootable zu setzen sonst bootet da gar nichts mangels Bootloader im Platten-MBR
 
OP
gehrke

gehrke

Administrator
Teammitglied
admine schrieb:
Ich würde das YaST machen lassen => Boot Loader Location.
Oops. Ich habe vergessen zu erwähnen, dass das Verfahren nicht nur mit Susi funktionieren darf. :eek:ps:
Sorry...
 
Guckst Du hier... Wenn ich das richtig verstehe kannst Du aus einer "einfachen" Partition nur mit einem anderen Bootloader grub2 aufrufen aber nicht direkt booten. Das deckt sich auch mit meiner Erfahrung das selbst bei grub1 die Installation in eine Boot-Partition nur dann klappt wenn grub noch den generischen Code in den MBR schreiben darf. Unter Autoyast heißt der Punkt <generic_mbr>true</generic_mbr> und ist unter Yast automatisch aktiviert und gut versteckt. Fehlt dieser Eintrag, startet grub nicht mal.

Welchen Sinn soll es denn haben grub2 nicht im MBR zu haben? Alle mir bekannten Systeme lassen sich über grub starten und sei es mittels chainload. os-prober arbeitet, zumindest unter debian-sid, recht zuverläßig und im Zweifel kann man noch an der 41_custom per Hand schrauben.
 

josef-wien

Ultimate Guru
gehrke schrieb:
dd if=/dev/null of=/dev/sdX bs=446 count=1
Damit erreichst Du nur, daß von der Festplatte gar nicht mehr gestartet werden kann. Im MBR der im BIOS definierten Boot-Platte muß ein Boot-Code (in der Länge von maximal 440 Bytes) enthalten sein. Einen generischen Boot-Code (der die erste "aktive" primäre Partition [die auch eine erweiterte sein kann] sucht und deren Boot-Code ausführt) findest Du bei openSUSE in /usr/lib/boot, ob es das bei anderen Distributionen auch gibt, kann ich nicht sagen.

Geier0815 schrieb:
Welchen Sinn soll es denn haben grub2 nicht im MBR zu haben?
Wie hier im Forum zu lesen war, funktioniert ein Update bestimmter Windows-Versionen nur dann, wenn ein generischer Boot-Code vorhanden ist (ich weiß nicht mehr, ob es nicht sogar Microsofts eigene Version sein muß).
 
OP
gehrke

gehrke

Administrator
Teammitglied
Geier0815 schrieb:
Welchen Sinn soll es denn haben grub2 nicht im MBR zu haben? Alle mir bekannten Systeme lassen sich über grub starten und sei es mittels chainload. os-prober arbeitet, zumindest unter debian-sid, recht zuverläßig und im Zweifel kann man noch an der 41_custom per Hand schrauben.

Die Frage hat 'josef-wien' andeutungsweise beantwortet - irgendwas mit Windows...

Ich selbst habe das noch nie gemacht, stattdessen immer mit dem MBR gearbeitet und liege da ganz auf Deiner Linie. Ich wollte es für einen Artikel im Wiki testen, aber da es zum einen scheinbar nicht so einfach ist und zum anderen mir selbst der Anwendungsfall nicht zwingend erscheint, lasse ich bis auf Weiteres die Finger davon.

Vielen Dank für Eure Antworten.

cu, gehrke
 
A

Anonymous

Gast
Ich arbeite zwar nicht mit grub2, hab aber schon hin und wieder mal im Quellcode gestöbert. Gefunden habe im Netz uA. solche Sätze:
"Installing GRUB2 in a partition is not recommended and generally considered to be a bad idea."

Grub2 besteht aus den 400undzerquetschten Byte (Stage1) die normalerweise im MBR geschrieben werden, und hinter der Partitionstabelle und vor der ersten Partition werden noch bis zu 31KB von Grub2 geschrieben. Dieses ist der Grub-core ( der eigentliche Grubkernel) der dann auch von dort ausgeführt wird und je nach Bedarf noch einige Grubmodule, die zusammen gebunden und komprimiert dort vorne außerhalb jeglicher Kontrolle durch User und irgendwelche Dateisysteme abgelegt werden. Also ähnlich Grub1 die stage1.5-Dateien. Nur ist Grub2 ein Baukastensystem mit vielerlei Modulen und es ließen sich sicherlich noch ein paar dazu entwickeln, und durch die Kombination von Core und verschiedener Module und zusätzlicher Komprimierung ist dieser Bereich dort außerhalb der Dateisysteme sogut wie nicht auf Plausibilität zu prüfen. (zB durch Quercheck der Bytes die dort stehen mit Dateien in /boot/grub ). Das ist praktisch eine offene Einladung zum schreiben von Bootviren und Infiltrations Software über den Bootloader. (ist meine Meinung, noch darf ja jeder seine eigene haben ;) )

Die andere Möglichkeit ist den Bootloader (Stage1) an den Beginn einer Partition zu schreiben und den komprimierten Grubcore innerhalb des boot Dateisystems zu belassen und dort über feste Blocknummern aus der Stage1 anzusprechen und zu nutzen, wie es bei Grub1 und den stage1.5 auch möglich gewesen war, aber das ist immer riskant und wird ungern genommen, da diese Datei dann nicht verschoben werden darf, ohne das Stage1 von Grub neu angepasst und installiert wird. Die Datei müsste also am besten im Dateisystem immutabel gemacht werden, und das lässt sich nicht immer wirklich mit jedem Dateisystemtype bewerkstelligen, bzw die Filesystemchecker haben da manchmal auch was dagegen.

Mischformen, Stage1 in Partition und die restlichen bis zu 31KB vor die erste Partition zwar auch denkbar, nichts dazu gefunden ?????

Ein paar Stellen aus dem Quelltext:
grub-setup.c schrieb:
]if (! dest_partmap && ! fs && !is_ldm)
{
grub_util_warn ("%s", _("Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea."));
goto unable_to_embed;
}
grun.info schrieb:
The partition table format traditionally used on PC BIOS platforms is
called the Master Boot Record (MBR) format; this is the format that
allows up to four primary partitions and additional logical partitions.
With this partition table format, there are two ways to install GRUB:
it can be embedded in the area between the MBR and the first partition
(called by various names, such as the "boot track", "MBR gap", or
"embedding area", and which is usually at least 31 KiB), or the core
image can be installed in a file system and a list of the blocks that
make it up can be stored in the first sector of that partition.

Each of these has different problems. There is no way to reserve
space in the embedding area with complete safety, and some proprietary
software is known to use it to make it difficult for users to work
around licensing restrictions; and systems are sometimes partitioned
without leaving enough space before the first partition. On the other
hand, installing to a filesystem means that GRUB is vulnerable to its
blocks being moved around by filesystem features such as tail packing,
or even by aggressive fsck implementations, so this approach is quite
fragile; and this approach can only be used if the `/boot' filesystem
is on the same disk that the BIOS boots from, so that GRUB does not
have to rely on guessing BIOS drive numbers.

The GRUB development team generally recommends embedding GRUB before
the first partition, unless you have special requirements. You must
ensure that the first partition starts at least 31 KiB (63 sectors)
from the start of the disk; on modern disks, it is often a performance
advantage to align partitions on larger boundaries anyway, so the first
partition might start 1 MiB from the start of the disk.

Ich habe mal versucht sowas im Forum zu finden, scheint aber jeder soweiso und gleich in den MBR zu installieren, hab jedenfalls so leicht nichts anderes gefunden.
Vielleicht versucht das mal jemand auf einer nicht ganz so wichtigen Maschine Grub2 in eine "normale" Paritition zu installieren (erweiterte Partition dürfte eventuell einfacher funktionieren), so wie ich den Quelltext und die Doku dazu interpretiere ohne mich tiefer reinzuhacken, es sollte theoretisch zwar möglich sein, aber wohl mindestens dicke Warnmeldungen heraus schreiben, wenn's nicht sogar ganz abgewiesen wird, oder das es überhaupt nur mit --force zu installieren geht.

robi
 
Oben