Linux 启动过程

一、initramfs：启动过程的 "隐形关键"

为什么它是难点？

很多人对 "内核启动" 有基础认知，却极易忽略 initramfs（临时初始化文件系统）的核心作用，甚至系统启动失败后，都想不到问题根源出在这里。新手常存疑惑："内核本身不是自带驱动吗？为什么还需要这个临时系统？"

核心解析

1. **内核的 "轻量化短板"**Linux 内核的设计原则是体积小、效率高，不可能内置所有硬件（如 NVMe 硬盘、RAID 阵列卡、特殊网卡、外置存储控制器）的驱动程序。如果没有 initramfs 的支撑，内核启动后根本无法识别系统盘，直接卡在 "找不到根文件系统" 的致命阶段。

2. initramfs 的本质与使命 它是一个打包好的迷你临时系统，内置了系统启动必需的硬件驱动、文件系统挂载工具、基础初始化脚本，核心作用只有三个：

   • 协助内核识别并初始化所有存储相关硬件；
   • 将硬盘中真正的系统盘挂载到临时目录/sysroot；
   • 完成硬件识别与挂载后，让内核切换到真实根目录，自身完成使命后释放资源。

3. 常见踩坑点

   • 升级内核后未重建 initramfs，导致新内核缺失关键硬件驱动，启动失败；
   • 新手手动修改 initramfs 内部文件，破坏驱动依赖关系，引发启动异常；
   • 存储硬件更换后，未更新 initramfs，内核无法识别新硬件。

实操补充（修复 / 重建 initramfs）

若 initramfs 损坏或缺失驱动，可在救援模式下快速重建：

# 先确认当前系统内核版本
uname -r
# 重建initramfs（自动匹配内核版本，无需手动替换）
dracut /boot/initramfs-$(uname -r).img $(uname -r)

二、target：彻底理清 Linux 的 "启动模式"

为什么它是难点？

老版本 Linux 的 "运行级别"（0-6）与新版的target启动模式极易混淆，新手常犯 "用旧命令操作新模式" 的错误；且救援模式、紧急模式的适用场景模糊，修复系统时选错模式，只会让问题更复杂。

核心解析

1. 旧概念 "运行级别" vs 新概念 "target" 新版 Linux 系统用systemd替代传统init进程，target也取代了原有运行级别，二者核心差异体现在设计逻辑上：

   对比维度	运行级别	target 启动模式
   标识方式	纯数字（如 3 = 命令行、5 = 图形）	语义化命名（如 multi-user.target）
   设计逻辑	固定数字映射，无嵌套关系	基于 "服务集合"，支持嵌套包含
   切换方式	需重启系统才能生效	动态切换，无需重启，即时生效

   关键结论：graphical.target（图形界面）本身包含multi-user.target（多用户命令行）的所有服务，开启图形界面后，依然支持命令行多用户登录。

2. **救援模式（rescue.target）vs 紧急模式（emergency.target）**这是最易混淆的两个修复模式，选对模式是修复系统的前提，二者核心区别如下：

   对比维度	rescue.target（救援模式）	emergency.target（紧急模式）
   根文件系统状态	自动可读写挂载	只读挂载（需手动修改为可读写）
   启动的服务	基础核心服务（网络、存储、shell）	仅启动最简易 shell，无任何服务
   操作难度	低，接近正常命令行环境	高，需手动完成硬件、挂载初始化
   适用场景	服务启动失败、普通配置文件错误、权限问题	根分区损坏、挂载清单严重错误、安全策略彻底紊乱

实操补充（正确切换 / 进入启动模式）

1. 运行中系统动态切换模式（临时生效，重启还原）

# 从图形界面切到纯命令行模式
systemctl isolate multi-user.target
# 从命令行切回图形界面模式
systemctl isolate graphical.target

2. 设置默认启动模式（永久生效，开机自动进入）

# 设置默认进入纯命令行模式（服务器常用）
systemctl set-default multi-user.target
# 设置默认进入图形界面模式（桌面版常用）
systemctl set-default graphical.target
# 验证当前默认启动模式
systemctl get-default

3. 开机时快速进入修复模式

重启系统，打断 GRUB2 启动菜单倒计时，选中对应内核按e进入编辑模式，找到linux开头的内核参数行，在末尾添加以下参数之一，按Ctrl+x启动即可：

• 进入救援模式：systemd.unit=rescue.target
• 进入紧急模式：systemd.unit=emergency.target

三、重置 root 密码：SELinux 标记是 "必踩坑点"

为什么它是难点？

新手重置 root 密码时，往往只记得核心的 "改密码" 步骤，却忽略 SELinux 安全上下文的自动重标记，导致重启后密码修改无效、无法登录系统。核心原因是：在临时启动环境中修改的密码文件，缺少正确的 SELinux 权限标记，系统会判定文件异常并拒绝识别。

核心解析

