Grub und mehrere unabhängige Installationen

[arnem]

...oder: ich sehe den Wald vor lauter Bäumen nicht mehr...

Guten Morgen!

Folgendes: Auf einer meiner Maschinen läuft Sarge auf /dev/sda1. Drin hängt auch eine bislang nicht wirklich genutzte 18GB-Platte als /dev/sdc. Darauf wollte ich mir Etch und Xen-3.0.3 installieren.

Wie sieht das mit Grub aus? Ich grübele schon ewig und hab mich inzwischen wohl irgendwie verrannt...

1. Grub von Sarge liegt auf /dev/sda
2. Etch in /dev/sdc1 installieren und Grub von Etch in /dev/sdc
3. Start von Sarge
4. Grub von Sarge nach weiteren OS suchen lassen (update-grub?), dann müsste er doch den Grub von Etch finden
5. Neustart und dann im Grub von /dev/sda die Etch wählen
6. freuen

Oder ganz anders?

[beta1]

Hallo

Ich dachte immer dass man einen Grub für alle Betribsysteme hat, aber vieleicht hast du Recht

mfg

[scipio]

Behalte Grub von Sarge und gib einfach die infos für das neue OS dazu. Das könnte dann z.B. so aussehen:

title Debian GNU/Linux, kernel 2.6.18-3-486
root (hd0,0)
kernel /vmlinuz-2.6.18-3-486 root=/dev/hdc2 ro
initrd /initrd.img-2.6.18-3-486
savedefault

title Anderes Linux, kernel 2.4.32-486
root (hd1,5)
kernel /vmlinuz-2.4.32-486 root=/dev/hdd6 ro
initrd /initrd.img-2.4.32-486
savedefault

[arnem]

also wie geplant, den Grub von Etch in /dev/sdc installieren lassen?

Oder in Etch überhaupt keinen Bootloader installieren und die Pfade zu vmlinuz und initrd aufschreiben und im Grub von Sarge wie beschrieben eintragen?

[nonoo]

Guten Tag,

Du kannst dein Problem per Chainloading lösen, Dann hast Du alle Betriebssystem entkoppelt.
Grub installierst Du jeweils in die root-Partition der jeweiligen Installation.

grub-install --root-directory=/mnt/sda1 /dev/sda1

Dann hast Du Grub in der Partion sda1. Der mbr wird nicht verändert.
Bei der Installation muß sda1 gemountet sein, oder Du gibst bei der Installation bei Grub als Ort folgendes ein: /devsda1.
Hilfreich kann hier ein Live Linux CD sein.

Deinen jetzigen Bootmanager konfigurierst Du , das dieser per Chainloading sda1 bootet.
Mit partimage kannst Du dann alles immer hin und herschaufeln und bist immer startfähig.
Das funktioniert einwandfrei.

Viel Erfolg
nonoo, der seine Betriebssystem inzwischen fliegend wechselt.

[Kokopelli]

Oder in Etch überhaupt keinen Bootloader installieren und die Pfade zu vmlinuz und initrd aufschreiben und im Grub von Sarge wie beschrieben eintragen?

Jepp, ein Grub für alle OS!
Chainloading ist für ein weiteres Linux nicht nötig, das benötigst Du für Systeme, die zwingend ihren eigenen Bootloader verwenden müssen, also etwa den NTLoader bei Windows.
Du kannst theoretisch so viele Grub-Instanzen wie Du möchtest chainloaden, aber das macht es nur unnötigerweise fehleranfällig und schlecht wartbar. Also trage alle Systeme in einen Grub ein, der dann im MBR wohnt... so läuft das ohne Probleme.

[nonoo]

Ein wesentlicher Vorteil von Chainloading ist, dass Du den Grub im mbr nicht mehr zu konfigurieren brauchst. D. h.,wenn die Partition wenn nicht verändert werden und Grub (der im mbr) für Chainloading konfiguriert ist, kannst Du Testinstallationen ohne Auswirkungen auf den mbr vornehmen. Datensicherungen und Datenrücksicherung, die Installationsbezogen sind können mit der Chainloadingvariante erheblich einfacher durchführt werden. Stage1 befindet dann immer auf jeweiligen Partition. Bei der Verwendung von einem Grub im mbr hast Du nur einen eingebundenen Stage1. Mit Chainlaoding bleibst eher startfähig. Weiterer HInweis: Windows XP und W2K benötigen für den Start Primarpartitionen. Das solltest Du auch berücksichtigen. mfg nonoo

[Kokopelli]

Du kannst theoretisch so viele Grub-Instanzen wie Du möchtest chainloaden, aber das macht es nur unnötigerweise fehleranfällig und schlecht wartbar. Also trage alle Systeme in einen Grub ein, der dann im MBR wohnt... so läuft das ohne Probleme.

