【最新Ubuntu 26.04 LTS】サーバー構築入門 虎の巻：OSインストール時の「つまずき」完全トラブルシューティング

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「最新Ubuntu 26.04 LTS サーバー構築入門」シリーズ本編をご愛読いただきありがとうございます。

今回は、読者の皆様から寄せられた多くの悲鳴（SOS）にお応えするための【インストール・トラブルシューティング特大号】です。
「解説記事の通りに進めようとしたのに、最初のUSBブートすらできない！」「インストール中に画面が真っ暗になってフリーズした！」「再起動したら No Bootable Device と表示されてOSが立ち上がらない！」
サーバー構築の第一歩であるOSインストールは、実はハードウェア（物理サーバーやPC）との相性問題が最も出やすく、多くの初心者がここで挫折してしまいます。

本記事は、仮想マシン（VM）ではなく、物理サーバーやミニPCに直接Ubuntuをインストールする際（ベアメタル構築）に発生するトラブルに特化した、実践的な逆引き辞典です。困った時の「お守り」として必ずブックマークしておいてください。

---

1. 【フェーズ1】USBメモリから起動しない・インストーラーが立ち上がらない

UbuntuのISOイメージをUSBメモリに書き込み、PCに挿して電源を入れたのに、そのまま元のWindowsが立ち上がってしまったり、「Operating System not found」と表示されたりするトラブルです。

1-1. 原因と対策の切り分けリスト

疑うべきポイント	詳細な原因とプロの対応策
ISOイメージの破損（チェックサム不一致）	ダウンロード時のネットワークの瞬断などで、ISOファイル自体が壊れている可能性があります。必ず公式サイトで配布されている「SHA256チェックサム」と、ダウンロードしたファイルのハッシュ値が完全に一致するか確認してください。
USB書き込みソフトの方式ミス	「Rufus」を使用する場合、「ISOイメージモード」で書き込むと最新のUbuntuインストーラーが起動しないハードウェアがあります。Rufusの書き込み時にプロンプトが出たら、必ず「DDイメージモードで書き込む」を選択してください。または「BalenaEtcher」を使用すると失敗が減ります。
BIOS/UEFIの起動順位（Boot Order）	PCの電源を入れた直後に F2, F12, Del などを連打し、BIOS設定画面に入ります。「Boot Sequence（起動順序）」で、USBメモリ（UEFI: USB Flash Drive 等）を一番上に設定します。
セキュアブート（Secure Boot）の妨害	Ubuntu 26.04はセキュアブートに対応していますが、一部のマザーボードでは独自の署名を弾くことがあります。BIOSのセキュリティタブで「Secure Boot」を一時的に「Disabled（無効）」にして試してください。
Fast Boot（高速スタートアップ）の悪影響	Windowsの「高速スタートアップ」が有効になっていると、USBからの起動をBIOSがスキップします。Windows側のコントロールパネルから「高速スタートアップを有効にする」のチェックを外すか、BIOSで「Fast Boot」を無効にしてください。

---

2. 【フェーズ2】画面が真っ暗になる・グラフィック関連のフリーズ（nomodesetの魔法）

USBブートメニューの「Try or Install Ubuntu Server」を押した後、Ubuntuのロゴが出たまま固まったり、画面が真っ暗（ブラックアウト）になって信号が途絶えたり、謎の文字が永遠にスクロールし続ける「カーネルパニック」に陥るパターンです。

2-1. 原因は「グラフィックドライバとカーネルの衝突」

サーバー用途であっても、PCにNVIDIA製のグラフィックボード（GPU）や、特殊なAMD製の統合チップが搭載されている場合、Ubuntu標準のオープンソースドライバ（nouveau 等）とハードウェアの相性が悪く、映像出力の初期化フェーズでカーネルがフリーズすることが多々あります。

2-2. プロの回避術：「nomodeset」パラメータの付与

このフリーズを回避する魔法の言葉が nomodeset（ノーモードセット）です。これは「OSのインストールが終わるまで、高度なグラフィックドライバを読み込まず、最低限の汎用VGAドライバで画面を映せ」というカーネルへの命令です。

これでフリーズせずにインストーラーが立ち上がれば、グラフィックドライバの問題で確定です。サーバー用途であればGUIは使わないため、インストール後もこの状態で全く問題ありません。

---

3. 【フェーズ3】ストレージが見えない！NVMe SSDやRAIDの認識エラー

無事にインストーラーが進み、ディスクのパーティション設定画面（Storage configuration）に来たのに、「インストール先のディスクが1つも表示されない（あるいはUSBメモリしか見えない）」という絶望的なトラブルです。

3-1. Intel VMD / RST（Rapid Storage Technology）の罠

最近のIntel製CPUを搭載したノートPCやミニPCでは、BIOSでストレージのモードが「Intel RST Premium (RAID)」や「Intel VMD (Volume Management Device)」に設定されていることが非常に多いです。
Windowsはこのモードを専用ドライバで処理しますが、Linuxカーネル（Ubuntu）はデフォルトでこのRAIDコントローラーを通してNVMe SSDを認識することができません。

