或
简单的方法是将Centos根卷附加到Amazon Linux机器并解决此问题。不要将Centos根卷附加到另一个运行Centos的ec2示例。AWS Marketplace中的Centos将“centos”作为根卷的标签。因此，当我们将Centos根卷附加到另一台Centos机器时，AWS会混淆要挂载的根卷，并发生异常。

由于被拧紧的根卷和原始示例根卷具有相同的标签附加到卷分区（在我的情况下，我的操作系统是centos6.5，标签是centos_root），因此我们必须更改示例的标签，以便下次启动时它不会查找标签centos_root，而是查找更改后的标签。
首先，通过命令ex. e2 label/dev/xvde your_label更改根卷分区标签，其中/dev/xvde是根分区
第二步，用your_label更改“/etc/fstab and / Boot /grub/grub.conf”中的标签。
第三，停止示例
第四，将拧紧的根卷附加到示例
第五，启动示例
第六，瞧，现在你可以看到搞砸了根卷分区，并将其挂载到一些挂载点，以解决您的问题。

从另一个ec2示例中分离“screwed up”卷
正常 Boot 引导其他示例
将EBS连接到正在运行的示例请参见http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html
以root身份执行fdisk -l，并查找新示例的设备名称
创建一个“挂载点”（一个目录）并在其上挂载所需的磁盘分区
修复后，在装入点上使用umount命令，然后断开卷的连接
如果AMI有市场代码，请尝试此答案中给出的步骤https://serverfault.com/questions/522173/aws-vol-xxxxxxx-with-marketplace-codes-may-not-be-attached-as-as-secondary-dev

PSA：不要在AWS中使用CentOS。
您不能再将CentOS示例的根卷附加到另一个示例。这是出于设计目的，以防止人们规避许可协议。尽管CentOS在技术上是免费的，因为它是一个市场AMI，但规则仍然适用。总的来说，这是一个很好的规则，但它使失败配置的恢复变得不可能。
使用Amazon Linux。它基本上是CentOS。

打开引导加载程序的表。
如果工作示例在作为数据卷（/dev/xvd[f-p]）连接时坚持引导损坏的卷，那么您可以尝试的一个简单的方法是扭转局面，将一个工作根卷作为数据卷连接到损坏的示例。
使用从完好示例借用的根卷，该方法已成功恢复损坏的CentOS 7根卷。两个示例都是从同一个Marketplace AMI构建的，并且没有关于将Marketplace AMI作为数据卷附加的投诉。系统引导了完好卷，而不是损坏卷。（即使损坏的卷仍显示在其原始设备位置/dev/xvda1，而引导的卷位于/dev/xvdf1。）
如果在装入损坏的卷时出现wrong fs type, ...，请检查标签冲突：

# blkid
/dev/xvda1: UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="xfs"
/dev/xvdf1: UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="xfs"

字符串
您可以使用以下命令装载而不检查UUID：

mount -o nouuid /dev/xvda1 /some/where

型
YMMV.