[SOLVED] Node crashes when trying to update to proxmox-kernel-7.0.14-19

dmpm

Member
Dec 29, 2023
87
6
13
I've got three nodes in a cluster and the other two upgraded fine but the third one got this far and then the node showed as down in the UI and I can't SSH in to it either.

Any ideas why this might have happened? I'll have to do a hard reboot to see if it comes up again, otherwise I'll have to connect it to a monitor and keyboard to check it.

Code:
Starting system upgrade: apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  proxmox-kernel-7.0.14-19-pve-signed
The following packages will be upgraded:
  proxmox-kernel-7.0
1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 131 MB of archives.
After this operation, 1,030 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://download.proxmox.com/debian/pve trixie/pve-no-subscription amd64 proxmox-kernel-7.0.14-19-pve-signed amd64 7.0.14-19 [131 MB]
Get:2 http://download.proxmox.com/debian/pve trixie/pve-no-subscription amd64 proxmox-kernel-7.0 amd64 7.0.14-19 [17.3 kB]
Fetched 131 MB in 1s (107 MB/s)             
Selecting previously unselected package proxmox-kernel-7.0.14-19-pve-signed.
(Reading database ... 62080 files and directories currently installed.)
Preparing to unpack .../proxmox-kernel-7.0.14-19-pve-signed_7.0.14-19_amd64.deb ...
Unpacking proxmox-kernel-7.0.14-19-pve-signed (7.0.14-19) ...

ETA: I've tried purging the package with 'dpkg --remove --force-remove-reinstreq proxmox-kernel-7.0.14-19-pve-signed' and clearing the cache with

Code:
apt-get clean
apt-get update
dpkg --configure -a

and doing the upgrade again with 'apt-get dist-upgrade' but it crashes every time, although it does at least recover by itself now without me having to do a hard reboot. There's plenty of free space in /boot, which currently only contains:


Code:
ls /boot -la
total 101137
drwxr-xr-x  5 root root     4096 Sep 22 13:50 .
drwxr-xr-x 19 root root     4096 Sep 20 15:12 ..
-rw-r--r--  1 root root   308353 Sep 10 10:16 config-7.0.14-17-pve
drwx------  3 root root      512 Jan  1  1970 efi
drwxr-xr-x  5 root root     4096 Sep 20 14:54 grub
-rw-r-----  1 root root 76481034 Sep 20 16:16 initrd.img-7.0.14-17-pve
drwxr-xr-x  2 root root     4096 Sep 17 17:13 pve
-rw-r--r--  1 root root 10478940 Sep 10 10:16 System.map-7.0.14-17-pve
-rw-r--r--  1 root root 16268392 Sep 10 10:16 vmlinuz-7.0.14-17-pve

I think I've fixed it now. It seems there was a problem with old CPU microcode causing the decompress to crash when using multiple threads. I was able to install the update using single-core execution with 'taskset -c 0 dpkg -i /var/cache/apt/archives/proxmox-kernel-7.0.14-19-pve-signed_7.0.14-19_amd64.deb'.

Then I installed the Intel microcode. Previously dmesg | grep -i microcode showed:
Code:
[    0.000000] x86/CPU: Running old microcode
[    0.195036] SRBDS: Mitigation: Microcode
[    0.629323] microcode: Current revision: 0x000000f4

and now it shows:
Code:
[    0.195382] SRBDS: Mitigation: Microcode
[    0.636117] microcode: Current revision: 0x000000fa
[    0.636119] microcode: Updated early from: 0x000000f4
and testing the multi-thread decompression with 'apt-get reinstall proxmox-kernel-7.0.14-19-pve-signed' and 'ar p /var/cache/apt/archives/proxmox-kernel-7.0.14-19-pve-signed_7.0.14-19_amd64.deb $(ar t /var/cache/apt/archives/proxmox-kernel-7.0.14-19-pve-signed_7.0.14-19_amd64.deb | grep data.tar) | xz -dc -T 0 | tar -tf - > /dev/null' confirms that's working now.
 
Last edited:
  • Like
Reactions: Onslow
This might be caused by a node-specific hardware issue, such as the power supply, NVMe drive, CPU power management, temperature, or memory.

You may also find this similar thread helpful:
 
  • Like
Reactions: dmpm
This might be caused by a node-specific hardware issue, such as the power supply, NVMe drive, CPU power management, temperature, or memory.

You may also find this similar thread helpful:
Thanks. Yeah it seems it was old CPU microcode that was causing it. I think it's fixed now. I was worried my CPU, RAM or NVMe was faulty as I bought this machine on ebay a few days ago and I was worrying about having to return it.
 
  • Like
