grub nach upgrade kaputt

[str]

Moin,

seit dem upgrade auf Point-Release 6.0.3 lässt sich grub auf keinem Weg mehr zur Arbeit überreden. Bis dahin lief er problemlos.

Im MBR verwende ich einen anderen Bootmanager, weshalb ich grub in den PBR der / Partition installiert habe (schon immer). Beim letzten dist-upgrade kam das übliche Gemecker von wegen "BAD idea" in einen PBR zu installieren und blocklists sind böse böse...
Aber bislang hat es ja funktioniert. Aber jetzt: Beim booten erscheint "GRUB" unten rechts auf dem Display - und nix mehr!

Installer CD gefühlte 512 mal im Rescue-Modus gebootet und folgende Rettungsversuche vorgenommen (jedesmal mit demselben Resultat):
* update-grub
* grub-install
* grub deinstalliert & neu installiert
* grub "gepurget" & neu installiert
* grub deinstalliert und versucht lilo zu installieren. Der aber verweigerte die Installation schon im Ansatz mit der Begründung, dass in /ect/fstab für diese Partition ein Label eingetragen ist (sollte man ja beim Upgrade auf lenny glaube ich machen) und das also kein Blockdevice sein könne. ????? Also den Eintrag in der fstab noch mit der UUID versehen und lilo war immer noch der Meinung das könne kein Blockdevice sein. Aaaaaarggh!!!

Hat irgendjemand noch eine Idee was ich noch versuchen könnte? Es kann doch nicht so schwer sein einen Bootloader zu installieren...
Vor allem wenn er bis zum Upgrade immer lief!

Gruß
Stephan

[syssi]

Hast du das Ganze in einem Chroot gemacht? Dann hast du moeglicherweise ein paar Binds vergessen?

Ich haette es so gemacht:

Code: Alles auswählen

mkdir /mnt/system
mount /dev/rootpartition /mnt/system
mount --bind /dev /mnt/system/dev
mount --bind /proc /mnt/system/proc
mount --bind /sys /mnt/system/sys
chroot /mnt/system
update-grub

[str]

Die nötigen Einstellungen scheint der Rescue Mode der Installer CD bereits vorzunehmen:

Code: Alles auswählen

#mount
/dev/sda8 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

Bin ich denn der einzige, dessen grub Installation beim Upgrade zerschossen wurde? Jedenfalls bin ich definitiv nicht der einzige, der den Bootloader in den PBR installiert, das haben die Reaktionen zum Umstieg auf grub2 klar gezeigt.

Gruß
Stephan

[r900]

Hast du es mal mit 'grub-install /dev/sdxx' probiert? wobei du sdxx natürlich durch deine root-partition ersetzt. Ist der andere boot-loader im MBR noch intakt? Wie sieht deine Partitionierung aus (fdisk -l)?

[str]

mit grub-install meinte ich natürlich grub-install --force /dev/sda8

Die Partitionstabelle ist genau wie zuvor. Wie gesagt, bis zum Upgrade funktionierte grub im PBR. Außer apt-get dist-upgrade habe ich keine Eingriffe vorgenommen.

[syssi]

Was passiert denn ueberhaupt, wenn du versuchst Linux zu booten? Irgendwelche Grub-Fragmente (grub-rescue) zu sehen? Einfach nur ein blinkender Cursor? Ein Reboot?

[Cae]

mit grub-install meinte ich natürlich grub-install --force /dev/sda8

Nicht in den MBR? /dev/sda?

Gruß Cae

[r900]

Nicht in den MBR? /dev/sda?

Das will er doch nicht, weil er da einen anderen tollen bootloader hat..

seit dem upgrade auf Point-Release 6.0.3

Vorher hattest du aber schon 6.0, also Squeeze, oder? Frage nur weil du auch was von Lenny schreibst.

Könnte ein bug sein, probier doch mal die Version aus testing. Wenn ich mir die Abhängigkeiten angucke müsste das gehen. Also wenn du alle grub-Pakete aus testing installierst (grub-pc, grub-pc-bin, grub-common und grub2-common).

[Cae]

Nicht in den MBR? /dev/sda?

Das will er doch nicht, weil er da einen anderen tollen bootloader hat..

