[gelöst]GRUB und sehr farbige Information

[halo44]

Habe leider keine wirklich passende Sektion für meine Frage gefunden.

Weil mein "Suspend to disk" unter Jessie schon länger nicht mehr funktioniert, führe ich inzwischen /usr/sbin/pm-utils aus, was allerdings auch nur etwa jedes zweite Mal das tut, was es soll: eben problemlos auf Power-Button wieder korrekt aufwachen. Aber das nur vor meiner eigentlichen Frage:

Was soll ich damit anfangen, wenn ich meinen Rechner per Power-Button wieder aufwecken will und erhalte dieses bunte Bild:



Ich kann mir damit helfen, daß ich bei meinem MSI-AMD-Mainboard bei Start F11 betätige und das Bootmedium HDD auswähle. Dann startet mein Jessie wie gewohnt.

Dieser Behelf kann aber nicht die Lösung sein. Vermutlich wäre dies eher die Reparatur des Bootloaders über Live-CD/DVD, was ich sicher noch versuchen werde.

Bis dahin aber würde mich interessieren, ob jemand weiß, was meinen Rechner zu dieser "Präsentation" motiviert.

Gruss H.

P.S. wie kann ich Bilder kleiner machen, d.h. Thumbs, die erst bei Klick das größere Bild zeigen?

[rendegast]

Mach mal nach einem funktionierenden Start
grub-install --recheck --no-floppy /dev/sdX
grub-install --recheck --no-floppy /dev/sdY
grub-install --recheck --no-floppy /dev/sdZ
Alternativ

Code: Alles auswählen

dpkg-reconfigure grub-pc

mit den devices /dev/sdX, /dev/sdY ... ausgewählt.
Entsprechend bei gpt + mbr-Partition oder bei EFI.

Vielleicht ist der stage1-Code (einer oder mehrerer Platten) schon länger nicht mehr synchron zum installierten grub gemacht worden.

[halo44]

Mach mal nach einem funktionierenden Start
grub-install --recheck --no-floppy /dev/sdX
grub-install --recheck --no-floppy /dev/sdY
grub-install --recheck --no-floppy /dev/sdZ
Alternativ

Code: Alles auswählen

dpkg-reconfigure grub-pc

mit den devices /dev/sdX, /dev/sdY ... ausgewählt.
Entsprechend bei gpt + mbr-Partition oder bei EFI.

Vielleicht ist der stage1-Code (einer oder mehrerer Platten) schon länger nicht mehr synchron zum installierten grub gemacht worden.

Hiermit bin ich wirklich überfordert. Ich verstehe zunächst nicht, was Du mit X, Y und Z meinst. Auf meinem Rechner habe ich zwei Festplatten sda und sdb. Ich boote von sda, habe also mal nur ausgeführt:

Code: Alles auswählen

grub-install --recheck --no-floppy /dev/sda

Beim folgenden Startversuch zeigt mein Display nur noch

GRUB

jetzt ohne die farbigen Character. Allerdings kann ich keine Eingaben machen, zumal auch hinter dem GRUB kein > folgt.

Ich kann jetzt aber wieder über F11 Jessie starten. Soll ich lieber doch den Bootloader über eine Live-CD reparieren oder kannst Du mir detaillierter weitere Schritte empfehlen?

Gruss H.

[rendegast]

grub-install --recheck --no-floppy /dev/sdX
grub-install --recheck --no-floppy /dev/sdY
grub-install --recheck --no-floppy /dev/sdZ

....
Ich verstehe zunächst nicht, was Du mit X, Y und Z

Das richtige / die richtigen devices trägst Du selber ein.
In der Form kann sich niemand durch einfaches c+p ein Ei ins Nest legen, da es sdX/Y/Z auf keinem System gibt.
Ich hatte aber auch 'dpkg-reconfigure' angegeben, wobei sich die entsprechenden sdX/Y/Z einfach ankreuzen lassen.

Eventuelle Schwierigkeit bei einer vorliegenden Mehrplatten-Konfiguration:
vielleicht werden in den diversen MBR auf Wunsch des Admin verschiedene grub-stage1 verschiedener Systeme vorgehalten.
Bei sowas weiß der Admin aber meist auch, was er da vorliegen hat.

