Linux上持久的微代码更新

1

我只是按照英特尔的指示尝试更新我的英特尔酷睿i3-3217U处理器的微码。我在Linux Mint Debian第2版（3.16.0-5-amd64内核）上。

我做了什么：

有一个 /sys/devices/system/cpu/microcode/reload
没有/lib/firmware/intel-ucode，只有一个/lib/firmware/intel。我从下载的软件包中添加了文件夹。

根据指令，我执行了SU

echo 1 > /sys/devices/system/cpu/microcode/reload

cat /proc/cpuinfo | grep microcode给我0x1f，这是更新版本 - 但只要系统正在运行。重启后我回来了0x12。

如何使更新永久化？

— ccprog
source

2

您无法使Intel微码更新成为永久更新，必须在每次启动后加载。微代码存储在CPU的易失性RAM中。

— 约翰·梅伦
source

2

作为微代码更新未移植到Debian中的中间解决方案，您可以在按照Intel指令安装微代码更新后将“echo 1> / sys / devices / system / cpu / microcode / reload”添加到/etc/rc.local。这是一个相当晚的修补，但如果你相信你的启动环境可能没问题:)

— port443
source

1

我发现我可以利用debian package intel-microcode的代码将微代码加载到初始ramdisk 。目前这是微代码的旧版本，但它们可以被覆盖。

安装软件包后，我手动删除了所有文件，/lib/firmware/intel-ucode并用英特尔下载的新版本替换它们。从那以后，我可以更新initrd.img-<kernel version>与

update-initramfs -u

grub-mkconfig 也会执行这个。

据我了解，intel-ucode.img其他答案中提到的将是所谓的“早期initramfs存档”。似乎包中包含的initramfs-tools钩子脚本会自行选择将更新模块放在单独的.img中还是放在主initrd.img中。

编辑：似乎新的微代码版本已经落入不稳定的包中。依赖关系没有改变，所以他们可能会在Debian延伸（或jessie，我仍在使用）上工作。我怀疑只有几天才能向后移植新的软件包版本。然后，安装就足够了。

— ccprog
source

0

在引导期间应用微码更新，因此应将其添加到引导加载程序，例如GRUB2或systemd-boot。更具体地讲，/boot/intel-ucode.img（或任何该文件位于系统上）应该作为你的引导过程的第一个initrd镜像（但应该不能取代正常的initrd镜像）。安装微码更新包后，grub-mkconfig脚本通常会自行处理，但您可以检查/boot/grub/grub.cfg文件是否有类似的行：

initrd  /intel-ucode.img /initramfs-linux.img

如果没有，您可以重新安装微代码包，也可以手动运行grub-mkconfig脚本。

— 古里
source

英特尔下载不包括.img文件，但仅包括原始微码。它必须在本地构建一个模块，请参阅我的答案。

— ccprog

Debian约定确实将微代码构建为现有内核映像的模块，但我建议重新安装微代码包仍然存在。来自Debian Stretch中intel-microcode包的README文件：在默认的Debian系统上（使用Debian内核，grub引导程序和initramfs-tools为内核创建initramfs），安装“intel-microcode”包及其依赖项，并重新启动。

— kori

正如我所说，唯一需要注意的是，目前包中包含的微代码版本比英特尔发布的版本要早。在安装软件包之后，有一个安装后挂钩来更新initrd.img。要获得新版本，您必须在交换微代码文件后手动重新构建。

— ccprog

1

哦，我完全错过了你直接从英特尔下载的部分！我为此道歉。您可以尝试使用弹性后挡板来获得更新版本，但它仍然可能已过时（3.20171117）。如果你感觉很幸运，你可以安装Sid（不稳定）的软件包，它有当前版本的3.20180312.1 - 查看依赖项及其版本，它实际上应该可以直接使用。

— kori

感谢链接，我错过了那个。Deps没有变化，所以很快就会出现这种情况。

— ccprog