为啥调整根 EBS 卷大小后 EC2 实例无法正确启动？

Posted

技术标签:

【中文标题】为啥调整根 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 控制台为空。 【参考方案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（以及其他非引导分区，如果存在）的一些属性：i1 会显示类似 

    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'

    现在删除d1 并重新创建分区n1 输入所需的参数。所有默认设置都适用于我（= 按 Enter），如有疑问，请参阅上面的分区信息

    第一个扇区 = 4096 最后一个扇区 = 新磁盘的实际末尾 - 此处采用默认值 类型 = 8300 (Linux)

    新分区的默认名称与旧分区不匹配。所以把它改成原来的 Onec1Linux（见上面的Partition name）

    接下来要更改的是分区的 GUIDxc1DBA66894-D218-4D7E-A33E-A9EC9BF045DB（请参阅Partition unique GUID，而不是上面的分区 guid 代码）

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

    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。

    写入磁盘并退出wy

    增长文件系统以匹配整个（较小的）磁盘。第一步将其缩小到可以容纳的最小尺寸

    $ 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 磁盘进行测试。

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

【讨论】：

以上是关于为啥调整根 EBS 卷大小后 EC2 实例无法正确启动？的主要内容，如果未能解决你的问题，请参考以下文章

EC2 增加大小后无法调整卷大小

实例上未列出增加的 ec2 卷

为啥即使禁用了 KMS 密钥，我仍然能够在 EC2 中读取加密的 EBS 卷数据？

Amazon EC2 - 将根实例存储设备与 EBS 设备交换

如何使用 Boto 启动 EC2 实例，指定 EBS 的大小？

aws相关知识