Absturz oder Reboot verbleibender Hosts bei Update und reboot des Quorum

R

Raudi

Member
Dec 29, 2025
57
13
8
Hallo,

ich habe gerade meinen 3. Host, auf dem eigentlich nur das Quorum und ein paar VM's laufen, aktualisiert:

1772824928976.png

Kurz nach dem Update haben die Hosts 1 und 2 einen reboot gemacht. Beide gleichzeitig. Die haben noch die ältere Version und die Hosts wurden eigentlich nicht angefasst.

Nach dem ich dann wieder auf die Umgebung kam, habe ich den 3. Host rebootet, damit der neue Kernel aktiv wird. Dabei haben die Hosts 1 und 2 erneut einen reboot gemacht.

Kent jemand zufällig ein solches Verhalten?

Ist schon spät, wenn gewünscht kann ich morgen noch mal nach genaueren Informationen schauen.

Viele Grüße
Stefan
 
Das klingt sehr nach dem HA-Watchdog/Fencing. Wenn auf den Hosts 1 und 2 HA aktiv ist und der Watchdog läuft, dann reicht ein kurzer Quorum-Verlust (z.B. weil Corosync auf Host 3 beim Update kurz neustartet) und die Kisten fencen sich sofort selbst.
Schau dir mal auf Host 1 oder 2 an was kurz vor dem Reboot im Journal stand:
Code: 
journalctl -b -1 -u pve-ha-lrm -u pve-ha-crm -u corosync --since "..." | tail -100
Da sollte stehen ob Quorum verloren ging und der Watchdog zugeschlagen hat. Und check mal ob der Softdog geladen ist:
Code: 
lsmod | grep softdog
Wenn du HA gar nicht nutzt bzw. keine HA-Ressourcen konfiguriert hast, kannst du den Watchdog auch deaktivieren, dann passiert das nicht mehr. Aber erstmal die Logs checken, dann sieht man genauer was los war.
 
Was mich wundert warum sollte HA hier die Hosts rebooten? Wenn 2 verbleibende Hosts aktiv sind und einer fehlt, dann dann müssen doch die 2 verbleibenden merken, dass sie aktiv sind und einer gestorben ist.

Code: 
Mar 06 20:04:28 pve01 corosync[1858]:   [CFG   ] Node 3 was shut down by sysadmin
Mar 06 20:04:28 pve01 corosync[1858]:   [QUORUM] Sync members[2]: 1 2
Mar 06 20:04:28 pve01 corosync[1858]:   [QUORUM] Sync left[1]: 3
Mar 06 20:04:28 pve01 corosync[1858]:   [TOTEM ] A new membership (1.107) was formed. Members left: 3
Mar 06 20:04:28 pve01 corosync[1858]:   [QUORUM] Members[2]: 1 2
Mar 06 20:04:28 pve01 corosync[1858]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 06 20:04:28 pve01 corosync[1858]:   [KNET  ] link: host: 3 link: 0 is down
Mar 06 20:04:28 pve01 corosync[1858]:   [KNET  ] host: host: 3 (passive) best link: 0 (pri: 1)
Mar 06 20:04:28 pve01 corosync[1858]:   [KNET  ] host: host: 3 has no active links
Mar 06 20:04:29 pve01 corosync[1858]:   [KNET  ] pmtud: PMTUD link change for host: 1 link: 0 from 469 to 8885
Mar 06 20:04:29 pve01 corosync[1858]:   [KNET  ] pmtud: Global data MTU changed to: 8885
Mar 06 20:04:34 pve01 pve-ha-crm[1922]: node 'pve03': state changed from 'online' => 'unknown'
Mar 06 20:05:02 pve01 corosync[1858]:   [KNET  ] rx: host: 3 link: 0 is up
Mar 06 20:05:02 pve01 corosync[1858]:   [KNET  ] link: Resetting MTU for link 0 because host 3 joined
Mar 06 20:05:02 pve01 corosync[1858]:   [KNET  ] host: host: 3 (passive) best link: 0 (pri: 1)
Mar 06 20:05:04 pve01 corosync[1858]:   [QUORUM] Sync members[3]: 1 2 3
Mar 06 20:05:04 pve01 corosync[1858]:   [QUORUM] Sync joined[1]: 3
Mar 06 20:05:04 pve01 corosync[1858]:   [TOTEM ] A new membership (1.10c) was formed. Members joined: 3
Mar 06 20:05:14 pve01 pve-ha-crm[1922]: lost lock 'ha_manager_lock - cfs lock update failed - Device or resource busy
Mar 06 20:05:14 pve01 pve-ha-crm[1922]: status change master => lost_manager_lock
Mar 06 20:05:14 pve01 pve-ha-crm[1922]: watchdog closed (disabled)
Mar 06 20:05:14 pve01 pve-ha-crm[1922]: status change lost_manager_lock => wait_for_quorum
Mar 06 20:05:26 pve01 pve-ha-lrm[1946]: lost lock 'ha_agent_pve01_lock - cfs lock update failed - Device or resource busy
Mar 06 20:05:26 pve01 pve-ha-lrm[1946]: status change active => lost_agent_lock
Mar 06 20:05:36 pve01 pve-ha-crm[1922]: status change wait_for_quorum => slave