[halo44]

... Ich hatte aber auch 'dpkg-reconfigure' angegeben, wobei sich die entsprechenden sdX/Y/Z einfach ankreuzen lassen ...

Auch das habe ich jetzt versucht für /dev/sda. Ich erhalte zunächst diesen Hinweis

Die folgende Linux-Befehlszeile wurde aus /etc/default/grub oder dem Parameter >>kopt<< in der Datei menu.lst von GRUB Legacy extrahiert. Bitte überprüfen Sie, ob die Befehlszeile korrekt ist und ändern Sie diese, wenn es notwendig ist. Diese Befehlszeile darf leer sein.

Ich habe die leere Zeile auch leer gelassen und erhielt dann diesen Hinweis

Die folgende Zeichenkette wird als Linux-Parameter für den Standardmenüeintrag, nicht aber für den Rettungsmodus verwandt.

Diese Zeile aber zeigt mir eine "alte" UUID meiner Swap-Partition, die bis vor 2 Wochen gültig war. Ich fand auch tatsächlich in der /etc/default/grub diesen falschen Eintrag. Ich habe diese also in der Datei durch die richtige UUID ersetzt und die Rekonfiguration neu gestartet. Anschließend konnte ich tatsächlich das richtige device auswählen und die grub.cfg wurde erstellt.

Beim nächsten Start aber erhalte ich wieder den schwarzen Bildschirm und GRUB. Also keine Änderung.

Ich weiß nicht, wie die "alte" UUID in meine /etc/default/grub geraten ist. Meiner Meinung nach war dort resume garnicht eingetragen.

Da ich ja über F11 das richtige Bootgerät auswählen kann, belasse ich den Zustand zunächst mal so. Vielleicht findest Du ja doch noch eine Erklärung für dieses Verhalten.

Ich werde wahrscheinlich erst morgen die Reparatur des Bootloaders über Live-CD angehen.

Gruss H.

[rendegast]

Diese Zeile aber zeigt mir eine "alte" UUID meiner Swap-Partition, die bis vor 2 Wochen gültig war. Ich fand auch tatsächlich in der /etc/default/grub diesen falschen Eintrag. Ich habe diese also in der Datei durch die richtige UUID ersetzt

