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

Dualbootsystem mit 2 Linuxdistributionen

A

Anonymous

Gast
Hallo,
Bei einem anderen Rechner von mir sind 2 Festplatten eingebaut.
Auf der einen Festplatte ist SuSE Linux 11.2 installiert und auf der 2. Festplatte ist Kubuntu 9.10 installiert.
Dabei muß ich erwähnen dass ich immer auf je einer Festplatte das System installiert habe.

Frage:
Wie kann ich über den Grub der ersten Festplatte die 2. Platte mit Kubuntu einbinden und starten?

Gruß Gerschon
 

lOtz1009

Moderator
Teammitglied
Eigentlich reicht es, wenn du in der /boot/grub/menu.lst von OS 11.2 einen entsprechenden Eintrag für Kubuntu machst.
Den solltest du bei Kubuntu in der /boot/grub/grub.cfg finden (Kubuntu 9.10 nutzt GRUB2, da weiß ich nicht genau, wo die Configs liegen).
 

Tooltime

Advanced Hacker
Ich denke die einfachste Variante ist einfach auf den Bootmechanismus der zweiten Platte zu wechseln. Auf diese Weise kann das System der zweiten Platte beliebig gewechselt werden.
/boot/grub/menu.lst (11.2):
Code:
title Booten von zweiter Platte
    map (hd1) (hd0)
    map (hd0) (hd1)
    rootnoverify (hd1)
    chainloader +1
 

towo

Moderator
Teammitglied
Und wozu das sinnlose ummappen?
Ein einfacher chainload reicht bei einem Linux voll zu!
 

Tooltime

Advanced Hacker
Wenn im MBR sich nur der generische Bootcode befindet, der auf die aktive Partition verzweigt, muss meiner Meinung nach auch die Reihenfolge der Platten getauscht werden.

Auch die Verbindung der ersten Grubstufe zu den Filesystemtreibern dürfte über die Reihenfolge im BIOS geschehen. Ich gehe mal davon aus das vor der Installation der jeweiligen Systeme, die entsprechende Platte im Bios als Bootplatte ausgewählt war, ansonsten hätten sich die Systeme um den MBR der Bootplatte geschlagen.
 

towo

Moderator
Teammitglied
Unfug!
chainload verweist auf den MBR der anderen Platte!
Mapping ist nur für "dumme" OS' nötig, wie Windows, weil Win nur von der, von sich aus gesehenen, 1. Platte startet.
Linux ist es völlig egal, von welcher Platte es startet.
 

Tooltime

Advanced Hacker
Das sehe ich ein bisschen anders. Es geht um den Code der ersten grub-Stufe, der auch wie der generische Bootloader in den MBR passen muss, was sind das 300-Byte. Die Verzweigung zur nächsten Bootloaderstufe geschieht meines Wissens über die direkte Adressierung BIOS-Gerät und Datenblock auf Gerät. Allein eine Änderung der Bootreihenfolge im Bios bringt diese Adressierung durcheinander. Daher hängt das notwendige Mapping von der Bootreihenfolge ab, die bei der Installation des zweiten System eingestellt war.

Das Mapping muss nur dann nicht korrigiert werden, wenn der erste Bootloader den Kernel und die initrd lädt und alles weitere über Kernelgerätenamen läuft.

Und die wirklich blödeste Variante wäre, wenn die erste Grubstufe auf der einen Platte installiert wäre und die Weiteren auf der Anderen. Dann würde man zum booten immer beide Platten benötigen. Nach meiner Methode ist jede Platte immer alleine als Bootdevice im BIOS nutzbar.

Aber ich sehe schon da brauchen wir noch eine andere Meinung zu dem Thema, wir sind uns da nicht einig.
 

towo

Moderator
Teammitglied
Dir is nicht klar, wie chainload funktioniert!
Chainload auf eine andere Platte oder Partition ruft auch nur den Bootloader auf.
Der Chainload selbst muß nicht wissen, was dieser Bootloader letztendlich laden soll!
Ergo sind die Grub-Stages in diesem monet völlig egal!
 

TomcatMJ

