Update Lenny -> Squeeze Raid-Probleme bei Kernel 2.6.32

[berni123]

Hallo,

ein neuer Fall zum Thema: Update Lenny->Squeeze und Raid Probleme.

Nach dem dist-upgrade von Lenny auf Squeeze wurde auch Kernel 2.6.32-5-amd64 installiert.
Damit startet das System zwar und mounted / welches auf /dev/md0 liegt,
aber die übrigen Raid-Arrays /dev/md1 und /dev/md2 werden nicht erkannt.
Unglücklicherweise liegt /var und andere auf einem der nichterkannten raids.

Boote ich den alten Kernel: 2.6.26-2-amd64 dann läuft alles wunderbar.

Ich habe mir jetzt schon nen Wolf gegoogelt, aber so richtig den passenden Tipp habe ich
noch nicht bekommen, wie ich das Raiderkennung unter 2.6.32 zum Laufen bekomme.
Vor allem /dev/md0 wird ja erkannt nur /dev/md1 und /dev/md2 nicht.

Bestehende /etc/mdadm.conf und mdadm-Ausgaben:

Code: Alles auswählen

:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.5 (squeeze)
Release:        6.0.5
Codename:       squeeze

:~# uname -a
Linux viro08 2.6.26-2-amd64 #1 SMP Wed Sep 21 06:20:44 UTC 2011 x86_64 GNU/Linux
viro08:~# 

:~# cat /etc/mdadm/madadm.conf
DEVICE partitions
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=2fd21b81:cc0de808:57a7b7fb:68a2d587
   devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=c1b8c04f:dfd4402d:fd1447e8:07328603
   devices=/dev/hda3,/dev/hdc3
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=eb4e3125:d499b6de:24fc2a8f:c78d0f1b
   devices=/dev/hda1,/dev/hdc1
MAILADDR root

:~# mdadm --version
mdadm - v3.1.4 - 31st August 2010

:~# mdadm --examine --scan --config=mdadm.conf
ARRAY /dev/md0 UUID=eb4e3125:d499b6de:24fc2a8f:c78d0f1b
ARRAY /dev/md1 UUID=c1b8c04f:dfd4402d:fd1447e8:07328603
ARRAY /dev/md2 UUID=2fd21b81:cc0de808:57a7b7fb:68a2d587

Die UUIDs sind also vorhanden ...

Die Option rootdelay=9 im grub-Eintrag bringt auch nichts, vor allem wird das /-Array ja wie erwähnt erkannt nur die restlichen nicht.
Etwas mit der Zeit muss es zu tun haben, denn ein zwischenzeitlicher Bootversuch zauberte auf ein mal zusätzlich /dev/md2 herbei,
und /dev/md1 fehlte dann nur. Beim nächsten reboot war das aber schon wieder weg.

Ich kann den Server auf keinen Fall neu installieren sondern muss mit dem update leben.
Ich möchte aber auf kurze Sicht auch gerne den aktuellen Kernel verwenden und nicht
bei dem alten bleiben müssen.

Hat also jemand einen zielführenden Tipp, wie ich unter 2.6.32 die Raid-Konfig so hinbekomme,
dass alle Raids erkannt werden und nicht nur das erste ?

Gruss,
Bernd

[rendegast]

Unglücklicherweise liegt /var und andere auf einem der nichterkannten raids.

Bringe /var wieder auf / unter,
datenreiche sekundäre Verzeichnisse (/var/www, /var/lib/mysql usw.) belasse an ihrem jetzigen Ort und binde sie über fstab zBsp. per bind-Mount ein.
Dadurch dürften /var/run /var/lock erstmal wieder zur Verfügung stehen.

ARRAY /dev/md1 level=raid1 num-devices=2 UUID=c1b8c04f:dfd4402d:fd1447e8:07328603
devices=/dev/hda3,/dev/hdc3
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=eb4e3125:d499b6de:24fc2a8f:c78d0f1b
devices=/dev/hda1,/dev/hdc1

