TSC_DEADLINE由于Errata而禁用，尽管BIOS更新和intel-microcode包
在内核更新之后，我的proxmox (基于Debian的)主服务器没有启动：
# 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.我发现了这和这的第一个TSC_DEADLINE disabled due to Errata错误问题。因此，我将我的贝奥斯更新为最新版本avaliable，即从2015年5月19日开始的V1.12版本。在更新过程中没有出现错误，它似乎适用于：
# dmidecode -t BIOS | grep -E 'Version|Date'
Version: V1.12
Release Date: 05/19/2015但错误仍在发生。我发现5.4.41-1-pve是引导成功的最新内核：
像5.3这样的老版本也能工作，但没有更新版本。因此，我安装了intel-microcode包，如果没有可以修复此问题的BIOS，则建议使用该包。但问题仍然存在，我无法启动较新的内核版本。
正则误差
其他正则表达式错误似乎是由/etc/lvm/lvm.conf引起的。我在那里配置了以下过滤器：
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"]这个避免磁盘的备用问题会导致proxmox周期性地从磁盘中获取信息，就像它们的使用一样，这会使它们保持清醒。
我想我需要在末尾放置一个分隔符，这意味着r|/dev/sda|而不是r|/dev/sda，这在过去才被容忍，我目前正在测试这个。
编辑
在运行update-grub时，我得到了相同的regex错误，并试图在最后用|修改模式。在此之后，update-grub将无错误地运行。但是在重新启动到新内核之后，我得到了同样的错误Invalid filter pattern "r|/dev/sda"，我在/etc/lvm/lvm.conf的末尾修复了丢失的|。
在运行apt upgrade时，我收到proxmox的警告，即内核已经更新，但尚未加载(需要重新启动)。此外，它还表示希望微码修改为0x28，而不是当前的活动0.19：
硬件细节
# 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回答 1
Unix & Linux用户
发布于 2020-11-28 21:32:21
问题是，/etc/lvm/lvm.conf并没有仅仅通过调用update-grub来重新加载。这篇文章给了我正确的提示(稍后也是这个用德语写的)：
对现有的initramfs进行备份并重新构建它，以便将更改后的/etc/lvm/lvm.conf文件用于后续的重新启动。
为了重新构建，我找到了更新-initramfs命令并执行如下：
update-initramfs -u -k all由于我有多个内核版本，并且预期在某些版本中可能会出现问题(就像以前的测试一样)，所以我重新构建了所有的内核版本。通常，在没有-k all开关的情况下重建最新的可能就足够了。
现在服务器重新启动，没有任何问题，我可以验证微码是否已经更新：
# 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.以前我有0x19，现在和proxmox预期的0x28一样。这些更新似乎没有应用，直到我手动更新了它们。我猜这与(现在)无效的regex模式有关，但最后没有|，这阻止了更新的应用。
https://unix.stackexchange.com/questions/621991
复制相似问题
腾讯云开发者