Guru
Towo hat recht solang es nur um eine zusätzliche fest im Rechner eingebaute und drinbleibende Platte geht. Erst wenn man direkt vor dem Installationszeitpunkt die Reihenfolge der Platten im BIOS geändert hat oder umgestöpselt hat damit das System explizit die Platte als erste sieht und man nicht gewillt ist die /etc/fstab später wieder anzupassen und danach den Bootloader erneut in den MBR der dann als zweite Platte im Bios zurückgestellten Festplatte zu schreiben sollte man mappen.
Das macht aber eigentlich auch nur Sinn wenn man die Platte desöfteren ausbaut um sie z.B. zum Testen von anderen Rechnern in eben diese dann einbaut, was aber im Privatumfeld nur selten der Fall sein dürfte.
Grub kann nicht nur von x-beliebigen eingebauten Platten per Chainload aus dem jeweiligen MBR der betroffenen Platte gestartet werden sondern wenn nötig auch aus x-beliebigen Partitionen eben dieser per Chainload oder bei Primärpartitionen x-beliebiger Platten sogar per Bootable-Flag ausgewählt werden wenn mehrere Primärpartitionen mit jeweils einem Bootloader vorhanden sind und der MBR keinen Bootloader enthalten soll.
Zu letzterem sollte man nur im BIOS die betroffene Platte als Bootplatte einstellen und das Active(=bootable) Flag per fdisk auf die gewünschgte Partition setzen. Wenn man den Grub immer zusätzlich in den MBR der Partition zusätzlich zum MBR der Platte installiert kann man so bei Experimenten mit Bootloadern sich immer eine Hintertür offenhalten wenn man beim Testen mal eventuell den MBR der Platte in Mitleidenschaft gezogen haben sollte und sich da eventuell den Grub gelöscht hat *mal als Tipp am Rande bemerk*

Bis denne,
Tom
[Edit]Eine Korrektur zur Klarstellung was ich meinte ist farblich markiert eingefügt worden[/Edit]
 

Tooltime

Advanced Hacker
TomcatMJ schrieb:
Towo hat recht solang es nur um eine fest im Rechner eingebaute und drinbleibende Platte geht.
Gerschon schrieb:
Auf der einen Festplatte ist SuSE Linux 11.2 installiert und auf der 2. Festplatte ist Kubuntu 9.10 installiert
Und nun?

Wenn man das so macht wie ich es beschreiben habe, stellt man einfach die Bootfolge im BIOS um, installiert auf der zweiten Platte ein beliebiges Betriebssystem und stellt einfach die Bootfolge im BIOS zurück. Die erste Platte bleibt unangetastet und man kann einfach auf den Bootloader der zweiten Platte verzweigen. Das ist gut wenn man Windows nebenbei auf dem Rechner hat oder öfter ein weiteres Betriebssystem installieren möchte.

Ich bin mal davon ausgegangen das klar ist, das es grundsätzlich nur um den zweiten nachgeladenen Bootloader geht, der im Falle eines weiteren Linuxsystems wieder Grub sein dürfte.

towo schrieb:
Chainload auf eine andere Platte oder Partition ruft auch nur den Bootloader auf.
Genau genommen lädt er wiederum nur die erste Stufe eines weiteren Bootloaders, direkt über den MBR, per generischen Bootcode aus der aktiven Partition oder aus einer beliebigen Partition.
towo schrieb:
Der Chainload selbst muß nicht wissen, was dieser Bootloader letztendlich laden soll!
Das Mapping wirkt sich grundsätzlich nur auf dem nachgeladenen Bootloader aus. Und dieser muß im BIOS wieder die gleichen Verhältnisse vorfinden, wie zu dem Zeitpunkt als er installiert wurde.
towo schrieb:
Ergo sind die Grub-Stages in diesem monet völlig egal
Da es sich beim zweiten Bootloader wieder um Grub handelt, ist dessen Funktionweise natürlich wichtig. Schließlich muss dieser später auch seine weiteren Stufen wiederfinden.
towo schrieb:
Dir is nicht klar, wie chainload funktioniert!
Das Komplement gebe ich einfach mal zurück. Da du anscheinend nicht einmal erkennst wo das eigentliche Problem liegt, der zweite nachgeladene Bootloader, macht es auch keinen Sinn mit dir weiter darüber zu diskutieren.
 

TomcatMJ

