linux software raid1: md0 veranderde spontaan naar md124

[Verwijderd]

Ik word er gek van...
Weer een nieuw probleem.
Een van de machines met centos 5.10 draait in software raid1 (twee gelijkgrote harddisks)
Het raidsysteem functioneerde normaal, md0, md1, md2, md3 aanwezig en te zien in fdisk, evenals de schijven /dev/sda# en /dev/sdb#.
Ik had geboot met mijn net gebrande GParted live cd - en ALLEEN DINGEN BEKEKEN, NIETS VERANDERD - en nu wil de raid machine niet meer booten en zegt 'kernel panic' en nog meer lelijks.
Als ik boot met een live cd en fdisk -l doe, blijken md0 t/m md3 veranderd te zijn in md124 t/m md127. Ik denk dat ie daarom niet wil booten.
Hoe verander ik e.e.a. weer terug?
Ik heb het al een keer eerder gehad, het is toen blijkbaar weer goed gekomen, alleen weet ik niet hoe ik het gefikst heb (niet onmogelijk: misschien heeft het zichzelf gefikst).

Ik snap trouwens niet, dat zulke kritische dingen automagisch kunnen veranderen en daardoor een systeem lam leggen. Is het een werkverschaffings-maatregel voor computertechnici???

[Kees]

Gebruik UUID's in plaats van devicenamen, die zijn er voor om deze problemen te voorkomen. Waarschijnlijk doen ze dat al (is de default bij heel veel distro's) en gaat er wat anders mis. Welke kernel panic krijg je?

Je boot overigens niet met je originele systeem, dus of md0-3 op je eigen systeem ook anders zijn is nog maar de vraag, grote kans dat je livecd een nieuwere kernel aan boord heeft en die gebruiken inderdaad md12x om een of andere reden.

[ Voor 3% gewijzigd door Kees op 21-09-2014 16:54 ]

[Verwijderd]

De live cd waarmee ik in mijn beginpost bootte, was een linux mint 13 live cd.

Nu dus weer geboot met het systeem zelf:
de tekst in beeld:
RedHat nash version 5.1.19.6 starting
EXT3-fs: unable to read superblock
mount: error mounting /dev/root on /sysroot as ext3: Invalid argument
setuproot: mounting /dev failed: no such file or directory
setuproot: error mounting /proc: no such file or directory
setuproot: error mounting /sys: no such file or directory
switchroot: mount failed: no such file or directory
Kernel panic - not syncing: Attempt to kill init!
- (=knipperende cursor)
op het keyboard knipperen de lampjes 'caps lock' en 'scroll lock'

de boot stopt op dat punt.

daarna heb ik geboot met de eerste install-cd van centos 5.10, en gekozen voor 'rescue' en voor 'linux rescue'.
dan krijg ik na het scherm met 'looking for centos installations' een scherm met:
'an error occured trying to mount some or all of your system
some of it may be mounted under /mnt/sysimage'

wanneer ik in /mnt/sysimage kijk is daar NIETS aanwezig.

als ik op de opdrachtregel 'fdisk -l' doe, krijg ik het DEELS normale overzicht van de twee schijven en hun partities:
de disk /dev/sda
de partities /dev/sda1 t/m /dev/sda5 met voor elk de waarden die ik ook zag toen het systeem nog liep;
de disk /dev/sdb
de partities /dev/sdb1 t/m /dev/sdb3
dan daartussen geworpen een paar regels die op de verkeerde plaats staan:
'disk /dev/md125 does'nt contain a valid partition table
disk /dev/md127 does'nt contain a valid partition table
disk /dev/md124 does'nt contain a valid partition table'
daaronder de resterende lijst van partities /dev/sdb4 en /dev/sdb5.
daar weer onder /dev/md124 t/m /dev/md127, met waarden die zijn als toen het systeem goed werkte.
het probleem is blijkbaar dat het niet md0 t/m md3 zijn.

wanneer ik op de opdrachtregel 'cat /proc/mdstat' geef, krijg ik een lijstje wat in orde is, behalve weer de md-nummering.
als ik 'mdadm --detail /dev/md124' intoets, krijg ik de goede waarden, behalve dat de 'preferred minor' 124 is.
voor md125, md126 en md127 hetzelfde verhaal.

