Linux 启动过程
一、initramfs：启动过程的 “隐形关键”
为什么它是难点？
很多人对 “内核启动” 有基础认知，却极易忽略 initramfs（临时初始化文件系统）的核心作用，甚至系统启动失败后，都想不到问题根源出在这里。新手常存疑惑：“内核本身不是自带驱动吗？为什么还需要这个临时系统？”
核心解析
内核的 “轻量化短板”Linux 内核的设计原则是体积小、效率高，不可能内置所有硬件（如 NVMe 硬盘、RAID 阵列卡、特殊网卡、外置存储控制器）的驱动程序。如果没有 initramfs 的支撑，内核启动后根本无法识别系统盘，直接卡在 “找不到根文件系统” 的致命阶段。
initramfs 的本质与使命它是一个打包好的迷你临时系统，内置了系统启动必需的硬件驱动、文件系统挂载工具、基础初始化脚本，核心作用只有三个：
- 协助内核识别并初始化所有存储相关硬件；
- 将硬盘中真正的系统盘挂载到临时目录
/sysroot； - 完成硬件识别与挂载后，让内核切换到真实根目录，自身完成使命后释放资源。
常见踩坑点
- 升级内核后未重建 initramfs，导致新内核缺失关键硬件驱动，启动失败；
- 新手手动修改 initramfs 内部文件，破坏驱动依赖关系，引发启动异常；
- 存储硬件更换后，未更新 initramfs，内核无法识别新硬件。
实操补充（修复 / 重建 initramfs）
若 initramfs 损坏或缺失驱动，可在救援模式下快速重建：
# 先确认当前系统内核版本 uname -r # 重建initramfs（自动匹配内核版本，无需手动替换） dracut /boot/initramfs-$(uname -r).img $(uname -r)二、target：彻底理清 Linux 的 “启动模式”
为什么它是难点？
老版本 Linux 的 “运行级别”（0-6）与新版的target启动模式极易混淆，新手常犯 “用旧命令操作新模式” 的错误；且救援模式、紧急模式的适用场景模糊，修复系统时选错模式，只会让问题更复杂。
核心解析
旧概念 “运行级别” vs 新概念 “target”新版 Linux 系统用
systemd替代传统init进程，target也取代了原有运行级别，二者核心差异体现在设计逻辑上：对比维度 运行级别 target 启动模式 标识方式 纯数字（如 3 = 命令行、5 = 图形） 语义化命名（如 multi-user.target） 设计逻辑 固定数字映射，无嵌套关系 基于 “服务集合”，支持嵌套包含 切换方式 需重启系统才能生效 动态切换，无需重启，即时生效 关键结论：
graphical.target（图形界面）本身包含multi-user.target（多用户命令行）的所有服务，开启图形界面后，依然支持命令行多用户登录。救援模式（rescue.target）vs 紧急模式（emergency.target）这是最易混淆的两个修复模式，选对模式是修复系统的前提，二者核心区别如下：
对比维度 rescue.target（救援模式） emergency.target（紧急模式） 根文件系统状态 自动可读写挂载 只读挂载（需手动修改为可读写） 启动的服务 基础核心服务（网络、存储、shell） 仅启动最简易 shell，无任何服务 操作难度 低，接近正常命令行环境 高，需手动完成硬件、挂载初始化 适用场景 服务启动失败、普通配置文件错误、权限问题 根分区损坏、挂载清单严重错误、安全策略彻底紊乱
实操补充（正确切换 / 进入启动模式）
1. 运行中系统动态切换模式（临时生效，重启还原）
# 从图形界面切到纯命令行模式 systemctl isolate multi-user.target # 从命令行切回图形界面模式 systemctl isolate graphical.target2. 设置默认启动模式（永久生效，开机自动进入）
# 设置默认进入纯命令行模式（服务器常用） systemctl set-default multi-user.target # 设置默认进入图形界面模式（桌面版常用） systemctl set-default graphical.target # 验证当前默认启动模式 systemctl get-default3. 开机时快速进入修复模式
重启系统，打断 GRUB2 启动菜单倒计时，选中对应内核按e进入编辑模式，找到linux开头的内核参数行，在末尾添加以下参数之一，按Ctrl+x启动即可：
- 进入救援模式：
systemd.unit=rescue.target - 进入紧急模式：
systemd.unit=emergency.target
三、重置 root 密码：SELinux 标记是 “必踩坑点”
为什么它是难点？
新手重置 root 密码时，往往只记得核心的 “改密码” 步骤，却忽略 SELinux 安全上下文的自动重标记，导致重启后密码修改无效、无法登录系统。核心原因是：在临时启动环境中修改的密码文件，缺少正确的 SELinux 权限标记，系统会判定文件异常并拒绝识别。
核心解析
SELinux 的 “文件安全校验”Linux 系统中强制启用的 SELinux 安全机制，会为每个文件分配 “上下文标记”，用于严格控制文件的访问权限。存储密码的核心文件
/etc/shadow，若标记异常，即使密码修改正确，系统也会拒绝 root 用户的登录请求。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参数，看似 “避免启动故障”，实则为生产环境埋下致命隐患。
核心解析
- fstab 的核心语法规则文件中一行对应一个设备的自动挂载配置，固定格式为：
设备标识 挂载点 文件系统类型 挂载参数 备份标记 自检顺序示例：UUID=123456-ABCD /data ext4 defaults 0 0
三大高频易错点
- 设备标识写错：推荐用 UUID（唯一不变），避免用分区名（如
/dev/sda1，硬件顺序变化会失效），可用blkid命令查询正确 UUID； - 挂载点不存在：系统无法挂载到不存在的目录，需提前用
mkdir创建； - 挂载参数冲突：如同时写
ro（只读）和rw（可读写），直接触发启动异常。
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的系统日志为临时存储，系统重启后日志丢失；新手既不知道如何配置日志持久化，也不会精准筛选启动相关的错误日志，排查问题时只能盲目尝试。
核心解析
- 日志持久化配置（一次配置，永久生效）要保留历史启动日志，需修改 journald 的配置文件，让日志永久存储到硬盘中：
# 编辑日志配置文件 vi /etc/systemd/journald.conf # 找到Storage项，修改为以下内容（取消注释并改值） Storage=persistent # 重启日志服务，让配置生效 systemctl restart systemd-journald配置后，日志会永久存储在/var/log/journal目录，重启后不会丢失，可随时查询历史启动记录。
- 精准筛选启动错误日志的实用命令
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信息）。