Amazon EC2 Linux インスタンスを間違ったボリュームから起動した問題をトラブルシューティングする - Amazon Elastic Compute Cloud

Amazon EC2 Linux インスタンスを間違ったボリュームから起動した問題をトラブルシューティングする

状況によっては、/dev/xvda または /dev/sda にアタッチしたボリューム以外のボリュームが、Linux インスタンスのルートボリュームになることがあります。これは、別のインスタンスのルートボリュームや、ルートボリュームのスナップショットから作成されたボリュームを、既存のルートボリュームのインスタンスにアタッチした場合に起こります。

これは Linux の初期ラムディスクの挙動です。/ で /etc/fstab として定義されたボリュームを選択した場合でも、一部のディストリビューションでは、ボリュームパーティションにアタッチされたラベルによってボリュームが決定されます。たとえば、/etc/fstab の内容が次のとおりであったとします。

LABEL=/ / ext4 defaults,noatime 1 1 
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

両方のボリュームのラベルを確認すれば、両方に / ラベルが含まれることが判ります。

[ec2-user ~]$ sudo e2label /dev/xvda1 
/ 
[ec2-user ~]$ sudo e2label /dev/xvdf1 
/

この例では、初期ラムディスクの実行後、意図していた /dev/xvdf1 ボリュームからの起動ではなく、/dev/xvda1 がインスタンスを起動するルートデバイスになる結果となりました。これを解決するために、同じ e2label コマンドを使用して、起動ボリュームではないアタッチ済みのボリュームのラベルを変更できます。

場合によっては、/etc/fstab で UUID を指定することで、この問題を解決できます。ただし、両方のボリュームが同じスナップショットから作成された場合、またはセカンダリボリュームがプライマリボリュームのスナップショットから作成されている場合は、両ボリュームは UUID を共有します。

[ec2-user ~]$ sudo blkid 
/dev/xvda1: LABEL="/" UUID=73947a77-ddbe-4dc7-bd8f-3fe0bc840778 TYPE="ext4" PARTLABEL="Linux" PARTUUID=d55925ee-72c8-41e7-b514-7084e28f7334 
/dev/xvdf1: LABEL="old/" UUID=73947a77-ddbe-4dc7-bd8f-3fe0bc840778 TYPE="ext4" PARTLABEL="Linux" PARTUUID=d55925ee-72c8-41e7-b514-7084e28f7334
アタッチされた ext4 ボリュームのラベルを変更するには

  1. e2label コマンドを使用して、ボリュームのラベルを / 以外のものに変更します。

    [ec2-user ~]$ sudo e2label /dev/xvdf1 old/

  2. ボリュームに新しいラベルがあることを確認します。

    [ec2-user ~]$ sudo e2label /dev/xvdf1 
old/
アタッチされた xfs ボリュームのラベルを変更するには

  • xfs_admin コマンドを使用して、ボリュームのラベルを / 以外のものに変更します。

    [ec2-user ~]$ sudo xfs_admin -L old/ /dev/xvdf1
writing all SBs
new label = "old/"

図のようにボリュームラベルを変更した後で、インスタンスを再起動すると、インスタンスの起動時にラムディスクが正しいボリュームを選択するはずです。

重要

新しいラベルを持つボリュームをデタッチし、別のインスタンスに戻してルートボリュームとして使用する場合は、上記の手順をもう一度実行してラベルを元の値に戻す必要があります。これを行わない場合、ラムディスクがラベル / を持つボリュームを見つけることができないため、別のインスタンスが起動しません。