en nu de klapper!
als ik /dev/md125 als ext3 mount op een gecreeerd mountpoint (md125 is de '/' directory), is de inhoud van '/' zichtbaar, en daarbij valt op dat sommige directories onverklaarbaar LEEG zijn:
namelijk: dev, proc, srv, sys.
Drie daarvan komen overeen met de meldingen in het 'kernel panic' gedeelte!!

Bij dit alles valt me in dat ik een soortgelijk probleem met lege directories ook eerder had (een paar weken terug) toen mijn raidsysteem naar de filistijnen was, ik weet het toen aan het moederbord (is nu nieuw, met processor en ram).
Ik was toen alleen maar in staat de schade te herstellen door alle data (wel toegankelijk door de betreffende partities in de rescue modus met de hand te mounten) weg te kopieren, toen centos 5.10 opnieuw te installeren en te configureren als raid1 en de data terug te spelen.
Een bijna eeuwig durend proces (veeeeeeel data, traag naar en van een usb2 externe disk).

Vraag: kan dit defect een centos 5.10 probleem zijn?
Ik had het raid systeem ongewijzigd (behalve de halfautomatische software-updates) sinds 2011 aan het lopen. Zou het kunnen dat de laatste kernel update van centos de problemen veroorzaakt???

[jbhc]

Kon je met de mint livecd de boel eerst wel benaderen en zo ja nu nog steeds?

Met een beetje googelen kom ik al snel hier:

http://www.sysresccd.org/...viewtopic.php?f=4&p=11814

[ Voor 41% gewijzigd door jbhc op 21-09-2014 21:29 ]

[Talisker_NL]

Heb je hier wat aan ? http://ubuntuforums.org/showthread.php?t=1764861

[Hero of Time]

als ik /dev/md125 als ext3 mount op een gecreeerd mountpoint (md125 is de '/' directory), is de inhoud van '/' zichtbaar, en daarbij valt op dat sommige directories onverklaarbaar LEEG zijn:
namelijk: dev, proc, srv, sys.
Drie daarvan komen overeen met de meldingen in het 'kernel panic' gedeelte!!

Verplicht leesvoer: Wikipedia: Filesystem Hierarchy Standard

Je moet wel snappen wat er aan de hand is en wat er gebeurt voordat je de boel kan herstellen. Zoals in je andere topics te merken is, schiet je regelmatig in 't donker en heb je geen enkel idee hoe je verder moet. Is niet erg, daar zijn wij dan weer voor om je een lichtje te geven, maar ik kan mij niet voorstellen dat je na jaren gebruik geen extra kennis van het systeem hebt opgedaan.

[Verwijderd]

jbhc schreef op zondag 21 september 2014 @ 21:27:
Kon je met de mint livecd de boel eerst wel benaderen en zo ja nu nog steeds?
Met een beetje googelen kom ik al snel hier:
http://www.sysresccd.org/...viewtopic.php?f=4&p=11814

Met de Mint live-cd van mijn eerste bericht heb ik alleen met 'fdisk -l' gekeken en toen de afwijkende md# benamingen gezien. Bedoel je met 'benaderen' de partities met de hand mounten en ernaar lezen/schrijven? Niet geprobeerd, maar ik denk het wel, want dat kan ik nu met de centos 5.10 install disk in rescue mode ook.
Ik zal vandaag proberen wat de Mint cd nu doet.
De goochel-link lees ik als: een al onderkend probleem bij het booten met een (alle??) system rescue cd(s). Raar dat zo'n rescue cd dan nooit meldt dat je bij het booten van een raidsysteem problemen gaat krijgen (en de oplossing ervoor aanbiedt).

Ik vind het wel raar dat niemand hier de drie lege directories (waar Kernel panic op stopte), en waarvan ik zag dat ze leeg waren, als probleem ziet..!
Bovendien: waardoor zijn die directories ineens leeg? Toch niet door een bootactie waarbij de bootloader zocht naar md0 t/m md3, md124 t/m md127 vond en daarop stopte!?

Ik ga er even van uit, dat wanneer ik de veranderde md-namen met behulp van de gelinkte tekst terug verander, het systeem wederom niet zal booten (ja, vanwege de 3 lege dirs)

[Verwijderd]

Hero of Time schreef op zondag 21 september 2014 @ 22:22:
Verplicht leesvoer:

Dat zou kunnen, maar wat helpt de info daarin me? Ik stelde vast dat bepaalde directories leeg zijn (geworden) en dat het booten daarop lijkt te stoppen.

maar ik kan mij niet voorstellen dat je na jaren gebruik geen extra kennis van het systeem hebt opgedaan.

Er zijn miljoenen mensen die niet weten waar de motor zit en toch al jaren autorijden.
Ik gebruik de computer voor een aantal taken (als werktuig) en kan simpele fouten bij de werking zelf herstellen. Waarom is dat een probleem?

[FireDrunk]

Als je het artikeltje had gelezen, had je begrepen dat /dev helemaal geen bestanden bevat, maar een speciale directory is, die gemount word door de kernel, waar fysieke devices in te vinden zijn....

Als je van een live-cd boot, word er een virtuele /dev gemaakt, en niet de /dev gebruikt die op jouw RAID array staat. Daarom is het dus logisch dat hij leeg is... (Datzelfde geld overigens voor /proc en /sys).

Punten waar je op moet letten:
MD# Nummer voorkeur staat in mdadm.conf, maar komt pas in je initrd als je die geüpdatet hebt. Let er dus op dat je na het updaten je initrd regenereert.

Wat misschien beter is, is om je /etc/fstab aan te passen zodat je / gemount word op UUID en niet op /dev/md Nummer, waardoor het booten altijd goed zal gaan.

Commando wat je moet gebruiken om het UUID van je MD array te vinden is blkid
Dat UUID zet je in /etc/fstab ipv /dev/md#

Zo'n entry word dus:

/dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee  /  ext4  defaults  0  0

Handleiding (van Microsoft nog wel ):
http://azure.microsoft.co...nes-linux-configure-raid/

[Pakjebakmeel]

Het probleem is (en dit heb ik ook gehad) is dat ik altijd netjes mijn MD's wil nummeren van 1 tm 3. Echter als ik boot van een Ubuntu Live CD dan veranderd de super-minor zoals je zelf aangeeft.*

*Wat ik overigens echt stupide vind.. LiveCD? Laat mn zooi met rust en mount het gewoon wil je..

Zodra je je echte OS boot kan ie je root, boot en swap niet mounten omdat de fstab verwijst naar de oude nummering. Een oplossing is om onder het LiveCD OS je arrays te assemblen met gebruik van de --update=super-minor optie.

Echter is het verstandiger je arrays te mounten op UUID, zo maakt het niets meer uit op welk device node ze terecht komen. Dit heb ik ook gedaan en sinds dien geen enkel probleem meer.

^^^ Zoals hierboven.. ^^^

Update super-minor: http://www.cyberciti.biz/...name-an-mdadm-raid-array/

UUID's bij mij zien er zo uit:

code:

gentoo ~ # cat /etc/fstab
UUID=035afafb-2e9b-4a57-9439-7ece158f04d9       /boot           ext4            defaults,noatime        1 2
UUID=ecb1e0e4-81c3-4d81-a96b-48cd39b2fffe       none            swap            sw                      0 0
UUID=c25c891a-10f4-403b-8449-66a75c1d1530       /               ext4            noatime                 0 1

proc                                            /proc           proc            defaults                0 0
shm                                             /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
hugetlbfs                                       /hugepages      hugetlbfs       defaults                0 0

En de nodes:

code:

gentoo ~ # ll /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root  9 Sep 18 10:50 035afafb-2e9b-4a57-9439-7ece158f04d9 -> ../../md1
lrwxrwxrwx 1 root root 11 Sep 18 10:50 9A18716818714473 -> ../../zd0p2
lrwxrwxrwx 1 root root 11 Sep 18 10:50 B41870FA1870BCC4 -> ../../zd0p1
lrwxrwxrwx 1 root root  9 Sep 18 10:50 c25c891a-10f4-403b-8449-66a75c1d1530 -> ../../md3
lrwxrwxrwx 1 root root  9 Sep 18 10:50 ecb1e0e4-81c3-4d81-a96b-48cd39b2fffe -> ../../md2

Aanvullend, als je je fstab wilt wijzigen vanuit een live cd moet je handmatig partities mounten en een chroot uitvoeren. Daarna je fstab aanpassen en je bootloader updaten. Hier zijn vast wel handleidingen voor te vinden voor je betreffende distributie.