Auf dem 2. Host sieht es etwas anders aus:

Code: 
Mar 06 20:05:04 pve02 corosync[1828]:   [QUORUM] Sync members[3]: 1 2 3
Mar 06 20:05:04 pve02 corosync[1828]:   [QUORUM] Sync joined[1]: 3
Mar 06 20:05:04 pve02 corosync[1828]:   [TOTEM ] A new membership (1.10c) was formed. Members joined: 3
Mar 06 20:05:04 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3
Mar 06 20:05:04 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3 4
Mar 06 20:05:04 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3 4
[...]
Mar 06 20:05:14 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3 4
Mar 06 20:05:15 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3 4
Mar 06 20:05:15 pve02 pve-ha-lrm[1918]: lost lock 'ha_agent_pve02_lock - cfs lock update failed - Device or resource busy
Mar 06 20:05:15 pve02 pve-ha-lrm[1918]: status change active => lost_agent_lock
Mar 06 20:05:16 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3 4
Mar 06 20:05:16 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3 4
[...]
Mar 06 20:06:03 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3 4
Mar 06 20:06:04 pve02 corosync[1828]:   [TOTEM ] Retransmit List: 3 4

Scheinbar zu der Zeit wo dann der 3. Host wieder verfügbar war...

Das war sonst aber nicht, letztens war mir auf dem kleinen 3. Host die SSD ausgefallen und ich musste diesen neu installieren, aber dabei liefen die anderen beiden Hosts die ganze Zeit weiter:

[SOLVED] Problem seit Update von 9.1.4 -> 9.1.5

Irgendwo ist da doch der Wurm drin...

Hier noch der Status:

Code: 
root@pve02:~# pvecm  status
Cluster information
-------------------
Name:             PVE-Cluster
Config Version:   5
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Mar  6 23:24:49 2026
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.119
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 192.168.33.42 (local)
0x00000002          1 192.168.33.41
0x00000003          1 192.168.33.43
root@pve02:~#

Hier auch noch ein paar Details zur HA Konfiguration:

[SOLVED] Verständnis Frage HA
 
