(Ubuntu) Opnieuw MDADM installatie na OS DISk defect

[Maxximus]

Na een stroomstoring is me voeding en achteraf ook mijn OS Disk gecrashed.

Nieuwe HD erin Ubuntu er op geïnstalleerd.

RAID schrijven zijn zover ik kan zien nog goed en werken.

Nu probeer ik mijn raid config weer aan de praat te krijgen maar gaat niet heel erg lekker.

Heb deze pagina gevolgd (https://ubuntuforums.org/showthread.php?t=1648922) maar kom niet verder.

Ik probeer deze code

code:

sudo mdadm --assemble  /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sdde

maar krijg dan deze foutmelding
mdadm: /dev/sdb has no superblock - assembly aborted

Deze oplossing geprobeerd en nog steeds dezelfde melding

code:

mdadm --zero-superblock /dev/sdb
mdadm --zero-superblock /dev/sdb1

https://ubuntuforums.org/showthread.php?t=1947275

[Neopatch]

Kun je eens het volgende proberen?

code:

sudo mdadm --assemble --scan

[Maxximus]

Dan krijg ik

code:

mdadm: Devices UUID-ff7f2e8a:f85fa249:af3f34cf:954723a3 and UUID-ff7f2e8a:f85fa249:af3f34cf:954723a3 have the same name: /dev/md/0_0
mdadm: Duplicate MD device names in conf file were found.

Regel stond 2x in de mdadm.conf deze verwijderd.
maar nog steeds dezelfde foutmelding.

[Neopatch]

Maxximus schreef op woensdag 21 december 2016 @ 09:01:
Dan krijg ik

code:

mdadm: Devices UUID-ff7f2e8a:f85fa249:af3f34cf:954723a3 and UUID-ff7f2e8a:f85fa249:af3f34cf:954723a3 have the same name: /dev/md/0_0
mdadm: Duplicate MD device names in conf file were found.

Regel stond 2x in de mdadm.conf deze verwijderd.
maar nog steeds dezelfde foutmelding.

Je hebt ze alle twee verwijderd? Heb je backup van die file gemaakt? Volgens mij moet je de tweede uitzetten (#) en de eerste laten staan. Een disk kan namelijk niet deel uitmaken van twee arrays.

[Maxximus]

nee 1tje maar

[Neopatch]

Als je er nu ééntje in de mdadm.conf hebt staan en hij assembled nog niet dan moet je een andere foutmelding krijgen neem ik aan?

[Maxximus]

helaas nog steeds dezelfde foutmelding

code:

maxximus@NASMaxximus:/$ sudo mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sdde
mdadm: Cannot assemble mbr metadata on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted

[Neopatch]

Ook als je die scan uitvoert? Want nu doe je weer wat je eerst deed zegmaar.

code:

sudo mdadm --assemble --scan

[Maxximus]

dan krijg ik dit

code:

maxximus@NASMaxximus:/$ sudo mdadm --assemble --scan
[sudo] password for maxximus:
maxximus@NASMaxximus:/$

[Neopatch]

Maxximus schreef op woensdag 21 december 2016 @ 10:18:
dan krijg ik dit

code:

maxximus@NASMaxximus:/$ sudo mdadm --assemble --scan
[sudo] password for maxximus:
maxximus@NASMaxximus:/$

Dus geen foutmelding? Hij zou eigenlijk een bericht moeten geven met hoeveel disks de array is assembled. Je kunt de status bekijken van je array met

code:

sudo mdadm --detail /dev/md0

Mocht alles correct zijn dan kan je hem mounten

code:

sudo mount /dev/md0 /mnt/x

waar x de map is waar je hem op mount

[Maxximus]

krijg

code:

maxximus@NASMaxximus:/$ sudo mdadm --detail /dev/md0
mdadm: cannot open /dev/md0: No such file or directory

[Neopatch]

Maxximus schreef op woensdag 21 december 2016 @ 10:29:
krijg

code:

maxximus@NASMaxximus:/$ sudo mdadm --detail /dev/md0
mdadm: cannot open /dev/md0: No such file or directory

Heet ie toevallig md127 ipv md0 ?

[BoAC]

Heb je gekeken welke md-devices er nu zijn in /proc/mdstat?

code:

cat /proc/mdstat

[Maxximus]

beide (zowel md0 als md127) krijg ik zelfde melding

code:

maxximus@NASMaxximus:/$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>

[Neopatch]

Maxximus schreef op woensdag 21 december 2016 @ 10:40:
beide (zowel md0 als md127) krijg ik zelfde melding

code:

maxximus@NASMaxximus:/$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>

Om er achter te komen welke md het is zou je ook even het volgende kunnen doen

code:

ls /dev/md + tab

Hiermee zou de aanwezige md zichtbaar moeten worden en vervolgens kan je die checken met --detail en daarna mounten zoals ik hierboven heb aangegeven.

[Maxximus]

Er is geen md

code:

maxximus@NASMaxximus:/$ sudo ls /dev/m
mapper/           mcelog            mem               memory_bandwidth  mqueue/
maxximus@NASMaxximus:/$ sudo ls /dev/m

[BoAC]

Heb je deze al doorgenomen: https://raid.wiki.kernel.org/index.php/RAID_Recovery ?

Ik denk dat deze je verder gaat helpen:

code:

mdadm --examine /dev/sd[bcdefghijklmn]1 >> raid.status

[Maxximus]

ja maar ik loop volgens mij tegen het probleem aan dat er geen superblok is

code:

maxximus@NASMaxximus:/dev$ sudo -i
root@NASMaxximus:~# mdadm --examine /dev/sd[bcdefghijklmn]1 >> raid.status
mdadm: No md superblock detected on /dev/sdb1.
mdadm: No md superblock detected on /dev/sdc1.
mdadm: No md superblock detected on /dev/sdd1.
mdadm: No md superblock detected on /dev/sde1.
root@NASMaxximus:~#

[BoAC]

Welke partities zijn er aanwezig op je disks? Of staan er zelfs geen partities op en heb je gewoon de disks zelf gebruikt in het array?

Misschien helpt deze je op weg: Recovering mdadm superblocks

Heb je toevallig dit gedaan op 1 of meer disks?

code:

mdadm --zero-superblock /dev/sd*

* = diskletter

Misschien heb je ook wel dit probleem: Software raid - mdadm - re-find my array

[ Voor 18% gewijzigd door BoAC op 21-12-2016 11:50 ]

[Maxximus]

BoAC schreef op woensdag 21 december 2016 @ 11:45:
Welke partities zijn er aanwezig op je disks? Of staan er zelfs geen partities op en heb je gewoon de disks zelf gebruikt in het array?

root@NASMaxximus:~# sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 37.3G 0 disk
├─sda1 8:1 0 487M 0 part /boot
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 36.8G 0 part
├─NASMaxximus--vg-root 252:0 0 35G 0 lvm /
└─NASMaxximus--vg-swap_1 252:1 0 1.8G 0 lvm [SWAP]
sdb 8:16 0 1.4T 0 disk
└─sdb1 8:17 0 1.4T 0 part
sdc 8:32 0 1.4T 0 disk
└─sdc1 8:33 0 1.4T 0 part
sdd 8:48 0 1.4T 0 disk
└─sdd1 8:49 0 1.4T 0 part
sde 8:64 0 1.4T 0 disk
└─sde1 8:65 0 1.4T 0 part

Heb je toevallig dit gedaan op 1 of meer disks?

code:

mdadm --zero-superblock /dev/sd*

* = diskletter

code:

root@NASMaxximus:~# sudo mdadm --zero-superblock /dev/sda
mdadm: Couldn't open /dev/sda for write - not zeroing

Misschien heb je ook wel dit probleem: Software raid - mdadm - re-find my array

nee want daar bestaat sda wel en bij mij niet

[BoAC]

Ik zeg niet dat je het moet uitvoeren
Die situatie kan natuurlijk wel van toepassing zijn op jouw situatie (alleen andere schijven)

[Sleepkever]

Aangezien je --assemble --scan goed is gegaan heb je ergens een raid device...
Kijk eens waar je device is gebleven met

code:

cat /proc/mdstat
mdadm --detail --scan

En wees alsjeblieft voorzichtig met alles uitvoeren, als er hier gevraagd word of je iets gedaan hebt moet je niet alsnog lukraak dat commando gaan uitvoeren en al je raid data wissen van schijven

Je maakt het jezelf daarmee erg moeilijk. Aangezien je je superblock op aan het begin hebt sdb hebt gezeroed zul je even moeite moeten doen om die terug te krijgen als dat daadwerkelijk een schijf was in je raid vroeger. Grote kans dat die driverletters na je reinstall ook verschoven zijn namelijk!

Welke raid level was dit trouwens? RAID5?

En even opletten

code:

mdadm --examine /dev/sd[bcdefghijklmn]1 >> raid.status

werkt niet voor jou door die 1 erachter, je hebt je raid superblock op de disk staan ipv op de eerste partitie.
Voer nog eens uit maar dan min de 1 op het eind en post het resultaat nog eens

[ Voor 19% gewijzigd door Sleepkever op 21-12-2016 12:46 ]

[Hero of Time]

Met de mensen hierboven. Je gaat niet zomaar lukraak zooi uitvoeren zonder te weten wat het doet. Uit de manpage van mdadm:

code:

--zero-superblock
If the device contains a valid md superblock, the block is overwritten with zeros. With --force the block where the superblock would be is overwritten even if it doesn't appear to be valid.

Dit is dus wel het aller, allerlaatste wat je uit moet voeren op (een schijf van) een array.

[Maxximus]

Sorry niet goed gekeken.

code:

maxximus@NASMaxximus:/dev$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
maxximus@NASMaxximus:/dev$

code:

maxximus@NASMaxximus:/dev$ sudo mdadm --detail --scan
maxximus@NASMaxximus:/dev$

[Hero of Time]

En wat geeft die --examine nou?

[Maxximus]

code:

root@NASMaxximus:~# mdadm --examine /dev/sd[bcdefghijklmn]1 >> raid.status
mdadm: No md superblock detected on /dev/sdb1.
mdadm: No md superblock detected on /dev/sdc1.
mdadm: No md superblock detected on /dev/sdd1.
mdadm: No md superblock detected on /dev/sde1.

[Sleepkever]

Maxximus schreef op woensdag 21 december 2016 @ 14:30:

code:

root@NASMaxximus:~# mdadm --examine /dev/sd[bcdefghijklmn]1 >> raid.status
mdadm: No md superblock detected on /dev/sdb1.
mdadm: No md superblock detected on /dev/sdc1.
mdadm: No md superblock detected on /dev/sdd1.
mdadm: No md superblock detected on /dev/sde1.

En dan nog eens zonder de 1 aan het eind?

[Maxximus]

code:

root@NASMaxximus:~# mdadm --examine /dev/sd[bcdefghijklmn] >> raid.status
root@NASMaxximus:~#

[BoAC]

En wat staat er nu in raid.status?

[Maxximus]

/dev/sdb:
MBR Magic : aa55
Partition[0] : 2930272002 sectors at 63 (type fd)
/dev/sdc:
MBR Magic : aa55
Partition[0] : 2930272002 sectors at 63 (type fd)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 2930277167 sectors at 1 (type ee)
/dev/sde:
MBR Magic : aa55
Partition[0] : 2930272064 sectors at 1 (type fd)

[BoAC]

Hier een goede uitleg van iemand die waarschijnlijk met hetzelfde probleem zat als jij nu hebt:
http://superuser.com/ques...creation-of-array-does-it

Ik raad wel aan om eerst images te trekken van je disks.. maar dat zal moeilijk zijn als je geen andere disks hebt. Let ook op het level (-l) wat je had voordat je gewoon gegeven commando's overtypt

[Maxximus]

okay,

even voor de zekerheid

Data gaat niet verloren hier mee?

2e

code:

lsmod | grep 'raid1\s'
grep 'Personalities : .*\[raid1\]' /proc/mdstat

Hier maak ik raid5 van

code:

sudo modprobe raid1

ook hier raid 5

code:

sudo mdadm --create /dev/md0 -n 2 -l 1 /dev/sdc /dev/sdd

En dit wordt dan

code:

sudo mdadm --create /dev/md0 -n 4 -l 5 /dev/sdb /dev/sdc /dev/sdd /dev/sde

[Hero of Time]

Create? Terwijl er in je raid.status al staat dat er een superblock aanwezig is. Lijkt mij eerder assemble dan create in dit geval.

[Sleepkever]

Met --create maak je een nieuwe array aan en die zal alle data die al op de disks stond overschrijven. Niet de handigste optie dus.


Interessant om te zien dat je 3x partition type FD hebt en een keer EE, na wat googlen kom ik hier op.
[quote]ee Indication that this legacy MBR is followed by an EFI header[/quote] Het zou dus kunnen zijn dat grub iets naars op een van je disks heeft gedaan? Volgens mij gaat die hier normaal wel redelijk goed mee om dus beetje gek is het wel...

Wat als je nu
[code]sudo mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sde[/code] uitvoert? Dan zal je array wel maar gebouwd worden vanuit 3 disks en dus degraded zijn maar dan kom je in ieder geval wel weer bij je data.

Nevermind, normaal hoor je met --examine je superblock data te zien, maar gezien je die heel stom in het begin gewist hebt ga je nu een nieuwe hel in. En aangezien er geen enkele superblock meer over is ga je ook niet kunnen vinden met wat voor chunk/stripe size de array is aangemaakt, data offsets, etc. Ik hoop dat je nog een backup van je data hebt want ik denk dat je dit redelijk als verloren kan beschouwen en je het beste gewoon overnieuw kan beginnen.

[ Voor 24% gewijzigd door Sleepkever op 21-12-2016 16:13 ]

[BoAC]

Zoals je in mijn laatste link kunt zien is er een kans dat het array netjes wordt opgebouwd en de data terug te halen is. De kans acht ik zeer zeer klein omdat het geen mirror is...
Mijn advies is dat je eerst images trekt van de disks voordat je verder gaat rommelen.

Als eerste (na de backup) zou ik echter gaan kijken of je met force de assemble kunt forceren omdat je de superblocks hebt gesloopt.

[Thralas]

BoAC schreef op woensdag 21 december 2016 @ 16:41:
Zoals je in mijn laatste link kunt zien is er een kans dat het array netjes wordt opgebouwd en de data terug te halen is. De kans acht ik zeer zeer klein omdat het geen mirror is...

Waarom zou dat met een RAID5 anders zijn?

Ik denk dat je dit prima kunt recoveren, mits je de array op exact dezelfde wijze opnieuw aanmaakt. De data is immers niet weg, noch zegt een nieuw superblock iets over de geldigheid van reeds 'aanwezige' data (dat onderscheid kan hij helemaal niet maken).

Volgens mij kan dat alles in theorie zelfs nog met pen en papier, want aan de inhoud van de disks kun je de chunk size en parity format ook wel afleiden.

Mijn advies is dat je eerst images trekt van de disks voordat je verder gaat rommelen.

Dit. Want volgens mij duwt TS hierboven bijna z'n array van het randje van de afgrond zo 't ravijn in.

Volgens de handleiding doet md namelijk een resync na het creëren van een array, tenzij je --assume-clean meegeeft. Als je niet exact dezelfde RAID format hanteert dan vermoed ik dat md vrolijk nieuwe blocks gaat wegschrijven om alles weer 'kloppend' te maken. Dan ben je niet alleen van je superblocks verlost, maar ook nog eens van 1/n van je data (effectief dus alles, want een puzzel leggen met 750 van de 1000 stukjes kan niet).

Als eerste (na de backup) zou ik echter gaan kijken of je met force de assemble kunt forceren omdat je de superblocks hebt gesloopt.

Dat lijkt me niet dus. Er valt niets te assemblen zonder superblock. Je moet eerst nieuwe metadata schrijven, al dan niet met --assume-clean.

Gezien TS' niet-heel briljante acties tot dusver weet ik niet helemaal hoe dit tot een goed einde komt. In theorie: stap 1 lijkt me om met dezelfde OS-versie als waarmee de array origineel was aangemaakt even een referentie-array bouwen, dan weet je in iedere geval zeker welke metadata version je had (dat maakt volgens mij ook uit voor de plek waar de superblock staat, dus lijkt me dat relevant).

Verder zegt mijn man page van mdadm dat de default chunk size 512k is. Krijg je die voor niets

Oh, en dezelfde disk-volgorde lijkt me ook van belang (want partity blocks staan verspreid over de disks).

[BoAC]

Thralas schreef op woensdag 21 december 2016 @ 21:11:
[...]


Waarom zou dat met een RAID5 anders zijn?

Oh, en dezelfde disk-volgorde lijkt me ook van belang (want partity blocks staan verspreid over de disks).

Vanwege het opbouwen van RAID5 zou het kunnen zijn dat vanwege de parity blocks de data vernaggeld gaat worden. Bij RAID1 (wat ook in het gelinkte artikel de gebruikte config is) is dat niet zo, dat is een volledige 1op1 kopie waardoor het terug krijgen van de data redelijk kansrijk is. Van de ene disk wordt namelijk een volledige kopie gemaakt op de andere disk waardoor je je data weer terug zal hebben

Verder ben ik het met je eens

[Hero of Time]

Ik ben niet super bekend met mdadm, maar gezien hij 4 schijven heeft, 1 is er sowieso 'blanco', zou het kunnen om z'n array te maken met een missende schijf, die de juiste index meegeven (dus disks 2, 3 en 4 zijn sdc, sdd en sde, missing is disk1 sdb), om dan later met een introduce oid sdb toe te voegen en hopen dat het goed gaat? Uiteraard is de backup het eerste wat gedaan wordt.

[Thralas]

Dat inderdaad, met de juiste volgorde (en de missing disk ook op de juiste plek). Anders staat niet alleen de data door elkaar, maar klopt de parity calculation ook niet meer.

[Demo]

Maxximus schreef op woensdag 21 december 2016 @ 14:56:
/dev/sdb:
MBR Magic : aa55
Partition\[0] : 2930272002 sectors at 63 (type fd)
/dev/sdc:
MBR Magic : aa55
Partition\[0] : 2930272002 sectors at 63 (type fd)
/dev/sdd:
MBR Magic : aa55
Partition\[0] : 2930277167 sectors at 1 (type ee)
/dev/sde:
MBR Magic : aa55
Partition\[0] : 2930272064 sectors at 1 (type fd)

Type FD is 'Linux RAID', dat lijkt me goed. Ik zie bij al mijn disks Type EE staan, waarschijnlijk omdat het GPT-disks zijn: Indication that this legacy MBR is followed by an EFI header
Je schijf sdd lijkt dus verkeerd te zijn gepartitioneerd. Zolang je de andere disks heel houdt, is er nog geen man overboord. Je moet even kijken naar de partitionering van sdd tov de andere 3 disks en dat gelijk trekken en dan mdadm --assemble --scan --force uitvoeren, dan zal hij de array in degraded mode starten. Dan zal sdd waarschijnlijk niet de array zitten (want geen superblock) en moet je de schijf opnieuw toevoegen en zal de data op de disk gerebuild worden.

Verder lijkt het me, zoals door meer mensen is genoemd, handig om je beter in te lezen/bewust te zijn van wat je aan het doen bent en niet klakkeloos commando's te copy/pasten. Het ene moment probeer je de array te starten op raw disks, terwijl je gepartitioneerde schijven gebruikt.

Thralas schreef op donderdag 22 december 2016 @ 00:10:
Dat inderdaad, met de juiste volgorde (en de missing disk ook op de juiste plek). Anders staat niet alleen de data door elkaar, maar klopt de parity calculation ook niet meer.

[afbeelding]

Dat maakt niet uit, de volgorde van de schijven staat keurig in de metadata.

[Hero of Time]

Demo schreef op donderdag 22 december 2016 @ 11:49:
[...]
Type FD is 'Linux RAID', dat lijkt me goed. Ik zie bij al mijn disks Type EE staan, waarschijnlijk omdat het GPT-disks zijn: Indication that this legacy MBR is followed by an EFI header
Je schijf sdd lijkt dus verkeerd te zijn gepartitioneerd. Zolang je de andere disks heel houdt, is er nog geen man overboord. Je moet even kijken naar de partitionering van sdd tov de andere 3 disks en dat gelijk trekken en dan mdadm --assemble --scan --force uitvoeren, dan zal hij de array in degraded mode starten. Dan zal sdd waarschijnlijk niet de array zitten (want geen superblock) en moet je de schijf opnieuw toevoegen en zal de data op de disk gerebuild worden.

Ik zou eigenlijk helemaal niet aan de partitietabel komen. Wat ik denk dat er met sdd aan de hand is, is dat deze toevallig de GPT indeling heeft ipv MBR en dat kan nog wel eens een andere identificatie opleveren maar zegt verders niets over hoe het er uiteindelijk uit ziet.

Zie o.a. een van mijn schijven:

code:

Parted:
Number  Start   End     Size    File system  Name    Flags
 1      1049kB  3001GB  3001GB  ext4         Terra3  msftdata

Fdisk:
Device     Start        End    Sectors  Size Type
/dev/sda1   2048 5860532223 5860530176  2.7T Microsoft basic data

Die flags 'msftdata' vind je alleen bij Windows systemen op Windows partities. En toch staat het op mijn ext4 partitie. Reden: GPT.

[Demo]

Goed punt. Eerst mdadm --assemble --scan --force en dan kijken welke disk er niet in de array zit en dan op je gemak uitzoeken hoe die disk weer in het gareel te krijgen is.

[CAPSLOCK2000]

Even voor de zekerheid, die afwijkende disk is toch niet per ongeluk je OS disk he? Pas op met de korte namen voor schijven (sda, sdb, etc), die kunnen veranderen. Wat voorheen sdb of sdd was kan na het vervangen van die OS-disk een andere naam hebben gekregen.

Verder zou 1 missende disk geen probleem moeten zijn, je gebruikt juist RAID5 om daar tegen te beschermen. Ook met drie disks zou de array dus moeten starten, is er misschien nog meer aan de hand?

[ Voor 27% gewijzigd door CAPSLOCK2000 op 22-12-2016 17:25 ]

[Thralas]

Demo schreef op donderdag 22 december 2016 @ 11:49:
Dat maakt niet uit, de volgorde van de schijven staat keurig in de metadata.

Ware het niet dat TS het volgende rapporteerde nadat --zero-superblock ten sprake kwam:

Maxximus in "(Ubuntu) Opnieuw MDADM installatie na OS DISk defect"

Hoewel hij dat nooit expliciet heeft bevestigd, suggereert bovenstaande dat hij alle superblocks heeft gewiped.

In dat geval kan die 'stukke' schijf nog wel nuttig zijn. Tenzij hij helemaal dood is zou ik daar 't superblock eens van printen/dumpen

& zeker weten? In de output van mdadm --examine zie ik namelijk alleen een array GUID en device count/number. Dus dan heb je alle superblocks in principe nodig.

[jbhc]

Maxximus schreef op woensdag 21 december 2016 @ 08:19:


Ik probeer deze code

code:

sudo mdadm --assemble  /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sdde

maar krijg dan deze foutmelding
mdadm: /dev/sdb has no superblock - assembly aborted

Deze oplossing geprobeerd en nog steeds dezelfde melding

code:

mdadm --zero-superblock /dev/sdb
mdadm --zero-superblock /dev/sdb1

https://ubuntuforums.org/showthread.php?t=1947275

Heb je wel al de stappen die je in dat topic hebt gezien herhaald met dezelfde uitkomst tot gevolg voordat je dit deed:

code:

mdadm --zero-superblock /dev/sdb
mdadm --zero-superblock /dev/sdb1

Begin anders eers eens met:

code:

sudo fdisk -l

[ Voor 4% gewijzigd door jbhc op 23-12-2016 22:13 ]