… oh. Lesen hilft.
Dann schließe ich mich mal deiner Frage an: "fdisk -l /dev/sda"? Ist /dev/sda8 als bootfähig markiert? Das ist das Sternchen in der "Boot"-Spalte.

Gruß Cae

[str]

Was passiert denn ueberhaupt, wenn du versuchst Linux zu booten? Irgendwelche Grub-Fragmente (grub-rescue) zu sehen? Einfach nur ein blinkender Cursor? Ein Reboot?

Unten links auf dem Bildschirm steht "GRUB" - dann passiert nix mehr.

Vorher hattest du aber schon 6.0, also Squeeze, oder? Frage nur weil du auch was von Lenny schreibst.

Ist Squeeze, seit kurz nach dem Release und Upgrade auf jedes Point-release kurz nach der Ankündigung.
Von Lenny schrieb ich, dass es für den Upgrade nötig war die Partitionen auf IDE Platten mit Labels zu versehen. Bin mir aber nicht so sicher ob es dieser Zeitpunkt war. Tut aber glaube ich auch nicht wirklich was zur Sache.

Könnte ein bug sein, probier doch mal die Version aus testing. Wenn ich mir die Abhängigkeiten angucke müsste das gehen. Also wenn du alle grub-Pakete aus testing installierst (grub-pc, grub-pc-bin, grub-common und grub2-common).

Wenn ich mir die Abhängigkeiten angucke, sehe ich z. B. debconf, was wiederum einen ganzen Rattenschwanz an Abhängigkeiten nach sich zieht. So ein manuelles Gefrickel habe ich irgendwann schon einmal versucht, mit dem Ergebnis dass irgendwann das halbe System aktualisiert war und gar nichts mehr ging. Ob es ein Bug sein könnte, war eigentlich der Grundgedanke hinter meiner Anfrage. Aber da ich der einzige mit dem Problem zu sein scheine, sitzt ebendieses offensichtlich vor dem Gerät...

Dann schließe ich mich mal deiner Frage an: "fdisk -l /dev/sda"? Ist /dev/sda8 als bootfähig markiert? Das ist das Sternchen in der "Boot"-Spalte.

fdisk -l kann ich erst heute abend ausführen. Ich weiß aber, dass "mein anderer toller bootloader" die Partition für das jeweils gewählte OS als bootfähig markiert (ist eben ein toller bootloader ).

Gruß
Stephan

[cosmac]

hi,

und wenn du mit "deinem anderen tollen bootloader" direkt kernel und initrd von sda8 lädst? Ohne Umweg über einen zweiten Bootloader? O.K., das ist nicht so elegant, aber dafür könntest du weitere Versuche aus dem original-squeeze heraus machen. Damit entfallen die chroot-Fehlerquellen.

Auf der Grundlage könntest du auch extlinux statt grub installieren (wenn du sogar schon lilo versucht hast...)

[r900]

Wenn ich mir die Abhängigkeiten angucke, sehe ich z. B. debconf, was wiederum einen ganzen Rattenschwanz an Abhängigkeiten nach sich zieht.

Die Abhängigkeit debconf (>= 0.5) hat das Paket aus stable aber auch, den "Rattenschwanz" hast du also ohnehin schon installiert. Trag doch einfach mal probehalber testing zusätzlich in die sources.list ein und pin es auf 100. Dann installierst du mit 'apt-get -t testing install grub-pc'. Wenn er dann wirklich zu viele Pakete aus testing installieren will kannst du ja immer noch verneinen.
Wenn ich durch die bugs blättere steht da schon das ein oder andere was auf deine Beschreibung passen könnte.
Wenn dir das alles zu viel ist kannst du natürlich auch einfach wieder die vorherige Version installieren.

[str]

Grub aus testing funktioniert auch nicht. Bringt aber immerhin bei der Konfiguration eine Fehlermeldung:

Code: Alles auswählen

Package configuration
Configuring grub-pc
GRUB failed to install to the following devices:
/dev/sda8

Nur fehlt mir in der Meldung der entscheidende Hinweis wo's denn hakt und was ich besser machen kann.

und wenn du mit "deinem anderen tollen bootloader" direkt kernel und initrd von sda8 lädst? Ohne Umweg über einen zweiten Bootloader?

So toll ist mein toller bootloader nun wieder auch nicht der kocht auch nur mit Wasser und kann nur "chainloaden".

