遇到这种情况很常见——EC2的根设备路径并不是固定的/dev/xvda或/dev/sda1，它会根据实例的硬件类型、虚拟化模式（PV/HVM）以及是否采用Nitro系统而变化。结合你的情况（磁盘能在新实例正常挂载，旧实例不行），下面列出其他可能的路径和排查方法：

1. Nitro系统实例的NVMe设备路径 #

现在大多数新一代EC2实例（比如t3、m5、c5系列）采用Nitro系统，这类实例的根卷会被识别为NVMe设备，路径通常是：

• /dev/nvme0n1（整个磁盘）
• /dev/nvme0n1p1（根分区）
  如果你的旧实例是这类Nitro实例，之前尝试的传统路径肯定不生效。

2. 检查旧实例的官方根设备名称 #

最准确的方法是直接从EC2控制台获取旧实例的根设备标识：

• 登录EC2控制台，找到目标旧实例，进入详情标签页
• 找到「根设备」字段，里面会明确显示该实例使用的根设备路径（比如/dev/sda1或/dev/nvme0n1p1）
  这个路径是AWS官方定义的，直接用它挂载即可。

3. 其他可能的传统设备路径 #

如果你的旧实例是较老的非Nitro实例，除了/dev/xvda和/dev/sda1，还可以尝试：

• /dev/xvda1（HVM实例常见的根分区路径）
• /dev/sda（整个磁盘，部分PV实例可能直接用磁盘而非分区作为根设备）
• 少数特殊AMI可能会将根分区设为/dev/xvda2，这种情况比较罕见，但也可以尝试排查。

4. 排查旧实例的设备识别情况 #

如果能通过AWS Systems Manager（SSM）或者救援模式临时访问旧实例，可以执行以下命令确认设备：

• 列出所有块设备，查看大小匹配的目标磁盘：

  lsblk
  

  输出中会显示设备名称、分区和挂载点，根设备通常会关联/挂载点（如果实例之前正常运行过）。
• 检查系统默认的根设备符号链接：

  ls -l /dev/root
  

  这个链接会指向实际的根设备路径，直接用这个路径挂载即可。

关键提示 #

你的磁盘能在新实例正常挂载，说明磁盘本身没有问题，问题大概率出在旧实例的设备命名规则和新实例不同。比如旧实例是PV虚拟化模式，新实例是HVM，或者旧实例是Nitro系统而你用了传统路径。

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