Grub lässt sich nicht auf Raid 1 installieren

generalmajor · 21 Dez. 2012

Ahoi,

derzeit setze ich ein System mit vier Festplatten in folgender Konfiguration auf:

Code:

/dev/sda --> /dev/sda1 --> /dev/md127
         --> /dev/sda2 --> /dev/md126
/dev/sdb --> /dev/sdb1 --> /dev/md127
         --> /dev/sdb2 --> /dev/md126
/dev/sdc --> /dev/sdc1 --> swap
         --> /dev/sdc2 --> /dev/md126
/dev/sdd --> /dev/sdd1 --> swap
         --> /dev/sdd2 --> /dev/md126

Auf /dev/md126 (4× 499,5 GB; Raid 10) will ich / unterbringen, auf /dev/md127 (2× 512 MB; Raid 1) hingegen /boot. Die Raids einzurichten, war etwas mühsam (siehe separaten Thread), und nun will ich openSuSE 12.1 aufsetzen. Das Installieren des Systems klappte zwar fehlerfrei, doch install-grub verweigerte beim Installieren des Bootloaders die Zusammenarbeit: «unknown file system 0xfd».

Ein Versuch, Grub von Hand zu installieren, schlug auch fehl:

Code:

grub> root (hd0,0)
unknown file system 0xfd

Was ich weiß ist: Installieren muss man Grub ins Raid /* denn nur das hat ein Dateisystem */, doch in der Grub-Config muss eine einzelne Partition (hier: /dev/sda1 alias hd0,0) eingetragen sein.

Ob ich Grub in den MBR (= /dev/sda bzw. /dev/sdb) schmeißen soll, weiß ich ehrlich gesagt nicht. Aber: Wie bekomme ich den Grub so aufs Raid, dass ich davon auch problemlos booten kann? Ich hab's in meiner Verzweiflung auch schon mit der Grub-Installier-Utility von der Ubuntu-Server-CD probiert, doch die hängt sich reproduzierbar auf, und auf bei SuSE gibt's so eine Utility schon seit Jahren nicht mehr.

Was mache ich da??

Anonymous · 22 Dez. 2012

Hast du jetzt überhaupt keinen Bootloader auf der Platte?

Das sich Grub an dem Partitionstype. (fd) stört währe mir neu, kann allerdings sein, da ich solche Raidkonfigurationen in Grub derzeit nur bis Suse 11.? getestet habe. Es könnte also durchaus sein das es ein neues Features oder ein Bug in Grub ist.

Als erstes allerdings prüfen dass die /boot/grub/device.map korrekt ist und zwar so wie der BIOS die Devices hochgibt. Hier kann es schon mal zu scheinbar ungewöhlichen Konstellationen kommen, wenn mehrere Platten von verschiedenen Plattenkontroller vorhanden sind.
hd1 sollte wirklich die sda sein und

Code:

udevadm info -q all -n /dev/sda | grep int13

sollte es als "int13_dev80" anzeigen.
entsprechend dann auch sdb als hd2 und int13_dev81
Und bitte noch mal überprüfen was /root für ein Filesystemtyp ist.

Sollte das soweit stimmen würde ich mal die Partitionstypekennung von sda1 temporär auf normales LINUX (83) ändern. Und dann mal die Grubkonfiguration noch mal versuchen. Danach wieder zurück auf fd zurücksetzen
das geht entweder mit fdisk, oder mit dem Befehl

Code:

sfdisk --change-id /dev/sda 1 83

Das ganze kann eine etwas Haarige Geschichte werden, da folgendes passieren kann/wird.
1. Nach der Änderung in der Partitionstabelle steht das zwar auf der Platte, aber der Kernel kennt es noch nicht. Der Kernel ließt das nur beim booten oder wenn er dazu aufgefordert wird. Die Aufforderung währe

Code:

sfdisk - R  /dev/sda

Der Kernel wird es aber nur akzepieren wenn dort von dieser Platte nichts in Benutzung ist. Es ist aber etwas in Benutzung (das Raid). Du könntest noch versuchen zusätzlich "-f" (force) zu benutzen. Aber möglich das reicht dann immer noch nicht aus um den Kernel zu überzeugen das er das neu einlesen soll. Also doch rebooten.

2. Bei diesem Reboot ist es jetzt aber möglich, das er die Raids auf dieser Platte nicht automatisch erkennt, ( kommt darauf an, was dort für Befehle in den Startscripten in der initrd verwendet werden) da er eventuell nur in Partitionen nach Raids sucht die zB. vom Type "fd" sind. Dieses Verhalten würde aber nicht auftreten, wenn eine richtig konfigurierte /etc/mdadm.conf existiert und zwar sowohl im /etc als auch in der "initrd"

Es bleiben für die Umgehung beider Probleme mehrere Möglichkeiten, alle nicht ganz so einfach zumindestens für den Linuxanfänger. Entweder vorher beide Raids auf dieser Platte auf failed zu setzen, damit die Platte frei ist wenn die Partitionstabelle geschrieben wird. Dann das /boot Raid wieder aufsetzen und dann Grub konfigurieren. Das große Raid erst wieder aufsetzen wenn der Partitionstype wieder auf fd zurückgesetzt ist.

oder vorher eine saubere /etc/mdadm.conf erzeugen und danach eine neue initrd erzeugen. Dann sollte er die Raidbestanteile in allen angegebenen Partitionen suchen&finden auch wenn sie nicht vom Type fd sind. (Alle initrd-Scripte die ich bisher bei Suse untersucht habe, würde die mdadm.conf automatisch mit in die initrd übernehmen. 12.? habe ich allerdings noch nicht studiert

)
oder das Ganze von einer LIVE-CD aus machen und die Raids auf den Platten am Anfang (bei der Änderung des Partitionstyps) gar nicht aktivieren. Nach der Änderung beide Raids aktivieren und dann muss in diesem Fall die Grub-Konfiguration aus einer kompletten "chroot" Umgebung heraus gemacht werden. Eine solche Chrootumgebung Ist nicht sonderlich kompliziert aber dennoch ein schönes Stück Handarbeit

robi

josef-wien · 22 Dez. 2012

robi schrieb:
Das sich Grub an dem Partitionstype. (fd) stört währe mir neu

GRUB stört das auch unter 12.1 nicht. Mich wundert allerdings, daß in der Fehlermeldung der Partitionentyp als Dateisystemtyp bezeichnet wird. Hat die Partition überhaupt ein Dateisystem?

robi schrieb:
int13_dev80

Das ist mittlerweile Geschichte, diese Verknüpfung wird von udev nicht mehr erzeugt. Führe als root

Code:

hwinfo --disk | egrep "Device Files:|BIOS id:"

aus.

robi schrieb:
hd1 sollte wirklich die sda

Da war es mit 1.45 Uhr wohl schon etwas spät. GRUB fängt mit hd0 an, was der BIOS-ID 0x80 entspricht.

robi schrieb:
/etc/mdadm.conf

In der initrd ist hier nur die Systempartition enthalten, mehr (auch die Boot-Partition) braucht der Kernel zum Systemstart nicht, die übrigen RAID werden dann aus /etc gelesen.

Anonymous · 22 Dez. 2012

josef-wien schrieb:
robi schrieb:

hd1 sollte wirklich die sda

Zum Vergrößern anklicken....

Da war es mit 1.45 Uhr wohl schon etwas spät. GRUB fängt mit hd0 an, was der BIOS-ID 0x80 entspricht.

da war es wohl wirklich schon etwas spät,

ps: hd0 sollte natürlich richtig sein.

wenn kein Problem mit den Partitiostyp fd vorhanden ist, dann vermute ich das sda wohl nicht die erste Platte ist die vom BIOS hochkommt, also nicht "BIOS-ID 0x80" oder eben in BIOS-Funktionsschreibweise "int13_dev80".
Wahrscheinlich haben deine Platte am Systemboard dann Vorrang. und der Kernel findet beim starten der Treiber aber zuerst die vom PCI-Kontroller. ( Ich habe auch Rechner wo sdd = hd0 ist und sda = hd1.)

robi

generalmajor · 22 Dez. 2012

Eine kurze Nachforschung ergab: Ich habe den Grub sehr wohl auf die Platte gekriegt, doch ist er völlig falsch konfiguriert! :-(

Erst mal habe ich die menu.lst wie folgt angepasst:

Code:

#--- RAID ---#
title RAID Platte 1 -- openSuSE 12.1
    kernel (hd0,0)/vmlinuz root=/dev/md126p1 resume=md127p1 splash=silent quiet showopts vga=0x317
    initrd (hd0,0)/initrd

#--- RAID ---#
title RAID Platte 2 -- openSuSE 12.1
    kernel (hd1,0)/vmlinuz root=/dev/md126p1 resume=md127p1 splash=silent quiet showopts vga=0x317
    initrd (hd1,0)/initrd

Alles freilich unter der Annahme, dass (hd0,0) für /dev/sda1 und (hd1,0) für /dev/sda2 steht. Aber in die device.map schau ich zur Sicherheit lieber nochmal rein…

Zum Dateisystem: (hd0,0) und (hd1,0) (/dev/sda1 + /dev/sda2) bilden zusammen das Level-1-Raid /dev/md126. Beide Partitionen sind vom Typ 0xfd (= Linux Raid). Ich habe auf das Raid (!) ein Ext4-Filesystem geklatscht, auf das man per /dev/md126p1 zugreifen kann.

…oder habe ich da was falsch gemacht??

Und: Greife ich von der Rescue-Shell aufs System zu, sehe ich die beiden Raids nicht. Muss ich sie extra assemblieren, bevor ich sie im Rettungssystem mounten kann, oder gibt's da einen schonenderen Weg?

Anonymous · 22 Dez. 2012

mit deiner Grubkonfiguration bin ich noch nicht so ganz einverstanden.

#--- RAID ---#
title RAID Platte 1 -- openSuSE 12.1
root (hd0,0) # bei dir zwar nicht unbedingt erforderlich, aber sicherer
kernel (hd0,0)/vmlinuz root=/dev/md126p1 resume=md127p1 splash=silent quiet showopts vga=0x317
initrd (hd0,0)/initrd

#--- RAID ---#
title RAID Platte 2 -- openSuSE 12.1
root (hd1,0) # bei dir zwar nicht unbedingt erforderlich, aber sicherer
kernel (hd1,0)/vmlinuz root=/dev/md126p1 resume=md127p1 splash=silent quiet showopts vga=0x317
initrd (hd1,0)/initrd

Das Blaue würde ich noch zufügen.
das Grüne kann nicht funktionieren. entweder "resume=/dev/sdc1" und ".... =/dev/sdd1" wenn dein Swap kein Raid werden soll. Das sind die Swap-devices die für ein Suspend to Disk genommen werden sollen. oder du musst deinen Swap zu einem Raid 1 konfigurieren dann kannst du "resume=/dev/md???" nehmen, aber solltest vorsichtshalber suspend to disk abschalten oder die Funktion vorher wirklich richtig austesten, das das zumindestens früher mal dann nicht richtig funktioniert hatte.

Das Rote hier bin ich mir noch nicht so ganz sicher ob dieses Device bei dir wirklich beim booten /dev/md126p1 bekommt. Dieser Name währe richtig wenn du die gesamte Platte als Raid nutzen würdest und dann dieses Raid erst partitioieren würdest, du also die Partitionstabelle in das Raid geschrieben hättest. dann währe dieser Knoten die erste Partition auf diesem Raid. Ansonsten und allgemein ein typischer Name währe /dev/md126, wobei es aber durchaus möglich ist das man die Gerätenummer mehr oder weniger frei wählen könnte. Es ist also wie es aussieht gar nicht so ganz klar und sicher was dort die Installationsroutine überhaupt gemacht hat. :???: :???: :???: Wenn du wirklich das Raid nochmal partitioniert hast und die erst Partition dann als dein Rootdevice hast, dann würde das einige Probleme erklären die du hast, das muss wieder runter, damit wirst du nie und nimmer glücklich, auch wenn es nicht unmöglich das System auch so zu betreiben. Es ist auf alle Fälle äußerst ungünstig für die Performance mit den 4KB Blocks auf den neuen Laufwerken.

Du kannst die Raids wenn sie nicht automatisch bei booten eines Rettungssystems gestartet werden per Hand starten.
Oftmals wird in solchen Systemen der Dienst nicht in jedem Fall automatisch gestartet. (zu erkennen daran das /proc/mdstat nicht existiert. Meist reicht es wenn du den entsprechenden Dienst nachstartest. Früher war das mal "boot.md" ob der jetzt bei 12.? immer noch so heißt ? bin ich mir nicht sicher.
Dazu ist folgendes zu sagen. Es gibt mehrere Möglichekeiten die Raids zustarten und zu bestimmen woher die Zuordnung der Geräte und Raidnamen kommen sollen. Bei Start des md Dienstes wird im Script schon

Code:

mdadm  -A -s -c /etc/mdadm.conf

ausgeführt, dieser würde die mdadm.conf verwenden soweit vorhanden, ansonsten alle Partitionen nach Raids absuchen und diese zusammenbauen, (das ist genau der Befehl der bei einer fehlenden mdadm.conf die Gerätenamen auf md127, md126 ....... umbenennen würde. )

1. aus einer /etc/mdadm.conf
dort steht Name und UUID des Raids drin, sowie auch die Devices oder Devicetypen die durchsucht werden müssen um die Bauteile für das Raid zu finden. Eine solche Datei hat oberste Priorität. Eine Kopie einer solche Konfigdatei steht wahrscheinlich auch in der initrd und diese wird dann zuerst aktiv, noch bevor die in /etc/ überhaupt gelesen werden kann.

2. aus den Raidsuperblöcken, dort steht der Raiddevicenummer mit drin. Es gibt einen Befehl sinngemäß untersuche alle Partitionen und suche das Raid mit der Raiddevicenummer und baue daraus wieder md??? zusammen.

Code:

mdadm -Ac partitions -m $MD_NR /dev/md$MD_NR

wobei $MD_NR die Raiddevicenummer ist, bzw die Variable in der das drinnen steht. Dabei bekommt das Raid den Namen der dort in den Raidsuperblöcken hinterlegt ist.
eine kleine Schleife würde alle möglichen Raids zusammensuchen, wenn man mal nicht genau weiß welche Namen (Devicenummern) sie mal bekommen hatten.

Code:

typeset -i MD_NR
 for ((MD_NR=0;MD_NR<128;MD_NR++))
 do
         mdadm -Ac partitions -m $MD_NR /dev/md$MD_NR 2>/dev/null
 done

3. kannst du den Gerätenamen für das Raiddevice frei wählen wie du willst, egal was in der /etc/mdadm.conf oder den Raidsuperblöcken steht, indem du einfach alle Raidbestandteile auflistest und daraus ein bestimmtes Raid Assembelst, ( Achtung nicht Createst) Beispiel:

Code:

mdadm -A /dev/md111 /dev/sda1 /dev/sdb2 /dev/sdc2 /dev/sd3

Dieser würde ein md111 zusammenbauen aus den Raidbestandteilen, egal wie das Raid früher bei der Erzeugung mal hehießen hätte.

Aber du solltest mal ein paar genaue und komplette Konfigurationsausgaben hier bringen, damit man mal sieht was dort bei dir im Rechner überhaupt los ist. Und bitte dazu schreiben, ob die jetzt aus dem richtig gestartetem System heraus oder von irgend einer CD- oder Rescue System heraus gemacht worden sind. Nur so kann man sich dann ein Bild machen was da überhaupt los ist auf deinem Rechner.

Code:

fdisk -l
cat /proc/mdstat
cat /proc/partitions
for i in sda1 sdb1 sda2 sdb2 sdc1 sdc2 sdd1 sdd2 md127 md126 md127p1 md126p1; do echo $i; file -s /dev/$i; echo; done
cat /boot/grub/menu.lst
cat /boot/grub/device.map
mount
cat /etc/mdadm.conf

robi

generalmajor · 22 Dez. 2012

Hier kommt, was ich bisher rausfinden konnte:

Code:

rescue ~# cat /boot/grub/device.map
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc
(hd3) /dev/sdd

rescue ~# cat /etc/mdadm.conf

DEVICE containers partitions
ARRAY /dev/md/suse12_boot UUID=0622ddf8:5d54cff7:05e4583e:b2103ec8
ARRAY /dev/md/suse12_root UUID=f344f793:53445347:52b0ff8a:02c3a794

Die Zurdnungen der Grub-Laufwerkssymbole sehen wie folgt aus:

Code:

hd0 587 /dev/sda 80
hd1 050 /dev/sdb 82
hd2 267 /dev/sdb 81
hd3 262 /dev/sdb 83

Eigenartig finde ich hier nur, dass bei hd1 und hd2 die BIOS-IDs irgendwie vertauscht sind.

Zu Beginn standen in der /proc/mdstat drei Geister-Arrays, die ich alle von Hand stoppte und hernach meine beiden Raids neu assemblierte. Klappte fehlerfrei. Danach beide Arrays gemountet (/mnt & /mnt/boot), chroot auf /mnt gemacht und ein wenig mit dem Grub herumgespielt. Ergebnis:

☠ grub-install moniert, dass /dev/md126p1 nicht dem entsprechenden BIOS-Laufwerk entspricht. Wundert mich nicht, denn das Raid kann das BIOS unmöglich kennen.
☠ grub interaktiv meldet bei root (hd0,0), ihm sei der Partitionstyp 0xfd nicht bekannt. Schon wieder.

Was muss ich hier noch ändern?

generalmajor · 22 Dez. 2012

Zu meiner menu.lst:

☠ Meine Swaps sind nicht geraidet, also muss ich dort folglich /dev/sdc1 & /dev/sdd1 reinschreiben.
☠ /boot liegt tatsächlich auf /dev/md126p1. Eigentlich wollte ich auf dem Raid nur eine Partition, doch ein oberschlauer SuSE-Installer führte trotzdem diese krude Nomenklatur ein. Aber sie ist grundsätzlich richtig.

Nur zur Erläuterung: Jetzt arbeite ich nur vom Rettungssystem aus, denn das «richtige» System kann ich ja immer noch nicht booten. :S

Anonymous · 22 Dez. 2012

generalmajor schrieb:
☠ /boot liegt tatsächlich auf /dev/md126p1. Eigentlich wollte ich auf dem Raid nur eine Partition, doch ein oberschlauer SuSE-Installer führte trotzdem diese krude Nomenklatur ein. Aber sie ist grundsätzlich richtig.

grundsätzlich richtig vielleicht, aber absolut unbrauchbar.
auf den Raids dürfen in diesem Fall überhaupt keine Partitionen drauf, die Dateisysteme müssen direkt auf das Raid und nicht auf Partitionen auf diesem Raids. /boot auf einer Partition in einem aus Partitionen bestehendem Array versteht kein Grub.

Das würde nur gehen wenn das Raid aus unpartitionierten Platten zusammengebaut wird. Allerdings würde dort /boot nur zuverlässig funktionieren bei einem Raid 1 als Grundlage, du aber willst Raid 10.

Meine Empfehlung:
Neuinstallieren, und manuelle erweiterte Partitionierung und Systemeinteilung bei der Installation verwenden und genau schauen was dort eingestellt ist bevor es losgeht. Die bestehenden Raids kannst du dabei wieder verwenden, brauchst sie also nicht neu Aufsetzen.

robi

generalmajor · 22 Dez. 2012

/dev/md126 für /boot ist ein Raid 1! Der Rest (/) kommt auf /dev/md127, ein Raid 10.

Das Böse ist nur: Ich habe im grafischen Partitionier-Tool direkt auf /dev/md126 geklickt und dort ein Ext4 einrichten lassen, doch der Installer hat ungefragt die Parti /dev/md126p1 hinzugefügt und das Ext4 da drauf gespielt.

H.i.K.: Muss ich /dev/md126 jetzt «von Hand» formatieren…? :-?

Anonymous · 22 Dez. 2012

generalmajor schrieb:
/dev/md126 für /boot ist ein Raid 1! Der Rest (/) kommt auf /dev/md127, ein Raid 10.

Das Böse ist nur: Ich habe im grafischen Partitionier-Tool direkt auf /dev/md126 geklickt und dort ein Ext4 einrichten lassen, doch der Installer hat ungefragt die Parti /dev/md126p1 hinzugefügt und das Ext4 da drauf gespielt.

H.i.K.: Muss ich /dev/md126 jetzt «von Hand» formatieren…? :-?

ist leider nicht so einfach mit dem was du uns hier an Informationen anbietest, die geforderten Konsolausgaben kommen nicht vollstandig, sind abgeschrieben und es sind Fehler drin. Letzlich kann niemand sagen was jetzt genau eine falsche Konfiguration ist und was nur ein Schreibfehler, und mit den fehlenden Informationen bleibt das hier im Forum ein Puzzel mit vielen Unbekannten.

Ich würde die Raids so lassen, wenn sie funktionieren. Wenn auf den Raids Partitionstabellen sind, die ersten 512 Byte mit NULL auf den Raids überschreiben und ein ext3/4 Dateisystem auf die Raids anlegen ( glaube nicht das ein Installationstools sich da ungefragt darüber hinwegsetzen darf, wenn dort schon ein Dateisystem ist) und dann neu Installieren und genau aufpassen was konfiguriert ist, bevor die Installation letztlich angestartet wird.

robi

generalmajor · 23 Dez. 2012

Langsam blicke ich hier echt nicht mehr durch…

Ich würde die Raids so lassen, wenn sie funktionieren. Wenn auf den Raids Partitionstabellen sind, die ersten 512 Byte mit NULL auf den Raids überschreiben und ein ext3/4 Dateisystem auf die Raids anlegen ( glaube nicht das ein Installationstools sich da ungefragt darüber hinwegsetzen darf, wenn dort schon ein Dateisystem ist) und dann neu Installieren und genau aufpassen was konfiguriert ist, bevor die Installation letztlich angestartet wird.

Es kam wie befürchtet: Ich musste aus der Rescue-Shell (mit fdisk → delete partition table) beide MD-Raids komplett leerputzen und hernach (mit mkfs.ext4) je ein Ext4-Dateisystem anlegen. Danach einen Reboot gemacht und das openSuSE 12.1 mit dem Installer neu aufgesetzt. Jetzt verfüge ich jetzt über zwei Raids mit einem Ext4 drauf: /dev/md126 (Raid 10; 1 TB netto für /) und /dev/md127 (Raid 1; 1 GB netto für /boot). Den Grub zu installieren klappte wieder nicht. Fehlermeldung (Popup im Installer): «Error 17. Can't mount hd (0,0).»

Im grafischen Installer gibt es bei einem MD-Raid offenbar nur noch die Möglichkeit, es zu löschen oder eine Partition darauf zu erstellen, nicht aber, es direkt mit einem Dateisystem zu formatieren (unter 11.2 gab's die Option noch, und Ubuntu hat sie bis heute.).

Die ganzen Config-Files kommen bald. Ich habe sie jetzt übrigens auf den USB-Stick verfrachtet.

generalmajor · 23 Dez. 2012

So, hier kommen die Files:

ACHTUNG: /dev/sde ist der USB-Stick!! Der Mountpoint /mnt ist dem Faktum geschuldet, dass ich aus der Rescue-Shell heraus gearbeitet habe.

/boot/grub/menu.lst:

Code:

# Modified by YaST2. Last modification on So Dez 23 14:51:14 CET 2012
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# For the new kernel it try to figure out old parameters. In case we are not able to recognize it (e.g. change of flavor or strange install order ) it it use as fallback installation parameters from /etc/sysconfig/bootloader

default 0
timeout 8
##YaST - generic_mbr
##YaST - activate


###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop -- openSUSE 12.1 - 3.1.0-1.2
    kernel (hd0,0)/vmlinuz-3.1.0-1.2-desktop root=/dev/disk/by-id/md-uuid-0622ddf8:5d54c7f7:05e4583e:b2103ec8 resume=/dev/disk/by-id/ata-WDC_WD5003AZEX-00K1GA0_WD-WMC1S0311267-part1 splash=silent quiet  showopts vga=0x317
    initrd (hd0,0)/initrd-3.1.0-1.2-desktop


###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 12.1 - 3.1.0-1.2
    kernel (hd0,0)/vmlinuz-3.1.0-1.2-desktop root=/dev/disk/by-id/md-uuid-0622ddf8:5d54c7f7:05e4583e:b2103ec8 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x317
    initrd (hd0,0)/initrd-3.1.0-1.2-desktop

/boot/grub/device.map:

Code:

(hd3)	/dev/disk/by-id/ata-WDC_WD5003AZEX-00K1GA0_WD-WMC1S0345262
(hd0)	/dev/disk/by-id/ata-WDC_WD5003AZEX-00K1GA0_WD-WMC1S0305587
(hd2)	/dev/disk/by-id/ata-WDC_WD5003AZEX-00K1GA0_WD-WMC1S0311267
(hd1)	/dev/disk/by-id/ata-WDC_WD5003AZEX-00K1GA0_WD-WMC1S0293050

/etc/mdadm.conf:

Code:

DEVICE containers partitions
ARRAY /dev/md/suse12_root UUID=0622ddf8:5d54c7f7:05e4583e:b2103ec8
ARRAY /dev/md/suse12_boot UUID=f344f793:53445347:52b0ff8a:02c3a794

/proc/mdstat:

Code:

Personalities : [raid1] [raid10] 
md126 : active raid10 sda2[0] sdd2[3] sdc2[2] sdb2[1]
      975725568 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      
md127 : active raid1 sda1[0] sdb1[1]
      521204 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

/proc/partitions:

Code:

major minor  #blocks  name

   8        0  488386584 sda
   8        1     521216 sda1
   8        2  487864320 sda2
   8       16  488386584 sdb
   8       17     521216 sdb1
   8       18  487864320 sdb2
   8       48  488386584 sdd
   8       49     521216 sdd1
   8       50  487864320 sdd2
   8       32  488386584 sdc
   8       33     521216 sdc1
   8       34  487864320 sdc2
   7        0      26852 loop0
   7        1       3028 loop1
   7        2      25172 loop2
   7        3      12060 loop3
   8       64    2015232 sde
   8       65    2015216 sde1
   9      127     521204 md127
   9      126  975725568 md126

fdisk -l:

Code:

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000499d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048     1044479      521216   fd  Linux raid autodetect
/dev/sda2   *     1044480   976773119   487864320   fd  Linux raid autodetect

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000499d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     1044479      521216   fd  Linux raid autodetect
/dev/sdb2   *     1044480   976773119   487864320   fd  Linux raid autodetect

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000499d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048     1044479      521216   fd  Linux raid autodetect
/dev/sdc2   *     1044480   976773119   487864320   fd  Linux raid autodetect

Disk /dev/sdd: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000499d0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1            2048     1044479      521216   fd  Linux raid autodetect
/dev/sdd2   *     1044480   976773119   487864320   fd  Linux raid autodetect

Disk /dev/sde: 2063 MB, 2063597568 bytes
16 heads, 32 sectors/track, 7872 cylinders, total 4030464 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xba888da8

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1              32     4030463     2015216    e  W95 FAT16 (LBA)

Disk /dev/md127: 533 MB, 533712896 bytes
2 heads, 4 sectors/track, 130301 cylinders, total 1042408 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000


Disk /dev/md126: 999.1 GB, 999142981632 bytes
2 heads, 4 sectors/track, 243931392 cylinders, total 1951451136 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

mount:

Code:

/dev/md126 on /mnt type ext4 (rw)
/dev/md127 on /mnt/boot type ext4 (rw)
/dev/sde1 on /mnt/media/usbstick type vfat (rw)

…und hier noch das Script, das mit «for» anfängt:

Code:

sda1
/dev/sda1: Linux/i386 swap file (new style), version 1 (4K pages), size 124671 pages, no label, UUID=ff8ae8a8-a229-4e8e-bd7e-b4f8e1a58c36

sdb1
/dev/sdb1: Linux/i386 swap file (new style), version 1 (4K pages), size 124671 pages, no label, UUID=1b844511-7aba-4cf2-8c92-45c4b6cd5b23

sda2
/dev/sda2: data

sdb2
/dev/sdb2: data

sdc1
/dev/sdc1: Linux/i386 swap file (new style), version 1 (4K pages), size 124671 pages, no label, UUID=a08d8e65-3dc1-4d5c-b8a2-9519ba87eade

sdd1
/dev/sdd1: Linux/i386 swap file (new style), version 1 (4K pages), size 124671 pages, no label, UUID=91063933-79b9-42c7-9cc3-cbbb559d5ed5

sdc2
/dev/sdc2: data

sdd2
/dev/sdd2: x86 boot sector; partition 1: ID=0x83, starthead 32, startsector 2048, 1951440896 sectors, code offset 0xb8

sde1
/dev/sde1: x86 boot sector; partition 4: ID=0x49, active, starthead 1, startsector 1394627663, 21337 sectors, Microsoft Windows 98 Bootloader, code offset 0x3e, OEM-ID "*5>+kIHC" cached by Windows 9M, sectors/cluster 64, root entries 512, Media descriptor 0xf8, sectors/FAT 248, heads 16, hidden sectors 32, sectors 4030432 (volumes > 32 MB) , serial number 0xc60dd71e, label: "KINGSTON   ", FAT (16 bit)

md126
/dev/md126: Linux rev 1.0 ext4 filesystem data, UUID=0aadd508-6327-4465-8463-d2dd25e44e93 (needs journal recovery) (extents) (large files) (huge files)

md127
/dev/md127: Linux rev 1.0 ext4 filesystem data, UUID=ed72f707-c578-4c2b-b817-73f63f5e2c6c (needs journal recovery) (extents) (huge files)

md126p1
/dev/md126p1: ERROR: cannot open `/dev/md126p1' (No such file or directory)

md127p1
/dev/md127p1: ERROR: cannot open `/dev/md127p1' (No such file or directory)

Fehlt noch was…?

josef-wien · 23 Dez. 2012

file ist der Ansicht, daß alle 4 Partitionen /dev/sd*1 jeweils SWAP-Partitionen sind (obwohl /dev/md127 mit ext4 formatiert ist), und bisher hat mir das Programm noch keinen Anlaß gegeben, ihm zu mißtrauen. Es ist logisch, daß GRUB auf einer SWAP-Partition seine Dateien nicht finden kann. Hast Du nach dem Formatieren von /dev/md127 die Partitionen /dev/sd[a,b]1 noch einmal formatiert? Ist das Verzeichnis /boot auf /dev/md126 leer, oder enthält es Daten?

Daß diese 4 Partitionen den Typ fd aufweisen, ist ein Schönheitsfehler, der zur Sicherheit auch korrigiert werden sollte.

generalmajor · 23 Dez. 2012

Nur zwei davon (sdc1 und sdd1) sollen Swaps sein, und so habe ich es beim Aufsetzen im Installer auch angegeben. Zum Schluss stand in der Tabelle aber Typ = Linux RAID und dahinter als Mountpoint SWAP. Hier gab der Installer also widersprüchliche Angaben.

/boot ist NICHT leer. Da sind tatsächlich (unvollständige?) Grub und sogar ein Kernel drauf. Überdies habe ich aus den angeblichen Swaps sda1 und sda2 ein funktionierendes MD-Raid zusammengebaut (nämlich md127), das sich ohne Probleme in /boot montieren lässt.

Kann ich den Typ von sda1 und sda2 ändern, ohne dass das Raid deswegen Probleme macht?

josef-wien · 23 Dez. 2012

generalmajor schrieb:
/boot ist NICHT leer. Da sind tatsächlich (unvollständige?) Grub und sogar ein Kernel drauf.

Mehr ist da auch nicht notwendig. Offenbar hast Du dem Installationsprogramm nicht gesagt, daß es /dev/md127 als /boot einhängen soll. Ich würde /dev/md127 noch einmal formatieren, dann sollte file ein anderes Ergebnis liefern. Danach kannst Du den Inhalt des Verzeichnisses /boot in das Hauptverzeichnis der RAID1-Partition kopieren, GRUB installieren und /boot ausleeren.

generalmajor schrieb:
Kann ich den Typ von sda1 und sda2 ändern, ohne dass das Raid deswegen Probleme macht?

Du sollst den Typ bei /dev/sdc1 und /dev/sdd1 ändern.

generalmajor · 23 Dez. 2012

Du sollst den Typ bei /dev/sdc1 und /dev/sdd1 ändern.

OK, das sind ja die beiden Swaps, die folglich 0x82 als fstype haben sollten. Gibt's da einen Befehl dafür?

Mehr ist da auch nicht notwendig. Offenbar hast Du dem Installationsprogramm nicht gesagt, daß es /dev/md127 als /boot einhängen soll.

Doch, das habe ich sehr wohl gemacht! Besser noch: Beim Rumfiddeln mit der Rescue-Shell habe ich /dev/md127 auch ausdrücklich unter /mnt/boot /* /mnt wegen Rettungssystem → ich wechsle dann per chroot in diesen Ordner */ gemountet, und zwar fehlerfrei. Deswegen verwundert mich das mit dem von file ermittelten FS-Typ ein wenig…

Ich würde /dev/md127 noch einmal formatieren, dann sollte file ein anderes Ergebnis liefern. Danach kannst Du den Inhalt des Verzeichnisses /boot auf die RAID1-Partition kopieren, GRUB installieren und /boot ausleeren.

Formatiert wird da das komplette RAID, nicht die Partis, aus denen es besteht, ja? Ich habe nämlich /dev/sda1 und /dev/sdb1 bei einem früheren Versuch als Swaps benützt (und /dev/sdc1 und /dev/sdd1 dafür als Bestandteile eines damaligen Raids), bei der jetzigen Tour auf «nicht formatieren» + FS-Typ «Linux RAID» gesetzt, aus den beiden ein MD-Raid gemacht (md127 nämlich) und mit mkfs.ext4 ein Ext4 auf das Raid geklatscht. Bei sdc1 und sdd1 gab ich «Formatieren als: Swap» an. Vielleicht ist das ja der Grund dafür. Sind vom Formatieren noch Überreste auf diesen Partis übrig geblieben, die file jetzt verwirren? Oder habe ich da was falsch gemacht?

josef-wien · 23 Dez. 2012

generalmajor schrieb:
Gibt's da einen Befehl dafür?

http://www.linux-club.de/viewtopic.php?f=4&t=117140#p739701

generalmajor schrieb:
aus den beiden ein MD-Raid gemacht (md127 nämlich) und mit mkfs.ext4 ein Ext4 auf das Raid geklatscht. ... Vielleicht ist das ja der Grund dafür. Sind vom Formatieren noch Überreste auf diesen Partis übrig geblieben, die file jetzt verwirren?

Auch wenn es mich wundert, scheint es doch so auszusehen. Nicht nur file wird "verwirrt", sondern auch GRUB. Hänge /dev/md127 getrennt von /dev/md126 ein, also nicht unter /mnt/boot. Enthält /dev/md127 Daten? Schauen sie aus wie der Inhalt von /boot aus /dev/md126?

generalmajor · 23 Dez. 2012

Hänge /dev/md127 getrennt von /dev/md126 ein, also nicht unter /mnt/boot. Enthält /dev/md127 Daten? Schauen sie aus wie der Inhalt von /boot aus /dev/md126?

Habe ich schon vorher probiert. Da erscheinen tatsächlich alle schon auf /boot gespielten Daten.

Mir ist auch eingefallen, warum Grub hd (0,0) mutmaßlich nicht montieren kann: Er muss ja direkt auf die Partition zugreifen! Die checkt er, merkt (aber mit welchem Mechanismus?), dass /dev/sda1 eine «Swap-Partition» ist (was ja falsch ist), und verweigert den Mount. Da drängt sich aber eine andere Frage auf: Reicht es, den FS-Typ einfach auf fd (oder notfalls 83) zu setzen, oder muss ich die betroffenen Partitionen komplett ausnullen?

Anonymous · 23 Dez. 2012

den FS-Typ einfach auf fd (oder notfalls 83) zu setzen

reicht vollkommen aus, aber ich glaube nicht das das etwas ändert, das wird im Normalfall von Linux gar nicht ausgewertet. Einzig Erweitere Partitionstypen, bei der Installation Swapdevices und beim Starten des md-Dienstes wird nach Raiddevices dort gesucht, sonst ist mich nicht bekannt das Linux das jemals interessiert hätte was dort für eine genaue Partitonskennung drin steht.

ansonsten deine Konfig sieht doch soweit ganz gut aus, wenn aus dem chroot die Bootloaderinstallation nicht funktioniert, vermute ich mal stark du hast in die chroot-Umgebung /proc /sys und vor allem /dev nicht eingebunden. nochmal den Link anschauen den ich weiter oben schon mal hier abgelegt hatte. Ohne Gerätedateien unterhalb von /dev kann er natürlich dort nichts finden.

"Den Grub zu installieren klappte wieder nicht. Fehlermeldung (Popup im Installer): «Error 17. Can't mount hd (0,0).»" Popup vom Installer, solange nicht bekannt ist was der genau macht und was nicht, ist der Installer bei einer solchen nicht alltäglichen Installation zweitrangig.

kontrolliere ob du in der Chroot /dev /proc und /sys hast und dann versuche Bootloader mit Hand zu installieren. Bitte den kompletten Log vom kompletten Befehl im Fehlerfall hier mal reinstellen.

robi

Grub lässt sich nicht auf Raid 1 installieren

Hacker

Anonymous

Gast

Ultimate Guru

Anonymous

Gast

Hacker

Anonymous

Gast

Hacker

Hacker

Anonymous

Gast

Hacker

Anonymous

Gast

Hacker

Hacker

Ultimate Guru

Hacker

Ultimate Guru

Hacker

Ultimate Guru

Hacker

Anonymous

Gast