Du hast recht, 2 von 3 Nodes haben Quorum. Die Logs zeigen das auch: "Sync members[2]: 1 2", Quorum war nie weg.
Das Problem passiert beim REJOIN von Node 3. Ab 20:05:04 kommt auf pve02 ne Flut an "Retransmit List: 3 4" und danach gehen auf beiden Hosts die CFS-Locks kaputt ("cfs lock update failed - Device or resource busy"). Also pmxcfs verhaspelt sich beim Re-Sync und HA verliert seine Locks.
Was mich aber stutzig macht: Auf pve01 steht "watchdog closed (disabled)", das ist ein sauberes Runterfahren vom Watchdog, kein Trigger. Wenn der Watchdog den Reboot verursacht hätte, würdest du das im Journal nicht mehr sehen, weil die Kiste dann einfach hart resettet. Sind die Logs hier vom aktuellen Boot oder von journalctl -b -1? Wir bräuchten eigentlich die Logs von VOR dem Reboot um zu sehen was den tatsächlich ausgelöst hat.
Und welche PVE-Version läuft auf Host 1 und 2 genau? Wenn die noch auf ner älteren Version sind könnte der Versionsunterschied beim Corosync-Rejoin ne Rolle spielen.
 
Also auf 1 und 2 läuft die Version, die oben im Screenshot zu sehen ist (von der er beim Update kommt), auf allen dreien waren die gleichen Versionen und ich wollte erstmal den 3. aktualisieren.

Um 20:04 schreibt der Node 1, dass Node 3 durch den sysadmin heruntergefahren wurde. Ich würde behaupten um 20:06 war dann der zweite Reset/Reboot, denn um 20:08 waren die beiden wieder da und er hat die ganzen VM's wieder gestartet.

Die Log-Schnipsel sind von unmittelbar vorm Reset/Reboot.

