1

After an kernel update, my proxmox (Debian based) homeserver didn't boot:

enter image description here

# dmesg | grep -i microcode
[    0.080090] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
[    0.200978] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    1.043840] microcode: sig=0x306c3, pf=0x2, revision=0x19
[    1.043870] microcode: Microcode Update Driver: v2.2.

I found this and this question to the first TSC_DEADLINE disabled due to Errata error. So I updated my bios to the latest version avaliable, which is V1.12 from 05/19/2015. There was no error during the update and it seems to be applied:

# dmidecode -t BIOS | grep -E 'Version|Date'
        Version: V1.12
        Release Date: 05/19/2015

But the error still occurs. I found out that 5.4.41-1-pve is the latest kernel which boots successfull:

enter image description here

Older ones like the 5.3 one works too, but no newer versions. So I installed the intel-microcode package, which is recommended if there is no BIOS update avaliable to fix the issue. But the problem still persists, I can't boot the newer kernel versions.

Regex errors

The other regex errors seems to be caused by /etc/lvm/lvm.conf. I configured the following filter there:

global_filter = [ "r|/dev/zd.*|", "r|/dev/mapper/pve-.*|" "r|/dev/mapper/.*-(vm|base)--[0-9]+--disk--[0-9]+|" "r|/dev/sda" "r|/dev/sdd"]

This avoids standby issues with the disks, cause proxmox fetches informations from the disks periodically like their usage, which keeps them awake.

I guess that I need to place a delimiter at the end, which means r|/dev/sda| instead of r|/dev/sda and this was only tolerated in the past, I'm testing this currently.

EDIT

I got the same regex error when running update-grub and tried to modify the pattern with | at the end. After this, update-grub run without error. But after rebooting into the new kernel, I got the same error Invalid filter pattern "r|/dev/sda" altough I fixed the missing | at the end in /etc/lvm/lvm.conf.

When running apt upgrade, I get a warning from proxmox that the kernel was updated but is not loaded yet (reboot required). Additionally, it says that it expects microcode revision 0x28 instead of the current active 0.19:

enter image description here

Hardware details

# dmidecode -t Baseboard | grep -E 'Manufacturer|Product|Version'
        Manufacturer: MSI
        Product Name: Z87-GD65 GAMING (MS-7845)
        Version: 1.0

# grep "model name" /proc/cpuinfo
model name      : Intel(R) Core(TM) i3-4150 CPU @ 3.50GHz

# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

# egrep ^deb /etc/apt/sources.list
deb http://ftp.de.debian.org/debian buster main contrib non-free
deb http://security.debian.org buster/updates main contrib non-free
deb [arch=amd64] https://download.docker.com/linux/debian buster stable
deb http://ftp.de.debian.org/debian buster-backports main
Improve this question

1 Answer 1

Reset to default
1

The problem was, that /etc/lvm/lvm.conf wasn't reloaded with just calling update-grub. This article gave me the right hint (later also this one in German):

Take a backup of the existing initramfs and rebuild it, so that the changed /etc/lvm/lvm.conf file will be used for subsequent reboots.

To rebuild, I found the update-initramfs command and executed it like this:

update-initramfs -u -k all

Since I had multiple kernel versions and expected to may have issues in some (as in my previous tests), I rebuilded all. Normally, it may be enough to rebuild the latest one without -k all switch.

Now the server rebooted without any issues and I could verify that the microcode was updated:

# dmesg | grep -i microcode
[    0.000000] microcode: microcode updated early to revision 0x28, date = 2019-11-12
[    0.200700] SRBDS: Mitigation: Microcode
[    0.929176] microcode: sig=0x306c3, pf=0x2, revision=0x28
[    0.929231] microcode: Microcode Update Driver: v2.2.

Previously I had 0x19, now 0x28 as expected from proxmox. It seems that those updates were not applied, until I updated them manually. I guess that this is related to the (now) invalid regex pattern without | at the end, which prevents the update from being applied.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.