grub-pc Update auf 1.99-20 schlägt fehl (amd64)

[samoht]

Die von mir gewünschte Installation in die Root-Partition (also nicht den MBR der Platte) wurde heute früh von der Installations-Routine abgelehnt und empfohlen, nicht fortzufahren.
Im folgenden Schritt wird aber nur die von mir nicht gewünschte Installation in den MBR oder die nicht mögliche Installation in die Root-Partition angeboten - also habe ich den Prozess per kill von einer anderen Konsole abgebrochen.
(Hier sollten eigentlich zwei screenshots stehen :oops: )
Der übliche Reparatur-Versuch ergab:

Code: [Select]

# apt-get -f install
E: Der dpkg-Prozess wurde unterbrochen; Sie müssen manuell »dpkg --configure -a« ausführen, um das Problem zu beheben.Damit wird der gleiche erfolglose Installationszyklus wieder angestoßen.
Deshalb war auch der Wechsel auf testing-Pakete im Runlevel 3 nicht möglich:

Code: [Select]

# apt-get install grub-common/testing grub-pc/testing grub-pc-bin/testing grub2-common/testing
E: Der dpkg-Prozess wurde unterbrochen; Sie müssen manuell »dpkg --configure -a« ausführen, um das Problem zu beheben.Das habe ich dann im Runlevel 5 abermals versucht und hier klappte die Installation  :?:
Greetings, Tom

Siehe auch:
http://aptosid.com/index.php?name=PNphpBB2&file=viewtopic&t=2255
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666992
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/972250

[vindeliker]

Hallo samoht,
grub2 warnt neuerdings, wenn man den Bootloader in eine Partition installieren will. Wenn du aber im MBR einen anderen Bootloader installiert hast, der wiederum auf die Partition verweist, dann passt's ja. Man soll an der Stelle einfach nochmal kurz zum Nachdenken aufgefordert werden, denn wenn du den grub in der Partition stehen hast und der MBR leer ist, dann geht eben nix mehr.
So wie ich das jetzt in Erinnerung habe, läuft die Installation aber durch, es kommt nur diese Warnung.

Grüße
Roland

[ralul]

Man kann die erneute Installation in MBR oder /dev/sdaX-Partition im ersten Dialog ganz ablehnen indem man die Kreuze (x) in den Kästchen entfernt.

Meiner Ansicht (devil - deine Meinung?) nach:
Das System bootet auch weiterhin, auch wenn man bei einem Grub upgrade nach obiger Methode die neuerliche Einnistung des Grub core.img Images verhindert. Wenn dies nicht stimmt, muss man unbedingt eine von den unten angezeigten Methoden nutzen nach einem grub upgrade vor dem Neustart. Ein HOLD eines funktionierenden Grub kann nie verkehrt sein ...

slh's Tip den os-prober zu purgen, wurde schon oft hier angeraten, mit der Alternative in /etc/grub.d/41_custom die üblichen fixen Links auf die Distro spezifischen vmlinuz Dateien zu nutzen.

Wenn man das eingenistete grub core.img erneuern will

1. mbr
grub-install /dev/sda

2. in die Partition
- bei gpt-Platten, oder
- um MsWin nicht zu stören (kann man eigentlich ein chroot vom MsWin aus machen?)
grub-install --force /dev/sdaY

3. eine ganz andere Möglichkeit wurde kürzlich auf der openSUSE-devel Mailingliste diskutiert, die ich aber noch nicht durchblicke:
/dev/sda4-sei-eine-erweiterte-Partition
/dev/sda5-lässt-am-Anfang-der-sda4-Partition-Platz-für
grub-install in den Anfang der erweiterten Partition

[edit] meine Frage an devil scheint von samoht unten beantwortet:
Wenn man grub nicht in den Mbr sondern in die Partition hinein mit
"grub-install --force <Partition>"
hat, muss man ein neuerliches grub-install nach einem upgrade des grub Pakets machen (lassen).

[samoht]

Danke, @vindeliker, für deinen Kommentar.
In diesem Fall geht es aber nicht um eine bloße Warnung, sondern um die explizite Verweigeung der Installation in die Rootpartition. Das habe ich bisher noch nicht erlebt, ist hoffentlich ein Bug und kein Feature.  :wink:
Deinen Hinweis, @ralul, mit den Kreuzchen kann ich nicht nachvollziehen, siehe nachgereichte Screenshots in meinem ersten Posting.
Greetings, Tom

[ralul]

@samoht, wieso nicht nachvollziehen?

In grub_pc_Installationsziel.png einfache alles disablen, dann bekommst du so irgendeine Nachfrage: Wirklich?

[samoht]

@ralul,
ich wusste nicht, dass man dort alle Kreuze entfernen kann, (warum sollte man auch?).
Ich habe das trotzdem ausprobiert.
Ergebnis. System bootete nicht mehr, d.h. der Bootsektor ist beim Update auf die neue Version 1.99-20 korrumpiert worden.
Erst Downgrade auf testing brachte das System wieder zum Laufen.
Greetings, Tom

[ralul]

@ralul,
ich wusste nicht, dass man dort alle Kreuze entfernen kann, (warum sollte man auch?).

Weil man danach gefragt wird? Und man hat vielleicht grub auf einer Partition installiert, die nicht bootfähig ist. Wie bei mir ubuntu auf /dev/sda8 auf einer hybrid-mbr Gpt-Platte...

Ich habe das trotzdem ausprobiert.
Ergebnis. System bootete nicht mehr, d.h. der Bootsektor ist beim Update auf die neue Version 1.99-20 korrumpiert worden.
Erst Downgrade auf testing brachte das System wieder zum Laufen.

Wie oben von mir geschrieben, manuell nach dem DU:
grub-install --force /dev/sda[PartNr]

[rolandx1]

http://paste.siduction.org/20120403174150.png

so siehts aus
dann probieren wir mal nenn reboot

[rolandx1]

reboot: fail
es erscheint noch ein GRUB am monitor und ansonsten bewegt sich nichts

[devil]

Bitte wartet auf grub-pc 1.99-21, dort ist der Bug gefixt.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23666992

greetz
devil

[ralul]

Ja, ist jetzt aktualisiert. Schuld war wohl ein 4k-alignement patch extra für kfreebsd (wer nutzt es), was jetzt von Colin Watson zurückgezogen ist.

Vielleicht könnene wir hier auch einem anderen Bug auf der Spur kommen. Wenn man in die root Partition gemacht hatte:
grub-install --force /dev/sdaY
sollte ein neues Upgrade vom Paket grub nichts an der Bootfähigkeit ändern, wenn man bei der Nachfrage kein Kästchen ankreutzt:
[ ] /dev/sda
[ ] /dev/sdaY
Ich habe noch kein DU mit dem neuen grub gemacht.
@devil, wo kann ich die debconf Priorität so einstellen, dass ich diese Nachfrage auf jeden Fall bekomme? (sonst wäre es bei mir natürlich /dev/sda3 voreingestellt)