3-2. 解決策：BIOSで「AHCI」モードに変更する

PCを再起動し、BIOS設定画面に入ります。

BIOSメニュー（メーカーにより異なります）	変更すべき設定値
SATA Operation / Storage Configuration	RAID または Intel RST から AHCI に変更する。
VMD Setup Menu / Intel VMD Controller	Disabled（無効）に変更する。

※注意：もしWindowsとUbuntuの「デュアルブート」を構築しようとしている場合、この設定をAHCIに変更すると、既存のWindowsがブルースクリーンになって起動しなくなります（Windows側でセーフモードを経由したレジストリ変更の事前準備が必要です）。サーバー専用機にするのであれば、迷わずAHCIに変更してください。

---

4. 【フェーズ4】Subiquityインストーラー実行中のクラッシュとログ解析

パーティション設定も終わり、ファイルのコピーが始まった（Installing system…）のに、途中で赤いエラー画面が出て「Install failed!」と表示され、インストールが中断してしまうケースです。

4-1. エラーの原因をログから探る

Ubuntu Serverのインストーラー（Subiquity）がクラッシュした場合、画面の View full log を選択するか、Ctrl + Alt + F2 を押して裏側の仮想コンソールに切り替え、以下のログファイルを直接確認します。

# インストーラーの詳細な動作ログを確認する
cat /var/log/installer/subiquity-server-debug.log | less

# カーネルやシステム全体のエラーを確認する
cat /var/log/syslog | grep -i error

4-2. 典型的なクラッシュ原因と対策

ログの特徴的なキーワード	原因と対策
OSError: [Errno 28] No space left on device	ディスク容量不足。 パーティション設定（LVM）でルートディレクトリ（/）に割り当てた容量が少なすぎます。最低でも15GB〜25GB以上を割り当てて再試行してください。
apt-get: Connection timed out / Archive mirror not found	ネットワークエラー。 インストール中に最新のパッケージをダウンロードしようとして失敗しています。ネットワークケーブルが抜けているか、IP設定が間違っています。LANケーブルを挿し直すか、「Offline install」を選択してください。
grub-install /dev/sda failed. This is a fatal error.	ブートローダーの書き込み失敗。 UEFIモードで起動したのに、ディスクがMBR形式でフォーマットされているか、EFIシステムパーティション（/boot/efi）が正しく作成されていません。ディスク全体をフォーマット（Use an entire disk）してやり直すのが確実です。

---

5. 【フェーズ5】インストール完了後「No Bootable Device」で起動しない

「Installation complete!」と表示され、喜んでUSBメモリを抜いて再起動したのに、真っ暗な画面に「No Bootable Device（起動可能なデバイスがありません）」や「Reboot and Select proper Boot device」と表示され、Ubuntuが全く立ち上がらない絶望的なケースです。

5-1. EFIブートエントリの登録漏れ

近年のUEFIマザーボードは、OSをインストールしたディスクがあっても、マザーボード内のメモリ（NVRAM）に「Ubuntuの起動プログラム（GRUB）はここにあるよ」という「EFIブートエントリ」が登録されていないと、OSを起動してくれません。
通常はインストーラーが自動で登録しますが、マザーボードのバグやセキュアブートの影響で登録に失敗することがあります。

5-2. BIOSでの手動追加

まずはBIOS画面に入り、「Boot」タブを確認します。もし ubuntu という名前の起動項目がなければ、手動で追加（Add New Boot Option）できるBIOSもあります。
ファイルパスとして \EFI\ubuntu\grubx64.efi または \EFI\ubuntu\shimx64.efi（セキュアブート時）を指定して登録し、それを起動順位の1番に設定してください。

BIOSで追加できない場合は、次章の「Live USBを使った修復」というプロの絶技が必要になります。

---

6. 【プロの絶技】Live USBと「chroot」を用いた壊れたGRUBの完全修復手順

インフラエンジニアであれば絶対にマスターしておかなければならない「究極の復旧技術」があります。それが「chroot（チェンジルート）」を用いたブートローダー（GRUB）の強制再インストールです。
この技術を使えば、OSが起動しなくなったサーバーを、USBメモリ経由で「外側から手術」して直すことができます。

Step 1: Live USBからレスキューモードで起動

インストールに使ったUbuntuのUSBメモリを再度挿し、「Try or Install Ubuntu」を選択します。インストーラー画面が出たら、インストールは進めずに Help メニューから Enter shell（または Ctrl + Alt + F2）を選んで、root権限の黒い画面（ターミナル）に入ります。

Step 2: インストール先のパーティションを特定

lsblk
# または
sudo fdisk -l

出力から、Ubuntuをインストールしたルートパーティション（例：/dev/nvme0n1p2 やLVMなら /dev/mapper/ubuntu--vg-ubuntu--lv）と、EFIパーティション（例：/dev/nvme0n1p1、サイズが500MB程度のvfat）を特定します。

