staging.inyokaproject.org

Hallo,

ich würde gerne zwei parallele Ubuntu-Systeme installieren. Dazu habe ich mir eine eigene Partition für GRUB eingerichtet, die von beiden Systemen in /boot gemountet wird. Soweit funktioniert das alles problemlos. Vor kurzem habe ich ausprobiert, was passiert, wenn ich auf einem der beiden Systeme einen Kernelupdate mache und die Einträge in der menu.lst für beide Systeme auf den neuen Kernel aktualisiere. Das Ergebnis war, dass das zweite System nicht mehr korrekt funktionierte (z.B. reagierte die Maus nicht mehr).

Deshalb stellt sich mir jetzt die Frage, was passiert, wenn ich den Kernelupdate bei beiden Systemen ausführe. Dann wird der erste aktualiserte Kernel ja überschrieben, weil beide Systeme den neuen Kernel in das selbe Verzeichnis auf den GRUB-Partition schreiben. Das hat zwar bei meinen Versuchen ohne Probleme funktioniert, nur bin ich mir nicht sicher, in wie weit sich Systemkonfiguration, installierte Programme, etc. die ja bei beiden Systemen verschieden sein werden, sich auf den Kernel auswirken. (Falls diese Frage völlig sinnlos ist, tut es mir leid. Aber bei solchen Sachen bin ich einfach (noch) ein N00b.)

Eine Möglichkeit, das zu umgehen, wäre ja, die GRUB-Partition nach /foo statt nach /boot zu mounten und eine Verknüpfung von /boot nach /foo/kernel_des_ersten_systems zu erstellen. Allerdings gefällt mir das nicht so besonders, da dann z.B. auch die menu.lst unter /foo/grub liegen würde. Gibt es also ein Möglichkeit, den Pfad des Kernelupdates zu ändern? Oder muss ich mir darüber sowieso keine Gedanken machen, solange die Kernelversion die gleiche ist?

Cookie2718

Cookie2718 schrieb:

ich würde gerne zwei parallele Ubuntu-Systeme installieren. Dazu habe ich mir eine eigene Partition für GRUB eingerichtet, die von beiden Systemen in /boot gemountet wird. Soweit funktioniert das alles problemlos. Vor kurzem habe ich ausprobiert, was passiert, wenn ich auf einem der beiden Systeme einen Kernelupdate mache und die Einträge in der menu.lst für beide Systeme auf den neuen Kernel aktualisiere. Das Ergebnis war, dass das zweite System nicht mehr korrekt funktionierte (z.B. reagierte die Maus nicht mehr).

Klar, denn nur das System, das das Update vorgenommen hat, besitzt die nötigen Module. Du musst also zumindest /lib/modules/uname -r rüberkopieren.

Deshalb stellt sich mir jetzt die Frage, was passiert, wenn ich den Kernelupdate bei beiden Systemen ausführe. Dann wird der erste aktualiserte Kernel ja überschrieben, weil beide Systeme den neuen Kernel in das selbe Verzeichnis auf den GRUB-Partition schreiben. Das hat zwar bei meinen Versuchen ohne Probleme funktioniert, nur bin ich mir nicht sicher, in wie weit sich Systemkonfiguration, installierte Programme, etc. die ja bei beiden Systemen verschieden sein werden, sich auf den Kernel auswirken. (Falls diese Frage völlig sinnlos ist, tut es mir leid. Aber bei solchen Sachen bin ich einfach (noch) ein N00b.)

Der Kernel selbst sollte keine Probleme machen, der kommt fertig und wird vom Zielsystem nicht mehr verändert. Die initrd kann sich aber unterscheiden und evtl. Probleme machen. Zum Thema Module s.o.

Eine Möglichkeit, das zu umgehen, wäre ja, die GRUB-Partition nach /foo statt nach /boot zu mounten und eine Verknüpfung von /boot nach /foo/kernel_des_ersten_systems zu erstellen. Allerdings gefällt mir das nicht so besonders, da dann z.B. auch die menu.lst unter /foo/grub liegen würde. Gibt es also ein Möglichkeit, den Pfad des Kernelupdates zu ändern? Oder muss ich mir darüber sowieso keine Gedanken machen, solange die Kernelversion die gleiche ist?

Das ganze Setup finde ich ... äääh ... suboptimal. Auf meinem Rechner mache ich's so: Produktivsystem ist ohne extra Boot-Partition normal installiert, Grub im MBR. Das Testsystem ist auch ganz normal ohne eigene Boot-Partition installiert, Grub im Partitions-Bootsektor. Im Grub des Hauptsystems ist für das Testsystem ein Chainloader-Eintrag (wie für Windows), der den Grub des Testsystems nachzieht. Vorteil: Die Systeme sind komplett getrennt, jedes kümmert sich um seine eigenen Kernel, menu.lsts usw., null Probleme mit Updates. Falls das nicht ganz klar war, kann ich das Setup gerne noch detaillierter erläutern.

Gruß

Prometheus

Das mit dem Chainloader hört sich interessant an. Müsste ich dann einfach den selben Eintrag wie für Windows in die menu.lst schreiben? Also etwa:

title        Zweites System
root         (hdX,Y)
chainloader  +1

