[[diary/Kojima]] ・/etc/fstab, grub.cfg のUUID化 Plamoのデフォルトでは/etc/fstabやgrub.cfgのパーティション指定は /dev/sda1 等のデバイル名を使い続けているのだけれど、デバイス名はカーネルが認識した順番に振られていくので、HDDを増設したりUSBデバイスを接続したまま起動すると、想定したデバイス名が狂って正しく起動できないことがある。 こういう問題に対応するために、最近ではデバイス名ではなくパーティション固有のUUIDで指定できるようになっていて、そういう機能があれば便利かな、と、デバイス名をUUIDに変換するようなスクリプトを書いてみた。 添付しているdev2uuid.shが/etc/fstabのデバイス名の部分をそれぞれのUUIDに変換するスクリプトで、grub_partuuid.shがgrub.cfgでカーネルに与えている root=... の部分をPARTUUIDに変換するスクリプト。 grub_partuuid.shでgrub.cfgのroot=...をPARTUUIDに書き換えると、ルートパーティションを示す /dev/root のシンボリックリンクがうまく生成できないので、/sbin/link_rootdev.sh も添付のスクリプトと入れ替える必要がある。 なお、/etc/fstabでマウントするパーティションはUUIDで指定するのだけれど、grub.cfgで指定する root=... の部分はUUIDとは異なるPART_UUIDで指定しなければいけないので、/etc/fstab の設定と grub.cfg の設定は一致しないので注意。 ざっと調べたところ、ファイルシステムのUUIDはそれぞれの「ファイルシステム」の内部にメタデータとして記録されているので、mkfs.xxx でファイルシステムを作り直すと新しいUUIDが振り直される。それに対し、PART_UUIDはHDDの「パーティション」に対して振られるUUIDで、HDDのパーティション・テーブルに記録されるので、HDDのパーティションテーブルを再生成しないかぎりファイルシステムを作り直しても変らない。なお、GPT形式のHDDではパーティション・テーブル内にPART_UUIDにGUIDを割りあてるための欄が用意されているのでPART_UUIDは16バイトのGUID(da6b6078-1a9d-4222-b392-a30b8c003d91等)になるのに対し、MBR形式ではそのような欄は用意されないので、MBRのデータから生成した(?)HDDのIDにパーティション番号を付けたようなスタイルになる(38633862-02等)。 一応、手元の仮想環境や実機では動いているものの、それ以外の実績は無いので使用の際は要注意。dev2uuid.shもgrub_partuuid.shも、元のファイルに.orgを付けて残すので、両者を比べて問題があれば元のファイルに戻すこと。 - よそのディストリではgrub.cfgのroot=.... の部分にUUIDを指定していることもあるのだけれど、これはカーネルではなく initrd のレベルでUUIDからデバイス名を引いてマウントすることで実現している模様。 -- [[kojima]] &new{2015-12-29 (火) 23:02:22}; - Plamoではext4やbtrfsのドライバをカーネル組み込みにしているのでinitrdを使わなくても読めるんだけど、普通はこれらはモジュール化してinitrdレベルでロードして使うので、ファイルシステムのモジュールを持たないカーネルはUUIDを読み込む機能は無く、PART-UUIDしか読めないので、initrdでよきにはからっているらしい。。 -- [[kojima]] &new{2015-12-29 (火) 23:03:57}; - Plamoではext4やbtrfsのドライバをカーネル組み込みにしているのでinitrdを使わなくても読めるんだけど、普通はこれらはモジュール化してinitrdレベルでロードして使うので、ファイルシステムのモジュールを持たないカーネルはUUIDを読み込む機能は無く、PART-UUIDしか読めないので、initrdでよきにはからうようにしているらしい。 -- [[kojima]] &new{2015-12-29 (火) 23:03:57}; #comment