Step 3: ディスクをマウント（マトリョーシカのように組み立てる）

Live USBの環境（/mnt）に、壊れたハードディスクのパズルを正しく組み立てていきます。

# ルートディレクトリをマウント
sudo mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt

# EFIパーティションをマウント
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

# OSが動作するために必要な仮想ファイルシステムをバインドマウント
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run

Step 4: chrootでハードディスク内に「侵入」する

ここが魔法のコマンドです。

sudo chroot /mnt

プロンプトが変わります。今、あなたは「USBのOS」から「ハードディスクの中の壊れたUbuntu」に乗り移りました。 ここで実行するコマンドはすべて、壊れたシステムに対して適用されます。

Step 5: GRUBの再インストールとEFIエントリの修復

# GRUBパッケージをNVRAM（UEFI）に強制的に再インストール
grub-install /dev/nvme0n1

# ブート設定ファイルの再生成
update-grub

# 終了して元のUSB環境に戻る
exit

Step 6: マウント解除と再起動

# 組み立てたパズルを丁寧に片付ける
sudo umount /mnt/run
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev
sudo umount /mnt/boot/efi
sudo umount /mnt

# 再起動
sudo reboot

USBを抜いて祈りましょう。マザーボードのNVRAMに正しくUbuntuが登録され、紫色の見慣れたGRUBメニュー、そしてログインプロンプトが表示されれば、あなたは「システムの死の淵からサーバーを蘇らせた」ことになります。

---

7. AIを活用した「カーネルパニック＆インストールログ」の高度な解析プロンプト

どうしてもインストールが失敗し、原因が特定できない場合、エラーで止まった画面の写真や、抽出したログをAI（GeminiやChatGPT）に解析させるのが現代の最強のトラブルシューティングです。

7-1. インストール障害解析用の神プロンプト

USBブート時やインストール中のエラーをAIに投げる際は、以下のフォーマットを使用すると的確な回答が得られます。

「あなたはLinuxカーネル開発およびUbuntuインフラ構築のシニアエンジニアです。
現在、物理サーバーに『Ubuntu 26.04 LTS』をインストールしようとしていますが、致命的なエラーが発生して先に進めません。

【環境情報】
・CPU: (例: Intel Core i7-13700K)
・GPU: (例: NVIDIA RTX 4070)
・ストレージ: (例: 1TB NVMe SSD)
・BIOSモード: UEFI (セキュアブート有効)

【エラーの症状と出力ログの抜粋】
(ここに画面に表示されているエラーメッセージや、/var/log/syslog のエラー行をそのまま書き写すか貼り付ける)
例：
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
ACPI Error: AE_ALREADY_EXISTS

【依頼事項】
1. このカーネルパニック、またはフリーズの『ハードウェアレベルの根本原因』を論理的に推測してください。
2. GRUBのカーネルパラメータ（nomodeset, acpi=off, nvme_core.default_ps_max_latency_us など）を用いて、この状態を回避してインストーラーを起動するための具体的な手順をステップバイステップで教えてください。
3. もしBIOS/UEFIの設定変更が必要な場合、どの項目を確認すべきか3つリストアップしてください。」

AIはあなたのハードウェア構成とエラーログを照らし合わせ、「ACPI関連のエラーが出ているため、マザーボードの省電力管理とUbuntu Kernel 7.0の相性が悪いです。GRUB編集画面で `acpi=off` または `pci=noacpi` を追加して起動してみてください」といった、マニアックで的確な回避策を瞬時に提示してくれます。

---

総まとめ：トラブルはハードウェアを深く知る最高のチャンス

超特大ボリュームの番外編「インストーラートラブルシューティング」、いかがでしたか？

AWSやVPSなどの「すでに用意された仮想マシン」を使うのが当たり前になった現代において、物理的なハードウェアに直接OSをインストールし、BIOSやブートローダー（GRUB）と格闘する経験は、インフラエンジニアとしてのかけがえのない財産になります。

「なぜUSBから起動しないのか？」「なぜディスクが見えないのか？」「chrootの裏側で何が起きているのか？」
これらのトラブルを自分の手で解決した時、あなたは「OSとハードウェアの境界線」を完全に理解したことになります。この低レイヤーの知識は、将来DockerやKubernetes、クラウドインフラで原因不明の障害に遭遇した時、必ずあなたを救う強力な武器となります。

エラー画面が出ても絶望しないでください。Linuxは常にログという形で「直すためのヒント」を吐き出し続けています。落ち着いてログを読み、仮説を立て、コマンドを打ち込む。その一つひとつの試行錯誤が、あなたを真のプロフェッショナルへと育て上げていきます。

何度でも失敗し、何度でもインストールし直してください。
あなたの努力の結晶であるUbuntu 26.04サーバーが、力強く起動の産声を上げることを応援しています！
LINUX工房の「リナックス先生」でした。