[ Voor 64% gewijzigd door Pakjebakmeel op 22-09-2014 08:38 ]

[Verwijderd]

FireDrunk schreef op maandag 22 september 2014 @ 08:24:
Als je het artikeltje had gelezen, had je begrepen dat /dev helemaal geen bestanden bevat, maar een speciale directory is, die gemount word door de kernel, waar fysieke devices in te vinden zijn....

In mijn ogen zei ik dat de /dev leeg was, het ging tussen leeg of met iets erin. Wat er precies in staat ben ik niet zo nieuwsgierig naar.

Als je van een live-cd boot, word er een virtuele /dev gemaakt, en niet de /dev gebruikt die op jouw RAID array staat. Daarom is het dus logisch dat hij leeg is... (Datzelfde geld overigens voor /proc en /sys).

Ik heb net het bewuste centos raidsysteem nog maar eens geboot, weer van de Mint13 live cd.
Als ik op de desktop een terminal screen open en 'cd /' intoets, krijg ik een reeks van dirs te zien, o.a. dev, sys en proc. Alledrie zijn echt niet leeg!

Commando wat je moet gebruiken om het UUID van je MD array te vinden is blkid
Dat UUID zet je in /etc/fstab ipv /dev/md#
Zo'n entry word dus:

/dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee  /  ext4  defaults  0  0

Dat gaat in ieder geval niet onder de Mint13 live-cd: fdisk -l geeft wel de twee raidschijven sda en sdb (en de partities erin), maar niet md#. Ook het commando mdadm kent de opdrachtregel niet.

[Verwijderd]

jbhc schreef op zondag 21 september 2014 @ 21:27:
Kon je met de mint livecd de boel eerst wel benaderen en zo ja nu nog steeds?

Met de Mint13 livecd geboot, kan ik met fdisk -l enkel de twee raid schijven zien (sda en sdb), niet md#.
Ik kan alle partities van zowel sda als sdb (afzonderlijk) mounten.
Wanneer ik dat doe voor sda2 resp. sdb2 (mijn / in het raidsysteem) zie ik in de inhoud o.a. dev, sys en proc. Het zijn mappen die gemaakt zijn op 5 sept. j.l. (op die dag na de vorige gelijksoortige crash door mij een nieuwe installatie van centos 5.10 en de raid1 configuratie gedaan).
En wat zit er in dev, sys en proc (op de raiddisks dus!)? niets!
Na de install die ik op 5 sept. deed zat er wel wat in!
Dit is hetzelfde wat ik bij de crash van begin september eerder had.

[u_nix_we_all]

Verwijderd schreef op maandag 22 september 2014 @ 12:12:
[...]

Met de Mint13 livecd geboot, kan ik met fdisk -l enkel de twee raid schijven zien (sda en sdb), niet md#.
Ik kan alle partities van zowel sda als sdb (afzonderlijk) mounten.
Wanneer ik dat doe voor sda2 resp. sdb2 (mijn / in het raidsysteem) zie ik in de inhoud o.a. dev, sys en proc. Het zijn mappen die gemaakt zijn op 5 sept. j.l. (op die dag na de vorige gelijksoortige crash door mij een nieuwe installatie van centos 5.10 en de raid1 configuratie gedaan).
En wat zit er in dev, sys en proc (op de raiddisks dus!)? niets!
Na de install die ik op 5 sept. deed zat er wel wat in!
Dit is hetzelfde wat ik bij de crash van begin september eerder had.

Nogmaals, lees je eens in in wat die directories zijn en doen.
Die dingen (/dev /proc en /sys) zijn leeg, en worden pas bevolkt door de kernel als het systeem start.

[FireDrunk]

Als het commando mdadm niet werkt, heb je een Live CD gepakt waar geen MD support ingebakken zit. In dat geval zou ik er toch voor kiezen om een Live CD van een andere distro te gebruiken. (wat overigens helemaal niet betekend dat je moet switchen ofzo hoor, ik heb ook wel eens een Gentoo installatie gerepareerd met een Ubuntu live CD...).

Van de Ubuntu Live CD weet ik in ieder geval dat hij MDADM ondersteund, waarmee je dus zeer waarschijnlijk wel een /dev/md* device krijgt.

[u_nix_we_all]

