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

Thomas Bork tom at eisfair.org
Mi Mär 4 21:41:40 CET 2015


Am 04.03.2015 um 02:33 schrieb Stefan Welte:

> grml-small-2012.05, wie genau weiß ich jetzt nicht mehr, aber vermutlich habe ich aus irgendeinem Grund,
> beim create den Parameter --name=data-raid1 mit angegeben.

Also fremderstellt.

> nicht deswegen, sondern weil am 15. Januar 2015 n.Chr. eiskernel 2.4.3 mit der Package-Suchfunktion nicht zu
> finden war.

Es gibt bei eisfair nur einen stabilen Kernel. Wenn zu diesem Zeitpunkt 
2.4.3 nicht mehr der stabile eiskernel war, konntest Du ihn schon allein 
deswegen nicht mehr finden. Aber sowohl der eisfair-1-Installer mit base 
2.3.4, eiskernel 2.4.3 als auch alle späteren Installer haben schon 
Metadata 1.2 unterstützt.

> Meine (ideallistische) Meinung dazu ist: ich habe unter 2.4.3-eiskernel ein RAID1 am Laufen, ich update den
> eiskernel und hinterher wird auch mit dem neuen eiskernel das RAID1 zum Laufen gebracht, unabhängig welche
> Eigenschaften das RAID1 im Detail hat.

Das ist ziemlich idealistisch, denn:

Wir unterstützen ab einem gewissen Zeitpunkt die Erstellung von Raids 
mit dem Installer. Also sorgen wir auch dafür, dass diese erstellten 
Raids nach einem Kernel-Update gestartet werden. Und das werden sie.

Wir ändern die Methode der Partitionierung und Raid-Erstellung im 
Installer, um Partitionen grösser 2TB zu unterstützen. Und wir sorgen 
dafür, dass beide Varianten (alt und neu) nach einem Kernel-Update immer 
noch sauber assembliert werden. Und das werden sie.

Du hast Dir etwas selbst gebastelt, was zufällig funktioniert hat. Nun 
funktioniert es nicht mehr. Aber niemand (zumindest ich nicht) kann alle 
selbstgefummelten Eventualitäten abdecken. Dazu fehlt mir einfach die 
Zeit und übrigens habe ich diesen Anspruch auch überhaupt nicht ;-)

> jup, aber es sollte optional/mit Abfrage sein. Nur weil bereits der 2.8.0-eiskernel gebootet ist, möchte ich
> auf den 2.4.3-eiskernel zurückgreifen können, was scheinbar nur bei nicht gebootetem 2.8.0-eiskernel so
> gehandhabt/ermöglicht wird, d.h. zum "drüberinstallieren" des 2.8.0-eiskernel UND behalten des
> 2.4.3-eiskernel musste ich eisfair neu starten und den 2.4.3-eiskernel booten.

Genau so ist das. So stand es in der Ankündigung zum Kernel-Update und 
so wird es bleiben. Wenn jemand trotz installiertem neuen Kernel den 
alten bootet, dann gehe ich davon aus, dass er dazu einen guten Grund 
hat - weil nämlich der neue Probleme bereitet. Und dann wird der alte 
nicht abgeräumt.

Nö, ich möchte wirklich nicht alle Kernel, die abgeräumt werden, im 
Update abnicken lassen:

...
     for delfile in /boot/kernel-2.4.35-wt1 \
                    /boot/kernel-2.4.35-wt1-SMP \
                    /boot/kernel-2.6.32-PAE \
                    /boot/kernel-2.6.32-SMP \
                    /boot/kernel-2.6.32-VIRT \
                    /boot/initrd-2.4.35-wt1.gz \
                    /boot/initrd-2.4.35-wt1-SMP.gz \
                    /boot/initrd-2.6.32-PAE.gz \
                    /boot/initrd-2.6.32-SMP.gz \
                    /boot/initrd-2.6.32-VIRT.gz \
                    /System.map-2.4.35-wt1 \
                    /System.map-2.4.35-wt1-SMP \
                    /System.map-2.6.32-eisfair-1 \
                    /System.map-2.6.32-eisfair-1-PAE \
                    /System.map-2.6.32-eisfair-1-SMP \
                    /System.map-2.6.32-eisfair-1-VIRT \
                    /lib/modules/2.2.19 \
                    /lib/modules/2.4.26-1 \
                    /lib/modules/2.4.26-1-SMP \
                    /lib/modules/2.4.35-wt1 \
                    /lib/modules/2.4.35-wt1-SMP \
                    /lib/modules/2.6.32-eisfair-1 \
                    /lib/modules/2.6.32-eisfair-1-PAE \
                    /lib/modules/2.6.32-eisfair-1-SMP \
                    /lib/modules/2.6.32-eisfair-1-VIRT \
 
/usr/src/linux-2.4.26-1/24_kernel_ia32-and-x86_64-fix-fpu-state.patch.txt \
                    /usr/src/linux-2.4.26-1/connmark.patch \
                    /usr/src/linux-2.4.26-1/dot-config \
 
/usr/src/linux-2.4.26-1/ea+acl+nfsacl+sec-2.4.25-0.8.71.diff \
                    /usr/src/linux-2.4.26-1/Makefile \
                    /usr/src/linux-2.4.26-1 \
                    /usr/src/linux-2.4.35/Makefile \
                    /usr/src/linux-2.4.35/dot-config \
                    /usr/src/linux-2.4.35 \
                    /usr/src/linux-2.6.32-eisfair-1/dot-config \
                    /usr/src/linux-2.6.32-eisfair-1/dot-config-nonsmp \
                    /usr/src/linux-2.6.32-eisfair-1/Module.symvers-nonsmp \
                    /usr/src/linux-2.6.32-eisfair-1/dot-config-pae \
                    /usr/src/linux-2.6.32-eisfair-1/Module.symvers-pae \
                    /usr/src/linux-2.6.32-eisfair-1/dot-config-smp \
                    /usr/src/linux-2.6.32-eisfair-1/Module.symvers-smp \
                    /usr/src/linux-2.6.32-eisfair-1/dot-config-virt \
                    /usr/src/linux-2.6.32-eisfair-1/Module.symvers-virt \
                    /usr/src/linux-2.6.32-eisfair-1
     do
...

>> Hier gibst Du den Namen /dev/md1 vor, der aber im Raid selbst mit Homehost eis2 und Raidname data-raid1
>> definiert wurde. So etwas kann ich nicht korrigieren.
> ich muss den Namen vorgeben, weil beim Assembeln ansonsten der RAID-Name benutzt wird und es scheitert. Das
> Scheitern liegt mbMn am udevlosen eisfair. Da eisfair udevlos ist, sollte der eiskernel-installer nicht
> udevbenötigende Devicenamen in die /etc/mdadm.conf schreiben, sondern im Zweifel die bisherigen übernehmen.
> Wie das sinnvoll gemacht implementiert werden kann, kann ich selber gerade nicht nennen, daher ist es
> lediglich meine grundsätzliche Meinung dazu... ggf. ändere ich den Raid-Namen und gut is...

Siehe oben. Die mit dem Installer erstellten Raids haben keinerlei 
Probleme - auch ohne udev. Und wo in unserer Dokumentation ist 
beschrieben, man solle dem Raid einen Namen verpassen?

-- 
der tom
[eisfair-team]


Mehr Informationen über die Mailingliste Eisfair