Reactions: kawano-y
Damn! Seems I spoke to soon. It's crashing again when doing multi-thread decompress, even with the governor set to powersave and adding "nvme_core.default_ps_max_latency_us=0" to the grub commandline.

I'm going to check the C-States setting in the BIOS next and try a different PSU. I'm already using a 65W one which should be fine for a P330 Tiny with an i7-8700T, 32GB RAM, one internal NVMe and two USB NVMes but I've got a 135W one I can try.

ETA: OK I changed C States from C1C3C6C7C8C10 to just C1 and with the 135W PSU it doesn't crash. I'll try it again with the 65W PSU to check whether it's the C States or the PSU that really made the difference.
 
Last edited:
Can you try to grab the crash message? It might be printed to a connected monitor or be visible in journalctl -b-1 -krp warning.
 
  • Like
Reactions: dmpm
Can you try to grab the crash message? It might be printed to a connected monitor or be visible in journalctl -b-1 -krp warning.
There doesn't seem to be anything critical there.

Code:
journalctl -b-1 -krp warning
Sep 22 16:33:49 pve-oakwood-3 kernel: faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2
Sep 22 16:33:49 pve-oakwood-3 kernel: kvm_intel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details.
Sep 22 16:33:46 pve-oakwood-3 kernel: kauditd_printk_skb: 111 callbacks suppressed
Sep 22 16:33:36 pve-oakwood-3 kernel: nvme nvme0: using unchecked data buffer
Sep 22 16:33:34 pve-oakwood-3 kernel: spi-nor spi0.1: supply vcc not found, using dummy regulator
Sep 22 16:33:34 pve-oakwood-3 kernel: spi-nor spi0.0: supply vcc not found, using dummy regulator
Sep 22 16:33:33 pve-oakwood-3 systemd-journald[1297]: File /var/log/journal/c1a7038ad788449ca21eeeb3aecd83bb/system.journal corrupted or uncleanly shut down, renaming and replacing.
Sep 22 16:33:33 pve-oakwood-3 kernel: zfs: module license taints kernel.
Sep 22 16:33:33 pve-oakwood-3 kernel: Disabling lock debugging due to kernel taint
Sep 22 16:33:33 pve-oakwood-3 kernel: zfs: module license 'CDDL' taints kernel.
Sep 22 16:33:33 pve-oakwood-3 kernel: spl: loading out-of-tree module taints kernel.
Sep 22 16:33:33 pve-oakwood-3 kernel: device-mapper: thin: Data device (dm-10) discard unsupported: Disabling discard passdown.
Sep 22 16:33:33 pve-oakwood-3 kernel: device-mapper: thin: Data device (dm-1) discard unsupported: Disabling discard passdown.
Sep 22 16:33:33 pve-oakwood-3 kernel: sd 5:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
Sep 22 16:33:33 pve-oakwood-3 kernel: sd 4:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
Sep 22 16:33:33 pve-oakwood-3 kernel: process 'usr/lib/mandos/plugin-runner' started with executable stack
Sep 22 16:33:33 pve-oakwood-3 kernel: ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
Sep 22 16:33:33 pve-oakwood-3 kernel: VMSCAPE: SMT on, STIBP is required for full protection. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/vmscape.html for more details.
Sep 22 16:33:33 pve-oakwood-3 kernel: MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more details.
Sep 22 16:33:33 pve-oakwood-3 kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
Sep 22 16:33:33 pve-oakwood-3 kernel: x86/cpu: SGX disabled or unsupported by BIOS.

With the 65W PSU it didn't crash without the two USB NVMe drives connected but once I connected them it did. With the 135W PSU it doesn't crash with them connected, so even though the CPU is only a 35W one it seems there's not enough headroom with the 65W PSU to handle three NVMe (including the internal one). I'll probably leave the C-States on C1 anyway, as there's minimal power saving from the higher states.
 
Please check with a connected monitor as well. Does it just reboot, power off, freeze or what happens exactly?
 
Last edited:
  • Like
Reactions: dmpm
Please check with a connected monitor as well. Does kt just reboot or what happens exactly?
The first time it happened it just locked up permanently and I had to do a hard reboot but after that the node just became unavailable in the UI or via SSH temporarily and then recovered itself. It wasn't rebooting so I think the power spike when decompressing with all the cores was maybe causing some memory bus corruption or something.
 
Can you check if it still accepts key presses via the keyboard when this happens? This behavior can also apply for a E1000E issue, for example.
If you think it's power related you can also try if disabling boost or limiting power via UEFI or RAPL changes things.
 
Last edited:
  • Like
Reactions: dmpm