Hier noch das Ergebnis von fdisk -l

Code: Alles auswählen

Disk /dev/sda: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x16691668

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         973     7815591   17  Hidden HPFS/NTFS
/dev/sda2             974        2432    11719417+  17  Hidden HPFS/NTFS
/dev/sda3            2433       23953   172867402    5  Extended
/dev/sda5            2433        2433        8001   78  Unknown
/dev/sda6            2434        6323    31246393+   b  W95 FAT32
/dev/sda7            6324       14104    62500851    7  HPFS/NTFS
/dev/sda8   *       14105       15077     7815591   83  Linux
/dev/sda9           15078       15199      979933+  82  Linux swap / Solaris
/dev/sda10          15200       22980    62500851   83  Linux
/dev/sda11          22981       23953     7815591   83  Linux

Aber wie gesagt, mit eben dieser Partitionierung hat es bislang immer funktioniert.

Ich denke ich werde mal im Pool nach den alten grub Paketen suchen und versuchen ob ich die so wie jetzt die aus Testing irgendwie manuell installiert kriege.

Gruß
Stephan

[Cae]

Ich denke ich werde mal im Pool nach den alten grub Paketen suchen und versuchen ob ich die so wie jetzt die aus Testing irgendwie manuell installiert kriege.

Ich denke, du solltest deinen tollen Bootloader in die Tonne kloppen und das alles per GRUB2 machen. Mit dem hatte ich unter den abartigsten Konfigurationen noch nie Probleme, sofern keine Layer 8-Störung vorlag.
Mach ein Backup vom MBR, installiere os-prober und dann grub-install /dev/sda && update-grub. Falls etwas schief geht, kannst du per live-CD den MBR wieder einspielen und es ist wie zuvor.

Gruß Cae

[cosmac]

Ich denke, du solltest deinen tollen Bootloader in die Tonne kloppen und das alles per GRUB2 machen.

und das ausgerechnet in diesem Thread... Was ist die Steigerung von Sarkasmus? Oder hab' ich was übersehen?

[str]

Ich denke, du solltest deinen tollen Bootloader in die Tonne kloppen und das alles per GRUB2 machen.

Genau das möchte ich ja gerade vermeiden. Wie man sieht, kann ein update von grub auch schon mal schief laufen. Im MBR würde das den Start aller installierter OSe verhindern. Wenn ich eine grub Installation je OS Version im zugehörigen PBR ablege kann mir auch nur die abschmieren. Alle anderen OSe kann ich nach wie vor vom "Master"-Bootloader starten. Das ist übrigens XOSL, der ist zwar schon "100 Jahre alt" aber den finde ich (neben der Tatsache, dass er funktioniert) optisch deutlich ansprechender und einfacher zu konfigurieren als grub.

Außerdem spare ich mir damit Inkonsistenzen durch das deinstallieren, neu installieren und aktualisieren von anderen Distributionen (demnächst steht eine Testphase mit wheezy an) sowie der Frage wer darf jetzt und wer muss wann den MBR-grub aktualisieren.

sofern keine Layer 8-Störung vorlag

Genau danach suche ich ja gerade. Aber die Fehlermeldungen von grub sind mir dabei keine echte Hilfe.

Gruß
Stephan

[Cae]

Ich denke, du solltest deinen tollen Bootloader in die Tonne kloppen und das alles per GRUB2 machen.

und das ausgerechnet in diesem Thread...

Das wäre nun mal eine saubere Lösung, von der ich weiß, dass sie von Anfang bis Ende funktioniert. Bisher hat sich der TE nicht mal dazu geäußert, welchen ersten Bootloader er einsetzt! Er wurde nicht gefragt, aber es hängt wohl unmittelbar zusammen.
--Edit: okay, das hat sich wohl erledigt, da er es kurz vor meinem Post geschrieben hat.

Gruß Cae

[r900]

Aber wie gesagt, mit eben dieser Partitionierung hat es bislang immer funktioniert.

Hast du eigentlich schon mal das Dateisystem auf sda8 überprüft? Könnte ich mir als Fehlerquelle ebenfalls vorstellen.

Ich denke ich werde mal im Pool nach den alten grub Paketen suchen und versuchen ob ich die so wie jetzt die aus Testing irgendwie manuell installiert kriege.

