Grub für 8 Betriebssysteme mit /root Partition

[Master Mayhem]

Frohe Ostern!

Da ich jetzt die neue Platte drin habe und nen debian sarge snapshot auf DVD (Cebit Special....hoffe ich muss nicht mehr allzuviel updaten) und alle anderen OSes auf CD oder DVD will ich loslegen....

Großes Project für mich, aber da ich AEleen Frischs Unix System Administration [1] wirklich verstehen will, benötige ich möglichst viele beschriebene OSes, d.h. freebsd, solaris, redhat, suse und für mich nochmal zwei debians (sarge und sid), zum spielen nen winXP und evtl nochmal nen ubuntu, gentoo, slackware oder fedora zum ausprobieren.
Die Lösung mit VMWare o.ä. möchte ich nicht, das soll nativ laufen!

Fesplatte ist entsprechend partitioniert, d.h. insgesamt über 10 Partitionen, die wichtigsten im überblick:

hda1 winXP
hda2 freebsd
hda3 solaris
hda5 swap (auf hdb1 gibt es noch eine swap)
hda6 /boot
hda7 debian sarge
hda8 debian sid
hda9 suse
hda10 redhat
usw.

boot partition hat also nix mit 1024 cylinder oder so zu tun, sondern soll eigentlich nur für die beiden debians die /boot partition sein und auch grub beheimaten, das im MBR hda installiert ist.

Eigentlich wollte ich dann für jedes weitere Linux, grub in die partition installieren, in der das Linux auch installiert ist und nen chainloader, von dem Grub im MBR hda machen, weil ich gerne auf automatische kernel-updates zurückgreifen möchte, bei redhat und suse (bei debian auch sehr praktisch)
Wenn der mir dann immer die Grub konfig im MBR hda überschreibt nervt das, daher die idee jedes linux sein eigenes grub in der eigenen partition.

Aber das funktioniert leider nicht, erstens muss die partition nen ext2 oder ext3 haben um grub z.B. auf hda9 zu installieren und selbst dann funktioniert so ziemlich nichts, um vom Grub im MBR den Grub auf hda9 zu booten, die dokumentation gibt dazu leider auch nix her, wie man grub mit grub nachläd...

Also dacht ich mir, warum nicht die /boot partition auch für die anderen Linuxe nutzen?
Gibt das evtl Probleme mit den verschiedenen Versionen von Grub, wenn jede Linux installation als /boot partition hda6 bekommt und ich auch jedesmal grub installiere, um automatisch die entsprechenden einträge in der /boot/grub/menu.list zu erhalten, wenn ich ein kernel-update über die entsprechende paketverwaltung mache (vorrausgesetzt suse bzw redhat machen das überhaupt...denke aber schon)??

Und wieviel platz benötige ich wohl für /boot, wenn ich 10 Linuxe und pro linux 2 kernels haben will?

Thx mfg tyler

[1] http://www.oreilly.de/catalog/esa3ger/

[KBDCALLS]

Installier einmal Grub , und pass die menu.lst von Hand an so das die Einträge in Ruhe gelassen werden.Das script update-grub gehört auch nicht zum Original Grub . Ist eh debianspezifisch. So kannst du jedes Linux komplett für sich installieren. Die Kernels unterschiedlicher Linuxe in ein /boot würd ich nicht machen, zumal man irgendwann dann die Übersicht verliert.

[Master Mayhem]

Bei nur debian systemen ist das kein problem, da ich genau weiß, was ich da einzutragen habe, nur z.B. vom suse kernel weiß ich, dass der ganz komische einträge im der menu.lst genötigt, da das ein speziell angepasster kernel ist...

bisher hab ich das auch immer so gemacht, mein debian sarge hat grub im MBR hda verwaltet und da habe ich alles per hand eingetragen....suse war da schon recht nervig, da ich bei der installation kein copy&paste benutzen konnte und mir die ellenlangen einträge für grub auf ein stück papier notieren musste

...und yast macht kein update grub o.ä. wenn ich mir nen neuen kernel installiere....kann ich mir fast nicht vorstellen, der durchschnittliche suse-user ist mit ner manuellen anpassung der menu.lst doch komplett überfordert