1. SELinux 的 "文件安全校验" Linux 系统中强制启用的 SELinux 安全机制，会为每个文件分配 "上下文标记"，用于严格控制文件的访问权限。存储密码的核心文件/etc/shadow，若标记异常，即使密码修改正确，系统也会拒绝 root 用户的登录请求。

2. touch /.autorelabel的关键作用 创建这个文件，是告诉系统：下次启动时，自动重新扫描所有文件，修复异常的 SELinux 上下文标记。这一步是重置密码的 "收尾关键"，跳过则必然导致密码修改无效，这也是 90% 新手踩坑的核心点。

完整避坑版重置步骤（全程无错）

# 1. 临时系统中，将真实系统盘改为可读写挂载
mount -o rw,remount /sysroot
# 2. 切换到真实的系统环境中
chroot /sysroot
# 3. 执行密码修改命令，按提示输入新密码并确认
passwd
# 4. 核心步骤：创建SELinux重标记文件（必做！）
touch /.autorelabel
# 5. 退出并重启系统，等待重标记完成即可
exit && exit

四、/etc/fstab：开机卡壳的 "高频元凶"

为什么它是难点？

/etc/fstab作为系统的 "自动挂载清单"，语法、参数、设备标识稍有错误，就会导致系统启动卡壳；且新手极易滥用nofail参数，看似 "避免启动故障"，实则为生产环境埋下致命隐患。

核心解析

1. fstab 的核心语法规则 文件中一行对应一个设备的自动挂载配置，固定格式为：设备标识 挂载点 文件系统类型 挂载参数 备份标记 自检顺序示例 ：UUID=123456-ABCD /data ext4 defaults 0 0

三大高频易错点

• 设备标识写错：推荐用 UUID（唯一不变），避免用分区名（如/dev/sda1，硬件顺序变化会失效），可用blkid命令查询正确 UUID；
• 挂载点不存在：系统无法挂载到不存在的目录，需提前用mkdir创建；
• 挂载参数冲突：如同时写ro（只读）和rw（可读写），直接触发启动异常。

1. nofail参数的 "隐形坑" nofail的作用是 "挂载失败时，不影响系统正常启动"，但新手常给所有挂载项 添加该参数，引发严重后果：
   • 场景：核心数据盘配置nofail后，若磁盘故障导致挂载失败，系统仍会正常启动；
   • 后果：业务程序往数据盘挂载目录写数据时，实际会写入根分区，最终撑满根分区导致整个系统崩溃；
   • 正确用法：仅对非核心、可缺失 的挂载项（如 U 盘、备用临时盘）添加nofail，核心系统盘、数据盘绝对禁止使用！

实操补充（快速定位并修复 fstab 错误）

当系统因 fstab 错误卡壳并进入紧急 shell 后，按以下步骤操作：

# 1. 将根分区修改为可读写，才能编辑fstab文件
mount -o rw,remount /
# 2. 检查所有挂载项，输出详细错误信息，定位问题点
mount --all
# 3. 编辑fstab文件，修复错误配置（注释/修改错误行）
vi /etc/fstab
# 4. 重新加载系统配置，让修改生效
systemctl daemon-reload
# 5. 再次验证挂载，无报错则说明修复成功
mount --all
# 6. 重启系统，恢复正常启动
reboot

五、journalctl：排查启动错误的 "核心工具"

为什么它是难点？

默认情况下，journalctl的系统日志为临时存储，系统重启后日志丢失；新手既不知道如何配置日志持久化，也不会精准筛选启动相关的错误日志，排查问题时只能盲目尝试。

核心解析

1. **日志持久化配置（一次配置，永久生效）**要保留历史启动日志，需修改 journald 的配置文件，让日志永久存储到硬盘中：

   编辑日志配置文件

   vi /etc/systemd/journald.conf

   找到Storage项，修改为以下内容（取消注释并改值）

   Storage=persistent

   重启日志服务，让配置生效

   systemctl restart systemd-journald

配置后，日志会永久存储在/var/log/journal目录，重启后不会丢失，可随时查询历史启动记录。

1. 精准筛选启动错误日志的实用命令 journalctl的核心优势是按启动周期、日志级别筛选，告别海量日志中翻找错误的低效操作，常用命令如下：

   查看上一次启动的所有错误日志（最常用，快速定位启动故障）

   journalctl -b -1 -p err

   查看本次启动的所有日志，按时间倒序排列

   journalctl -b 0 -r

   查看最近10分钟的启动相关日志，实时刷新

   journalctl -b 0 --since "10 minutes ago" -f

   筛选挂载清单（fstab）相关的启动错误

   journalctl -b -1 | grep -i fstab

   查看所有启动周期的日志，按启动时间分类

   journalctl --list-boots

参数说明 ：-b指定启动周期（0本次、-1上一次、-2上两次）；-p指定日志级别（err错误、warn警告、info信息）。