Klar.
Den Pfad zu dm-1 musst Du selber rausfinden, sollte in /etc/fstab stehen.
fsck.ext4 /dev/mapper/dm-1Den Pfad zu dm-1 musst Du selber rausfinden, sollte in /etc/fstab stehen.
Proxmox Cluster Problem
- Thread starter bchristopeit
- Start date
Lieber Maxim, danke für deine Hilfe. Leider bin ich nun noch etwas aufgeschmissen und eventuell kannst du mir ja helfen. In der Datei steht bei mir nur:
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext4 errors=remount-ro 0 1
UUID=B295-5AC2 /boot/efi vfat defaults 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0
Meine Linux Basics sind sehr sehr sehr lange her. Ich habe jedoch im /dev/mapper eine pve-root / pve-swap und pve-data. Dann natürlich noch mein LUN. Wenn ich das auf pve-root mache bekomme ich:
root@pve2:/dev/mapper# fsck.ext4 pve-root
e2fsck 1.47.0 (5-Feb-2023)
pve-root is mounted.
e2fsck: Cannot continue, aborting.
Das wird wohl die HDD vom System sein. Beim Data gibt es mir folgendes aus:
root@pve2:/dev/mapper# fsck.ext4 pve-data
e2fsck 1.47.0 (5-Feb-2023)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open pve-data
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
und ich bin gerade auf dem node2 eben der Probleme macht:
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext4 errors=remount-ro 0 1
UUID=B295-5AC2 /boot/efi vfat defaults 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0
Meine Linux Basics sind sehr sehr sehr lange her. Ich habe jedoch im /dev/mapper eine pve-root / pve-swap und pve-data. Dann natürlich noch mein LUN. Wenn ich das auf pve-root mache bekomme ich:
root@pve2:/dev/mapper# fsck.ext4 pve-root
e2fsck 1.47.0 (5-Feb-2023)
pve-root is mounted.
e2fsck: Cannot continue, aborting.
Das wird wohl die HDD vom System sein. Beim Data gibt es mir folgendes aus:
root@pve2:/dev/mapper# fsck.ext4 pve-data
e2fsck 1.47.0 (5-Feb-2023)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open pve-data
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
und ich bin gerade auf dem node2 eben der Probleme macht:
Last edited:
Aber im Screenshot wird das Filesystem auf device "dm-1" bemängelt. Das muss ja existieren. Du könntest mit "lsblk" mehr erfahren.
Tut mir leid, mir gehen die Ideen aus. Ein Versuch wert wäre noch zu prüfen, ob /dev/dm-1 existiert und falls ja fsck.ext4 /dev/dm-1 auszuführen
Wenn ich mir mit versuche anzuzeigen was es ist erhalte ich:
root@pve2:/# blkid /dev/dm-1
/dev/dm-1: UUID="07d629fc-4f99-4e23-9636-0303ec044f03" BLOCK_SIZE="4096" TYPE="ext4"
aber die UUID ist bei lvdisplay bei all den gelisteten Sachen nicht mit dabei.
So wie es aussieht, scheint das aber die Platte zu sein wo Proxmox drauf läuft. Würde heissen, ich muss mit einem Ubuntu den Server Booten und schauen, dass ich das gemountet bekomme um einen Check zu machen?
root@pve2:/# udevadm info --query=all --name=/dev/dm-1
P: /devices/virtual/block/dm-1
M: dm-1
R: 1
U: block
T: disk
D: b 252:1
N: dm-1
L: 0
S: mapper/pve-root
S: disk/by-id/dm-uuid-LVM-e6B4mSummrLkANtN0bpCZBg1VwtIEe5rscz69FD3ABzNbBJ8OCNKHKW6u8lKTUDa
S: pve/root
S: disk/by-uuid/07d629fc-4f99-4e23-9636-0303ec044f03
S: disk/by-id/dm-name-pve-root
Q: 11
E: DEVPATH=/devices/virtual/block/dm-1
E: DEVNAME=/dev/dm-1
E: DEVTYPE=disk
E: DISKSEQ=11
E: MAJOR=252
E: MINOR=1
E: SUBSYSTEM=block
E: USEC_INITIALIZED=640667
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=pve-root
E: DM_UUID=LVM-e6B4mSummrLkANtN0bpCZBg1VwtIEe5rscz69FD3ABzNbBJ8OCNKHKW6u8lKTUDa
E: DM_SUSPENDED=0
E: DM_VG_NAME=pve
E: DM_LV_NAME=root
E: ID_FS_UUID=07d629fc-4f99-4e23-9636-0303ec044f03
E: ID_FS_UUID_ENC=07d629fc-4f99-4e23-9636-0303ec044f03
E: ID_FS_VERSION=1.0
E: ID_FS_TYPE=ext4
E: ID_FS_USAGE=filesystem
E: SYSTEMD_READY=1
E: DEVLINKS=/dev/mapper/pve-root /dev/disk/by-id/dm-uuid-LVM-e6B4mSummrLkANtN0bpCZBg1VwtIEe5rscz69FD3ABzNbBJ8OCNKHKW6u8lKTUDa /dev/pve/root /de>
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:
root@pve2:/# blkid /dev/dm-1
/dev/dm-1: UUID="07d629fc-4f99-4e23-9636-0303ec044f03" BLOCK_SIZE="4096" TYPE="ext4"
aber die UUID ist bei lvdisplay bei all den gelisteten Sachen nicht mit dabei.
So wie es aussieht, scheint das aber die Platte zu sein wo Proxmox drauf läuft. Würde heissen, ich muss mit einem Ubuntu den Server Booten und schauen, dass ich das gemountet bekomme um einen Check zu machen?
root@pve2:/# udevadm info --query=all --name=/dev/dm-1
P: /devices/virtual/block/dm-1
M: dm-1
R: 1
U: block
T: disk
D: b 252:1
N: dm-1
L: 0
S: mapper/pve-root
S: disk/by-id/dm-uuid-LVM-e6B4mSummrLkANtN0bpCZBg1VwtIEe5rscz69FD3ABzNbBJ8OCNKHKW6u8lKTUDa
S: pve/root
S: disk/by-uuid/07d629fc-4f99-4e23-9636-0303ec044f03
S: disk/by-id/dm-name-pve-root
Q: 11
E: DEVPATH=/devices/virtual/block/dm-1
E: DEVNAME=/dev/dm-1
E: DEVTYPE=disk
E: DISKSEQ=11
E: MAJOR=252
E: MINOR=1
E: SUBSYSTEM=block
E: USEC_INITIALIZED=640667
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=pve-root
E: DM_UUID=LVM-e6B4mSummrLkANtN0bpCZBg1VwtIEe5rscz69FD3ABzNbBJ8OCNKHKW6u8lKTUDa
E: DM_SUSPENDED=0
E: DM_VG_NAME=pve
E: DM_LV_NAME=root
E: ID_FS_UUID=07d629fc-4f99-4e23-9636-0303ec044f03
E: ID_FS_UUID_ENC=07d629fc-4f99-4e23-9636-0303ec044f03
E: ID_FS_VERSION=1.0
E: ID_FS_TYPE=ext4
E: ID_FS_USAGE=filesystem
E: SYSTEMD_READY=1
E: DEVLINKS=/dev/mapper/pve-root /dev/disk/by-id/dm-uuid-LVM-e6B4mSummrLkANtN0bpCZBg1VwtIEe5rscz69FD3ABzNbBJ8OCNKHKW6u8lKTUDa /dev/pve/root /de>
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:
Last edited:
Du kannst fsck auch auf einem Filesystem ausführen, das in Verwendung ist. Ohne weitere Angaben führt es keine Änderungen durch.
Das dm-1 ist ja laut der Ausgabe pve-root. Wenn ich aber dort das versuche kommt:
root@pve2:~# fsck.ext4 /dev/mapper/pve-root
e2fsck 1.47.0 (5-Feb-2023)
/dev/mapper/pve-root is mounted.
e2fsck: Cannot continue, aborting.
Aber ich möchte mich auf jeden Fall für deine Hilfe bedanken. Dass ist nicht selbstverständlich und ich weiss das sehr zu schätzen. Auch wenn ich vielleicht mit einigen dämlichen Fragen komme.
root@pve2:~# fsck.ext4 /dev/mapper/pve-root
e2fsck 1.47.0 (5-Feb-2023)
/dev/mapper/pve-root is mounted.
e2fsck: Cannot continue, aborting.
Aber ich möchte mich auf jeden Fall für deine Hilfe bedanken. Dass ist nicht selbstverständlich und ich weiss das sehr zu schätzen. Auch wenn ich vielleicht mit einigen dämlichen Fragen komme.
Also wenn die Server und NVMes brandneu sind, dann ist das tatsächlich unwahrscheinlich (aber nicht unmöglich!), dass hardwaretechnisch was kaputt ist.
Interessant wäre daher ein Blick auf die SMART-Werte, die sind nicht immer eindeutig interpretierbar in kaputt/nicht kaputt.
Falls das keinen Aufschluss bringt, wäre ich geneigt zu sagen, dass du den zickigen Server runterfährst und alle Netzwerkkabel trennst (damit auch bei versehentlichem reboot kein traffic mehr davon zum Cluster kommt, das ist wichtig!). Dann seinen Eintrag aus dem Cluster raus (von den anderen Nodes aus wird das gemacht).
In Ruhe lesen, auf Details achten, die Prozedur in Gänze verstehen und nicht in Panik einfach drauf loslegen:
https://pve.proxmox.com/wiki/Cluster_Manager#_remove_a_cluster_node
https://www.thomas-krenn.com/de/wiki/Proxmox_Node_aus_Cluster_entfernen_und_erneut_hinzufügen
Den betroffenen Server dann erst wieder ans Netzwerk anschließen, wenn er frisch installiert ist. Den gleichen Namen und die IPs geht dann auch klar.
Interessant wäre daher ein Blick auf die SMART-Werte, die sind nicht immer eindeutig interpretierbar in kaputt/nicht kaputt.
smartctl -x -q noserial /dev/nvmeX <- gerne als .txt im AnhangFalls das keinen Aufschluss bringt, wäre ich geneigt zu sagen, dass du den zickigen Server runterfährst und alle Netzwerkkabel trennst (damit auch bei versehentlichem reboot kein traffic mehr davon zum Cluster kommt, das ist wichtig!). Dann seinen Eintrag aus dem Cluster raus (von den anderen Nodes aus wird das gemacht).
In Ruhe lesen, auf Details achten, die Prozedur in Gänze verstehen und nicht in Panik einfach drauf loslegen:
https://www.thomas-krenn.com/de/wiki/Proxmox_Node_aus_Cluster_entfernen_und_erneut_hinzufügen
Den betroffenen Server dann erst wieder ans Netzwerk anschließen, wenn er frisch installiert ist. Den gleichen Namen und die IPs geht dann auch klar.
Geht, wie schon gesagt mit dem fstab Eintrag, fsck.ext4 /dev/pve/root, das Problem ist nur, daß es un-mountet sein muß, wenn es denn was reparieren soll.
Ansonsten geht nur dry-run = gucken (-N/-n ? -> man), was denn versucht würde zu reparieren.
Wenn man fsck auf das "/" laufen lassen möchte, muß man zB ein live-linux per usb booten, und dann fsck auf die orig-PLatte von "/" laufen lassen.
Ansonsten geht nur dry-run = gucken (-N/-n ? -> man), was denn versucht würde zu reparieren.
Wenn man fsck auf das "/" laufen lassen möchte, muß man zB ein live-linux per usb booten, und dann fsck auf die orig-PLatte von "/" laufen lassen.
Also wenn die Server und NVMes brandneu sind, dann ist das tatsächlich unwahrscheinlich (aber nicht unmöglich!), dass hardwaretechnisch was kaputt ist.
Interessant wäre daher ein Blick auf die SMART-Werte, die sind nicht immer eindeutig interpretierbar in kaputt/nicht kaputt.
smartctl -x -q noserial /dev/nvmeX<- gerne als .txt im Anhang
Falls das keinen Aufschluss bringt, wäre ich geneigt zu sagen, dass du den zickigen Server runterfährst und alle Netzwerkkabel trennst (damit auch bei versehentlichem reboot kein traffic mehr davon zum Cluster kommt, das ist wichtig!). Dann seinen Eintrag aus dem Cluster raus (von den anderen Nodes aus wird das gemacht).
In Ruhe lesen, auf Details achten, die Prozedur in Gänze verstehen und nicht in Panik einfach drauf loslegen:
https://pve.proxmox.com/wiki/Cluster_Manager#_remove_a_cluster_node
https://www.thomas-krenn.com/de/wiki/Proxmox_Node_aus_Cluster_entfernen_und_erneut_hinzufügen
Den betroffenen Server dann erst wieder ans Netzwerk anschließen, wenn er frisch installiert ist. Den gleichen Namen und die IPs geht dann auch klar.
Sieht tatsächlich ok aus.
Es gibt neuere Firmware GXA7802Q für das Modell, wäre nicht das erste Mal dass einen so ein Bug beißt. (Ich hab das nur grob überflogen, aber ka ob das hier plausibel zum Fehlerbild zusammenpasst und falls ja, willst du das auch für die anderen Nodes flashen) Edit: Vergiss das mit der neuen Firmware, ich hatte mich in der Zeile vertan.
https://last-public-ovh-baremetal.s...otification_for_General_customer_v2.1_PDF.pdf
Ich kenne mich mit den OEM-Bezeichnungen von Samsung nicht sonderlich aus, aber gleiche trotzdem genau ab (SAMSUNG MZVL2512HCJQ-00B00)
00B00 = General?
00L = Lenovo
Obwohl eine falsche Firmware zu 99% abgelehnt werden würde damit man nichts kaputtmachen kann, aber man sollte lieber 3x gucken und prüfen.
Also mein best "shot", wenn jetzt niemand mit nem besseren Vorschlag um die Ecke kommt tatsächlich die neue Firmware auf diese disk drauf, offline nehmen (aus cluster raus), frisch installieren, wieder rein in den Cluster. Wenn das klappt, dann die Firmware auf den anderen disks nachziehen, möglichst zeitnah nach ausgiebigem Test.
https://last-public-ovh-baremetal.s...otification_for_General_customer_v2.1_PDF.pdf
Ich kenne mich mit den OEM-Bezeichnungen von Samsung nicht sonderlich aus, aber gleiche trotzdem genau ab (SAMSUNG MZVL2512HCJQ-00B00)
00B00 = General?
00L = Lenovo
Obwohl eine falsche Firmware zu 99% abgelehnt werden würde damit man nichts kaputtmachen kann, aber man sollte lieber 3x gucken und prüfen.
Also mein best "shot", wenn jetzt niemand mit nem besseren Vorschlag um die Ecke kommt tatsächlich die neue Firmware auf diese disk drauf, offline nehmen (aus cluster raus), frisch installieren, wieder rein in den Cluster. Wenn das klappt, dann die Firmware auf den anderen disks nachziehen, möglichst zeitnah nach ausgiebigem Test.
Last edited:
Nicht schlimm. Hab nur explizit bei der SSD nen fw-bug vermutet, aber ich war in der Zeile verrutscht für dein Modell.
Mag sein, aber in dem screenshot von #15 sagts ja, dass nur noch read only gemountet ist. Das heißt auf jeden Fall, dass zum einen die Daten auf der Platte nicht (mehr?) konsistent sind (das ext4 ist auf jeden Fall als hinüber zu betrachten) und zum anderen corosync auf jeden Fall auch nicht mehr konsistent ist, weil ja nicht geschrieben werden konnte.
Bei ZFS hätte ich gesagt, lass nen scrub laufen und hoffe aufs Beste (geringe Chance auf nen autoheal weil eben nur eine disk und keine Redundanz), bei ext4 weiß ich es nicht und würde mich auf die Tips der anderen verlassen. Wenn das live nicht fixbar ist und mit ner bootcd auch nicht...tzja, dann bleibt dir leider nichts mehr übrig als die node frisch aufzuziehen.
Dachte ich nach all dem auch. Muss nur genau verstehen in dem Beitrag wie ich aus dem Cluster nur node2 entfernen kann. Das ist noch nicht zu 100% klar. 
Kann nächsten Montag wieder hin. Das wäre sowieso erst einmal der erste WegOk, dann würde ich raten, es doch nochmal penibel mit der live cd zu versuchen.