Im normalen pool wirst du das nicht mehr finden, dafür gibt es snapshot.debian.org. Die momentane Version ist 1.98+20100804-14+squeeze1 und kam am 19.09.2011 ins Archiv. Also trägst du z.B. den snapshot vom 04.09. in deine sources.list ein:

Code: Alles auswählen

deb http://snapshot.debian.org/archive/debian/20110904T213109Z/ squeeze main
deb http://snapshot.debian.org/archive/debian-security/20110904T121433Z/ squeeze/updates main

Dann kannst du nach 'apt-get update' mit 'apt-get install grub-common=1.98+20100804-14 grub-pc=1.98+20100804-14' die vorherige Version installieren.

EDIT: 'apt-get -o Acquire::Check-Valid-Until=false update' ist der richtige Befehl, sonst ignoriert apt den snapshot.

[str]

Habe am WE noch einiges ausprobiert. Zuerst die letzte grub Version installiert - und keine Änderung, Ausgabe "GRUB" und das System steht. Da das aber vorher definitiv funktioniert hat, deutet es auf einen defekten Bootsektor hin.

Hast du eigentlich schon mal das Dateisystem auf sda8 überprüft? Könnte ich mir als Fehlerquelle ebenfalls vorstellen.

Als nächstes ein fsck -c /dev/sda8 gemacht. Als Meldung erschien "updating bad block inode" und "filesystem was modified", aber keinen Hinweis darauf, ob schlechte Blöcke oder andere Fehler gefunden wurden. Neustart und nochmal update-grub brachten auch keine Änderung. Damit wäre der Verdacht "Platte hin" weder bestätigt noch widerlegt.

Aber einen Versuch haben wir ja noch: in /dev/sda11 liegt noch eine funktionierende Installation aus der Zeit, als squeeze noch testing war. Zu der Zeit weigerte sich grub komplett, in einen PBR installiert zu werden, bot aber als Alternative einen Rückfall auf lilo an. Und genau der sitzt noch im PBR von sda11 und funktioniert. Also habe ich dieses System gestartet und dort ein dist-upgrade gemacht. Und ganz mutig auch grub aktualisiert. Was soll ich sagen: beim nächsten Start bootete wieder lilo...
Letzter Versuch: grub-install --force /dev/sda11 und update-grub, immer noch lilo.
Das sieht für mich so aus, als würde grub trotz --force gar keinen Bootsektor schreiben, wenn nicht der MBR angegeben ist. Petzt aber nicht, sondern meldet brav "No errors". Das jetzt plötzlich 2 Bootsektoren defekt sein sollen (mindestens einer noch lesbar aber nicht mehr schreibbar) scheint mir dann doch recht unwahrscheinlich, also scheidet Plattendefekt wohl auch aus.

Kann irgend jemand bestätigen, dass die aktuelle grub Version im PBR funktioniert? Wenn ja wie macht man das? Was gibt es da falsch zu machen?

Gruß
Stephan

[r900]

Kann irgend jemand bestätigen, dass die aktuelle grub Version im PBR funktioniert?

Ich probiere es heute abend mal in meiner VirtualBox aus und erstatte Bericht

Haben eventuell zwei deiner Partitionen die selbe UUID/das selbe label? Passiert typischerweise durch klonen mit dd.
Als letztes Mittel fiele mir noch ein in der fstab die UUID wieder durch /dev/sdxx zu ersetzen, in /etc/default/grub UUID zu deaktivieren und dann nochmal 'update-grub' und 'grub-install /dev/sdxx --force'. In dieser Reihenfolge.
Das würde zumindest Probleme mit label oder UUID ausschließen. Die Empfehlung in der fstab UUID's einzutragen hatte ja hauptsächlich mit Änderungen an libata und dem Übergang von /dev/hdx nach /dev/sdx zu tun.

[r900]

So, also prinzipiell scheint grub im pbr zu funktionieren. In meiner Virtualbox hab ich Lenny und Squeeze. Und da hab ich einfach mal lilo aus Lenny in den MBR installiert und grub aus Squeeze in die root-Partition. Das war allerdings eine primäre Partition. Installation aus chroot heraus konnte ich auch nicht testen.
Was du noch probieren könntest wäre die Vorgängerversion von grub2. Die bekommst du über das Paket grub-legacy. Es sei denn deine root-Partition ist ext4, das unterstützt grub-legacy nämlich nicht.

