GRUB中set root指定/boot所在分区，root=UUID=...指向根文件系统（/）；前者决定内核读取位置，后者决定系统挂载点，二者可不同，混淆会导致“no such device”或“file not found”错误。
grub> 下怎么 set root 和 root=UUID 不混淆
很多人卡在第一行 set root=(hd0,gpt2) 就出错，本质是没分清两个“root”：GRUB 的 set root 指的是它去哪读内核文件（即 /boot 所在分区），而内核参数里的 root=UUID=... 指的是 Linux 启动后真正的根文件系统（即 / 所在分区）。这两个可以相同，也可以不同——比如 /boot 独立在 (hd0,gpt1)，而 / 在 (hd0,gpt2)，那就得分开设。
常见错误现象：
-
error: no such device: xxx-xxx—— 说明root=UUID=...填错了，不是 GRUB 找不到分区，而是内核启动时找不到根设备 -
error: file '/boot/vmlinuz-...' not found——set root设错了位置，或路径写漏了/boot/
实操建议：
- 先用
ls (hd0,gpt1)/boot/vmlinuz-+ TAB 确认内核是否存在，再决定set root设哪个分区 -
root=后的 UUID 必须来自根分区（/），不是/boot分区；可在 Live 系统中运行sudo blkid查看，重点关注 TYPE="ext4" 或 "xfs" 那行对应的 UUID - 如果记不住 UUID，临时可用
root=/dev/sda2测试（需确认设备名与当前硬件一致），但进系统后必须改回 UUID，否则下次可能因设备名变动失败
linux 命令里 root= 后面该填什么
linux 命令那行的 root= 参数，决定内核挂载哪个设备作为 /。填错就直接 kernel panic，停在 “VFS: Unable to mount root fs”。
使用场景：
- UEFI 系统常见根分区是
/dev/nvme0n1p2或/dev/sda2，对应 UUID 可能是1a2b3c4d-5e6f-7890-g1h2-i3j4k5l6m7n8 - LVM 环境下，
root=要填/dev/mapper/vg0-lv_root或对应 UUID（blkid输出中显示LVM2_member的那一行不作数，要找挂载点为/的逻辑卷） - 加密 LUKS 分区需额外加
rd.luks.uuid=...，但root=仍指向解密后的 mapper 设备，不是原始分区
性能 / 兼容性影响：
- 用设备名（如
/dev/sda2）启动快、无依赖，但设备名可能随硬盘增减变化，重启后失效 - 用 UUID 最稳妥，所有现代发行版默认采用，但输入长串易错；GRUB 中可配合 TAB 补全（部分版本支持）
- 别用 LABEL，某些 initramfs 不识别，尤其 CentOS/RHEL 8+ 默认禁用
initrd 加载失败常见原因和绕过方法
initrd 行出错，多数不是文件缺失，而是 initramfs 本身不兼容当前内核或缺少关键驱动模块。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
常见错误现象：
-
error: you need to load the kernel first—— 忘了先敲linux行，顺序错了 -
error: file '/boot/initrd.img-...' not found—— 路径不对，或 initrd 文件名带.gz或.lz后缀没写全 - 内核启动后卡在 “dracut: FATAL: No root device found” —— initramfs 里没打包对应磁盘控制器驱动（如 NVMe、RAID 卡）
实操建议：
- 用
ls (hd0,gpt2)/boot/initrd+ TAB 查看真实文件名，Ubuntu 常为initrd.img-5.15.0-xx-generic，CentOS 常为initramfs-4.18.0-xxx.el8.x86_64.img - 若怀疑 initramfs 损坏，可尝试跳过它（仅限调试）：
linux /boot/vmlinuz-... root=UUID=... ro init=/bin/bash，直接进入 bash，但无法完成完整启动 - 进系统后立即重建 initramfs：
sudo update-initramfs -u（Debian/Ubuntu）或sudo dracut -f（RHEL/CentOS/Fedora）
chroot 修复 grub.cfg 前必须挂载哪些目录
手动引导进系统只是第一步，不修复 /boot/grub/grub.cfg，下次重启还会回到 grub>。而修复它必须在 chroot 环境中执行 update-grub 或 grub2-mkconfig，否则生成的配置会指向 Live 环境的设备路径。
容易踩的坑：
- 只挂载了
/mnt（根分区），忘了/mnt/boot或/mnt/boot/efi—— 导致update-grub找不到内核文件，报 “no kernels found” - 没挂载
/dev、/proc、/sys——grub-probe无法获取设备信息，grub2-mkconfig失败 - UEFI 系统漏挂
/mnt/boot/efi，grub-install会提示 “EFI directory does not exist”
标准挂载顺序（假设根分区已挂载到 /mnt）：
-
sudo mount /dev/sda1 /mnt/boot（若/boot独立） -
sudo mount /dev/sda2 /mnt/boot/efi（UEFI，ESP 分区通常为 FAT32） sudo mount --bind /dev /mnt/devsudo mount --bind /proc /mnt/procsudo mount --bind /sys /mnt/syssudo chroot /mnt
进 chroot 后验证：ls /boot/vmlinuz* 和 ls /boot/efi/EFI/*/grubx64.efi（UEFI）必须存在，再运行 update-grub 或 grub2-mkconfig -o /boot/grub2/grub.cfg。
最常被忽略的一点：chroot 里执行的 grub-install 必须显式指定 --boot-directory（BIOS）或 --efi-directory（UEFI），否则它会按宿主环境路径写入，导致修复无效。
