银河麒麟等基于systemd的系统应优先使用rd.break进入救援环境，它在initramfs阶段中断并挂载/sysroot，需先执行mount -o remount,rw /sysroot再chroot /sysroot；误用init=/bin/bash会修改内存中空文件导致密码失效，且必须执行touch /.autorelabel以修复SELinux上下文。
GRUB编辑时加rd.break还是init=/bin/bash
两者都能进救援环境，但适用场景不同：rd.break是RHEL/CentOS/银河麒麟等基于systemd的系统标准做法，它在initramfs阶段中断，挂载的是/sysroot，必须先chroot /sysroot才能操作真实根文件系统；init=/bin/bash则跳过initramfs直接启动bash，挂载点是/，适合Ubuntu/Debian等发行版，但某些较新内核或启用了Secure Boot的机器可能拒绝该参数。
常见错误：在麒麟或CentOS上误用init=/bin/bash，导致passwd报错“Authentication token manipulation error”，因为/etc/shadow实际位于/sysroot/etc/shadow，而你正在修改的是initramfs里的空文件。
- 银河麒麟、CentOS 7/8、RHEL 7/8 → 优先用
rd.break - Ubuntu 18.04+、Debian 10+ → 优先用
init=/bin/bash - 不确定时，先试
rd.break；若卡在“switch_root: command not found”，再换init=/bin/bash
mount -o remount,rw /sysroot失败怎么办
典型现象是执行后提示“mount: /sysroot: cannot remount sysroot read-write, is write-protected”。这不是命令写错了，而是SELinux或只读挂载策略在起作用。银河麒麟默认启用SELinux，且initramfs中/sysroot初始挂载为ro。
必须按顺序执行：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先运行
mount -o remount,rw /sysroot - 再运行
chroot /sysroot - 如果仍失败，检查是否漏了
rd.break——它才是触发initramfs中断的关键，没加这个参数，/sysroot根本不会被挂载出来 - 极少数情况需临时禁用SELinux：在GRUB编辑界面的内核行末尾加
selinux=0，但重启后要记得恢复，否则touch /.autorelabel才有效
改完密码后必须执行touch /.autorelabel吗
在启用了SELinux的系统（如银河麒麟、RHEL、CentOS）上，**必须执行**。不加这一步，重启后可能卡在登录界面或SSH拒绝连接，因为SELinux上下文丢失，关键文件（如/etc/shadow）标签损坏，login进程无权读取。
原因不是密码本身，而是SELinux强制访问控制机制：passwd命令更新密码时不会自动重打SELinux标签，系统启动时发现标签不一致，就拒绝加载认证模块。
- 银河麒麟系统几乎100%需要
touch /.autorelabel - 执行位置：必须在
chroot /sysroot之后、exit之前 - 不要写成
touch /sysroot/.autorelabel——此时/就是/sysroot，直接touch /.autorelabel - 重启后首次启动会变慢（需重打标签），属正常现象
为什么passwd root输完两次密码却提示“password unchanged”
这不是密码没生效，而是你当前所在环境不是真正的root用户上下文。常见于两种情况：
- 没执行
chroot /sysroot就直接跑passwd root：此时改的是initramfs内存里的/etc/shadow，重启即丢 - 执行了
chroot /sysroot但忘了先mount -o remount,rw /sysroot：/sysroot仍是只读，passwd无法写入文件，静默失败 - 输入密码太简单，被PAM策略拦截（如
BAD PASSWORD: The password fails the dictionary check）：这不是错误，只是警告，继续输入两次仍会成功；但若系统配置了pam_pwquality强策略，可能真的拒绝保存
最稳的验证方式：改完密码后，不重启，直接在chroot里执行getent shadow root，看第二字段是否变成非空的哈希串（如$6$...）。如果是*或!，说明没改成功。
