为什么在调整根EBS卷的大小后，EC2实例无法正确启动？

我正在使用https://matt.berther.io/2015/02/03/how-to-resize-aws-ec2-ebs-volumes/和http://atodorov.org/blog/2014/02上的说明/ 07 / aws-tip-shrinking -ebs-root-volume-size /移动到磁盘空间较小的EBS卷。在这两种情况下，当我将缩小的EBS卷（如/ dev / xdva或/ dev / sda1都不工作）连接到EC2实例并启动它时，它会自行停止

State transition reason Client.InstanceInitiatedShutdown: Instance initiated shutdown

一些更多的修补，我发现新卷没有BIOS启动分区。所以我使用gdisk创build一个，并将原始卷中的MBR复制到新卷中（这可以起作用，并且可以使用它启动实例）。现在，这个实例并没有终止，但我不能SSH入新启动的实例。

这种情况背后的原因是什么？我怎样才能获得更多的信息（从日志/ AWS控制台等），为什么发生这种情况？

问题是BIOS启动分区。我能够解决这个问题，首先用一个较小的EBS卷初始化一个实例。然后分离音量并将其粘贴到一个实例上，用于从较大的音量或更小的音量中复制内容。这创建了一个实际上起作用的BIOS启动分区。简单地创建一个新的和复制启动分区不起作用。

现在，按照这两个链接中的任何一个概述的步骤将有助于缩小根EBS的体积。

要将GPT分区引导EBS卷缩小到标准映像似乎使用的8GB以下，可以执行以下操作：（从https://matt.berther.io/2015/02/03/how- to-resize-aws-ec2-ebs-volumes / ）

源磁盘是/dev/xvdf ，目标是/dev/xvdg

收缩源分区

 $ sudo e2fsck -f /dev/xvdf1 $ sudo resize2fs -M /dev/xvdf1

会打印类似的东西

 resize2fs 1.42.12 (29-Aug-2014) Resizing the filesystem on /dev/xvdf1 to 257491 (4k) blocks. The filesystem on /dev/xvdf1 is now 257491 (4k) blocks long.

我把它转换成MB，即257491 * 4/1024〜= 1006 MB

从设备到设备（！）复制以上大小+多一点，而不仅仅是分区到分区，因为它包括启动分区中的分区表和数据
```
 $ sudo dd if=/dev/xvdf of=/dev/xvdg bs=1M count=1100 
```

现在使用gdisk修复新磁盘上的GPT分区

 $ sudo gdisk /dev/xvdg

你会大致迎接

 GPT fdisk (gdisk) version 0.8.10 Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use 'v' to verify disk integrity, and perhaps options on the experts' menu to repair the disk. Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header.# Warning! One or more CRCs don't match. You should repair the disk! Partition table scan: MBR: protective BSD: not present APM: not present GPT: damaged **************************************************************************** Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended. **************************************************************************** Command (? for help):

以下是gdisk的键盘输入。要解决这些问题，复制的分区表中存在的数据分区需要调整大小以适应新的磁盘。这意味着需要重新创建更小的属性，并且需要设置属性以匹配旧的分区定义。没有测试它，所以可能不需要将备份表重新定位到磁盘的实际末端，但无论如何我都这样做了：

去额外的专家选项： x
将备份数据结构重定位到磁盘的末尾： e
回到主菜单： m

现在要修复分区大小

打印并记下分区1的一些属性（以及其他非引导分区，如果存在的话）：
i
1
会显示类似的东西

 Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) Partition unique GUID: DBA66894-D218-4D7E-A33E-A9EC9BF045DB First sector: 4096 (at 2.0 MiB) Last sector: 16777182 (at 8.0 GiB) Partition size: 16773087 sectors (8.0 GiB) Attribute flags: 0000000000000000 Partition name: 'Linux'

现在删除
d
1
并重新创建分区
n
1
输入所需的参数。所有的默认值都在这里工作（=按回车键），如果有疑问请参考上面的分区信息
- 第一部门= 4096
- 最后一个扇区=无论是新磁盘的实际结束 – 在这里采取默认值
- type = 8300（Linux）
新分区的默认名称与旧分区的名称不匹配。所以把它改成原来的一个
c
1
Linux （请参阅上面的Partition name ）
接下来要改变的是分区的GUID
x
c
1
DBA66894-D218-4D7E-A33E-A9EC9BF045DB （请参阅Partition unique GUID ，而不是上面的分区GUID代码）

应该是这样的。返回主菜单和打印状态
m
i
1
现在将打印

 Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) Partition unique GUID: DBA66894-D218-4D7E-A33E-A9EC9BF045DB First sector: 4096 (at 2.0 MiB) Last sector: 8388574 (at 4.0 GiB) Partition size: 8384479 sectors (4.0 GiB) Attribute flags: 0000000000000000 Partition name: 'Linux'

唯一的变化应该是Partition size 。

写入磁盘并退出
w
y

增长文件系统以匹配整个（较小的）磁盘。第一步把它缩小到可以装配的最小尺寸
```
 $ sudo resize2fs -p /dev/xvdg1 
```
我们完成了。分离音量和快照。
可选步骤。为AMI选择适当的内核ID。

如果您正在处理PVM映像，并在实例日志中遇到以下挂载错误

内核恐慌 – 不同步：VFS：无法挂载根目录

当你的实例没有通过启动检查时，你可能需要执行这个额外的步骤。

解决这个错误的办法是从你的快照创建镜像时为你的PVM镜像选择合适的内核ID。内核ID（AKI）的完整列表可以在这里获得。

为您的图像选择适当的AKI，它们受到地区和体系结构的限制！