Geloest: Grub2 im Rescue Mode und $root ist leer

[maddeb]

Hallo,

ich frage mal hier, damit ich heute noch dazu komme, was zu essen.

Ich versuche seit gefuehlten 10h ein Squeeze/Xen4 mit Grub2 zu starten.
Im Livesystem (GRML) im Changeroot kann ich nichts Komisches entdecken. Aber wenn ich booten will, kommt folgendes:

Code: Alles auswählen

GRUB loading.
Welcome to GRUB!

error: file not found.
Entering rescue mode...
grub rescue>

Ich habe 5 Kommandos zur Verfuegung an dieser Stelle. Drei davon sind unset, insmod, und eines, das ich vergessen habe und nicht wieder finde. Die andern beiden:

Code: Alles auswählen

grub rescue> set
prefix=(hd0,msdos1)/grub
root=hd0,msdos1
grub rescue> ls
(hd0) (hd0,msdos1) (hd0,msdos2)
grub rescue> ls /

grub rescue>

Durch gezieltes Testen konnte ich sehen, dass $root stimmt, denn wenn ich es mit der anderen Partition versuche, bekomme ich "unknown filesystem.". Aber in diesem erkannten Dateisystem werden keine Dateien angezeigt. Sie sind aber da, wie man im Livesystem sehen kann.
Die Partitionen entprechen sda1 (/boot) und sda2 (LVM im LUKS). Das hat bei anderen Systemen immer gut funktioniert.
Auf jeden Fall ist es etwas mit dem Bootloader selbst, auf die einzelnen Eintraege brauchen wir hier gar nicht zu achten.

Ich glaub zwar, das update-grub nur grub.cfg erzeugt, bin mir da aber nicht sicher. Deshalb hier die /etc/default/grub:

Code: Alles auswählen

GRUB_DEFAULT=0
GRUB_TIMEOUT=3
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
GRUB_TERMINAL=console

Der Inhalt unter /etc/grub.d/ ist unveraendert, die fertige grub.cfg ist hier: http://nopaste.debianforum.de/36122

Was kann ich noch fuer sinnvolle Informationen liefern?
Bei der ersten Installation von Grub schlug die Installation in den MBR fehl. Auf der Shell grub-install dagegen lieferte "No errors reported.".
Ich habe spaeter Grub gepurged, die damals noch unnoetigerweise mitlaufende zweite HDD abgeschaltet (d.h. es gibt nur noch eine Platte im System) und Grub neu installiert, dieses Mal ebenfalls mit "No errors reported.". Am Problem hat sich nichts geaendert.