Bei squeeze gibt es meist keine hd* mehr,
da dürften es dann sda bis sdd sein.
Eventuell kannst/solltest Du "devices=" ganz weglassen, weil zu statisch?
Eventuell hilft eine Prüfung der /boot/grub/device.map auf sda bis sdd,
Anpassung der mdadm.conf
und auf Start des 2.6.26 fürderhin verzichten.
('update-initramfs -u -kall' dürfte die aktualisierte mdadm.conf in die initrd übertragen.)

[berni123]

Danke für die Tips!!!

Unglücklicherweise liegt /var und andere auf einem der nichterkannten raids.

Bringe /var wieder auf / unter,
datenreiche sekundäre Verzeichnisse (/var/www, /var/lib/mysql usw.) belasse an ihrem jetzigen Ort und binde sie über fstab zBsp. per bind-Mount ein.
Dadurch dürften /var/run /var/lock erstmal wieder zur Verfügung stehen.

Der 2.6.32-Boot legt ohne /dev/md1 unter /var (ohne mount) schon die nötigen Verzeichniss an (bis auf spool, usw.), aber
aufgrund des Platzes kann ich auf den zusätzlichen Mount nicht verzeichten, da / selber etwas klein ist.

ARRAY /dev/md1 level=raid1 num-devices=2 UUID=c1b8c04f:dfd4402d:fd1447e8:07328603
devices=/dev/hda3,/dev/hdc3
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=eb4e3125:d499b6de:24fc2a8f:c78d0f1b
devices=/dev/hda1,/dev/hdc1

Bei squeeze gibt es meist keine hd* mehr,
da dürften es dann sda bis sdd sein.
Eventuell kannst/solltest Du "devices=" ganz weglassen, weil zu statisch?
Eventuell hilft eine Prüfung der /boot/grub/device.map auf sda bis sdd,
Anpassung der mdadm.conf und auf Start des 2.6.26 fürderhin verzichten.
('update-initramfs -u -kall' dürfte die aktualisierte mdadm.conf in die initrd übertragen.)

[/quote]

Wenn ich unter laufendem 2.6.26 mit mdadm --examine --scan --config=mdadm.conf scanne bekomme ich:

Code: Alles auswählen

ARRAY /dev/md0 UUID=eb4e3125:d499b6de:24fc2a8f:c78d0f1b
ARRAY /dev/md1 UUID=c1b8c04f:dfd4402d:fd1447e8:07328603
ARRAY /dev/md2 UUID=2fd21b81:cc0de808:57a7b7fb:68a2d587

Sollte ich evtl. damit mal die neue initrd bauen und testen den 2.6.32er Kernel zu starten?

Derzeit läuft das System halbwegs, aber ich hab schon festgestellt, das udev und 2.6.26 einige
Device-Rechte nicht richtig setzt (falsche UID/GID, falsche Zugriffsrechte 600 anstelle 666 oder 660).

Leider leider leider habe ich http://www.debian.org/releases/stable/i ... ng.de.html erst jetzt
entdeckt und gelesen, das man vor dem dist-upgrade erst udev und Kernel erneuern sollte und auch mit apt-get und nicht
aptitude arbeiten soll. Ich habe halt getreu den vorherigen Erfahrungen es über aptitude gemacht und bin damit voll in
die Sch****e getappt.

[rendegast]

Code: Alles auswählen

bekomme ich:
    ARRAY /dev/md0 UUID=eb4e3125:d499b6de:24fc2a8f:c78d0f1b
    ARRAY /dev/md1 UUID=c1b8c04f:dfd4402d:fd1447e8:07328603
    ARRAY /dev/md2 UUID=2fd21b81:cc0de808:57a7b7fb:68a2d587

sieht bei mir zwar etwas anders aus

Code: Alles auswählen

    ARRAY /dev/md/0 metadata=1.2 UUID=eb4e3125:d499b6de:24fc2a8f:c78d0f1b name=hostname:0
    ARRAY /dev/md/1 metadata=1.2 UUID=c1b8c04f:dfd4402d:fd1447e8:07328603 name=hostname:1
    ARRAY /dev/md/2 metadata=1.2 UUID=2fd21b81:cc0de808:57a7b7fb:68a2d587 name=hostname:2

