[raid] Server boot niet meer na extra HDD in raid1/5 arrays

[geez]

edit: Inmiddels is duidelijk dat initrd faalt omdat mdadm de raid1 voor / niet assembled, en dat het root device daarom niet bestaat. Zie ook 3 posts lager.

Mijn server (Debian Wheezy amd64), met hiervoor 3x 1.5TB WD Green, heeft een upgrade gekregen met een extra 2TB WD Green.

Ik heb met

code:

sfdisk -d /dev/sda | sfdisk /dev/sdc

de partitietable gekloond van één van de bestaande disks naar de nieuwe (de nieuwe was sdc). Hierna de partitietable gecontroleerd, dit werkte prima. 500GB ongebruikte ruimte achteraan natuurlijk, maar dat is geen probleem.

Het root filesystem is raid1, klein volume van zo'n 5GB. Ik heb de corresponderende partitie toegevoegd aan de array:

code:

mdadm /dev/md0 -a /dev/sdc1

Dit was natuurlijk snel klaar (cat /proc/mdstat)

Vervolgens heb ik de tweede, grote, partitie toegevoegd aan md1, voor /home:

code:

mdadm /dev/md1 -a /dev/sdc2

Dit duurde heel lang zoals te verwachten, maar zag er goed uit aan het eind:

code:

databeest:/# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md1 : active raid5 sda2[0] sdc2[3] sdd2[2] sdb2[1]
      4368153600 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md0 : active raid1 sda1[0] sdc1[3] sdd1[2] sdb1[1]
      7815488 blocks [4/4] [UUUU]

Een blik in dmesg leverde echter het volgende op (melding over inodes):

code:

databeest:/# dmesg | tail -n 10
[  232.492222] md: using 128k window, over a total of 1456051200k.
[107933.179643] md: md1: reshape done.
[107934.397273] RAID conf printout:
[107934.397277]  --- level:5 rd:4 wd:4
[107934.397280]  disk 0, o:1, dev:sda2
[107934.397282]  disk 1, o:1, dev:sdb2
[107934.397283]  disk 2, o:1, dev:sdd2
[107934.397285]  disk 3, o:1, dev:sdc2
[107934.397292] md1: detected capacity change from 2981992857600 to 4472989286400
[107934.678997] VFS: busy inodes on changed media or resized disk md1

Omdat ik de nieuwe grootte ook niet terug zag met df -h:

code:

databeest:/# df -h
Filesystem                                              Size  Used Avail Use% Mounted on
rootfs                                                  7.4G  4.1G  2.9G  59% /
udev                                                     10M     0   10M   0% /dev
tmpfs                                                   176M  456K  176M   1% /run
/dev/disk/by-uuid/125d7c8c-0ae8-4955-b78d-f69778e45a22  7.4G  4.1G  2.9G  59% /
tmpfs                                                   5.0M     0  5.0M   0% /run/lock
tmpfs                                                   1.1G     0  1.1G   0% /run/shm
/dev/md1                                                2.7T  2.6T   77G  98% /home

heb ik toen voor de zekerheid gereboot. Toen bleek dat ik niet meer kon booten. initrd faalt met de melding dat de device voor het root filesystem niet gevonden kan worden:

code:

Gave up waiting for root device. Common problems:
-knip-
ALERT! /dev/disk/by-uuid/125d7c8c-0ae8-4955-b78d-f69778e45a22 does not exist. Dropping to shell!

Een snelle test laat inderdaad zien dat hij niet liegt:

code:

ls /dev/disk/by-uuid
674aaa..... d4668...... aa2799.....

Deze symlinks verwijzen naar /dev/sda3, /dev/sdb3, /dev/sdd3, wat de swap partities zijn. /dev/sdc mist hier dus. Dit suggereert dat een update-initramfs / update-grub nodig is?

Deze machine staat voor mij op afstand, en ik probeer hem nu te repareren met iemand op locatie die weinig van Linux af weet. Iemand ideeën om uit te vinden wat hier aan de hand is?

edit: Als ik nu naar de output van df -h kijk, vraag ik me ook af waarom niet /dev/md0 als / gemount is, maar dat UUID? Dat heeft vast iets te maken met manier van assembly van de mdadm arrays op boot, maar is de raid1 dan wel correct functioneel?

[ Voor 6% gewijzigd door geez op 18-03-2015 20:46 ]

[Hero of Time]

Nu ben ik ook niet zo bekend met mdadm e.d., maar is je file system ook vergroot toen je het mdadm -a commando draaide? Als ik wat zoek op Google, krijg ik http://www.nmmm.nu/raid2.htm als resultaat terug. Hoewel dit over ext3 gaat en mogelijk een oudere versie van mdadm, laat 't wel zien dat je mogelijk een paar stappen hebt overgeslagen. Het vergroten van het file system is iig een belangrijke stap.

Dat je je disk-by-uuid niet ziet, heeft er mee te maken dat mdadm die nog niet geïnitialiseerd heeft. Zoals je ook aangeeft, zie je alleen de ongewijzigde schijven/array. Heb je echt geen mogelijkheid tot remote shell via IPMI (HP iLO, Dell iDRAC, oid)? Dit oplossen over de telefoon is niet zo 1-2-3 gedaan.

