嘿，遇到这种内核panic确实头疼，咱们一步步来排查，先从最容易验证的点入手：

1. 先回退旧内核确认问题根源 #

重启虚拟机时，在GRUB启动菜单里选之前能用的那个Fedora 27内核版本（别选4.16.7-200.fc27这个出问题的），看看能不能正常进系统：

• 如果能顺利启动，那百分百是这个新更新的内核搞的鬼，接下来就盯着它排查；
• 如果旧内核也panic，那问题可能出在更新时顺带更的其他组件（比如initramfs、虚拟驱动），得换个方向找原因。

2. 给有问题的内核加启动参数，临时屏蔽可疑点 #

要是你非得测试这个出问题的内核，重启时在GRUB菜单选中它，按e进编辑模式，找到linux开头的那一行，试试加这些参数：

• 加nomodeset：禁用图形相关的内核模式设置，很多时候虚拟机的虚拟显卡适配问题会触发panic；
• 加init=/bin/bash：直接进单用户shell，跳过系统服务初始化，看看能不能正常进入内核，判断是内核本身的问题还是用户空间服务搞的鬼；
• 要是用的KVM虚拟机，加rd.driver.blacklist=virtio_gpu；VMware的话加rd.driver.blacklist=vmwgfx：先把虚拟显卡驱动禁用，排查是不是驱动冲突。
  改完按Ctrl+X启动，看看还会不会panic。

3. 把panic日志抓到手（这是关键！） #

如果还是panic，一定要把报错信息完整记下来：

• 屏幕上的panic内容，尤其是开头的BUG:、Call Trace:部分，这些内核栈回溯信息能直接指出是哪个模块出问题了；
• 要是虚拟机支持串口日志，你可以在宿主机把虚拟机的串口输出定向到一个文件，然后重启触发panic，这样就能完整保存所有日志，不会因为屏幕滚动丢内容。

4. 检查dnf更新记录和内核包完整性 #

回到能正常启动的旧内核，看看这次更新到底装了啥：

• 先跑dnf history，找到最近那次update的ID，再用dnf history info <ID>查看这次更新的所有包，重点盯内核、内核模块、虚拟硬件相关的包（比如kvm-guest-tools、virtio-drivers这类）；
• 检查内核包有没有损坏：执行rpm -V kernel-4.16.7-200.fc27.x86_64，如果输出有文件损坏的标记，说明安装过程出问题了，试试重新装这个内核：dnf reinstall kernel-4.16.7-200.fc27.x86_64，然后重启测试。

5. 排查宿主机虚拟化的兼容性问题 #

毕竟是虚拟机环境，宿主机的配置也可能影响：

• 看看宿主机的内核版本：uname -r，Fedora28的内核会不会和Fedora27的4.16.7内核有兼容性冲突；
• 调整虚拟机硬件配置试试：比如减少虚拟CPU核心数、关掉嵌套虚拟化（如果开了的话）、把虚拟显卡从Virtio换成VMVGA这类传统类型，再重启测试新内核；
• 检查宿主机的虚拟化服务状态：比如KVM的话跑systemctl status libvirtd，看看服务有没有报错，是不是正常运行。

6. 搜已知问题或提交bug #

把你拿到的panic日志里的关键词（比如BUG: unable to handle kernel NULL pointer dereference at加上对应的内存地址，或者出问题的模块名），去Fedora官方的bug跟踪系统搜搜，看看有没有其他用户遇到过同样的问题，有没有现成的解决方案或者临时补丁；
要是没找到已知问题，就整理好你的环境信息（宿主机版本、虚拟机版本、内核版本、完整的panic日志、更新的包列表），提交一个新的bug报告给Fedora项目。

内容的提问来源于stack exchange，提问作者swv