gpu unlock エラー -16：ドライバーが先にカードを掴んだ

ログに出る gpu unlock エラー -16 の形

3 行がこの順で出ます。よく引用されるのは 3 行目です。

NVRM: GPU 0000:01:00.0: RmInitAdapter failed!
NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0
nvidia: probe of 0000:01:00.0 failed with error -16

-16 は EBUSY です。gpu_unlock unlock failed -16 は、モジュールはあったのに、デバイスの取り合いに負けたという意味です。カーネルはカードが壊れているとも未対応だとも言っていません。デバイスにはすでに持ち主がいる、と言っています。実際の持ち主は nvidia です。上の並びは、負けたあとにドライバー自身のプローブが失敗した記録です。 [issue #11]

この -16 は診断の手がかりになります。ほかに何が問題であっても、ファームウェアの段階までは進んでいません。-16 を返すカードは電気的に正常で、システムからはきちんと見えています。

gpu unlock の取り合いを順番に見る

コールドブートでは 3 者が GPU を掴む機会を得ます。勝つのは最初の 1 つだけです。

インストール時に失敗が見えないのも同じ理由です。パッケージは入り、モジュールはビルドされ、ファームウェアも生成されます。どの手順も成功と報告します。間違いが出るのは次の起動時、カーネルログの 1 行です。

gpu unlock の原因 3 つ、出てくる順に

• 出てくる順の原因と、それぞれ何を変えるべきか。

• モジュールが initramfs に入っていない

  見える症状

  動いているカーネル向けにだけビルドされた

  対処

  drop-in を置き、イメージを再構築し、コールドブートする

• drop-in を間違ったジェネレーターの場所に置いた

  見える症状

  起動時にエラーなし。lsinitramfs でも見つからない

  対処

  自分のジェネレーターが読む場所にファイルを置く

• 起動後に手で読み込んだ

  見える症状

  modprobe gpu_unlock は成功したように見えた

  対処

  シェルのセッションから外し、もっと早く読み込む

2 行目が、新規インストールで最もよくある形です。dracut のマシンに initramfs-tools 用のファイルを置いても、何も起きません。しかも無言で何も起きません。この形の gpu_unlock unlock failed -16 は、コールドブートでは消えません。ファイルが間違った順番ではなく、間違ったディレクトリにあるからです。Ubuntu 25.10 と 26.04 は dracut で起動します。一方、gpu_unlock の Debian パッケージは initramfs-tools のパスに書き込みます。 issue #54 に記録があります。

dracut がイメージを作るなら、initramfs-tools のパスを真似せず、dracut の initramfs インストール手順 に従ってください。

3 行目は再構築が要りません。シェルで modprobe gpu_unlock を打つのは、定義上もう遅いです。ドライバーがデバイスを持っており、モジュールには取り返せません。

gpu unlock エラーを原因別に直す

最初の 2 つは対処の形が同じです。drop-in をジェネレーターが読む場所に置き、イメージを再構築し、コールドブートします。gpu unlock の対応表 にないカードには、どちらの対処も効きません。載っていないカードは取り合いにならず、読み飛ばされるからです。

• Arch、CachyOS、EndeavourOS： /etc/mkinitcpio.conf.d/
• Debian、Ubuntu 25.04 まで： /usr/share/initramfs-tools/modules.d/
• Fedora、RHEL、Ubuntu 25.10 以降： /usr/lib/dracut/dracut.conf.d/

再構築の前に、これから起動するイメージの中身を確かめてください。

lsinitramfs /boot/initrd.img-$(uname -r) | grep gpu_unlock

何も出なければ、モジュールはイメージに入っていません。順番の話は意味がありません。何か出れば、モジュールは入っているのに負けています。そこでは 3 つ目の対処になります。

モジュールがあるのに遅いときは、issue #171 の init-top スクリプトを使います。最も早いユーザー空間で動く小さなフックで、udev が GPU のプローブを始める前に gpu_unlock を読み込みます。順番を決めるのは、スクリプトが initramfs のどこにあるかです。modprobe のオプションではありません。

softdep nvidia pre: は答えに見えますが、答えではありません。kmod が有効にするのは、ツリー内で最初の softdep nvidia 行だけです。多くのデスクトップでは、その行は nvidia-utils のものです。

Ubuntu 24.04 では、ここに至る道がさらに 2 つあります。

• パッケージの drop-in を使わず、/etc/initramfs-tools/modules を手で編集している場合です。initramfs-tools はそのファイルと modules.d の両方を読みます。順番を自分で決めるなら、gpu_unlock を nvidia より前に自分で書く必要があります。
• 複数のカーネルがあるマシンで、いま起動していないカーネル向けにイメージを作り直した場合です。セッションの uname -r と、実際に作り直したイメージが一致している必要があります。合っていなければ、誰も読まないファイルを直したことになります。

gpu unlock が今度は読み込まれたか確かめる

2 つのコマンドが、gpu_unlock unlock failed -16 について別々の問いに答えます。モジュールが動いたか、そのあとドライバーがバインドしたかです。

journalctl -k -b | grep gpu_unlock
lspci -nnk -s 0000:01:00.0

ログを読むときの注意が 1 つあります。アンロック済みでも、nvidia-smi の SM クロックが 210 MHz 付近で固まったままに見えることがあります。その間もベンチマークはフルスピードで動きます。これはテレメトリーのアーティファクトで、新しい gpu_unlock unlock failed -16 の事例ではありません。

これも issue #258 の内容です。 [issue #258]

gpu unlock がまだ -16 を返すとき