Почему это изменение делает мое блочное устройство недоступным?

Я работаю с Amazon Linux в AWS и пытаюсь настроить несколько файловых систем на одном EBS томе (блочном устройстве) по соображениям соблюдения. Я делаю это, устанавливая том EBS в уже запущенный экземпляр EC2, выполняя серию команд, размонтируя его, создавая моментальный снимок, а затем превращая его в AMI.

Я могу заставить все работать с «базовым» набором команд, которые просто удаляют и повторно добавляют существующий раздел. Но когда я добавляю второй раздел, я больше не могу запускать какие-либо экземпляры EC2 из этого AMI. Вместо этого, используя функцию «Get Instance Screenshot» в AWS, экземпляр EC2 никогда не загружается, и я вижу следующее:

введите описание изображения здесь

Когда я выполняю следующие команды из экземпляра EC2 хоста, на котором я смонтировал том EBS, все работает так, как ожидалось :

# 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 

/ и т.д. / 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 или, возможно, в другом файле, так как я предполагаю, что эта новая конфигурация теперь уже не совпадает с исходной конфигурацией.

Для полного объяснения этого может потребоваться некоторая предыстория последовательности загрузки ПК. (Современные ПК с UEFI делают все по-другому, но логика аналогична).

Итак, давайте оглянемся на 80-е годы, когда на ПК впервые появились жесткие диски.

BIOS загрузит первый сектор жесткого диска. Это содержало главную загрузочную запись (MBR), которая была комбинацией кода и таблицы разделов. Всего было всего 512 байт, поэтому кодирование было жестким.

MBR рассмотрит таблицу разделов и узнает, какой раздел был активным и где он был запущен. Затем он загрузит дополнительную систему загрузки, которая была сохранена внутри этого раздела. (Исторически это означало, что вторичный загрузчик должен был находиться на первом диске с 504 МБ). Этот код знал о файловой системе и мог загружать ОС (обычно IO.SYS, MSDOS.SYS, COMMAND.COM). И, таким образом, DOS загрузился. Для типичного нового ПК потребуется «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 … все они могут быть разными).

Это не говорит вам, что делать, чтобы исправить вашу сборку, но, по крайней мере, теперь вы должны понять, почему ваша ОС не загружается!

Обратите внимание, что загрузочный том в AWS является особым, я не смог найти место для его подтверждения и объяснить, почему, но корневой том подключен как sda1 (xvda1), обратите внимание на номер раздела 1 в конце, см. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html . Я думаю, что это может быть причиной того, что BIOS не загружается из раздела, который сам содержит таблицу разделов и больше разделов.

Я не думаю, что вы можете избежать использования более одного тома, если вам нужно больше одного раздела (без использования уродливых трюков, таких как устройства loop, прикрепленные к большим файлам в корневом разделе: D).