naja ich hätts auch lieber automatisch, da ich kein bock habe mich näher mit der kernel configuration von ner suse und den benötigten boot-optionen zu beschäftigen, denn die sind wirklich komisch:

Code: Alles auswählen

# Suse auf hda4
title Suse 9.1
root    (hd0,3)
kernel  /boot/vmlinuz root=/dev/hda4 vga=0x317 splash=silent desktop resume=/dev
/hdb2 showopts
initrd  /boot/initrd
savedefault
boot

# Suse auf hda4 failsave
title Suse 9.1 failsave
root    (hd0,3)
kernel  /boot/vmlinuz root=/dev/hda4 showopts ide=nodma apm=off acpi=off vga=nor
mal noresume nosmp noapic maxcpus=0 3
initrd  /boot/initrd
boot

schon klar der link für vmlinuz bzw initrd muss angepasst werden, aber wer weiß, ob die anderen einstellungen alle gleich bleiben....

naja wenns nicht geht mach ich es wie früher auch schon, ein grub verwaltet von der produktivumgebung debian sarge und einträge per hand vornehmen.

Aber eine /boot partition für debian sarge und debian sid dürfte doch keine probleme verursachen, oder?

mfg tyler

ps.s: warum lääst sich grub eigentlich auf eine beliebige partition installieren, wenn es sich von da aus nicht booten lässt, oder ist das gedacht für die freaks die gerne den windoof bootloader behalten wollen und damit dann nen linux starten wollen?

[KBDCALLS]

Eigentlich sieht der Eintrag nicht viel anders für Suse als für Debian.

Aber sieh die mal diese Wiki Seite an.

Grub Boot CD

Grub startet eine anderen Grub müßte aber auch funktionieren. Werd ich mal demnächst ausprobieren.

[Master Mayhem]

Eigentlich sieht der Eintrag nicht viel anders für Suse als für Debian.

Naja der Eintrag für suse, den ich oben gepostet habe weicht schon stark von nem debian eintrag ab: "kernel /boot/vmlinuz root=/dev/hda4 vga=0x317 splash=silent desktop resume=/dev/hdb2 showopts"
andererseits ist mir aufgefallen dass bei so einem eintrag, wo nur mit vmlinuz und initrd (ohne versionsnummer) gearbeitet wird, gar kein update der menu.lst nötig ist, bei nem kernel update, weil einfach die symlinks vmlinuz und initrd angepast werden...eigentlich gar keine so schlechte idee, naja bis auf die tatsache, dass der neue kernel dann auch 100%tig booten sollte, sonst ist manuelle nacharbeit mit nem knoppix angesagt

Grub startet eine anderen Grub müßte aber auch funktionieren. Werd ich mal demnächst ausprobieren.

Also wenn du das schaffst bitte rückmeldung! Ich hab das einen ganzen tag versucht und denke ich habe alle möglichen optionen durch, die man grub übergeben kann, angefangen von einem eintrag identisch zu einem windows eintrag (soll ja schließlich auch ein bootloader nachgeladen werden) bis hin zu nur rootnoverify habe ich alles durch.........
Documentation sagt dazu absolut nix - nada
Installieren lässt sich grub nur auf eine Festplattenpartition, wenn diese ext2 oder ext3 ist, wenn grub in den mbr soll kann die /boot partition reiserfs haben, xfs geht gar nicht.
Eigentlich sollte grub auch grub nachladen können, was in gewissen fällen sogar sinn macht....

mfg tyler

[Savar]

@Master Mayhem:

warum willst du mit knoppix nacharbeiten wenn bei Grub der falsche Kernel ausgewählt wurde? Du kannst doch direkt mittels Grub beim booten jeden Kernel auswählen den du möchtest (der auf der Platte installiert ist)

[schwedenmann]

Hallo


Das ist gar kein Problem.

Du mußt nur
1. Einmal am besten bei der letzetn Linuxinstalltion Grub in den MBR, also nach Hda installieren.
2. Bei alle anderen Linuxen, freebsd, etc kannst du den Booloader in die entsprechende Rootpartition installieren, oder auch keinen Bootloader installieren.