Das sollte ich weiter ausführen:
Bei der Installation eines jeden aktuellen GNU/Linux, welches Grub einsetzt, wirst Du gefragt werden, ob Du Grub im MBR haben möchtest. Bei einer Antwort mit "JA" wird dann der MBR überschrieben, allerdings nicht, ohne dabei sehr zuverlässig alle startbaren Betriebssysteme auf deinen Platten aufzufinden und automatisch mit in den Grub aufzunehmen. Das schließt eventuell vorhandene Win-Partitionen ein.
Das warten einer einzigen menu.lst Datei ist ein weiter Vorteil, weil Du auch nur einen singlePointOfFailure haben kannst... und wenn alles schief geht (sehr unwahrscheinlich, da Du ja immer höchstens einen Eintrag auf einmal ändern wirst) einfach den Grub von BootCD|Diskette nochmal nachinstallieren.
Das chainloaden verlängert die Bootzeit... Und selbst wenn Du wirklich ständig mit Images deine Partitionen hin- und herwerfen möchtest (was ich bezweifele), dann ist das ändern einer einzigen Zeile in Grub immernoch kein Grund, so eine Konfiguration aufzusetzen.... Grub ist ein Bootloader und soll per Definition verschiedene Systeme booten....Warum sollte er einen neuen Grub booten, der dann seinem eigentlichen Job nachkommt?

[KBDCALLS]

Chainloading eins zeiten Grubs hat auch den Vorteil , das du den Grub im MBR also den von Sarge nur einmal anpassen mußt. Wenn in Etch ein Kernel entfernt oder neu installiert wird kriegt Sarge das ja nicht mit . Da mußt du dich jedesmal selbst drum kümmern, das der korrigiert wird wenn nötig.

[nonoo]

Guten Tag, die Verlängerung der Bootzeit ist durch chainloading sicherlich ein Nachteil für denjenigen, der auf die ca. 3 Sekunden angewiesen ist. Time is Money. Ich nutze die Zeit für Popkorn. mfg nonoo

[arnem]

Chainloading eins zeiten Grubs hat auch den Vorteil , das du den Grub im MBR also den von Sarge nur einmal anpassen mußt. Wenn in Etch ein Kernel entfernt oder neu installiert wird kriegt Sarge das ja nicht mit . Da mußt du dich jedesmal selbst drum kümmern, das der korrigiert wird wenn nötig.

Der Hinweis macht die Sache interessant - die Etch-Installation soll ja gerade zum Spielen und Testen sein.

Also der Grub von Sarge in /dev/sda bleibt soweit erstmal unangetastet, den von Etch installiere ich in /dev/sdc:

Code: Alles auswählen

title Debian GNU/Linux, kernel 2.6.18-3-486
root (hd0,0)
kernel /vmlinuz-2.6.18-3-486 root=/dev/hdc2 ro
initrd /initrd.img-2.6.18-3-486
savedefault

title Anderes Linux, kernel 2.4.32-486
root (hd3,0)
chainloader +1
boot

[nonoo]

Guten Tag amen, viel erfolg beim werfen der Partition und bei deiner Installation. MfG nonoo

[KBDCALLS]

Code: Alles auswählen

title Debian GNU/Linux, kernel 2.6.18-3-486
root (hd0,0)
kernel /vmlinuz-2.6.18-3-486 root=/dev/hdc2 ro
initrd /initrd.img-2.6.18-3-486
savedefault

title Anderes Linux, kernel 2.4.32-486
root (hd3,0)
chainloader +1
boot

Das önnte man so machen , aber noch nen Hinweis . Der Eintrag für das andere Linux , der ja auch Kernelupdate auf Sarge überstehen soll nach dieser Zeile einfügen

Code: Alles auswählen

### END DEBIAN AUTOMAGIC KERNELS LIST

oder vor dieser

Code: Alles auswählen

### BEGIN AUTOMAGIC KERNELS LIST

Die genaue Zuordnung der Devices findest du in der Datei /boot/grub/device.map Grub schert sich nicht darum wie Linux die Devices zuordnet sondern numeriert stur durch angefangen bei 0

[arnem]

Die Methode per chainloader funktioniert perfekt

[edit]

so muss es aussehen:

Code: Alles auswählen

# linux auf sda1
title Debian GNU/Linux, kernel 2.6.18-3-486
root (hd0,0)
kernel /vmlinuz-2.6.18-3-486 root=/dev/hdc2 ro
initrd /initrd.img-2.6.18-3-486
savedefault

#grub von sdc booten
title Anderes Linux auf /dev/sdc
root (hd2)
chainloader +1
boot