はじめに
Ubuntuをサスペンドさせたところ、復帰後も画面が真っ黒なままになった。
当初はPC自体が復帰していないと思っていた。しかしログを確認すると、OSは正常に復帰していて、画面表示だけが戻っていなかった。
最終的には、Linuxカーネルを 7.0.0-28-generic から 6.17.0-35-generic へ戻すことで、次の2つが解消した。
- サスペンド復帰後のブラックスクリーン
- 画面の明るさを変更できない問題
この記事では、原因を切り分けた過程と、GRUBで旧カーネルを既定にする方法をまとめる。
👉 なお本記事は「バグを直した」記録ではなく、切り分けて回避した記録である。カーネル側の不具合と完全に確定させたわけではない。
環境
再現条件として重要なので先に書いておく。
| 項目 | 値 |
|---|---|
| OS | Ubuntu 24.04.4 LTS |
| デスクトップ環境 | GNOME（gnome-classic） |
| ディスプレイサーバー | Wayland |
| GPU | Intel HD Graphics 620 (rev 02) |
| GPUドライバー | i915 |
| PC | NEC PC-NS600HAW |
| 起動方式 | UEFI |
| 問題が発生したカーネル | 7.0.0-28-generic |
| 正常に動いたカーネル | 6.17.0-35-generic |
確認に使ったコマンドはこれ。
uname -r
lspci | grep -Ei 'vga|3d|display'
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
echo "$XDG_CURRENT_DESKTOP / $XDG_SESSION_TYPE"
👉 Hyprland と hypridle もインストールしてあるが、今回の問題発生時には動いていなかった。これは後の切り分けで重要になる。
発生した症状
起きたことを時系列に並べるとこうなる。
- PCをサスペンドする
- 電源ボタンを押して復帰させる
- 画面が真っ黒なまま戻らない
- 反応がないと思い、電源ボタンを何度か押した
- 画面の明るさ変更も効かなくなっていた
このとき「PCが固まった」「サスペンドから復帰できていない」と思い込んでいた。
しかし後から分かったことはこうだった。
❌ OSが停止していた
✅ サスペンドからは復帰していて、ディスプレイまたはバックライトだけが正常に復帰していなかった
この思い込みが調査を遠回りさせた原因でもある。
最初に疑ったもの
調査を始めた時点で、頭に浮かんだ仮説は5つあった。
- PC自体がサスペンドから復帰していない
- 何かが繰り返しサスペンドを実行している
- コンポジタのDPMS制御に問題がある
- Intel GPUドライバーの問題
- カーネル更新による回帰
上から順に潰していく。仮説を書き出しておくと、あとで「どれが消えたか」が分かるので切り分けが進む。
journalctlで前回起動時のログを確認
まず事実を確認する。今のセッションではなく、問題が起きていたときのログが見たい。
journalctl の -b -1 は「1回前の起動時のログ」を意味する。
journalctl -b -1
そのままでは量が多すぎるので、電源管理と画面周りに絞る。
journalctl -b -1 | grep -Ei \
'suspend|resume|sleep|power key|i915|drm|backlight'
ログで分かったこと
出てきたのがこれ。
7月 29 15:41:56 systemd-logind[1213]: Power key pressed short.
7月 29 15:41:56 systemd-logind[1213]: The system will suspend now!
7月 29 15:41:58 kernel: PM: suspend entry (deep)
7月 29 15:53:43 kernel: PM: suspend exit
7月 29 15:53:57 systemd-logind[1213]: Power key pressed short.
7月 29 15:53:57 systemd-logind[1213]: The system will suspend now!
7月 29 15:53:58 kernel: PM: suspend entry (deep)
7月 29 15:54:03 kernel: PM: suspend exit
7月 29 15:54:28 systemd-logind[1213]: Power key pressed short.
7月 29 15:54:28 systemd-logind[1213]: The system will suspend now!
読み方はこう。
| ログ | 意味 |
|---|---|
Power key pressed short. |
電源ボタンが短く押された（systemd-logind が検知） |
The system will suspend now! |
これからサスペンドする |
PM: suspend entry (deep) |
カーネルがサスペンドに入った |
PM: suspend exit |
カーネルがサスペンドから抜けた（復帰完了） |
ここで決定的なのが 15:53:43 と 15:53:57 の関係だ。
15:53:43 PM: suspend exit ← 復帰は完了している
15:53:57 Power key pressed short. ← その14秒後に電源ボタンを押している
つまり、こうなっていた。
- サスペンドから正常に復帰した
- しかし画面が真っ黒なので、復帰していないと思った
- 電源ボタンを押した
- 復帰済みだったので、その押下が「サスペンド指示」として処理された
- また寝る
このループが 7月29日 15:53 から 7月30日 11:23 まで何度も記録されていた。自分で寝かせ続けていたわけである。
👉 ここが今回いちばん大きな学び。
ブラックスクリーン ＝ OSが起動していない、とは限らない
なお、記録されている The system will suspend now! はすべて直前に Power key pressed short. がある。つまりサスペンドの起点は例外なく人間（自分）の電源ボタン押下で、「何かが勝手にサスペンドさせていた」という仮説はこの時点で消えた。
ログで分からなかったこと
一方で、期待していたものが出てこなかった。
復帰時刻の前後を i915 と drm で絞って見ても、エラーも警告も一切なかった。出ていたのは次のような正常ログだけである。
kernel: mei_hdcp 0000:00:16.0-...: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
❌ 「画面が壊れているのだからGPUドライバーがエラーを吐いているはず」
これは外れだった。GPUドライバーは何も文句を言わずに、しかし画面は真っ黒。
👉 ログにエラーが出ていなくても壊れていることがある。
ここでログだけを見る調査は行き詰まる。エラーメッセージから原因を辿るルートが使えないので、別のやり方が必要になった。
そこで方針を切り替える。条件を1つだけ変えて、動作を比較する。
HypridleとHyprlandを疑って除外する
このPCには Hyprland 環境用のツールが入っている。Hypridle は「一定時間操作がないと画面ロックやサスペンドを実行する」デーモンで、サスペンド関連の設定を持っている。
まず動いているか確認する。
pgrep -a hypridle
pgrep -a Hyprland
設定も見る。
grep -RniE 'suspend|sleep|dpms|before_sleep|after_sleep' ~/.config/hypr
設定ファイルにはこう書かれていた。
before_sleep_cmd = loginctl lock-session
after_sleep_cmd = hyprctl dispatch dpms on
| 設定 | 意味 |
|---|---|
before_sleep_cmd |
サスペンド直前に実行する処理（ここではセッションをロック） |
after_sleep_cmd |
サスペンド復帰後に実行する処理（ここでは hyprctl でディスプレイをオン） |
一見「復帰後にディスプレイをオンにする対策はすでに入っている」ように見える。ここで諦めずにログを見たのが正解だった。
7月 29 15:33:11 systemd[2103]: Started hypridle.service - Hyprland's idle daemon.
7月 29 15:33:12 systemd[2103]: hypridle.service: Main process exited, code=exited, status=1/FAILURE
7月 29 15:33:12 systemd[2103]: hypridle.service: Failed with result 'exit-code'.
7月 29 15:33:12 systemd[2103]: hypridle.service: Scheduled restart job, restart counter is at 1.
Hypridle はログイン直後に落ちていた。 status=1/FAILURE で終了し、systemd がリトライして restart counter is at 5 まで進んだところで停止していた。
理由は環境の食い違いである。今回のセッションは GNOME の Wayland セッションで、Hyprland コンポジタは動いていない。Hypridle は GNOME 側のコンポジタには接続できているものの、必要な機能が揃わずに終了していた。
これで容疑者リストが一気に片付く。
Hypridle は死んでいた → 繰り返しサスペンドの原因ではない
Hyprland は動いていない → hyprctl / DPMS 制御は無関係
サスペンドは全部 power key → 人間（自分）が押していた
i915 のエラーログはゼロ → GPU層のエラーとしても現れない
─────────────────────────────
→ DE層・ユーザー空間の容疑は消えた。残るのはカーネル
👉 after_sleep_cmd = hyprctl dispatch dpms on は一度も実行されていない。設定ファイルに書いてあっても、デーモンが死んでいれば動かない。
❌ 設定ファイルに書いてあるから効いている
設定の存在と、実際に動いていることは別物。ログで動作を確認するまで「対策済み」と思ってはいけない。
バックライトの状態を確認
今回は復帰後のブラックスクリーンだけでなく、明るさ調整も効かなくなっていた。症状が2つあるのは切り分けのヒントになる。
Linuxではバックライトがファイルとして見える。
ls /sys/class/backlight
intel_backlight
これは sysfs というカーネルの仕組みで、カーネルやハードウェアの状態をファイルとして読み書きできる。intel_backlight は Intel GPU 環境のバックライト制御インターフェースである。
直接書き込んで明るさを変えることもできる。
B=/sys/class/backlight/intel_backlight
max=$(cat "$B/max_brightness")
echo $((max / 2)) | sudo tee "$B/brightness"
👉 intel_backlight 自体は存在していた。つまりバックライトデバイスが完全に認識されていないわけではない。デバイスは見えているのに制御が効かない、という状態だった。
「デバイスは存在する」「エラーログは出ない」「でも動かない」。ここまで来ると、ユーザー空間の設定を眺めていても答えは出ない。
カーネル更新履歴を確認
残った仮説は「カーネル更新による回帰」だ。回帰（Regression） とは、新しいバージョンに更新した結果、以前動いていた機能が動かなくなる不具合のこと。
まず「いつカーネルが更新されたか」を調べる。apt の履歴に残っている。
zgrep -hEi 'linux-image|linux-generic' /var/log/apt/history.log*
出てきたのがこれ（抜粋）。
Install: linux-image-7.0.0-28-generic:amd64 (7.0.0-28.28~24.04.1, automatic)
linux-hwe-7.0-tools-7.0.0-28:amd64 (7.0.0-28.28~24.04.1, automatic)
Install: linux-image-6.17.0-35-generic:amd64 (6.17.0-35.35~24.04.1, automatic)
linux-hwe-6.17-tools-6.17.0-35:amd64 (6.17.0-35.35~24.04.1, automatic)
ここで2つ分かる。
- 症状が出る前に
7.0.0-28-genericがインストールされていた - パッケージ名が
linux-hwe-7.0/linux-hwe-6.17になっている
後者が重要だ。HWEカーネル（Hardware Enablement Kernel）は、Ubuntu LTS に新しいハードウェア対応を追加するための新しめのカーネル系列である。Ubuntu 24.04 LTS を使っていても、HWE を有効にしていると本体より新しいカーネルが降ってくる。
👉 今回は HWE の系列が 6.17 から 7.0 に上がったタイミングで症状が出ていた。
次に、旧カーネルがまだ残っているか確認する。Linuxは複数のカーネルをインストールしたまま保持できる。
ls -1 /boot/vmlinuz-*
/boot/vmlinuz-6.17.0-35-generic
/boot/vmlinuz-7.0.0-28-generic
残っていた。これで条件を1つだけ変えた比較ができる。同じPC・同じ設定・同じデスクトップ環境で、カーネルだけを入れ替えればいい。
GRUBから旧カーネルを起動
起動時にどのカーネルを使うかは GRUB が決めている。まず全体の流れを押さえる。
電源投入
↓
UEFI ... 電源投入直後に動き、OSの起動を開始する仕組み（BIOSの後継）
↓
GRUB ... ブートローダー。OSとカーネルを選んで起動する
↓
Linuxカーネル
↓
Ubuntu
👉 GRUB は「どのOSを起動するか」だけでなく「どのカーネルを起動するか」も選んでいる。 ここが今回の鍵になる。
旧カーネルは GRUB メニューのサブメニューにいる。
Advanced options for Ubuntu
└ Ubuntu, with Linux 6.17.0-35-generic
起動時に Ubuntu ではなく Advanced options for Ubuntu を選び、その中から 6.17.0-35-generic を選択する。
GRUBメニューとGRUBシェルは別物
ここで一度ハマったので書いておく。
grub> と表示される画面は GRUBメニューではなくGRUBのコマンドライン（GRUBシェル） である。
❌ grub> の画面で Advanced options for Ubuntu と文字入力する
これは意味がない。メニュー項目名はコマンドではないので、入力しても何も起きない。この画面に落ちてしまったら、通常のGRUBメニューへ戻る必要がある。
👉 選びたいのはメニューの項目であって、打ち込むコマンドではない。
6.17で動作確認
起動したら、まず本当に切り替わったか確認する。
uname -r
6.17.0-35-generic
uname -r は現在使用中のカーネルを表示するコマンド。ここが 6.17.0-35-generic なら成功。
次にサスペンドを試す。
systemctl suspend
復帰後のログはこうなった。
7月 30 11:56:32 kernel: PM: suspend entry (deep)
7月 30 11:56:40 kernel: PM: suspend exit
そしてこの後に Power key pressed short. が記録されていない。画面がちゃんと戻ったので、電源ボタンを連打する必要がなかったということである。7.0のときとの差がログにそのまま出ている。
明るさ調整も動くようになっていた。結果を並べるとこうなる。
| 項目 | 7.0.0-28 | 6.17.0-35 |
|---|---|---|
| 明るさ調整 | 動作しない | 正常 |
| サスペンド | 実行できる | 実行できる |
| 復帰後のOS | 復帰している | 復帰している |
| 復帰後の画面 | 真っ黒 | 正常 |
変えたのはカーネルだけ。デスクトップ環境も設定も同じである。
この比較から、7.0.0-28 と Intel HD Graphics 620 の組み合わせで、ディスプレイ復帰またはバックライト制御に回帰が発生している可能性が高いと判断した。
👉 ただし断定はしない。GNOME / Wayland との組み合わせで起きている可能性も残っているので、カーネル単体のバグとまでは言えない。ここで確定したのは「6.17で起動すれば症状が出ない」という事実だけである。
6.17をGRUBの既定値に設定
毎回起動時に手でメニューを選ぶのは面倒なので、既定で 6.17 が起動するようにする。
編集前にバックアップを取る。
sudo cp /etc/default/grub /etc/default/grub.bak
/etc/default/grub がGRUBの基本設定ファイル。今回関係するのは3つ。
GRUB_DEFAULT=saved
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
| 設定 | 意味 |
|---|---|
GRUB_DEFAULT=saved |
保存された起動項目を既定値として使う |
GRUB_TIMEOUT_STYLE=menu |
起動時にGRUBメニューを表示する |
GRUB_TIMEOUT=5 |
メニューを5秒間表示する |
GRUB_DEFAULT に番号を直接書く方法もあるが、カーネルが増減すると番号がずれる。saved にしておけば項目名で指定できるので壊れにくい。
設定を書き換えたら、実際の起動メニューを再生成する。
sudo update-grub
そして既定の起動項目を指定する。
sudo grub-set-default \
'Advanced options for Ubuntu>Ubuntu, with Linux 6.17.0-35-generic'
サブメニューの中の項目なので、> で階層を繋いで指定する。
確認する。
sudo grub-editenv list
saved_entry=Advanced options for Ubuntu>Ubuntu, with Linux 6.17.0-35-generic
saved_entry が期待どおりなら完了。次回以降は自動で 6.17 が起動する。
👉 GRUB_TIMEOUT_STYLE=menu にしてメニューを出しておくと、必要になったときに 7.0 を選び直せる。回避策を入れるときは、戻せる状態を残しておくほうがいい。
古いカーネルを使っても大丈夫なのか
「古いカーネルで固定」と聞くと不安になるので、そこも整理しておく。
まず 6.17.0-35-generic は Ubuntu公式リポジトリからインストールされた署名済みカーネルである。どこかから拾ってきた非公式ビルドを使っているわけではない。
👉 GRUBのメニューに出ている選択肢は、すべて apt が正規に入れたものである。
一方で注意点もある。
- 古いカーネルを永続的に固定すると、いずれセキュリティ更新を受けられなくなる可能性がある
- HWEカーネルは系列ごとにサポート期間が決まっている
- apt の自動削除で旧カーネルが消えることもある
そのため今回は 一時的な回避策として扱う。7.0 の修正版や次の系列が配布された時点で、もう一度サスペンドと明るさ調整を確認する予定である。
❌ 動いたからこれで終わり
✅ 動く状態を確保したうえで、更新のたびに再確認する
参考になる公式ドキュメントはこのあたり。
- カーネルのサポート期間とリリーススケジュール: https://ubuntu.com/kernel/lifecycle
- HWEカーネル（LTS Enablement Stack）の説明: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
- セキュリティ更新の一覧: https://ubuntu.com/security/notices
今回学んだこと
- 画面が真っ黒でも、OS自体は復帰している場合がある
-
journalctl -b -1で前回起動時のログを確認できる - 電源ボタンの操作も systemd のログに残る。自分の操作を客観的に見返せる
- 設定ファイルに書いてあっても、デーモンが死んでいれば動かない
-
ログにエラーが出ていなくても壊れていることがある。今回
i915の異常ログはゼロだった - だからこそ、条件を1つだけ変えて比較する切り分けが効く
- Linuxは複数のカーネルをインストールしたまま切り替えられる
- GRUBはOSだけでなく、起動するカーネルも選択している
- 新しいカーネルが常に自分の環境で安定するとは限らない
特に効いたのは「ログにエラーが出ていなくても壊れていることがある」と「条件を1つだけ変えて比較する」の組み合わせだった。ログから原因を特定できなくても、「カーネルだけを入れ替える」という1変数の比較ができれば、原因の範囲を一気に狭められる。
まとめ
Ubuntuでサスペンド復帰後に画面が真っ黒になる問題を調査した。
ログを見ると PM: suspend exit が記録されていて、OS自体は正常に復帰していた。問題は画面表示側にあった。しかし i915 にエラーは出ておらず、ログから原因を辿ることはできなかった。
そこでカーネルだけを 7.0.0-28 から 6.17.0-35 に変えて比較したところ、サスペンド復帰と明るさ調整がともに正常になった。GRUBで旧カーネルを既定に設定し、一時的な回避策とした。
新しいカーネルで画面系の回帰が発生
→ ログと旧カーネルで切り分け
→ GRUBで正常な旧カーネルを既定に設定
現時点では 6.17 を使い、今後のカーネル更新後に改めて動作確認する。