Grub + Raid: hoe grub van andere disk laten booten?

[WhiteDog]

Mijn server had deze ochtend een degraded array na een crash / reboot. Bij nadere inspectie in fdisk werd het nog vreemder: de partitietabellen tussen beide disks waren ineens verschillend. Ik heb toen /dev/sda van de raid losgemaakt, mbr gewist, partitietabel weer gekopiëerd en /dev/md0 en /dev/md1 weer aangekoppeld Omdat er nog wat errors waren wou ik eerst even een reboot proberen.

De server kwam echter niet meer online en van het datacenter heb ik dan vernomen dat hij niet wou booten van /dev/sda. Hij kon wel booten van /dev/sdb wat ze ook gedaan hebben (vraag me niet hoe / met welk commando).

Daar ik /dev/sda even niet meer vertrouw zou ik grub graag vertellen dat hij zich enkel met /dev/sdb moet bezighouden. Ik heb wat zitten inlezen rond grub op een raid configuratie (grub op beide disks zetten, etc.) net om dit soort situaties te voorkomen.

Helaas kan ik niet even vanalles "uitproberen" want als het fout loopt moet ik weer een uurtje wachten op iemand die hem in het datacenter laat verder booten.

Daarom graag jullie advies hoe ik grub /dev/sda laat vergeten en van /dev/sdb laat booten.
Zo kan ik de raid rustig weer repareren en evetueel de disk laten vervangen.

Ik post even wat info die ik al bij elkaar gezocht heb:

code:

root@server [~]# cat /boot/grub/device.map
# this device map was generated by anaconda
(hd0)     /dev/sda
(hd1)     /dev/sdb

code:

grub> find /grub/stage1
find /grub/stage1
 (hd0,0)
 (hd1,0)

code:

root@server[~]# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      104320 blocks [2/2] [UU]

md1 : active raid1 sda5[0] sdb5[1]
      2096384 blocks [2/2] [UU]

md2 : active raid1 sdb2[1]
      972462528 blocks [2/1] [_U]

grub.conf:

code:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/md2
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-371.1.2.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-371.1.2.el5 ro root=/dev/md2
    initrd /initrd-2.6.18-371.1.2.el5.img
