USB メモリにブートローダーを分離し安全なデュアルブート環境を実現する
安価なUSBメモリの/boot内にGRUBとEFIシステムパーティションだけ置いておいて、/ディレクトリをWindowsのデータが入っているパーティションと同系列で同居させた状態でLinuxをデュアルブートすることに成功した。以下記事も合わせて読むといいかもしれない。
https://yokkin.com/blog/ways-of-dualbooting-linux.html
目次
筆者環境
自分用のメモなのであくまで参考程度に！
OSやハードウェアの設定など
- Windows 11 Pro
- ライブ環境、インストール環境共にManjaro Linux
- UEFI、CSM（互換性サポートモジュール）はOFF
- セキュアブートもOFF
パーティションなど
/dev/sda 2TBのSerial ATA SSD
/sda1Windows 予約済み/sda2Windows 予約済み/sda31TB, Cドライブ、NTFS/sda4Windows回復環境、NTFS/sda5250GB, ここにUSBのRFS（ルートファイルシステム）を置換する
/dev/sdb 4TBのSerial ATA HDD
/sdb3120GB, exFAT, イメージファイルのバックアップ用
/dev/sdc 16GBのUSB
/sdc1/bootにマウント/sdc2Btrfs でフォーマット済。いくつかのサブボリュームが構成する。@/にマウントする@home/homeにマウント@log/var/logにマウント@cache/var/cacheにマウント
手順
どの作業もバカ慎重になってなりすぎないことはないので、自分が1つ1つ何をしようとしているのか自覚して作業すること。
Manjaro Linuxのインストール
まずは普通にUSBメモリにManjaro Linuxをインストールする。
筆者の環境では、USBメモリは/dev/sdcとして認識された。グラフィカルなインストーラーに完全に任せてOSをインストールすると、このボリュームが2つのパーティションに分けてインストールされる。それぞれ/sdc1がブートパーティションとして/bootにマウントされ、一方で/sdc2が/にマウントされている状態になっている。
/sdc2を見てみると、勝手に上の環境のようにBtrfs上のファイルシステムのルート上にサブボリュームが作られた状態でインストールしてくれる。別におせっかい機能ではないし、スナップショットも取りやすいのでとても良い。
ID 256 gen 9927 top level 5 path @
ID 257 gen 9927 top level 5 path @home
ID 258 gen 9714 top level 5 path @cache
ID 259 gen 9927 top level 5 path @log
ID 260 gen 9487 top level 5 path timeshift-btrfs/snapshots/2022-09-04_11-53-49/@
ID 261 gen 9487 top level 5 path timeshift-btrfs/snapshots/2022-09-07_08-29-49/@
ID 262 gen 9487 top level 5 path timeshift-btrfs/snapshots/2022-09-12_01-22-00/@/etc/fstab を見ると、起動時にこれらのサブボリュームをsubvol=@ オプションをつけて指定のマウント先にマウントするようになっている。
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=2D3C-D977 /boot/efi vfat umask=0077 0 2
UUID=997e00a3-3e58-442e-8a57-317840230a14 / btrfs subvol=/@,defaults,space_cache=v2,noatime,compress-force=zlib:3 0 0
UUID=997e00a3-3e58-442e-8a57-317840230a14 /home btrfs subvol=/@home,defaults,space_cache=v2,noatime,compress-force=zlib:3 0 0
UUID=997e00a3-3e58-442e-8a57-317840230a14 /var/cache btrfs subvol=/@cache,defaults,space_cache=v2,noatime,compress-force=zlib:3 0 0
UUID=997e00a3-3e58-442e-8a57-317840230a14 /var/log btrfs subvol=/@log,defaults,space_cache=v2,noatime,compress-force=zlib:3 0 0外部ライブ環境の起動および作業
外部ライブ環境を起動し、lsblkでデバイス名とUUIDをメモする。
手始めに、USBメモリにインストールしてあるパーティションをddでイメージとしてバックアップするための、バックアップ先を用意する。
# mount /dev/sdb3 /mnt/hdd
バックアップとリストア
USBメモリにインストールしてあるルートパーティションをddでイメージとしてバックアップする。余力があったら、ブートパーティションもバックアップして損はないので、同じようにバックアップしておくとよい。ブートパーティションは小さいのですぐに終わる。
# dd if=/dev/sdc2 of=/mnt/hdd/sdXn.img bs=100M status=progress
バックアップしたイメージを、SSD側に新しく作成しておいたパーティションに流し込む。
# dd if=/mnt/hdd/sdXn.img of=/dev/sdXn bs=100M status=progress
USBメモリ側のUUIDの変更
ddを使ってSSD側のパーティションに流し込んだデータは、USBにあるパーティションのデータの完全な複製である。したがって、SSDにある/dev/sda5のUUIDがUSBメモリ側のもの/dev/sdc2 と重複する状態になる。
実はこれはあまりよろしくない状態で、ときによってはシステムの障害を起こす原因となりうる。というのも、ブート時、手始めにブートローダーのGRUBは、このUUIDを頼りにルートパーティションをマウントするようInitramfsにお願いするだけでなく、Linuxカーネル側も/etc/fstabに記述してあるデバイスを自動でマウントするようになっている。このようにUUIDはOSの起動に際して重要な役目を果たしているため、記述に何らかの異常があるとシステムが起動しなくなってしまう、といった問題が生じる。
これを防ぐためには、USBメモリ側のルートパーティション、すなわち/dev/sdc2 のUUIDを変更する。これによってGRUBがUSBのルートディレクトリを読みに行くことはなくなるので注意すること。
# btrfstune -u /dev/sdc2
ファイルシステムの終了位置の変更
認知負荷を下げたいという理由でここだけGUIを利用した。CUIじゃなくてごめん。
ddでイメージを流し込んだままではもともとUSBにあったパーティションの大きさに等しい16GB分の容量しか使えないので、ファイルシステムの終了位置を250GBのデバイスの領域めいっぱいまで動かす必要がある。GPartedを起動し、/dev/sda5に「チェック」を適用する。
諸問題の解決
デュアルブートでの運用を行うにつれて実際に経験しうる諸問題も発生する。本セクションではこういった問題に対して、解説を行い、その対処療法について紹介する。
Nautilusの左ペインに旧ルートデバイスが表示されるのを防ぐ
ファイルマネージャーのNautilusが左ペインに旧ルートデバイスを表示し続ける問題を解決したい。場所が場所だけにクリックしてしまいやすいし、一発でもクリックしたら簡単にマウントされてしまう点が非常に憎たらしい。ここから先はお好みなので、気になる人は実行する。
手順については、以下記事を参照すること。
https://yokkin.com/blog/disable-unwanted-device-listing-in-nautilus.html
おわりに
Btrfs を使っていると、こういうときにずいぶん柔軟な運用ができるもんだなと感じる。