2010-03-09 09:55:18 +0000 2010-03-09 09:55:18 +0000
31
31

Hoe krijg ik een inactief RAID apparaat weer aan de praat?

Na het booten, gaat mijn RAID1 apparaat (/dev/md_d0 *) soms in een rare toestand en kan ik het niet mounten.

* Oorspronkelijk had ik /dev/md0 aangemaakt, maar het heeft zichzelf op de een of andere manier veranderd in /dev/md_d0.

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail or so

Het RAID apparaat lijkt op de een of andere manier inactief te zijn:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

Vraag is, hoe maak ik het apparaat weer actief (met behulp van mdmadm, neem ik aan)?

(Andere keren is het in orde (actief) na het booten, en kan ik het handmatig mounten zonder problemen. Maar hij wil nog steeds niet automatisch mounten, ook al heb ik hem in /etc/fstab staan:

/dev/md_d0 /opt ext4 defaults 0 0

Dus een bonus vraag: *wat moet ik doen om het RAID apparaat automatisch te laten mounten op /opt tijdens het opstarten? * )

Dit is een Ubuntu 9.10 werkstation. Achtergrondinformatie over mijn RAID-installatie in deze vraag] (https://superuser.com/questions/101630/creating-a-raid1-partition-with-mdadm-on-ubuntu).

Edit : Mijn /etc/mdadm/mdadm.conf ziet er zo uit. Ik heb dit bestand nooit aangeraakt, althans niet met de hand.

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

In /proc/partitions is de laatste entry md_d0 althans nu, na reboot, als het apparaat toevallig weer actief is. (Ik weet niet zeker of het hetzelfde zou zijn als het inactief is.)

Oplossing : zoals Jimmy Hedman voorstelde , ik nam de uitvoer van mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

en toegevoegd aan /etc/mdadm/mdadm.conf, wat het hoofdprobleem verholpen lijkt te hebben. Na het veranderen van /etc/fstab om weer /dev/md0 te gebruiken (in plaats van /dev/md_d0), wordt het RAID apparaat ook automatisch gemount!

Antwoorden (9)

25
25
25
2010-03-10 12:34:08 +0000

Voor je bonusvraag:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf
11
11
11
2011-08-01 02:41:23 +0000

Ik heb ondervonden dat ik de array handmatig moet toevoegen in /etc/mdadm/mdadm.conf om Linux hem te laten mounten bij reboot. Anders krijg ik precies wat jij hier hebt - md_d1-apparaten die inactief zijn enz.

Het conf-bestand zou er uit moeten zien zoals hieronder - d.w.z. een ARRAY regel voor elk md-apparaat. In mijn geval ontbraken de nieuwe arrays in dit bestand, maar als u ze wel heeft staan is dit waarschijnlijk geen oplossing voor uw probleem.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Voeg een array per md-apparaat toe, en voeg ze toe na het commentaar hierboven, of als zo'n commentaar niet bestaat, aan het eind van het bestand. U krijgt de UUID’s door sudo mdadm -E --scan te doen:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Zoals u kunt zien, kunt u de uitvoer van het scan-resultaat vrijwel gewoon in het bestand kopiëren.

Ik draai ubuntu desktop 10.04 LTS, en voor zover ik me herinner verschilt dit gedrag van de server versie van Ubuntu, maar het was zo lang geleden dat ik mijn md-apparaten op de server aanmaakte dat ik het mis kan hebben. Het kan ook zijn dat ik gewoon een optie gemist heb.

Hoe dan ook, het toevoegen van de array in de conf-file lijkt de truc te doen. Ik heb de bovenstaande raid 1 en raid 5 al jaren zonder problemen draaien.

7
7
7
2012-03-21 22:21:47 +0000

Waarschuwing: Allereerst wil ik zeggen dat het onderstaande (vanwege het gebruik van “–force”) mij riskant lijkt, en als u onherstelbare gegevens hebt, raad ik u aan kopieën te maken van de betrokken partities voordat u begint met het proberen van een van de dingen hieronder. Dit werkte echter voor mij.

Ik had hetzelfde probleem, met een array die als inactief werd weergegeven, en niets wat ik deed, inclusief de “mdadm –examine –scan >/etc/mdadm.conf”, zoals door anderen hier voorgesteld, hielp ook maar iets.

In mijn geval, toen hij de RAID-5 array probeerde te starten na een schijfvervanging, zei hij dat hij vuil was (via dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Waardoor hij als inactief in /proc/mdstat tevoorschijn kwam:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Ik ontdekte dat alle apparaten dezelfde gebeurtenissen hadden, behalve de schijf die ik had vervangen (/dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

De array-details lieten echter zien dat er 4 van de 5 apparaten beschikbaar waren:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number Major Minor RaidDevice State
       0 8 4 0 inactive dirty /dev/sda4
       2 8 36 2 inactive dirty /dev/sdc4
       3 8 52 3 inactive dirty /dev/sdd4
       5 8 68 4 inactive dirty /dev/sde4

(Het bovenstaande is uit mijn geheugen op de “State” kolom, ik kan het niet terugvinden in mijn scroll-back buffer).

Ik kon dit oplossen door de array te stoppen en dan opnieuw te assembleren:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

Op dat moment was de array in bedrijf, met 4 van de 5 apparaten, en kon ik het vervangende apparaat toevoegen en het opnieuw opbouwen. Ik heb toegang tot het bestandssysteem zonder enig probleem.

5
5
5
2012-04-24 01:29:43 +0000

Ik had problemen met Ubuntu 10.04 waar een fout in FStab verhinderde dat de server kon opstarten.

Ik voerde dit commando uit zoals vermeld in de bovenstaande oplossingen:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Dit zal de resultaten van “mdadm –examine –scan” toevoegen aan “/etc/mdadm/mdadm.conf”

In mijn geval was dit:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

Dit is een fakeraid 0. Mijn commando in /etc/fstab voor automatisch mounten is:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

Het belangrijkste hier is dat je “nobootwait” en “nofail” hebt. Nobootwait slaat alle systeemberichten over die je verhinderen om op te starten. In mijn geval was dit op een externe server, dus was het essentieel.

Hoop dat dit sommige mensen helpt.

2
2
2
2010-03-09 10:46:27 +0000

U kunt uw md apparaat activeren met

mdadm -A /dev/md_d0

Ik veronderstel dat een of ander opstartscript te vroeg start, voordat een van de RAID leden ontdekt was of een soortgelijk probleem. Als een snelle en vuile workaround, zou je deze regel moeten kunnen toevoegen aan /etc/rc.local :

mdadm -A /dev/md_d0 && mount /dev/md_d0

Bewerk : blijkbaar bevat je /etc/mdadm/mdadm.conf nog steeds de oude configuratienaam. Bewerk dit bestand en vervang de voorkomende namen van md0 door md_d0.

2
2
2
2011-08-15 01:56:27 +0000

Ik had een soortgelijk probleem… mijn server wilde md2 niet mounten nadat ik de gekoppelde devices partities had gekweekt. Toen ik deze thread las, ontdekte ik dat het md2 RAID apparaat een nieuwe UUID had en dat de machine de oude probeerde te gebruiken.

Zoals voorgesteld… gebruik makend van ‘md2’ uitvoer van

mdadm --examine --scan

Ik bewerkte /etc/mdadm/mdadm.conf en verving de oude UUID regel door de uitvoer van bovenstaand commando en mijn probleem ging weg.

2
2
2
2010-03-10 13:14:14 +0000

md_d0 : inactive sda4[0](S) ziet er verkeerd uit voor een RAID1 array. Het lijkt te suggereren dat de array geen actieve apparaten heeft en één reserve apparaat (aangegeven door de (S), je zou daar (F) zien voor een defect apparaat en niets voor een OK/actief apparaat) - voor een RAID1 array die niet degraded draait zouden er minstens twee OK/actieve apparaten moeten zijn (en voor een degraded array, minstens één OK/actief apparaat) en je kunt geen RAID1 array activeren zonder niet-failed niet-spare apparaten (aangezien spares geen kopie van de data bevatten totdat ze actief worden gemaakt wanneer een andere schijf faalt). Als ik die /proc/mdstat uitvoer goed lees, kun je de array in zijn huidige staat niet activeren.

Zijn er fysieke schijven in de machine die er niet in geslaagd zijn om op te starten? Toont ls /dev/sd* alle schijven en partities die je normaal op die machine zou verwachten?

2
2
2
2012-11-26 21:43:18 +0000

Als je doet alsof je iets doet met /dev/md[012346789} gaat het naar /dev/md{126,127...}./dev/md0 blijft gemount op /dev/md126 of /dev/md127 moet je:

umount /dev/md127of umount /dev/md126.

Dit is tijdelijk om je commando’s en sommige applicaties te laten uitvoeren zonder je systeem te stoppen.

2
2
2
2017-02-14 23:24:17 +0000

Een eenvoudige manier om de array aan de praat te krijgen, ervan uitgaande dat er geen hardwareprobleem is en dat je genoeg drives/partities hebt om de array te starten, is het volgende:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20 --run

Het kan zijn dat om wat voor reden dan ook de array in orde is, maar dat iets verhinderde dat hij kon starten of opbouwen. In mijn geval was dit omdat mdadm niet wist dat de oorspronkelijke naam van de array md127 was en alle drives waren losgekoppeld voor die array. Bij het opnieuw aansluiten moest ik handmatig assembleren (waarschijnlijk een bug waarbij mdadm dacht dat de array al actief was vanwege de offline oude array naam).