[geez]

Het lijkt erop dat je gelijk hebt in het geval van de raid5 /home array. Maar / is een raid1 array, het filesystem hoeft dus niet resized te worden. Zodra ik weer / heb en ssh kan starten ben ik al een stuk verder

Als het filesystem niet resized is, zou de grootte niet gewoon als kleiner zichtbaar blijven (zoals gebeurde voor de reboot)?

Helaas geen opties voor remote console..

[ Voor 28% gewijzigd door geez op 18-03-2015 16:48 ]

[CAPSLOCK2000]

Ik zou fstab aanpassen om /dev/md0 te mounten ipv zo'n UUID. UUID is soms handig maar kan ook een hoop gedoe opleveren. Dan 'update-initramfs -u -k all' draaien. De catch-22 is dat je dan wel eerst op het root fs moet komen. Lukt het je om dat met de hand te mounten?

[geez]

Ik kwam hierop: How to use the initramfs shell to save the day. Deze persoon heeft een vergelijkbare setup, echter met LVM. Ik zie zijn eerste melding (Assembling all MD arrays ... mdadm: No devices listed in conf file were found.) niet, maar wel de tweede (Gave up waiting for root device).

code:

(initramfs) cat /etc/mdadm/mdadm.conf
DEVICE partitions
HOMEHOST <system>
ARRAY /dev/md0 level=raid1 num-devices=3 UUID=128d2fb3:0dffebf3:fc127180:dfe179cf
ARRAY /dev/md1 level=raid5 num-devices=3 UUID=0156bc9b:5593fd9c:2272c86d:dcfb8bbc

num-devices=3?

Wat me een optie leek om / gemount te krijgen is met mdadm --assemble --scan, maar dat levert niets op (geen enkele output). Ik weet niet waarom, ik wacht nog even op output van mdadm --detail --scan. edit: Dit levert ook geen output op. Vreemd?

In /dev/ staan wel alle /dev/sda1 t/m /dev/sdd3 devices netjes. Maar ze staan dus niet allemaal in /dev/disk/by-uuid. In /dev/disk/by-path e.d. staan ze wel allemaal.

code:

(initramfs) blkid
/dev/sdb1: UUID="128d2fb3-0dff-ebf3-fc12-7180dfe179cf" TYPE="linux_raid_member"
/dev/sdb2: UUID="0156bc9b-55930fd9c-2272-c86ddcfb8bbc" TYPE="linux_raid_member"
/dev/sdb3: UUID="aa27990d-7328-4cde-a043-fc203ccbd541" TYPE="swap"
/dev/sda1: UUID="128d2fb3-..." TYPE="linux_raid_member"
/dev/sda2: UUID="0156bc9b-..." TYPE="linux_raid_member"
/dev/sda3: UUID="d4668b5c-..." TYPE="swap"
/dev/sdc1: UUID="128d2fb3-..." TYPE="linux_raid_member"
/dev/sdc2: UUID="0156bc9b-..." TYPE="linux_raid_member"
/dev/sdd1: UUID="128d2fb3-..." TYPE="linux_raid_member"
/dev/sdd2: UUID="0156bc9b-..." TYPE="linux_raid_member"
/dev/sdd3: UUID="674aaa1d-..." TYPE="swap"

Oke. Alle eerste en tweede partities respectievelijk hebben allemaal hetzelfde UUID. De identieke UUIDs zijn blijkbaar normaal. De swap partities hebben allemaal een andere UUID, ook normaal. De swap partitie van sdc, sdc3, mist. De UUID's van de 3 swap partities corresponderen met degene in /dev/disk/by-uuid. Dit lijkt dus allemaal te kloppen.

Teruggaand naar de UUID waar de initramfs over klaagt als root fs, dat is een UUID die hier nergens tussen staat en dus als het goed is die van md0 zoals bedoeld. De key lijkt dus te liggen in het assemblen van md0. Dit kan misschien handmatig als volgt:

code:

mdadm --assemble --update=summaries  /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1

[ Voor 18% gewijzigd door geez op 18-03-2015 20:51 ]

[Hero of Time]

Volgens mij krijg je alleen een disk-by-uuid als er een bruikbaar file system op staat. Omdat het om RAID arrays gaat, is de identifier voor sda1, sdb1 etc eentje waar geen file system op staat. Voor een RAID1 is dat uiteindelijk wel het geval en zou je 'm handmatig kunnen mounten door 't fs te specificeren (heb ik eerder eens gedaan met een ext3 schijf uit een NAS, jaren terug).

Assembly is hoe dan ook nodig, als je geen /dev/md* entries hebt.

Waarom je voor mdadm schijven liever de dev node van /dev/md0 zou willen gebruiken, ipv het UUID vind ik wat apart. We hebben hier in NOS recentelijk nog iemand gehad die juist problemen ermee had, z'n array werd spontaan md127.