3. Menüliste anpassen
a. bei Bootloader in der Rootpartition z.B. von Suse
root /Partiton)
chainloader +1

b. Ansonsten mußt du in der menu.lst root und boot Einträge des jeweiligen OS anpassen und ev. z.B. bei Suse die initrd Einträge auch reinschreiben.

Das wäre eigebentlich alles.
Du kannst dann in den jeweiligen menu.lst der OS, in denen du grub in die Rootpartition geschrieben hast, jeweils timeout=0 setzen.

Wenn du jetzt im Bootmenü von Grub aus dem MBR z.B. Suse aufrufst, dessen grub in der Rootpartitioon von Suse liegt, wird grub (suse) in der Rootpartition per chainloader+1 aufgerufen und dieser startet dann dein Suse.
Ohne den chainloadereintarg mußt du eben ein paar Zeilen mehr schreiben und grub in hda springt den Kernel von z.B. Suse direkt an und startet ihn.


Mfg
schwedenmann

[Master Mayhem]

@savar
hast ja recht, solange das grub im mbr nicht geschrottet ist, oder ein grub auf diskette nicht existiert, besteht keine notwendigkeit nen knoppix o.ä. zu nehmen, besonders da ich ja mehrere linuxe installiert habe unter denen ich die partition mounten kann und die menu.lst bearbeiten kann

@schwedenmann

Das habe ich noch nicht ganz verstanden, daher fasse ich einmal zusammen, was ich gleich ausprobiere und du nickst, wenn du das so gemeint hast?!

Stand der Dinge:
hda1 hat nen winXP installiert, das überleben soll, der rest ist noch frei, bzw zu testzwecken genutzt

1. debian basisinstallation incl partitionierung mit RC2 (ja ich nehme linux24 zur sicherheit) auf hda7
dabei grub in die /root partition (d.h. hda7) installieren, d.h. ich kann die basisinstallation dann noch nicht abschließen, da ich das dann nicht booten kann wg fehlendem grub im mbr

2. debian basisinstallation partitionierung beibehalten mit RC2 auf hda6
dabei grub in den mbr hda installieren, basisinstallation abschließen und dann in der menu.lst vom grub im mbr hda folgendes eintragen:

Code: Alles auswählen

# grub fuer debian auf hda7
title grub debian hda7
root (hd0,6)
chainloader +1

(da hda1, hda2, hda3, hda5, etc. ist das für grub hd0,6)

jetzt verstehe ich aber:

b. Ansonsten mußt du in der menu.lst root und boot Einträge des jeweiligen OS anpassen und ev. z.B. bei Suse die initrd Einträge auch reinschreiben.

nicht, damit meinst du menu.lst vom grub auf hda7 (in meinem beispiel) oder die menu.lst vom grub im mbr?

logisch wäre ja die menu.lst vom grub auf hda7, nur muss da ja nix angepasst werden, weil die ja eigentlich schon von der basisinstallation bzw der grub installation auf hda7 stimmen müssten - deswegen wünsche ich ja dieses seltsame konstrukt, damit ich nicht immer manuell nacharbeiten muss (bei 2 oder 3 linuxen noch o.k. bei mehr ist das einfach zu nervig...)

Obwohl ich nicht sicher bin, habe ich das auch schon ausprobiert und ne meldung wie incorrect or invalid partition table geerntet (o.ä. je nach eintrag habe ich da ne menge fehlermeldungen gesammelt), bin mir aber nicht sicher, ob ich wirklich schon diese kombination probiert habe....daher versuche ich das gleich!

Und du meinst also dass das grub im mbr als letztes installiert werden muss/soll?
Unpraktisch, wenn man mal ne neue distri ausprobiert, obwohl dann ja eigentlich nen grub install mbr hda von dem linux das grub mbr verwaltet (in meinem beispiel hda6) ausreichen müsste, oder?

erstmal thx für den tip....wenn ich das schaffe, ist das die beste lösung für mich (so hatte ich es auch ursprünglich geplant)!