Of in je live-cd even mdadm en lvm tools installeren, ook zo gebeurd (hoewel je dan vaak ook een update moet draaien, dat kan wel iets langer duren)

[Verwijderd]

u_nix_we_all schreef op maandag 22 september 2014 @ 12:23:
Die dingen (/dev /proc en /sys) zijn leeg, en worden pas bevolkt door de kernel als het systeem start.

Goed, als jij dat zo duidelijk zegt is dat okay.
Het gaat er dus alleen nog om het systeem te starten.
En dat zou ie dan moeten doen wanneer md124 tot md127 weer md0 tot md3 heten?

[u_nix_we_all]

Ik denk dat de handigste manier om dit te herstellen idd is om eerst ze weer md0 t/m md3 te nummeren. Dit doe je dan door in de /etc/mdadm.conf de sets weer de juiste namen te geven.
En als dat weer werkt, het zaakje omzetten naar UUID's in die file. Daarbij moet je dan ook je initrd updaten.

[Pakjebakmeel]

Verwijderd schreef op maandag 22 september 2014 @ 12:32:
[...]

Goed, als jij dat zo duidelijk zegt is dat okay.
Het gaat er dus alleen nog om het systeem te starten.
En dat zou ie dan moeten doen wanneer md124 tot md127 weer md0 tot md3 heten?

Jup, ik vermoed dat de fstab de root niet kan mounten omdat /dev/md3 niet bestaat.

u_nix_we_all schreef op maandag 22 september 2014 @ 13:27:
Ik denk dat de handigste manier om dit te herstellen idd is om eerst ze weer md0 t/m md3 te nummeren. Dit doe je dan door in de /etc/mdadm.conf de sets weer de juiste namen te geven.
En als dat weer werkt, het zaakje omzetten naar UUID's in die file. Daarbij moet je dan ook je initrd updaten.

Inderdaad, hernoemen om weer bootable te worden. Dan hoef je je partities niet te mounten en niet te chroot'en om grub te updaten. Als je eenmaal geboot bent omzetten naar UUID's en grub updaten om te voorkomen dat dit weer gebeurt.

Ik heb inderdaad ook meedere malen Ubuntu Live gebruikt voor een gentoo installatie. Tegenwoordig zit MDADM geloof ik ook in de gentoo minimal.

[Verwijderd]

Tsja, het is allemaal toch niet zo eenduidig...

Vandaag het raidsysteem geboot van de centos 5.10 installatie cd nr. 1 (heeft mdadm aan boord), dan 'rescue' en 'linux rescue'. Ik zit dan in de rescue mode.
De bestaande centos installatie wordt niet gevonden, wordt dus ook niet gemount onder /mnt/sysimage.
Op de command line ingeven van fdisk -l toont beide raiddisks sda en sdb en hun partities, en md124 t/m md127
Als ik opgeef 'mdadm --detail /dev/md0' krijg ik de melding dat device md0 'does not appear to be active'.
Als ik opgeef 'mdadm --detail /dev/md124 (evenzo 125,126 en 127) krijg ik wel en een goed overzicht van de betreffende partitie. Alles goed, enkel de preferred minor niet (komt overeen met het nummer van md#).
Wanneer ik md125 mount, de map die / bevat, kan ik naar /etc gaan en daar mdadm.conf bekijken. De aanmaakdatum van die file is weer 5 september, erin staan md0 t/m md3 elk ook met hun UUID (!). De mdadm.conf file lijkt me dus in orde te zijn.
Wanneer ik op diezelfde mount naar /etc ga en fstab bekijk (ook fstab heeft als datum 5 september) staan ook in fstab md0 t/m md3. Dat lijkt me ook in orde.

Conclusie: ik kan mdadm.conf niet veranderen, omdat ie al goed is.
Voor fstab hetzelfde verhaal.

Als ik reboot, de cd verwijder en met het systeem zelf start, krijg ik weer dezelfde Kernel panic van eerst.
Dus??

[FireDrunk]

FireDrunk schreef op maandag 22 september 2014 @ 08:24:
Als je het artikeltje had gelezen, had je begrepen dat /dev helemaal geen bestanden bevat, maar een speciale directory is, die gemount word door de kernel, waar fysieke devices in te vinden zijn....

