为什么这种更改会使我的块设备无法引导？

Question

我正在AWS中使用Amazon，并试图在单个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或者其他文件中遗漏了什么，因为我想这个新的配置现在已经和原来的配置不同了。

Answer 1

这可能需要一些前历史的PC启动序列，以充分解释.(现代PC与UEFI的做法不同，但逻辑相似)。

所以让我们回顾一下80年代，当时个人电脑刚开始使用硬盘。

BIOS将加载硬盘的第一个扇区。其中包含主引导记录(MBR)，它是代码和分区表的组合。只有512个字节才能容纳所有这些，所以编码很紧凑。

MBR会查看分区表，找出哪个分区是活动的，哪个分区是从哪里开始的。然后，它将加载一个二级引导系统，该系统存储在该分区中。(从历史上看，这意味着辅助引导加载程序必须位于磁盘的第一个504Mb之内)。这段代码了解文件系统，可以加载操作系统(通常是IO.SYS、MSDOS.SYS、COMMAND.COM)。于是DOS就启动了。一个典型的新PC需要"fdisk /mbr“来安装这个主引导扇区。

事实上，它是MBR中的软件，这使得引导过程更加灵活，并允许交替引导加载程序。Linux的早期引导加载程序是LILO (“Loader")。这里有一个主加载程序，一个辅助加载程序。它了解标准Linux文件系统，并能够双引导Linux和DOS (和Windows)。

后来出现了GRUB (然后是GRUB2)。但是它们都遵循主/辅助引导加载程序过程。

现在，您要做的是在修改/boot分区时移动辅助引导过程。(相当愚蠢的)主引导加载程序不知道在哪里找到智能部件。所以你的虚拟机无法启动。

您需要做的是与旧的"fdisk /mbr“进程的现代等效；您需要告诉您的MBR在哪里找到辅助加载程序。

如何做到这一点取决于您正在使用的引导加载程序。它可能是“grub-安装”或“肮脏的2-安装”或"lilo“。它将依赖于操作系统变体(CentOS，Ubuntu，Debian，Amazon.它们可能都不一样)。

这没有告诉您如何修复您的构建，但至少现在，您应该了解为什么您的操作系统无法启动！

Answer 2

注意，AWS中的引导卷有点特殊，我还没有找到确认它的位置并解释原因，但是根卷被附加为sda1 (xvda1)，请注意末尾的分区1，参见http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html。我认为这可能是bios无法从包含分区表和更多分区的分区启动的原因。

我认为，如果需要多个分区(而不使用附加到根分区中的大文件的循环设备)，就不能避免使用多个卷。