Manjaro(ArchLinux)加载内核模块失败

Published on Jul 28, 2020

前言

笔记本上安装的 Win10Manjaro 双系统, 使用 Grub2 引导。 前几天在 Manjaro 系统执行系统升级 pacman -Syyuu, 重启后发现无法正常进入 Manjaro 系统。 报错信息如下:

[FAILED] Failed to start Load Kernel Modules.
[FAILED] Failed to mount /boot/efi.
[DEPEND] Dependency failed for Local File System.

解决方案

出现这个问题的最直观原因就是升级了linux内核,导致系统无法正常启动。 而更深层次的原因(“为什么升级了linux内核,就导致了系统无法正常启动”),可能是多种多样的。

所以,解决方案也有两种。 第一种,内核降级,回滚到升级前的版本(治标)。 第二种,找到深层次的原因,对症下药(治本)。

方案一:内核降级

  1. 进入紧急模式(Emergency Mode)

    当系统停止在报错页面后,尝试按键 Ctrl + Alt + F2 打开一个新的终端(tty),使用 root 用户登入系统;

  2. 确认升级之前的内核版本号

    可以从pacman的日志文件 /var/log/pacman.log 中找到需要的信息:

    cat /var/log/pacman.log | grep "upgraded linux" | tail -n10
    
    [2020-04-26T16:28:36+0800] [ALPM] upgraded linux-firmware (20200320.r1602.edf390c-1 -> 20200421.r1628.78c0348-1)
    [2020-04-26T16:28:38+0800] [ALPM] upgraded linux419 (4.19.114-1 -> 4.19.117-1)
    [2020-05-01T13:45:40+0800] [ALPM] upgraded linux-firmware (20200421.r1628.78c0348-1 -> 20200424.r1632.b2cad6a-1)
    [2020-05-01T13:45:48+0800] [ALPM] upgraded linux419 (4.19.117-1 -> 4.19.118-1)
    [2020-05-16T23:03:15+0800] [ALPM] upgraded linux419 (4.19.118-1 -> 4.19.121-1)
    [2020-05-20T16:34:39+0800] [ALPM] upgraded linux419 (4.19.121-1 -> 4.19.122-1)
    [2020-06-03T20:39:05+0800] [ALPM] upgraded linux-api-headers (5.4.17-1 -> 5.6.11-1)
    [2020-06-03T20:39:45+0800] [ALPM] upgraded linux-firmware (20200424.r1632.b2cad6a-1 -> 20200519.r1641.8ba6fa6-1)
    [2020-06-03T20:39:54+0800] [ALPM] upgraded linux419 (4.19.122-1 -> 4.19.125-1)
    [2020-07-22T09:04:34+0800] [ALPM] upgraded linux419 (4.19.125-1 -> 4.19.133-1)
    

    可以看到,最后一次内核升级是从 4.19.125 升级到 4.19.133。

  3. 执行降级安装

    pacman -U /var/cache/pacman/pkg/linux419-4.19.125-1-x86_64.pkg.tar.xz
    
  4. 重启

    reboot
    

方案二:找深层次原因,对症下药

找深层次原因,确实是一件费时费力的活。 找原因的过程我就略过不讲了,太琐碎了,就是各种google,各种尝试。 最终确定了是因为pacman安装的内核版本和进入系统时加载的内核版本不同, 这个描述可能并不正确,毕竟我也没理解透彻。

其实是 uname -rpacman -Q linux 两个命令显示的linux内核版本不同。

$ uname -r
4.19.125-1-MANJARO

$ pacman -Q linux
linux419 4.19.133-1

至于为什么会出现这个现象,原理(理论知识)上我现在也讲不明白。 但是跟系统的启动引导肯定有关系。 查看 /etc/fstab 配置,发现 EFI系统分区 是挂载到 /boot/efi 目录的。 因此又回想到,再往前一段时间,因为笔记本开机无法进入 GRUB引导 页面, 而是直接进入Win10系统, 我通过 archlinux livecd U盘 修复过一次 grub 引导(修复过程找机会再写一遍文章记录一下)。 当时我是把 EFI系统分区 直接挂载到了 /boot ,且在执行 grub-install 时, --efi-directory 参数指定的也是 /boot 目录。 最后试验证明,问题确实在这,修复(即验证)步骤如下:

  1. 通过方案一回滚内核版本后,正常进入系统
  2. 确认EFI系统分区确实是挂载到了 /boot/efi 目录

    mount | grep "boot"
    # OR
    findmnt /boot/efi
    
  3. 重新执行 grub-install

    grub-install --recheck /dev/sda --efi-directory=/boot/efi
    update-grub
    
  4. 再次升级内核

    pacman -Syyuu
    
  5. 重启

    reboot
    

命令汇总

# 查看系统信息
uname -a
# 查看已安装的linux包
pacman -Q linux
# 分析所有可用模块
depmod -an
# 查看硬盘分区表
fdisk -l
# 查看所有可用块设备的信息
lsblk -f
# fstab文件可用于定义磁盘分区、各种其他块设备或远程文件系统该如何装入文件系统
# 每个文件系统在一个单独的行中描述。这些定义将在引导时动态地转换为系统挂载单元,并在系统管理器的配置重新加载时转换。
cat /etc/fstab
mount | grep "boot"
findmnt /boot
systemctl status systemd-modules-load.service
systemctl status boot-efi.mount
grep "crypto_user" -r /etc/modules-load.d /usr/lib/modules-load.d
pacman -Qo /usr/lib/modules-load.d/bluez.conf
pacman -Rsc bluez

参考