Als je van een live-cd boot, word er een virtuele /dev gemaakt, en niet de /dev gebruikt die op jouw RAID array staat. Daarom is het dus logisch dat hij leeg is... (Datzelfde geld overigens voor /proc en /sys).

Punten waar je op moet letten:
MD# Nummer voorkeur staat in mdadm.conf, maar komt pas in je initrd als je die geüpdatet hebt. Let er dus op dat je na het updaten je initrd regenereert.

Wat misschien beter is, is om je /etc/fstab aan te passen zodat je / gemount word op UUID en niet op /dev/md Nummer, waardoor het booten altijd goed zal gaan.

Commando wat je moet gebruiken om het UUID van je MD array te vinden is blkid
Dat UUID zet je in /etc/fstab ipv /dev/md#

Zo'n entry word dus:

/dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee  /  ext4  defaults  0  0

Handleiding (van Microsoft nog wel ):
http://azure.microsoft.co...nes-linux-configure-raid/

Om mijzelf maar even te quoten...

Wat ik dus al zeg: verander je /etc/fstab en zet er in dat hij niet / moet mounten vanaf /dev/md0(of w/e) maar van een UUID.

[Pakjebakmeel]

FireDrunk schreef op dinsdag 23 september 2014 @ 12:50:
[...]

Om mijzelf maar even te quoten...

Wat ik dus al zeg: verander je /etc/fstab en zet er in dat hij niet / moet mounten vanaf /dev/md0(of w/e) maar van een UUID.

Loopt hij dan niet stuk omdat je grub ook eerst moet updaten? Niet echt veel ervaring met grub(2), ik gebruik voornamelijk lilo.

In ieder geval, als je alleen de preffered minor wilt updaten hoef je hem helemaal niet te mounten! Je moet:

