grub1 startet grub2 nicht!?

[k2]

Hi,

in einer Multiboot-Umgebung dient eine Lenny-Console ausschließlich als Service-OS; d. h. für Backups, zur Pflege gemeinsam genutzter Datenbestände und für den Bootvorgang mittels grub im MBR. Dieser startet dann die div. Arbeits- und Testinstallationen mittels chainloader. Seit grub2 im Einsatz ist, bei Squeeze oder auch Linux Mint Debian Edition, kann der Bootloader im MBR die Bootloader von grub2 im BR der jeweiligen Partition nicht starten.

Ist das grundsätzlich so, oder müssen diese auf eine andere Art und Weise gestartet werden als durch chainloader +1? Die Grub2-Fehlermeldung jedenfalls besagt immer, der Bootrecord der entsprechenden Partition wäre nicht ausführbar!

Hat schon einmal jemand mit grub1 im MBR einen grub2 auf der Partiton gestartet?

Grüße k2

[rendegast]

grub2 priorisiert Installation (des Bootcodes) in den MBR,
in die Partition nur auf Nachfrage mit Warnung.

grub1 / legacy, Hier wird es zumindest angesprochen:
http://www.gnu.org/software/grub/manual/legacy/
http://www.gnu.org/software/grub/manual ... B-natively

Code: Alles auswählen

Once you've set the root device correctly, run the command setup (see setup):
     grub> setup (hd0)
This command will install the GRUB boot loader on the Master Boot Record (MBR) of the first drive. If you want to put GRUB into the boot sector of a partition instead of putting it in the MBR, specify the partition into which you want to install GRUB:
     grub> setup (hd0,0)
If you install GRUB into a partition or a drive other than the first one, you must chain-load GRUB from another boot loader. Refer to the manual for the boot loader to know how to chain-load GRUB. 

Vergleiche dazu die Doku zum grub2 http://www.gnu.org/software/grub/manual/grub.html

Hat schon einmal jemand mit grub1 im MBR einen grub2 auf der Partiton gestartet?

Allgemeiner gesprochen:
"Hat schon einmal jemand mit chainload einen grub2 auf der Partiton gestartet?"
Ich nicht,
aber schonmal ein Dateisystem damit zerstört (zum Glück nur frisch aufgesetzte Testsysteme)
Was eventuell geht, wäre das core.img über chainload anzusprechen,
Oder den Bootcode in eine kleine dummy-Partition zu legen.
Oder dann wieder eine Image-Datei zu erwägen (core-img ist das ja),
und falls grub-install sich da sträubt, diese vielleicht mit kvm-nbd als Blockdevice zur Verfügung stellen?

[k2]

Hi,

grub2 priorisiert Installation (des Bootcodes) in den MBR,
in die Partition nur auf Nachfrage mit Warnung.

Das würde ja bedeuten, dass (bei mir) 4 Arbeits- und Testinstallationen versuchen würden, ihren Bootcode in den MBR zu schreiben. Welch' Chaos bei den Updates! Deswegen habe ich u. a. das Service-OS, so kann jede Installation ihren grub auf der eingenen Partition updaten - und lässt den MBR unangetastet.

Allgemeiner gesprochen:
"Hat schon einmal jemand mit chainload einen grub2 auf der Partiton gestartet?"

- da hast Du es auf den Punkt gebracht! Aber das muss möglich sein, ich werde daran arbeiten.

So habe ich nun noch zwei Möglichkeiten:
1.) Versuchen ob grub2 einen grub2 mittels chainloader starten kann, oder
2.) die anderen Installationen von grub2 zu grub-legacy downgraden oder gleich einen anderen Bootloader verwenden.

Ich werde wohl gleich das Service-OS von Lenny auf Squeeze updaten; bei den paar Konsolentools wohl keine große Aktion, und damit grub1 durch grub2 ersetzen.

DANKE erstmal!
k2

[rendegast]

so kann jede Installation ihren grub auf der eingenen Partition updaten
...
oder gleich einen anderen Bootloader verwenden

Eigentlich brauchst Du den Bootcode gar nicht.
Beim kernel-upgrade wird nur update-grub (menu.lst / grub.cfg) gebraucht.
Die jeweiligen /boot/grub/grub.cfg könntest Du aus der custom.cfg des "Hauptgrub" ansprechen

Code: Alles auswählen

  source (hdX,XXXXX)/boot/grub/grub.cfg;
  source (hdY,YYYYY)/boot/grub/grub.cfg;
  source (hdZ,ZZZZZ)/boot/grub/grub.cfg;
...

Zum Zurückspringen in den jeweiligen custom.cfg einen Eintrag ala

Code: Alles auswählen

menuentry .... {
    root (hd0)
    chainloader +1
}