Hier noch mal das Log vom 3er:
Code: 
Mar 06 20:04:58 pve03 corosync[1148]:   [TOTEM ] Initializing transport (Kronosnet).
Mar 06 20:04:58 pve03 corosync[1148]:   [TOTEM ] totemknet initialized
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] pmtud: MTU manually set to: 0
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so
Mar 06 20:04:58 pve03 corosync[1148]:   [SERV  ] Service engine loaded: corosync configuration map access [0]
Mar 06 20:04:58 pve03 corosync[1148]:   [QB    ] server name: cmap
Mar 06 20:04:58 pve03 corosync[1148]:   [SERV  ] Service engine loaded: corosync configuration service [1]
Mar 06 20:04:58 pve03 corosync[1148]:   [QB    ] server name: cfg
Mar 06 20:04:58 pve03 corosync[1148]:   [SERV  ] Service engine loaded: corosync cluster closed process group service v1.01 [2]
Mar 06 20:04:58 pve03 corosync[1148]:   [QB    ] server name: cpg
Mar 06 20:04:58 pve03 corosync[1148]:   [SERV  ] Service engine loaded: corosync profile loading service [4]
Mar 06 20:04:58 pve03 corosync[1148]:   [SERV  ] Service engine loaded: corosync resource monitoring service [6]
Mar 06 20:04:58 pve03 corosync[1148]:   [WD    ] Watchdog not enabled by configuration
Mar 06 20:04:58 pve03 corosync[1148]:   [WD    ] resource load_15min missing a recovery key.
Mar 06 20:04:58 pve03 corosync[1148]:   [WD    ] resource memory_used missing a recovery key.
Mar 06 20:04:58 pve03 corosync[1148]:   [WD    ] no resources configured.
Mar 06 20:04:58 pve03 corosync[1148]:   [SERV  ] Service engine loaded: corosync watchdog service [7]
Mar 06 20:04:58 pve03 corosync[1148]:   [QUORUM] Using quorum provider corosync_votequorum
Mar 06 20:04:58 pve03 corosync[1148]:   [SERV  ] Service engine loaded: corosync vote quorum service v1.0 [5]
Mar 06 20:04:58 pve03 corosync[1148]:   [QB    ] server name: votequorum
Mar 06 20:04:58 pve03 corosync[1148]:   [SERV  ] Service engine loaded: corosync cluster quorum service v0.1 [3]
Mar 06 20:04:58 pve03 corosync[1148]:   [QB    ] server name: quorum
Mar 06 20:04:58 pve03 corosync[1148]:   [TOTEM ] Configuring link 0
Mar 06 20:04:58 pve03 corosync[1148]:   [TOTEM ] Configured link number 0: local addr: 192.168.33.43, port=5405
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 0)
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 2 has no active links
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 1)
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 2 has no active links
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 1)
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 2 has no active links
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 1 has no active links
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 1 has no active links
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] host: host: 1 has no active links
Mar 06 20:04:58 pve03 corosync[1148]:   [KNET  ] link: Resetting MTU for link 0 because host 3 joined
Mar 06 20:04:58 pve03 corosync[1148]:   [QUORUM] Sync members[1]: 3
Mar 06 20:04:58 pve03 corosync[1148]:   [QUORUM] Sync joined[1]: 3
Mar 06 20:04:58 pve03 corosync[1148]:   [TOTEM ] A new membership (3.108) was formed. Members joined: 3
Mar 06 20:04:58 pve03 corosync[1148]:   [QUORUM] Members[1]: 3
Mar 06 20:04:58 pve03 corosync[1148]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 06 20:04:58 pve03 systemd[1]: Started corosync.service - Corosync Cluster Engine.
Mar 06 20:04:59 pve03 systemd[1]: Starting pve-ha-crm.service - PVE Cluster HA Resource Manager Daemon...
Mar 06 20:04:59 pve03 pve-ha-crm[1214]: starting server
Mar 06 20:04:59 pve03 pve-ha-crm[1214]: status change startup => wait_for_quorum
Mar 06 20:04:59 pve03 systemd[1]: Started pve-ha-crm.service - PVE Cluster HA Resource Manager Daemon.
Mar 06 20:05:03 pve03 corosync[1148]:   [KNET  ] link: Resetting MTU for link 0 because host 2 joined
Mar 06 20:05:03 pve03 corosync[1148]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 1)
Mar 06 20:05:03 pve03 corosync[1148]:   [KNET  ] pmtud: PMTUD link change for host: 2 link: 0 from 469 to 1397
Mar 06 20:05:03 pve03 corosync[1148]:   [KNET  ] pmtud: Global data MTU changed to: 1397
Mar 06 20:05:04 pve03 corosync[1148]:   [KNET  ] rx: host: 1 link: 0 is up
Mar 06 20:05:04 pve03 corosync[1148]:   [KNET  ] link: Resetting MTU for link 0 because host 1 joined
Mar 06 20:05:04 pve03 corosync[1148]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Mar 06 20:05:04 pve03 corosync[1148]:   [KNET  ] pmtud: PMTUD link change for host: 1 link: 0 from 469 to 1397
Mar 06 20:05:04 pve03 corosync[1148]:   [KNET  ] pmtud: Global data MTU changed to: 1397
Mar 06 20:05:04 pve03 corosync[1148]:   [QUORUM] Sync members[3]: 1 2 3
Mar 06 20:05:04 pve03 corosync[1148]:   [QUORUM] Sync joined[2]: 1 2
Mar 06 20:05:04 pve03 corosync[1148]:   [TOTEM ] A new membership (1.10c) was formed. Members joined: 1 2
Mar 06 20:06:08 pve03 corosync[1148]:   [KNET  ] link: host: 1 link: 0 is down
Mar 06 20:06:08 pve03 corosync[1148]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Mar 06 20:06:08 pve03 corosync[1148]:   [KNET  ] host: host: 1 has no active links
Mar 06 20:06:10 pve03 corosync[1148]:   [TOTEM ] Token has not been received in 2737 ms
Mar 06 20:06:10 pve03 corosync[1148]:   [KNET  ] link: host: 2 link: 0 is down
Mar 06 20:06:10 pve03 corosync[1148]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 1)
Mar 06 20:06:10 pve03 corosync[1148]:   [KNET  ] host: host: 2 has no active links
Mar 06 20:06:11 pve03 corosync[1148]:   [TOTEM ] A processor failed, forming new configuration: token timed out (3650ms), waiting 4380ms for consensus.
Mar 06 20:06:15 pve03 corosync[1148]:   [QUORUM] Sync members[1]: 3
Mar 06 20:06:15 pve03 corosync[1148]:   [TOTEM ] A new membership (3.110) was formed. Members left: 1 2
Mar 06 20:06:15 pve03 corosync[1148]:   [TOTEM ] Failed to receive the leave message. failed: 1 2
Mar 06 20:06:15 pve03 corosync[1148]:   [QUORUM] Members[1]: 3
Mar 06 20:06:15 pve03 corosync[1148]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 06 20:06:20 pve03 systemd[1]: Starting pve-ha-lrm.service - PVE Local HA Resource Manager Daemon...
Mar 06 20:06:20 pve03 pve-ha-lrm[1403]: starting server
Mar 06 20:06:20 pve03 pve-ha-lrm[1403]: status change startup => wait_for_agent_lock
Mar 06 20:06:20 pve03 systemd[1]: Started pve-ha-lrm.service - PVE Local HA Resource Manager Daemon.
Mar 06 20:08:20 pve03 corosync[1148]:   [KNET  ] rx: host: 2 link: 0 is up
Mar 06 20:08:20 pve03 corosync[1148]:   [KNET  ] link: Resetting MTU for link 0 because host 2 joined
Mar 06 20:08:20 pve03 corosync[1148]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 1)
Mar 06 20:08:20 pve03 corosync[1148]:   [KNET  ] pmtud: Global data MTU changed to: 1397
Mar 06 20:08:20 pve03 corosync[1148]:   [QUORUM] Sync members[2]: 2 3
Mar 06 20:08:20 pve03 corosync[1148]:   [QUORUM] Sync joined[1]: 2
Mar 06 20:08:20 pve03 corosync[1148]:   [TOTEM ] A new membership (2.115) was formed. Members joined: 2
Mar 06 20:08:20 pve03 corosync[1148]:   [QUORUM] This node is within the primary component and will provide service.
Mar 06 20:08:20 pve03 corosync[1148]:   [QUORUM] Members[2]: 2 3
Mar 06 20:08:20 pve03 corosync[1148]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 06 20:08:26 pve03 corosync[1148]:   [KNET  ] link: Resetting MTU for link 0 because host 1 joined
Mar 06 20:08:26 pve03 corosync[1148]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 1)
Mar 06 20:08:26 pve03 corosync[1148]:   [QUORUM] Sync members[3]: 1 2 3
Mar 06 20:08:26 pve03 corosync[1148]:   [QUORUM] Sync joined[1]: 1
Mar 06 20:08:26 pve03 corosync[1148]:   [TOTEM ] A new membership (1.119) was formed. Members joined: 1
Mar 06 20:08:26 pve03 corosync[1148]:   [QUORUM] Members[3]: 1 2 3
Mar 06 20:08:26 pve03 corosync[1148]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 06 20:08:26 pve03 corosync[1148]:   [KNET  ] pmtud: Global data MTU changed to: 1397
Mar 06 20:08:30 pve03 pve-ha-crm[1214]: status change wait_for_quorum => slave
 
