Software RAID nach UCS Installation "verschwunden"

Hallo Gemeinde,

ich evaluiere derzeit den Univention Corporate Server als Alternative zu Windows Small Business Server. Mit der “Free for Personal Use”-Edition habe ich bereits erfolgreich einen DC Master (UCS 3.0-1) auf einem System installieren können. Allerdings scheitert bei dem Versuch ein DC Slave-System aufzusetzen der Bootvorgang. Es scheint so, als würden zwei der eingerichteten Software-RAIDs einfach verschwinden.

System-Informationen:

Es handelt sich um einen Maxdata Platinum 200 Server mit 2 x 250 GB SATA Festplatten an einem FakeRAID-Controller (ICH7R vermutlich). Dieser wurde im BIOS deaktiviert, der SATA-Controller auf AHCI eingestellt. Vormals war auf dem System ein Gentoo Linux mit XEN Hypervisor installiert. Installiert wurde der Univention Corporate Server 3.0 (UCS 3.0) gemäß Handbuch und Experten-Dokumentation wegen der Übernahme der vorhandenen Software-RAIDs/des Partitionslayouts. Die LVM-Gruppe darf nicht gelöscht und/oder neu erstellt werden, da hier noch zwei virtuelle XEN-Maschinen ihren Platz finden.

Partitionslayout
sd[a|b]1 100 MB ext2 RAID-1 (md0) /boot sd[a|b]2 1024 MB swap swap sd[a|b]3 2048 MB ext3 RAID-1 (md1) / sd[a|b]4 (Rest) - RAID-0 (md127) LVM2 VG-Name: vg_ucs

LVM-Layout (VG: vg_ucs)
home 10 GB ext3 /home opt 4 GB ext3 /opt tmp 2 GB ext2 /tmp usr 8 GB ext3 /usr var 4 GB ext3 /var vartmp 6 GB ext2 /var/tmp

Während der Experten-Installation wurden die entsprechenden Variablen in der Configuration Registry gesetzt (installer/device/…/[fs|name|mp], grub/boot, grub/groot, gem. Wiki-Beitrag), GRUB wurde nach /dev/sda und /dev/sdb installiert. Die Installation wurde erfolgreich abgeschlossen, nach dem Neustart wird versucht zu booten, doch hier werde ich dann auf die Shell zurückgeworfen, weil er die Root-Partition nicht finden kann.

Während der Installation:

[code]# cat /proc/mdstat
Pesonalitites : [raid1] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
102336 blocks [2/2] [UU]

md1 : active raid1 sda3[0] sdb3[1]
2096116 blocks super 1.2 [2/2] [UU]

md127 : active raid0 sda4[0] sdb4[1]
482945024 blocks super 1.2 512k chunks

unused devices: [/code]

Nach der Installation:

[code]

Success: loaded module raid1.
Success: loaded module raid0.
Begin: Assembling all MD arrays …
[ 3.080217] md: md127 stopped.
[ 3.083350] md: bind
[ 3.083488] md: bind
mdadm: Container /dev/md/imsm0 has been assembled with 2 drives
Failure: failed to assemble all arays.
Begin: Waiting for root file system … done.
Gave up waiting for root device. …

ALERT! /dev/md1 does not exist. Dropping to a shell!

cat /proc/partitions

major minor #blocks name

8 0 244168584 sda
8 16 244198584 sdb

cat /proc/mdstat

Personalities : [raid0] [raid1]
md127 : inactive sdb1 sda0
4514 blocks super external:imsm

unused devices: [/code]

Versuchweise habe ich md0 aufgelöst und ausschließlich /dev/sda1 für /boot verwendet, leider ohne Erfolg. Google lieferte mir leider auch keine brauchbaren Ergebnisse. Ich bin im Moment etwas ratlos was dieses Verhalten anbelangt. Zumal die vorherige Gentoo-Installation ohne Probleme auch vom RAID-1 booten konnte. Vielleicht übersehe ich aber auch das Wesentliche. Wäre nett wenn mir jemand einen Wink in die richtige Richtung geben könnte. Vielen Dank jetzt schon im Voraus.

