RAID inaktiv

[Crys]

Hallo miteinander,

ich habe neue SAS-Kontroller in mein NAS verbaut und seitdem geht ein RAID nicht mehr.
Das RAID md2 (auch mit denselben Kontrollern angeschlossen) geht noch wie zuvor, das RAID md1 nicht mehr.
System: Ubuntu 16

Es werden die "md"-Partitionen nicht mehr angezeigt:

# lsblk
sdn
└─sdn1   linux_raid_member 
sdc           
└─sdc1   linux_raid_member
  └─md2  ext4
[...]

Das RAID wird aber gefunden:

# sudo mdadm --examine --scan
ARRAY /dev/md/2  metadata=1.2 UUID=e1a68a14:[...] name=uNAS:2
ARRAY /dev/md/1  metadata=1.2 UUID=affd9b87:[...] name=ChrisXu:1

Das steht auch in der "/etc/mdadm/mdadm.conf" drinnen.

# mount -a
mount: /dev/sda1 is already mounted or /media/freigaben busy

Der Ordner ist beliebig, daran liegt es nicht.

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md2 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      5860260736 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/22 pages [0KB], 65536KB chunk

md1 : inactive sda1[0](S) sde1[8](S) sdg1[5](S) sdf1[6](S) sdm1[4](S) sdi1[9](S) sdn1[7](S) sdl1[3](S) sdh1[1](S)
      26371173532 blocks super 1.2

unused devices: <none>

# mdadm -A /dev/md0 /dev/sdf1 /dev/sdm1 /dev/sdi1 /dev/sdg1 /dev/sde1 /dev/sdn1 /dev/sdl1 /dev/sda1 /dev/sdh1
mdadm: /dev/sdf1 is busy - skipping
mdadm: /dev/sdm1 is busy - skipping
mdadm: /dev/sdi1 is busy - skipping
mdadm: /dev/sdg1 is busy - skipping
mdadm: /dev/sde1 is busy - skipping
mdadm: /dev/sdn1 is busy - skipping
mdadm: /dev/sdl1 is busy - skipping
mdadm: /dev/sda1 is busy - skipping
mdadm: /dev/sdh1 is busy - skipping

# mdadm --detail /dev/md*
mdadm: /dev/md does not appear to be an md device
/dev/md1:
        Version : 1.2
     Raid Level : raid0
  Total Devices : 9
    Persistence : Superblock is persistent

          State : inactive

           Name : ChrisXu:1
           UUID : affd9b87:548927b4:e4849a4c:f9502eb5
         Events : 61217

    Number   Major   Minor   RaidDevice

       -       8        1        -        /dev/sda1
       -       8      209        -        /dev/sdn1
       -       8      193        -        /dev/sdm1
       -       8      177        -        /dev/sdl1
       -       8      129        -        /dev/sdi1
       -       8      113        -        /dev/sdh1
       -       8       97        -        /dev/sdg1
       -       8       81        -        /dev/sdf1
       -       8       65        -        /dev/sde1
/dev/md2:
        Version : 1.2
  Creation Time : Sat Jan 27 19:49:22 2018
     Raid Level : raid5
     Array Size : 5860260736 (5588.78 GiB 6000.91 GB)
  Used Dev Size : 2930130368 (2794.39 GiB 3000.45 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Thu Jan  6 18:12:31 2022
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           Name : uNAS:2  (local to host uNAS)
           UUID : e1a68a14:bd8f0e50:39b788bf:a9b462fd
         Events : 131284

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       3       8       49        2      active sync   /dev/sdd1

Und das kuriose ist, wenn die SATA-Anschlüsse umstecke, auf die alten Kontroller, neu starte, dann wird das RAID md1 wieder einwandfrei gefunden.

Wie bekomme ich mein RAID wieder zum Laufen?

Vielen Dank.

 

[PHuV]

Blöde Frage für mich: Ändern sich die UUIDs der Datenträger, wenn man sie an einen anderen Controller hängt? Die sollten doch nach reiner Lehre gleich bleiben, oder?

 

[Crys]

Blöde Frage für mich: Ändern sich die UUIDs der Datenträger, wenn man sie an einen anderen Controller hängt?

Die UUID sind alle gleich geblieben, da habe ich abgeglichen

 

[kieleich]

es scheint ja im mdstat auf

also ist versucht worden das zusammen zu bauen

was steht dann zu diesem vorgang im journalctl dmesg

ansonsten lieber --examine statt --detail letzteres ist bei Problemen, eher wert los

wenn du von Hand ein mdadm --assemble machen möchtest geht das nur wenn du das Array aus dem mdstat --stop sonst busy!

bei der gelegenheit auch mal smartctl checken!!

 

[Crys]

Vielen Lieben Dank @kieleich, du hast mir den Abend gerettet!

In journalctl konnte ich nichts finden, smartctl ist auch alles ohne Befund.
"mdstat --stop" und dann erst mdstat -A ... das war die Lösung!