[Eisfair] [e1] Fehler nach update auf base v2.8.5 und eiskernel-smp v4.4.0

[Thomas Zweifel]

Hallo Marcus

Am 13.01.20 um 23:03 schrieb Marcus Röckrath:
> W. Loefstedt wrote:
> 
>> Allerdings haben sich die Bezeichnungen geändert:
> 
> Das haben wir ja gemerkt und dann die bisherigen Korrekturen vorgeschlagen.
> 
>> eisfair # cat /proc/mdstat
>> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
>> [raid4] [multipath]
>> md125 : active (auto-read-only) raid1 sda2[1] sdb2[0]
>>        2104448 blocks [2/2] [UU]
>>
>> md126 : active raid1 sda3[1] sdb3[0]
>>        75979328 blocks [2/2] [UU]
>>
>> md127 : active raid1 sda1[1] sdb1[0]
>>        64128 blocks [2/2] [UU]
>>
>> War mal /dev/md1, /dev/md2, /dev/md3
>>
>> Könnt Ihr mir das erklären?
> 
> Nein, mir erschließt es sich nicht, wieso bei die die Nummerierungen
> geändert sind.
> 
> Das erfordert aber nun noch weitere Korrekturen, wie z. B. in
> der /etc/lilo.conf für boot, sonst geht das nächste Kernelupdate nicht.

Womit sie dann für immer md1xx wären ;-)
Oder bis sie in der initrd korrigiert werden....

> Derr boot-Eintrag passt dort nicht mehr, wenn du von dem neuen Kernel aus
> ein Kernelupdates machen willst, da muss wohl md126 statt md1 rein.

md127


> Aber in Ruhe bevor man was zerschießt; übrigens ist Thomas Zweifel ziemlich
> fit mit RAID, vielleicht hat er eine Idee.

Leider nein!  Momentan habe ich auch nicht wirklich Zeit :-(


Aber ich werfe mal meine bisherigen Beobachtungen in die Runde:

Ende Oktober wurden fremd-raids beim booten zusammengebaut (md127 abwärts)
Auch frisch erstellte md (kein kernel-Update, die UUID in der mdadm.conf 
hinterlegt) wurden zu md127...

Eine Korrektur meiner 'zweiten raid-assemble Runde' 
(/etc/init.d/raid-init) hats gerichtet:

eis2 2.8.23 # cat /etc/init.d/raid-init
.....
#
## disassemble md's > 100
#
for md in `/bin/ls -1 /dev/md1[0-9][0-9] 2>/dev/null` ; do
   mdadm --stop $md
done
.....


Beim Update meiner Klonstation auf E64 und testen vom 4.9 kernel wurden 
md Aktionen nicht richtig finalisiert. (um Weinachten rum)

z.B. Raid5 von 3 auf 4 Partitionen erweitert:

eis2 2.8.23 # mdadm -G -n4 /dev/md56
mdadm: Need to backup 768K of critical section..

Nach erfolgtem Reshape:

eis2 2.8.23 # pvcreate /dev/md56
   Physical volume "/dev/md56" successfully created.

eis2 2.8.23 # vgextend dare /dev/md56
   WARNING: scan found duplicate PVID oIIKxFjo10fPYAfGElsZnR1R9nGnnmuK 
on /dev/sde6
   Volume group "dare" successfully extended

eis2 2.8.23 # pvscan --cache
   WARNING: scan found duplicate PVID oIIKxFjo10fPYAfGElsZnR1R9nGnnmuK 
on /dev/sde6
   pvscan[4905] PV /dev/md56 online.
   pvscan[4905] PV /dev/md57 online.

eis2 2.8.23 # pvscan
   WARNING: scan found duplicate PVID oIIKxFjo10fPYAfGElsZnR1R9nGnnmuK 
on /dev/sde6
   PV /dev/md57   VG dare            lvm2 [120.84 GiB / 70.84 GiB free]
   PV /dev/md56   VG dare            lvm2 [149.97 GiB / 149.97 GiB free]
   Total: 2 [270.81 GiB] / in use: 2 [270.81 GiB] / in no VG: 0 [0   ]

eis2 2.8.23 # vgreduce dare /dev/md56
   WARNING: scan found duplicate PVID oIIKxFjo10fPYAfGElsZnR1R9nGnnmuK 
on /dev/sde6
   Removed "/dev/md56" from volume group "dare"

eis2 2.8.23 # mdadm --stop /dev/md56
mdadm: stopped /dev/md56

eis2 2.8.23 # mdadm -As
mdadm: Fail create md56 when using /sys/module/md_mod/parameters/new_array
mdadm: /dev/md56 has been started with 4 drives.

eis2 2.8.23 # pvscan
   PV /dev/md57   VG dare            lvm2 [120.84 GiB / 70.84 GiB free]
   PV /dev/md56                      lvm2 [150.00 GiB]
   Total: 2 [270.84 GiB] / in use: 1 [120.84 GiB] / in no VG: 1 [150.00 GiB]

eis2 2.8.23 # vgextend dare /dev/md56
   Volume group "dare" successfully extended

Nach einem Neustart des md oder verkleinern der md-Komponentengrösse vor 
dem Reshape und anschliessend wieder Vergrössern, wurde das neu 
hinzugefügte Device als Raid-Member erkannt und vom LVM wie angewiesen 
ignoriert.

Dasselbe, wenn eine Partition entfernt wurde (--fail / --remove) und 
durch eine neue ersetzt wurde (--add), bot sich dasselbe Verhalten.



Gestern hatte ich ein Raid5 auf drei USB-Sticks erstellt und auf meinem 
Backup (E64 base 2.8.20, kernel 3.16.70) Eingestöpselt --> Die Sticks 
wurden eingebunden, aber kein md zusammengebaut - Wie erwartet.

Auf der Klon-Station (E64 aktueller Stand) hingegen wird beim einstecken 
des ersten Stick das md angeworfen:

md21 : inactive sdg1[2](S)
       524224 blocks

beim zweiten Stick:

md21 : inactive sdh1[1](S) sdg1[2](S)
       1048448 blocks

und beim dritten ist es dann komplett zusammengebaut und aktiv:

md21 : active raid5 sdi1[0] sdh1[1] sdg1[2]
       1048448 blocks level 5, 4k chunk, algorithm 2 [3/3] [UUU]


Auch fdisk fungiert als trigger:

eis2 # grep md58 /proc/mdstat
md58 : active raid5 sdc8[2] sdd8[4] sdb8[1] sdf8[3] sde8[0]

eis2 # mdadm --stop /dev/md58
mdadm: stopped /dev/md58

eis2 # fdisk /dev/sdb
Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): q

eis2 # grep md58 /proc/mdstat
md58 : inactive sdb8[1](S)



Ich hoffe ihr könnt damit was anfangen. :-)




Gruss Thomas