Probleme mit RAID aus Tar-Image

Z

zeaq

New Member
Hallo zusammen,

ich verzweifel seit Tagen an einem Restore-Szenario.

Ich habe von meinem System ein Tar-Image erstellt und möchte nun in einer VMWare den Restore-Fall nach einem Hardware-Totalausfall simulieren. Die Daten- und Bootmanagerwiederherstellung funtioniert bestens. Allerdings bekomme ich das verwendete mdadm-Raid nicht mehr zum Rennen und sehe beim Booten nur folgende Meldung:

Begin: Mounting root file system... ...
Begin: Running /scruots/local-top ...
Begin: Loading MD modules ...
Success: loaded module raid1.
Done.
Begin: Assembling all MD arrays ...
mdadm: No devices listed in conf file were found.
failure: failed to assemble all arrays.
Done.
Done.
Begin: Waiting for root file system... ...
Click to expand...

Das Problem ist also, dass das Raid nicht zusammen geführt werden kann. Aber mir fallen keine Stellschrauben mehr ein. Ich habe ein neues Raid erstellt, die mdadm.conf angepasst und sicherheitshalber ein neues initramfs geschrieben. Habe ich irgendwo einen Denkfehler? Hier mein detailiertes Vorgehen:

#Booten über aktuelle Systemrescuecd

#Partitionstabelle auf /dev/sda und /dev/sdb erstellen
cfdisk /dev/sda
# sda1 Boot Primäre Linux raid autodetect 57,58
# sda2 Primäre Linux swap / Solaris 1077,52
# sda3 Primäre Linux raid autodetect 248921,65
sfdisk -d /dev/sda | sfdisk /dev/sdb

#Raid-Verbund erstellen / superblock updaten
mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sda1 /dev/sdb1 --metadata=0.90
mdadm --create /dev/md1 --level=mirror --raid-devices=2 /dev/sda3 /dev/sdb3 --metadata=0.90

#Dateisystem erstellen
mkfs.ext3 /dev/md0
mkfs.ext3 /dev/md1
mkswap /dev/sda2
mkswap /dev/sdb2

#Archiv einspielen
mount /dev/md1 /mnt/
mkdir /mnt/boot
mount /dev/md0 /mnt/boot/
cd /mnt
time ncftpget -c -V -u user -p pass 192.168.0.100 archiv.tar.bz2 | tar -xjpf - -C /mnt

#chroot starten:
chroot /mnt /usr/bin/env -i HOME=/root TERM=$TERM PS1='\u:\w\$ ' PATH=/usr/sbin:/usr/bin:/sbin:/bin /bin/bash +h
mount -t proc /proc proc

#Bootloader installieren
grub --no-floppy
root (hd0,0)
setup (hd0)
quit

#neue uuid des Raids ermitteln
mdadm --detail --scan
>ARRAY /dev/md0 level=raid1 num-devices=2 UUID=e89b1f50:4b91fcbe:c44c77eb:7ee19756
>ARRAY /dev/md1 level=raid1 num-devices=2 UUID=431cee17:6513c31f:c44c77eb:7ee19756

#uuid in mdadm.conf anpassen
mcedit /etc/mdadm/mdadm.conf
# ARRAY /dev/md1 level=raid1 num-devices=2 UUID=431cee17:6513c31f:c44c77eb:7ee19756
# ARRAY /dev/md0 level=raid1 num-devices=2 UUID=e89b1f50:4b91fcbe:c44c77eb:7ee19756

#initramfs aktualisieren
mkinitramfs -o /boot/initrd.img-2.6.18-6-686 2.6.18-6-686

#chroot beenden
umount /proc
exit

cd /
umount /mnt/boot
umount /mnt
reboot
Click to expand...

Ohne Raid funktioniert das zuverlässig. Das Einzige was mir jetzt noch einfällt ist, dass der Superblock den die Systemrescuecd schreibt für das Debian4 aus dem Tar-Archiv nicht lesbar ist. Deshalb habe ich Version 0.90 bei mdadm angegeben, weil das laut mdadm auf meinem Originalsystem der Defaultwert ist. Wie man aber die tatsächliche Version des Superblocks auslesen kann, habe ich noch nicht rausgefunden.

Wer hat eine Idee, wie ich hier weiter komme? Ich bin echt ratlos. Eine defekte Platte in einem Raid gegen eine neue Austauschen ist ja mehr oder weniger Alltag. Aber es muss doch auch möglich sein, dass Ganze auf komplett neuer Hardware zum Laufen zu bringen, oder?

Danke für eure Hilfe!
-Zeaq-
 
inode size fällt mir da ein wenn es Debian 4.0 ist.

