在最近的公司计算机上启动期间崩溃

经过一些最近的更新后，我的计算机不再启动！这是我可以确定的：

• 这是公司IT向我提供的最新计算机。它具有最新的Intel CPU（Skylake一代）。
• 该计算机运行Ubuntu 16.04。
• 上一次在三月份的某个时间正确启动了计算机。该问题可能是由于软件更新或硬件错误引起的。
• 我有一台运行16.04的计算机，安装了几乎相同的软件（我使用过apt-clone），并且工作正常。它具有不同的硬件（也为amd64，但具有不同的CPU，不同的GPU等）。
• 内核确实启动，initrd正常工作。在图形模式下使用启动屏幕启动时，系统提示输入dm-crypt卷的密码，最后我看到的是它已成功安装。
• 挂起发生在我得到登录提示之前。当计算机挂起时，这很困难。甚至Alt+ SysRq都没有回应。由于风扇完全爆炸，因此CPU显然固定在100％。
• 重新启动之前，我仍然有运行中的内核。当我在Grub菜单中选择此内核时，我得到了相同的锁定。因此，这似乎是一个预先存在的内核错误，该错误由其他原因触发-但是呢？
• 如果我关闭了启动画面（splash从linuxGrub中的命令行删除），则看到许多服务正在启动，然后它将锁定。

• 我可以通过添加得到一个root shell init=/bin/sh到linux在GRUB命令行。我什至可以通过添加进一步

  systemd.unit=basic.target systemd.shell
  

  这将启动许多服务，并在tty9上运行根shell。

• 如果我systemctl start multi-user.target从该根外壳运行，则计算机将锁定。因此，大概是这些服务之一触发了问题。
• 我跑去systemctl list-dependencies multi-user.target看什么服务开始。我一一手动启动了列出的依赖项，一切开始正常。

因此，这看起来像是由某些软件触发的硬件错误（因为它发生在一台计算机上，而不是另一台计算机上）。但是什么软件？由于计算机锁定非常困难，因此无法获取任何日志。我什至无法获得任何有用的控制台输出。

有用的调试技术：

• Alt+ SysRq：魔术SysRq键，可让您执行紧急重启之类的操作。它以非常低的级别访问内核，因此除了最严重的崩溃外，它都能正常工作。就我而言，Alt+ SysRq不会响应，这表明崩溃的程度。
• 要修改启动参数，请Shift在打开电源后按住几秒钟。在BIOS初始化键盘之后，但在操作系统引导之前，您需要按一下它。这将使Grub菜单出现。
• 在Grub菜单上，按e编辑菜单项的命令行。要更改Linux引导参数，请导航至以开头的行linux。在现代Ubuntu上，您会在“ Ubuntu的高级选项”下找到旧内核。对命令行进行所需的更改后，请按Ctrl+ x引导。您在此处所做的任何更改仅用于此引导，它们不会保存到磁盘。
• linux命令行上一些有用的选项：
  • quiet nosplash隐藏几乎所有引导消息。删除它们以在启动期间在控制台上获取消息，这对于诊断问题是必须的。
  • recovery为您提供了几乎没有服务的root shell。您需要知道root密码。“恢复模式”菜单项使用此选项。
  • init=/bin/sh为您提供了根本没有服务的root shell。要恢复正常引导，请运行exec init。您可以在此时传递systemd选项，例如exec init --unit=basic.target，启动init和一些服务（请注意，这不会以任何方式启动登录，因此最好在另一个控制台上运行shell）。注意，根文件系统是只读安装的；运行mount -o remount,rw /以能够对其进行写入。
  • systemd.unit=basic.target启动一组非常基本的服务。请注意，这不包括任何登录方式！您可以通过systemctl set-default basic.target在根目录提示符下运行将其设置为默认值。要恢复原始的默认目标，请运行systemctl set-default graphical.target（或systemctl set-default multi-user.target对于没有GUI的服务器）。
  • systemd.debug-shell在tty9上启动根shell。您可以通过systemctl enable debug-shell在根提示符下运行来为每次引导启用此功能。解决的问题后，别忘了禁用此功能systemctl disable debug-shell。按Alt+ F9切换到tty9。
  • 另请参阅Fedora systemd提示，Arch Linux引导问题提示。

