NVIDIA搭載Ubuntuでの2〜3分のログイン遅延を修正(Xorgとnvidia-drmの問題)

Table of Contents
パスワードを入力してEnterキーを押すと、何も起こりませんでした。いや、正確には何も起こらなかったわけではありません。画面は真っ黒なままで、カーソルが私をあざ笑っていました。2分が過ぎ、3分が過ぎました。ようやくデスクトップが表示され、何事もなかったかのようでした。
これが何週間も続きました。後で直そうと自分に言い聞かせ続けました。そして、もう我慢できなくなったとき、その「後で」がやってきました。
もしあなたがUbuntuでXorgを動かしているNVIDIAカードを持っていて、ログインが2003年のダイヤルアップ接続を待っているような感覚なら、この記事はあなたのために書かれたものです。
私が直面していた問題
- 起動時間は全く問題ありませんでした。ログイン画面まで約20秒。
- 私はNVIDIA GPUでXorg (GNOME) を使用しています。
- 問題点: パスワード入力後、毎回2〜3分間完全にフリーズする。
間違った問題を追いかける
ほとんどの人と同じように、私もいつもの場所から始めました。Systemdです。
起動時間を確認するために systemd-analyze を実行しました。すべて正常に見えました。次に、ユーザーサービスがハングしていないか確認するために systemd-analyze --user blame を試しました。特に目立ったものはありませんでした。不要なものをいくつか無効にしてみましたが、効果はありませんでした。
何も変わりませんでした。
起動アプリケーションを確認しました。これも違いました。GNOME拡張機能も確認しました。やはり違いました。私はこれが遅いサービスか、問題のあるアプリケーションのせいだと確信していました。
しかし、完全に間違っていました。
何が私にヒントを与えたのか
最終的に、dmesg でカーネルログを確認することを思いつきました。そこに埋もれていたのは、場違いな2つの項目でした。
[nvidia-drm] Failed to grab modeset ownership
と
nvidia-gpu ... i2c timeout error
これを見て、私は推測をやめ、原因を突き止めにかかりました。
本当に何が起こっていたのか
Linux上のNVIDIAについてですが、ほとんどの場合、問題なく動作します。しかし、時々、人生の選択を疑うような奇妙なことをします。
問題はDRMモードセット所有権の競合でした。技術的に聞こえますが、考え方はシンプルです。
争い
Xorgが起動すると、nvidia-drm がディスプレイの制御を試みます。しかし、すでに何かがDRMの所有権をロックしていました。
膠着状態
ドライバは gracefully に諦めることなく、何度も何度も叩き続けました。リトライ、リトライ。2〜3分間、何も起こりません。
降伏
最終的にタイムアウトし、手放され、GNOMEがようやくデスクトップを描画できるようになりました。その頃には、私はすでにコーヒーを淹れていました。
なぜこんなことが起こるのでしょうか?私にも分かりません。カーネルのバージョンによっては、モードセットのハンドオフの処理が異なるようです。システムアップデートで何かが変わったのかもしれません。私が知っているのは、nvidia-drm とXorgが同じリソースを巡って争い、どちらも譲ろうとしなかったということです。
解決策(ネタバレ:たった1行です)
あれこれデバッグした結果、解決策はほとんど滑稽なほどシンプルでした。
GRUB設定を開く
ターミナルを起動してGRUBを編集します。
sudo nano /etc/default/grub
カーネルパラメータを1つ追加する
GRUB_CMDLINE_LINUX_DEFAULT を見つけます。おそらく "quiet splash" のようなものが見つかるでしょう。これを次のように変更します。
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=0"
適用する
ファイルを保存し、GRUBを更新して再起動します。
sudo update-grub
sudo reboot
これだけです。たった1つのカーネルパラメータ。nvidia-drm.modeset=0。
これが実際に何をするのか
nvidia-drm.modeset=0 を設定すると、NVIDIAドライバーのDRMモード設定が無効になります。これにより、デッドロックが始まる前に停止します。起動シーケンスは、カーネルからNVIDIAドライバー、Xorgへと直接進み、所有権の争いは一切発生しません。
再起動後、私はログインし、息を殺して待つと…デスクトップが瞬時に表示されました。最初からそうあるべきだったかのように。私は一瞬、待つ必要がなかったことに戸惑い、そこに座っていました。
しかし、欠点はないのか?
良い質問です。DRMモード設定を無効にすると、一部の機能が失われます。
Xorgの代わりにWaylandを使用している場合、この修正は問題を発生させます。WaylandはDRMモード設定が正しく機能するために必要です。PRIME SyncやGSPファームウェア機能に依存している場合も同様です。
しかし、私のように、デスクトップで1つのモニターを使ってプレーンなXorgを実行している場合、何も気づかないでしょう。すべて同じようにレンダリングされます。ゲームも動作します。ビデオ再生も問題ありません。唯一の違いは、ログイン時にコンピューターが実際に応答するようになることです。
これをすべきでない場合
- Waylandを使用している場合(これにより壊れます)
- PRIME SyncまたはGSPファームウェア機能が必要な場合
- Optimusラップトップ設定を使用している場合
これらの場合は、デフォルトのモード設定を使用してください。
学んだこと
私は存在しないパフォーマンスの問題を追いかけるのに何時間も費やしました。Systemdログ、GNOMEの調整、カーネルパラメータなど、あらゆるものを試しました。その間ずっと、答えは私が無視し続けていた dmesg の出力の中に隠されていました。
次にシステムで何か奇妙なことが起こったとき、dmesg は私が最初に確認する場所であり、最後ではありません。カーネルは通常、何が問題なのかを正確に知っています。ただ尋ねるだけでいいのです。
そして正直なところ、時には最も単純な修正が正しいこともあります。たった10秒で入力できる1つのブートパラメータが、毎日2〜3分の待ち時間から私を救ってくれました。数ヶ月で計算すると、真っ黒な画面を見つめる時間が何百分も減ったことになります。
今ではログインするとすぐにデスクトップが表示されます。何の派手さもなく、待つこともありません。まさにそうあるべき姿です。
こちらもどうぞ
Free In-Browser Developer Tools
Clean AI CLI logs, build cron expressions, decode JWTs, and calculate chmod permissions offline.
Related Articles

Ubuntuでの2分間のログイン遅延を修正(実際のデバッグの旅)
Ubuntuで2分間のログインフリーズを3日間追いかけ、NetworkManagerのネットワーク待機、gnome-keyringの二重起動、snapdによる18個のsnapへの2分追加という3つの問題が積み重なっていたことが判明。そのデバッグの全過程を紹介します。
Read more
Ubuntu Serverセキュリティ:実用的なLinux強化チェックリスト
SSHキーの強制、UFWファイアウォール、Fail2banによる侵入防止、自動アップグレード、auditdロギングなど、本番環境のUbuntuサーバーを強化するためのガイド。
Read more
2026年のEdgeComputing: 実世界におけるアーキテクチャパターンとユースケース
CDNの枠を超えて成熟したEdgeComputingが、リアルタイムAI推論から分散型マルチプレイヤーゲームまで、現代のアプリケーションをどのように支えているかを探ります。
Read more