Die hat sich von 128 auf 256 geändert mit irgendeiner Grub Version.

Kannst du beim mkfs angeben als Parameter.

Zum Anderen fällt mir auf das ich proc immer vorm chrooten mounte und auch dev dazu...

mount -t proc proc /mnt/proc
mount -o bind /dev /mnt/dev

dann chroot...

Zwischendurch hilft auch mal:

mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdb2

vorm erstellen eines neuen Raids...
 
Hey DjTom-i,

danke für deine Antwort. Ich habe mal versucht all deine Tipps umzusetzen. Leider hänge ich unverändert an der gleichen Stelle beim Booten.

>>inode size 128 zu 256
Ich habe mir eine Systemrescuecd von 2008 besorgt und verwende somit die gleiche Software wie auch meinem System

>>/proc und /dev vor chroot bereitstellen
habe ich mal so gemacht. wobei ich /dev nach meinem verständnis nicht brauche, weil ich noch ein statisches /dev und kein udev habe.

>>mdadm --zero-superblock /dev/sdb1
Habe ich auch schon mal probiert. Da ich allerdings auf komplett leeren Platten loslege, habe ich jetzt hier nichts weiteres ausprobiert.

Das chroot mache ich jetzt wie folgt:

#chroot starten
mount -o bind /proc/ /mnt/proc
chroot /mnt /bin/bash

...

#chroot beenden
exit
umount /mnt/proc
Click to expand...

Hast du weitere Ideen?
 
Last edited by a moderator:
Wenn ich nichts kaputt machen kann und du von allem Backups hast auf anderen Kisten würde ich mir das sogar mal "so" anschauen weil du doch mein Interesse geweckt hast.

ICQ 115985 .
 
Dritte Runde....

Nach tiefgründiger Recherche hat DjTom-i einige Dinge heraus gefunden. An dieser Stelle nochmal vielen Dank für deine Hilfsbereitschaft!

1.) Dass meine Bootpartition im Originalsystem eine ext2 und keine ext3 ist.

Ich habe darauf hin das System nochmal neu aufgesetzt und auch den Tipp mit der inode size nochmal berücksichtigt. Die Platten formatiere ich also nun wie folgt:

#Dateisystem erstellen
mkfs.ext2 -I 128 /dev/md0
mkfs.ext3 -I 128 /dev/md1
mkswap /dev/sda2
mkswap /dev/sdb2
Click to expand...

2.) Beim chroot binden wir nun auch noch das /dev mit an:

#chroot starten
mount -o bind /dev /mnt/dev
mount -t proc proc /mnt/proc
chroot /mnt /bin/bash
Click to expand...

3.) Wenn man /var/initramfs-tools komplett leert, klappt's auch mit update-initramfs. Somit machen ich das Update nun wie folgt:

update-initramfs -u
Click to expand...

Der einzige Haken an der Sache ist, dass es immer noch nicht funktioniert.... wer weiß rat?
 
Ins Blaue geraten: die UUID aus der /etc/mdadm.conf stimmt nicht mit der realen überein? Eventuell mußt Du die initrd anpassen?

ext2/3 macht eigentlich nicht den Unterschied - das Journal "stört" nicht, wenn man als ext2 mountet.
 
Hi Whistler,

danke für deine Antwort. Aber über die Steine bin ich schon gestolpert.

>>UUID aus der /etc/mdadm.conf stimmt nicht mit der realen überein?

Ich habe die UUID wie folgt ausgelesen bzw. aktualisiert:

#neue uuid des Raids ermitteln
mdadm --detail --scan
>ARRAY /dev/md0 level=raid1 num-devices=2 UUID=e89b1f50:4b91fcbe:c44c77eb:7ee19756
>ARRAY /dev/md1 level=raid1 num-devices=2 UUID=431cee17:6513c31f:c44c77eb:7ee19756

#uuid in mdadm.conf anpassen
mcedit /etc/mdadm/mdadm.conf
# ARRAY /dev/md1 level=raid1 num-devices=2 UUID=431cee17:6513c31f:c44c77eb:7ee19756
# ARRAY /dev/md0 level=raid1 num-devices=2 UUID=e89b1f50:4b91fcbe:c44c77eb:7ee19756
Click to expand...

Kann man das noch an anderer Stelle tun?

>>Eventuell mußt Du die initrd anpassen?

Hab ich so gemacht (siehe auch letzten Post):

update-initramfs -u
Click to expand...

>>ext2/3 macht eigentlich nicht den Unterschied
Wieder was gelernt.

Wenn du noch irgendwelche Ideen hast, immer her damit. Mir gehen inzwischen einfach die Ideen aus.

-zeaq-
 
