我是 Linux 新手,在 Pop_os 上遇到了这个问题。按 ctrl+d 时,我得到了同样的错误。我还没有尝试任何东西,因为我害怕破坏某些东西。我该怎么做才能恢复正常? 编辑:我使用 journalctl -xb 调查了日志,以下是我发现的一些错误(在系统日志中以红色突出显示):
BIOS Error (bug): Could not resolve symbol
[drm] *ERROR* Port F/TC#3: timeout waiting for PHY ready
Failed to insert module 'autofs4': Invalid argument
Same error with modules 'lp', 'ppdev', 'parport_pc', 'msr', 'kyber_iosched'.
Failed to start Load Kernel Modules.
nvme0n1: /usr/lib/udev/rules.d/60-block-pop.rules:6 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:0e.0/pci10000:e0/10000:e0:1d.0/10000:e1:00.0/nvme/nvme0/nvme0n1/queue/scheduler}, ignoring: invalid argument
loop4: /usr/lib/udev/rules.d/60-block-pop.rules:2 Failed to write ATTR{/sys/devices/virtual/block/loop4/queue/scheduler}, ignoring: Invalid argument
Same with loop 0-7
FAT-fs (nvme0n1p2): IO charset iso8859-1 not found
Failed to mount /recovery
Failed to mount /boot/efi.
正如 telcoM 在评论中所说,BPF 消息可能不相关,并且很可能导致真正的错误从屏幕上滚动出来。
这两种操作(按 ctrl-d 或 enter)都不太可能造成损坏,但可能也无法立即解决问题。如果您准备尝试修复系统,尝试这些操作不会有什么坏处。
如果您按下回车键,您应该能够探索系统并尝试确定错误并可能(部分)修复它。
错误中建议的 journalctl 命令应该有助于查看滚动的完整启动日志,可能会暴露真正的错误,可能是关于找不到磁盘或找不到根磁盘的错误。
比较 lsblk 可用的设备与 fstab 预期的磁盘并
df
检查实际安装的磁盘,可以帮助确定哪一个出现故障(如果您尚未在日志中找到它)。如果故障磁盘并不重要,您可以编辑 fstab(可能必须先重新挂载读写)以注释掉故障磁盘。完成后,您可以退出救援模式并尝试正常启动,然后稍后再探索丢失的磁盘。
如果故障磁盘很重要(例如根磁盘),您可能需要做一些更困难的来修复它,这取决于挂载失败的原因。
您需要使用 root 凭据登录。请尝试建议的“journalctl -xb”,因为它可能会有所帮助。
BPF 消息是内核日志的一部分,而不是引导日志的一部分,看来您的系统很早就出故障了。您的紧急模式很可能来自 initrd(initramdisk),并且常规根目录尚未挂载。“mount”命令会向您显示。
如果是这种情况,您可能需要为您的发行版启动一个实时媒体,或者如果存在的话,启动一个“救援”内核。
分析
您的 imgur 截图表明根文件系统和加密交换都已成功激活,因此问题可能是 中列出的剩余文件系统中的一个或多个
/etc/fstab
。您在日志中发现的错误有多种原因:
这可能只有 BIOS 更新才能修复...并且可能一直存在,只是您没有注意到。
关于显示适配器的某些问题,可能正在探测主板上未连接的端口。
这很有趣...您最近安装了任何更新吗?也许是更新的内核包?一些内核模块似乎出现故障,但这些模块都不是绝对关键的。其中一半与传统并行端口(打印机端口)有关,而现代系统几乎没有这种端口。
udev 规则
/usr/lib/udev/rules.d/60-block-pop.rules
正在尝试切换用于各种文件系统的 I/O 调度程序……并且可能以一种“嘈杂”的方式进行:它似乎正在遍历所有类似磁盘的设备,而不关心该设置是否不适用于特定设备。这可能是您的系统无法启动的最直接原因:它正尝试挂载
/recovery
和/boot/efi
,它们显然都是 FAT 系列的文件系统(可能具体是 FAT32)。但是由于
/etc/fstab
没有iocharset=
为它们定义挂载选项,系统正在尝试使用内置的默认 FAT 系列文件系统 I/O 字符集来挂载它:iso8859-1
。但显然内核不支持它:也许它已配置为可加载模块,但nls_iso8859-1.ko
模块不可用或已以某种方式损坏。或者也许整个文件系统的 ISO8859-1 字符支持完全被排除在最新内核的配置之外,因为有人认为每个现代文件系统都会使用 UTF-8。(那将是一个错误。)所有这些让我怀疑您的系统收到的最新内核更新可能出了问题。也许是 initramfs 创建过程耗尽了磁盘空间,系统现在正在使用不完整的 initramfs 启动,还是其他原因?
要验证这一点,请运行
dpkg --list 'linux-image*' to list the currently-installed kernel packages in your system. If there's more than one, find the highest-version one that does not say
(元包)in the
说明field, and note down in full what its
名称`字段。然后在包管理日志中搜索该名称:替换
<kernel package name>
为您找到的完整软件包名称。这应该会为您提供指示该内核软件包安装时间的日志条目。如果安装日期恰好在问题开始之前,那么您可能已经找到原因。解决方法
如果安装了多个内核,最简单的解决方法是尝试使用第二新的内核版本而不是最新版本来启动系统。我个人不使用 Pop_OS,因此此建议将基于谷歌搜索。Pop_OS 不使用最常见的 Linux 引导加载程序 GRUB,但它似乎使用
systemd-boot
。因此涉及 GRUB 的常规程序将不适用。在启动过程开始时,应该有一个简单的基于文本的菜单,其中包含大约四个项目,以及大约 10 秒的超时时间。它可能看起来像这样:
如果您通常看不到这样的菜单,请尝试在打开系统电源后立即点击 SPACE 键。继续点击它,直到您看到除 BIOS 消息或制造商徽标之外的任何内容,然后您应该会看到上述菜单。
如果只有最新的内核包有问题,选择“旧内核”菜单选项(
Pop!_OS (pop_os-oldkern.conf)
或类似选项)应该可以让系统或多或少正常启动……目前是这样。但您不应该让系统安装任何进一步的更新,直到您找出问题所在并最好修复它为止。如果使用旧内核的系统启动正常,请打开终端窗口并运行
df -h
以查看是否有任何文件系统已 100% 满或接近 100%。特别是,如果文件系统非常满,则可能是导致此故障的根本原因。您的分区(最有可能是您的 EFI 系统分区)/boot/efi
的大小只有 498M,对于多个已安装的内核版本及其 initramfs 文件来说,这个大小可能太小了。/dev/nvme0n1p1
/boot/efi
如果使用较旧的内核启动没有帮助,
Pop!_OS recovery
则启动选项也值得一试。但是,我没有使用过它,所以你应该先阅读System76 的文档。