Hyper-V中Linux虚拟机密码忘记，如何重置root或用户密码？

Question

在Hyper-V中运行的Linux虚拟机（如Ubuntu、CentOS等）若遗忘root或普通用户密码，因无传统BIOS/UEFI交互界面，无法直接通过GRUB菜单进入单用户模式。常见误区是尝试在Hyper-V“连接”界面按Shift/Ctrl+Alt等键调出GRUB——实际无效，因Hyper-V默认禁用GRUB可见性且不传递部分按键。正确方法需分两步：首先通过Hyper-V管理器挂载该VM的VHD/VHDX磁盘到另一台可登录的Linux主机（如调试VM），以chroot方式挂载根文件系统；随后执行`passwd root`或`passwd username`重置密码，并确保更新`/etc/shadow`权限与SELinux上下文（如适用）。对于UEFI启动的系统，还需注意EFI分区挂载。整个过程无需重装系统，但要求对Linux文件系统结构及chroot机制熟悉。务必操作前快照备份，避免误改fstab或initramfs导致启动失败。

Answer 1

```html

一、现象剖析：为什么Hyper-V中Linux VM无法触发GRUB单用户模式？

在物理机或VMware/VirtualBox中，用户习惯性在启动时狂按Shift（Legacy BIOS）或Esc/Ctrl+Alt+Del（UEFI）以调出GRUB菜单——但在Hyper-V中，该操作100%无效。根本原因有三：

• GRUB可见性被默认禁用：Hyper-V的合成视频驱动（`hv_vmbus` + `hyperv_fb`）不支持传统VGA文本模式切换，且Ubuntu/CentOS默认启用`splash`+`quiet`内核参数，彻底隐藏GRUB界面；
• 按键事件未透传至Guest OS Bootloader：Hyper-V的“连接”窗口本质是Enhanced Session或Basic Session的RDP/VMConnect协议封装，不模拟物理键盘中断，GRUB依赖的`INT 16h` BIOS调用在UEFI固件层即被截断；
• 无BIOS Setup交互入口：Hyper-V虚拟固件为UEFI-only（即使Legacy模式也经由UEFI shim模拟），且不暴露标准F2/F12键功能，无法进入Boot Manager选择“Boot from Firmware Update”等调试路径。

二、误区警示：高频误操作及其后果

误操作	技术原理错误点	潜在风险
在VMConnect窗口反复按Ctrl+Alt+Del	该组合键被Host OS捕获并发送SIGTERM至vmwp.exe进程，非传递至Guest内核	触发VM意外关机，可能损坏ext4 journal
修改VHDX磁盘内/boot/grub/grub.cfg添加init=/bin/bash	grub.cfg为自动生成文件，且Hyper-V下GRUB根本未获得控制权	下次更新kernel后配置被覆盖，徒劳无功

三、核心原理：chroot救援法为何可行？

Linux启动本质是：firmware → bootloader → kernel → init → 用户空间。当无法干预前两阶段时，我们绕过启动流程，直接操作已持久化的根文件系统。关键支撑机制包括：

• 磁盘可挂载性：VHDX是标准NTFS封装的原始块设备镜像，Linux可通过losetup -P识别分区表（GPT/MBR）；
• 命名空间隔离：chroot将当前进程的/重定向至目标根目录，使passwd命令真实写入/etc/shadow而非宿主机；
• SELinux上下文继承：使用mount --bind /proc /mnt/proc等挂载伪文件系统后，chroot环境能正确调用setfiles恢复SELinux标签（对RHEL/CentOS至关重要）。

四、标准化操作流程（含UEFI适配）

flowchart TD
  A[对故障VM创建检查点快照] --> B[关闭故障VM]
  B --> C[在Hyper-V管理器中“编辑磁盘”挂载VHDX至调试VM]
  C --> D{判断启动模式}
  D -->|Legacy BIOS| E[挂载/dev/sdb1为/boot]
  D -->|UEFI| F[挂载/dev/sdb1为/efi, /dev/sdb2为/]
  E --> G[执行chroot挂载链：/proc /sys /dev /run]
  F --> G
  G --> H[执行passwd root && restorecon -Rv /etc]
  H --> I[umount -R /mnt && 弹出磁盘]
  I --> J[启动原VM验证登录]

五、关键命令清单（含权限与SELinux修复）

# 1. 挂载VHDX分区（假设设备为/dev/sdb）
losetup -P /dev/loop0 /path/to/faulty.vhdx
# UEFI场景：sdb1=EFI System Partition, sdb2=rootfs
mkdir -p /mnt/rescue && mount /dev/sdb2 /mnt/rescue
mkdir -p /mnt/rescue/efi && mount /dev/sdb1 /mnt/rescue/efi

# 2. 构建chroot环境（必须！否则passwd失败）
for i in /proc /sys /dev /run; do mount --bind $i /mnt/rescue$i; done

# 3. 进入并重置密码（CentOS/RHEL需SELinux修复）
chroot /mnt/rescue /bin/bash -c 'passwd root'
chroot /mnt/rescue /bin/bash -c 'restorecon -Rv /etc/shadow'

# 4. 验证shadow权限（必须为0000，否则PAM拒绝认证）
ls -lZ /mnt/rescue/etc/shadow  # 应显示 system_u:object_r:shadow_t:s0

六、进阶陷阱与防御性实践

• fstab UUID冲突：若调试VM与故障VM使用相同Linux发行版，blkid输出的UUID可能重复，务必用lsblk -f比对LABEL或PARTUUID；
• initramfs未更新：CentOS 7+修改/etc/shadow后需运行dracut -f（在chroot内），否则新密码不生效；
• 加密LVM卷处理：若VHDX含LUKS加密，须先cryptsetup luksOpen再挂载逻辑卷，且需提前备份/etc/crypttab密钥路径；
• 容器化替代方案：对Kubernetes集群节点，可改用kubectl debug node临时Pod挂载宿主机/proc/1/root实现免重启修复。

```