Ich hatte mal das Problem dass die Festplatten nicht schnell genug bereit waren. "rootdelay=60" in der Kernel-Kommandozeile hat geholfen. Ansonsten schau Dir das hier mal an: http://wiki.debian.org/InitramfsDebug
Mit break=premount kannst Du selber nachschauen ob die mdadm.conf korrekt ist und was mit den Platten ist.
 
Eine gute Richtung

Hallo touchstone,

ich glaube das geht in die richtige Richtung. Mit "rootdelay=60" passiert zwar nach 60 Sekunden Wartezeit genau das gleiche, wie ohne Wartezeit. Aber das hat mir für "break=premount" die Augen geöffnet. Ich hab mal ein bisschen ausprobiert:

#cat /proc/mdstat
>Personalities : [raid1]
>unused devices: <none>

#cat /proc/partitions
>majar mino #blocks name

#fstype /dev/sda1
>/dev/sda1: No such file or directory

#cat /proc/modules
>...
>raid1
>md_mod
>sata_nv
>sata_svw
>scsi_mod
>ide_disk
>ide_core
>ext3
>...
Click to expand...

Bislang habe ich hier immer nur realisiert, dass das Raid nicht verfügbar ist. Allerdings sind ja auch die Partitionen nicht lesbar und sogar das Device sda1 überhaupt nicht bekannt. Die notwendigen Module sollten allerdings da sein.

Wie kann es kommen, dass initramfs meine Platte nicht erkennt?

-zeaq-
 
Welchen SCSI-Controller emulierst Du unter VMware? Buslogic oder LSI?
Vielleicht ist der Treiber oder ein Hilfsmodul nicht in der Initrd?
Eventuell hilft ein "scsi0.virtualDev = lsilogic"?
 
SCSI-Controller

Hallo Whistler,

danke für deine Antwort. Ich habe "einfach nur" eine neue SCSI-Platte eingefügt. Laut Config-File also eine "lsilogic". Ich habe mir mal parallel ein frisches Debian installiert - hier wird in der /etc/modules nur "loop" geladen und alles funktioniert... Hier die Konfigruation meiner virtuellen Maschine. Wo es jetzt auf ein VMWare Problem hinaus zu laufen scheint: Ich verwende VMWare Version 1.08!

config.version = "8"
virtualHW.version = "4"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "512"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "Ubuntu.vmdk"
ide1:0.present = "TRUE"
ide1:0.fileName = "C:\systemrescuecd-x86-1.0.4.iso"
ide1:0.deviceType = "cdrom-image"
floppy0.fileName = "A:"
Ethernet0.present = "TRUE"
displayName = "Neu"
guestOS = "ubuntu"
priority.grabbed = "normal"
priority.ungrabbed = "normal"

scsi0:1.present = "TRUE"
scsi0:1.fileName = "Ubuntu (2).vmdk"
ide1:0.autodetect = "TRUE"
floppy0.present = "FALSE"

scsi0:0.redo = ""
scsi0:1.redo = ""
ethernet0.addressType = "generated"
uuid.location = "56 4d c5 57 df 42 49 85-dc c3 a3 a1 f4 68 52 f6"
uuid.bios = "56 4d c5 57 df 42 49 85-dc c3 a3 a1 f4 68 52 f6"
ethernet0.generatedAddress = "00:0c:29:68:52:f6"
ethernet0.generatedAddressOffset = "0"
Click to expand...

Was nun?

-zeaq-
 
Last edited by a moderator:
Verzweiflung

Ein letzer Versuch, dass Thema nochmal zu beleben. Hat noch irgendjemand eine Idee?
 
mal schauen, ob ich dir etws helfen kann.
Sichere vor dem Einspielen die Datei /etc/modprobe.conf und das /boot Verzeichnis (und auch /etc/fstab und /etc/mdadm.conf). Nach dem Einspielen des Backups die modprobe.conf wieder ersetzen und die beiden anderen vergleichen. Das /boot Verz. wieder eersetzen. Dein Kernel hat sonst nämlich nicht die notwendigen Module, wenn du es mit den Kernel aus dem Backup überschreibst.
 
Last edited by a moderator:
Wiederbelebungsversuch

Hallo BruceLee,

danke für das Wiederbeleben meines Threads. Ich habe zwischenzeitlich mein
ganzes Szenario einmal mit Virtualbox, anstatt mit VMWare ausprobiert. Mit
dem Ergebnis, dass exakt das gleiche Problem auftritt. An VMWare liegt es also schon mal nicht.

Um auszuschließen, dass doch irgendwie die Partitionstabelle irgendwelche RAID-Geheimnisse beinhaltet, habe ich mir folgendes Vorgehen ausgedacht:

