Ubuntu启动时看不到自检进度，是因为默认启用quiet splash参数抑制了内核和systemd日志输出；需在GRUB中临时删除这两个参数，或永久修改/etc/default/grub并执行sudo update-grub，还可通过journalctl -b、dmesg、/var/log/kern.log等回溯自检过程。
Ubuntu启动时看不到自检进度？先确认是否禁用了内核日志输出
默认情况下，Ubuntu（尤其是22.04+桌面/服务器版）在启动时会隐藏大部分内核和init进程的输出，只显示一个小logo或空白屏，看起来像“卡住”——其实不是没在自检，而是输出被抑制了。真正的问题往往出在quiet和splash这两个内核参数上。
它们被写在GRUB配置里，导致dmesg、驱动加载、systemd单元启动等过程全被静音。要看到真实自检进度，必须临时或永久移除它们：
- 重启时按住
Shift（BIOS模式）或连续按Esc（UEFI模式）进GRUB菜单 - 用方向键选中当前启动项，按
e编辑启动参数 - 找到以
linux开头的行，删掉其中的quiet splash - 按
Ctrl+X或F10启动——此时你会看到滚动的内核消息、设备探测、服务启动顺序等原始自检过程
如何持久化启用启动日志输出（不靠每次手动编辑）
临时改GRUB只能看一次，想每次开机都显示，得改/etc/default/grub并更新配置：
- 编辑文件：
sudo nano /etc/default/grub - 找到这一行：
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" - 改成：
GRUB_CMDLINE_LINUX_DEFAULT=""（清空）或至少去掉quiet splash，比如保留网络调试参数：GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3" - 保存后运行：
sudo update-grub - 下次重启就自动显示完整初始化流程了
loglevel=3 是个折中选择：既避免loglevel=7（全量日志）带来的刷屏干扰，又能显示关键服务启动、硬件检测、错误警告等有效自检信息。
启动完成后怎么回溯自检过程？查journalctl -b最可靠
即使你没开启动日志，systemd也会把整个引导过程记下来。只要系统能正常进桌面或命令行，就能用journalctl还原当时发生了什么：
Ubuntu 26.04 LTS（代号“Resolute Raccoon”）是Canonical于2026年4月23日发布的下一代长期支持版操作系统，提供长达10年的技术支持。它搭载Linux 7.0内核与GNOME 50桌面环境，全面转向Wayland协议，并引入Rust重写的核心工具以增强安全性。官方提供适用于AMD64和ARM64架构的桌面及服务器ISO镜像，是追求前沿技术与极致稳定的开发者
-
journalctl -b：查看本次启动的所有日志（从内核第一条消息到登录管理器启动） -
journalctl -b -p err：只看启动过程中的错误（err级别），快速定位失败服务 -
journalctl -b | grep -i "failed\|error\|timeout"：关键词过滤，比翻全量日志高效 - 加
-n 50限制行数，比如journalctl -b -n 50看最后50行，常用于判断卡在哪一步
注意：journalctl -b 默认只保留最近几次启动日志（取决于/etc/systemd/journald.conf中MaxRetentionSec设置），老的日志会被自动轮转清理。
哪些日志文件能直接反映自检阶段的关键节点？
除了journalctl，几个静态日志文件也值得打开扫一眼，尤其当你怀疑是硬件或早期初始化失败时：
-
/var/log/boot.log：记录systemd启动前的init阶段（如rc.local执行、模块加载），但Ubuntu 22.04+默认不生成此文件，需手动启用rsyslog服务 -
/var/log/dmesg：内核环缓冲区快照，包含设备识别、驱动绑定、内存检测等底层自检结果；sudo dmesg -H可带颜色和时间戳阅读 -
/var/log/syslog：混合日志，含systemd、udev、网络服务等，适合查服务级自检失败（比如network-manager超时） -
/var/log/kern.log：纯内核消息，比dmesg更持续，适合排查显卡、存储控制器等硬件兼容性问题
真正容易被忽略的是：这些日志里的时间戳全是UTC，而你的系统时区可能已设为本地——别用肉眼比对“12:03:45”是否合理，先timedatectl status确认时区设置是否一致。
