はじめに
こんにちは、倉野です。
「最強の開発環境、それは Arch Linux(と Hyprland)。」
そんな甘い響きに誘われて、Windows と elementary OS のデュアルブート環境から、Windows + Arch Linux という構成に移行することにしました。
公式インストーラーである archinstall を使えば楽勝だと思っていたのですが、消去したはずの元OSが雑草のような生命力でブートメニューに居座り続ける というホラー現象に遭遇したので、その修復記録を残しておきます。
同じような沼にハマった同志の助けになれば幸いです。
環境と目的
- マシン: ASUS Vivobook 15X OLED M1503QA
- 元環境: Windows 11 / elementary OS (デュアルブート)
- 目的: elementary OS を消滅させて、その跡地に Arch Linux を建てる(Windowsは温存)
-
使用ツール:
archinstall(Arch Linux公式の便利ツール)
事件発生:インストールしたのにArchがいない!
archinstall を起動し、ウキウキで以下の設定を行いました。
-
elementary OS のパーティション (
ext4)- フォーマットして
/(ルート) に割り当て。よし、これでelementaryとはお別れだ。
- フォーマットして
-
WindowsのEFIパーティション (
FAT32)- フォーマットせずに
/bootに割り当て。(※Windowsを消すと大変なことになるので)
- フォーマットせずに
インストールはエラーもなく正常終了。「Reboot」を選択して、いざ新世界へ!
しかし、再起動後のGRUBメニューに表示されたのは……
- elementary OS (←!?!?!?)
- Windows Boot Manager
肝心の「Arch Linux」がいません。
フォーマットして消したはずの elementary OS が、雑草のような凄まじい生命力でメニューに残り続け、新入りの Arch が完全に無視されている状態でした。
「え、僕のArch、どこに行っちゃったんですか…?」
なぜこんなことになったのか(原因の深掘り)
手順は間違っていないはず。調べてみると、便利な archinstall 君の「気の利かなさ」…いや、**「優しすぎる性格」**が原因だったことが分かりました。
1. 「上書き」ではなく「ルームシェア」を選んだ優しさ
私は /boot (EFIパーティション) に対して「ここにArchを入れるからよろしく!」と頼みました。
人間の心理としては**「元カレ(elementary OS)の荷物は全部捨てて、俺の色に染めてくれ」**という気持ちです。
しかし、archinstall の挙動は違いました。
人間の期待: 「elementaryのファイル? 邪魔だから消して消して!」
archinstall: 「あ、Windowsさんがいますね。隣にelementaryさんも住んでますね。じゃあ僕は彼らの荷物には指一本触れず、部屋の隅っこにArchの荷物をそっと置いておきますね」
結果、EFIパーティションの中には elementary フォルダと Arch フォルダが仲良くルームシェアすることに。
物理的にファイルが残っている以上、消えることはありません。彼は断捨離ができないタイプだったようです。
2. Archの挨拶が小声すぎた(NVRAM問題)
これが最大の原因です。
PCのマザーボードには「起動順序リスト(NVRAM)」という名簿があり、そこには以前から住んでいる elementary OS が「第1位」 として登録されていました。
archinstall も裏でこっそり「Archも入りました…」と名簿に書き込もうとはしたはずです。
しかし、既存の第1位(elementary)を**蹴落としてまで自分を1位にするほどの強引さ(--force)**が足りなかったようです。
その結果、PC起動時にマザーボードはこう判断しました。
マザーボード: 「お、新しいArchってやつが来たらしいな。でも名簿(NVRAM)を見ると…1番偉いのは elementary 様って書いてあるぞ! よし、elementary 様をお呼びしろ!!」
PC: 「へい!! ……あれ? 呼びに行きましたが、中身(OS本体)が空っぽです!!(起動失敗)」
つまり、「元カレの表札が玄関に一番デカく掲げられたまま、新しい彼氏が家に入ろうとして締め出された」 というのが事の真相でした。
解決策:chrootしてGRUB再インストール
自動インストーラーが優しすぎるなら、人間が手動で「オラッ!」とやるしかありません。
(「最初から手動インストールしろ」というマサカリは勘弁してください…)
インストールメディア(USB)からもう一度立ち上げ、chroot(インストールしたArchの中に潜り込む) してブートローダーを強制的に修復しました。
1. パーティションの確認
まずは lsblk で、現状を確認します。
lsblk
# または
lsblk -f
私の環境では以下の通りでした。
-
/dev/nvme0n1p4: Arch Linux本体 (ext4) -
/dev/nvme0n1p1: EFIシステムパーティション (vfat/ Windowsと共用)
2. ファイルシステムのマウント
Archのシステムに入り込む準備をします。
# Arch本体を /mnt にマウント
mount /dev/nvme0n1p4 /mnt
# EFI領域を /mnt/boot にマウント
mount /dev/nvme0n1p1 /mnt/boot
3. chroot(システムに潜入)
以下のコマンドで、USB上のLinuxから、SSD上のArch Linuxへ操作権を移します。
arch-chroot /mnt
プロンプトの表示が変われば成功です。ここからはSSDの中の世界です。
4. GRUBの再インストールと設定更新
ここが本番です。GRUBを強制的にインストールし、NVRAM(ブート順序)を上書きします。
優しさは捨ててください。
# GRUBをEFIにインストール(IDをArchとして登録)
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=Arch
# 設定ファイルを生成(Windowsなどを再検出させる)
grub-mkconfig -o /boot/grub/grub.cfg
grub-mkconfig の実行結果に以下が表示されれば勝利確定です。
Found linux image...
Found Windows Boot Manager...
5. 再起動
chrootから抜けて再起動します。
exit
reboot
これで無事に「Arch Linux」が起動メニューに表示され、ログインできるようになりました!
まとめ
archinstall は非常に便利ですが、複雑なデュアルブート環境(特にOSの入れ替え)では、ブートローダーの登録まで完璧にこなしてくれないことがあります。
「インストールに失敗した?」と焦って再インストールする前に、「chrootしてブートローダーだけ修復する」 という手段を知っておくと、時間を無駄にせず済みます。
最後に
こうして私は、苦労の末にあとから今話題のOmarchyをいれ、「最強の開発環境」を手に入れました。
OSの起動も爆速、ウィンドウ操作も爆速です。
あとは、この最強の環境に見合うだけの「私のプログラミングスキル」をインストールするだけなのですが、どうやら sudo pacman -S skill では入らないようです。
yayならはいるのかな。