[SOLVED]Jessie: Grub2 in Image installieren (Loop device)

[DiscoBoy]

Hallo, ich hatte in diesem Thread (http://debianforum.de/forum/viewtopic.php?f=12&t=147217) mein Problem gelöst, Grub in ein Image zu schreiben, dass ich als loop device gemountet hatte. Mit Wheezy hat am Ende alles geklappt - leider nicht mehr mit Debian Jessie. Dort ist grub in der Version (grub-2.00-22), und nach 2 Tagen erfolglosem Herumprobieren hoffe ich hier auf Hilfe

Das Problem ist, dass Grub nun immer sofort in die Rescue Konsole bootet mit dem Hinweis:

Code: Alles auswählen

[b]error: no such device: UUID[/b]

Ein "ls" in der Rescue Konsole zeigt mir auch nur (hd0) und kein (hd0,1) was in meinem Image /dev/sda1 wäre. Ich habe die grub.cfg schon eingehändig erstellt, genauso wie device.map um sicherzugehen, dass dort entweder beim Boot alles ganze neutral auf

Code: Alles auswählen

(hd0)   /dev/sda
(hd0,1) /dev/sda1

zeigt, oder aber auch spezifisch auf:

Code: Alles auswählen

(hd0)   /dev/sda
(hd0,1) /dev/disk/by-uuid/f3f012a0-5f53-4914-9597-629ddeadb54d

Grub installiert in das richtige boot folder, nur grub-probe spinnt im Gegensatz zu Wheezy öfters wegen dem zweiten Eintrag in der device.map. Deswegen habe ich (installiere ja in einem gechrooteteten loopdevice) schon vor grub-install & update-grub auf diesen Eintrag gesetzt.

Code: Alles auswählen

(hostdisk//dev/$loopdev)	hostdisk//dev/$loopdev
(hostdisk//dev/$freeloop)	hostdisk//dev/$freeloop

Leider immer das gleiche. Grub startet mit der UUID Fehlermeldung und findet das Device nicht....

[maledora4]

Dann tue ihm doch den Gefallen in seiner grub.cfg

Code: Alles auswählen

..
set ruuid="f3f012a0-5f53-4914-9597-629ddeadb54d"
search --no-floppy --fs-uuid $ruuid --set=root
...

[smutbert]

Wenn Grub im Rescuemodus landet kommt er ja gar nicht bis zum Einlesen der Konfigurationsdatei, sondern scheitert schon daran das Dateisystem mit dem grub-Ordner (normalerweise /boot/grub) zu finden, in dem sich eben jene Konfigurationsdatei, die Grub-Module und noch einiges mehr befinden.

Hier scheint grub ja schon am erkennen der Partition(en) zu scheitern. Es gibt relativ viele Partitionierungsschemata, die grub unterstützt: msdos (mbr), gpt, amiga, apple, sun, bsd, sunpc,…
Wenn ich das richtig in Erinnerung habe geht's hier um grub-pc, da können wohl aus Platzgründen nicht beliebig viele Module direkt in die ersten beiden stages eingebaut werden.

Wenn also zB part_msdos fehlt, kann grub auch nicht auf das Dateisystem zugreifen um fehlende Module nachzuladen. Ich habe keine Idee wie man überprüfen könnte, ob es wirklich daran liegt, aber es wäre vielleicht einen Versuch wert grub-install mit --modules=… die notwendigen Module für Partitionierung und Dateisystem mitzugeben. (nur so eine Idee, ich war bereits im vorigen Thread nicht so besonders hilfreich)

[DiscoBoy]

Schon mal vielen Dank für eure Antworten! Grub nervt mich echt ganz schön, aber ich hoffe andere finden meine Tortur später hilfreich (Vor allem der Tipp mit dem 2x einhängen des loop devices um Grub zur Installation zu überreden war Gold wert).

Zu Antwort 1:

Habe dies explizit in der grub.cfg angegeben. Überall steht jetzt eigentlich die richtige UUID drin, aber es kommt der gleiche Fehler.

Zu Antwort 2:

Ich glaube auch, dass Grub überhaupt nicht einmal die Partitionen erkennt (Außer, dass es hd0 gibt). Das würde dann darauf hinweisen, dass grub seine Module nicht findet.
Den Unterschied den ich zwischen Grub 1.99 (wheezy) und Grub 2.00 (jessie) finde, ist der, dass das grub directory neu organisiert ist: In Jessie gibt es jetzt Unterordner (siehe Vergleich).

wheezy

Code: Alles auswählen

root@debian-7:~# ls -la /root/wheezy/boot/grub/
total 1808
drwxr-xr-x 3 root root  12288 May  9 19:56 .
drwxr-xr-x 3 root root   4096 May  9 19:56 ..
-rw-r--r-- 1 root root   7368 May  9 19:56 915resolution.mod
-rw-r--r-- 1 root root  10412 May  9 19:56 acpi.mod
-rw-r--r-- 1 root root   1844 May  9 19:56 adler32.mod
-rw-r--r-- 1 root root   4644 May  9 19:56 affs.mod
-rw-r--r-- 1 root root   5092 May  9 19:56 afs_be.mod
... usw.

jessie

Code: Alles auswählen

root@debian-7:~# ls -la /root/jessie/boot/grub/
total 40
drwxr-xr-x 5 root root  4096 May 13 14:44 .
drwxr-xr-x 3 root root  4096 May 13 14:44 ..
-rw-r--r-- 1 root root    80 May 13 14:44 device.map
drwxr-xr-x 2 root root  4096 May 13 14:44 fonts
-r--r--r-- 1 root root  2551 May 14 09:18 grub.cfg
-rw-r--r-- 1 root root  1024 May 13 14:44 grubenv
drwxr-xr-x 2 root root 12288 May 13 14:44 i386-pc
drwxr-xr-x 2 root root  4096 May 13 14:44 locale

Bei jessie liegen die modules nun also in dem Folder i386-pc - keine Ahnung warum das so ist!?
Ein Verschieben der Module in den grub Ordner selbst hat nichts bewirkt.
An der Partitionierung meines Images hat sich ansonsten nichts geändert:

Code: Alles auswählen

Size: 2149580800 bytes, 2149 MB
Heads: 255   Sectors per Track: 63   Cylinders: 261

Name                           Flags       Part Type          FS Type         [Label]      Size (MB)
 ----------------------------------------------------------------------------------------------------------------------------------------------
                                           Pri/Log            Free Space                   1.05
location_jessie_20140513.img1  Boot        Primary            ext4            [rootfs]     1572.87
location_jessie_20140513.img2              Primary            swap            [swapfs]     575.67

Grub wird anscheinend in das richtige Loop device installiert, aber dann findet es beim Start seine Dateien nicht...
Was passiert eigentlich wenn Grub in den MBR geschrieben wird? Werden hier irgendwelche Pfade fix gesetzt und was steht in der Datei grubenv?

[DiscoBoy]

Noch ein Nachtrag: Unter boot/grub/i386-pc gibt es die Datei load.cfg
mit folgendem Inhalt:

Code: Alles auswählen

search.fs_uuid f3f012a0-5f53-4914-9597-629ddeadb54d root  
set prefix=($root)/boot/grub

Allerdings wirken sich Änderungen an dieser Datei nicht auf den Boot-Vorgang aus.
Ein hinzugefügtes Echo command wurde nicht ausgeführt, genauso wie die Änderung in:

Code: Alles auswählen

search.fs_label rootfs root  
set prefix=($root)/boot/grub

Die grub error console spuckt mir bei Befehlen wie:

Code: Alles auswählen

grub_rescue> insmod echo

error: Unknown file system

aus

[smutbert]

Wie gesagt, er findet nicht einmal die Partition, geschweige denn das Dateisystem oder irgendwelche Konfigurationsdateien oder Module darauf, also auch keine load.cfg, die wahrscheinlich eh nur dem Erstellen des Grub-Images dient (dem Inhalt nach hätte ich vermutet, dass das die Konfigurationsdatei ist, die im Grub-Image eingebettet wird und grub eben dem Auffinden des grub-Verzeichnisses dienen soll - wenn sich also Änderungen an der Datei auswirken sollen, wirst du grub neu installieren müssen, wobei ich nicht sicher bin, ob dabei nicht eine load.cfg erstellt wird).
Dass die Module in nach der Archtektur benannten Unterverzeichnissen liegen ist insofern sinnvoll, weil sich mit dem neuen Layout wohl auch recht einfach auf mehreren Architekturen bootfähige USB-Sticks oder dergleichen mit grub erstellen lassen - vorher war das etwas schwieriger. Aber da darf das Problem nicht liegen.


Inzwischen glaube ich, dass bei dir das Problem aber sogar noch etwas früher auftritt. Es gibt ein Skript, dass alle Festplatten/Datenträger analysiert und recht genau anzeigt, was die Bootloader tun bzw. zu tun versuchen, vielleicht bringt das neue Erkenntnisse?
http://bootinfoscript.sourceforge.net/
(den Teil des Ergebnisses für die CF-Karte - um so eine ging es doch? - könntest du nach nopaste hochladen. Dort sollte dann auch die eingebette Konfiguration drin stehen (und mit der load.cfg übereinstimmen))

Generell hatte grub desöfteren Probleme, wenn er nicht in dem MBR installiert wurde - einfach weil den stages ohne MBR weniger (zu wenig) Platz zur Verfügung steht. Das wäre also auch einen Versuch wert. Das mit den manuell angegebenen Modulen für das Partitionsschema hast du auch noch nicht ausprobiert?

grubenv soll afaik nur diverse Umgebungsvariablen über einen Neustart hinaus speichern, also zB welcher Menüeintrag zuletzt gewählt wurde, damit dieser beim nächsten Systemstart automatisch wieder ausgewählt werden kann. Scheitert grub an der grubenv gibt es zwar eine Fehlermeldung aber sonst funktioniert meiner Erfahrung nach trotzdem der Rest ganz normal.

[DiscoBoy]

Bin gerade dabei, die Module zu übergeben! Mit dem bootinfosript ergibt sich folgender Unterschied zwischen wheezy und jessie:

jessie!
=> Grub2 (v1.99) is installed in the MBR of /dev/sdb and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
in partition 98 for .

wheezy!
=> Grub2 (v1.99) is installed in the MBR of /dev/sdc and looks at sector 1 of
the same hard drive for core.img. core.img is at this location and looks
for (,1)/boot/grub on this drive.

Mittlerweile habe ich grub etwas besser verstanden: grub-install ruft also grub-mkimage auf, das mittels der load.cfg und anderen Einstellungen ein grub image erstellet. Damit ist mir klar welchen Zweck load.cfg hat.

Ein dump von bootinfoscript:
http://nopaste.info/4f06750c30.html

[smutbert]

Das hier (der UUID nach ist /dev/sdb(1) das Gerät, um das es hier geht)

Code: Alles auswählen

 
=> Grub2 (v1.99) is installed in the MBR of /dev/sdb and looks at sector 1 of
    the same hard drive for core.img. core.img is at this location and looks
    in partition 98 for .

gefällt mir nicht.

• Erstens hast du grub doch gar nicht in den MBR installiert (oder hab' ich dich falsch verstanden). Das könnte dann ein Überbleibsel von einer alten Installation sein (wofür auch mein zweitens spräche).
  Wenn du grub in einen PBR (partition boot record) installieren willst, wirst du auch einen Microsoft-ähnlichen MBR schreiben müssen, der den Bootloader zB aus dem PBR der aktiven (als bootfähig markierten) primären Partition lädt — siehe mbr
• Zweitens scheint die eingebettete Konfiguration (oder gleich der ganze zweite Teil von grub) defekt oder überschrieben worden zu sein. Denn Partition 98 . ist bestimmt nichts, womit ein Bootloader etwas Sinnvolles anfangen kann.
  Das sind womögliche Bruchstücke von der neuen in den PBR installierten Grub-Version, die damit den zweiten Teil des vorigen Grub (der dann im MBR installiert gewesen sein muss, wie es üblich ist) überschrieben hat.

Soweit mein Erklärungsversuch…

[DiscoBoy]

Die manuell hinzugefügte Module waren die Lösung. Jetzt startet Grub und das Menu erscheint! Vielen Dank!

Zu deinen Anmerkungen: Ich finde den Eintrag .98 auch sehr komisch. Es kann aber nicht von einer älteren Version stammen, da dies ein eben neu angefertigtes Image ist!

Meine Vorgehensweise:

1. Ich erstelle mir mit dd ein *.img
2. Ich erstelle darauf 2 Partitionen
3. Ich binde das *.img mit kpartx als loopdevice ein (-> loop0 und mapper/loop0p1,loop0p2)
4. ch binde mapper/loop0p1 (=Partition1) nochmals als loop1 ein
5. Ich mounte loop1, chroote dorthin, installiere mit debootstrap ein Debian und Packete
6. Ich installiere grub nun in loop0

[smutbert]

ich hasse es, wenn etwas funktioniert und ich weiß nicht wieso aber trotzdem gut, dass es das tut.

[DiscoBoy]

Vielen Dank dir für den richtigen Hinweis. Inzwischen glaube ich grub besser zu verstehen und ich werde in Zukunft einfach ein bisschen mehr bei der grub image erzeugung rumspielen bis es klappt!

[habakug]

Hallo!

Zum Vorgehen noch eine Ergänzung. Es geht auch so:

Code: Alles auswählen

# losetup -P /dev/loop2 dd.img
# mount /dev/loop2p1 /mnt/img

Gruss, habakug