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

【问题标题】：Why does EC2 instance not start correctly after resizing root EBS volume?为什么调整根 EBS 卷大小后 EC2 实例无法正确启动？
【发布时间】：2015-09-23 14:05:57
【问题描述】：

我使用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 制作了一个并将 MBR 从原始卷（有效并且我可以使用它启动实例）复制到新卷。现在实例没有终止，但我无法通过 ssh 连接到新启动的实例。

发生这种情况的原因可能是什么？如何获取更多信息（从日志/AWS 控制台等）了解为什么会发生这种情况？

【问题讨论】：

您的机器使用什么操作系统？你在 AWS EC2 控制台 -> Syslog 中有什么吗？
Amazon Linux 和 AWS EC2 控制台为空。

标签： linux amazon-web-services amazon-ec2 amazon-ebs

【解决方案1】：

要将 GPT 分区的引导 EBS 卷缩小到标准映像似乎使用的 8GB 以下，您可以执行以下操作：（dd 方法与 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
输入所需的参数。所有默认设置都适用于我（= 按 Enter），如有疑问，请参阅上面的分区信息
- 第一个扇区 = 4096
- 最后一个扇区 = 新磁盘的实际末尾 - 此处采用默认值
- 类型 = 8300 (Linux)
新分区的默认名称与旧分区不匹配。所以把它改成原来的 One
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 映像并在实例日志中遇到以下 mount error

内核崩溃 - 不同步：VFS：无法挂载根目录

当您的实例未通过启动检查时，您可能需要执行此额外步骤。

解决此错误的方法是在从快照创建映像期间为您的 PVM 映像选择正确的内核 ID。可以通过here 获取内核 ID (AKI) 的完整列表。

请为您的图像选择合适的 AKI，它们受区域和架构的限制！

【讨论】：

删除/重新创建不影响实际数据？只有分区表？
@Suncatcher 是的，分区表不知道文件系统中的数据，它只需要知道文件系统在字节边界方面的位置，然后您重新创建该数据
为您的解决方案添加了可选步骤，这在我的序列中没有成功调整大小。谢谢，伙计！
谢谢你，我很惊讶它没有被标记为答案
正是我需要的，非常感谢@zapl 和 Suncatcher！希望我有办法让你们喝咖啡什么的

【解决方案2】：

问题出在 BIOS 引导分区。我能够通过首先初始化一个具有较小 EBS 卷的实例来解决这个问题。然后分离卷并将其附加到一个实例，该实例将用于从较大的卷或较小的卷中复制内容。这创建了一个实际工作的 BIOS 引导分区。简单地创建一个新分区并复制引导分区是行不通的。

现在遵循两个链接中的任何一个中列出的步骤将有助于缩小根 EBS 的体积。

【讨论】：

【解决方案3】：

今天，使用 UBUNTU 在这里没有任何其他解决方案。但是，我找到了它：

谨慎起见：快照大卷（备份）
CREATE 一个实例 IDENTICAL 尽可能像 LARGE volume 效果很好。 但体积较小（所需大小）
分离他的新卷并ATTACH大卷（如/dev/sda1）和START实例
将 较小的 新卷附加为 /dev/sdf
在新实例中登录。在 /mnt 上挂载较小的卷： sudo mount -t ext4 /dev/xvdf1 /mnt
删除 /mnt 上的所有内容。忽略警告/错误，因为 /mnt 无法删除 :) 使用 sudo rm -rf /mnt
将整个 / 复制到较小的卷：sudo cp -ax / /mnt
从实例退出并在 AWS 控制台中停止
分离两个卷。现在，重新附加较小的卷，重要的是，作为 /dev/sda1
启动实例。登录实例并以较小的音量确认一切正常
删除大卷，删除大快照，创建小卷的新快照。结束。

【讨论】：

老兄！传奇！这是唯一对我的 Ubuntu 20.04.1 EC2 实例有效的步骤。其他指南会使实例无法启动。
这个答案你应该得到奖牌。这是迄今为止缩小根 EBS 卷的最简单方法，我可以确认它有效。
只有这种方法适用于 ubuntu-focal-20.04-amd64-server AMI，其他方法会产生无法启动的卷

【解决方案4】：

以上程序不完整，缺少步骤：

复制磁盘 UUID
安装 grub 引导加载程序
复制标签

更完整的程序可以在这里找到：

https://medium.com/@m.yunan.helmy/decrease-the-size-of-ebs-volume-in-your-ec2-instance-ea326e951bce

这个过程更快更简单（没有 dd/resize2fs 只有 rsync）。

使用较新的 Nvme AWS 磁盘进行测试。

如果您需要帮助，请发布任何问题

【讨论】：