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

[Stefan Welte]

Hallo Thomas,

Am 02.03.2015 um 21:42 schrieb Thomas Bork:
>> Zur Chronologie: Anfang 2014 war RAID1 mit metadate 0.9
> 
> Selbst erstellt oder von unserem Installer?
selbst erstellt.
Gibt es einen extra-Raid-Installer oder meinst du den eisfair-Installer?
Ich habe den eisfair-Installer seit ca. 10 Jahren nicht mehr benutzt. Wie bereits in vor...vorigem Posting
erzählt:
> zuerst war es ein reines (Spass-)Daten-Raid1. Irgendwann war mir /var, /public, /tmp zu stark am zunehmen
> an Datenmenge, da habe ich es von / ausgegliedert auf das Raid1.
Da /var darauf ist, mache ich Raid-Änderungen meist mit ungebootetem eisfair im Livelinuxsystem
grml-small-2012.05.

>> Mitte 2014: eiskernel -> 2.4.3
> 
> Kernel-Update und Raid wurde erkannt und gestartet?
soweit ich erinnere war das ein Wechsel von 2.4.1,2.4.2, die problemlos waren. Wie der Umstieg von 2.4.35
auf 2.6 verlief kann ich mich nicht mehr erinnern, könnte aber sein, daß in der NG noch was zu finden ist...

>> Anfang 2015: RAID1 Neubau mit metadata 1.2, initrd(2.4.3) zurechtgezimmert
> 
> Wie genau womit gebaut? Was wurde in initrd gemacht?
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.
initrd: Lediglich ändern von Textdateien linuxrc (/sbin/raidautorun... durch /sbin/mdadm... ersetzt),
mdadm.conf und kopieren von Binärprogramm mdadm.

>> Anfang 2015: eiskernel -> 2.8.0 -> Ich hatte keine Möglichkeit, den eiskernel-Installer 2.4.3 mit einem
>> RAID1-metadata 1.2 zu benutzen.
> 
> eisfair-1-Installer mit base 2.3.4, eiskernel 2.4.3 hat aber schon Metadata 1.2 unterstützt.
nicht deswegen, sondern weil am 15. Januar 2015 n.Chr. eiskernel 2.4.3 mit der Package-Suchfunktion nicht zu
finden war.

>> das ist richtig, das Raid1 läuft unter /dev/md1 laut /proc/mdstat, aber "mdadm -Es" liefert 
>> /dev/md/data-raid1 statt /dev/md1
> 
> mdadm liest aus, wie das Raid ursprünglich erstellt wurde. Das kann ich nicht korrigieren.
> Wahrscheinlich musst Du den Namen korrigieren. Aber hier kommt auch noch der Homehost in's Spiel, wenn
> das Raid fremderstellt ist...
ich kann den Namen korrigieren.
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.

> Der stabile Kernel ist 2.8.0. Wenn ich die Altlasten nicht entsorgen würde, hätte niemand mehr Platz in 
> /boot und /.
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.

>> *ALT: ARRAY /dev/md/data-raid1  metadata=1.2 UUID=f44e039c:45ea2cec:725660e2:18851785
>> name=eis2:data-raid1 *NEU: ARRAY /dev/md1  metadata=1.2 UUID=f44e039c:45ea2cec:725660e2:18851785
>> name=eis2:data-raid1
> 
> 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...

Gruss,
Stefan