Guru
Ich meinte eine zusätzliche fest eingebaute und im Rechner verbleibende Platte...die Korrektur ist oben eingefügt+farblich markiert...(auch wenn ich davon ausgehe daß du durchaus wusstest was gemeint war war meine Formulierung in der ursprünglichen Form leider etwas missverständlich geraten und bedurfte daher der Korrektur *g*)

Übrigens: Der fragliche Bootloader muss nicht unbedingt ein GrUB sein,es kann auch ein EXTLINUX, ein lilo, ein elilo, XOSL, U-Boot, der BSD-typische boot0 Bootloader (dem man übrigens auch Linux als zu ladendes System beibringen kann) oder was ganz anderes sein,denn nicht nur GrUB kann als Bootloader für Linux fungieren, genauso wie GrUB auch was anderes als Linux (und zwar nativ und nicht nur per Chainload) laden könnte ;) , z.B. Solaris oder BSD-Unixderivate oder einen ganzen Haufen anderer Betriebsysteme die es noch so auf dem Markt gibt. Per entsprechender Offsetangabe in der Chainload Anweisung könnte man so einen x-beliebigen Bootloader sogar mitten auf einer Platte positionieren ohne daß dieser Bootloader überhaupt in einer Partition sein müsste,allerdings dürfte sowas in der Praxis ziemlich sinnfrei sein solang man sowas nicht mit einer wirren Art der Verschlüsselung kombiniert.

Somit bleibt Towos Aussage daß zum Chainloaden die GrUB Stagefiles des nachzuladenden Bootloaders ziemlich egal sind (nicht jedoch die eigenen, denn der GrUB der Chainloaden soll muss ja erstmal wissen daß er Chainloaden soll,benötigt daher seine eigenen Stagefiles und seine Konfigurationsdatei um dann zum nächsten per Chainload zu ladenden Bootloader übergehen zu können,dessen Konfiguration oder Stagefiles dem zuerst gestarteten GrUB daher ziemlich eghal sind*g*) korrekt. Es fehlte allenfalls die für mitdenkende Leute klar erkennbare Zuordnung der Stagefiles zum nachzuladenden GrUB in seinen Ausführungen ;)

Noch etwas dazu: Da inzwischen auch bei aktuellen Versionen des GrUB die Laufwerke nach Device-ID sortierbar sind für die Installation des Bootloaders muss dieser Bootloader selbst ja auch noch nichteinmal mehr wissen ob er nun von der ersten oder zweiten Platte gestartet wurde,das ist nur noch für das vom GrUB zu ladende Betriebsystem relevant sofern dort noch per BIOS-Reihenfolge statt per Device-ID sortiert gemountet wird. Stattdessen reihcts aus wenn der Bootloader weiss von welcher Device-ID er seine Stagefiles und seine Konfigurationsdatei beziehen soll und wo diese dort liegen,egal ob das nun die 1.,2. oder 4. Platte im System ist.

Zitat dazu aus meiner /boot/grub/device.map:
Code:
sudo cat /boot/grub/device.map
(hd1)   /dev/disk/by-id/ata-SAMSUNG_HD401LJ_S0HVJ1FL702063
(hd0)   /dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1MA122715
(hd2)   /dev/disk/by-id/ata-Maxtor_6E040L0_E14MTZLE
Danach ist es ziemlich egal was ich im BIOS einstelle,die Platten haben für GrUB immer die in der device.map festgelegte Reihenfolge die ja eindeutig nach Device-ID geht und nicht mehr wie früher nach dem was das BIOS dazu meint.

Bis denne,
Tom
 

josef-wien

Ultimate Guru
Bringst Du da nicht etwas durcheinander? Die device.map wird im laufenden System als "Übersetzungstabelle" zwischen Linux und GRUB verwendet, wenn irgendwelche GRUB-Aktivitäten erfolgen. Während des Boot-Vorgangs richtet sich GRUB nur nach der vom BIOS vorgegebenen Festplattenreihenfolge.

Jetzt aber zurück zum Auslöser der Diskussion. Auch bei "chainloader +1" auf einen anderen GRUB wirkt "map". Über die Konsequenzen und die potentiellen Fallen einer solchen Vorgehensweise will ich lieber nicht nachdenken.
 
Moin Gerschon

Frage:
Wie kann ich über den Grub der ersten Festplatte die 2. Platte mit Kubuntu einbinden und starten?

