Re: Softraid - grundsätzliche Frage
Am Sonntag, 22. Juli 2012 schrieb Andre Tann:
> Moin beisammen,
Tach,
> jetzt hab ich mal wieder eine Testreihe durchgeführt. Hier die
> Erkenntnisse, die ich gewonnen habe:
>
> Martin Steigerwald, Freitag, 20. Juli 2012:
> > > drinhängt, egal ob als sdb oder als sda.
> >
> > Ich hätte gerne mal fdisk -l für sda und sdb und cat /proc/mdstat.
> >
> > Kann nicht sagen, ob es was bringt, aber ich möchte jetzt wirklich
> > erst nochmal genau Dein Setup sehen.
>
> Kriegst Du - hier die Partitionierung [¹], hier das Raid [²]. Und wenn
> wir schon dabei sind - hier df -hT [³].
Okay, das entspricht dem, was ich nach meinen Hinweisen jetzt auch
erwartet hätte.
> > Naja, hab ich doch gezeigt. Das core.img liegt als Datei in
> > /boot/grub und dessen Inhalt muss halt irgendwo hinter dem MBR
> > wieder auftauchen. Ich hab hier nur halt einen Teil überprüft.
> >
> > Es könnte auch weiter hinten noch kaputt sein. Mit dem Wissen, wo es
> > genau anfängt und wie lange es ist, ließe es sich mit dd in eine
> > Datei speichern und diese dann mit /boot/grub/core.img vergleichen.
>
> Sorry, das hatte ich nicht genau genug gelesen. Aber jetzt habe ich das
> nochmal überprüft (jetzt kenne ich dd, xxd, diff und cmp genau ;) )
>
>
> Im Einzelnen:
>
> - Direkt nach einer Installation einer Minimal-Squeeze liegt core.img
> auf sda, beginnend mit dem 513. Byte, insgesamt 27270 Bytes lang.
> Auf sdb liegt core.img nicht, die Bytes 513-27782 stimmen nicht mit
> core.img überein, und zwar schon nach dem 2. Byte.
>
> - ein dpkg-reconfigure grub-pc führt dazu, daß die Bytes 513-27782 von
> sda und sdb übereinstimmen, und diese stimmen wiederum mit der
> core.img überein.
Okay, das ist zu erwarten.
> - anders als in einem früheren Beitrag geschrieben stimmen aber sowohl
> direkt nach einer Neuinstallation, als auch nach einem anschließenden
> dpkg-reconfigure grub-pc die ersten 440 Bytes von sda und sdb nicht
> überein. Der Abschnitt für den Bootloader differiert also.
Das muss jetzt nicht sonderlich viel heißen. Es kann sein, dass irgendein
Teil vom MBR platten-spezifisch ist… So tief bin ich da jetzt auch nicht
drin.
> Daraufhin habe ich gemacht
>
> dd if=/dev/sda of=/dev/sdb bs=512 count=1
>
> Ergebnis:
>
> # cmp /dev/sda /dev/sdb
> /dev/sda /dev/sdb differieren: Byte 33281, Zeile 98.
Und den Unterschied hättest Du damit dann plattgemacht.
> Also sind Bootloader, Partitionstabelle, core.img und noch weitere
> 5499 Bytes nunmehr identisch.
>
> Trotzdem bootet die Kiste nicht von der urspr. sdb, der Effekt ist
> wie immer: ununterbrochene Neustarts. Hänge ich stattdessen die urspr.
> sda wieder rein (egal an welchen Port, also so wie ursprünglich
> installiert, oder vertauscht), dann startet Kiste und RAID ganz
> normal.
Tja, dann weiß ich auch nicht weiter.
Keine Ahnung, was da los ist.
> Festzuhalten ist also: Der Bootloader-Abschnitt im MBR auf beiden
> Platten unterscheidet sich vor und auch nach einem dpkg-reconfigure
> grub-pc, und übrigens auch nach einem grub-install /dev/sda bzw. sdb.
> Das core.img aber kann auf diese Weise auf sdb untergebracht werden.
> Auf sda ab Byte 513 landet das core.img dagegen nach der Installation
> von selbst.
>
> Der Grund, warum die Kiste nicht starten will, muß also irgendwo weiter
> hinten ab Byte 33281 liegen. Da wiederum kenne ich mich nicht genau
> genug aus, keine Ahnung, was dort abgelegt ist.
Der Grund könnte auch aus irgendeinem Grund an GRUB selbst liegen.
Eine Idee noch:
Enthält das „core.img“ denn das raid-Modul?
Ich denke mal, das dürfte
martin@merkaba:~> ls -l /boot/grub/raid.mod
-rw-r--r-- 1 root root 6548 Jul 14 14:01 /boot/grub/raid.mod
sein
Das müsste ja auch drin sein, da es von beiden Platten ja geht:
martin@merkaba:~> ls -l /boot/grub/lvm.mod
-rw-r--r-- 1 root root 7216 Jul 14 14:01 /boot/grub/lvm.mod
Kleiner (unschöner Test):
martin@merkaba:~> ls -l /boot/grub/core.img
-rw-r--r-- 1 root root 25975 Jul 14 14:01 /boot/grub/core.img
martin@merkaba:~> ls -l /boot/grub/kernel.img
-rw-r--r-- 1 root root 30204 Jul 14 14:01 /boot/grub/kernel.img
martin@merkaba:~> grep "$( cat /boot/grub/btrfs.mod )"
/boot/grub/kernel.img
Übereinstimmungen in Binärdatei /boot/grub/kernel.img.
martin@merkaba:~> grep "$( cat /boot/grub/btrfs.mod )" /boot/grub/core.img
martin@merkaba:~#1>
Ha, und es scheint das „kernel.img“, nicht das „core.img“ zu sein, dass
grub-install zusammenstellt und hinter den MBR schreibt.
Unschön der Test, weil btrfs.mod auch Anführungszeichen enthält und das an
sich dann mit meinem Quoting Ärger geben könnte. Aber möglicherweise
„denkt“ die Shell bei $( ) da mit.
Hmmm, das stimmt aber nicht mit der Dokumentation überein:
`kernel.img'
This image contains GRUB's basic run-time facilities: frameworks
for device and file handling, environment variables, the rescue
mode command-line parser, and so on. It is rarely used directly,
but is built into all core images.
`core.img'
This is the core image of GRUB. It is built dynamically from the
kernel image and an arbitrary list of modules by the `grub-mkimage'
program. Usually, it contains enough modules to access
`/boot/grub', and loads everything else (including menu handling,
the ability to load target operating systems, and so on) from the
file system at run-time. The modular design allows the core image
to be kept small, since the areas of disk where it must be
installed are often as small as 32KB.
*Note BIOS installation::, for details on where the core image can
be installed on PC systems.
(aus der Info-Datei unter „Images“)
Jetzt raff ich grad gar nix mehr, denn hier scheint es sich genau umgekehrt
zu verhalten.
Es sei denn mein grep-Test haut wegen dem Quoting daneben und GRUB
komprimiert die Module, die es in core.img reinklatscht irgendwie, so dass
GRUB die dann zur Laufzeit wieder dekromprimiert.
Wenn jemand einen guten Vorschlag hat, um in einer Datei nach dem binären
Inhalt einer anderen Datei zu greppen, nur zu. Mir fällt da grad nix
sinnvolles ein.
Und dann müsste die grub.cfg ja auch:
insmod lvm
insmod raid
insmod part_msdos
und das Dateisystem für /boot enthalten, aber ich glaube, das hatten wir
schon.
Ich empfehle Dir so langsam, das bei den GRUB2-Entwicklern einzukippen
oder als Debian-Bugreport auf grub-pc, denn wir raten hier nun schon auf
ziemlich tiefen Ebenen rum und könnten gut auch weit daneben liegen ;)
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: