为何U-Boot忽略uEnv.txt中的mmcroot配置？Yocto启动异常

我来帮你一步步排查这个双根文件系统的启动问题——这种情况大概率是U-Boot的环境变量加载、启动脚本逻辑或者内核参数传递环节出了问题，咱们从几个核心点入手：

有时候U-Boot可能没正确读取uEnv.txt，或者存在优先级更高的固化环境变量覆盖了它。你可以在启动时按任意键打断U-Boot的自动启动，进入命令行后执行：

printenv mmcroot

如果输出不是/dev/mmcblk1p3，说明uEnv.txt的配置没被加载。这时候可以手动临时设置试试：

setenv mmcroot /dev/mmcblk1p3
boot

如果手动设置后能正常从p3启动，那问题就出在uEnv.txt的加载逻辑上。

• 首先确认uEnv.txt放在正确的boot分区（一般是/dev/mmcblk1p1），挂载后用ls -l查看文件权限，确保是可读状态。
• 检查文件内的格式：有些U-Boot版本对空格敏感，比如不要写成mmcroot = /dev/mmcblk1p3（等号前后有空格），正确格式应该是mmcroot=/dev/mmcblk1p3，也不要有多余的换行或注释干扰。

很多定制化的U-Boot会使用boot.scr这类启动脚本，可能在读取uEnv.txt后又重新覆盖了mmcroot的值。你可以在U-Boot命令行里查看启动命令链：

printenv bootcmd

如果输出里有类似run boot_mmc的指令，再查看这个指令的具体定义：

printenv boot_mmc

要是发现里面写死了mmcroot=/dev/mmcblk1p2，那你需要修改对应的启动脚本，或者确保uEnv.txt的配置优先级更高。

如果U-Boot这边的配置看起来没问题，但内核还是挂载了p2，那得检查内核实际收到的启动参数。系统启动后执行：

cat /proc/cmdline

看看里面的root=参数是不是/dev/mmcblk1p3。如果不是，说明U-Boot没把正确的参数传递给内核；如果参数正确但还是挂载了p2，那就要检查initramfs的初始化脚本（比如/init）或者/etc/fstab，看有没有强制挂载p2的逻辑。

最后也别忘了检查/dev/mmcblk1p3的文件系统是否正常。在当前启动的系统里尝试挂载它：

mount /dev/mmcblk1p3 /mnt

如果挂载失败，说明p3的根文件系统损坏或不完整，有些U-Boot或内核会自动 fallback 到已知可用的p2启动，这也是常见的容错逻辑。

内容的提问来源于stack exchange，提问作者Dave