seit dem letzten Update ist mein Bootloader (Grub2) im Eimer, d.h. ich lande beim Hochfahren immer im Grub-Rescue-Prompt. Es hat (glaube ich) damit angefangen, dass nach dem Update ein Grub-Konfigurationsdialog eingefroren ist (warum startet der überhaupt von selbst?), also ohne mein Zutun. Ich boote jetzt mit der Super Grub2 Disk und habe versucht, Grub neu zu konfigurieren, und zwar mittels grub-install, update-grub und grub-mkconfig und zwar unter / UND /boot (extra Bootpartition). Jedesmal werden alle Systeme (Ubuntu, Windows) erkannt und ich erhalte die Meldung "No errors were reported.".

Trotzdem lande ich nach wie vor im Rescue-Prompt. Jetzt frage ich mich, woran es noch liegen könnte? Wird der MBR eventuell nicht überschrieben? Ist das Paket (grub-pc) defekt?

Man kann auch irgendwie Pakete reparieren oder so auswählen. Lass das mal durchlaufen. Und anschließend probiers noch mal mit grub-install, etc.

Hab ich schon probiert, wird nicht als defekt erkannt. hab aber auch schon apt-get purge grub-pc und install danach probiert. problem bleibt weiterhin

http://codezentrale.bplaced.net/dcz/?p=1436

Das hab' ich alles schon probiert (eigentlich schon vor dem ersten Post), aber es hilft nix. Ich hab zwischenzeitlich mal den MBR mit dem Windows-Bootloader überschrieben, dann wieder GRUB und wollte sehen, ob sich was tut. Aber ich lande weiterhin in der Recovery-Console. Das heißt doch, dass GRUB die grub.cfg nicht finden konnte, oder? Aber die liegt ja unter /grub und /boot/grub ... was kann denn da schief laufen?

Bei mir ist die /etc/grub.conf und liegt da, wo meist alle Konfigurationsdateien liegen sollten, im Verzeichnis /etc/.

Bei mir gibt es keine /etc/grub.conf. Sicher, dass du Grub2 verwendest? Also jedenfalls sollte dort das Bootmenü zu finden sein, bzw. ist es auch.

Bei modernen Distros werden die Diskpfade typischerweise per Partitions-UUID oä. angegeben, was an sich ja auch eine tolle Sache ist. Aber offensichtlich ist Grub 2 noch nicht so richtig robust und ich hatte einen einzelnen Desktop, der diese Angabe irgendwann einfach nicht mehr vertragen hat und nicht mehr booten wollte.

Als ich die Bootparameter dahingehend umeditierte, dass die Rootpartition nicht mehr per UUID, sondern ganz klassisch ( /dev/sda3 oä.) angegeben wird, hat alles wieder funktioniert.

Ich hatte bis dato keine Zeit mir das genauer anzusehen und nachdem das System sowieso komplett automatisiert per Preseeding und Puppet aufgesetzt war, habe ich es einfach geplättet und neu installieren lassen. Könnte man bestimmt auch reparieren, aber ich habe selbst gute 20 Minuten lang keine Lösung gefunden und daraufhin beschlossen, dass mir meine Zeit zu schade für sowas ist, wenn neuinstallieren mich keine zwei Minuten Arbeit kostet.

In Deinem Fall ist das natürlich Käse. Wenn es Dir reicht, das Symptom zu bekämpfen und den Rechner wieder normal booten zu lassen, setze evtl. mal in /etc/default/grub GRUB_DISABLE_LINUX_UUID=true , falls Du das gleiche Problem hattest, das ich hatte, sollte das Abhilfe schaffen.

Der Bug könnte der hier oder etwas ähnliches gewesen sein:
https://savannah.gnu.org/bugs/?26834
(Müsste mir mal ansehen, welche Grub-Versionen davon betroffen sind und welche Lucid verwendet.)

knivil: Welche Distro verwendest Du? Es muss auch in /boot eine Grub-Config liegen, bei Ubuntu wird die aus den Daten in /etc/grub.d/ und /etc/default/grub generiert.