Gruß
Sascha Schröder

Hallo,

haben Sie nach der erfolgreichen UCS-Installation eine /etc/mdadm/mdadm.conf im Installationssystem abgelegt?
Können Sie die bei der Installation gesetzten “installer/”-Variablen noch rekonstruieren und hier angeben?
Können die RAID-Devices in der Rescue-Shell manuell assembliert werden (z.B. “mdadm --assemble --scan”)? Bzw. ist es möglich /dev/sda1 oder /dev/sdb1 manuell zu mounten?
Mit welchen Optionen wird der Kernel derzeit gebootet (cat /proc/cmdline)?

Bitte beachten Sie dass der Wiki-Artikel zu Software-RAID für UCS 2.4 geschrieben wurde. Mit UCS 3.0 sind hier aufgrund des Wechsels von Grub1 auf Grub2 Anpassungen im Ablauf notwendig die z.B. im Thread Probleme mit Grub bei erweiterter Installation Software-RAID diskutiert wurden.

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

Ja, diese wurde mittels mdadm --detail --scan erzeugt und zusätzlich nach /instmnt/etc/mdadm/mdadm.conf kopiert. Danach wurde die Initrd mittels update-initramfs neu erstellt. Während der Installation werden die Partitionen auch noch korrekt erkannt.

Aber klar:

[code]ucr set installer/device/0/fs=ext3
ucr set installer/device/0/mp=/
ucr set installer/device/0/name=/dev/md1

ucr set installer/device/1/fs=linux-swap
ucr set installer/device/1/mp=None
ucr set installer/device/1/name=/dev/sda2

ucr set installer/device/2/fs=linux-swap
ucr set installer/device/2/mp=None
ucr set installer/device/2/name=/dev/sdb2

ucr set installer/device/3/fs=ext2
ucr set installer/device/3/mp=/boot
ucr set installer/device/3/name=/dev/md0

ucr set installer/device/4/fs=ext3
ucr set installer/device/4/mp=/usr
ucr set installer/device/4/name=/dev/mapper/vg_ucs-usr

ucr set installer/device/5/fs=ext3
ucr set installer/device/5/mp=/var
ucr set installer/device/5/name=/dev/mapper/vg_ucs-var

ucr set installer/device/6/fs=ext2
ucr set installer/device/6/mp=/var/tmp
ucr set installer/device/6/name=/dev/mapper/vg_ucs-vartmp

ucr set installer/device/7/fs=ext3
ucr set installer/device/7/mp=/opt
ucr set installer/device/7/name=/dev/mapper/vg_ucs-opt

ucr set installer/device/8/fs=ext2
ucr set installer/device/8/mp=/tmp
ucr set installer/device/8/name=/dev/mapper/vg_ucs-tmp

ucr set installer/device/9/fs=ext3
ucr set installer/device/9/mp=/home
ucr set installer/device/9/name=/dev/mapper/vg_ucs-home[/code]

Nein, mdadm findet “angeblich” nur ein RAID-Device (md127) das komplett über beide Festplatten geht. Leider haben die Festplatten keine Partitionen lt. /proc/partitions:

code cat /proc/partitions
major minor #blocks name

8 0 244198584 sda
8 16 244198584 sdb[/code]

code cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.32-ucs52-amd64 root=/dev/md1 ro loglevel=0 vga=788[/code]

GRUB findet die Boot-Partition(en) und kann auch den Kernel und die Initrd erfolgreich laden. Was mich verwundert, dass der Kernel entgegen dem Installer-Kernel den integrierten “Intel Matrix Storage Controller” erkennt. Daher auch die Meldung mdadm: Container /dev/md/imsm0 has been assembled with 2 drives. Wenn ich wie in diesem Beitrag vorgehe, kommt folgendes bei raus:

code mdadm -I /dev/md/imsm0
mdadm: Started /dev/md/Volume0 with 2 devices
(initramfs) cat /proc/partitions
major minor #blocks name