[str]

grub deinstalliert und grub-legacy installiert (habe zwar keine Meldungen gesehen, gehe jedoch davon aus, dass das Paket in einen funktionsfähigen Zustand konfiguriert wurde).
Das Ergebnis war wie immer GRUB beim booten und nix mehr. (Mit anderen Worten: der PBR wurde offenbar auch hier nicht überschrieben)
Also wieder Installer-CD im Rescue-Mode und dann dies hier::

Code: Alles auswählen

#grub-install /dev/sda8
Searching for GRUB installation directory ... found: /boot/grub


    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

       [ Minimal BASH-like line editing is supported.   For
         the   first   word,  TAB  lists  possible  command
         completions.  Anywhere else TAB lists the possible
         completions of a device/filename. ]
grub> root (hd0,7)
 Filesystem type is ext2fs, partition type 0x83
grub> setup  --stage2=/boot/grub/stage2 --prefix=/boot/grub (hd0,7)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,7)"... failed (this is not fatal)
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,7)"... failed (this is not fatal)
 Running "install --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0,7) /boot/grub/stage2 p /boot/grub/menu.lst "... failed

Error 22: No such partition
grub> quit

Habe dann noch in der fstab die UUID durch den Devicenamen ersetzt und nochmal update-grub und grub-install. Das Ergebnis war aber wieder dasselbe.

[r900]

Kaum zu glauben dass es in Debian scheinbar momentan keinen bootloader gibt der halbwegs zuverlässig funktioniert
Versuch es doch nochmal ohne das grub-install script. Vielleicht kommt dann auch eine etwas ausführlichere Fehlermeldung:

Code: Alles auswählen

grub --device-map=/boot/grub/device.map
grub> root (hd0,7)
grub> setup --stage2=/boot/grub/stage2 --prefix=/boot/grub (hd0,7)
grub> quit
update-grub

Das "grub>" am Anfang der Zeilen sollst du übrigens nicht eingeben, das soll nur verdeutlichen dass diese Kommandos innherhalb von grub eingegeben werden müssen. In /boot/grub/device.map sollte stehen: "(hd0) /dev/sda".

[str]

IT WORKED!

Die manuelle Abarbeitung in der grub shell brachte dasselbe Ergebnis wie der Aufruf von grub-install inkl. der Fehlermeldung "No such partition".
Der entscheidende Hinweis war der auf den Inhalt von device.map, dort habe ich die vorhandene Zeile auskommentiert und die vorgeschlagene Zeile angefügt:

Code: Alles auswählen

#(hd0)   /dev/disk/by-id/ata_SAMSUNG_SP2014N_S088J1PP106506
(hd0)    /dev/sda

Damit war das Setup erfolgreich, update-grub lief wie gewohnt und der anschließende Boot-Vorgang hat funktioniert, so dass ich hier aus dem erstmals erfolgreich gestarteten System seit dem Point-Release posten kann.

@ r900
Vielen Dank für die Hilfe, da wäre ich von allein niemals drauf gekommen!


PS: fragt man sich, was es mit dem Eintrag in der device.map auf sich hat. Ich habe den Original-Eintrag da nicht reingetan. Der muss bei irgendeinem Installationsschritt (sicherlich von einem DI, aber k. A. von welcher Version) da reingeschrieben worden sein und grub muss das ja auch mal so verstanden und verarbeitet haben. Jedenfalls sieht der Eintrag aus, als wäre er aus den Plattenparamern erstellt worden und an denen hat sich nichts geändert! Aber grub muss sich geändert haben wenn er diesen Eintrag "auf einmal" nicht mehr mag.

Gruß
Stephan

[AxelMD]

Hallo str,

kannst Du nochmals bitte genau beschreiben wie Du Grub2 in in PBR installiert hast?
Das ist hier doch ein wenig durcheinander geraten.

Ich habe ein ähnliches Problem:

http://debianforum.de/forum/viewtopic.php?f=12&t=133081

Und genau deine Philosphie in Bezug auf Chainloading vertrete ich auch, und das auch mit XOSL. Obwohl sehr alt, funktioniert der super.

MfG

xsid