1. 项目概述：当“上帝”被锁在门外

在嵌入式Linux开发与运维的日常里，我们这些搞硬件的、写驱动的、做系统集成的，最怕遇到的尴尬事之一，恐怕就是对着一个正在运行的设备，突然发现自己被挡在了“root”的大门之外。这个拥有最高权限的账户，就像是整个嵌入式系统的“上帝”，一旦忘记密码，设备就成了一块无法深度配置、无法更新核心软件、甚至无法进行故障诊断的“砖头”。这绝不是危言耸听，尤其是在产品已经部署到现场，或者在进行产线批量烧录与测试时，一个遗忘的密码可能导致产线停滞、现场维护成本激增。

我遇到过不少这样的情况：有的同事在开发板测试阶段设了一个复杂的密码，后来再也没用过，等到要抓取关键日志或更新固件时傻眼了；有的在量产镜像中统一设置了初始密码，但文档遗失，后续维护人员无从下手；更常见的是，在uboot或内核启动参数中做了一些安全加固，结果却把自己也给“加固”在了外面。基于这个高频痛点，结合“嵌入式”、“Linux”、“root密码”、“uboot”这些核心关键词，我将系统性地梳理和实战演示几种在嵌入式Linux平台上找回或重置root密码的可靠方法。这些方法覆盖了从拥有物理访问权限到仅能通过网络访问的不同场景，核心思路都是绕过或修改系统的身份验证机制。请注意，所有操作均基于你拥有该设备的合法管理权限，旨在解决合法运维中的技术问题。

2. 核心思路与方案选型：条条大路通罗马

面对忘记root密码的困境，解决方法的核心逻辑在于中断或干预Linux系统的正常启动流程，在身份验证环节生效之前，获得一个具有root权限的Shell环境。一旦获得了这个环境，修改密码就易如反掌。根据嵌入式设备的具体硬件配置、启动引导程序（通常是uboot）的开放程度以及系统设计，我们可以选择不同的路径。

2.1 方案全景图与选型依据

大体上，方法可以分为以下几类，其选择严重依赖于你的设备访问权限和启动环境：

对于绝大多数嵌入式工程师而言，方法1（单用户模式）是首选的尝试方向，因为它最接近通用Linux服务器的恢复方式，且成功率很高。方法2则依赖于开发团队最初构建系统时的“仁慈”，是一个值得检查的捷径。当我们谈论“uboot”这个热搜词时，它正是我们实现方法1、3、4、5的关键枢纽，几乎所有绕过操作都离不开对uboot命令行的操控。

注意：在执行任何操作前，请务必确认你对该设备拥有合法的管理权限。这些方法会完全绕过系统安全机制，仅用于合法的系统恢复。

2.2 为什么是uboot？它在密码恢复中的核心作用

U-Boot，这个几乎统治了嵌入式领域的开源引导加载程序，是我们此次“救援行动”的指挥中心。它负责初始化硬件、加载内核与设备树、传递启动参数（bootargs），并最终将控制权交给Linux内核。密码验证发生在内核启动、系统初始化（systemd或SysV init）之后，而uboot的启动阶段远在这之前。

因此，我们的突破口就在uboot传递给内核的启动参数上。通过串口或调试接口中断uboot的自动启动流程，进入其命令行，我们就可以修改这些参数，从而改变内核的启动行为。例如，告诉内核直接运行一个Shell而不是正常的初始化程序，这就是单用户模式的原理。理解uboot的bootcmd、bootargs环境变量以及bootm/booti等命令，是成功的关键。

3. 实战操作一：通过单用户模式重置密码（最通用方法）

这是最经典、最广泛适用的方法。其原理是：在Linux内核启动时，通过内核命令行参数init指定一个特殊的初始化程序（通常是/bin/sh或/bin/bash），从而跳过正常的、会触发登录验证的系统初始化流程。

3.1 前期准备与环境接入

1. 物理连接：你需要通过串口（UART）连接到目标嵌入式设备。这是嵌入式开发的标准调试接口，通常包含TX、RX、GND三根线。使用USB转TTL串口模块，连接电脑和设备上的调试串口。
2. 终端软件：在电脑上打开串口终端软件（如PuTTY、MobaXterm、Minicom、SecureCRT）。正确设置波特率（常见的有115200、9600、57600等）、数据位（8）、停止位（1）、无校验位（None）。
3. 中断uboot启动：给设备上电，并立即在终端软件中连续按下回车键或指定的中断键（如空格键）。成功的话，你会看到uboot的启动过程停止，并出现类似=>或U-Boot>的命令行提示符。

3.2 关键步骤：修改内核启动参数

进入uboot命令行后，我们首要任务是查看当前的启动命令和参数。

=> printenv bootargs bootargs=console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait

上面的输出是一个示例，表示内核启动参数设置了控制台和根文件系统位置。现在，我们需要修改这个bootargs，添加进入单用户模式的参数。

方法A：直接附加init参数这是最直接的方式，在原有参数后追加init=/bin/sh或init=/bin/bash。

=> setenv bootargs ‘console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait init=/bin/sh’ => saveenv => boot

方法B：使用single或rescue参数对于一些使用systemd的系统，更标准的参数是systemd.unit=rescue.target或systemd.unit=emergency.target，亦或是传统的single。

=> setenv bootargs ‘console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait systemd.unit=rescue.target’ => saveenv => boot

实操心得：init=/bin/sh通常能给你一个最“干净”的shell，但可能缺少一些环境变量。rescue.target会尝试挂载根文件系统并启动一些基本服务，有时会更稳定。如果一种不行，可以尝试另一种。另外，saveenv命令会将修改保存到uboot的环境变量存储区（如SPI Flash），下次启动仍会生效。如果只想本次生效，可以不执行saveenv，直接boot。

3.3 进入Shell并修改密码

执行boot命令后，内核会使用新的参数启动。如果成功，你会直接获得一个以root权限运行的Shell提示符（通常是#），而不会出现登录提示。

此时，根文件系统通常是以**只读（ro）**方式挂载的，因为我们在bootargs中虽然写了rw，但某些系统在异常启动时仍会强制只读。首先需要将其重新挂载为可读写：

# mount -o remount,rw /

然后，使用passwd命令修改root密码：

# passwd Enter new UNIX password: （输入新密码） Retype new UNIX password: （再次输入新密码） passwd: password updated successfully

如果系统使用了影子密码（/etc/shadow），passwd命令会自动处理。修改完成后，为了确保系统下次能正常启动，强烈建议将启动参数改回去。但因为我们是通过临时修改uboot参数进来的，所以需要重启并再次中断uboot。

# reboot

设备重启后，再次中断uboot，将bootargs中的init=/bin/sh或systemd.unit=rescue.target部分删除，恢复原样，然后saveenv并boot。现在，你应该可以使用新设置的root密码登录了。

4. 实战操作二：利用Initramfs中的调试Shell

有些嵌入式系统，特别是针对调试优化的开发板镜像，会在初始RAM文件系统（initramfs或initrd）中集成一个SSH服务器（如dropbear）或一个简单的telnet/串口Shell。这相当于在系统挂载真正的根文件系统之前，就提供了一个救援通道。

4.1 判断与进入

1. 观察启动日志：正常启动时，仔细观察内核解压initramfs后的日志。你可能会看到类似“Starting Dropbear SSH server…”或者“Debug shell on ttyS0”的信息。
2. 尝试连接：
   • 如果内置了Dropbear SSH：initramfs会临时配置一个IP地址（可能是通过DHCP或静态配置）。在同一个网络下的另一台机器上，尝试SSH连接到这个IP地址，用户名可能是root，并且通常无需密码。
   • 如果内置了串口Shell：在uboot启动内核后，在串口终端里尝试按回车键，可能会直接出现一个#提示符。

4.2 在Initramfs Shell中操作

一旦进入，你会发现这是一个极简的环境，根文件系统是内存中的initramfs。你的目标根文件系统（例如/dev/mmcblk0p2）可能还没有被挂载到/下，而是需要你手动操作。

首先，找到你的根文件系统分区：

# ls /dev/mmcblk* # 查看MMC/SD卡分区 # ls /dev/nvm* # 查看NVMe分区 # blkid # 查看所有块设备及其类型、UUID

假设你的根文件系统在/dev/mmcblk0p2，将其挂载到一个临时目录：

# mkdir -p /mnt/root # mount /dev/mmcblk0p2 /mnt/root

现在，你需要chroot到这个真正的根文件系统环境中去修改密码。chroot意味着将指定的目录变为进程的根目录“/”。

# chroot /mnt/root /bin/bash

此时，你的Shell就“切换”到了目标根文件系统内。接着，修改密码：

# passwd （输入新密码）

修改完成后，退出chroot环境，卸载分区，然后重启：

# exit # umount /mnt/root # reboot

注意事项：这种方法高度依赖于initramfs的构建配置。很多为了安全或精简的生产镜像会移除此类调试功能。如果你的设备启动时没有相关提示，此路很可能不通。

5. 实战操作三：通过uboot直接操作根文件系统（高阶方法）

当上述方法都失效时（例如，内核参数被锁定，initramfs没有Shell），我们还可以尝试在uboot阶段直接读写存储介质上的根文件系统，修改密码文件。这需要uboot支持对应文件系统的命令（如ext4load,ext4write,fatload,fatwrite等），并且操作必须极其小心，否则会直接破坏文件系统。

5.1 原理与风险

Linux的用户密码信息存储在/etc/shadow文件中（现代系统），root账户对应第一行。我们可以尝试在uboot中，将这个文件读取到内存，修改其中加密后的密码哈希值，再写回存储设备。或者，更简单一点，清空root的密码（不推荐用于生产环境）。

巨大风险警告：直接在uboot中操作文件系统是底层且危险的行为。文件系统可能处于不一致状态，uboot的文件系统驱动可能不完整，一个字节的错误就可能导致整个分区无法挂载。务必先备份！

5.2 操作步骤示例（以EXT4文件系统为例）

假设根文件系统在/dev/mmcblk0p2，格式为EXT4。

1. 在uboot中挂载并备份文件（如果uboot支持）：

   => ext4load mmc 0:2 ${loadaddr} /etc/shadow

   这条命令尝试从MMC设备0的第2分区加载/etc/shadow文件到内存地址${loadaddr}。你需要先通过printenv查看可用的内存地址范围。

2. 修改内存中的数据（极度困难）：即使成功加载，在uboot中解析和编辑这个文本文件也几乎是不可能的，因为uboot缺乏方便的文本处理工具。

因此，一个更可行的“暴力”方法是：直接用一个已知密码的shadow条目覆盖。

3. 准备一个已知的shadow条目。在另一台Linux机器上，用openssl生成一个密码哈希。例如，生成密码为“newpassword”的哈希：

   openssl passwd -6 -salt $(openssl rand -base64 12) newpassword

   这会输出类似$6$somesalt$HASH...的字符串。$6$表示SHA-512加密。

4. 构造新的shadow行。root的shadow行格式为：root:$6$somesalt$HASH...:19110:0:99999:7:::你需要将:后的第一个字段（即密码哈希部分）替换为你生成的哈希。如果只想清空密码，则将其替换为空，变成root::19110:0:99999:7:::（两个冒号紧挨着）。

5. 将新行写入文件？问题来了，uboot很难将一段内存数据以精确的偏移量写回文件。通常的ext4write命令要求你知道文件的inode等信息，操作极其复杂。

鉴于其超高的复杂性和风险，除非万不得已，并且你对uboot和文件系统有极深的理解，否则不建议采用此方法。它更像是一种理论上的可能性，在实际救援中，优先考虑前两种方法，或者接下来的方法四。

6. 实战操作四：替换或修改Initramfs镜像

如果设备的启动流程是：uboot -> initramfs -> 挂载根文件系统 -> 切换根目录，那么我们可以通过替换initramfs镜像来植入我们自己的“后门”。这个方法需要你能访问到存储initramfs的介质（通常是boot分区，可能是SD卡、eMMC的某个分区、或者NOR Flash）。

6.1 获取与解包Initramfs

1. 找到initramfs镜像：它可能叫initrd.img,initramfs.cpio.gz,uInitrd等，通常和内核镜像（zImage,uImage）放在同一个FAT或EXT格式的boot分区。
2. 备份原镜像：在任何操作前，务必备份原始文件。
3. 解包：initramfs通常是一个cpio归档，可能经过gzip压缩。

   mkdir initramfs_root && cd initramfs_root gunzip -c ../initramfs.cpio.gz | cpio -idmv

6.2 修改Initramfs内容

解压后，你会看到一个小型根目录树。我们的目标是修改其初始化脚本，使其在早期就给我们一个Shell。

1. 查找初始化脚本：通常位于/init或/linuxrc。也可能在/scripts/init-top/,/scripts/init-premount/等目录下，取决于构建工具（如busybox init, systemd in initramfs）。
2. 编辑脚本：用文本编辑器打开主初始化脚本（比如/init）。在脚本中寻找挂载根文件系统、执行switch_root的地方。在这之前，插入一段代码，例如：

   # 在/bin/sh存在的情况下，启动一个shell，方便调试 if [ -x /bin/sh ]; then echo “—— Initramfs Debug Shell ——” echo “Type ‘exit’ to continue booting.” exec /bin/sh fi

   或者，更谨慎一点，等待一个特定的触发条件，比如某个按键：

   # 检查串口输入，如果收到‘debug’字符串，则启动shell echo -e “\nPress ‘d’ for debug shell in 3 seconds...” read -t 3 -n 1 key if [ “$key” == “d” ]; then exec /bin/sh fi

6.3 重新打包与部署

修改并保存脚本后，重新打包initramfs：

cd initramfs_root find . | cpio -o -H newc | gzip -9 > ../new_initramfs.cpio.gz

然后用新的镜像文件替换boot分区中的原文件。重启设备，在initramfs阶段，根据你的脚本设计（比如按‘d’键），就能获得一个root shell。在这个shell里，你可以像方法二那样，手动挂载根文件系统并chroot进去修改密码。

实操心得：这种方法给了你最大的灵活性，可以打造一个功能强大的救援镜像。但它的前提是你能替换boot分区中的文件。对于某些安全启动（Secure Boot）或写保护的设备，这可能无法实现。同时，要确保你打包的initramfs与内核版本兼容。

7. 常见问题与深度排查技巧

在实际操作中，你可能会遇到各种意想不到的问题。下面记录了一些典型场景和我的排查思路。

7.1 无法中断uboot启动流程

• 现象：疯狂按回车/空格键，uboot还是直接启动了内核。
• 排查：
  1. 检查串口连接与波特率：这是最常见的原因。确认TX/RX线没有接反，波特率是否与uboot配置完全一致（尝试115200, 9600, 57600等常见值）。
  2. 确认中断键：有些uboot配置使用Ctrl+C，而不是回车或空格。可以都尝试一下。
  3. uboot配置被锁定：查看uboot环境变量bootdelay。如果它被设置为-1（或-2），表示启动延迟为无穷大或直接启动，不等待中断。这时你可能需要通过JTAG等更底层的调试工具来恢复，或者如果bootcmd本身包含了等待输入的命令，则还有机会。
  4. 启动速度过快：有些高性能SOC的uboot启动极快，窗口期很短。可以尝试在uboot源码中增加bootdelay的值，并重新编译烧写，但这要求你有源码和编译环境。

7.2 进入单用户模式后，根文件系统挂载失败

• 现象：内核panic，提示“VFS: Unable to mount root fs”。
• 排查：
  1. 核对根文件系统设备节点：在uboot中使用printenv查看bootargs中的root=参数。确认/dev/mmcblk0p2或root=PARTUUID=xxxx是否正确指向了你的根文件系统分区。你可以用uboot的mmc list和part list mmc 0等命令来查看分区信息。
  2. 检查文件系统类型：bootargs中可能需要指定文件系统类型，如rootfstype=ext4。如果内核没有编译进对应文件系统的驱动，也会失败。
  3. 驱动问题：确保内核镜像包含了对应的存储控制器（如SD/MMC控制器）和文件系统（如EXT4）的驱动。如果是模块形式，需要包含在initramfs中。

7.3 修改密码后，系统仍提示密码错误

• 现象：用passwd命令成功修改密码，但重启后用新密码无法登录。
• 排查：
  1. 文件系统挂载状态：确保你修改密码时，根文件系统是以**读写（rw）**方式挂载的。如果是以只读（ro）方式挂载，passwd命令会正常执行（因为它修改的是内存中的shadow文件副本），但在同步到磁盘时会失败。使用mount命令确认，并用mount -o remount,rw /重新挂载。
  2. Shadow文件权限：极少数情况下，/etc/shadow文件的权限可能被误修改。其正确权限应为640，所有者root，组shadow。可以用ls -l /etc/shadow检查，并用chmod 640 /etc/shadow修复。
  3. PAM配置问题：非常罕见，但如果系统使用了特殊的PAM（可插拔认证模块）配置，可能会绕过本地shadow文件。在嵌入式环境中较少见。

7.4 系统使用了只读根文件系统（Read-only RootFS）

• 现象：常见于基于Flash的嵌入式设备，为了延长Flash寿命，根文件系统被挂载为只读。即使你在bootargs中加了rw，系统启动后也会被重新挂载为ro。
• 解决方案：
  1. 在单用户模式下：如前所述，先mount -o remount,rw /。
  2. 永久修改：修改密码后，你需要找到让系统以读写方式挂载根文件系统的方法。这通常需要修改/etc/fstab文件（将/对应的条目中的ro或defaults改为rw），或者修改初始化脚本（如/etc/init.d/rcS或systemd的mount单元）。修改完成后，可能还需要执行sync命令确保数据写回。

7.5 针对特定开发板的快速参考

• 树莓派（Raspberry Pi）：更简单。将SD卡插入读卡器，挂载到电脑上。在boot分区（FAT32格式）的cmdline.txt文件中，在行末添加init=/bin/sh，保存。将卡插回树莓派启动即可获得root shell。
• 基于i.MX系列的平台：uboot通常很强大。中断启动后，重点关注bootargs环境变量。其eMMC/SD卡分区编号可能与常见Linux略有不同，使用mmc dev和mmc part命令仔细查看。
• 对于锁定了uboot环境的设备：有些产品化设备会通过printenv命令需要密码，或者禁用了setenv。这时可能需要通过硬件调试接口（如JTAG）来读取Flash内容，或者寻找设备上可能存在的“恢复模式”触发机制（如按住某个按键上电）。

密码恢复的本质是一场与系统启动流程的“赛跑”，核心在于在身份验证这道闸门落下之前，取得控制权。掌握uboot和Linux内核启动参数，是赢得这场比赛的关键。每次成功“救砖”的背后，都是对系统引导过程更深一层的理解。希望这份详尽的指南，能成为你嵌入式工具箱里一件可靠的“万能钥匙”。