- Uitzoeken welke partitie wat is (laat ons de 3 mdadm --details zien)
- Even je fstab posten
- De UUID's van de arrays achterhalen door middel van blkid. (Weet niet of deze gelijk zijn aan de ID's van mdadm namelijk)
- Preferred minors updaten (we kunnen je helpen met de commando's als we bovenstaande info hebben)

Als je systeem weer op is fstab bewerken en Mount en op UUID en grub updaten.

Als een grub update niet nodig is is firedrunk's oplossing het makkelijkste en tevens permanent:

Mount de root partitie en bewerk de fstab. Vervang de /dev/MD[0,1,2] entries voor UUID= entries. Dit is sowieso verstandig en veel robuuster!

Je fstab moet er dus ongeveer zo uit gaan zien:

code:

gentoo ~ # cat /etc/fstab
UUID=035afafb-2e9b-4a57-9439-7ece158f04d9       /boot           ext4            defaults,noatime        1 2
UUID=ecb1e0e4-81c3-4d81-a96b-48cd39b2fffe       none            swap            sw                      0 0
UUID=c25c891a-10f4-403b-8449-66a75c1d1530       /               ext4            noatime                 0 1

proc                                            /proc           proc            defaults                0 0
shm                                             /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
hugetlbfs                                       /hugepages      hugetlbfs       defaults                0 0

In plaats van:

code:

gentoo ~ # cat /etc/fstab
/dev/md1       /boot           ext4            defaults,noatime        1 2
/dev/md2       none            swap            sw                      0 0
/dev/md3       /               ext4            noatime                 0 1

proc                                            /proc           proc            defaults                0 0
shm                                             /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
hugetlbfs                                       /hugepages      hugetlbfs       defaults                0 0

[ Voor 51% gewijzigd door Pakjebakmeel op 23-09-2014 19:39 ]

[FireDrunk]

Hij krijgt een kernel panic, waarmee ik dus verwacht dat zijn rootfs niet goed gemount word.
Als Grub het probleem zou zijn, zou hij geen kernel panic krijgen, maar een GRUB error

(Denk ik )

[Pakjebakmeel]

FireDrunk schreef op dinsdag 23 september 2014 @ 19:09:
Hij krijgt een kernel panic, waarmee ik dus verwacht dat zijn rootfs niet goed gemount word.
Als Grub het probleem zou zijn, zou hij geen kernel panic krijgen, maar een GRUB error

(Denk ik )

Dow..

Juist. Correct.

[u_nix_we_all]

Ja maar eh .... volgens mij gaat het fout bij het switchen van initrd image (tijdelijk rootfs) naar de root op zijn raidset. Waarschijnlijk verwijst die nog naar md3 ipv een UUID. Dus daarom stelde ik voor eerst die weer in de fstab te zetten ipv meteen naar UUID's te switchen.

[Pakjebakmeel]

hmm.. Werk nooit met CentOS.. Gentoo is wat dat betreft erg simpel.. Heb ook sinds kort een initramfs gemaakt maar sinds dien ook niet veel meer mee gedaan.. It just works. Daarvoor nooit rekening mee hoeven houden en kernel auto assembly alles laten regelen. Overgegaan naar UUID's na een aantal maal in dit schuitje te zijn beland. Nooit meer problemen.

In dat geval;

fstab posten
mdadm --detail voor alle arrays posten

Kunnen we je wellicht helpen om de juiste preferred minor te updaten op het juiste array. Zoals hierboven aangegeven ben je dan (hopelijk) weer bootable.

Het komt er op neer dat je

1. boot in een LiveCD met mdadm
2. array stoppen met 'mdadm --stop /dev/mdX'
3. array assemblen met 'mdadm --assemble --update=super-minor /dev/mdX /dev/sdXX /dev/sdXX'
4. herhaal stap 2 tm 4 voor alle arrays
5. reboot naar CentOS.
6. bier
8. Migreer alsnog naar UUID's om dit te voorkomen en update je initramfs.

Doe eerst maar de details en fstab dan weten we meer.

[ Voor 25% gewijzigd door Pakjebakmeel op 23-09-2014 21:18 ]

[jbhc]

Nou ben ik geen linuxgoero en beschouw mijzelf dan ook echt als beginner maar zelfs ik begrijp dat er bepaalde mountpoints moeten zijn die leeg blijven als er een ander os gebruikt wordt.

Ik betwijfel dan ook of ts de boel weer aan de gang gaat krijgen.

Ook vraag ik me af waarom je zonder kennis van zaken iets exotisch als centos gaat gebruiken en dan als klap op de vuurpijl met een livecd in een raidvolume gaat zitten rommelen.....

[CAPSLOCK2000]

Zo exotisch is CentOS niet hoor, 't is gewoon wit-merk RedHat. En rommelen met je systeem, tja, ik geloof dat de TS daar ook niet om heeft gevraagd, maar iemand zal het probleem moeten oplossen.

[Pakjebakmeel]

Vervelende is dat een live cd je preffered minor update als hij raid volumes detecteert. Nooit begrepen waarom ze dat doen.

Zo exotisch is het inderdaad niet. Het 'probleem' is de combinatie van de livecd die met zijn takken aan je raid volumes zit en de afwezigheid van UUIDs in de fstab.

Anders had je dit niet gehad. Zodra de ts de fstab en de mdadm --details van de volumes post kunnen we hem vast de juiste commando's geven om de preferred minors terug te zetten.

[Verwijderd]

Goed. Hier maar weer eens een update.
Zoals reeds gezegd is Centos niet obscuur, maar de community enterprise versie van RedHat, en heb ik er verder niet veel over te klagen.
Ook heb ik niet zitten rommelen met een system rescue cd, maar daar gewoon mee geboot.
Nergens op de cd is te vinden dat je er niet mee op een raid systeem mag werken.

Ik was niet in staat met initrd te updaten, waarschijnlijk omdat me niet duidelijk is wat precies te doen.
Nadat ik alle data van de schijven naar een externe usb-disk had gekopieerd, heb ik met behulp van de centos 5.10 install cd het centos raid-1 systeem opnieuw geinstalleerd (weer identieke grootten van de volumes gekozen).
Daarna in /etc/fstab met behulp van de UUID nummers van de md0 t/m md3 volumes (verkregen door blkid /devmd#) een paar nieuwe regels geschreven (als in het voorbeeld in deze draad) en de oude (met /dev/md# erin) gedeactiveerd. Verder geen update van initramfs of andere dingen.
nb: eerst geprobeerd met de UUID's die getoond worden in mdadm /dev/md#, maar die werkten niet (reboot eindigt in een command line).
Nu boot de machine als gewenst.
Ik heb nog niet met een system rescue cd gewerkt, dus het ultieme bewijs is er nog niet dat het systeem nu crashproof is.