web-dev-qa-db-ja.com

FSTABのUUIDと/ dev / sdX

システムを実行するために/ dev/devnameを強制するLinuxシステムがあります。

proc            /proc            proc    defaults        0       0
/dev/sda1       /                ext3    barrier=1,errors=remount-ro 0       1
/dev/sda5       /opt             ext3    barrier=1,defaults        0       22 
/dev/sda2       /opt/vortex/dvss ext3    barrier=1,defaults 0   3
/dev/sda6       none             swap    sw              0       0
/dev/scd0       /media/cdrom0    udf,iso9660 user,noauto     0       0

現在まで、このシステムは問題なく稼働しています。しかし、インストールされている一部のマシンでは、システムが正しく起動できず、突然「Grubrescue」に入ることがよくあります。

デバイスをセカンダリとしてマウントしてE2Fsckを実行すると、システムを復元できることがわかります。

現在、この失敗に対処しようとしています。 [ GRUBエラー によるシステムブートエラーの修正

順番に、いくつかのフォーラムで、FSTABでUUIDベースの起動を設定するように言われていることに気づきました

uUIDを介して設定した場合に得られるすべての利点は何ですか。

それが私のGRUB ERRORを減らす可能性はありますか？

bootpartitiongrub2fstab
4
Ragav

UUIDは私の問題を解決しましたが、それはあなたの問題と同じでした。

次の抜粋 Arch Wikiから は非常に役立ちます：

マシンに複数のSATA、SCSI、またはIDEディスクコントローラーがある場合、対応するデバイスノードが追加される順序は任意です。これにより、/dev/sdaや/dev/sdb起動ごとに切り替え、起動できないシステム、カーネルパニック、またはブロックデバイスの消失に至ります。永続的な命名により、これらの問題が解決されます。

つまり、マシンがsdaとsdcを任意に交換することを決定する場合があります。その場合、ブートは失敗します。

3
Tommy

man fstabから：

デバイスを明示的に指定する代わりに、UUIDまたはボリュームラベル（e2label（8）またはxfs_admin（8）を参照）によってマウントされる（ext2またはxfs）ファイルシステムを示し、LABEL =またはUUID =と記述します。 、「LABEL = Boot」または「UUID = 3e6be9de-8139-11d1-9106-a43f08d823a6」。これにより、システムがより堅牢になります。SCSI[またはSATA]ディスクを追加または削除すると、ディスクデバイス名は変更されますが、ファイルシステムボリュームラベルは変更されません。

GRUBが起動に失敗することがある理由については、UUIDを設定しても何かが変わるとは思えません（ いくつかの奇妙なBIOS設定が与えられたUUIDでも失敗する可能性があります =）ですが、試してみる価値はあります。

3
zagrimsan