Host stützt ab oder friert ein.

[toddler]

Hallo zusammen,

da ich mittlerweile an dem Punkt angekommen bin nicht mehr weiter zu kommen hoffe ich hier auf Hilfe.
Kenntnisstand zu Linux und Proxmox ist eher so Noob-Level.

Aktuell laufen für Edomi und weitere Heimautomationsdienste auf einem ESXi 6.7.
Da immer mehr VM´s dazu gekommen sind sollte dieser so langsam ersetzt werden.
Da ESXi und non Intel NIC´s nicht die besten Freunde sind wollte ich es mit Proxmox probieren.

Leider ist es auch bei probieren geblieben.
Die Kiste friert oder stürzt oder was auch immer regelmäßig ab.
So geschehen wärend ich hier tippe...
Nach 12:58 Min kommt das Fenster "Verbindungsfehler". Es war keine VM oder Container am laufen.
Server ist dann nicht mehr bedienbar es hilft nur Hardreset.
Feststellen konnte ich das der Stromverbrauch von ca 11-14 Watt auf ca 23 Watt ansteigt.
In Logfile finde ich nichts oder ich weiß nicht wo ich suchen soll.

Daten zum Host:

CPU: I3 - 12100
Mainboard: Gigabyte B660M DS3H So.1700 DDR4 ATX Retail
Ram: G.Skill 64GB DDR4-2666 und Kingston 16GB DDR4-2400
NVME: 2x Seagate FireCuda 510 2TB SSD (als ZFS-Raid)
SSD: 2x Kioxia Exceria SSD 480GB 2.5 (als ZFS-Raid)
NIC: Onboard Realtek oder Intel X710-da2
PSU: Inter-Tech Mini-ITX PSU 200Watt

PVE:

pve-manager/7.4-3/9002ab8a (running kernel: 6.2.11-2-pve)

Intel Microcode:

[ 0.000000] microcode: microcode updated early to revision 0x2c, date = 2023-01-04 [ 3.670451] microcode: Microcode Update Driver: v2.2.

/etc/kernel/cmdline:

root=ZFS=rpool/ROOT/pve-1 boot=zfs split_lock_detect=off intel_iommu=off cpufreq.default_governor=powersave


Hardware ist bis auf die 16GB Kingston Ram alles Neu.
Fehler ist als ersten auf einer Installation mit einer alten SSD aufgetreten. Diese wurde dann gegen die 2 Kioxia ausgetauscht und alles einmal neu installiert.
Nach einer weile (Server läuft aktuell nur wie ich Zeit habe etwas daran zu tun) ist der Fehler wieder aufgetreten.

Ram habe ich 4 verschidene Sätze getestet immer mit dem selben Fehler.

Netzteile habe ich auch schon 3 Verschieden getestet da es sporadisch auch noch zu Reboot/Neustarts kommt. Wobei ich hierzu den Verdacht habe es könnte vom geringen Stromverbrauch kommen und eine Abschaltung des Netzteils sein.
So lange die X710 verbaut war kann ich mich nicht erinnern das es aufgetreten ist.


Jetzt die Frage in die Runde... Was mache ich Falsch bzw. wo kann ich nachschauen oder hat jemand eine Idee???

Gruß

