OS auf Raid aber andere Partion

[sunghost]

So Squeeze versucht im Expertmode mit Bootpart, selber Fehler mit 2.6 und 3.2 Kernel - im Log steh dann:

base-installer: error: exiting on error base -installer/kernel/failded-install
warning configuring bootstrap-base failed with error code 1
warning menu item bootstrap-base failed
debug resoler libslang2-udeb package doesnt exist ignored

Mir sagt das nichts, was kann man da machen?

[sunghost]

So nach etwas Suche wurde ich auf einen Beitrag aufmerksam indem der USB-Stick das Problem war. Jetzt habe ich diesen von alt und noname auf neu und Kingston getauscht und siehe da, er installiert Jetzt habe ich raid1 für root und raid5 für swap, sowie die ~9tb für raid5 die grade noch rebuild werden. Allerdings wurde Grup2 in den MBR der sda installiert. Das kommt mir etwas komisch vor. Hätte ich dort etwas anders machen müssen? Bzw. wie bekomme ich den jetzt auf die anderen Platte für den Fall eines Ausfalls?

[Cae]

Bzw. wie bekomme ich den jetzt auf die anderen Platte für den Fall eines Ausfalls?

Wenn dir jetzt /dev/sda abraucht, wirst du nicht booten können, RAID hin oder her. Das ist erst einmal so.

Natürlich kann man jetzt hingehen und das ändern. Oder man sorgt dafür, dass sdb immer kaputtgeht. Falls du Version eins vorziehen solltest, kontrolliere mit

Code: Alles auswählen

$ cat /proc/mdstat

ob deine RAID-Devices tatsächlich gerade /dev/sd{a,b} sind. Falls ja, fahre

Code: Alles auswählen

# grub-install /dev/sda /dev/sdb

. Dann bekommst du entweder einen Fehler, weil grub-install nur ein Argument frisst (denke aber nicht), oder zwei mal etwas von wegen successfully blah.
Nächster Schritt wäre dann, sda mit dd kaputtzuballern und zu rebooten, fdisk/sfdisk/dd den MBR [1] zu klonen und das RAID zu resynchen. Wenn das funktioniert, kannst du das Ding produktiv einsetzen. Man kann sich das auch sparen und dann im Recoveryfall anfangen, zu schwitzen.

Gruß Cae

[1] (s)fdisk schreiben den Bootloadercode *nicht* neu, update-grub wie oben ist erforderlich

[sunghost]

Status:

Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sda4[0] sdd4[3] sdc4[2] sdb4[1]
8764134912 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
[============>........] resync = 62.4% (1823903700/2921378304) finish=669.6min speed=27314K/sec

md1 : active (auto-read-only) raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1]
2929152 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

md0 : active raid1 sda2[0] sdd2[3] sdc2[2] sdb2[1]
7811464 blocks super 1.2 [4/4] [UUUU]

unused devices: <none>

Die 9TB werden also noch erzeugt. Der Rest ist fertig. Sobald ich Grub in die anderen 3 HDDs geschrieben habe und z.b. den Stecker von der ersten ziehe, sollte einer der anderen anspringen? Woher weiß er welche? Das er das Raid dann neu synct wäre ja normal, Grub müsste aber doch Raidunabhängig installiert worden sein, oder? So richtig verstehe ich das mit der Grubinstallation noch nicht.

[Cae]

Woher weiß er welche? Das er das Raid dann neu synct wäre ja normal, Grub müsste aber doch Raidunabhängig installiert worden sein, oder?

Das weiß eigentlich nur das BIOS, das nacheinander alle lebenden Platten durchprobiert. Diese Reihenfolge kann man einstellen. GRUB wird dadurch RAID-unabhängig, indem man die stage 1 auf alle beteiligten Platten installiert. Dann ist es egal, welcher gerade angebootet wird, GRUB sucht sein /boot, lädt stage 2 und den Kernel.

Das Synchen gerade hat sehr wahrscheinlich nix mit der GRUB-Installation zu tun, das ist einfach noch nicht fertig geworden.

Gruß Cae

[sunghost]

Das weiß eigentlich nur das BIOS, das nacheinander alle lebenden Platten durchprobiert. Diese Reihenfolge kann man einstellen. GRUB wird dadurch RAID-unabhängig, indem man die stage 1 auf alle beteiligten Platten installiert. Dann ist es egal, welcher gerade angebootet wird, GRUB sucht sein /boot, lädt stage 2 und den Kernel.
ah, sehr interessant...

Das Synchen gerade hat sehr wahrscheinlich nix mit der GRUB-Installation zu tun, das ist einfach noch nicht fertig geworden.

das ist richtig, ist ja das 9TB Raid5

Ok, dann mach ich, nach dem Sync das was du oben geschrieben hattest:

Code: Alles auswählen

grub-install /dev/sda /dev/sdb
grub-install /dev/sda /dev/sdc
grub-install /dev/sda /dev/sdd

Allerdings ist mir noch nicht klar, wie ich sehen kann, wo grub installiert ist. mdstat zeigts nicht und auch partet zeigt nur den HDD Zustand.

[Cae]

Ok, dann mach ich, nach dem Sync das was du oben geschrieben hattest:

Code: Alles auswählen

grub-install /dev/sda /dev/sdb
grub-install /dev/sda /dev/sdc
grub-install /dev/sda /dev/sdd

Ähm, da gibt es ein Missverständnis, das ist keine Reihenfolge oder so. Das ist einfach die Bitte an GRUB, sich auf den übergebenen Devices einzupflanzen. Welches Device dann tatsächlich angebootet wird, obliegt allein dem BIOS. Es hat (bei Verwendung von UUIDs, mdadm verwendet auch welche) keine Auswirkungen, von welchem MBR aus der Bootloader gestartet wird.

Also reicht

Code: Alles auswählen

# grub-install /dev/sda
# grub-install /dev/sdb
# grub-install /dev/sdc
# grub-install /dev/sdd # *oder* als Einzeiler
# for dev in /dev/sd{a,b,c,d}; do grub-install "$dev"; done

Gruß Cae

[sunghost]

Ok, als Reihenfolge hatte ich es auch nicht verstanden, nur dass er den von sda nimmt und nach sdb kopiert etc. aber nun ist es klar. Ich installiere einfach grub auf den jeweiligen Disks. Zum testen müsste auch das abstöpseln einer Disk reichen, oder? Wo sehe ich eigentlich im laufenden System von wo Grub grade geladen wurde?

[sunghost]

Hey,
ich habe eine Frage zu grub. Ich habe das System jetzt nochmal aufgesetzt und grub2 in den MBR einer Disk installiert, allerdings hatte ich keine Abfrage auf welcher. Ich vermute er hat ihn in alle 4 installiert, weil ich sie ja als Boot geflaggt hatte:

/dev/sda
x86 boot sector
partition 1: ID=0xee, starthead 0, startsector 1, 4294967295 sectors, extended partition table (last)\011, code offset 0x63
/dev/sda1
data
/dev/sda2
data
/dev/sda4
data
/dev/sdb
x86 boot sector
partition 1: ID=0xee, starthead 0, startsector 1, 4294967295 sectors, extended partition table (last)\011, code offset 0x0
/dev/sdb1
data
/dev/sdb2
data
/dev/sdb3
data
/dev/sdb4
data
/dev/sdc
x86 boot sector
partition 1: ID=0xee, starthead 0, startsector 1, 4294967295 sectors, extended partition table (last)\011, code offset 0x0
/dev/sdc1
data
/dev/sdc2
data
/dev/sdc3
data
/dev/sdc4
data
/dev/sdd
x86 boot sector
partition 1: ID=0xee, starthead 0, startsector 1, 4294967295 sectors, extended partition table (last)\011, code offset 0x0
/dev/sdd1
data
/dev/sdd2
data
/dev/sdd3
data
/dev/sdd4
data

Das würde doch bedeuten, dass ich mir den Nachlauf:

grub-install /dev/sdx ....

sparen kann, oder?

[Cae]

Code: Alles auswählen

# dd if=/dev/sda bs=512 count=1 2>/dev/null | hd | grep GRUB
00000180  47 52 55 42 20 00 47 65  6f 6d 00 48 61 72 64 20  |GRUB .Geom.Hard |

sollte für sda eine Zeile als Ergebnis bringen, sofern sie jemals von GRUB gehört hat. Ob dieser MBR tatsächlich korrekt starten würde, lässt sich damit allerdings nicht feststellen. Das da ist jetzt unter Wheezy, ein anderer Grub könnte aber durchaus ein anderes Layout im hd-Output haben, so dass grep nicht matcht. Binäres Greppen wäre die Abhilfe.

Gruß Cae

[sunghost]

Hallo,
mein Grub und MBR Experte und danke für deine schnelle Antwort. Bei zeigt er nur für sda dies an:

dd if=/dev/sda bs=512 count=1 2>/dev/null | hd | grep GRUB
00000180 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 |GRUB .Geom.Hard |

Daraus schlussfolgere ich, dass was ich geliefert habe ist nur die Partitionierung, entspr. sda,sdb... für den Bootloader. Da er obiges bei mir anzeigt, wird er dort den mbr installiert haben, sodass ich nun wie zuvor besprochen den selbigen auf die anderen 3 hdds installiere, richtig?

Danke und schöne Wo

[sunghost]

Hallo,
ich bin an dem Punkt an dem ich das System um eine weiter 3TB HDD erweitere. Vom Prinzip her müsste es mit der selben Partitionierung funktionieren, das habe ich mit parted probiert, allerdings versteh ich nicht wie ich die 100MB Partition für das Bios makiere/festlege. Selbes gilt für SWAP, der Rest wäre ok. Für eure Hilfe wäre ich dankbar.

[sunghost]

Mittels "set" ist dies möglich. Allerdings kann ich nach dem -add und --grow kein resize2fs auf dem md1, was ja die raid5 SWAP Partition ist durchführen:

resize2fs: Bad magic number in super-block beim Versuch, /dev/md1 zu Öffnen

Wenn ich nun im Netz etwas suche und mir die beiden Rechner, die ja identisch sind, ansehe, dann zeigt mir mdadm für den mit 5hdds:

Raid Level : raid5
Array Size : 3905536 (3.72 GiB 4.00 GB)
Used Dev Size : 976384 (953.66 MiB 999.82 MB)
Raid Devices : 5
Total Devices : 5
Persistence : Superblock is persistent

State : clean
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0

Damit sollte das root Raid doch die neue Größe von 4GB haben oder? Denn der 2. Rechner zeigt:

Raid Level : raid5
Array Size : 2929152 (2.79 GiB 3.00 GB)
Used Dev Size : 976384 (953.66 MiB 999.82 MB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent

State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Das würde bedeuten, dass ich ein resize2fs gar nicht machen muss, oder? Bis jetzt machte ich nach dem grow immer ein resize2fs um dann die UUIDs in der fstab zu aktualisieren. Kann das jemand bestätigen, bzw. bei dem obigen Fehler helfen? Oder wird das bei einer SWAP Partition anders gehandhabt?

edit: auf dem md0 was das root System ist läuft resize2fs sauber durch.
edit: die UUID aus --detail und --scan von md0 sind mit der vorherigen aus der mdamd.conf identisch, normal?