title CentOS (2.6.18-308.4.1.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-308.4.1.el5 ro root=/dev/md2
    initrd /initrd-2.6.18-308.4.1.el5.img
title CentOS (2.6.18-308.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-308.el5 ro root=/dev/md2
    initrd /initrd-2.6.18-308.el5.img

En het commando dat het misschien zou oplossen:

code:

grub> device (hd0) /dev/sdb
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Alleen zou ik hem liever vertellen om /dev/sda voorlopig even helemaal te vergeten...
Is het zo eenvoudig als in grub.conf alles naar root (hd1,0) wijzen en/of het commando grub> root (hd1,0) geven?

Mijn eeuwige dank alvast!

[ Voor 19% gewijzigd door WhiteDog op 27-01-2014 12:42 . Reden: typos ]

[Hero of Time]

Gewoon de grub config gelijk houden hoe 't al staat. Wat je moet doen, is zorgen dat er geen Grub meer in de MBR staat van sda. Het systeem probeert te starten van de eerste schijf die een geldige MBR heeft. Als je 4 schijven in je systeem hebt en de laatste is bootable, zal het systeem de eerste drie overslaan. Er is op 't web een commando die met dd de eerste 512 bytes weggooid, zodat je partitietabel nog in orde is, maar de MBR waar grub staat leeg is.

Heb je geen 'console' toegang tot je server? Dan hoef je niet bang te zijn om wat verkeerd te doen en hoef je ook niet telkens te wachten op de hosting partij.

[WhiteDog]

Hero of Time schreef op maandag 27 januari 2014 @ 13:36:
Gewoon de grub config gelijk houden hoe 't al staat. Wat je moet doen, is zorgen dat er geen Grub meer in de MBR staat van sda. Het systeem probeert te starten van de eerste schijf die een geldige MBR heeft. Als je 4 schijven in je systeem hebt en de laatste is bootable, zal het systeem de eerste drie overslaan. Er is op 't web een commando die met dd de eerste 512 bytes weggooid, zodat je partitietabel nog in orde is, maar de MBR waar grub staat leeg is.

Heb je geen 'console' toegang tot je server? Dan hoef je niet bang te zijn om wat verkeerd te doen en hoef je ook niet telkens te wachten op de hosting partij.

Helaas geen console toegang, enkel remote reboot en ssh. Rescue Mode (PXE boot) is ook beschikbaar maar doet het niet momenteel.

Het is de eerste keer in 5 jaar dat ik de boot om zeep help dus gelukkig valt dat nog mee. Meestal remove ik een disk uit de raid en wordt deze daarna door een nieuwe vervangen. Nu heb ik lopen klooien... niet erg slim van mezelf.

Ik kom uit op deze commando's

code:

# delete partition table
dd if=/dev/null of=/dev/sdX bs=512 count=1

code:

# delete only grub
dd if=/dev/null of=/dev/sdX bs=446 count=1

Dat eerste commando heb ik meen ik gebruikt om de disk na het removen te "wissen".

Ik wil ook gerust /dev/sda weer loskoppelen en even herbeginnen. Misschien is mijn volgorde verkeerd?
Eerst grub erop zetten en dan pas de partitietabel overzetten?

Edit:

Heb inmiddels sda weer uit de array gegooid en volgende commando's losgelaten:

code:

mdadm --zero-superblock /dev/sda
mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sda2
mdadm --zero-superblock /dev/sda3
mdadm --zero-superblock /dev/sda4
mdadm --zero-superblock /dev/sda5
dd if=/dev/zero of=/dev/sda bs=512 seek=124914352

Dat zou me dus een lege /dev/sda moeten geven alsof er een nieuwe disk inzit.
Misschien een beter uitgangspunt?

[ Voor 13% gewijzigd door WhiteDog op 27-01-2014 14:51 ]

[Hero of Time]

Je fout was om na het trashen van je MBR gelijk grub erop te gooien. Dat zal natuurlijk nooit goed gaan, want het verwijst dan naar de schijf waar verder geen grub config te vinden is. Je doet altijd eerst de schijf vullen met data, dan pas z'n boot herstellen. Op die manier heb je namelijk gegarandeerd een systeem dat start als de recovery tussentijds onderbroken wordt.

[WhiteDog]

Hero of Time schreef op maandag 27 januari 2014 @ 20:06:
Je fout was om na het trashen van je MBR gelijk grub erop te gooien. Dat zal natuurlijk nooit goed gaan, want het verwijst dan naar de schijf waar verder geen grub config te vinden is. Je doet altijd eerst de schijf vullen met data, dan pas z'n boot herstellen. Op die manier heb je namelijk gegarandeerd een systeem dat start als de recovery tussentijds onderbroken wordt.

Ik heb momenteel het probleem dat hij altijd aangeeft dat het device "busy" is als ik /dev/sda2 aan md2 weer wil toevoegen. Als tip lees ik dan vaak "om een keer te rebooten". Ik kan dus helaas momenteel niet eerst alle data herstellen.

Ik ben nu bezig met het wissen van de voledige schijf met: dd if /dev/zero of /dev/sda bs 1M

Hierna zou ik graag:
1. rebooten
2. partitietabel kopiëren
3. raid weer volledig maken

Maar dan moet ik wel even zeker zijn dat hij straks gaat booten op sdb

[Hero of Time]

Als je zeker weet dat / nu op sdb draait, is een reboot niet noodzakelijk. Je moet alleen zorgen dat de kernel de wijzigingen van je schijf weet. Parted doet dat voor je, maar als je die niet gebruikt, is partprobe de oplossing.

Je zou als experiment kunnen proberen om een dd clone te doen van sdb naar sda, maar om daar het juiste resultaat mee te krijgen is het beter om dat niet bij een off-site machine te doen. Met je lege sda, moet je 'm weer aan je MD toevoegen alsof 't een nieuwe is. Er zijn zat tutorials en andere documenten op 't web die dat beschrijven.

[WhiteDog]

Helaas... na wipen van hele disk:

code:

root@server [~]# sfdisk -d /dev/sdb | sfdisk /dev/sda --force
Checking that no-one is using this disk right now ...
BLKRRPART: Device or resource busy

This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util sfdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 121601 cylinders, 255 heads, 63 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
 /dev/sda: unrecognized partition table type
Old situation:
No partitions found
New situation:
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sda1   *        63    208844     208782  fd  Linux raid autodetect
/dev/sda2        208845 1945134134 1944925290  fd  Linux raid autodetect
/dev/sda3     1945134135 1949327099    4192965  82  Linux swap / Solaris
/dev/sda4     1949327100 1953520064    4192965   5  Extended
/dev/sda5     1949327163 1953520064    4192902  fd  Linux raid autodetect
Successfully wrote the new partition table

Re-reading the partition table ...
BLKRRPART: Device or resource busy
The command to re-read the partition table failed
Reboot your system now, before using mkfs

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

code:

root@server [~]# partprobe
root@server [~]# mdadm --manage /dev/md0 --add /dev/sda1
mdadm: added /dev/sda1
root@server [~]# mdadm --manage /dev/md1 --add /dev/sda5
mdadm: added /dev/sda5
root@server [~]# mdadm --manage /dev/md2 --add /dev/sda2
[b]mdadm: Cannot open /dev/sda2: Device or resource busy[/b]

[CAPSLOCK2000]

Heb je de GPT-waarschuwing gezien? Al snap ik niet dat hij daarna wel gewoon partities aan maakt.

[WhiteDog]

CAPSLOCK2000 schreef op dinsdag 28 januari 2014 @ 20:21:
Heb je de GPT-waarschuwing gezien? Al snap ik niet dat hij daarna wel gewoon partities aan maakt.

Zover ik het begrepen heb is die melding fout:

code:

root@server [~]# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.6.10

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present

Als ik er GPT commando's op los laat krijg ik daar de melding dat er geen GPT gevonden is.
Ik heb overigens een identieke server (zelfde hardware, zelfde OS, op zelfde moment geïnstalleerd) die in fdisk dezelfde GPT error geeft. Ging er vanuit dat het een geinigheidje van CentOS was daar hij inderdaad gewoon verder doet.

Net even dit losgelaten:

code:

sgdisk --zap /dev/sda
sgdisk --zap /dev/sdb
partprobe

GPT errors zijn nu verdwenen, data nog intact maar...

code:

root@server [~]# mdadm --manage /dev/md2 --add /dev/sda2
mdadm: Cannot open /dev/sda2: Device or resource busy

[ Voor 15% gewijzigd door WhiteDog op 28-01-2014 21:34 ]