mfg tyler

[schwedenmann]

Hallo


ich gehe jetzt mal davon aus.
1. Du hast schon einige OS drauf
2. Du installierst Debian auf hda6 und auf hda7
3. Du installierst danach noch einieg OS.


Hda6 normal installieren und grub in den MBR schreiben


danach hda7 installieren und grub wieder in den MBR schreiben.
Jetzt bootest du alle installierten OS per Grub im MBR, wobei dein Bootmenu = /biot/grub/mneu.lst auf Hda7 liegt.
Ev. mußt du für alle anderen OS das Menü anpassen.

Vom MBR jetzt ein backup per dd machen und irgendwo auf hda7 speichern.

Wenn du jetzt noch weitere OS installieren willst z.B. nach hda10, kannst du entscheiden wo grub hin soll.

1. Einfache Möglichkeit grub in die Rootpartition des jeweiligen OS
Eintrag dann auf /hda7/boot/grub/menu.lst
root (rootpartiton des zuletzt installierten OS)
chainloader +1

dadurch wird grub auf hda10 gestartet, ev. dann den timeout Eintrag im mmenu.lst auf hda10 !! auf Null setzen, Standardwerte sind für jedes OS ev. unterschiedlich.

2. du installierst ein OS auf hda10, schreibst dessen bootloder in den MBR.
Du mußt jetzt nur, wenn dein hauptsystem auf hda7 liegt und alle von hda7 gebootet werden soll (Bootmenü) dein MBR-backup von hda7 nach hda kopieren. Dadurch wird der ursprüngliche zustand (grub von hda7 im MBR) wiederhergestellt und dein Bootmenü, für alle OS, liegt wieder auf hda7.

mfg
schwedenmann

[Savar]

so irgendwie plan ich nu gar nichts mehr..

erstmal nochmal die Frage: Warum für jedes System einen eigenen Bootloader??????

ansonsten müsste es reichen jedes System so zu installieren, dass deren Bootloader immer nur in ihre Partition installiert werden und dann die "menu.lst" von deinem "Hauptsystem" (also hier deinem Debian auf hda6 und hda7) anpassen, dass halt zu dem Bootloader gewechselt werden soll.. nur was bringt das?

[schwedenmann]

Hallo

ansonsten müsste es reichen jedes System so zu installieren, dass deren Bootloader immer nur in ihre Partition installiert werden und dann die "menu.lst" von deinem "Hauptsystem" (also hier deinem Debian auf hda6 und hda7) anpassen, dass halt zu dem Bootloader gewechselt werden soll.. nur was bringt das?

manchmal kann man die Installtion nur abschließen, wenn ein Bootloader installiert wird.
Wie man dann weiter vorggeht ist Geschmackssache
1. Bootloader in den MBR, überschreibt vorhandenen Bootloader
2. Bootloader in Rootpartiton
3. Bootloader auf Diskette
4. keinen Bootloader installieren

je nachdem welche der Möglichkeiten 1-2 man wählt, muß dann dementsprechend weiter verfahren werden, wenn z.B. hda7 das hauptsystem bleiben soll.

Mfg
schwedenmann

[KBDCALLS]

Wenn unbedingt ein Bootloader Installation verlangt wird. Dan kriegt ebend Yast sein Räppelchen Entweder auf Diskette oder direkt in die Partition. Und gut ist. Ich muß ihn ja nicht benutzen.

[Master Mayhem]

Wenn unbedingt ein Bootloader Installation verlangt wird. Dan kriegt ebend Yast sein Räppelchen Entweder auf Diskette oder direkt in die Partition. Und gut ist. Ich muß ihn ja nicht benutzen.

Ich will ihn aber insofern verwenden, als dass ich davon ausgehe, dass nahezu jede dristri sowas nettes hat, wie debian, eben die automatische anpassung des bootlaoders (lilo oder grub) bei nem kernel-update per paketverwaltung.

