「记录」解决Ubuntu Server 18.04因Intel微码修复无法启动问题

最近在重建学院GPU云，使用原来实验室云的双层虚拟化架构。原来实验室云使用的是基于ubuntu16的GPU服务器，21年再使用16版本就有点老了，准备换成ubuntu18，但是遇到一个奇怪的问题，在此记录一下。

问题的表现形式如下：

环境：

实体机：曙光 天阔 W780-G20
操作系统： VMware ESXi, 6.7.0, 14320388
管理平台： VMware vCenter Server Appliance, 6.7.0, 15129973
虚拟机兼容性： ESXi 6.7 Update 2
虚拟机高级配置附加参数：
hypervisor.cpuid.v0 = FALSE
pciPassthru.use64bitMMIO = TRUE
虚拟机操作系统版本：Ubuntu Server 18.04.5 LTS
截止2021年1月20日，已更新所有最新包

当虚拟机CPU只给一个核心的时候，一切正常。当给2个或者更多核心的时候会出现无法启动的问题，显示如下：

经过排查发现问题触发的原因有两个：①虚拟机高级配置参数 hypervisor.cpuid.v0 = FALSE；②有2个或更多CPU核心

通过搜索找到两篇类似问题的文章：ESXi 6.7 ubuntu GPU直连踩坑记、VMware ESXi 6.7.0 update2 使用 GPU Passthrough 模式的坑。第一篇文章是通过更新esxi解决的，但是第一篇文章里更新后的esxi版本与我现在使用的是同一版本，所以解决方法对我不适用。第二篇文章将问题的根源指向了intel的漏洞修补微码软件包“intel-microcode”。

通过测试发现，无法启动的核心问题就是由“intel-microcode”导致的，该软件包是intel为了修补幽灵、熔断漏洞的补丁，应该是在启动之前执行某种防护操作。我测试时首先尝试卸载该软件包，并同时卸载依赖包，结果导致部分核心包被卸载，无法启动。之后测试只卸载该软件包，不卸载依赖，结果问题解决，确定问题核心就是该软件包导致。

为了解决问题，我首先想到的是在安装vsphere过程中被提示可能受intel的漏洞影响，所以我考虑可能是虚拟化平台的宿主机没有进行漏洞修补，而ubuntu虚拟机进行了漏洞修补，出现兼容性问题。为此我查阅了vsphere的文档，确定默认状态下vsphere6.7确实是不启用漏洞修补程序的。同时，我也发现启动修补程序会导致严重的性能损失，不适合我现在的场景。

之后，我考虑既然虚拟化平台没有进行漏洞修补，那关掉ubuntu虚拟机的漏洞修补应该可以解决问题。于是我阅读了第二篇文章中提到的讨论：Intel-microcode package upgrade in ubuntu 18.04 leads to unbootable system。根据这个讨论，可以通过更改grub参数的方式禁用微码修补，但是尝试了讨论中的解决方案和关联的解决方案，发现并没有效果。最终，我决定按照讨论中的最终解决方案，更换旧版本的二进制软件包。

解决方案：