1. Virtuelle Maschine mit zwei SCSI-Platten erstellen, Debian 4.0 von CD installieren, Partitionionen und RAID's wie angegeben erstellen. Ergebnis: Die Kiste läuft wie geschmiert.

2. Virtuelle Maschine herunterfahren und per Rescuecd wieder starten. Alle Dateien (bis auf /boot als Mountpunkt) löschen und die Dateien aus dem Backup wieder einspielen. Anschließend die /etc/mdadm/mdadm.conf wie oben beschrieben aktualisieren. Als Ergebnis bekomme ich beim Booten den bekannten Fehler.

Mein Fazt:
- es liegt nicht an VMWare oder Virtualbox
- es liegt nicht an der Partitionstabelle

Vermutung:
- es fehlen irgendwelche Dateien
- im initrd ist der Wurm drin, da dieses schon /proc/partitions nicht lesen kann.

Ich bin jetzt gerade dabei deine Tipps auszuprobieren. Drück mir die Daumen ;-)

VG, Zeaq
 
Ich' werd' bekloppt....

Ich' werd' bekloppt.... 'et läuft! Wahnsinn! Ich danke dir für den Tipp. Aktuell bekomme ich jetzt noch einige Fehlermeldungen dieser Art:

modprobe: FATAL: could not load /lib/modules/2.6.18-6-486/modules.dep: No such file or directory

Was daran liegt, dass mein Originalsystem einen 2.6.18-6-686 Kernel (beachte den Unterscheid in der dritt letzten Zahl ;-) nutzt.

Jetzt bekomme ich zwar mein System irgendwie wieder "hingetrickst", allerdings würde ich gerne die Wurzel allen Übels finden wollen. Bei deinem Vorgehen haben wir ja den kompletten Kernel "getauscht". Wie komme ich aber den aus meiner Sicherung zum Rennen?

Das modprobe.d Verzeichnis habe ich abgeglichen, das war identisch. Auch die fstab und mdadm.conf möchte ich einmal ausschließen. Entsprechend liegt es wohl am Kernel oder der Initrd. Was ist aber bei diesem Austausch anders als wenn ich nach dem Restore (im chroot) einen neuen Kernel installiere (hatte ich auch schon mal probiert und beim Booten wieder die MDADM-Fehlermeldunge bekommen).

-zeaq-
 
mach erstmal einen snapshot.
vergleiche die modprobe.conf's.
installier einfach den 686 Kernel. jetzt kennt der Kernel ja noch nicht die modules aus deiner Sicherung, sondern die für die vmware erst-installation
 
Vergleich

Hi,

jetzt habe ich noch einmal ein bisschen weiter getestet. Das Ergebnis ist, dass das System bootet, sobald ich Kernel + initrd aus dem Rescuesystem verwende. Die Dateien /etc/mdadm/, /etc/modprobe.conf und /etc/fstab auszutauschen und die MDADM-ID's anzupassen ist nicht notwendig! Um fehlerfrei booten zu können, habe ich lediglich noch die Module des neuen Kernel unter /lib/modules mitgenommen.

Momentan bin ich gerade dabei die Inhalte der initrd's miteinander zu vergleichen. Hier taucht etc/mdadm, etc/modprobe usw. natürlich nochmals auf - ggf. liegt hier der Hund begraben. Wobei ich ja in vorherigen Tests die initrd bereits neu generiert hatte...

Falls du noch Ideen zur Analyse hast, bin ich natürlich immer dankbar!

-ZEAQ-
 
Ich würde mir auch noch die config.gz der beiden Kernel zu Gemüte führen.
Gerade für Rescuesysteme werden gerne auch Treiber statisch in den Kernel kompilieert.
 
config.gz

Hallo Whistler,

gute Idee, das werde ich auf jeden Fall auch noch einmal tun. Allerdings war das mit dem Rescuesystem etwas ungenau. Was ich aktuell tue, um mein System aus dem Backup zum Fliegen zu bekommen, ist folgendes:

1.) Ein frisches Debian 4 mit gleicher Partitionsstruktur + Raid in einer Virtualbox aufsetzen, Grub installieren, alles testen + System herunterfahren
2.) Das Ganze über die Systemrescuecd booten, die Platten von Schritt 1 einhängen, das Verzeichnis /boot und /lib/modules sichern...
3.) alle anderen Dateien löschen und die Dateien aus meiner Sicherung wiederherstellen + update-grub + reboot

Als Ergebnis habe ich dann also alle Dateien aus meinem Backup sowie den Kernel aus der Debian 4 Installation (aus Schritt 1) und nicht den von der Rescuesystem.

Viele Grüße
-Zeaq-
 
You must log in or register to reply here.
Back
Top