Einige Quellen vermuten, dass bei der Erstellung vom core.img das Modul fuer ext2 fehlt. Aber die Ausgabe von "ls /" ist leer. Bei root=('hd0,msdos2) passiert aber folgendes:

Code: Alles auswählen

grub rescue> ls /
error: unknown filesystem.
grub rescue>

Schlussinfo: das System ist wie folgt entstanden:

• * Booten mit LiveCD (GRML)
  * sshfs 192.168.1.2:/ /mnt
  * mount /dev/xen1vg0/root0 /mnt/mnt sowie alle noetigen mounts fuer
  * chroot /mnt /bin/bash
  * debootstrap squeeze /mnt (debootstrap auf der CD war wohl zerkratzt)
  * chroot verlassen, umount
  * chroot-Prozedur fuer das neue System, Pakete installiert, darunter Xen und Grub

Kann bei dieser Prozudur ein Schritt vergessen worden sein, der irgendeinen Einfluss hat?
fstab und crypttab waren leer oder gar nicht da, und erste Versuche von update-initramfs beschwerten sich darueber, mtab nicht lesen zu koennen, weil die auch fehlte. Die habe ich aus dem mount-Kommando gepiped, und alles entfernt, was nicht von innerhalb der Chroot-Umgebung stammte - kann da etwas schief gegangen sein?

Vielen Dank schonmal und gute Restnacht

[r900]

die fertige grub.cfg ist hier: http://nopaste.debianforum.de/36122

Verglichen mit meiner grub.cfg fehlt vor Zeile 38 (### END /etc/grub.d/00_header ###)

Code: Alles auswählen

insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set 6af999ac-067b-4938-810f-5ca2e406712b

In der letzten Zeile musst du die UUID durch deine eigene ersetzen Die kannst du z.B. mit 'blkid /dev/sda1' herausfinden.

Was steht in "/boot/grub/device.map"?

Kannst du evtl. Super Grub2 Disk benutzen um das System zu starten? Und dann von dort nochmal 'update-grub' und 'grub-install /dev/sda' ausführen.

Übrigens, das Kommando "help" in grub sollte weitere Auskunft über mögliche Befehle geben können.

[maddeb]

Hallo r900,

danke fuer den Hinweis mit der grub.cfg; ich hab sie nochmal neu erzeugt, mit dem selben Ergebnis.
Entscheidend ist jedoch, dass die Datei gar nicht erst zur Bootzeit gelesen werden kann.
Ich habe jetzt auch mal testweise den alten Grub installiert, und bekomme einen Fehler in Stage1.5 - IMHO total analog zu Grub2.

Übrigens, das Kommando "help" in grub sollte weitere Auskunft über mögliche Befehle geben können.

Jein. Ich habe wirklich nur 5 Kommandos, help ist nicht darunter. Die kommen hinzu, wenn man die richtigen Module per insmod laedt, fuer die es ihrerseits einen Abhaengigkeitsbaum gibt. Nach meiner Kenntnis haengt das Modul "help" von "normal" ab. Fuer eine praktische Veranschaulichung guckst du hier:
http://dione.no-ip.org/AlexisWiki/Debia ... d1AndGrub2
Seine Situation ist etwas anders, ich hab hier kein RAID, und kein "no such disk".
Ich habe jetzt auch versucht, grub-install mit den Modulen part_msdos und ext2 zu starten, gleiches Ergebnis. Jedes weitere sinnvolle Modul macht ihn zu grosz fuer den MBR.
SuperGrub probiere ich morgen mal aus, danke auch fuer diesen Hinweis. Ich bin dem zwar schon vorher begegnet, dachte aber immer, das waere nur ein LiveSystem, mit dem man Grub besonders einfach fixen koenne.

[r900]

Hmm.. also von Xen hab ich gar keine Ahnung, so viel schonmal vorneweg. Kannst du vielleicht ein bisschen näher erklären warum die Installation so abenteuerlich war mit sshfs und booten von grml?

Stell doch mal die fstab hier rein und den Inhalt von /boot/grub/device.map. Bist du eigentlich sicher dass die Partitionstabelle msdos ist? Stimmen die IDs der Partitionen (83 für Linux etc.)? Keine doppelt vorhandenen UUIDs?

Die Partitionen entprechen sda1 (/boot) und sda2 (LVM im LUKS).

Und mal ganz blöd gefragt, liegen die grub-Dateien vielleicht noch im root-Dateisystem im LVM? Als du die Installation des Systems beschrieben hast, erwähnst du nämlich nichts von separater boot-Partition. Oder war die gemountet als du das debootstrap gemacht hast? (wie gesagt ich steige bei deiner Beschreibung der Installation noch nicht so ganz durch)

[r900]

Ich habe jetzt auch mal testweise den alten Grub installiert, und bekomme einen Fehler in Stage1.5 - IMHO total analog zu Grub2.

Das könnte mit deiner device.map zusammenhängen. grub2 benutzt nämlich z.B. so etwas

Code: Alles auswählen

(hd0)	/dev/disk/by-id/ata-SAMSUNG_HD322HJ_S17AJ90S323175

und grub-legacy hätte lieber

Code: Alles auswählen

(hd0)	/dev/sda

Noch was anderes. Wenn du grub auf einer separaten boot-Partition hast befinden sich die Dateien unter (hd0,1)/grub/, normalerweise aber unter (hd0,1)/boot/grub/. Erkennt er das eventuell nicht richtig? Setzt doch mal im root deiner boot-Partition einen symlink

Code: Alles auswählen

ln -sd . boot

Wie groß ist dein core.img und wo fängt die erste Partition an?

[maddeb]

Kannst du vielleicht ein bisschen näher erklären warum die Installation so abenteuerlich war mit sshfs und booten von grml?

Zuerst war die Platte eine Bitkopie eines anderen Rechners. Ich hatte aber nicht bedacht, dass es ein 64Bit-System ist, das auf einem Pentium3 nur schwer bootet :-/
Wollte ich also mit LiveCD booten und chrooten, aber das versucht ja die Shell im chroot zu starten, und die ist ja immer noch 64Bit. Also dachte ich mir, dann eben debootstrap, ist bei GRML ja dabei. Input/Output error. Hexdump von debootstrap ergibt nur Nullen. Also nahm ich an, die CD ist etwas zerkratzt.
Was tun? USB-Stick gerade nicht auffindbar, keine Rohlinge im Haus, meine Debian-CD auch unauffindbar (vielleicht verschenkt), kein Adapter fuer alte PATA-Platten, um meine Laptopplatte zu benutzen. Nach 18Uhr sind die Fachlaeden hier ja schon zu. Aber ein 32Bit-Laptop mit SSH. Und dort im Laufwerk eben auch die GRML - die verlege ich nie.

Stell doch mal die fstab hier rein und den Inhalt von /boot/grub/device.map.

Ich habe, da Grub-legecy auch nicht lief, wieder Grub2 installiert. Dazu passt:

Code: Alles auswählen

(hd0)   /dev/disk/by-id/ata-WDC_WD1600BB-00FTA0_WD-WMAES3834967

Unter grub-legacy sieht das genauso aus. Wenn ich das manuell auf /dev/sda1 aendere, kommt mehrfach

Code: Alles auswählen

Unknown partition table signature

Code: Alles auswählen

proc /proc proc defaults 0 0
/dev/mapper/xen1vg0-root0 / ext4 noatime,errors=remount-ro 0 1
UUID=a7bab12a-f9d7-4d8d-bb36-e9253f655e54 /boot ext4 noatime,auto 0 2
/dev/mapper/xen1vg0-swap none swap sw 0 0

Bist du eigentlich sicher dass die Partitionstabelle msdos ist? Stimmen die IDs der Partitionen (83 für Linux etc.)?

Code: Alles auswählen

Disk /dev/sda: 19457 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1   *      0+     15      16-    128488+  83  Linux
/dev/sda2         16   19456   19441  156159832+  83  Linux
/dev/sda3          0       -       0          0    0  Empty
/dev/sda4          0       -       0          0    0  Empty
total: 156290904 blocks

Ich denke, das ist das DOS-Schema, oder nicht? Mit Partitionsschemata kenne ich mich nicht wirklich aus.
Das beantwortet gleich noch eine andere Frage:

Wie groß ist dein core.img und wo fängt die erste Partition an?

Zur core.img: beim Originalpost war sie noch 23924B und hatte dieselbe MD5 wie die core.img auf meinem Laptop. Mittlerweile (ich vermute, durch die Option --modules="part_msdos ext2") sind es 20B weniger. Jedes weitere sinnvolle Modul, das mir so einfiel, haette die Datei zu viel wachsen lassen.
Zu sda1: ich lasse die Boot-Partition immer ganz vorne Anfangen, wegen der Moeglichkeit von Limitierungen/Bugs im BIOS.

Setzt doch mal im root deiner boot-Partition einen symlink (...)

Habe ich gemacht, aber da wie gesagt kein Inhalt (also auch kein /grub) erkannt wird, bin ich davon ausgegangen, dass auch ein Symlink am selben Ort nicht erkannt wird, und so war es auch.

Und mal ganz blöd gefragt, liegen die grub-Dateien vielleicht noch im root-Dateisystem im LVM? Als du die Installation des Systems beschrieben hast, erwähnst du nämlich nichts von separater boot-Partition. Oder war die gemountet als du das debootstrap gemacht hast?

Ich gebe zu, ich bin nicht immer der Meister der Verstaendlichkeit.
Nun, tatsaechlich war sda1 beim debootstrap nicht gemounted, und auch nicht bei der Installation des Kernels/Xen im chroot, was mir beim Erstellen der fstab auffiel. Ich habe aber alles auf sda1 verschoben danach. Seitdem wurde Grub mehrfach gepurged und neu installiert.

Ich habe es auch jetzt mit Supergrub2 versucht, am Ende mit dem selben Ergebnis. Zuerst hatte ich ein "Unknown filesystem", aber Supergrub setzt root=hd0 ich machte daraus root=hd1. Eine leere Ausgabe ohne Fehler bekam ich durch root=hd1,msdos1; root=hd1,1 liefert das gleiche (auch bei meinem System) - ich habe den Eindruck, die Ausdruecke sind gleichwertig.

Ich mach mir jetzt erstmal eine Kopie von sda1 und guck mir die naeher an.

[r900]

Ich habe es auch jetzt mit Supergrub2 versucht

Der hat doch verschiedene Funktionen, grub2 Installation finden, OS entdecken, Partitionen auflisten etc. Also wenn nichts davon etwas auf der Platte erkennt wäre das schon sehr seltsam. Würde dann für Probleme mit den BIOS-Einstellungen sprechen (siehe weiter unten).

Supergrub setzt root=hd0 ich machte daraus root=hd1

Die Nummerierung im neuen grub ist ein bisschen verwirrend, die Festplatten fangen bei 0 an, die Partitionen aber erst bei 1. Von daher wäre hd0 für die erste Platte schon richtig.

Zuerst war die Platte eine Bitkopie eines anderen Rechners. Ich hatte aber nicht bedacht, dass es ein 64Bit-System ist, das auf einem Pentium3 nur schwer bootet

Vielleicht liegt da dein Problem. Je nachdem wie die Einstellungen im BIOS dieses Rechners sind (LBA, CHS Werte) wird die Platte eventuell anders erkannt als bei der ursprünglichen Partitionierung. Und grub kann ja nur mit dem arbeiten was das BIOS ihm anbietet. Der Linux kernel übernimmt ja erst später.

Ich denke, das ist das DOS-Schema, oder nicht? Mit Partitionsschemata kenne ich mich nicht wirklich aus.

Daraus kann man leider nicht so viel erkennen, hat grml gdisk? Dann poste mal bitte die Ausgabe von 'gdisk -l /dev/sda', da steht etwas mehr.

Ich mach mir jetzt erstmal eine Kopie von sda1 und guck mir die naeher an.

Bei mir schreibt grub das boot.img in den MBR (in die ersten 440 bytes um genauer zu sein) von sda. Das core.img schreibt er dann direkt dahinter, also ab byte 512. Das scheint bei dir nicht so ganz richtig zu funktionieren, sonst hätte er ja mehr als nur diese 5 rudimentären Befehle. Gibt es dhex in grml? Das ist ein hex-editor mit diff-Modus. Dann könntest du nachsehen ob das core.img richtig auf sda geschrieben ist.

Code: Alles auswählen

du -b /boot/grub/core.img
dd if=/dev/sda of=new.bin bs=1 count=<Ausgabe von du -b> skip=512
dhex new.bin /boot/grub/core.img

Bei mir stimmt das überein, bis auf dieses hier:

Code: Alles auswählen

sda:
208     90 3a 00 00 3c 70 00 00  28 55 00 00 00 00 00 00      .:..<p..(U......
218     ff ff ff ff 28 2c 6d 73  64 6f 73 31 29 2f 62 6f      ....(,msdos1)/bo
228     6f 74 2f 67 72 75 62 00  00 00 00 00 00 00 00 00      ot/grub.........

core.img:
208     90 3a 00 00 3c 70 00 00  28 55 00 00 ff ff ff ff      .:..<p..(U......
218     ff ff ff ff 2f 62 6f 6f  74 2f 67 72 75 62 00 00      ..../boot/grub..
228     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00      ................

Nachtrag (zur Vollständigkeit): Ich sehe gerade aus deiner fstab dass deine boot-Partition ext4 ist (vollkommen unnötig übrigens, ext2 oder ext3 reicht dafür vollkommen aus). Das wird von grub-legacy nicht unterstützt. Einer der vielen Gründe weshalb grub von Grund auf neu geschrieben wurde.

[maddeb]

So, dieses Problem waere geloest.
Ich hatte das BIOS so eingestellt, dass die Laufwerke zur Bootzeit erkannt werden. Man muss sie aber - bei diesem BIOS zumindest - fest einstellen, um LBA waehlen zu koennen.
Mit Grub-legacy habe ich jetzt eine Shell, vorher hat ich gar nichts dergleichen.
Und Grub2 funktioniert einfach.

Gut, der Boot kommt nicht allzu weit, der Bildschirm wird dunkel und der Rechner begibt sich in eine Bootschleife.
Aber das ist wahrscheinlich kein Problem mit Grub mehr und damit Off-Topic. Es kommt mir auch nicht so vor, als haette ich das nicht auch schon mal geloest.

Nochmal danke an r900. Ich waer alleine nicht drauf gekommen, die Ursache im BIOS zu suchen und haette eher defekte Hardware vermutet - die Festplatte ist mit ihren 6Jahren die juengste Komponete im System.

[r900]

Freut mich dass mein herumstochern etwas gebracht hat