はじめに

こんにちは、倉野です。

「最強の開発環境、それは 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ならはいるのかな。