# 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/xvda1` ボリュームからの起動ではなく、`/dev/xvdf1` がインスタンスを起動するルートボリュームになる結果となりました。これを解決するために、同じ **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/ ``` 1. ボリュームに新しいラベルがあることを確認します。 ``` [ec2-user ~]$ sudo e2label /dev/xvdf1 old/ ``` **アタッチされた xfs ボリュームのラベルを変更するには** + **xfs\$1admin** コマンドを使用して、ボリュームのラベルを `/` 以外のものに変更します。 ``` [ec2-user ~]$ sudo xfs_admin -L old/ /dev/xvdf1 writing all SBs new label = "old/" ``` 図のようにボリュームラベルを変更した後で、インスタンスを再起動すると、インスタンスの起動時にラムディスクが正しいボリュームを選択するはずです。 **重要** 新しいラベルを持つボリュームをデタッチし、別のインスタンスに戻してルートボリュームとして使用する場合は上記の手順をもう一度実行してラベルを元の値に戻す必要があります。これを行わない場合、ラムディスクがラベル `/` を持つボリュームを見つけることができないため、別のインスタンスが起動しません。