Daher könnte man schon grub in die partition installieren und das dann gar nicht benutzen, sondern einfach nur den neuen eintrag in die /boot/grub/menu.lst kopieren, die in den mbr installiert ist.
Wenn er aber schonmal da ist, kann man ihn auch benutzen, da er mir diesen copy&paste vorgang abnimmt - einzigster nachteil ist, dass ich dann nur ext2 oder ext3 nehmen kann....

Kann ja auch sein und keine der testinstallationen hat nen script das den bootloader anpasst bei der neuinstallation des kernels (ubuntu macht das bestimmt auch, da debian grundlage), oder die machen das wie ich das bei suse vermute mit symlinks vmlinuz und initrd, die immer auf den aktuellen kernel verweisen, dann habe ich mir den stress umsonst gemacht, dafür kann ich dann nen bootloader auch nachladen per chainloader+1 (hoffe ich, bis gerade an meinem LSTjahresausgleich 2003 gesessen, daher fange ich jetzt an zu testen)

Die idee den mbr per dd zu sichern ist gar nicht so schlecht, allerdings sollte ein grub-install /dev/hda mit rückgesicherter menu.lst von der installation, die den mbr verwalten soll, dieselbe arbeit erledigen, ne boot-diskette mit nem grub für das debian sarge system habe ich sowieso immer da (obwohl knoppix und chroot grub-install /dev/hda auch helfen würde)

thx for the feedback!
mfg tyler

[schwedenmann]

Hallo

Wenn er aber schonmal da ist, kann man ihn auch benutzen, da er mir diesen copy&paste vorgang abnimmt - einzigster nachteil ist, dass ich dann nur ext2 oder ext3 nehmen kann....

Versteh ich nicht, grub kann ext2/3, rfs und xfs direkt booten, kein problem.

Die idee den mbr per dd zu sichern ist gar nicht so schlecht, allerdings sollte ein grub-install /dev/hda mit rückgesicherter menu.lst von der installation, die den mbr verwalten soll, dieselbe arbeit erledigen, ne boot-diskette mit nem grub für das debian sarge system habe ich sowieso immer da (obwohl knoppix und chroot grub-install /dev/hda auch helfen würde)

das stimmt, beide Methoden erfüllen denselben zweck, ich bevorzuge die methode per dd, außerdem kann ein Backup des MBR+Partitionstabelle und ein Backup des MBR ohne Partitonstabelle nie schaden, falls nämlich eine Installation von grub scheitert, kannst du mit der MBR-Methode dein System wieder bootfähig machen.

Mfg
schwedenmann

[Master Mayhem]

Hallo

Wenn er aber schonmal da ist, kann man ihn auch benutzen, da er mir diesen copy&paste vorgang abnimmt - einzigster nachteil ist, dass ich dann nur ext2 oder ext3 nehmen kann....

Versteh ich nicht, grub kann ext2/3, rfs und xfs direkt booten, kein problem.

Aber zumindestens mit dem sarge rc2 installer läßt sich grub nicht in die partition installieren, wenn diese nicht ext2 oder ext3 ist.
Bei dem grub im mbr kann die /boot partition außerdem noch reiserfs sein, wenn xfs verwendet wird scheitert die grub-install /dev/hda immer.

Ist aber nicht schlimm, wenn redhat, suse, und die testsysteme nen ext3 bekommen, geplant war reiserfs...

geht also nicht darum, was gebootet werden kann, sondern auf welchen fs grub installiert werden kann.

mfg tyler

[Master Mayhem]

Nochmal großes Thx an alle!

mit

root (hd0,9)
chainloader +1

zum gewünschten erfolg gekommen!

nur mit der Cebit special debian sarge unzufrieden - kein enlightenment, kein firestarter (noch nichtmal guarddog...da muss man echt mit iptables per hand ran - das ist definitiv unbefriedigend)
naja also doch wieder fast alles runterladen, das update dauert bei ner 1024 bit/s auch schon 25 min

mfg tyler

[KBDCALLS]

Auf eine DVD passen halt nur 4,7 GB und bei vier Architekturen kann sich jeder ausrechen was für jede Archtektur draufpasst. Oder mann hätte gleich ne Duallayer nehmen sollen. Aber die DVD war schon veraltet wie sie gepresst wurde.