Persoonlijk had ik nog LVM over het array gezet, voor wat meer flexibiliteit. Maar goed, dat kan ook weer extra complexiteit opleveren.

[geez]

Omdat de arrays inclusief mdx nummer in /etc/mdadm/mdadm.conf gespecificeerd zijn zouden ze in principe niet moeten veranderen. Maar ik begrijp je punt. Je punt over UUIDs is ook duidelijk, dat is ook wat ik ervan begrepen had om dat juist de raid partitities niet onder by-uuid staan.

Mijn grootste issue momenteel is dat ik in tegenstelling tot die persoon waar ik naar linkte, geen enkele output krijg bij mdadm commando's onder initramfs. Iemand enig idee waarom?

Dank voor de suggesties dusverre beiden

edit: Zou het een idee zijn om een Ubuntu live disk te starten (hoewel ik nu ook gevonden heb dat Debian inmiddels live images aanbiedt), de de raid1 te assemblen, chroot, en dan update-initramfs draaien? Of gaat dat niet werken vanaf Ubuntu komend? Een collega denkt dat dat OK is maar ik wil graag een 2e mening want ik wil de half werkende initramfs niet slopen

Die num-devices=3 in /etc/mdadm/mdadm.conf lijkt me een probleem. Waarschijnlijk had ik

code:

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

moeten draaien en dan update-initramfs.

We hebben nu geprobeerd:

code:

(initramfs) mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/md0 has been started with 4 drives.
(initramfs) cat /proc/mdstat
Personalities: [raid1]
md0 : active (auto-read-only) raid1 sda1[0] sdc1[3] sdd1[2] sdb1[1]
      7815488 blocks [4/4] [UUUU]

Dit werkt dus (read only, wordt hij automatisch read-write geremount later?)

code:

(initramfs) ls /dev/disk/by-uuid/
125d7c8c-0ae8-4955-b78d-f69778e45a22
plus de 3 swap partitites uiteraard.
(initramfs) exit
- systeem boot! -

Ingelogd, en vervolgens:

code:

databeest~# mount -n -o remount /
databeest~# mount

Laat zien dat / inderdaad read-write gemount is. Een blik in /etc/mdadm/mdadm.conf levert op dat beide arrays daarin staan als num-devices=3. Deze file hebben we aangepast zodat er nu num-devices=4 staat. Vervolgens:

code:

databeest~# mdadm --assemble /dev/md1
mdadm: /dev/md1 has been started with 4 drives.
databeest~# cat /proc/mdstat
md1: active raid5 sda2[0] sdc2[3] sdd2[2] sdb2[1]
      xxxxxx blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md0: ..... zoals verwacht

[ Voor 105% gewijzigd door geez op 19-03-2015 11:33 ]

[Hero of Time]

Dus, opgelost neem ik aan? En weer wat geleerd natuurlijk.

[geez]

Nog niet helemaal. Ik zit in de maintenance shell (Give root password for maintenance (or type Control-D to continue)), en daarom (denk ik?) is update-initramfs niet beschikbaar, net als update-grub e.d. Moet ik eerst deze shell exiten om boot af te maken, weer inloggen en dan update-initramfs uitvoeren?

Mijn typhulp is even weg dus vanmiddag meer Een hoop geleerd inderdaad, meteen wat bijgelezen over initramfs, wat man pages, etc

Todo:

code:

- update-initramfs -u -k all
- grub-install /dev/sdc
- mdadm --readwrite /dev/md1
- e2fsck -f /dev/md1 -C 0
- resize2fs /dev/md1 -p
- e2fsck -f /dev/md1 -C 0
- Rebooten en hopen dat alles weer werkt :)

Eerste e2fsck geen problemen (kostte een paar uur), resize en mount:

code:

resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/md1 to 1092038400 (4k) blocks.
Begin pass 1 (max = 11109)
Extending the inode table     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/md1 is now 1092038400 blocks long.

code:

databeest:/# df -h
Filesystem                                              Size  Used Avail Use% Mounted on
rootfs                                                  7.4G  4.1G  2.9G  59% /
udev                                                     10M     0   10M   0% /dev
tmpfs                                                   176M  568K  176M   1% /run
/dev/disk/by-uuid/125d7c8c-0ae8-4955-b78d-f69778e45a22  7.4G  4.1G  2.9G  59% /
tmpfs                                                   5.0M     0  5.0M   0% /run/lock
tmpfs                                                   1.1G     0  1.1G   0% /run/shm
/dev/md1                                                4.1T  2.6T  1.4T  65% /home

2e e2fsck ook goed afgelopen. Voor reboot heb ik eerst de initrd bekeken, om te kijken of de /etc/mdadm/mdadm.conf daar nu in klopt. Om de initrd uit te pakken:

code:

zcat /boot/initrd.img-3.2.0-4-amd64 | cpio -i

Dit klopte, vervolgens reboot, helemaal goed!

Opgelost dus Dank voor de hulp. 1.5 dag downtime, nieuw record in bijna 5.5 jaar

[ Voor 90% gewijzigd door geez op 19-03-2015 20:22 ]