Stelle im Bios die Bootreihenfolge so um, das von der Platte mit Ubuntu gestartet wird. Führe unter Ubuntu im Terminal ein sudo update-grub aus, und du wirst sehen, das SuSE Linux 11.2 erkannt wird. Neustarten, und gut ist. Sollte im Laufe der Zeit unter Suse ein Kernelupdate angeboten werden, musst du danach
Führe unter Ubuntu im Terminal ein sudo update-grub aus
wiederholen, weil sonst der Grub 1.97 Eintrag für die 11.2 ins Leere läuft.

Bei mir sieht es so aus:

Code:
linux-rc1c:/home/bauwagen # fdisk -l

Platte /dev/sda: 160.0 GByte, 160041885696 Byte
255 Köpfe, 63 Sektoren/Spuren, 19457 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x00047bf2

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *           1        3039    24410736   83  Linux
/dev/sda2            3040       19457   131877585    5  Erweiterte
/dev/sda5            3040       19457   131877553+  83  Linux

Platte /dev/sdb: 160.0 GByte, 160041885696 Byte
255 Köpfe, 63 Sektoren/Spuren, 19457 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x61c57877

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdb1               1         547     4393746   82  Linux Swap / Solaris
/dev/sdb2             548        3158    20972857+  83  Linux
/dev/sdb3            3159       19457   130921717+  83  Linux

Platte /dev/sdc: 640.1 GByte, 640135028736 Byte
255 Köpfe, 63 Sektoren/Spuren, 77825 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x03320332

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdc1   *           1       11985    96269481    7  HPFS/NTFS
/dev/sdc2           11986       77825   528859800    5  Erweiterte
/dev/sdc5           11986       77825   528859768+   7  HPFS/NTFS

Auf sda ist Ubuntu 9.10 + home installiert. Grub 2 (1.97 beta) im MBR der Platte.
Auf sdb ist openSuSE 11.2 + home und swap für beide Systeme. Grub 1 in der Systempartition.
Auf sdc ist Windows 7 + Datenaustauschpartition in ntfs für alle drei Systeme. Bootlader für Win im MBR von sdc.

Installiert habe ich in der Reihenfolge: Win7 - openSuSE - Ubuntu. Jedesmal die anderen zwei Festplatten vom Board getrennt. Vorteil: Der zuletzt im MBR von sda geschriebene Grub 2 listet alle Systeme nach update-grub auf und startet sie. Ich kann alle Platten einzeln betreiben, wenn mal eine ausfällt. Nachteil: Wenn ich die Platte mit SuSE 11.2 einzeln betreiben möchte, muss ich erst mit SuperGrub starten um dann den Bootlader in den MBR der Festplatte zu schreiben.

Schöne Nacht noch wünscht: Hans
 

josef-wien

Ultimate Guru
brachiopode schrieb:
Nachteil: Wenn ich die Platte mit SuSE 11.2 einzeln betreiben möchte, muss ich erst mit SuperGrub starten um dann den Bootlader in den MBR der Festplatte zu schreiben.
Da läuft etwas falsch. YaST muß so eingestellt sein, daß GRUB in die root-Partition installiert wird, was laut Deinen Angaben bereits der Fall ist. Weiters brauchst Du einen generischen MBR, den hast Du aber durch Supergrub nicht mehr. Du kannst ihn aber mit
Code:
dd if=/usr/lib/boot/master-boot-code of=/dev/disk/by-id/... bs=440 count=1
wiederherstellen. Drittens muß die root-Partition aktiv sein, das ist sie bei Dir derzeit nicht.

Alternativ (oder auch zusätzlich) kannst Du GRUB in den MBR Deiner "openSUSE-Platte" installieren. YaST kann das aber nur dann, wenn diese Platte die Boot-Platte ist, daher mußt Du das auf andere Weise (Supergrub, direkte GRUB-Befehle, ...) bewerkstelligen (YaST sollte so eingestellt sein, daß GRUB in die root-Partition installiert wird). Das "hält" solange, bis ein geändertes GRUB-rpm-Paket installiert wird. Bei einem Kernel-Update "hält" es, da in diesem Fall keine Änderungen bei den Dateien /boot/grub/*stage* erfolgen.
 
Oben