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

[Thomas Bork]

Am 27.02.2015 um 14:51 schrieb Stefan Welte:

> "mdadm -Es" liefert auf meinem eisfair mit 2.6er Kernel:
>> ARRAY /dev/md/data-raid1  metadata=1.2 UUID=2828347a:cf1db600:e7afe499:791fb662 name=eis1:data-raid1
> Exakt dies wurde bei der Installation vom 3.2er Kernel direkt in die mdadm.conf der initrd geschrieben,
> obwohl es in der initrd weder ein /dev/md-Verzeichnis noch ein passendes /dev/md/data-raid1-Blockgerät gibt.
> Mit udev ist das problemlos, weil automatisch erzeugt, aber soweit ich weiss, ist eisfair udevlos. Daher
> konnte der initiale Boot mit dem 3.2er Kernel nicht klappen.

In keiner der beim Kernel-Update erzeugten initrds weder bei Kernel 3.2 
noch bei Kernel 2.6.32 existiert in /dev ein Verzeichnis md oder 
/dev/md?. Das Assemblieren des Raids gelingt aber sowohl mit Metadata 
0.9 als auch bei Metadata 1.2. Das habe ich selbst bis zum Erbrechen 
getestet.

Wenn es nicht funktionieren würde, hätten _alle_ damit ein Problem, oder?

> Könnte man das 2.8.0-eiskernel-Paket derart abändern, daß ein laufendes Raid korrekt/korrigiert und nicht
> mit der Ausgabe von "mdadm -Es" in die mdadm.conf der initrd aufgenommen wird (falls das derzeit so passiert
> :-) )?

Das ist alles, was bezüglich Raid in install.sh des Kernel-Updates getan 
wird (schau doch einfach mal rein):

# check, if '/sbin/mdadm --assemble --scan' has to be executed for soft 
raids
startraid=''
for level in $(awk '/^md[0-9][0-9]*[[:space:]]*:/ { print $4 }' 
/proc/mdstat | sort -u)
do
     case $level in
     linear)
             startraid='1'
             ;;
     raid[0145])
             startraid='1'
             ;;
     *)
             message="Raid level $level in /proc/mdstat not recognized!"
             mecho --error "$message"
             echo "$message" >>"$klogfile"
             ;;
     esac
done

# do this also by only ide devices, lilo.conf with append line
# raid=noautodetect will make sure, autodetect runs always
# in initrd
if [ -n "$startraid" ]
then
     # new variant with mdadm in initrd
     cp /sbin/mdadm $initrd_mount/sbin
     echo "DEVICE /dev/[sh]d*" >$initrd_mount/etc/mdadm.conf
     mdadm --examine --scan >>$initrd_mount/etc/mdadm.conf
     echo "/sbin/mdadm --assemble --scan" >>$initrd_mount/linuxrc
     message="Added /sbin/mdadm for software raid to linuxrc."
     echo "$message"
     echo "$message" >>"$klogfile"
fi

> Zuvor kann ich ggf. den 2.8.0er-Kernel nochmal installieren und nur /dev/md/data-raid1 zu /dev/md1 ändern,
> damit man sieht, ob dies die einzige Ursache ist.

Ich kann nichts korrigieren, was ich nicht durchschaue - gerade bei von 
Usern selbst gebastelten Raids.

Was ich weiß ist:
Die mit unserem Installer erstellten Raids überleben ein Kernel-Update 
mit der Routine, wie sie in den Kernel-Update-Raketen drin ist - ob 
davon gebootet wird oder nicht.

Und zu mehr fehlt mir im Moment die Zeit.

Hast Du unter dem von mir geposteten Link nachgelesen?

-- 
der tom
[eisfair-team]