8 0 244198584 sda
8 16 244198584 sdb
8 126 244195328 md126
259 0 102400 md126p1
259 1 52488 md126p2
259 2 2097152 md126p3
259 3 241470464 md126p4
(initramfs) cat /proc/mdstat
Personalities : [raid0] [raid1]
md126 : active (read-only) raid1 sda[1] sdb[0]
244195328 blocks super external:/md127/0 [2/2] [UU]

md127 : inactive sdb1 sda0
4514 blocks super external:imsm

unused devices: [/code]
Nun kann ich mittels mkdir /mnt; mount /dev/md126p1 /mnt die Boot-Partition erfolgreich mounten und auf diese zugreifen. Ich möchte ungern an /init der initrd Hand anlegen, noch den IMSC aus dem Board löten.

Mit freundlichen Grüßen

Sascha Schröder

Hallo,

ein ähnliches Verhalten konnten wir bisher noch nicht beobachten, ich bin allerdings auch nicht sicher ob ob/wie viele Systeme mit einem Intel Matrix Storage Controller betrieben werden. Generell hätte ich vermutet das dessen Funktionen (die ja nach der Installation aktiv scheinen) durch das Deaktivieren im BIOS abgeschaltet würden. Ein allgemeines Problem in Ihrem Setup kann ich so nicht erkennen und Sie scheinen ja auch nicht unerfahren im Thema zu sein. Es scheint mir hier auf jeden Fall eine Art Wechselwirkung mit den Funktionen des Intel Matrix Storage Controller und den Metadaten des Software-RAID zu geben.
Das differente Verhalten zwischen Installer und Installiertem System lässt sich dadurch erklären das der installierte Kernel aktueller ist als der Kernel mit dem der Installer betrieben wird. Ggf. könnten Sie einmal prüfen wie sich der Installer auf dem aktuellen UCS 3.0-2 Medium verhält da dieser wiederum aktueller sein sollte als der Momentan installierte.

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

Das waren die richtigen Stichworte. Ich habe heute morgen mit dem vorherigen SysAdmin ein Gespräch geführt. Hierbei erklärte er mir, dass der Server einst mit Windows 2003 geliefert wurde und ein RAID-0 per Controller-Firmware eingerichtet war. Das später installierte Gentoo-Linux System wurde mittels eigens für diesen Server angepassten Kernel betrieben. Da keine Bedarf an einem alle Festplatten-umfassenden RAID-0 vorhanden war, wurde das entsprechende Kernel-Modul einfach weggelassen. Bei meiner weiteren Analyse wurde folgendes ans Tageslicht gefördert:

code mdadm --detail-platform
Platform : Intel® Matrix Storage Manager

Port0 : /dev/sda (WDC WD2500AAKS-00V6A0)
Port1 : /dev/sdb (WDC WD2500AAKS-00V6A0)
Port2 : - no device attached -
Port3 : - no device attached -
…[/code]

Eine Suche auf der Mailingliste linux-raid ergab, dass es möglich ist den Superblock des IMSC zu entfernen, da dieser seine Metadaten ans Ende der Festplatte(n) schreibt und (glücklicherweise) nicht oder nur bedingt mit den Metadaten von mdadm kollidieren. Wie in dem Beitrag von Dan Williams beschrieben konnten die Metadaten wie folgt entfernt werden:

code mdadm --stop /dev/md/imsm0
(initramfs) mdadm --zero-superblock -e imsm /dev/sda
(initramfs) mdadm --zero-superblock -e imsm /dev/sdb
(initramfs) reboot[/code]

Danach startet der Server einwandfrei, alle Partitionen (/dev/md0, /dev/md1, LVM) werden wie im Installer angegeben eingebunden und es ist auch kein Datenverlust aufgetreten.

Ich bedanke mich nochmals bei Herrn Meybohm für die freundliche Unterstützung und die passenden Hinweise zur Lösungsfindung.

Mit freundlichen Grüßen

Sascha Schröder

Hallo,

vielen Dank für die ausführliche und aufschlussreiche Rückmeldung, diese Diskussion wird bestimmt auch für andere zur wertvollen Informationsquelle.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon