Leap 15.1 Upgrade auf Sotware Raid mit LVM
Hallo zusammen, ich versuche gerade einen Rechner, der noch Leap 15.0 drauf hat auf 15.1 zu aktualisieren. Das System hat acht Festplatten, von denen jeweils vier zu einem Software-Raid (Raid5) zusammengeschlossen sind. Auf jedem Raid ist ein LVM aufgesetzt. Beim Starten des Leap-15.1 mit dem Installationsimage stellt der Installer beim "Festplatten überprüfen" fest: "Die Volume-Gruppe /dev/raid1 ist unvollständig, da einige physische Volumes fehlen." Bricht man die grafische Oberfläche ab und schaut sich die Systeminformationen im Textbasierten Installer unter der Systeminformation an, sieht man, dass er alle Festplatten gefunden hat. Mit STRG-ALT-F2 habe ich daher zur Text-Konsole gewechselt und mir die Konfiguration des Raid mit cat /proc/mdstat angesehen: Statt md0 ist dort md127 zu finden, dass auch noch als "(auto-read-only)" markiert ist. Das zweite Array md1 wird korrekt erkannt und hat auch nicht den Status read-only. Ich vermute, dass die Ursache im md127 statt md0 zu suchen ist. Ich kann allerdings mit vgscan vgchange -ay mount /dev/mapper/raid1-root /mnt das Root-Volume einhängen und auch darauf zugreifen. Das ändert aber am Status in /proc/mdstat leider nichts. Hat jemand eine Idee, wie ich das Upgrade dazu bringen kann, das Raid korrekt zu erkennen und auch zu nutzen? Vielen Dank und noch einen schönen Sonntag. Mark -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Sun, 1 Mar 2020 15:05:10 +0100 Mark Wenzel
Das System hat acht Festplatten, von denen jeweils vier zu einem Software-Raid (Raid5) zusammengeschlossen sind. Auf jedem Raid ist ein LVM aufgesetzt. Beim Starten des Leap-15.1 mit dem Installationsimage stellt der Installer beim "Festplatten überprüfen" fest: "Die Volume-Gruppe /dev/raid1 ist unvollständig, da einige physische Volumes fehlen."
Gibt es noch weitere außer den oben genannten 8 Festplatten oder heißt die VG nur so seltsam?
Konfiguration des Raid mit cat /proc/mdstat angesehen: Statt md0 ist dort md127 zu finden, dass auch noch als "(auto-read-only)" markiert ist. Das zweite Array md1 wird korrekt erkannt und hat auch nicht den Status read-only.
Ich vermute, dass die Ursache im md127 statt md0 zu suchen ist.
LVM ist es unwichtig, unter welchem Device-Namen es seine PVs findet - solange sie komplett sind, d.h. nach einem pvscan keine fehlenden Devices gemeldet werden. Wenn eines nun md127 statt früher md0 heißt, ist die Änderung zwar seltsam und verwirrend, aber zunächst einmal unkritisch. Eine häuft verwendete lvm.conf scannt alles, was unter /proc/devices zu finden ist und wenn es auf dem jeweiligen Device ein LVM-Label findet, wird es unter "pvs" gelistet und steht grundsätzlich für LVMs zur Verfügung, wird also bei einem "vgchange -ay" für die Erstellung von VGs verwendet - solange unter /etc/lvm/backup nix steht (was bei einer Neuinstallation immer so ist). Normalerweise verwendet das System die Datei /etc/mdadm.conf, um die korrekte Zuordnung von md's und Platten zu finden. Bei einer Neuinstallation fehlt diese Datei, da die mdadm.conf vom Installations-OS verwendet wird. Der Installer muss also das nehmen, was ihm "mdadm -E --scan" liefert. Eine Markierung "auto-read-only" bedeutet, dass der Installer den "assemble" mit der "read-only"-Option durchgeführt hat. In diesem Fall schaltet das RAID-Device erst beim ersten Schreibzugriff auf read-write um. Ist also für den Ablauf unkritisch. Wichtiger ist, ob der Inhalt von /prod/mdstat fehlende Devices anzeigt? Ist erkennbar am "_" in der Laufwerksliste? Falls ja, solltest Du die Superblock-Infos der einzelnen Devices mit den RAID-Details vergleichen, also z.B. "mdadm -E /dev/sda1" und "mdadm -E /dev/sdb1" mit "mdadm -D /dev/md127". Wenn es hier Inkonsistenzen gibt, wird es kompliziert. Lässt sich jedenfalls nicht mehr so einfach erklären, auch wenn Linux-Soft-RAIDs jede Menge Möglichkeiten der Reparatur bieten. Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Tobias, Am 01.03.20 um 22:02 schrieb Tobias Crefeld:
On Sun, 1 Mar 2020 15:05:10 +0100 Mark Wenzel
wrote: Das System hat acht Festplatten, von denen jeweils vier zu einem Software-Raid (Raid5) zusammengeschlossen sind. Auf jedem Raid ist ein LVM aufgesetzt. Beim Starten des Leap-15.1 mit dem Installationsimage stellt der Installer beim "Festplatten überprüfen" fest: "Die Volume-Gruppe /dev/raid1 ist unvollständig, da einige physische Volumes fehlen." Gibt es noch weitere außer den oben genannten 8 Festplatten oder heißt die VG nur so seltsam?
Ich habe jeweils eine VG für jedes Raid angelegt. Daher heißt die eine VG "raid" und die andere "raid1" Hier sind die Ausgeben aus dem laufenden 15.0: # pvs PV VG Fmt Attr PSize PFree /dev/md0 raid lvm2 a-- 2.73t 746.15g /dev/md1 raid1 lvm2 a-- 1.36t 184.28g und aus dem Start mit dem Installationsmedium 15.1: # pvs WARNING: Failed to connect to lvmetad. Falling back to device scanning. PV VG Fmt Attr PSize PFree /dev/md1 raid1 lvm2 a-- 1.36t 184.28g /dev/md127 raid lvm2 a-- 2.73t 746.15g Bis auf den Namen des PV und der Warning, dass er keinen lvmetad findet sehen die gleich aus.
Konfiguration des Raid mit cat /proc/mdstat angesehen: Statt md0 ist dort md127 zu finden, dass auch noch als "(auto-read-only)" markiert ist. Das zweite Array md1 wird korrekt erkannt und hat auch nicht den Status read-only.
Ich vermute, dass die Ursache im md127 statt md0 zu suchen ist. LVM ist es unwichtig, unter welchem Device-Namen es seine PVs findet - solange sie komplett sind, d.h. nach einem pvscan keine fehlenden Devices gemeldet werden. Wenn eines nun md127 statt früher md0 heißt, ist die Änderung zwar seltsam und verwirrend, aber zunächst einmal unkritisch. Eine häuft verwendete lvm.conf scannt alles, was unter /proc/devices zu finden ist und wenn es auf dem jeweiligen Device ein LVM-Label findet, wird es unter "pvs" gelistet und steht grundsätzlich für LVMs zur Verfügung, wird also bei einem "vgchange -ay" für die Erstellung von VGs verwendet - solange unter /etc/lvm/backup nix steht (was bei einer Neuinstallation immer so ist).
Normalerweise verwendet das System die Datei /etc/mdadm.conf, um die korrekte Zuordnung von md's und Platten zu finden. Bei einer Neuinstallation fehlt diese Datei, da die mdadm.conf vom Installations-OS verwendet wird. Der Installer muss also das nehmen, was ihm "mdadm -E --scan" liefert.
Beim Start aus dem laufenden Leap 15.0 als auch aus dem mit dem Installationsmedium 15.1 sieht das so aus: # mdadm -E --scan ARRAY /dev/md/1 metadata=1.0 UUID=cbaa08e1:14c43e28:8f89bc7e:90112c9f name=any:1 ARRAY /dev/md/0 metadata=1.2 UUID=a66d98b9:3922d0c0:fe4900de:b7ccd162 name=host:0
Eine Markierung "auto-read-only" bedeutet, dass der Installer den "assemble" mit der "read-only"-Option durchgeführt hat. In diesem Fall schaltet das RAID-Device erst beim ersten Schreibzugriff auf read-write um. Ist also für den Ablauf unkritisch.
Wichtiger ist, ob der Inhalt von /prod/mdstat fehlende Devices anzeigt? Ist erkennbar am "_" in der Laufwerksliste? Falls ja, solltest Du die Superblock-Infos der einzelnen Devices mit den RAID-Details vergleichen, also z.B. "mdadm -E /dev/sda1" und "mdadm -E /dev/sdb1" mit "mdadm -D /dev/md127".
Die Ausgaben von /proc/mdstat zeigen keine für mich auffälligen Ausgaben an. Alle Devices sind verfügbar: Im laufenden System unter 15.0 sieht das so aus: # cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sdf1[0] sde1[4] sdh1[3] sdg1[1] 2929878528 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/8 pages [0KB], 65536KB chunk md1 : active raid5 sdd1[4] sdb1[1] sda1[0] sdc1[2] 1465155840 blocks super 1.0 level 5, 128k chunk, algorithm 2 [4/4] [UUUU] bitmap: 1/4 pages [4KB], 65536KB chunk unused devices: <none> Und beim Start mit dem Leap 15.1 Installationsmedium sieht das so aus: # cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md127 : active (auto-read-only) raid5 sdh1[3] sdf1[0] sdg1[1] sde1[4] 2929878528 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/8 pages [0KB], 65536KB chunk md1 : active raid5 sdb1[1] sdc1[2] sda1[0] sdd1[4] 1465155840 blocks super 1.0 level 5, 128k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/4 pages [0KB], 65536KB chunk unused devices: <none> Danke für Deine Mühen und viele Grüße Mark -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Sun, 1 Mar 2020 23:11:25 +0100 Mark Wenzel
# mdadm -E --scan
ARRAY /dev/md/1 metadata=1.0 UUID=cbaa08e1:14c43e28:8f89bc7e:90112c9f name=any:1 ARRAY /dev/md/0 metadata=1.2 UUID=a66d98b9:3922d0c0:fe4900de:b7ccd162 name=host:0
Nehme an, dass beim Boot des alten OS etwas anderes in der Datei /etc/mdadm.conf drin steht. Nachdem der Installer diese Datei nicht kennt, kann es schon passieren, dass md's mit anderen Device-Namen erkannt werden. Der Installer meckert ja auch das md1 an, also das nicht umbenannte und ohne "read-only" gemountete RAID. Nein, so alles in allem kann ich keine Fehler in den md's und im LVM erkennen. Aber gut, in die "Philosophie" eines Installers schaut man nicht immer rein. Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Tobias, Am 02.03.20 um 02:41 schrieb Tobias Crefeld:
Nehme an, dass beim Boot des alten OS etwas anderes in der Datei /etc/mdadm.conf drin steht. Nachdem der Installer diese Datei nicht kennt, kann es schon passieren, dass md's mit anderen Device-Namen erkannt werden.
Nein, so alles in allem kann ich keine Fehler in den md's und im LVM erkennen. Aber gut, in die "Philosophie" eines Installers schaut man nicht immer rein.
Danke für Deinen prüfenden Blick. Ich habe mir die Datei /etc/mdadm.conf des betreffenden Rechners nochmal angesehen und mit der eines anderen verglichen, der das Problem nicht hatte. Der einzige Unterschied war die zusätzliche Zeile DEVICE containers partitions beim problematischen Rechner. Da das aber der Default sein soll - wenn ich die man-page richtig gelesen habe - sollte das egal sein. Nachdem ich sowohl im Raid als auch im System keinen Fehler entdecken konnte habe ich mich entschieden das Upgrade via zypper dup durchzuführen. Das hat problemlos geklappt und das System läuft wieder einwandfrei mit der aktuellen Version. Mark -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (2)
-
Mark Wenzel
-
Tobias Crefeld