(unter squeeze-Installer erstellte raids) so aber auch in der mdadm.conf,
also ohne explizite Angabe von devices.
Die entsprechende Information über die Art der raids steht dann wohl in den Headern derselben.
(Ich könnte mir noch Ostereier ob des metadata-Formats der bestehenden raids denken)
Die Angabe der UUID reicht wohl dem 'mdadm --assemble' der Startskripte.

Versuch macht kluch.


In der /etc/default/mdadm könnte auch für einen Kernel eine andere mdadm.conf gesetzt werden,
über die Variablen CONFIG / DAEMON_OPTIONS in den Startskripten, in der Art:

Code: Alles auswählen

cat /proc/version | grep "Linux version 2.6.26" && { CONFIG=alte_mdadm.conf; DAEMON_OPTIONS="$DAEMON_OPTIONS --config=alte_mdadm.conf"; }

das udev und 2.6.26 einige
Device-Rechte nicht richtig setzt (falsche UID/GID, falsche Zugriffsrechte 600 anstelle 666 oder 660).

Dafür gibt es in der mdadm.conf eigentlich eine Zeile wie

Code: Alles auswählen

CREATE owner=root group=disk mode=0660 auto=yes

Mal /usr/share/mdadm/mkconf ausprobieren.

[berni123]

Die entsprechende Information über die Art der raids steht dann wohl in den Headern derselben.
(Ich könnte mir noch Ostereier ob des metadata-Formats der bestehenden raids denken)
Die Angabe der UUID reicht wohl dem 'mdadm --assemble' der Startskripte.

Versuch macht kluch.

In der /etc/default/mdadm könnte auch für einen Kernel eine andere mdadm.conf gesetzt werden,
über die Variablen CONFIG / DAEMON_OPTIONS in den Startskripten, in der Art:

Code: Alles auswählen

cat /proc/version | grep "Linux version 2.6.26" && { CONFIG=alte_mdadm.conf; DAEMON_OPTIONS="$DAEMON_OPTIONS --config=alte_mdadm.conf"; }

Nette Info, finde dort gerade:

Code: Alles auswählen

# INITRDSTART:
#   list of arrays (or 'all') to start automatically when the initial ramdisk
#   loads. This list *must* include the array holding your root filesystem. Use
#   'none' to prevent any array from being started from the initial ramdisk.
INITRDSTART='/dev/md0'

Wäre also auch einen Versuch wert dort mal "all" einzutragen und nicht nur md0 ... wobei später ja steht

Code: Alles auswählen

# AUTOSTART:
#   should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
#   during boot?
AUTOSTART=true

und das sollte für /var dann auch reichen.

das udev und 2.6.26 einige
Device-Rechte nicht richtig setzt (falsche UID/GID, falsche Zugriffsrechte 600 anstelle 666 oder 660).

Dafür gibt es in der mdadm.conf eigentlich eine Zeile wie

Code: Alles auswählen

CREATE owner=root group=disk mode=0660 auto=yes

Mal /usr/share/mdadm/mkconf ausprobieren.

Das Script liefert:

Code: Alles auswählen

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE ${DEVICE:-partitions}
viro08:/etc/mdadm# /usr/share/mdadm/mkconf 
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md0 UUID=eb4e3125:d499b6de:24fc2a8f:c78d0f1b
ARRAY /dev/md1 UUID=c1b8c04f:dfd4402d:fd1447e8:07328603
ARRAY /dev/md2 UUID=2fd21b81:cc0de808:57a7b7fb:68a2d587

# This configuration was auto-generated on Sun, 17 Jun 2012 12:23:43 +0200
# by mkconf 3.1.4-1+8efb9d1+squeeze1

Also analoges Ergebnis und eine paar zusätzliche Angabe

Ich werde am Montag dann mal mit dieser Config und neuer initrd den Boot mit Kernel 2.6.32 versuchen.

Gruss,
Bernd