1. 问题引入当你的Linux世界在启动时“宕机”作为一名和Linux系统打了十几年交道的运维老兵我处理过无数千奇百怪的启动故障。但有一种报错每次看到它都意味着一个相对棘手的排查过程开始了——那就是屏幕上赫然出现的Kernel panic - not syncing: No working init found.。这行红字对于任何Linux管理员来说都像是一个刺耳的警报它宣告着内核已经完成了自己的引导工作却找不到那个至关重要的“第一号进程”来接手最终只能选择“恐慌”panic并停止一切。这不仅仅是内核的失败更是整个系统启动链条的断裂。今天我们就来彻底拆解这个经典问题从内核的视角出发一步步还原它发生的场景、背后的原理并给出从新手到老手都能上手的完整排查与修复指南。无论你是在实体服务器、虚拟机还是嵌入式设备上遇到它这篇文章都将帮你理清思路找到症结。2. 内核启动的最后一公里从init到用户空间要理解“No working init found”我们必须先搞清楚Linux内核启动的终点在哪里。很多人以为内核启动完毕就是系统启动完毕这是一个常见的误解。实际上内核的启动是一个“交棒”的过程。2.1 内核启动的终局与init的使命当内核完成硬件初始化、加载了必要的驱动、挂载了根文件系统rootfs之后它的核心任务就接近尾声了。此时内核需要找到一个可以执行的用户空间userspace程序并将系统的控制权完全交给它。这个被选中的程序就是“init”进程它的进程号PID固定为1。PID 1是一个具有特殊意义的进程它是所有其他用户空间进程的祖先负责启动和管理系统的各项服务如网络、登录、定时任务等。内核是如何找到这个init程序的呢它遵循一个明确的查找顺序内核命令行参数init这是优先级最高的指定方式。例如在GRUB的启动参数中你可以看到类似init/bin/bash或init/sbin/init的配置。内核会直接尝试执行这个路径指定的程序。编译时指定的备用路径如果init参数未指定内核会尝试几个硬编码的备用路径。历史上常见的有/sbin/init/etc/init/bin/init以及/bin/sh。具体尝试哪些路径取决于内核的编译配置。求救信号/sbin/init和/bin/sh如果上述路径都失败了内核会作为最后的手段尝试执行/sbin/init和/bin/sh。如果连这两个都失败内核就彻底“没辙”了。“No working init found”这个报错就发生在这个查找链的末端。它意味着内核尝试了所有它知道的路径但要么文件不存在要么文件存在但无法被成功执行例如文件损坏、没有可执行权限、或者它本身运行时又出错退出了。2.2 根文件系统init程序的藏身之所这里引出一个关键概念根文件系统Root Filesystem。init程序必须位于内核成功挂载的根文件系统之内。如果内核因为某种原因挂载了错误的设备作为根文件系统比如把/dev/sda2挂成了/dev/sda1那么即使你的系统里/sbin/init完好无损内核在它当前挂载的那个“错误”的根文件系统里也根本找不到它。这就好比你要根据地址去朋友家取钥匙结果导航把你带到了一个完全陌生的小区你当然找不到那扇门。因此在排查“No working init found”时我们的思维不能只局限于init程序本身必须扩大到整个启动链条内核参数 - 根文件系统定位与挂载 - init程序查找与执行。3. 系统性排查指南从外到内逐层剥离当面对这个报错时切忌盲目操作。一个系统性的排查流程能帮你快速定位问题层。下图展示了核心的排查思路与路径flowchart TD A[遇到 Kernel panic:brNo working init found.] -- B{第一步检查内核引导参数brGRUB/Uboot} B -- C[参数 root 指定是否正确] C --|否| D[修正 root 参数指向正确的根分区] C --|是| E[参数 init 是否被意外指定] E --|是且路径错误| F[移除或更正 init 参数] E --|否| G[进入救援/单用户模式] G -- H{第二步检查根文件系统} H -- I[根分区能否成功挂载] I --|否| J[检查文件系统是否损坏br使用 fsck 修复] I --|是| K[init 程序文件是否存在] K --|否| L[重新安装或恢复 init 程序包br如 systemd-sysv, upstart] K --|是| M[文件权限/属性是否正常] M --|否| N[修复文件权限与属性] M --|是| O[检查动态链接库依赖] O -- P{第三步检查 init 程序本身} P -- Q[使用 ldd 检查依赖库是否完整] Q --|依赖缺失| R[修复缺失的库文件br从正常系统复制或重装包] Q --|依赖完整| S[手动执行 init 程序测试] S --|执行失败| T[分析 init 程序内部错误br如配置错误、服务冲突] S --|执行成功| U[问题可能为临时性br检查启动服务依赖链] D F J L N R T -- V[问题解决重启系统] U -- V下面我们按照这个流程深入每一个环节。3.1 第一步检查内核引导参数这是最先需要确认的环节因为它是内核行为的“指挥棒”。你需要进入系统的引导加载器Bootloader界面进行查看和编辑。对于大多数PC和服务器使用GRUB在GRUB启动菜单界面选中你的启动项按e键进入编辑模式。找到以linux或linuxefi开头的那一行这一行后面跟着的就是内核命令行参数。仔细检查两个关键参数root这个参数指定了根文件系统所在的分区。例如root/dev/mapper/ubuntu--vg-root或rootUUIDxxxx-xxxx。确认这个标识符是否指向了你真正的系统分区。一个常见的错误是在磁盘顺序变更如增加新硬盘后/dev/sdX的编号发生变化导致root/dev/sda1实际上指向了一个空分区或非Linux分区。init检查是否手动指定了init参数。如果你或某个安装脚本错误地指定了一个不存在的路径如init/bin/init而你的系统用的是/sbin/init就会直接导致此错误。如果并非你的本意请删除这个参数让内核使用默认查找顺序。对于嵌入式系统常使用U-Boot 你需要通过串口或其他调试接口在U-Boot命令行下使用printenv命令查看bootargs环境变量。同样检查其中的root和init设置。修改后使用setenv和saveenv保存。实操心得对于使用UUID或LABEL的root参数稳定性更高不受磁盘设备名变化的影响。如果你的系统还在使用/dev/sdX在调整磁盘后极易出问题建议在系统正常时在/etc/fstab和GRUB配置中迁移到UUID标识。3.2 第二步介入检查根文件系统与init程序如果内核参数看起来正确问题可能出在根文件系统本身。此时我们需要一个“外援”环境来挂载并检查出问题的根文件系统。这就是**救援模式Rescue Mode或单用户模式Single User Mode**的用武之地。如何进入救援模式使用安装介质这是最通用、最强大的方法。从Linux安装U盘或光盘启动选择“救援模式”或“Troubleshooting” - “Rescue a system”。该模式会引导一个最小的Linux环境并尝试自动查找和挂载你硬盘上的系统到/mnt/sysimage之类的目录下。使用GRUB临时修改如果GRUB还能工作你可以在编辑启动参数时在root参数后添加启动级别single或1或者直接追加init/bin/bash或systemd.unitrescue.target针对systemd系统。这会让内核直接跳入一个极简的shell而不启动完整的init系统。进入救援环境后的检查清单 假设你的原系统根分区已被挂载到/mnt/sysimage。检查根分区挂载情况mount | grep /mnt/sysimage确认分区已正确挂载且文件系统类型ext4, xfs等识别正常。检查init程序是否存在ls -lh /mnt/sysimage/sbin/init查看/sbin/init文件是否存在。它通常是一个指向实际init系统的符号链接。ls -l /mnt/sysimage/sbin/init # 可能输出/sbin/init - /lib/systemd/systemd # systemd系统 # 或/sbin/init - /sbin/upstart # Upstart系统 # 或直接就是 /sbin/init # SysV init系统如果/sbin/init这个链接或文件丢失那就是根本性问题。检查init程序的权限与属性ls -l /mnt/sysimage/sbin/init确保它拥有可执行权限-rwxr-xr-x或类似。在极端情况下文件权限被错误修改如chmod -x /sbin/init会导致无法执行。检查动态链接库依赖 init程序通常是动态链接的依赖一系列.so库文件。如果关键库文件丢失或损坏init程序会在执行时立即失败。# 查看init程序的依赖 ldd /mnt/sysimage/sbin/init观察输出检查是否有“not found”的库。所有列出的库文件都应该能在/mnt/sysimage/lib、/mnt/sysimage/lib64或/mnt/sysimage/usr/lib*下找到。3.3 第三步修复与恢复实战根据上一步的检查结果我们可以进行针对性的修复。场景一init程序或关键库文件丢失这通常是由于不完全的软件包操作如强制卸载、部分升级失败或文件系统损坏导致。修复方法在救援模式下使用原系统的包管理器重新安装init系统包。对于基于Debian/Ubuntu使用systemd的系统chroot /mnt/sysimage # 切换根目录到原系统环境 apt update apt install --reinstall systemd systemd-sysvsystemd-sysv包提供了/sbin/init到systemd的符号链接。对于基于RHEL/CentOS/Fedora使用systemd的系统chroot /mnt/sysimage yum reinstall systemd # 或 dnf reinstall systemd对于使用SysV init的系统chroot /mnt/sysimage apt install --reinstall sysvinit-core # Debian/Ubuntu # 或 yum reinstall initscripts # RHEL/CentOS手动恢复如果包管理器也无法使用最粗暴但有效的方法是从一个同版本、同架构的健康系统中将/sbin/init文件及其所有依赖库通过ldd查询复制到故障系统的对应位置。务必注意保持文件权限和属性一致。场景二根文件系统损坏如果fsck检查报告错误或者在挂载时出现I/O error、Corrupt journal等提示。修复方法在救援模式下先尝试卸载分区然后对分区进行文件系统检查与修复。umount /mnt/sysimage # 确保分区未挂载 fsck -y /dev/sda1 # 假设根分区是 /dev/sda1-y 自动确认修复对于ext3/ext4文件系统fsck通常能修复大部分非硬件性的损坏。修复完成后重新挂载并检查文件是否恢复。场景三内核与根文件系统不匹配这种情况在升级内核后未更新initramfs或者手动更换了不同版本的内核时可能出现。内核需要initramfs初始内存文件系统中的模块来访问根分区如SCSI驱动、RAID驱动、LVM驱动、加密驱动等。如果initramfs中没有对应的驱动内核就无法挂载根分区自然找不到init。修复方法在救援模式下重新生成对应内核的initramfs。chroot /mnt/sysimage # 查看当前已安装的内核版本 ls /boot/vmlinuz-* # 为特定内核生成initramfs以5.4.0-xx-generic为例 update-initramfs -c -k 5.4.0-xx-generic # Debian/Ubuntu # 或 dracut -f /boot/initramfs-$(uname -r).img $(uname -r) # RHEL/CentOS/Fedora同时检查/etc/fstab和 GRUB配置中的root参数确保它们使用了正确的、稳定的标识符如UUID。4. 进阶分析与深度避坑解决了常见的直接原因后我们还需要关注一些更隐蔽、更进阶的场景这些往往是老手们踩过坑的地方。4.1 init程序自身的“沉默失败”有时候/sbin/init文件本身完好无损也能被内核找到并执行但它执行后立即退出了导致内核认为“没有工作的init”。这种情况内核的报错可能仍然是“No working init found”因为从内核角度看init进程没存活。如何诊断在GRUB启动参数中临时添加init/bin/bash。如果系统能成功进入bash shell说明内核到根文件系统的通路是好的问题出在默认的init程序如systemd自己身上。此时在bash里手动执行/sbin/init观察其输出exec /sbin/init你可能会看到systemd启动过程中的具体报错例如关键配置文件错误/etc/systemd/system.conf,/etc/fstab语法错误。必需的挂载点失败/var,/home等独立分区在/etc/fstab中配置错误导致挂载失败systemd可能因此放弃启动。服务依赖死锁某个关键服务如网络、设备管理器反复失败导致系统无法进入默认目标multi-user.target等。排查思路在bash环境下检查系统日志的存储位置如/var/log下的boot.log,messages,syslog。如果/var是独立分区且挂载失败日志可能看不到。此时需要手动检查和修复/etc/fstab或者使用systemctl --failed查看失败单元但需要先让systemd跑起来有点矛盾。更直接的方法是在bash下用journalctl查看内核日志但需要以只读方式挂载/sys/fs/cgroup和/run等目录操作较为复杂。一个更简单的办法是在GRUB参数中添加systemd.log_leveldebug来获取详细的启动日志。4.2 存储栈的“隐形断点”LVM、RAID与加密在现代服务器和桌面系统中根文件系统很可能不在一个简单的/dev/sda1分区上而是位于逻辑卷LVM、软RAID阵列mdadm或加密卷LUKS之上。内核需要一系列步骤来组装出最终的根设备。LVM内核需要device-mapper驱动和lvm工具来扫描卷组并激活逻辑卷。如果initramfs中没有包含dm-mod、lvm2等模块和工具或者卷组名、逻辑卷名在系统间迁移后发生变化就会导致激活失败。软RAID内核需要md_mod驱动来组装RAID阵列。如果RAID超级块损坏或者磁盘顺序识别错误阵列就无法进入/dev/mdX可用状态。全盘加密LUKS这增加了交互环节。内核需要dm-crypt驱动并且initramfs中需要包含一个程序如cryptsetup来在启动早期提示输入密码或读取密钥文件然后才能打开加密设备。避坑指南更新initramfs是必须的任何时候只要你修改了内核、更新了存储相关的驱动、或者调整了/etc/crypttab、/etc/mdadm.conf等配置都必须记得重新生成initramfs。在initramfs中调试可以在GRUB参数中添加breakpremount或rd.breaksystemd系统让启动过程在挂载根文件系统之前暂停进入一个initramfs提供的临时shell。在这里你可以手动执行lvm vgchange -ay、mdadm --assemble --scan、cryptsetup luksOpen等命令来验证存储栈的组装过程是否顺利。这是一个非常强大的调试手段。检查UUID和标签对于LVM和RAID在/etc/fstab和GRUB配置中使用/dev/mapper/vg-name/lv-name或/dev/disk/by-uuid/...比使用可能变化的/dev/md0或/dev/dm-0更可靠。4.3 硬件与固件的“暗箭”在极少数情况下问题根源可能不在软件层面。内存故障有缺陷的内存条可能导致内核数据损坏或者在将init程序从磁盘加载到内存时发生错误。可以尝试使用Memtest86等工具进行长时间的内存测试。磁盘坏道恰好损坏了/sbin/init文件或关键库文件所在的磁盘扇区。使用badblocks或smartctl检查磁盘健康状态。UEFI/BIOS设置某些主板的“快速启动”或“安全启动”选项可能与Linux的启动过程产生微妙的冲突尤其是在使用自定义内核或驱动时。尝试在固件设置中禁用这些选项。内核与硬件不兼容非常新的硬件搭配较旧的内核或者为特定平台如服务器编译的内核用在不同的平台如笔记本电脑上可能会缺少必要的驱动。确保使用的内核版本与硬件匹配。处理“Kernel panic - not syncing: No working init found.”这个错误本质上是一场对Linux系统启动链的侦探游戏。从GRUB的参数到内核的驱动从根文件系统的完整性到init程序的健康度每一个环节都不能出错。我的经验是按照“引导参数 - 根文件系统 - init程序”这个由外到内的顺序进行排查成功率最高。永远不要忘记救援模式这个“万能钥匙”它给了你一个站在系统之外审视问题的上帝视角。最后养成好习惯修改关键配置前备份更新内核后记得刷新initramfs使用UUID等稳定标识符。这些小事能在关键时刻避免一场漫长的故障排查。 
长河君 · 2026/8/3 20:52:16 · 阅读 1.2k Linux内核启动失败：No working init found 排查与修复全指南
1. 问题引入当你的Linux世界在启动时“宕机”作为一名和Linux系统打了十几年交道的运维老兵我处理过无数千奇百怪的启动故障。但有一种报错每次看到它都意味着一个相对棘手的排查过程开始了——那就是屏幕上赫然出现的Kernel panic - not syncing: No working init found.。这行红字对于任何Linux管理员来说都像是一个刺耳的警报它宣告着内核已经完成了自己的引导工作却找不到那个至关重要的“第一号进程”来接手最终只能选择“恐慌”panic并停止一切。这不仅仅是内核的失败更是整个系统启动链条的断裂。今天我们就来彻底拆解这个经典问题从内核的视角出发一步步还原它发生的场景、背后的原理并给出从新手到老手都能上手的完整排查与修复指南。无论你是在实体服务器、虚拟机还是嵌入式设备上遇到它这篇文章都将帮你理清思路找到症结。2. 内核启动的最后一公里从init到用户空间要理解“No working init found”我们必须先搞清楚Linux内核启动的终点在哪里。很多人以为内核启动完毕就是系统启动完毕这是一个常见的误解。实际上内核的启动是一个“交棒”的过程。2.1 内核启动的终局与init的使命当内核完成硬件初始化、加载了必要的驱动、挂载了根文件系统rootfs之后它的核心任务就接近尾声了。此时内核需要找到一个可以执行的用户空间userspace程序并将系统的控制权完全交给它。这个被选中的程序就是“init”进程它的进程号PID固定为1。PID 1是一个具有特殊意义的进程它是所有其他用户空间进程的祖先负责启动和管理系统的各项服务如网络、登录、定时任务等。内核是如何找到这个init程序的呢它遵循一个明确的查找顺序内核命令行参数init这是优先级最高的指定方式。例如在GRUB的启动参数中你可以看到类似init/bin/bash或init/sbin/init的配置。内核会直接尝试执行这个路径指定的程序。编译时指定的备用路径如果init参数未指定内核会尝试几个硬编码的备用路径。历史上常见的有/sbin/init/etc/init/bin/init以及/bin/sh。具体尝试哪些路径取决于内核的编译配置。求救信号/sbin/init和/bin/sh如果上述路径都失败了内核会作为最后的手段尝试执行/sbin/init和/bin/sh。如果连这两个都失败内核就彻底“没辙”了。“No working init found”这个报错就发生在这个查找链的末端。它意味着内核尝试了所有它知道的路径但要么文件不存在要么文件存在但无法被成功执行例如文件损坏、没有可执行权限、或者它本身运行时又出错退出了。2.2 根文件系统init程序的藏身之所这里引出一个关键概念根文件系统Root Filesystem。init程序必须位于内核成功挂载的根文件系统之内。如果内核因为某种原因挂载了错误的设备作为根文件系统比如把/dev/sda2挂成了/dev/sda1那么即使你的系统里/sbin/init完好无损内核在它当前挂载的那个“错误”的根文件系统里也根本找不到它。这就好比你要根据地址去朋友家取钥匙结果导航把你带到了一个完全陌生的小区你当然找不到那扇门。因此在排查“No working init found”时我们的思维不能只局限于init程序本身必须扩大到整个启动链条内核参数 - 根文件系统定位与挂载 - init程序查找与执行。3. 系统性排查指南从外到内逐层剥离当面对这个报错时切忌盲目操作。一个系统性的排查流程能帮你快速定位问题层。下图展示了核心的排查思路与路径flowchart TD A[遇到 Kernel panic:brNo working init found.] -- B{第一步检查内核引导参数brGRUB/Uboot} B -- C[参数 root 指定是否正确] C --|否| D[修正 root 参数指向正确的根分区] C --|是| E[参数 init 是否被意外指定] E --|是且路径错误| F[移除或更正 init 参数] E --|否| G[进入救援/单用户模式] G -- H{第二步检查根文件系统} H -- I[根分区能否成功挂载] I --|否| J[检查文件系统是否损坏br使用 fsck 修复] I --|是| K[init 程序文件是否存在] K --|否| L[重新安装或恢复 init 程序包br如 systemd-sysv, upstart] K --|是| M[文件权限/属性是否正常] M --|否| N[修复文件权限与属性] M --|是| O[检查动态链接库依赖] O -- P{第三步检查 init 程序本身} P -- Q[使用 ldd 检查依赖库是否完整] Q --|依赖缺失| R[修复缺失的库文件br从正常系统复制或重装包] Q --|依赖完整| S[手动执行 init 程序测试] S --|执行失败| T[分析 init 程序内部错误br如配置错误、服务冲突] S --|执行成功| U[问题可能为临时性br检查启动服务依赖链] D F J L N R T -- V[问题解决重启系统] U -- V下面我们按照这个流程深入每一个环节。3.1 第一步检查内核引导参数这是最先需要确认的环节因为它是内核行为的“指挥棒”。你需要进入系统的引导加载器Bootloader界面进行查看和编辑。对于大多数PC和服务器使用GRUB在GRUB启动菜单界面选中你的启动项按e键进入编辑模式。找到以linux或linuxefi开头的那一行这一行后面跟着的就是内核命令行参数。仔细检查两个关键参数root这个参数指定了根文件系统所在的分区。例如root/dev/mapper/ubuntu--vg-root或rootUUIDxxxx-xxxx。确认这个标识符是否指向了你真正的系统分区。一个常见的错误是在磁盘顺序变更如增加新硬盘后/dev/sdX的编号发生变化导致root/dev/sda1实际上指向了一个空分区或非Linux分区。init检查是否手动指定了init参数。如果你或某个安装脚本错误地指定了一个不存在的路径如init/bin/init而你的系统用的是/sbin/init就会直接导致此错误。如果并非你的本意请删除这个参数让内核使用默认查找顺序。对于嵌入式系统常使用U-Boot 你需要通过串口或其他调试接口在U-Boot命令行下使用printenv命令查看bootargs环境变量。同样检查其中的root和init设置。修改后使用setenv和saveenv保存。实操心得对于使用UUID或LABEL的root参数稳定性更高不受磁盘设备名变化的影响。如果你的系统还在使用/dev/sdX在调整磁盘后极易出问题建议在系统正常时在/etc/fstab和GRUB配置中迁移到UUID标识。3.2 第二步介入检查根文件系统与init程序如果内核参数看起来正确问题可能出在根文件系统本身。此时我们需要一个“外援”环境来挂载并检查出问题的根文件系统。这就是**救援模式Rescue Mode或单用户模式Single User Mode**的用武之地。如何进入救援模式使用安装介质这是最通用、最强大的方法。从Linux安装U盘或光盘启动选择“救援模式”或“Troubleshooting” - “Rescue a system”。该模式会引导一个最小的Linux环境并尝试自动查找和挂载你硬盘上的系统到/mnt/sysimage之类的目录下。使用GRUB临时修改如果GRUB还能工作你可以在编辑启动参数时在root参数后添加启动级别single或1或者直接追加init/bin/bash或systemd.unitrescue.target针对systemd系统。这会让内核直接跳入一个极简的shell而不启动完整的init系统。进入救援环境后的检查清单 假设你的原系统根分区已被挂载到/mnt/sysimage。检查根分区挂载情况mount | grep /mnt/sysimage确认分区已正确挂载且文件系统类型ext4, xfs等识别正常。检查init程序是否存在ls -lh /mnt/sysimage/sbin/init查看/sbin/init文件是否存在。它通常是一个指向实际init系统的符号链接。ls -l /mnt/sysimage/sbin/init # 可能输出/sbin/init - /lib/systemd/systemd # systemd系统 # 或/sbin/init - /sbin/upstart # Upstart系统 # 或直接就是 /sbin/init # SysV init系统如果/sbin/init这个链接或文件丢失那就是根本性问题。检查init程序的权限与属性ls -l /mnt/sysimage/sbin/init确保它拥有可执行权限-rwxr-xr-x或类似。在极端情况下文件权限被错误修改如chmod -x /sbin/init会导致无法执行。检查动态链接库依赖 init程序通常是动态链接的依赖一系列.so库文件。如果关键库文件丢失或损坏init程序会在执行时立即失败。# 查看init程序的依赖 ldd /mnt/sysimage/sbin/init观察输出检查是否有“not found”的库。所有列出的库文件都应该能在/mnt/sysimage/lib、/mnt/sysimage/lib64或/mnt/sysimage/usr/lib*下找到。3.3 第三步修复与恢复实战根据上一步的检查结果我们可以进行针对性的修复。场景一init程序或关键库文件丢失这通常是由于不完全的软件包操作如强制卸载、部分升级失败或文件系统损坏导致。修复方法在救援模式下使用原系统的包管理器重新安装init系统包。对于基于Debian/Ubuntu使用systemd的系统chroot /mnt/sysimage # 切换根目录到原系统环境 apt update apt install --reinstall systemd systemd-sysvsystemd-sysv包提供了/sbin/init到systemd的符号链接。对于基于RHEL/CentOS/Fedora使用systemd的系统chroot /mnt/sysimage yum reinstall systemd # 或 dnf reinstall systemd对于使用SysV init的系统chroot /mnt/sysimage apt install --reinstall sysvinit-core # Debian/Ubuntu # 或 yum reinstall initscripts # RHEL/CentOS手动恢复如果包管理器也无法使用最粗暴但有效的方法是从一个同版本、同架构的健康系统中将/sbin/init文件及其所有依赖库通过ldd查询复制到故障系统的对应位置。务必注意保持文件权限和属性一致。场景二根文件系统损坏如果fsck检查报告错误或者在挂载时出现I/O error、Corrupt journal等提示。修复方法在救援模式下先尝试卸载分区然后对分区进行文件系统检查与修复。umount /mnt/sysimage # 确保分区未挂载 fsck -y /dev/sda1 # 假设根分区是 /dev/sda1-y 自动确认修复对于ext3/ext4文件系统fsck通常能修复大部分非硬件性的损坏。修复完成后重新挂载并检查文件是否恢复。场景三内核与根文件系统不匹配这种情况在升级内核后未更新initramfs或者手动更换了不同版本的内核时可能出现。内核需要initramfs初始内存文件系统中的模块来访问根分区如SCSI驱动、RAID驱动、LVM驱动、加密驱动等。如果initramfs中没有对应的驱动内核就无法挂载根分区自然找不到init。修复方法在救援模式下重新生成对应内核的initramfs。chroot /mnt/sysimage # 查看当前已安装的内核版本 ls /boot/vmlinuz-* # 为特定内核生成initramfs以5.4.0-xx-generic为例 update-initramfs -c -k 5.4.0-xx-generic # Debian/Ubuntu # 或 dracut -f /boot/initramfs-$(uname -r).img $(uname -r) # RHEL/CentOS/Fedora同时检查/etc/fstab和 GRUB配置中的root参数确保它们使用了正确的、稳定的标识符如UUID。4. 进阶分析与深度避坑解决了常见的直接原因后我们还需要关注一些更隐蔽、更进阶的场景这些往往是老手们踩过坑的地方。4.1 init程序自身的“沉默失败”有时候/sbin/init文件本身完好无损也能被内核找到并执行但它执行后立即退出了导致内核认为“没有工作的init”。这种情况内核的报错可能仍然是“No working init found”因为从内核角度看init进程没存活。如何诊断在GRUB启动参数中临时添加init/bin/bash。如果系统能成功进入bash shell说明内核到根文件系统的通路是好的问题出在默认的init程序如systemd自己身上。此时在bash里手动执行/sbin/init观察其输出exec /sbin/init你可能会看到systemd启动过程中的具体报错例如关键配置文件错误/etc/systemd/system.conf,/etc/fstab语法错误。必需的挂载点失败/var,/home等独立分区在/etc/fstab中配置错误导致挂载失败systemd可能因此放弃启动。服务依赖死锁某个关键服务如网络、设备管理器反复失败导致系统无法进入默认目标multi-user.target等。排查思路在bash环境下检查系统日志的存储位置如/var/log下的boot.log,messages,syslog。如果/var是独立分区且挂载失败日志可能看不到。此时需要手动检查和修复/etc/fstab或者使用systemctl --failed查看失败单元但需要先让systemd跑起来有点矛盾。更直接的方法是在bash下用journalctl查看内核日志但需要以只读方式挂载/sys/fs/cgroup和/run等目录操作较为复杂。一个更简单的办法是在GRUB参数中添加systemd.log_leveldebug来获取详细的启动日志。4.2 存储栈的“隐形断点”LVM、RAID与加密在现代服务器和桌面系统中根文件系统很可能不在一个简单的/dev/sda1分区上而是位于逻辑卷LVM、软RAID阵列mdadm或加密卷LUKS之上。内核需要一系列步骤来组装出最终的根设备。LVM内核需要device-mapper驱动和lvm工具来扫描卷组并激活逻辑卷。如果initramfs中没有包含dm-mod、lvm2等模块和工具或者卷组名、逻辑卷名在系统间迁移后发生变化就会导致激活失败。软RAID内核需要md_mod驱动来组装RAID阵列。如果RAID超级块损坏或者磁盘顺序识别错误阵列就无法进入/dev/mdX可用状态。全盘加密LUKS这增加了交互环节。内核需要dm-crypt驱动并且initramfs中需要包含一个程序如cryptsetup来在启动早期提示输入密码或读取密钥文件然后才能打开加密设备。避坑指南更新initramfs是必须的任何时候只要你修改了内核、更新了存储相关的驱动、或者调整了/etc/crypttab、/etc/mdadm.conf等配置都必须记得重新生成initramfs。在initramfs中调试可以在GRUB参数中添加breakpremount或rd.breaksystemd系统让启动过程在挂载根文件系统之前暂停进入一个initramfs提供的临时shell。在这里你可以手动执行lvm vgchange -ay、mdadm --assemble --scan、cryptsetup luksOpen等命令来验证存储栈的组装过程是否顺利。这是一个非常强大的调试手段。检查UUID和标签对于LVM和RAID在/etc/fstab和GRUB配置中使用/dev/mapper/vg-name/lv-name或/dev/disk/by-uuid/...比使用可能变化的/dev/md0或/dev/dm-0更可靠。4.3 硬件与固件的“暗箭”在极少数情况下问题根源可能不在软件层面。内存故障有缺陷的内存条可能导致内核数据损坏或者在将init程序从磁盘加载到内存时发生错误。可以尝试使用Memtest86等工具进行长时间的内存测试。磁盘坏道恰好损坏了/sbin/init文件或关键库文件所在的磁盘扇区。使用badblocks或smartctl检查磁盘健康状态。UEFI/BIOS设置某些主板的“快速启动”或“安全启动”选项可能与Linux的启动过程产生微妙的冲突尤其是在使用自定义内核或驱动时。尝试在固件设置中禁用这些选项。内核与硬件不兼容非常新的硬件搭配较旧的内核或者为特定平台如服务器编译的内核用在不同的平台如笔记本电脑上可能会缺少必要的驱动。确保使用的内核版本与硬件匹配。处理“Kernel panic - not syncing: No working init found.”这个错误本质上是一场对Linux系统启动链的侦探游戏。从GRUB的参数到内核的驱动从根文件系统的完整性到init程序的健康度每一个环节都不能出错。我的经验是按照“引导参数 - 根文件系统 - init程序”这个由外到内的顺序进行排查成功率最高。永远不要忘记救援模式这个“万能钥匙”它给了你一个站在系统之外审视问题的上帝视角。最后养成好习惯修改关键配置前备份更新内核后记得刷新initramfs使用UUID等稳定标识符。这些小事能在关键时刻避免一场漫长的故障排查。