我正在 AWS 中使用 Amazon Linux，并出于合规性原因尝试在单个 EBS 卷（块设备）上设置多个文件系统。为此，我将 EBS 卷挂载到已运行的 EC2 实例，执行一系列命令，卸载它，创建快照，然后将其转换为 AMI。
我可以使用一组“基本”命令来完成所有操作，只需删除并重新添加现有分区即可。但是，当我添加第二个分区时，我无法再从该 AMI 启动任何 EC2 实例。相反，使用 AWS 中的“获取实例屏幕截图”功能，EC2 实例永远不会启动，我看到以下内容：
当我从已安装 EBS 卷的主机 EC2 实例执行以下命令时，一切都按预期进行：
# Make a tar of the current EBS Volume
umount -l /mnt/ebs-volume
mount -o ro /dev/xvdf1 /mnt/ebs-volume
tar -cf /tmp/ebs.tar --exclude='./dev/*' --exclude='./proc/*' --exclude='./sys/*' /mnt/ebs-volume
umount /mnt/ebs-volume
# Replace the old partition with one new partition and format it as ext4
sgdisk --delete 1 /dev/xvdf
sgdisk --new 1:0:+7800M /dev/xvdf && sgdisk --change-name 1:Linux
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf1 && e2label /dev/xvdf1 /
# Mount the new partition and restore the snapshot
mount /dev/xvdf1 /mnt/ebs-volume
cd / && tar -xf /tmp/ebs.tar --acls --selinux --xattrs && rm /tmp/ebs.tar
# I don't make any updates to the /etc/fstab file
但是当我执行这些命令时，EC2实例无法启动如上图：
# Make a tar of the current EBS Volume
umount -l /mnt/ebs-volume
mount -o ro /dev/xvdf1 /mnt/ebs-volume
tar -cf /tmp/ebs.tar --exclude='./dev/*' --exclude='./proc/*' --exclude='./sys/*' /mnt/ebs-volume
umount /mnt/ebs-volume
# Replace the old partition with two new partitions and format them as ext4
sgdisk --delete 1 /dev/xvdf
sgdisk --new 1:0:+7800M /dev/xvdf && sgdisk --change-name 1:Linux
sgdisk --new 2:0:+100M /dev/xvdf
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf1 && e2label /dev/xvdf1 /
/sbin/mkfs.ext4 -F -m0 -O ^64bit /dev/xvdf2
# Mount the new partitions and restore the snapshot
mount /dev/xvdf1 /mnt/ebs-volume
mkdir -p /mnt/ebs-volume/boot && mount /dev/xvdf2 /mnt/ebs-volume/boot
cd / && tar -xf /tmp/ebs.tar --acls --selinux --xattrs && rm /tmp/ebs.tar
# I now execute commands that write the below /etc/fstab file to the volume at /mnt/ebs-volume/etc/fstab
/etc/fstab：
LABEL=/ / ext4 defaults,noatime 1 1
/dev/xvda2 /boot ext4 defaults,noatime 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
为什么添加单独的文件系统会/boot导致此错误？我/etc/fstab是否在我的或另一个文件中遗漏了某些内容，因为我认为这个新配置现在不再与原始配置相同。
答案1
这可能需要一些 PC 启动顺序的前史才能完全解释。 （采用 UEFI 的现代 PC 的做法有所不同，但逻辑相似）。
让我们回顾一下 80 年代，当时 PC 刚开始配备硬盘。
BIOS 将加载硬盘的第一个扇区。其中包含主引导记录 (MBR)，它是代码和分区表的组合。只有 512 个字节可以容纳所有这些，因此编码很紧张。
MBR 将查看分区表并找出哪个分区处于活动状态以及它的起始位置。然后它会加载一个中学引导系统，存储在该分区内。 （从历史上看，这意味着辅助引导加载程序必须位于磁盘的第一个 504Mb 内）。该代码了解文件系统并可以加载操作系统（通常是 IO.SYS、MSDOS.SYS、COMMAND.COM）。这样DOS就启动了。通常，新的 PC 需要“fdisk /mbr”来安装此主引导扇区。
事实上，它是 MBR 中的软件，使得引导过程变得灵活并允许备用引导加载程序。 Linux 的早期引导加载程序是 LILO（“Linux Loader”）。它有一个主装载机和一个辅助装载机。它了解标准 Linux 文件系统，并且能够双启动 Linux 和 DOS（以及 Windows）。
后来 GRUB（然后是 GRUB2）出现了。但它们都遵循主/辅助引导加载程序过程。
现在你正在做的是移动修改/boot分区时的辅助启动过程。 （相当愚蠢的）主引导加载程序不知道在哪里可以找到智能部分。所以你的虚拟机无法启动。
您需要做的是旧的“fdisk /mbr”过程的现代等效项；您需要告诉您的 MBR 在哪里可以找到辅助加载程序。
如何执行此操作取决于您使用的引导加载程序。它可能是“grub-install”或“grub2-install”或“lilo”。这取决于操作系统变体（CentOS、Ubuntu、Debian、Amazon...它们可能都不同）。
这不告诉你什么修复你的构建，但至少现在你应该明白为什么您的操作系统无法启动！
答案2
请注意，AWS中的启动卷有点特殊，我一直无法找到地方来确认它并解释原因，但根卷附加为sda1（xvda1），注意最后的分区号1，看http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html。我认为这可能是 BIOS 无法从本身包含分区表和更多分区的分区启动的原因。
如果您需要多个分区，我认为您无法避免使用多个卷（不使用丑陋的技巧，例如附加到根分区中的大文件的循环设备:D）。