Trotzdem finde ich, dass eine separate Bootpartition gewisse Vorteile hat. Z.B. muss ich mich, falls ich Ubuntu mal neu installieren möchte, nicht um die menu.lst kümmern (außer veilleicht die UUID anpassen). Deshalb wäre es mir am liebsten, wenn ich in meiner Bootpartition zwei Verzeichnisse (etwa system1 und system2) hätte, in denen die jeweiligen Kernels und initrd's liegen. Den Pfad kann ich ja in der menu.lst beliebig angeben. Sinn macht das aber nur, wenn ich dem Kernelupdate sagen kann, wohin der updaten soll. Sonst muss ich jedesmal nachbessern, was auch auf die Nerven geht... Ist das irgendwie möglich?

Ach ja, wo wir schon dabei sind. Nach jedem automatischen Kernelupdate habe ich in der menu.lst zusätzliche Einträge mit dem neuen Kernel. Die Idee ist ja nicht schlecht, auch noch auf das alte System zugreifen zu können. Allerdings muss ich damit jedesmal die menu.lst meinen Wünschen neu anpassen. Kann man dieses Verhalten irgendwie beeinflussen?

Cookie2718

Cookie2718 schrieb:

Das mit dem Chainloader hört sich interessant an. Müsste ich dann einfach den selben Eintrag wie für Windows in die menu.lst schreiben? Also etwa:

title        Zweites System
root         (hdX,Y)
chainloader  +1

Genau so. Das leitet dann weiter zum Testsystem-eigenen Grub in der Partition.

falls ich Ubuntu mal neu installieren möchte

Äääh ... welches von den beiden denn? 😉

nicht um die menu.lst kümmern (außer veilleicht die UUID anpassen).

So ist doch auch nur minimales Editieren fällig. Im Falle des "vorderen" Systems den fertigen Chainloader-Eintrag am Ende der menu.lst ent-kommentieren und hd(X,Y) anpassen, und im Falle des "hinteren" Systems bloß den Grub in die eigene Partition installieren lassen.

Ist das irgendwie möglich?

Keine Ahnung, aber es ist vom Aufpass- und Anpassungsaufwand eher nerviger als mein Vorschlag, denke ich.

Ach ja, wo wir schon dabei sind. Nach jedem automatischen Kernelupdate habe ich in der menu.lst zusätzliche Einträge mit dem neuen Kernel. Kann man dieses Verhalten irgendwie beeinflussen?

Ja. Innerhalb des "Automagic Kernels List"-Abschnitts gibt es die doppelt auskommentierten Kommentare und die einfach auskommentierten Variablen, die man ändern, aber nicht ent-kommentieren kann. Sie werden von den automatischen Grub-Skripten ausgewertet. Unter anderem gibt es folgende Option:

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
##      howmany=7
# howmany=all

Wenn Du das auf 3 setzt, behältst Du also drei normale und drei Recovery-Einträge. Einträge außerhalb der Automagic Kernels List sind davon nicht betroffen.

Gruß

Prometheus

Was ich mit

nicht um die menu.lst kümmern

meine, ist, dass ich mir das Sichern und ähnliches bei einer Neuinstallation eines der beiden System sparen kann. (Kein Angst. Ich hab schon noch ne Sicherungskopie, falls was schief geht. ☺). Von daher wäre mir eine eigene Bootpartition lieber. Allerdings habe ich den spärlichen Informationen, die mir Google geliefert hat, leider auch entnommen, dass das Beeinflussen des Kernelupdates schwierig ist. Weiß vielleicht jemand anderes was zu dem Thema?

Was deine Lösung angeht:

1. Bei dem zweiten System wird dann wieder GRUB geladen, sodass theoretisch ein zweites Bootmenü erscheint, solange ich das nicht abstelle, richtig?

2. Spricht was dagegen, als Workaround beide Systeme mit chainload zu booten? D.h. ich habe eine Bootpartition, die nirgends gemountet wird und auf der wirklich nur GRUB liegt (keine Kernels oder initrd's) und die den Bootvorgang an die beidenanderen GRUB's weiterreicht, wobei bei denen jeweils kein Bootmenü erscheint.

Cookie2718 schrieb:

1. Bei dem zweiten System wird dann wieder GRUB geladen, sodass theoretisch ein zweites Bootmenü erscheint, solange ich das nicht abstelle, richtig?

Sind halt zwei Enter-Drücke direkt hintereinander 😉 Du kannst den zweiten Grub auch in der menu.lst auf "hiddenmenu" setzen.

2. Spricht was dagegen, als Workaround beide Systeme mit chainload zu booten? D.h. ich habe eine Bootpartition, die nirgends gemountet wird und auf der wirklich nur GRUB liegt (keine Kernels oder initrd's) und die den Bootvorgang an die beidenanderen GRUB's weiterreicht, wobei bei denen jeweils kein Bootmenü erscheint.

Das müsste gehen. Deine Bootpartition muss dann nur ein paar Megabyte groß sein, und den Grub installierst Du einfach mit irgendeiner Live-CD. Dann kann jedes der beiden Ubuntu-Setups seinen eigenen Grub in die eigene Partition installieren. Ein Bootmenü wirst Du zumindest beim zweitinstallierten System zu sehen bekommen, weil dieses beim Grub einrichten das erstinstallierte finden wird. Wiederum: hiddenmenu in der menu.lst setzen.

Gruß

Prometheus