OK das pve03-Log ist eindeutig. "Failed to receive the leave message. failed: 1 2" um 20:06:15 heißt: beide Hosts sind hart weggebrochen, kein sauberes Shutdown. Muss der Watchdog oder ein Panic gewesen sein.
Das "watchdog closed (disabled)" von vorhin auf pve01 kam vom CRM, der hat seinen eigenen Watchdog sauber zugemacht. Aber der LRM hatte seinen eigenen Watchdog noch scharf gestellt, und wenn der dann wegen der CFS-Lock-Probleme nicht mehr gefüttert wurde...
Kannst du auf pve01 oder pve02 mal schauen:
Code: 
journalctl -b -1 -k | grep -iE "watchdog|softdog|panic|oom"
Da sollte drin stehen ob der Kernel-Watchdog den Reset ausgelöst hat oder ob es ein Panic war. Und schau mal ob in /var/log/kern.log noch was von 20:06 steht, das überlebt normalerweise auch nen harten Reboot.
 
Erster Reboot, letzte Zeile:
Code: 
Mar 06 19:53:38 pve01 kernel: watchdog: watchdog0: watchdog did not stop!
danach:
Code: 
Mar 06 19:55:52 pve01 kernel: NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
Mar 06 19:55:52 pve01 kernel: simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
Mar 06 19:55:53 pve01 kernel: ast 0000:03:00.0: [drm] Registered 1 planes with drm panic
Mar 06 19:55:54 pve01 kernel: softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Mar 06 19:55:54 pve01 kernel: softdog:              soft_reboot_cmd=<not set> soft_active_on_boot=0
Zweiter Reboot letzte Zeile:
Code: 
Mar 06 20:05:58 pve01 kernel: watchdog: watchdog0: watchdog did not stop!
danach
Code: 
Mar 06 20:08:12 pve01 kernel: NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
Mar 06 20:08:12 pve01 kernel: simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
Mar 06 20:08:13 pve01 kernel: ast 0000:03:00.0: [drm] Registered 1 planes with drm panic
Mar 06 20:08:14 pve01 kernel: softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Mar 06 20:08:14 pve01 kernel: softdog:              soft_reboot_cmd=<not set> soft_active_on_boot=0

