[Eisfair] [e1] eiskernel 2.8.0 (Status 'stable') verfügbar - 3.2er Kernel für eisfair-1

[Thomas Zweifel]

Hallo Thomas

Am 11.03.2015 um 20:27 schrieb Thomas Bork:
> Am 11.03.2015 um 17:00 schrieb Thomas Zweifel:
> 
>> Was in der mdadm.conf eingetragen ist wird gestartet, alles andere wird
>> nicht angefasst. (mit 1.2 zumindest, 0.90 habe ich noch nicht getestet)
> 
> Du testest nicht, wie der eisfair-Mechanismus (Assemblierung in der
> initrd) an sich funktioniert, sondern mit Deinen Besonderheiten a la
> /etc/mdadm/mdadm.conf.lvm und einer späteren Assemblierung.
> 
> Das macht zumindest bei Raids mit Namen einen Unterschied.

Nein, das Skript läuft nach dem aktivieren vom swap und vor dem fsck:

cat /etc/init.d/boot
....
swapon -a
/bin/mount -n -o remount,ro / 2>/dev/null

if [ $? -eq 0 ]
then
    # start lvm
    if [ -x /etc/init.d/boot.lvm ] ; then
        /etc/init.d/boot.lvm
    fi

    # -C display output with progressbar
    FSCK_PROGRESS=''
....

und macht folgendes:

cat /etc/init.d/boot.lvm
#!/bin/sh
#
# mount /proc and /sys
#
if [ ! -e /proc/mounts ] ; then
    /bin/mount -n -t proc /proc /proc >/dev/null 2>&1
    /bin/mount -n -t sysfs /sys /sys >/dev/null 2>&1
fi

# assemble aditional md
#
if [ -f /etc/mdadm/mdadm.conf.lvm ] ; then
    /sbin/mdadm -A -s --config=/etc/mdadm/mdadm.conf.lvm
fi

# Device mapper & related initialization
#
if /bin/fgrep -q "device-mapper" /proc/devices 2>/dev/null ; then
  if [ -d /dev/mapper ] ; then
    /bin/mount -n -t ramfs -o size=64k ramfs /dev/mapper
    /bin/mknod /dev/mapper/control c \
      $(/bin/awk '/ misc$/ { print $1 }' /proc/devices) \
      $(/bin/awk '/ device-mapper$/ { print $1 }' /proc/misc)
2>/dev/null 2>&1
  fi
  if [ -c /dev/mapper/control ] ; then
    /sbin/modprobe dm-mod >/dev/null 2>&1
    /sbin/modprobe dm-mirror >/dev/null 2>&1
    if [ -x /sbin/lvm ] ; then
      /sbin/lvm vgchange -a y --ignorelockingfailure 2>/dev/null
    fi
  fi
fi


Die zum assemblen benutze mdadm.conf ist auch nicht besonders aufregend.

cat /etc/mdadm/mdadm.conf.lvm
#
#  generated from mkmdadmconf.sh
#
DEVICE partitions
#
ARRAY /dev/md1 UUID=b8fbe2ff:a849235a:fed2633c:57c6ac4a
ARRAY /dev/md/2  metadata=1.2 UUID=d1b6a3fe:94567591:06225af4:ad1e1e3d
name=service02test:2
ARRAY /dev/md3 UUID=fbf4f3f2:669a9aa6:2162b165:bb7a626b
ARRAY /dev/md/49  metadata=1.2 UUID=7d2f6a52:5101d4e4:069833f8:5d0c20e2
name=service02test:49
ARRAY /dev/md/50  metadata=1.2 UUID=f451b5d0:4cba0816:0b9f895c:d8693764
name=service02test:50
ARRAY /dev/md/51  metadata=1.2 UUID=e6f67e55:4855f6aa:2357c251:4457aede
name=service02test:51
ARRAY /dev/md/52  metadata=1.2 UUID=6a2ff1b6:3e75213c:824d8a1b:dd33875b
name=service02test:52
ARRAY /dev/md/53  metadata=1.2 UUID=66cf9417:f2f3612c:fd88fc91:14f6bd0b
name=service02test:53
ARRAY /dev/md/77  metadata=1.2 UUID=ec3cec13:9936a791:c31b9e4a:fb824da5
name=77
ARRAY /dev/md/foobar  metadata=1.2
UUID=01a9f9ce:f0a7ff3d:f788faf0:d6ecd9ac name=foobar
ARRAY /dev/md/78  metadata=1.2 UUID=252ccd4e:4b19beaf:3a8a9cb8:cc7b7ca8
name=service02test:78
ARRAY /dev/md/barfoo  metadata=1.2
UUID=b8d5d52d:6656d31c:96c70065:e6e1bc5f name=service02test:barfoo


> Wie Du selbst schreibst:
> 
>> Der name= Parameter ist allerdings für den E1 ziemlich unbrauchbar,
>> solange man nicht selbst Hand anlegt:
> 
> Und wie man hier sieht:
> 
>> mdadm --stop /dev/md[5678]
>> mdadm: stopped /dev/md5
>> mdadm: stopped /dev/md6
>> mdadm: stopped /dev/md7
>> mdadm: stopped /dev/md8
>>
>> mdadm -As --config=/etc/mdadm/mdadm.conf.lvm
>> mdadm: /dev/md/77 has been started with 5 drives.
>> mdadm: /dev/md/foobar has been started with 5 drives.
>> mdadm: /dev/md/78 has been started with 5 drives.
>> mdadm: /dev/md/barfoo has been started with 5 drives.
>>
>> ls -l /dev/md/
>> lrwxrwxrwx  1 root root     9 Mar 11 17:44 77 -> /dev/md77
>> lrwxrwxrwx  1 root root     9 Mar 11 17:44 78 -> /dev/md78
>> lrwxrwxrwx  1 root root    10 Mar 11 17:44 barfoo -> /dev/md126
>> lrwxrwxrwx  1 root root    10 Mar 11 17:44 foobar -> /dev/md127
> 
> Auch wenn bei Deinen Tests mdadm im schon laufenden System die
> entsprechenden Devices unter /dev/md und die Links unter /dev/md*
> angelegt hat, wird das beim Assemblieren in der initrd nie funktionieren:
> 
> Die initrd hat ihr eigenes /dev-System. Es ist toll, wenn die Links und
> Devices von mdadm dort angelegt werden. Allerdings knallt es dann beim
> Verlassen der initrd, wenn die Links und Devices im normalen /dev-System
> nicht existieren.

Richtig, der unterschied ist lediglich, dass sie aufgrund der readonly
root nicht gestartet werden, weil mdadm die Devices nicht erstellen kann.

Das hat zum testen, inwiefern sich der homehost und name parameter beim
assemblen auswirken, keinerlei einfluss.

Das Fazit ist ja eben:
homehost --> unkritisch
name --> nicht unterstützt (da kein udev)


> Quintessenz:
> Es ist weder im Installer noch im Kernel-Update etwas zu ändern. Selbst
> erzeugte Raid-Devices mit Namen werden nicht assembliert. Die
> Dokumentation beschreibt an keiner Stelle, dass die Raid-Devices benamt
> werden sollen.
> 
> Wie Du schreibst, ist es egal, was im homehost steht, solange das Array
> in mdadm.conf steht. Also sollte sich jedes selbst erstellte Raid ohne
> Namen nach einem Kernel-Update in der initrd assemblieren lassen.

Genau


> Bitte überprüft das - und zwar auf dem normalen Weg der Assemblierung in
> der initrd, damit nicht wieder Äpfel und Birnen verglichen werden.

Überflüssig, siehe oben.



Gruss Thomas