grub-rescue nach dist-uprade von 7 auf 8

[mistersixt]

Ich habe eben auf einem Server einen dist-upgrade von Debian 7.8 auf Debian 8 gemacht. Nun hänge ich nach dem ersten Reboot im grub-rescue fest . Also habe ich mich mit ls durch die (hdX,Y)-Partitionen gehangelt, um die root und boot Partition ausfindig zu machen. Aber nun:

Code: Alles auswählen

grub rescue> set root=(hd0,msdos2)
grub rescue> set prefix=(hd0,msdos2)/boot/grub/i386-pc
grub rescue> insmod linux
error: symbol not found: `grub_realidt'
grub rescue>

Von CD oder so booten ist etwas schwierig, hänge über mehrere SSH-Tunnel an der RMM-Karte vom Server.

Jemand eine Idee, wie ich die Kiste wieder gebootet bekomme?

Gruss, mistersixt.

[mistersixt]

Habe es mit keinerlei Tricks geschaft, den Server innerhalb vom grub-rescue zu booten, ich hab es aber zum Glück geschafft, den Server von einem Debian-CD-ISO Image via RMM-Karte zu booten und habe dann den grub im Rescue-Modus neu geschrieben, Server bootet jetzt ganz normal... puuh, erstmal 2 Bier auf diesen Schreck . Warum es den grub beim dist-upgrade zerschossen hat... keine Ahnung, gab keinerlei Warnungen oder Fehler beim Upgrade.

Gruss, mistersixt.

[rendegast]

Warum es den grub beim dist-upgrade zerschossen hat...

wurde wohl einfach kein grub-install durchgeführt.

Eine Analysemethode wäre schön,
ob der grub-"kernel" (also das Binäre was nach dem MBR kommt,
inklusive dessen Einstellungen wie zBsp. Zielpartition)
auch zum Userland im beabsichtigten /boot/grub/ paßt.

[mistersixt]

Eine Analysemethode wäre schön,

Warum wird eigentlich per Default ein dist-upgrade nicht mitprotokolliert? Bei allen "apt-get install..." und "apt-get [dist-]upgrade..." Befehlen sollte man doch eigentilch den Output irgendwo nach /var/log/ schreiben. Bin gerade erstaunt, dass das apt-get/dpkg/Debian offensichtlich nicht tut.

Merken: das nächste Mal mit screen alles aufzeichnen für eine mögliche, spätere Fehleranalyse.

Gruss, mistersixt.

[smutbert]

Wird das denn weder in /var/log/apt/… noch in /var/log/dpkg… protokolliert?

[…]
Eine Analysemethode wäre schön,
ob[…]

In debconf müsste doch irgendwo stehen ob grub den im MBR (und/oder sonstwo "eingebetteten", also alles was noch in keinem Dateisystem steht) Code durch eine Neuinstallation von grub aktualisiert.
Ich weiß nicht ob das daran liegt, dass ich gewohnheitsmäßig die debconf-Nachfragepriorität auf "low" eingestellt habe, aber grub-pc hat bei mir bei der Installation nachgefragt auf welchen MBRs und PBRs (da kann man auch keinen oder mehrere wählen) grub installiert werden soll und afaik wird grub an den gewählten Stellen auch beim Upgrade automatisch aktualisiert.

Auf meinem System kann ich nichts davon überprüfen, weil bei grub-efi alles Teil des Dateisystems ist und man daher keine derartige Nachfrage benötigt, aber bei grub-pc würde ich mir einmal ansehen ob man anhand der Ausgabe von

Code: Alles auswählen

debconf-show grub-pc

etwas erkennen kann.

[mistersixt]

Oooh, es wird doch was in /var/log/apt/ mitprotokolliert, immerhin, hier alles zum grub während des dist-upgrades:

Code: Alles auswählen

Preparing to unpack .../grub-pc_2.02~beta2-22_amd64.deb ...
Unpacking grub-pc (2.02~beta2-22) over (1.99-27+deb7u2) ...
Preparing to unpack .../grub-pc-bin_2.02~beta2-22_amd64.deb ...
Unpacking grub-pc-bin (2.02~beta2-22) over (1.99-27+deb7u2) ...
Preparing to unpack .../grub2-common_2.02~beta2-22_amd64.deb ...
Unpacking grub2-common (2.02~beta2-22) over (1.99-27+deb7u2) ...
Preparing to unpack .../grub-common_2.02~beta2-22_amd64.deb ...
Unpacking grub-common (2.02~beta2-22) over (1.99-27+deb7u2) ...
/etc/kernel/postinst.d/zz-update-grub:
GRUB >= 2.00 has been unpacked but not yet configured.
grub-mkconfig will not work until the upgrade is complete.
It should run later as part of configuring the new GRUB packages.
Setting up grub-common (2.02~beta2-22) ...
Installing new version of config file /etc/bash_completion.d/grub ...
Installing new version of config file /etc/grub.d/00_header ...
Installing new version of config file /etc/grub.d/05_debian_theme ...
Installing new version of config file /etc/grub.d/10_linux ...
Installing new version of config file /etc/grub.d/20_linux_xen ...
Installing new version of config file /etc/grub.d/30_os-prober ...
Installing new version of config file /etc/grub.d/41_custom ...
Setting up grub2-common (2.02~beta2-22) ...
Setting up grub-pc-bin (2.02~beta2-22) ...
Setting up grub-pc (2.02~beta2-22) ...
Installing new version of config file /etc/kernel/postinst.d/zz-update-grub ...
Installing new version of config file /etc/kernel/postrm.d/zz-update-grub ...
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
done

Und die Ausgabe vom debconf-show sieht so aus (mit 8.2, nachdem ich den grub mittels rescue-Image repariert habe):

Code: Alles auswählen

  grub-pc/chainload_from_menu.lst: true
  grub-pc/hidden_timeout: false
* grub2/linux_cmdline:
  grub2/device_map_regenerated:
  grub-pc/install_devices_failed: false
  grub-pc/install_devices_failed_upgrade: true
  grub2/force_efi_extra_removable: false
* grub-pc/install_devices: /dev/disk/by-id/scsi-3600605b004a64d1017f82cad10fb5ca0
* grub2/linux_cmdline_default: quiet intel_idle.max_cstate=0 processor.max_cstate=0
  grub-pc/disk_description:
  grub2/kfreebsd_cmdline:
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/timeout: 5
  grub-pc/partition_description:
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_disks_changed:
  grub-pc/install_devices_empty: false
  grub-pc/kopt_extracted: false

Gibt es ein Eagle-Eye, das was sieht? Ich irgendwie nicht ...

[smutbert]

Vermutlich ist das die Einstellung

Code: Alles auswählen

* grub-pc/install_devices: /dev/disk/by-id/scsi-3600605b004a64d1017f82cad10fb5ca0

die ich meine. grub hätte imho also im MBR der Festplatte aktualisiert werden sollen, auf die dieser symbolische Link zeigt.

Hättest du grub zusätzlich manuell, etwa mit »grub-install /dev/sdx« woanders installiert und immer von dort gebootet, hilft es aber nichts, dass „dieser andere grub-Kernel“ aktualisiert wurde.

Oder vielleicht hat sich mit einem neuen Kernel der symbolische Link geändert oder so etwas (existiert »/dev/disk/by-id/scsi-3600605b004a64d1017f82cad10fb5ca0«?) und daher ist das Update gescheitert. Mit

Code: Alles auswählen

# dpkg-reconfigure -p low grub

kommt die Abfrage nach den Geräten auf die der grub-Kernel geschrieben werden soll noch einmal und du könntest da den bzw. die gewünschten MBRs und PBRs auswählen.



Da kenne ich mich aber überhaupt nicht mehr aus…

Code: Alles auswählen

grub-pc/install_devices_failed: false
grub-pc/install_devices_failed_upgrade: true

…weil die zweite Zeile danach klingt als wäre das Update von grub gescheitert, aber andererseits habe ich diese Zeile mit Google bei anderen Leuten ohne Probleme genauso gefunden, genauso allerdings Fälle bei denen ein Grub-Update wegen geänderter Gerätedateinamen (vor allem im Zusammenhang mit lvm2) gescheitert ist
(also vielleicht ist das ein Indiz dafür, dass das Update wegen eines neueren Kernels gescheitert ist)

[mistersixt]

Ok, danke für die Info und die Analyse. Ich habe noch einen identischen Server mit identischer Installation im gleichen Serverschrank, den ich am kommenden Wochenende von Wheezy auf Jessie upgraden will, dann schreibe ich explizit den Grub nochmal in alle vorhandenen MBRs und PBRs bevor ich ihn das erste Mal neu boote. Werde berichten .

Gruss, mistersixt.

[rendegast]

Ich dachte bei Analyse eher an den grub-Stage-Code ab Sektor 1.

Ich erkenne da zuerst mal eine ~ Kopie des core.img, ~ 30kB.
Die geringen Abweichungen könnten wohl Zeitcodes oder Einstellungen darstellen.
Danach (bei mir) nochmal ~30kB weiterer Binärmüll, was wohl Kopien verwendeter grub-Module beinhaltet.
Wann das endet ist für mich nicht ersichtlich, grub-install füllt da wohl nicht bis zur Partition mit Nullen auf.
Wie könnte daraus zumindest mal die Sprungadresse zum /boot/grub/ gelesen werden?
Wie ein Dekompilieren?

Checksumme zur Kontrolle hilft nicht, da sich diese (nicht bei jeder Ausführung) ändert.
Sollte imo nur passieren, wenn ich Änderungen in /etc/default/grub oder /etc/grub.d/ vorgebe.





grub-Installation auf verschiedene Platten habe ich jetzt gar nicht "untersucht".

[habakug]

Hallo!

@rendegast

Bei einer GPT gibt es im Sektor #2 hinter den Daten zur Festplatte wie GUID usw. einen Bereich der mit Nullen gefüllt sein *muss*. Das sind 420 Octette für 512-Byte Sektoren und 4004 Octette für 4-KiB Sektoren. Hier ist das nochmal alles aufgemalt [1] [2].

Gruss, habakug

[1] MBR
https://en.wikipedia.org/wiki/GNU_GRUB# ... drives.svg
[2] GPT
https://en.wikipedia.org/wiki/GNU_GRUB# ... drives.svg

[rendegast]

Bei einer GPT gibt es im Sektor ....

Gerade mal in einer jessie-VM durchgespielt.
zusätzliches Image, gpt-Table, mehrere Partitionen.
'grub-install' verweigert sich erstmal.
Nach Umlabeln einer Partition zur BIOS (gpt-Typ 4) wird das binäre grub-Gelumpe am Anfang dieser Partition angelegt.

Nun aber,
das was sda(dos) ab Sektor1 liegt unterscheidet sich doch stark/stärker von dem am Anfang von sdb1(gpt, BIOS),
zBsp. sda-Code Länge 0xc800, sdb1-Code Länge 0xd000.

(Fehlt noch ein Vergleich einer weiteren "Platte" im dos-Format)

[mistersixt]

For the records: die Server haben je 2 Devices, /dev/sda und /dev/sdb (hängt jeweils ein RAID-10 dran), und der erste Server bootete mit grosser Wahrscheinlickkeit laut BIOS-Eintrag von /dev/sdb, aber der grub wurde beim dist-upgrade von 7 auf 8 nur in /dev/sda aktualisiert. Daher alter Grub mit neuen Grub-Modulen --> Feierabend.

Beim zweiten Server habe ich vor dem Reboot explizit nochmal den Grub auf beide Devices geschrieben, und er kam danach wie erwartet ohne Probleme nach dem dist-upgrade wieder.

Gruss, mistersixt.