Gleiches auf dem 2. Host:

Erster Reboot, letzte Zeile:
Code: 
Mar 06 19:53:31 pve02 kernel: watchdog: watchdog0: watchdog did not stop!
danach:
Code: 
Mar 06 19:55:51 pve02 kernel: NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
Mar 06 19:55:51 pve02 kernel: simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
Mar 06 19:55:52 pve02 kernel: ast 0000:03:00.0: [drm] Registered 1 planes with drm panic
Mar 06 19:55:53 pve02 kernel: softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Mar 06 19:55:53 pve02 kernel: softdog:              soft_reboot_cmd=<not set> soft_active_on_boot=0
Zweiter Reboot, letzte Zeile:
Code: 
Mar 06 20:05:57 pve02 kernel: watchdog: watchdog0: watchdog did not stop!
danach:
Code: 
Mar 06 20:08:17 pve02 kernel: NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
Mar 06 20:08:17 pve02 kernel: simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
Mar 06 20:08:18 pve02 kernel: ast 0000:03:00.0: [drm] Registered 1 planes with drm panic
Mar 06 20:08:19 pve02 kernel: softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Mar 06 20:08:19 pve02 kernel: softdog:              soft_reboot_cmd=<not set> soft_active_on_boot=0

Könnte die wichtigsten VM's ja mal runter fahren und dann den 3er Host noch mal rebooten und dabei per IPMI Konsole auf die anderen Hosts gehen um zu sehen, was auf der Konsole ausgegeben wird. (Falls es zu schnell geht, am besten gleich irgendwie aufzeichnen.)

Aber das mache ich am besten heute am späten Abend, so ohne DNS usw. da beschweren sich die Kid's hier im Haus. :)

Ein kern.log habe ich nicht gefunden auch nichts was so ähnlich aussieht.

Könnte nun natürlich auch die anderen beiden Hosts mit Updates nachziehen um zu sehen ob es das dann behebt. Aber so grundsätzlich darf sowas ja bei einem Update-Vorgang eigentlich nicht passieren... Könnte ja auch ein Bug sein wo es hilfreich wäre ihn zu finden....
 
Ich habe heute noch mal diverse Tests gemacht und ich konnte es nicht mehr reproduzieren.

Seit der oben beschriebenen Aktion habe ich die Umgebung nicht mehr angefasst, ich habe dann auf den ersten beiden Hosts die Konsole geöffnet, ein Screen-Recording gestartet und den dritten Host rebootet, wie zuvor auch. Aber es ist nicht passiert...

Ich habe dann noch mal auf dem 3. die neuen Updates installiert und die aktuellen Updates auf den anderen beiden Hosts installiert.

Lief alles Problemlos...
 
You must log in or register to reply here.
Top Bottom
Back