私は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...すべて異なる場合があります)。
私はあなたにこれを言わない何ビルドを編集してください。しかし、少なくとも今は理解しなければなりません。なぜオペレーティングシステムを起動できません!
答え2
AWS のブートボリュームは少し特別であることに注意してください。これを確認して理由を説明できる場所が見つかりませんでしたが、ルートボリュームはsda1(xvda1)にリンクされています。最後にパーティション番号1を書き留めます。http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html。これが、BIOSがパーティションテーブルとより多くのパーティションを含むパーティションから起動できない理由であると思います。
複数のパーティションが必要な場合は、複数のボリュームを使用することを避けることはできません(ルートパーティションの大きなファイルに接続されているループデバイスなどの醜いトリックを使用せずに:D)。