この変更によってブロックデバイスが起動しないのはなぜですか?

この変更によってブロックデバイスが起動しないのはなぜですか?

私はAWSでAmazon Linuxを使用しており、コンプライアンスのために単一のEBSボリューム(ブロックデバイス)に複数のファイルシステムを設定しようとしています。そのために、実行中のEC2インスタンスにEBSボリュームをマウントし、一連のコマンドを実行してからマウント解除し、スナップショットを作成してAMIに変換しました。

既存のパーティションを削除して再度追加する「デフォルト」コマンドセットを使用して、これをすべて実行できます。ただし、2 番目のパーティションを追加すると、その 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はこれを異なる方法で実行しますが、ロジックは似ています。)

PCに初めてハードドライブが搭載された1980年代を振り返ります。

BIOSはハードドライブの最初のセクタをロードします。これには、コードとパーティションテーブルの組み合わせであるマスターブートレコード(MBR)が含まれます。これらすべてを収容できる長さは512バイトなので、エンコーディングがタイトです。

MBRはパーティションテーブルを見て、どのパーティションがアクティブでどこから始まるかを調べます。それから中学校システムを起動し、このパーティションに保存します。 (歴史的には、これはセカンダリブートローダがディスクの最初の504 Mb内にあることを意味します。)このコードはファイルシステムを理解し、オペレーティングシステム(通常IO.SYS、MSDOS.SYS、COMMAND.COM)をロードできます。 。これでDOSが起動します。通常、新しいPCにはこのマスターブートセクタをマウントするために「fdisk / mbr」が必要です。

実際にブートプロセスを柔軟にし、代替ブートローダを可能にするのはMBRのソフトウェアです。 Linux用の初期ブートローダーはLILO(「Linuxローダー」)でした。メインローダーと補助ローダーがあります。標準の Linux ファイルシステムを理解し、Linux と DOS (Windows はもちろん) をダブルブートできます。

それからGRUB(そしてGRUB2)が登場しました。ただし、すべて基本/セカンダリブートローダプロセスに従います。

今あなたがしていることは移動する/bootパーティションの変更時に起動プロセスをサポートします。 (やや愚かな)メインブートローダーは、スマート部分をどこで見つけることができるかわかりません。したがって、仮想マシンを起動できません。

あなたがしなければならないことは、MBRにセカンダリローダを見つける場所を教えなければならない以前の "fdisk /mbr"プロセスと同等の最新の作業です。

これを行う方法は、使用するブートローダーによって異なります。 「grub-install」、「grub2-install」、または「lilo」のいずれかです。 OSのバリエーションによって異なります(CentOS、Ubuntu、Debian、Amazon...すべて異なる場合があります)。

私はあなたにこれを言わないビルドを編集してください。しかし、少なくとも今は理解しなければなりません。なぜオペレーティングシステムを起動できません!

おすすめ記事