Edit: nach weiteren 33:43 Min war es wieder so weit und die Kiste war weg...:-(

 

[Richard]

Hallo zusammen,

da ich mittlerweile an dem Punkt angekommen bin nicht mehr weiter zu kommen hoffe ich hier auf Hilfe.
Kenntnisstand zu Linux und Proxmox ist eher so Noob-Level.

Aktuell laufen für Edomi und weitere Heimautomationsdienste auf einem ESXi 6.7.
Da immer mehr VM´s dazu gekommen sind sollte dieser so langsam ersetzt werden.
Da ESXi und non Intel NIC´s nicht die besten Freunde sind wollte ich es mit Proxmox probieren.

Leider ist es auch bei probieren geblieben.
Die Kiste friert oder stürzt oder was auch immer regelmäßig ab.
So geschehen wärend ich hier tippe...
Nach 12:58 Min kommt das Fenster "Verbindungsfehler". Es war keine VM oder Container am laufen.
Server ist dann nicht mehr bedienbar es hilft nur Hardreset.
Feststellen konnte ich das der Stromverbrauch von ca 11-14 Watt auf ca 23 Watt ansteigt.
In Logfile finde ich nichts oder ich weiß nicht wo ich suchen soll.

Daten zum Host:

CPU: I3 - 12100
Mainboard: Gigabyte B660M DS3H So.1700 DDR4 ATX Retail
Ram: G.Skill 64GB DDR4-2666 und Kingston 16GB DDR4-2400
NVME: 2x Seagate FireCuda 510 2TB SSD (als ZFS-Raid)
SSD: 2x Kioxia Exceria SSD 480GB 2.5 (als ZFS-Raid)
NIC: Onboard Realtek oder Intel X710-da2
PSU: Inter-Tech Mini-ITX PSU 200Watt

PVE:

pve-manager/7.4-3/9002ab8a (running kernel: 6.2.11-2-pve)

Intel Microcode:

[ 0.000000] microcode: microcode updated early to revision 0x2c, date = 2023-01-04 [ 3.670451] microcode: Microcode Update Driver: v2.2.

/etc/kernel/cmdline:

root=ZFS=rpool/ROOT/pve-1 boot=zfs split_lock_detect=off intel_iommu=off cpufreq.default_governor=powersave


Hardware ist bis auf die 16GB Kingston Ram alles Neu.
Fehler ist als ersten auf einer Installation mit einer alten SSD aufgetreten. Diese wurde dann gegen die 2 Kioxia ausgetauscht und alles einmal neu installiert.
Nach einer weile (Server läuft aktuell nur wie ich Zeit habe etwas daran zu tun) ist der Fehler wieder aufgetreten.

Ram habe ich 4 verschidene Sätze getestet immer mit dem selben Fehler.

Netzteile habe ich auch schon 3 Verschieden getestet da es sporadisch auch noch zu Reboot/Neustarts kommt. Wobei ich hierzu den Verdacht habe es könnte vom geringen Stromverbrauch kommen und eine Abschaltung des Netzteils sein.
So lange die X710 verbaut war kann ich mich nicht erinnern das es aufgetreten ist.


Jetzt die Frage in die Runde... Was mache ich Falsch bzw. wo kann ich nachschauen oder hat jemand eine Idee???

Gruß

Edit: nach weiteren 33:43 Min war es wieder so weit und die Kiste war weg...:-(

Aus dem Text geht für mich nicht eindeutig hervoer, on nur WEB-access nicht mehr geht, oder auch die Konsole (direkt, nicht über ssh). Vermute Letzteres, was auf ein Hardware Problem (am ehesten Disk) hindeuted. Würde probieren mal von einem externen Laufwerk (USB) zu booten und die eingbaute Disk außen vor zu lassen.
Bzgl. logging am besten sich /var/log/syslog ansehen. Da sieht man sehr gut, wann gebooted wurde, und mal sehen, was unittelbar davor im Log steht. Wenn tatsächlich nichts brauchbares wird's wohl wirklich die Disk (oder Controller) sein.

 

[toddler]

Hallo,

Habe es eben extra nochmals ausprobiert. Es geht kein Zugriff über Web, SSH oder direkt auf der Konsole.
Über die Konsole lässt sich nicht mehr eingeben.
Selbst der Unterstrich welcher hinter der letzten Eingabe immer blickt ist stehen geblieben --> Hard Reset...


Das sind die letzten Einträge welche unter Syslog angezeigt werden bevor der Host einfriert.

Jun 03 18:31:59 Hypervisor kernel: fwbr300i0: port 2(tap300i0) entered blocking state Jun 03 18:31:59 Hypervisor kernel: fwbr300i0: port 2(tap300i0) entered forwarding state Jun 03 18:31:59 Hypervisor pvedaemon[2265]: <root@pam> end task UPID:Hypervisor:000078B6:0004364F:647B6AFF:qmstart:300:root@pam: OK Jun 03 18:32:15 Hypervisor pvedaemon[2265]: <root@pam> starting task UPID:Hypervisor:000085C5:00043CDF:647B6B0F:vncproxy:310:root@pam: Jun 03 18:32:15 Hypervisor pvedaemon[34245]: starting lxc termproxy UPID:Hypervisor:000085C5:00043CDF:647B6B0F:vncproxy:310:root@pam: Jun 03 18:32:16 Hypervisor pvedaemon[2266]: <root@pam> successful auth for user 'root@pam' Jun 03 18:32:17 Hypervisor pvedaemon[2265]: <root@pam> end task UPID:Hypervisor:000085C5:00043CDF:647B6B0F:vncproxy:310:root@pam: OK Jun 03 18:32:25 Hypervisor pvedaemon[2267]: <root@pam> successful auth for user 'root@pam' Jun 03 18:32:26 Hypervisor pvedaemon[2265]: <root@pam> starting task UPID:Hypervisor:00008711:0004410F:647B6B1A:vncproxy:310:root@pam: Jun 03 18:32:26 Hypervisor pvedaemon[34577]: starting lxc termproxy UPID:Hypervisor:00008711:0004410F:647B6B1A:vncproxy:310:root@pam: Jun 03 18:32:26 Hypervisor pvedaemon[2266]: <root@pam> successful auth for user 'root@pam' Jun 03 18:32:53 Hypervisor pvedaemon[2265]: <root@pam> end task UPID:Hypervisor:00008711:0004410F:647B6B1A:vncproxy:310:root@pam: OK Jun 03 18:43:44 Hypervisor systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab... Jun 03 18:43:44 Hypervisor systemd[1]: fstrim.service: Succeeded. Jun 03 18:43:44 Hypervisor systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab. Jun 03 18:46:04 Hypervisor smartd[1578]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 194 Temperature_Celsius changed from 77 to 76 Jun 03 18:46:04 Hypervisor smartd[1578]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 194 Temperature_Celsius changed from 77 to 76 -- Reboot -- Jun 03 19:38:31 Hypervisor kernel: microcode: microcode updated early to revision 0x2c, date = 2023-01-04 Jun 03 19:38:31 Hypervisor kernel: Linux version 6.2.11-2-pve (build@proxmox) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PREEMPT_DYNAMIC PVE 6.2.11-2 (2023-05-10T09:13Z) () Jun 03 19:38:31 Hypervisor kernel: Command line: initrd=\EFI\proxmox\6.2.11-2-pve\initrd.img-6.2.11-2-pve root=ZFS=rpool/ROOT/pve-1 boot=zfs split_lock_detect=off intel_iommu=off cpufreq.default_governor=powersave

Wie lässt sich das prüfen ob Disk oder Controller defekt sind? die Hardware ist vielleicht erst 3 Monate alt. Jetzt schon ein defekt...

 

[sherminator]

Würde probieren mal von einem externen Laufwerk (USB) zu booten und die eingbaute Disk außen vor zu lassen.

Ich würde hier gleich noch einen Schritt weitergehen und die Disks ausbauen. Ich habe schon erlebt, dass defekte Disks ein System runtergezogen haben, obwohl sie nicht benutzt wurden.

Und das Netzteil scheint mir in der Tat unterdimensioniert. Dass Dein System bei 11-14 Watt idled, finde ich überraschend wenig, aber ich habe keine Erfahrung mit neueren Intel-CPUs. Waren die anderen Netzteile, die Du getestet hat, auch so "klein"?

 

[toddler]

Hi,

Alle Disks? System (ZFS-Raid aus 2x Kioxia Exceria SSD 480GB 2.5) und die Disks für VM´s (ZFS-Raid aus 2x Seagate FireCuda 510 2TB NVME).


Aktuell ist Power Supply Idle Control (oder wie Gigabyte das gerade nennt) im BIOS aktiviert sonst bin ich bis auf 6,5 Watt im Idle als niedrigsten Wert runter gekommen.
Getestet wurde noch 300 Wat und 450 Watt Netzteil.
Die CPU ist mit TDP von 60 Watt (Turbo 89 Watt) angegeben, sie ist aber zusätzlich über Limit P1 und P2 gedeckelt.
Max Leistungsaufnahme waren glaube ich unter 60 Watt.
Flaschenhals bei den PicoPSU´s s ist der Strom der 5V.
Die 5V des Netzteils sind mit 12A angegeben was genug für mehrere Laufwerke sein sollte.
Laufwerke wurden ausgewählt nach möglichst geringer Leistungsaufnahme und "Schlafmodus" um hier mit den C-States runter zu kommen.
Kioxia Leistungsaufnahme: (maximal), 1.6W (Betrieb), 0.01W (Leerlauf), 0.01W (Schlafmodus)
Seagate Leistungsaufnahme: (maximal), 6W (Betrieb), 0.026W (Leerlauf), 0.002W (Schlafmodus)

Leistungsaufnahme war also bewusst ein Thema bei der Bauteil Auswahl...

 

[Richard]

Ich würde hier gleich noch einen Schritt weitergehen und die Disks ausbauen. Ich habe schon erlebt, dass defekte Disks ein System runtergezogen haben, obwohl sie nicht benutzt wurden.

Es bleibt IMO nur, Komponente für Komponente auszutauschen bzw. zu entfernen wie z.B. oben beschrieben, alles andere ist pure Spekulation. Alles zu entfernen, was man nicht unbedingt braucht und dann von extern booten wäre der erste Schritt, wenn das stabil funktioniert, dann Schritt für Schritt alles wieder einbauen, bis man den Sünder findet.

 

[mow]

Jun 03 18:46:04 Hypervisor smartd[1578]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 194 Temperature_Celsius changed from 77 to 76
Jun 03 18:46:04 Hypervisor smartd[1578]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 194 Temperature_Celsius changed from 77 to 76

Sind die Temperaturen echt oder verrechnet sich smartd da mal wieder?

 

[sherminator]

Leistungsaufnahme war also bewusst ein Thema bei der Bauteil Auswahl...

alles klar, dann wird an dieser Ecke wohl alles passen.

EIn paar Stunden memtest hast Du sicherlich schon gemacht, oder?
Und wie gesagt würde ich dann mal den einzelnen Disks auf den Zahn fühlen.

Sind die Temperaturen echt oder verrechnet sich smartd da mal wieder?

76-77 Grad Celsius sind für SSDs und NVMEs nicht so tragisch, oder?

 

[mow]

76-77 Grad Celsius sind für SSDs und NVMEs nicht so tragisch, oder?

Ich sehe gerade für die Firecuda NVME "0°C bis 70°C" und für die Kioxia SATA "0°C bis 65°C". Wenn also die Temperaturen echt sind, wäre das gar nicht gut. smartd zeigt bei der Temperatur allerdings öfter mal Unsinn an, daher sollte man das mal anderweitig gegenprüfen.

Wobei die 120TBW der Kioxia für ZFS schon arg knapp sind. Die FireCuda hat immerhin 2600TBW.

 

[Dunuin]

Das sind keine Temperaturen in Grad Celsius. Ruf mal smartctl -a /dev/sda | grep Temperature_Celsius auf. Da sollten dann die Temperaturen in Celsius zu finden sein.

 

[sherminator]

Ich sehe gerade für die Firecuda NVME "0°C bis 70°C" und für die Kioxia SATA "0°C bis 65°C".

Stimmt, Du hast recht (ich hatte die Lagertemperaturen im Kopf). Und da das die letzten syslog-Einträge sind, bevor die Kiste abschmiert, könnte der Hund tatsächlich dort begraben sein.

Das sind keine Temperaturen in Grad Celsius. Ruf mal smartctl -a /dev/sda | grep Temperature_Celsius auf. Da sollten dann die Temperaturen in Celsius zu finden sein.

In den syslog-Einträgen steht durchaus "Temperature_Celsius".
Ich habe gerade ein paar Stichproben bei uns gemacht: Alle (Samsung)SSDs zeigen hier plausible Werte um die 25 Grad Celsius.

 

[Dunuin]

In den syslog-Einträgen steht durchaus "Temperature_Celsius".
Ich habe gerade ein paar Stichproben bei uns gemacht: Alle (Samsung)SSDs zeigen hier plausible Werte um die 25 Grad Celsius.

Was aber nicht heißt, dass die 77 und 76 auch menschenleserliche Werte in Grad Celsius sind. Den Gesundheitszustand eines SMART Attributes kann man ja z.B. auch von 100 bis 0 darstellen.

Beispiel hier bei mir in den Logs:

Jun  8 07:49:23 voyager smartd[2441]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Temperature_Case changed from 80 to 81
Jun  8 12:19:23 voyager smartd[2441]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Temperature_Case changed from 81 to 80

Und wenn man dann mal smartctl anguckt:
190 Temperature_Case 0x0022 079 075 000 Old_age Always - 21 (Min/Max 15/25)

Da ist dann die SSD 21 Grad Celsius, hat nie 15 Grad C überschritten, nie 25 Grad C überschritten laut smartctl -a wärend im Syslog halt der 0-100 Gesundheitswert steht.

 

[sherminator]

Was aber nicht heißt, dass die 77 und 76 auch menschenleserliche Werte in Grad Celsius sind. Den Gesundheitszustand eines SMART Attributes kann man ja z.B. auch von 100 bis 0 darstellen.

wow, wieder was dazugelernt, vielen Dank!
Tatsächlich stehen auch bei uns im syslog nicht die Temperaturen, sondern der "Gesundheitszustand", meist Werte zwischen 70 und 80.

 

[toddler]

Hi,

Einen memtest habe ich noch nicht gemacht.
Der Fehler ist mit vier verschiedenen Ram-Kit´s aufgetreten. Einer davon läuft in einem anderen PC ca. 12-14 Stunden am Tag ohne Fehler allerdings unter Windows...
Aus diesem Grund hatte ich mir die menmtest "noch" gespart.

Zu den Temperaturen:

SSD:

root@Hypervisor:~# smartctl -a /dev/sda | grep Temperature_Celsius
194 Temperature_Celsius     0x0023   074   074   020    Pre-fail  Always       -       26 (Min/Max 18/26)
root@Hypervisor:~# smartctl -a /dev/sdb | grep Temperature_Celsius
194 Temperature_Celsius     0x0023   073   073   020    Pre-fail  Always       -       27 (Min/Max 18/27)

NVME:

root@Hypervisor:~# smartctl -a /dev/nvme1n1 | grep Temperature
Temperature:                        33 Celsius
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
root@Hypervisor:~# smartctl -a /dev/nvme0n1 | grep Temperature
Temperature:                        32 Celsius
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Vielleicht habe ich ja am Wochenende Zeit mir die Kiste nochmal vorzunehmen.

Vielen Dank schonmal für die Hilfe.