Beim aktuellen grub kann ich mir keine swap-UUID in der commandline vorstellen.
Eventuell ein resume-Überbleibsel des grub1?
(resume-Anweisungen befinden sich normalerweise innerhalb der initrd)
Normalerweise kann
GRUB_CMDLINE_LINUX=
GRUB_CMDLINE_LINUX_DEFAULT=
leergelassen werden.
(Ich mache das hier in einer
/etc/default/grub.d/aaa.cfg,
um meine danach folgenden Einstellungen dafür vor jeglichem Gewese des dpkg-reconfigure in /etc/default/grub zu schützen.
Dort setze ich auch erst "meine" Einstellung
GRUB_DEFAULT=...
GRUB_TIMEOUT=...
Anm. 'update-grub' wertet /etc/default/grub und /etc/default/grub.d/*.cfg zusammen aus, für die Optionen gilt last-strike)

Das resume sollte sich auf ein tatsächlich dafür benutztes swap beziehen.
Die Einstellungen dafür dürften sich verstecken in
/etc/default/???
/etc/initramfs-tools/???
/etc/???
/etc/default/grub / /etc/default/grub.d/*.cfg auf gegebenenfalls obsolete Einstellung kontrollieren.
Wenn aktualisiert, neue initrd erstellen 'update-initramfs -u -k all', 'update-grub'.

Die folgende Linux-Befehlszeile wurde aus /etc/default/grub oder dem Parameter >>kopt<< in der Datei menu.lst von GRUB Legacy extrahiert.

Das klingt nach einem nicht vollständigen Transfer grub1 -> grub2.
Du kannst/solltest mal /boot/grub/ löschen, um grub1-Überbleibsel los zu werden.
( Falls vorhanden, den EFI-Link/-Mountpoint darin jedoch unberührt belassen! )
Dann /boot/grub/ wiederherstellen per

Code: Alles auswählen

grub-install ... ...     
(für alle Platten, deren mbr-grub sich auf den aktuellen /boot/grub/ beziehen sollen.
Bei einer gpt-Platte sollte sich auf dieser eine (sehr) kleine Partition vom gpt-Typ 2 "MBR" befinden)
update-grub

oder

Code: Alles auswählen

dpkg-reconfigure grub-pc
resp.
dpkg-reconfigure grub-efi

------------------------------------------
Anmerkung buggy 'dpkg-reconfigure grub-pc':
In der device-Auswahl dürften/sollten sich eigentlich keine Partitionen mehr finden,
da sich grub (aus gutem Grund) weigert, seinen stage1-Code dorthin zu schreiben.
Ausnahmen davon sollte der Admin mit einem expliziten 'grub-install' machen.
Das führt zu buggy 'grub-install': Wenn ich dort ein gefahrloses (weil leeres) Partitions-device angebe,
sollte sich 'grub-install' nicht mit "ist nicht formatiert" weigern, darauf seinen stage1-Code zu schreiben.

[halo44]

Danke Dir für Dein Engagement, leider hat sich bisher keine Änderung ergeben. Aber nun im einzelnen:

Vorab zu eventuellen Grub1-Resten. Die kann es nicht geben, weil ich Debian von Anfang an nur mit Grub2 eingerichtet habe. Grub1 habe ich auch schon bei der Vorgängerdistribution openSuse vor etwa 4-5 Jahren ad acta gelegt.

Der Eintrag der "alten" resume-UUID in der /etc/default/grub findet sich tatsächlich schon in allen Systemsicherungen, die mir noch vorliegen. Mir ist unklar, wie dieser Eintrag entstanden ist.

Ich habe diesen Eintrag jetzt entfernt. Ein Ordner /etc/default/grub.d existiert nicht. Den Eintrag der richtigen UUID in der /etc/initramfs-tools/conf.d/resume habe ich belassen.

Danach habe ich die initrd und die grub.cfg neu erstellt und das System neu gebootet. Keine Änderung: eine schlichtes GRUB auf schwarzem Display.

Ich möchte nochmal erwähnen, daß ich ja mit F11 die /dev/sda als Bootmedium auswählen und dann das OS starten kann. Das sieht für mich so aus, daß der Bootloader keinen Hinweis auf dieses Gerät erhält sondern "woanders" sucht.

Ich werde jetzt mal einen Versuch mit gelöschter /etc/initramfs-tools/conf.d/resume und anschließendem update-initramfs + update-grub unternehmen auch wenn ich skeptisch bin, ob das hilft.

Gruss H.

[halo44]

Dieser Versuch hat erwartungsgemäß keine Besserung gebracht.

Dafür hat aber eine andere Überlegung zur Lösung geführt. Ich zitiere mich mal selbst

Das sieht für mich so aus, daß der Bootloader keinen Hinweis auf dieses Gerät erhält sondern "woanders" sucht.

Ich habe mal beim Systemstart mittels F11 nicht das richtige Bootmedium ausgewählt sondern "Setup" gewählt. Dort fand ich dann in den Bootprioritäten, daß meine zweite Festplatte (sdb) unmittelbar hinter der CD/DVD an zweiter Stelle folgte. Die erste Festplatte mit meinem Bootloader wurde dort garnicht aufgeführt. Ich habe dies geändert und nun startet das System einwandfrei.

Eine Erklärung dafür, wie diese Priorität entstanden sein könnte habe ich nicht. Schließlich trat der Fehler ja auf, als ich meinen Rechner aus dem suspend-to-disk aufwecken wollte. Diesen hatte ich ja aus einem einwandfrei startenden System schlafen geschickt. Wer hat in dieser Zwischenzeit am BIOS bebastelt?

Das Problem ist ja nun gelöst und ich um eine Erfahrung reicher. Vielen Dank nochmal rendegast für Deine Hilfe.

Gruss H.