问题

事实证明，我的问题是（某些）Skylake CPU上的最新Intel微代码与最新Linux内核之间的已知问题，这主要是由sssd触发的。请参见Ubuntu错误＃1759920“英特尔微码3.20180312.0导致登录屏幕锁定（带有linux-image-4.13.0-37-generic）”，以及许多其他错误，它们都是相同的问题。 ，例如Ubuntu错误＃1746806“ sssd似乎使AWS c5和m5实例崩溃，导致100％CPU”和Ubuntu错误＃1746418“在安装linux-image-4.13.0-32-generic后启动Xorg时系统冻结”。在以下情况下，您可能会遇到此错误：

• 您有一个非常新的Intel CPU。据我所知，此错误仅出现在Skylake CPU上。
• 您已经安装了英特尔微码软件包。恢复到较早的，经过测试的内核对我来说不起作用，因为我只能使用较早的微代码运行该内核。
• 您的计算机已连接到公司网络（通常为LDAP或Active Directory）以进行用户身份验证。尽管还有其他方法可以触发该错误，但是运行sssd似乎是最常见的罪魁祸首。也有Xorg崩溃的报告。

该错误是由于缓解了2018年1月发布的Spectre安全问题所致。某些内核代码与某些处理器微代码之间不兼容，从而在某些情况下导致锁定。

如何修理

1. 如果无法正常启动，则需要在Grub提示符下编辑内核命令行。请参阅问题以获取解释以及获取root shell的可能方法。
2. 解决此特定错误的方法是将noibpb参数添加到内核​​命令行（1746418 / 14，1759920/56）。这样可以使您正常启动并进行一些修复。
   这将禁用导致问题的漏洞缓解，这意味着您的计算机现在容易受到某些攻击。它们是本地攻击，即攻击者需要在您的计算机上运行代码，但是这些攻击可能例如通过Web浏览器中的JavaScript进行。
   如果您没有其他方法，可以通过添加noibpb到内核​​命令行来使其永久化，直到获得固定的内核为止。
3. 在Ubuntu中，该修复程序预计于2018年4月23日这一周发布，大概是内核4.4.0-117和4.13.0-39。同时，Tyler Hicks发布了4.4和4.13的测试内核。

我如何诊断问题

我尝试了几件事（请参阅问题），并确定该错误是在到达basic.target和到达之间触发的multi-user.target。因此，我将默认的systemd目标设置为basic.target（systemctl set-default basic.target），并启用了debug-shell服务（systemctl enable debug-shell）以获取根shell。

我运行systemctl list-dependencies multi-user.target并手动启动列出的依赖项。这没有触发崩溃。

并非所有服务都由systemd直接管理。有些作为Upstart服务管理，有些作为SysVinit脚本管理。下面的shell脚本将运行所有这些脚本。注意：我只测试了一次，并且设计使它崩溃了。

#!/bin/sh
wants=$(systemctl show -p Wants multi-user.target | sed 's/^Wants=//' | tr ' ' '\n' | sort)
log=/var/tmp/multi-user-steps-$(date +%Y%m%d-%H%M%S)

log () {
  echo "$* ..." | tee -a "$log"
  sync
  "$@"
  ret=$?
  echo "$* -> $ret" | tee -a "$log"
  sync
  return $ret
}

# systemd services
for service in $wants; do
  log systemctl start $service
  sleep 2
done

# upstart services
for conf in /etc/init/*.conf; do
  service=${conf##*/}; service=${service%.conf}
  log service ${service} start
  sleep 2
done

# sysvinit services
for service in /etc/rc3.d/S*; do
  log ${service} start
  sleep 2
done

启动后我的计算机崩溃了sssd。从那里，在“ sssd linux kernel hang”上进行的网络搜索将我带到https://bugs.launchpad.net/cloud-images/+bug/1746806以及诊断和解决方案。