ArchWiki - 利用者の投稿記録 [ja]

SDDM

2026-05-05T22:17:25Z

AshMyzk: 同期

[[Category:KDE]]
[[Category:ディスプレイマネージャ]]
[[de:Login-Manager#SDDM]]
[[en:SDDM]]
[[fr:SDDM]]
[[hu:SDDM]]
[[ru:SDDM]]
[[zh-hans:SDDM]]
[https://github.com/sddm/sddm/ Simple Desktop Display Manager] (SDDM) は[[ディスプレイマネージャ]]です。[[LXQt]] デスクトップ環境の推奨ディスプレイマネージャです。

[[Wikipedia:ja:Simple Desktop Display Manager]] より:

:Simple Desktop Display Manager (SDDM) は、X Window SystemとWayland向けのディスプレイマネージャである。SDDMはC++11で書かれており、QMLによるテーマをサポートしている。

{{Note|SDDM バージョン 0.20 の時点で、[[Wayland]] セッションは一覧に表示され、SDDM から起動することは可能ですが、SDDM greeter 自体はデフォルトでは依然として X11 モードで動作します。しかし、実験的な Wayland greeter を[[#Wayland|有効化することが可能です]]。}}

== インストール ==

{{Pkg|sddm}} パッケージを[[インストール]]してください。任意で [[KDE#KCM|KConfig Module]] のための {{Pkg|sddm-kcm}} や Qt5 テーマのサポートを有効化する {{Pkg|qt5-declarative}} もインストールしてください。

[[ディスプレイマネージャ#ディスプレイマネージャをロードする]]に従って、ブート時に SDDM を起動させてください。

== 設定 ==

SDDM のデフォルト設定ファイルは {{ic|/usr/lib/sddm/sddm.conf.d/default.conf}} に存在します。設定を変更するときは {{ic|/etc/sddm.conf.d/}} に設定ファイルを作成してください。利用可能なオプションは {{man|5|sddm.conf}} を見て下さい。

({{grp|plasma}} グループに含まれている) {{pkg|sddm-kcm}} パッケージをインストールすることで Plasma のシステム設定から GUI で SDDM を設定できます。[[Qt]] ベースの設定エディタ {{AUR|sddm-conf-git}} も存在します。

Arch Linux は [[systemd]] を使用していて、さらに SDDM はデフォルトで {{ic|systemd-logind}} をセッション管理に使用するので、特に設定せずに機能するはずです。

=== 自動ログイン ===

SDDM は設定ファイルによって自動ログインをサポートしています、例:

{{hc|/etc/sddm.conf.d/autologin.conf|2=
[Autologin]
User=john
Session=plasma
}}

上の設定だと、システムが起動した時に {{ic|john}} ユーザーで KDE Plasma セッションが起動します。利用できるセッションのタイプについては、X 用は {{ic|/usr/share/xsessions/}} で、Wayland 用は {{ic|/usr/share/wayland-sessions/}} でわかります。

セッションをロックすると同時に KDE Plasma に自動ログインする方法は (例えば、自動起動させるアプリに起動する時間を与えるためなど)、[[KDE#ロックスクリーン]] を参照してください。

=== パスワードレスログイン ===

パスワード無しで一部のアカウントにログインできるように SDDM を設定することができます。ログインするアカウントを選ぶ必要があるという点で自動ログインとは異なり、また、([[SSH]] 経由でログインしてきたリモートユーザなどを除く) インタラクティブユーザのみにログインを許可するという点で、アカウントのパスワードを空白に設定するのとも異なります。

SDDM は [[PAM]] 経由で動作するので、PAM で SDDM に関連する設定を行う必要があります:

{{hc|/etc/pam.d/sddm|2=
#%PAM-1.0
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''
auth include system-login
...
}}

パスワード無しで KDE Plasma のロック画面を解除できるようにするために、{{ic|/etc/pam.d/kde}} の先頭にも先と同じ行を追加してください:

{{hc|/etc/pam.d/kde|2=
#%PAM-1.0
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''
auth include system-login
...
}}

次に、パスワードを入力せずにインタラクティブにログインできるようにするために、あなたのユーザーを {{ic|nopasswdlogin}} グループに追加する必要があります:

# groupadd -r nopasswdlogin
# gpasswd -a ''username'' nopasswdlogin

=== ログイン時に KDE Wallet のロックを解除 ===

[[KDE Wallet#ログイン時に KDE ウォレットを自動的にアンロック]] を見てください。

=== テーマ設定 ===

{{ic|[Theme]}} セクションでテーマの設定を変更できます。Plasma の KDE システム設定を使っている場合、テーマのプレビューを表示できます。

デフォルトの Plasma テーマを使うには {{ic|breeze}} に設定してください。

{{AUR|archlinux-themes-sddm}} など、[[AUR]] から入手できるテーマもあります。

==== 現在のテーマ ====

現在のテーマは {{ic|Current}} で設定します。例: {{ic|1=Current=archlinux-simplyblack}}。

==== テーマの編集 ====

SDDM のデフォルトのテーマディレクトリは {{ic|/usr/share/sddm/themes/}} です。作成したカスタムテーマはこのディレクトリのサブディレクトリに追加することができます。サブディレクトリの名前はテーマの名前と同じである必要があります。インストールされているファイルを参考に自分自身のテーマを作成してみてください。

==== テーマをカスタマイズ ====

設定ファイル {{ic|theme.conf}} の設定をオーバーライドするには、カスタムの {{ic|theme.conf.user}} ファイルを同じディレクトリに作成してください。例えば、テーマの背景を変更するには:

{{hc|head=/usr/share/sddm/themes/''name''/theme.conf.user|output=
[General]
background=''/path/to/background.png''
}}

==== テーマのテスト (プレビュー) ====

必要であれば SDDM のテーマをプレビューすることができます。これは、テーマを編集した際などにテーマがどのような見た目になるか分からない場合や、ログアウトせずにテーマを確認したい場合などに便利です。以下のようにコマンドを実行してください:

$ sddm-greeter-qt6 --test-mode --theme /usr/share/sddm/themes/breeze

接続されているモニタすべてに新しいウィンドウが開き、テーマのプレビューが表示されます。

{{Note|これはプレビューだけです。このモードでは、シャットダウンやサスペンド、ログインなどの一部のアクションは効果がありません。}}

==== マウスカーソル ====

マウスカーソルのテーマを設定したい場合は、{{ic|CursorTheme}} を使用したいカーソルテーマに設定してください。

[[Plasma]] で使用できるマウスカーソルのテーマの名前は、{{ic|breeze_cursors}}、{{ic|Breeze_Light}}、そして {{ic|breeze-dark}} です。

KDE 環境で SDDM が Adwaita テーマになってしまう場合 (マウスカーソルが GNOME)、{{ic|/usr/share/icons/default/index.theme}} 内の {{ic|Inherits}} 変数に所望の値を手動で設定する必要があります。

{{Tip|Plasma でアクティブなマウスカーソルテーマの名前を確認するには、{{ic|grep -i cursortheme ~/.config/kcminputrc}} を実行してください。}}

==== ユーザアイコン (アバター) ====

{{Out of date|設定をせずとも SDDM は {{ic|/var/lib/AccountsService/icons/}} 内のアイコンを検出します。そして、Plasma はもはや {{ic|$HOME/}} 内にファイル (以下で述べているアイコンファイルや、そのファイルへのシンボリックリンク) を作成しません。}}

SDDM は、各ユーザの {{ic|~/.face.icon}} か、あるいは SDDM 設定ファイル内の {{ic|FacesDir}} で指定された全ユーザに共通の場所から PNG イメージのユーザアイコン (別名: "アバター") を読み込みます。設定は {{ic|/etc/sddm.conf}} に直接、あるいは {{ic|/etc/sddm.conf.d/avatar.conf}} のように {{ic|/etc/sddm.conf.d/}} 下のファイルとして保存することができます (後者が推奨されます)。

{{ic|FacesDir}} のオプションを使用するには、設定ファイルの {{ic|FacesDir}} キーで指定された場所に各ユーザに対して {{ic|''ユーザ名''.face.icon}} という名前で PNG イメージファイルを配置してください。デフォルトの {{ic|FacesDir}} は {{ic|/usr/share/sddm/faces/}} です。ニーズに応じてデフォルトの {{ic|FacesDir}} を変更することができます。例えば以下のように:

{{hc|/etc/sddm.conf.d/avatar.conf|2=
[Theme]
FacesDir=/var/lib/AccountsService/icons/
}}

もう一つの方法は、ホームディレクトリのルートに {{ic|.face.icon}} という名前の PNG ファイルを置くことです。この場合、SDDM の設定ファイルを変更する必要はありません。ただし、{{ic|sddm}} ユーザがユーザアイコンの PNG イメージファイルを読むことができるようにしておく必要があります。

{{Note|多くの KDE バージョンで、ユーザのアイコンイメージファイルは {{ic|~/.face}} であり、{{ic|~/.face.icon}} はそのファイルへのシンボリックリンクとなっています。ユーザのアイコンイメージがシンボリックリンクである場合、シンボリックリンク先のファイルに適切なファイルパーミッションを設定する必要があります。}}

[[アクセス制御リスト#ACL の設定|適切なパーミッションを設定する]]には、以下を実行してください:

$ setfacl -m u:sddm:x ~/
$ setfacl -m u:sddm:r ~/.face.icon

以下を実行することで、[[アクセス制御リスト#ACL の表示|パーミッションを確認する]]ことができます:

$ getfacl ~/
$ getfacl ~/.face.icon

[https://github.com/sddm/sddm#no-user-icon SDDM README: No User Icon] を参照してください。

=== Numlock ===

Numlock を強制的に有効にしたい場合、{{ic|[General]}} セクションに {{ic|1=Numlock=on}} と設定してください。

SDDM が Wayland で動作している場合、numlock の設定は現在反映されません。Numlock を有効化するには KWin の設定を変更する必要があるかもしれません。[https://github.com/sddm/sddm/issues/1830#issuecomment-1859339401 この issue] を参照してください。

=== ディスプレイの回転 ===

[[Xrandr#設定]] を見てください。

=== DPI の設定 ===

ディスプレイマネージャのレベルでディスプレイの PPI 設定を適切に設定できると便利です。[https://github.com/sddm/sddm/blob/master/README.md#custom-dpi] {{ic|ServerArguments}} の末尾にパラメータ {{ic|-dpi ''your_dpi''}} を追加する必要があります。例:

{{hc|head=/etc/sddm.conf.d/dpi.conf|output=
[X11]
ServerArguments=-nolisten tcp -dpi 94
}}

=== HiDPI の有効化 ===

{{Note|SDDM バージョン 0.20.0 から、HiDPI サポートがデフォルトで有効化されており、以下のステップは必要ではなくなりました。}}

以下のファイルを作成してください:

{{hc|/etc/sddm.conf.d/hidpi.conf|2=
[Wayland]
EnableHiDPI=true

[X11]
EnableHiDPI=true
}}

Wayland を使用する場合、HiDPI スケーリングは、使用する greeter に依存します。[https://github.com/sddm/sddm/issues/1704] 例えば、Breeze などの Qt ベースの greeter を使用する場合、以下の設定を追加してください:

{{bc|1=
[General]
GreeterEnvironment=QT_SCREEN_SCALE_FACTORS=2,QT_FONT_DPI=192
}}

=== 仮想キーボードを有効化する ===

{{pkg|qt6-virtualkeyboard}} (あるいは他の[[アプリケーション一覧/ユーティリティ#スクリーンキーボード|仮想キーボード]]) をインストールしてください。

以下のファイルを作成してください:

{{hc|/etc/sddm.conf.d/virtualkbd.conf|2=
[General]
InputMethod=''name_of_virtual_keyboard''
}}

これで、SDDM は仮想キーボードを開くボタンをログインスクリーンの左下の角に表示するようになります。

=== 指紋リーダーを使う ===

{{Tip|Plasma 6 以降、KDE のロック画面は既に指紋によるロック解除をサポートしており、{{ic|kscreenlocker}} には必須の {{ic|/etc/pam.d/kde-fingerprint}} が含まれています。

しかし、これにはログインの設定は含まれておらず、既存のセッションのロック解除のみです。

KWallet はログイン時にパスワードベースの認証を必要とするので (以下参照)、SDDM での指紋認証のセットアップはしないほうが良いかもしれません。
}}

{{Note|これらの変更を加える前に、あなたの指紋が登録されていることを確認してください。指紋リーダーへの対応はまだ不完全であり、この方法を使うとパスワードのみでのログインができなくなってしまうようです。}}

SDDM では [[fprint]] を利用した指紋認証が可能です。{{Pkg|fprint}} をインストールして指紋署名を登録したのち、{{ic|/etc/pam.d/sddm}} の先頭に以下の行を加えてください:

{{hc|/etc/pam.d/sddm|
auth sufficient pam_fprintd.so}}

パスワードか指紋認証のいずれか片方を使うには、代わりに以下の行を {{ic|/etc/pam.d/sddm}} の先頭に加えてください:

{{hc|1=/etc/pam.d/sddm|2=
auth [success=1 new_authtok_reqd=1 default=ignore] pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_fprintd.so}}

KWallet は指紋リーダーを使ってロックを解除できないことに注意してください ([[KDE Wallet#ログイン時に KDE ウォレットを自動的にアンロック]] をご覧ください)。しかし、1行目の記述によりパスワードログインが自動的に KWallet を解除することが保証されます。

パスワード欄を空にして {{ic|Enter}} キーを押すと、指紋認証が開始されます。

=== Rootless ===

従来、[[X11]] ディスプレイサーバーはデフォルトで root 権限で実行されてきました。この rootful モードでは、X11 はシステムリソースに無制限にアクセスできます (ハードウェアへの直接的なアクセスと管理が一般的であった環境では rootful モードが動作に不可欠だったのです)。しかし、最近のコンピューティング環境ではセキュリティが重要視されるようになり、rootless モードへ移行する作業が行われてきました。また、これは [[Wayland]] がデフォルトで rootless モードで動作する理由でもあります。

非特権 X11 (及び Wayland) セッションは {{Pkg|sddm}} 0.20.0 からサポートされています。[https://github.com/sddm/sddm/blob/v0.20.0/ChangeLog]

Rootless モードを有効化するには、{{ic|/etc/sddm.conf.d/}} に新しいファイルを適当な名前で作成し、以下を追加してください (必要に応じて {{ic|x11-user}} は {{ic|wayland}} に置き換えてください):

{{hc|/etc/sddm.conf.d/rootless-x11.conf|2=
[General]
DisplayServer=x11-user}}

Rootless モードで動作しているかどうかを確認するには、コンポジタのプロセス ({{ic|kwin_wayland}}) など) がどのユーザーによって所有されているかを調べてください。

=== Wayland ===

{{Note|
* SDDM では、Wayland のサポートは実験的とされています。
* デフォルトでは、{{ic|1=DisplayServer=wayland}} は、たとえインストールされていなくとも、[[weston]] コンポジタの使用を試みます。他の Wayland コンポジタを使用するには、[[#KDE Plasma / KWin]] で説明されているように {{ic|CompositorCommand}} オプションにプログラムと関連引数を指定してください。詳細は {{man|5|sddm.conf}} を参照してください。
}}

==== KDE Plasma / KWin ====

以下の記述を設定ファイルに追加すれば、KWin が Wayland コンポジタとして使用されるようになり、[https://wayland.app/protocols/wlr-layer-shell-unstable-v1 wlr_layer_shell] Wayland プロトコル拡張も有効化されます。Qt6 を使用する SDDM テーマを使うには {{Pkg|layer-shell-qt}} が、Qt5 を使用するものには {{AUR|layer-shell-qt5}} が必要です。

{{hc|/etc/sddm.conf.d/10-wayland.conf|2=
[General]
DisplayServer=wayland
GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell

[Wayland]
CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1}}

===== 仮想キーボード =====

仮想キーボードのサポートを有効化するには (例えば、{{pkg|qt6-virtualkeyboard}} や {{pkg|plasma-keyboard}} を使う場合)、以下のように {{ic|--inputmethod}} フラグに適切なキーボードを指定して、{{ic|kwin_wayland}} コマンドに追加してください。{{ic|InputMethod}} オプションは {{ic|General}} セクションで指定しないでください。仮想キーボードが表示されなくなってしまいます。

{{hc|/etc/sddm.conf.d/10-wayland.conf|2=
[Wayland]
CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts --locale1 --inputmethod plasma-keyboard}}

===== Plasma のディスプレイ設定に合わせる =====

Plasma Wayland セッションのディスプレイの設定 (例:モニターレイアウト、解像度など) に対する如何なる変更も SDDM に対しては適用されません。設定を適用させるには、Plasma の ''KDE システム設定'' を開き、''起動と終了 > ログイン画面 (SDDM)'' へ行き、"''Plasma 設定を適用...''" をクリックしてください。この操作を行うためには許可が必要です。

同じことは、以下のようにして手動で行うこともできます:

SDDM でディスプレイを適切に管理するには (スケーリング、モニタの解像度、リフレッシュレートなど)、ホームディレクトリから適切な設定ファイルを SDDM の設定ディレクトリにコピー (かつ必要であれば変更) することができます:

# cp ~/.config/kwinoutputconfig.json /var/lib/sddm/.config/
# chown sddm:sddm /var/lib/sddm/.config/kwinoutputconfig.json

SDDM で適切な入力処理 (タップでクリックやタッチスクリーンのマッピングなど) を可能にするには、適切な設定ファイルをホームディレクトリから SDDM の設定ディレクトリにコピーしてください:

# cp ~/.config/kcminputrc /var/lib/sddm/.config/
# chown sddm:sddm /var/lib/sddm/.config/kcminputrc

== トラブルシューティング ==

=== greeter が表示されず、カーソルのみの黒画面 ===

利用可能なディスクの空き領域が存在しない場合、greeter はクラッシュします。{{ic|df -h}} でディスクの空き領域を確認してください。

ディスクの空き領域の問題でないとしたら、[https://github.com/sddm/sddm/issues/1179 バグ]のせいかもしれません。[[Getty#インストール|他の TTY に切り替えて]]、{{ic|loginctl unlock-session ''session_id''}} を実行するか、SDDM を[[再起動]]してみてください。

=== ログイン後にフリーズする ===

{{ic|~/.Xauthority}} を削除し、再起動せずに再ログインしてみてください。ログインせずに再起動すると、このファイルが再び作成されてしまい、問題が解決されません。

=== SDDM が tty7 ではなく tty1 で起動する ===

SDDM は [https://web.archive.org/web/20260111214445/https://0pointer.de/blog/projects/serial-console.html systemd の慣習]に従って tty1 に最初のグラフィカルセッションを起動します。

設定ファイルには {{ic|MinimumVT}} オプションがまだ存在しますが、SDDM 0.20 からこのオプションは無視されるようになったことに注意してください: {{man|5|sddm.conf|3=MinimumVT=|url=https://man.archlinux.org/man/sddm.conf.5#MinimumVT=}}。

=== 1つ以上のユーザが greeter に表示されない ===

{{Warning|一般に、[https://systemd.io/UIDS-GIDS/ 1000 未満あるいは 60513 より大きい UID] に設定されているユーザは[[ディスプレイマネージャ]]に公開すべきではありません。}}

デフォルトでは、SDDM は 1000 から 60513 の範囲内の UID を持つユーザのみを表示するように設定されています。表示したいユーザの UID がこの範囲の外である場合、この範囲を変更しなければなりません。

例えば、501 の UID を持つユーザの場合、{{ic|MinimumUid}} を設定し、システムユーザによって使用されるシェルを持つユーザは隠してください:

{{hc|/etc/sddm.conf.d/uid.conf|2=
[Users]
HideShells=/usr/bin/nologin,/sbin/nologin,/bin/false,/usr/bin/git-shell
MinimumUid=500
}}

高い UID を持つユーザの場合は {{ic|MaximumUid}} を適切な値に変更してください。

=== ユーザのアバターが greeter に表示されない ===

ユーザの数が {{ic|DisableAvatarsThreshold}} を超過した場合や、アバターが {{ic|EnableAvatars}} パラメータによって有効化されていない場合、ユーザのアバターは表示されません。これを回避するには、以下の記述を sddm の設定に追加してください:

{{hc|/etc/sddm.conf.d/avatars.conf|2=
[Theme]
EnableAvatars=true # enable avatars
DisableAvatarsThreshold=7 # set the threshold for the number of users. Avatars are not shown if this threshold is exceeded.
}}

=== SDDM が US キーボードのレイアウトしかロードしない ===

SDDM は {{ic|/etc/X11/xorg.conf.d/00-keyboard.conf}} で指定されたキーボードレイアウトをロードします。{{ic|localectl set-x11-keymap}} コマンドを使うことでこの設定ファイルを生成することが可能です。詳しくは [[Xorg でのキーボード設定]] を見て下さい。

SDDM でのみ効果を持ち、後続のセッションには適用されないキーボードレイアウトを設定するもう一つの方法は、SDDM のスタートアップスクリプト ({{ic|/usr/share/sddm/scripts/Xsetup}} にあり) で ''setxkbmap'' コマンドを実行することです。例は [[Xorg でのキーボード設定#setxkbmap を使う]] を参照してください。

また、SDDM は間違ってレイアウトを US キーボードとして表示することもありますが、パスワードを打ち始めると即座に正しいレイアウトに変わります [https://github.com/sddm/sddm/issues/202#issuecomment-76001543]。これは SDDM のバグではなく、[[X]] のバグのようです。[https://gitlab.freedesktop.org/xorg/xserver/-/issues/257]

=== 画面解像度が低すぎる ===

[[Wikipedia:Extended Display Identification Data|EDID]] の情報が壊れているディスプレイで [[HiDPI]] を使用した場合に発生する可能性のある問題です [https://github.com/sddm/sddm/issues/692]。[[#HiDPI の有効化|HiDPI]] を有効化している場合、HiDPI を無効にしてみてください。

無効にしても問題が解決しない場合、Xorg の設定ファイルでスクリーンのサイズを設定してみることができます:

{{hc|/etc/X11/xorg.conf.d/90-monitor.conf|2=
Section "Monitor"
Identifier "<default monitor>"
DisplaySize 345 194 # in millimeters
EndSection
}}

=== ホームディレクトリが autofs の場合にロード時間が長い ===

SDDM はデフォルトでユーザーのアバターとして {{ic|~/.face.icon}} ファイルを使います。ホームディレクトリが [[autofs]] の場合 (例えば [[dm-crypt]] を使っている場合)、autofs がディレクトリをマウントできないと報告するまで SDDM は60秒間待機します。

以下の設定ファイルを作成することでアバターを無効化することができます:

{{hc|/etc/sddm.conf.d/avatar.conf|2=
[Theme]
EnableAvatars=false
}}

=== X authority (別名 MIT-MAGIC-COOKIE) ファイル ===

[https://github.com/sddm/sddm/issues/622] で詳細が言及されているように、SDDM は認証ファイルのためにランダムな新しい UUID を使います。そのため、そのファイルを見つけるためにスクリプトを使うことができます:

# find /var/run/sddm/ -type f

ログイン中のユーザーがいない時に [[x11vnc]] を開始する必要がある場合、このスクリプトが必要である場合があります。例えば:

# x11vnc -display :0 -auth "$( find /var/run/sddm/ -type f )"

=== マルチモニタの環境で greeter が重複する ===

複数スクリーンの環境で X モニターのレイアウトが正しく設定されずに greeter が重複することがあります。この問題を解決するためには、以下のスクリプトを追加して、sddm greeter のレイアウトを左から右に並べてください:

{{hc|/usr/share/sddm/scripts/Xsetup|2=
for next in $(xrandr --listmonitors {{!}} grep -E " *[0-9]+:.*" {{!}} cut -d" " -f6); do
[ -z "$current" ] && current=$next && continue
xrandr --output $current --auto --output $next --auto --right-of $current
current=$next
done
}}

=== 予期しないディスプレイにログイン画面が表示される ===

複数のディスプレイが接続されている場合に、SDDM のログインセッションがプライマリディスプレイではないディスプレイに表示されることがあります。サブディスプレイが回転されているがプライマリディスプレイはそうなっていない場合、この問題は腹立たしいでしょう。この問題に対するシンプルな修正法は、''xrandr'' を使って、ログインセッションが ''Xsetup'' スクリプトを使用する前にディスプレイを設定することです。例えば、以下では、''xrandr'' は、2つのディスプレイが接続されており、2つ目のディスプレイ (DP-2) はプライマリディスプレイ (DP-4) の左にあると報告しています。

# xrandr | grep -w connected
DP-2 connected 2160x3840+0+0 left (normal left inverted right x axis y axis) 597mm x 336mm
DP-4 connected primary 3840x2160+2160+0 (normal left inverted right x axis y axis) 697mm x 392mm

{{Note|xrandr は、Wayland セッション内の出力には異なる名前を与えます。上記のコマンドを実行する前に、X11 セッション内にいることを確認してください。}}

以下の ''Xsetup'' は、上記のセットアップをログインウィンドウのために再作成します:

{{hc|/usr/share/sddm/scripts/Xsetup|2=
#!/bin/sh
# Xsetup - run as root before the login dialog appears

xrandr --output DP-4 --auto --primary
xrandr --output DP-2 --left-of DP-4 --rotate left --noprimary
}}

=== NVIDIA グラフィックカードでログアウト後に黒画面 ===

ユーザからログアウトした後に、完全な黒画面や、カーソル/ディスプレイデバイスのロゴだけの黒画面が発生する場合があります。これは、{{ic|sddm.service}} が NVIDIA ドライバよりも早く起動してしまうため、発生します。[[NVIDIA#早期ロード|KMS の早期ロード]]を検討してください。

=== パスワードの最初の試行に失敗すると、その後の試行で数回キーを押すと文字列が勝手に消されてしまう===

デフォルト以外の別のテーマを使用してください。

=== ハイブリッドグラフィックスで Wayland を使用すると画面の同期がずれる ===

SDDM で {{ic|kwin_wayland}} コンポジタを使用すると、ブート時に画面の同期がずれる場合があります。{{ic|mesa-amber}} ドライバを使用していて、X11 に戻すと正しく動作する場合、{{ic|mesa-amber}} ドライバを {{ic|mesa}} に置き換えると Wayland が正しく動作する可能性があります。この問題に関する詳細は [https://bugs.kde.org/show_bug.cgi?id=483804 KDE Bug 483804] で見られます。

=== 一部のテーマがクラッシュする ===

一部の SDDM テーマは {{ic|metadata.desktop}} 内で {{ic|QtVersion}} を指定しないため、互換性の無い greeter (qt6 ではなく qt5) を SDDM が開始してしまいます。

カスタムのテーマを設定しているが、再起動時に {{ic|Library import requires a version}} というエラーでデフォルトテーマになってしまう場合、{{ic|/usr/share/sddm/themes/''テーマ名''/metadata.desktop}} に {{ic|QtVersion{{=}}6}} を追加する必要があります。

=== 時計の12時間表示と24時間表示 ===

24時間表示の時計を表示してほしいのに、12時間表示の時計になってしまうことがあります。これが発生するのは、おそらくユーザの母国語以外を使用しているが (例えば、フランス語話者がアメリカ英語を使用するなど)、母国で使用されている単位を期待するためです。

時計は、{{ic|/etc/locale.conf}} ではなく SDDM の設定に従います。{{ic|LC_TIME}} に所望のロケールが設定されていることを確認してください。詳細は [[ロケール]] を参照してください。

{{TranslationStatus|SDDM|2026-05-06|869024}}

NetworkManager

2026-05-04T11:21:05Z

AshMyzk: 同期

[[Category:ネットワークマネージャ]]
[[Category:DHCP]]
[[ar:Networkmanager]]
[[de:Networkmanager]]
[[en:NetworkManager]]
[[fr:NetworkManager]]
[[hu:NetworkManager]]
[[pt:NetworkManager]]
[[ru:NetworkManager]]
[[zh-hans:NetworkManager]]
{{Related articles start}}
{{Related|ネットワーク設定}}
{{Related|ワイヤレスネットワーク設定}}
{{Related articles end}}

[[Wikipedia:ja:NetworkManager|NetworkManager]] は、システムがネットワークに自動的に接続できるようにするためにネットワークの検出と設定の機能を提供するプログラムです。

[https://networkmanager.dev/ NetworkManager] は無線ネットワークと有線ネットワークの両方で有用です。無線ネットワークでは、NetworkManager は既知の無線ネットワークを優先するようになっており、最も信頼性のあるネットワークに切り替える機能もあります。NetworkManager 対応のアプリケーションはオンラインモードとオフラインモードの切り替えが可能です。

また、NetworkManager は無線接続よりも有線接続を優先するようになっており、モデム接続と特定の種類の VPN に対応しています。

{{Warning|デフォルトでは、シークレット (Wi-Fi のパスワードなど) は root ユーザからファイルシステムでアクセス可能であり、さらに GUI ([[#nm-applet]] など) を介して設定にアクセスできるユーザからもアクセス可能です。詳細は [[#Wi-Fi パスワードの暗号化]] を参照してください。}}

== インストール ==

NetworkManager は {{Pkg|networkmanager}} パッケージで[[インストール]]できます。このパッケージには、デーモン、コマンドラインインターフェイス (''nmcli'')、そして curses ベースのインターフェイス (''nmtui'') が含まれています。

=== NetworkManager を有効化する ===

インストールしたら、{{ic|NetworkManager.service}} を[[起動/有効化]]する必要があります。NetworkManager デーモンが起動すると、既に構成されている利用可能な "システム接続" に自動的に接続します。"ユーザ接続" や未構成の接続を設定したり接続したりするには、''nmcli'' やアプレットが必要です。

{{Note|
* 各ネットワークインターフェイスは、ただ一つの [[ネットワーク設定#ネットワークマネージャ|DHCP クライアントあるいはネットワークマネージャ]]のみで管理する必要があります。つまり、システム上には複数の DHCP クライアントあるいはネットワークマネージャを動かすべきではありません。現在実行中のサービスのリストを {{ic|1=systemctl --type=service}} で確認し、競合しているサービスを[[停止]]あるいは再設定してください。
* [[systemd-resolved]] が[[起動]]されていない場合、エラーメッセージがログに溢れ始めます。詳細は [[#Unit dbus-org.freedesktop.resolve1.service not found]] を見てください。
}}

=== 追加のインターフェイス ===

* {{Pkg|nm-connection-editor}}: グラフィカルユーザインターフェイス。
* {{Pkg|network-manager-applet}}: システムトレイアプレット ([[#nm-applet]] 章を参照)。

=== モバイルブロードバンドサポート ===

NetworkManager はモバイルブロードバンド接続のサポートに [[ModemManager]] を使用します。

{{Pkg|modemmanager}} と {{Pkg|usb_modeswitch}} を[[インストール]]してください。その後、{{ic|ModemManager.service}} を[[有効化]]し、[[起動]]してください。

ModemManager を認識させるために {{ic|NetworkManager.service}} を[[再起動]]する必要がある場合があります。サービスを再起動し、モデムを挿し直せば、認識されるはずです。

フロントエンド (例えば {{Pkg|nm-connection-editor}}) から接続を追加し、接続タイプにモバイルブロードバンドを選択してください。ISP と料金プランを選んだら、[[Wikipedia:ja:APN|APN]] とその他の設定が {{Pkg|mobile-broadband-provider-info}} にある情報で自動的に書き込まれるはずです。

=== PPPoE / DSL サポート ===

PPPoE / DSL サポートに関しては {{Pkg|ppp}} を[[インストール]]してください。PPPoE 接続を追加するには、{{ic|1=nm-connection-editor}} を使って新しい DSL/PPPoE 接続を追加してください。

=== VPN サポート ===

NetworkManager 1.16 から [[WireGuard]] のネイティブなサポートが追加されました。必要なのは {{ic|wireguard}} カーネルモジュールだけです。詳細は [https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ NetworkManager のブログ記事の WireGuard] を見てください。

その他の VPN タイプに対するサポートはプラグインなシステムをベースとしています。以下のパッケージで提供されています:

* {{Pkg|networkmanager-openconnect}}: [[OpenConnect]] 用
* {{Pkg|networkmanager-openvpn}}: [[OpenVPN]] 用
* {{Pkg|networkmanager-pptp}}: [[PPTP クライアント]]用
* {{Pkg|networkmanager-strongswan}}: [[strongSwan]] 用
* {{Pkg|networkmanager-vpnc}}
* {{AUR|networkmanager-fortisslvpn}}
* {{AUR|networkmanager-iodine-git}}
* {{AUR|networkmanager-libreswan}}
* {{Pkg|networkmanager-l2tp}}
* {{AUR|networkmanager-ssh}}
* {{Pkg|network-manager-sstp}}

{{Warning|1=VPN サポートに関連する[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues?search=VPN&state=opened バグ]が大量に存在しています。デーモンプロセスのオプションが GUI から適切に設定されていることを確認し、パッケージのリリースの度にダブルチェックしてください。}}

{{Note|1=<nowiki/>
* VPN 使用時に DNS 解決を完全に機能させるには、[[#DNS キャッシングと条件付きフォワーディング|条件付きフォワーディング]]をセットアップする必要があります。
* これらのプラグインは、ドキュメント化されたコマンドラインインターフェイスが存在しなかったり、アプレットが実行されていないと全く動作しなかったりする場合があります。通常のデスクトップ環境を使用している場合には問題になりません。通常とは異なるものを使用している場合は、接続を設定したりアクティブ化したりする際に必要なダイアログが表示されるようにするために [[#nm-applet]] を実行するべきです。[https://bbs.archlinux.org/viewtopic.php?id=246698]
}}

== 使い方 ==

NetworkManager には {{man|1|nmcli}} と {{man|1|nmtui}} が付属しています。

=== nmcli 例 ===

近くの Wi-Fi ネットワークを一覧表示します:

$ nmcli device wifi list

Wi-Fi ネットワークに接続します:

$ nmcli device wifi connect ''SSID_または_BSSID'' password ''パスワード''

非表示の Wi-Fi ネットワークに接続します:

$ nmcli device wifi connect ''SSID_または_BSSID'' password ''パスワード'' hidden yes

{{ic|wlan1}} インターフェイスで Wi-Fi に接続します:

$ nmcli device wifi connect ''SSID_または_BSSID'' password ''パスワード'' ifname wlan1 ''プロファイル名''

インターフェイスを切断します:

$ nmcli device disconnect ifname eth0

名前、UUID、タイプ、バッキングデバイスを含む接続のリストを取得します:

$ nmcli connection show

接続を有効にします (つまり、既存のプロファイルでネットワークに接続します):

$ nmcli connection up ''名前_または_uuid''

接続を削除します:

$ nmcli connection delete ''名前_または_uuid''

ネットワークデバイスとその状態のリストを表示します:

$ nmcli device

Wi-Fi をオフにします:

$ nmcli radio wifi off

=== 接続を編集する ===

設定の包括的なリストについては、{{man|5|nm-settings}} を参照してください。

まず、接続のリストを取得する必要があります:

{{hc|$ nmcli connection|<nowiki>
NAME UUID TYPE DEVICE
有線接続 2 e7054040-a421-3bef-965d-bb7d60b7cecf ethernet enp5s0
有線接続 1 997f2782-f0fc-301d-bfba-15421a2735d8 ethernet enp0s25
MY-HOME-WIFI-5G 92a0f7b3-2eba-49ab-a899-24d83978f308 wifi --
</nowiki>}}

ここでは、後で使用する接続 ID として最初の列を使用できます。この例では、{{ic|有線接続 2}} を接続 ID として選択します。

作成後に接続 {{ic|有線接続 2}} を設定するには、次の3つの方法があります:

; nmcli 対話型エディタ
: {{ic|nmcli connection edit '有線接続 2'}}。 使用法はエディタから十分に文書化されています。

; nmcli コマンドラインインターフェイス
: {{ic|nmcli connection modify '有線接続 2' ''設定''.''プロパティ'' ''値''}}。使用方法については {{man|1|nmcli}} を参照してください。例えば、{{ic|nmcli connection modify '有線接続 2' ipv4.route-metric 200}} コマンドを使用して、IPv4 ルートメトリックを 200 に変更できます。
設定を削除するには、次のように空のフィールド ("") を渡します:
: {{ic|nmcli connection modify '有線接続 2' ''設定''.''プロパティ'' ""}}

; 接続ファイル
: {{ic|/etc/NetworkManager/system-connections/}} で、対応する {{ic|有線接続 2.nmconnection}} ファイルを変更します。 {{ic|nmcli connection reload}} で設定ファイルをリロードすることを忘れないでください。

=== nmtui ===

NetworkManager には、接続、システムのホスト名、無線切り替え管理のためのテキストユーザインタフェース (TUI) が付いています。{{ic|nmtui}} と実行することで起動できます。

== フロントエンド ==

[[デスクトップ環境]]と統合するために、ほとんどのユーザはアプレットをインストールしたいと考えるでしょう。アプレットはネットワークの選択や設定を容易にするだけでなく、機密情報をセキュアに保存するために必要なエージェントも提供します。様々なデスクトップ環境は独自のアプレットを持っています。デスクトップ環境に独自のアプレットが存在しない場合、[[#nm-applet]] を使用することもできます。

=== GNOME ===

[[GNOME]] にはツールが内蔵されており、ネットワーク設定からアクセス可能です。

=== KDE Plasma ===

{{Pkg|plasma-nm}} パッケージを[[インストール]]してください。その後、''パネルオプション > ウィジェットを追加 > ネットワーク'' で KDE タスクバーにアプレットを追加してください。

=== nm-applet ===

{{Pkg|network-manager-applet}} は、システムトレイのある Xorg 環境で機能する GTK 3 フロントエンドです。

接続に関する機密情報 (Wi-Fi のパスワードなど) を保存するには、[https://specifications.freedesktop.org/secret-service-spec/latest/ Secret Service D-Bus API] を実装しているアプリケーション ([[GNOME/Keyring]]、[[KDE Wallet]]、[[KeePass|KeePassXC]] など) をインストールし設定してください。

接続の設定で {{ic|Make available to other users}} チェックボックスオプションを有効化すると、NetworkManager はその接続のパスワードを平文で保存することに注意してください。とはいえ、パスワードが含まれるファイルは root (及び {{ic|nm-applet}} を通して他のユーザ) からしかアクセスできません。[[#Wi-Fi パスワードの暗号化]] を見てください。

{{AUR|trayer}} か {{Pkg|stalonetray}} を使うことで、システムトレイ無しで {{ic|nm-applet}} を実行することができます。例えば、以下のようなスクリプトをパスに追加することができます:

{{hc|nmgui|<nowiki>
#!/bin/sh
nm-applet 2>&1 > /dev/null &
stalonetray 2>&1 > /dev/null
killall nm-applet
</nowiki>}}

''stalonetray'' のウィンドウを閉じると、{{ic|nm-applet}} も閉じます。なので、ネットワークの設定を終えたら余分なメモリが消費されることはありません。

このアプレットは、Wi-Fi ネットワークの接続や切断などのイベントの通知を表示することができます。これらの通知を表示させるには、通知サーバがインストールされている必要があります ([[デスクトップ通知]] を見てください)。アプレットを通知サーバ無しで使うと、標準出力や標準エラー出力にメッセージが表示され、最悪、アプレットがハングするかもしれません。[https://bugzilla.gnome.org/show_bug.cgi?id=788313] を参照してください。

通知を無効化した状態で {{ic|nm-applet}} を実行するには、アプレットを以下のコマンドで起動してください:

$ nm-applet --no-agent

{{Tip|{{ic|nm-applet}} は[[XDG Autostart|自動起動デスクトップファイル]]によって自動的に起動されるかもしれません。そのような場合に {{ic|--no-agent}} オプションを追加するには、デスクトップファイルの Exec 行を変更してください。つまり:

{{bc|1=Exec=nm-applet --no-agent}}

}}

{{Warning|[[i3]] では、nm-applet が {{ic|--no-agent}} オプションで起動された場合、パスワード入力ダイアログが表示されないため、アイテムリストをクリックして新しい暗号化された Wi-Fi ネットワークに接続することができなくなります。[[journal]] には {{ic|no secrets: No agents were available for this request}} と出力されます。}}

==== Appindicator ====

バージョン 1.18.0 から、Appindicator のサポートが公式の {{Pkg|network-manager-applet}} パッケージで[https://gitlab.archlinux.org/archlinux/packaging/packages/network-manager-applet/-/commit/527448fb2a87d85055f504f463dfe961dccd75c3 利用可能]になりました。nm-applet を Appindicator の環境で使うには、アプレットを以下のコマンドで起動してください:

$ nm-applet --indicator

=== networkmanager-dmenu ===

フロントエンドのもう一つの選択肢は {{Pkg|networkmanager-dmenu}} です。これは、NetworkManager の接続を {{ic|nm-applet}} ではなく [[dmenu]] や [[rofi]] で管理する小さなスクリプトです。このスクリプトには必須の機能が全て揃っています。例えば: NetworkManager の既存の Wi-Fi 接続や有線接続に接続する、新しい Wi-Fi 接続に接続する、必要に応じてパスフレーズを要求する、既存の VPN 接続に接続する、ネットワークを有効化/無効化する、''nm-connection-editor'' GUI を起動する、Bluetooth ネットワークに接続する。

=== switchboard ===

Pantheon の {{Pkg|switchboard}} は、{{Pkg|switchboard-plug-network}} と {{Pkg|nm-connection-editor}} と組み合わせて使えば、NetworkManager を設定するためのデスクトップ環境に依存しない方法になります。以下のコマンドで実行できます:

$ io.elementary.settings

== 設定 ==

NetworkManager を適切に実行させるには、いくつか追加の手順が必要になる場合があります。[[ネットワーク設定#ホスト名の設定]] で説明されているように、{{ic|/etc/hosts}} が設定されていることを確認してください。

NetworkManager のグローバルな設定ファイルは {{ic|/etc/NetworkManager/NetworkManager.conf}} です。追加の設定ファイルは {{ic|/etc/NetworkManager/conf.d/}} に置くことができます。通常、グローバルなデフォルト値に対して設定を行う必要はありません。

設定ファイルを編集したら、以下のコマンドで変更を適用することができます:

# nmcli general reload

=== NetworkManager-wait-online ===

{{ic|NetworkManager.service}} を有効化すると、{{ic|NetworkManager-wait-online.service}} も有効化されます。{{ic|NetworkManager-wait-online.service}} は oneshot なシステムサービスで、ネットワークが構成されるまで待機します。このサービスには {{ic|1=WantedBy=network-online.target}} が含まれているため、このサービスが終了するのは、{{ic|network-online.target}} 自体が有効化されている時か、あるいは {{ic|network-online.target}} が他のユニットによって実行された時のみです。[[systemd#ネットワークが稼働した後にサービスを実行する]] も参照してください。

デフォルトでは、{{ic|NetworkManager-wait-online.service}} は、ネットワーク接続が確立されるのを待つ ({{man|1|nm-online}} を参照) のではなく、NetworkManager の起動が完了するのを待ちます。ネットワークの準備が整う前に {{ic|NetworkManager-wait-online.service}} が終了してしまってブート時に一部のサービスが失敗してしまう場合、{{ic|NetworkManager-wait-online.service}} [[ユニットを拡張]]し、{{ic|ExecStart}} 行から {{ic|-s}} を削除してください:

[Service]
ExecStart=
ExecStart=/usr/bin/nm-online -q

ただし、これにより[https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/EGC324JD3HJCGVN7J55WYPRLFDA3TP7N/ 他の問題]が発生する可能性があることに注意してください。

一部のケースで、タイムアウトの設定が短すぎるために、このサービスの起動が失敗してしまう場合があります。サービスを[[編集]]して {{ic|NM_ONLINE_TIMEOUT}} を {{ic|60}} からより大きい値に変更してください。

=== PolicyKit のパーミッションをセットアップする ===

デフォルトでは、アクティブなローカルセッションのユーザは全員パスワード無しでほぼ全てのネットワーク設定を変更することができます。セッションの種類を確認する方法については、[[一般的なトラブルシューティング#セッションのパーミッション]] を見てください。ほとんどの場合、特に設定しなくても全て動作するはずです。

一部のアクション (システムのホスト名を変更するなど) においては、管理者のパスワードが必要です。そのような場合、自身のユーザを {{ic|wheel}} グループに[[ユーザーとグループ#グループ管理|追加]]し、パスワードのプロンプトを表示する [[Polkit#認証エージェント|Polkit の認証エージェント]]を実行する必要があります。

リモートセッションの場合 (例えば、[[TigerVNC#vncserver をバーチャル(ヘッドレス)セッションで起動する|ヘッドレス VNC]])、NetworkManager を使用するために必要な特権を得る方法は複数あります:

# 自身を {{ic|wheel}} グループに[[ユーザーとグループ#グループ管理|追加]]する。アクションの度にパスワードを入力する必要があります。注意点として、{{ic|wheel}} グループに追加すると他の権限 (root パスワードを入力せずに [[sudo]] を実行できるなど) も付与される場合があります。
# 自身を {{ic|network}} グループに[[ユーザーとグループ#グループ管理|追加]]し、以下の内容で {{ic|/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules}} を作成する: {{bc|<nowiki>
polkit.addRule(function(action, subject) {
if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {
return polkit.Result.YES;
}
});
</nowiki>}} {{ic|network}} グループ内の全ユーザがパスワード無しでネットワークの追加と削除を行えるようになります (これは、Polkit 認証エージェントを実行する必要がないことを意味します。なので、この方法は SSH セッションでも使えます。)。

=== プロクシ設定 ===

NetworkManager はプロキシに関するいくつかの設定をサポートしています。それらは ''nmtui'' から直接変更することはできませんが、''nm-applet'' と ''nmcli'' はそれらをサポートしています。

プロキシの設定項目は {{man|5|nm-settings-nmcli}} を参照してください。

また、ディスパッチャスクリプトを使うことでカスタムのプロキシコマンドを常時実行することができます。[[#ディスパッチャの例]] を参照してください。

参照: [[プロキシ設定]]

=== 接続の確認 ===

NetworkManager は、ネットワークに接続した後にウェブサーバへの接続を試みて、キャプティブポータルなどが存在しないか確認します。デフォルトの接続先ホスト ({{ic|/usr/lib/NetworkManager/conf.d/20-connectivity.conf}} で設定されています) は [https://ping.archlinux.org ping.archlinux.org] (redirect.archlinux.org の CNAME エイリアス) です。別のウェブサーバを使う、または接続チェックを無効化するには、{{ic|/etc/NetworkManager/conf.d/20-connectivity.conf}} を作成してください ({{man|5|NetworkManager.conf|CONNECTIVITY SECTION}} を参照)。以下は、GNOME のサーバを使用する例です ([[GNOME]] を使用する必要はありません):

{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki>
[connectivity]
uri=http://nmcheck.gnome.org/check_network_status.txt
</nowiki>}}

NetworkManager の接続チェックを無効化するには、以下の設定を使用してください。これは、接続チェックを無効化する VPN に接続している場合に便利です。

{{hc|/etc/NetworkManager/conf.d/20-connectivity.conf|<nowiki>
[connectivity]
enabled=false
</nowiki>}}

{{Note|自動的な接続チェックはプライバシーの問題を引き起こす可能性がありますが、Arch Linux のデフォルトの接続先 URL は如何なるアクセスも記録しません。[https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/fabccd0f61e5dea3925e8a0c6a46d56d5750c121#a4f34381bbb18ea77bfb3dd11a8aeca707078fca_0_26] [https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/ping/templates/nginx.d.conf.j2] を参照してください。}}

=== キャプティブポータル ===

[[Wikipedia:ja:キャプティブポータル|キャプティブポータル]]が存在している場合、デスクトップマネージャが、資格情報を求めるウィンドウを自動的に開く場合があります。あなたのデスクトップ環境がこれを行わない場合、{{Pkg|capnet-assist}} パッケージを使用することができます (しかし現在、このパッケージの NetworkManager ディスパッチャスクリプトは壊れています)。あるいは、NetworkManager ディスパッチャスクリプトを以下の内容で作成することもできます:

{{hc|/etc/NetworkManager/dispatcher.d/90-open_captive_portal|<nowiki>
#!/bin/sh -e
# Script to dispatch NetworkManager events
#
# Runs shows a login webpage on walled garden networks.
# See NetworkManager(8) for further documentation of the dispatcher events.

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

if [ -x "/usr/bin/logger" ]; then
logger="/usr/bin/logger -s -t captive-portal"
else
logger=":"
fi

wait_for_process() {
PNAME=$1
while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do
sleep 3;
done
}

#launch the browser, but on boot we need to wait that nm-applet starts
start_browser() {
local user="$1"
local display="$2"

export DISPLAY="$display"
wait_for_process nm-applet

export XAUTHORITY="/home/$user/.Xauthority"

$logger "Running browser as '$user' with display '$display' to login in captive portal"
sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null
}

# Run the right scripts
case "$2" in
connectivity-change)
$logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"
if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then
# Match last column of who's output with ' :[at least one digit] '
who | awk '$NF ~ /$:[0-9]+$/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \
while read user display; do
start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"
done
fi
;;
*)
# In a down phase
exit 0
;;
esac
</nowiki>}}

スクリプトには[[実行可能属性]]を付与してください。しかし、このスクリプトは X が使用されていることを仮定しており、単純に http ページを開きます。必ずしも動作するとは限らないかもしれません。

このスクリプトを実行するには、{{ic|NetworkManager.service}} を[[再起動]]するか、システムを再起動する必要があります。そうしたら、ディスパッチャスクリプトはキャプティブポータルを検知するとログインウィンドウを開くはずです。

簡潔な解決策は [https://github.com/Seme4eg/captive-portal-sh captive-portal-sh] です。これはキャプティブポータル URL を取得し、デフォルトのブラウザで開くシェルスクリプトです (Wayland のみ)。

別の解決策は Google Chrome ベースの {{AUR|captive-browser-git}} です。

==== 古いハードウェアにおける iwd のキャプティブポータルサポート ====

一部の古い Fi-Fi チップ (Broadcom BCM4360 など) ではプロプライエタリな {{ic|wl}} ドライバが必要ですが、これには、多くのキャプティブポータルホットスポットがログインページ表示前に使用する OWE/Elliptic-Curve ハンドシェイクのサポートがありません。NetworkManager の Wi-Fi バックエンドを、既存のドライバ上でユーザスペース内で完全な OWE 鍵交換をサポートする {{ic|iwd}} に切り替えることにより ([[#Wi-Fi バックエンドとして iwd を使用する]] を参照)、暗号化されたアソシエーションを確立したり、DHCP を利用したり、ポータルの “PORTAL” ステートをトリガーできるようになります。以上が終わったら、他の方法では完全に接続できなかったハードウェア上でも、ディスパッチャスクリプトかブラウザランチャーがログインページをポップアップします。

=== DHCP クライアント ===

デフォルトでは、NetworkManager は自身の内蔵 DHCP クライアントを使用します。内蔵 DHCPv4 プラグインは [https://nettools.github.io/n-dhcp4/ nettools の n-dhcp4] ライブラリをベースにしていますが、内蔵 DHCPv6 プラグインは systemd-networkd ベースのコードから作られています。

別の DHCP クライアントを使用するには、以下の代替実装のどれかを[[インストール]]してください:

* {{Pkg|dhcpcd}} - [[dhcpcd]]
* {{Pkg|dhclient}} - [[dhclient]]

DHCP クライアントのバックエンドを変更するには、{{ic|/etc/NetworkManager/conf.d/}} 内に設定ファイルを作成して、そのファイル内で {{ic|1=main.dhcp=''DHCP_クライアント名''}} オプションを設定してください。例えば:

{{hc|1=/etc/NetworkManager/conf.d/dhcp-client.conf|2=
[main]
dhcp=dhcpcd
}}

{{Note|
{{Pkg|dhclient}} パッケージと {{Pkg|dhcpcd}} パッケージに同梱されている systemd ユニットは有効化しないでください。NetworkManager と競合してしまいます。詳細は [[#インストール]] セクションに書かれているノートを見てください。
}}

=== DNS の管理 ===

NetworkManager の DNS 管理については、GNOME プロジェクトの wiki ページ [https://wiki.gnome.org/Projects/NetworkManager/DNS Projects/NetworkManager/DNS] で説明されています。

==== DNS キャッシングと条件付きフォワーディング ====

NetworkManager には、[[dnsmasq]] または [[systemd-resolved]] を使用して DNS キャッシングと条件付きフォワーディングを有効化するプラグインが存在します ([https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143 以前は]、"条件付きフォワーディング" は NetworkManager のドキュメントで "split DNS" と呼ばれていました)。このセットアップには、DNS ルックアップがキャッシュされるので名前解決の時間が短縮され、VPN ホストの DNS ルックアップが、関連する VPN の DNS サーバに転送されるという長所があります。これは、複数の VPN に接続する場合に特に便利です。

{{Note|{{ic|/etc/resolv.conf}} が {{ic|/run/systemd/resolve/stub-resolv.conf}} や {{ic|/run/systemd/resolve/resolv.conf}}、{{ic|/lib/systemd/resolv.conf}}、{{ic|/usr/lib/systemd/resolv.conf}} へのシンボリックリンクである場合、NetworkManager は systemd-resolved を自動的に選択します。dnsmasq を使用するには、まずシンボリックリンクを削除する必要があります。その後で、NetworkManager を再起動してください。}}

===== dnsmasq =====

{{Pkg|dnsmasq}} がインストールされていることを確認してください。そして、{{ic|/etc/NetworkManager/conf.d/}} 内の設定ファイル (無い場合は作成してください) で {{ic|1=main.dns=dnsmasq}} を設定してください:

{{hc|/etc/NetworkManager/conf.d/dns.conf|2=
[main]
dns=dnsmasq
}}

次に、{{ic|nmcli general reload}} を root として実行してください。NetworkManager は自動的に dnsmasq を起動し、{{ic|/etc/resolv.conf}} に {{ic|127.0.0.1}} を追加します。元の DNS サーバは {{ic|/run/NetworkManager/no-stub-resolv.conf}} を見れば分かります。dnsmasq が使用されているかどうかは、{{ic|drill example.com}} で同じ DNS ルックアップを2度行ってサーバとクエリの時間を計測すれば確認できます。

{{Note|
* {{ic|dnsmasq.service}} を起動したり、{{ic|/etc/dnsmasq.conf}} を編集したりする必要はありません。NetworkManager は、その systemd サービスを使わず、さらに dnsmasq のデフォルトの設定ファイルを読み込まずに dnsmasq を起動します。
* NetworkManager によって起動された dnsmasq インスタンスは {{ic|127.0.0.1:53}} にバインドされます。なので、これと同じアドレスとポートで他のソフトウェア ({{ic|dnsmasq.service}} も含む) を実行することはできません。
}}

====== dnsmasq のカスタム設定 ======

{{ic|/etc/NetworkManager/dnsmasq.d/}} 内に設定ファイルを作成することで、''dnsmasq'' のカスタム設定を作成することができます。例えば、DNS キャッシュ (RAM 内に格納されます) のサイズを変更するには:

{{hc|/etc/NetworkManager/dnsmasq.d/cache.conf|2=
cache-size=1000
}}

設定ファイルの構文は以下のコマンドで確認できます:

$ dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d

利用可能な全てのオプションについては {{man|8|dnsmasq}} を参照してください。

====== IPv6 ======

{{Accuracy|NetworkManager は {{ic|::1}} を {{ic|/etc/resolv.conf}} に追加しないため、以下の方法では問題を解決できません。{{ic|@::1}} を手動で drill に渡さない限り、{{ic|Error: error sending query: No (valid) nameservers defined in the resolver}} というエラーで失敗します。}}

NetworkManager で {{ic|dnsmasq}} を有効化すると、IPv6 のみの DNS ルックアップ (つまり、{{ic|drill -6 [hostname]}}) が機能しなくなる場合があります (しかし、それ以外では機能する)。この問題を解決するには、以下のファイルを作成し、IPv6 ループバックもリッスンするように ''dnsmasq'' を設定してください:

{{hc|/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf|2=
listen-address=::1
}}

さらに、{{ic|dnsmasq}} は上流の IPv6 DNS を優先しません。残念ながら、NetworkManager も IPv6 DNS を優先しません ([https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/936712 Ubuntu Bug])。回避策は、NetworkManager の設定で IPv6 DNS を無効化することです (IPv4 DNS があると仮定します)。

====== DNSSEC ======

NetworkManager によってデフォルトで開始される dnsmasq インスタンスは、[[DNSSEC]] を検証しません。DNSSEC 検証を有効化するには、以下の設定ファイルを作成してください (これにより、DNSSEC をサポートしない名前サーバでの DNS 解決が機能しなくなります):

{{hc|/etc/NetworkManager/dnsmasq.d/dnssec.conf|2=
conf-file=/usr/share/dnsmasq/trust-anchors.conf
dnssec
}}

===== systemd-resolved =====

NetworkManager は [[systemd-resolved]] を DNS リゾルバ及び DNS キャッシュとして使用することができます。まず先に、''systemd-resolved'' が適切に設定されていて、{{ic|systemd-resolved.service}} が[[開始]]されていることを確認してください。

{{ic|/etc/resolv.conf}} が {{ic|/run/systemd/resolve/stub-resolv.conf}} や {{ic|/run/systemd/resolve/resolv.conf}}、{{ic|/usr/lib/systemd/resolv.conf}} への[[systemd-resolved#DNS|シンボリックリンク]]である場合、systemd-resolved は自動的に使用されます。

{{ic|/etc/NetworkManager/conf.d/}} 内の設定ファイルで {{ic|1=main.dns=systemd-resolved}} を設定することで、これを明示的に有効化することもできます:

{{hc|/etc/NetworkManager/conf.d/dns.conf|2=
[main]
dns=systemd-resolved
}}

===== openresolv サブスクライバのある DNS リゾルバ =====

ローカルの [[DNS リゾルバ]]へのサブスクライバ (加入者) が [[openresolv]] に存在している場合、サブスクライバをセットアップし、[[#openresolv を使う|openresolv を使用するように NetworkManager を設定してください]]。

NetworkManager は単一の "インターフェイス" を ''resolvconf'' に広告するため、2つの NetworkManager 接続間で条件付きフォワーディングを行うのは不可能です。[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 NetworkManager issue 153] を参照してください。

この問題は {{ic|/etc/resolvconf.conf}} で {{ic|1=private_interfaces="*"}} を設定すれば、部分的に緩和できます [https://roy.marples.name/projects/openresolv/configuration/]。検索ドメインリストに無いドメインのクエリは、フォワーディングされません。そのようなクエリは、他の DNS サーバにフォワーディングされるか、DNS ルートサーバから回帰的に解決されるなどして、ローカルのリゾルバの設定に従って処理されます。

==== カスタム DNS サーバ ====

===== カスタムグローバル DNS サーバの設定 =====

全ての接続に対して DNS サーバを設定するには、{{man|5|NetworkManager.conf}} 内で {{ic|[global-dns-domain-*]}} というセクション内で {{ic|1=servers=''serveripaddress1'',''serveripaddress2'',''serveripaddress3''}} という構文を使ってDNS サーバを指定してください。例えば:

{{hc|/etc/NetworkManager/conf.d/dns-servers.conf|2=
[global-dns-domain-*]
servers=::1,127.0.0.1
}}

{{Note|
* [[#DNS キャッシングと条件付きフォワーディング|NetworkManager の dnsmasq か systemd-resolved プラグイン]]、または [[#openresolv サブスクライバのある DNS リゾルバ|openresolv サブスクライバ]]を使用する場合、{{ic|1=servers=}} オプションにループバックアドレスを指定しないでください。DNS 解決が機能しなくなる可能性があります。
* 指定されたサーバは [[systemd-resolved]] に送られず、接続の DNS サーバが代わりに使用されます。[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1366 NetworkManager issue 1366] と [https://github.com/systemd/systemd/issues/33754 systemd issue 33754] を参照。
}}

===== 接続でのカスタム DNS サーバの設定 =====

====== 接続でのカスタム DNS サーバの設定 (GUI) ======

セットアップ方法は、使用するフロントエンドの種類に依ります。手順としては通常、アプレットを右クリックし、プロファイルを編集 (または作成) し、DHCP タイプに ''自動 (アドレスのみ)'' (''Automatic (specify addresses)'') を選択するというものです。DNS アドレスを入力する必要があり、通常、{{ic|127.0.0.1, ''DNS-server-one'', ...}} という形です。

====== 接続でのカスタム DNS サーバの設定 (nmcli / 設定ファイル) ======

DNS サーバーを接続毎にセットアップするには、[[#接続を編集する|接続設定]]で {{ic|ipv4.dns}} と {{ic|ipv6.dns}} の設定 (及び、それらに関連する {{ic|dns-search}} と {{ic|dns-options}}) を変更してください。

{{ic|method}} が {{ic|auto}} に設定されている場合 (DHCP/RA を使用する場合)、{{ic|ignore-auto-dns}} を {{ic|yes}} に設定する必要があります。

DNS over TLS を使用するには ([[#systemd-resolved|systemd-resolved が必要です]])、{{ic|1=dns=''ip.address''#''servername'';}} のようにして DNS サーバーを指定し、さらに {{ic|connection.dns-over-tls}} を {{ic|2}} に設定してください。例えば、Quad9 を使用するには:

{{hc|/etc/NetworkManager/system-connections/Example Wi-Fi.nmconnection|2=
...
[connection]
...
dns-over-tls=2

[ipv4]
...
dns=9.9.9.9#dns.quad9.net;149.112.112.112#dns.quad9.net;
ignore-auto-dns=true

[ipv6]
...
dns=2620:fe::fe#dns.quad9.net;2620:fe::9#dns.quad9.net;
ignore-auto-dns=true
}}

{{Note|この例では Quad9 を使用しています。あなたにとって信頼できる DNS リゾルバに変更してください。[[ドメイン名前解決#サードパーティの DNS サービス]] を参照してください。}}

==== /etc/resolv.conf ====

NetworkManager の {{ic|/etc/resolv.conf}} 管理モードは、{{ic|main.rc-manager}} で設定されます。{{Pkg|networkmanager}} パッケージはこれを、上流のデフォルトである {{ic|auto}} ではなく、{{ic|symlink}} に設定します。設定と値は {{man|5|NetworkManager.conf}} man ページでドキュメント化されています。

{{Tip|openresolv を使用すると、NetworkManager は、''resolvconf'' によってサポートされている他のソフトウェアと共存できます。例えば、openresolv が [[openresolv#Subscribers|subscriber]] を持つローカル DNS キャッシングおよび分割 DNS リゾルバを実行できます。openresolv で NetworkManager を使用する場合、条件付きフォワーディングは[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/153 まだ完全にサポートされていない]ことに注意してください。}}

また、''NetworkManager'' は、ネットワークの変更後に {{ic|/etc/resolv.conf}} を変更するために使用できる、いわゆるディスパッチャスクリプトを介したフックも提供します。詳細は [[#ネットワークサービスで NetworkManager dispatcher を使用する]] と {{man|8|NetworkManager}} を参照してください。

{{Note|
* NetworkManager が [[#dnsmasq|dnsmasq]] または [[systemd-resolved]] のいずれかを使用するように設定されている場合、適切なループバックアドレスが {{ic|/etc/resolv.conf}} に書き込まれます。
* NetworkManager が書き込む {{ic|resolv.conf}}、または {{ic|/etc/resolv.conf}} に書き込む内容は、{{ic|/run/NetworkManager/resolv.conf}} で見られます。
* 取得したネームサーバーと検索ドメインを含む {{ic|resolv.conf}} ファイルは、{{ic|/run/NetworkManager/no-stub-resolv.conf}} にあります。
}}

===== 管理対象外の /etc/resolv.conf =====

NetworkManager が {{ic|/etc/resolv.conf}} に干渉しないようにするには、{{ic|/etc/NetworkManager/conf.d/}} の設定ファイルで {{ic|1=main.dns=none}} を設定してください:

{{hc|/etc/NetworkManager/conf.d/dns.conf|2=
[main]
dns=none
}}

{{Tip|NetworkManager が DNS 設定を [[systemd-resolved]] に送信しないように、{{ic|1=main.systemd-resolved=false}} を設定することもできます。}}

{{Note|{{ic|1=main.dns=none}} を使うのではなく、[[dnsmasq]] や [[systemd-resolved]] などの他の DNS バックエンドを使用するように NetworkManager を設定する方法については、[[#DNS キャッシングと条件付きフォワーディング]] を見てください。}}

その後、{{ic|/etc/resolv.conf}} が壊れたシンボリックリンクになり、削除する必要が生じるかもしれません。その場合、新しい {{ic|/etc/resolv.conf}} ファイルを作成してください。

===== openresolv を使う =====

{{Note|NetworkManager は、{{Pkg|systemd-resolvconf}} によって提供されている systemd-resolved の ''resolvconf'' インターフェイスの使用をサポートしていません ({{man|1|resolvectl|COMPATIBILITY WITH RESOLVCONF(8)}})。
* [[systemd-resolved]] を使用する際は {{ic|1=main.rc-manager=resolvconf}} を設定しないでください。代わりに、[[systemd-resolved#DNS|/etc/resolv.conf シンボリックリンクを適切に作成する]]か、[[#systemd-resolved|systemd-resolved を使用するように NetworkManager を明示的に設定]]してください。
* systemd-resolved を使用しない場合は、{{Pkg|systemd-resolvconf}} パッケージがインストールされていないことを確認してください。{{ic|systemd-resolved.service}} が起動されていないと、このパッケージは、resolvconf を使用する全てのネットワーキングソフトウェア (NetworkManager だけではありません) の機能を破壊します。
}}

[[openresolv]] を使用するように NetworkManager を設定するには、{{ic|/etc/NetworkManager/conf.d/}} 内の設定ファイルで {{ic|1=main.rc-manager=resolvconf}} を設定してください:

{{hc|/etc/NetworkManager/conf.d/rc-manager.conf|2=
[main]
rc-manager=resolvconf
}}

=== ファイアウォール ===

現在の接続に基づいて [[Firewalld#NetworkManager を使ったゾーン管理|firewalld ゾーンを割り当てる]]ことができます。たとえば、職場では制限の厳しいファイアウォールを使用し、自宅では制限の少ないファイアウォールを使用します。

これは、[[#ネットワークサービスで NetworkManager dispatcher を使用する|NetworkManager dispatcher]] を使用して行うこともできます。

== ネットワークサービスで NetworkManager dispatcher を使用する ==

NetworkManager がインターフェイスを立ち上げるまで実行したくないようなネットワークサービスはたくさんあります。NetworkManager には、(例えば [[NFS]] や [[SMB]]、[[ネットワークタイムプロトコルデーモン|NTPd]] を使用する時などに) ネットワークに接続したらサービスを開始し、切断したらサービスを停止する機能があります。

この機能を有効化するには、{{ic|NetworkManager-dispatcher.service}} を[[有効化]]し、かつ[[起動]]する必要があります。

このサービスを有効化したら、{{ic|/etc/NetworkManager/dispatcher.d}} 内にスクリプトを追加することができます。

スクリプトは '''root''' によって所有されていなければなりません。ディスパッチャは、root によって所有されていないスクリプトを実行しません。セキュリティを高めるために、スクリプトのグループ[[所有権]]も root に設定してください:

# chown root:root /etc/NetworkManager/dispatcher.d/''10-script.sh''

スクリプトファイルを[[実行可能属性|実行可能]]にするのを忘れないでください。

スクリプトは、ネットワークへの接続時にはアルファベット順で実行され、切断時には逆アルファベット順で実行されます。実行される順番を保証するために、スクリプトの名前の前に数字を置くのが一般的です (例: {{ic|10-portmap}}、{{ic|30-netfs}}。こうすることで、NFS がマウントを試みる前に、''portmapper'' が立ち上がります)

スクリプトは以下の引数を受け取ります:

* '''インターフェイス名:''' 例えば {{ic|eth0}}
* '''アクション:''' ''up''、''down''、''vpn-up''、''vpn-down'' など (完全なリストは {{man|8|NetworkManager-dispatcher}} を見てください)

{{Warning|外部ネットワークや公開ネットワークに接続する場合は、どのサービスを起動するのか、どのサーバにサービスは接続できるのかに注意してください。公開ネットワークに接続する際に間違ったサービスを起動してしまうとセキュリティホールを作ってしまう可能性があります。}}

=== ディスパッチャのタイムアウトを防ぐ ===

上記がうまくいっているのであれば、このセクションは関係しません。しかし、ディスパッチャのスクリプトの実行に時間が掛かってしまうという一般的な問題があります。最初は、3 秒だけの内部タイムアウトが使用されていました。呼ばれたスクリプトが時間内に完了しないと、そのスクリプトは kill されていました。後に、タイムアウトは約 20 秒に延長されました (詳細は [https://bugzilla.redhat.com/show_bug.cgi?id=982734 Bugtracker] を参照)。タイムアウトのせいで依然として問題が発生する場合は、{{ic|NetworkManager-dispatcher.service}} に対する[[ドロップインファイル]]を使って、終了後もアクティブ状態を維持するように設定することで問題を回避できます:

{{hc|/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf|2=
[Service]
RemainAfterExit=yes
}}

その後、変更した {{ic|NetworkManager-dispatcher}} サービスを開始し、かつ有効化してください。

{{Warning|{{ic|RemainAfterExit}} 行を追加すると、ディスパッチャが閉じられなくなります。残念ながら、ディスパッチャは、スクリプトを再び実行する前に'''閉じなければなりません'''。先の設定により、ディスパッチャはタイムアウトしませんが、閉じられもしません。これは、スクリプトはブート毎に 1 度しか実行されないことを意味します。なので、タイムアウトが実際に問題を起こしていない限り、この行を追加しないでください。}}

=== ディスパッチャの例 ===

==== タイムゾーンを自動的に設定する ====

[[#ネットワークサービスで NetworkManager dispatcher を使用する|NetworkManager ディスパッチャスクリプト]]を作成し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/NetworkManager/dispatcher.d/09-timezone|
#!/bin/sh
case "$2" in
up)
timedatectl set-timezone "$(curl --fail <nowiki>https://ipapi.co/timezone</nowiki>)"
;;
esac
}}

{{Tip|{{ic|up}} の代わりに {{ic|connectivity-change}} を使うと、[[OpenConnect]] などの VPN クライアントで VPN に接続した際に、タイムゾーンが変更されないようにすることができます。}}

あるいは、{{AUR|tzupdate}} ツールを使うと、IP アドレスのいち情報に基づいてタイムゾーンを自動的に設定できます。運用環境内でどの API を使用するのかを決める際には、[https://medium.com/@ipdata_co/what-is-the-best-commercial-ip-geolocation-api-d8195cda7027 最も人気のある IP 位置情報 API の比較]をみると役立つかもしれません。

==== sshfs でリモートディレクトリをマウントする ====

このスクリプトは非常に制限された環境内で実行されるため、SSH エージェントに接続するためには {{ic|SSH_AUTH_SOCK}} 変数をエクスポートする必要があります。これを行う方法はいくつかあります (詳細は[https://bbs.archlinux.org/viewtopic.php?pid=1042030#p1042030 このメッセージ]を見てください)。以下の例は [[GNOME Keyring]] を使って動作し、キーリングがまだアンロックされていない場合はパスワードを要求します。NetworkManager がログイン時に自動的にネットワークに接続するような状況では、''gnome-keyring'' がまだ開始されておらず、変数のエクスポートが失敗する可能性が高いです (そのために sleep コマンドがあります)。接続とマッチする {{ic|UUID}} は、{{ic|nmcli connection status}} か {{ic|nmcli connection list}} を実行すれば確認できます。

{{bc|<nowiki>
#!/bin/sh
USER='username'
REMOTE='user@host:/remote/path'
LOCAL='/local/path'

interface=$1 status=$2
if [ "$CONNECTION_UUID" = "</nowiki>''uuid''<nowiki>" ]; then
case $status in
up)
# sleep 10
SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')
export SSH_AUTH_SOCK
su "$USER" -c "sshfs $REMOTE $LOCAL"
;;
down)
fusermount -u "$LOCAL"
;;
esac
fi
</nowiki>}}

==== SMB 共有をマウントする ====

[[SMB]] 共有は特定のネットワークや場所 (例えば自宅) でしか利用できないことがあります。ディスパッチャを使えば、現在の場所で利用可能な SMB 共有のみをマウントすることができます。

以下のスクリプトは、特定のネットワークに接続していることを確認し、それに応じて共有をマウントします:

{{hc|/etc/NetworkManager/dispatcher.d/30-mount-smb.sh|<nowiki>
#!/bin/sh

# 接続 UUID はターミナルで "nmcli connection show" を実行して確認してください。
# 全種類の NetworkManager 接続がサポートされています: 無線、VPN、有線など。
if [ "$2" = "up" ]; then
if [ "$CONNECTION_UUID" = "uuid" ]; then
mount /your/mount/point &
# add more shares as needed
fi
fi
</nowiki>}}

以下のスクリプトは、ソフトウェアが特定のネットワークからの切断を開始する前に、全ての SMB 共有をアンマウントします:

{{hc|/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh|<nowiki>
#!/bin/sh

if [ "$CONNECTION_UUID" = "uuid" ]; then
umount -a -l -t cifs
fi
</nowiki>}}

{{Note|このスクリプトは上記の通り {{ic|pre-down.d}} サブディレクトリに配置してください。さもないと、接続状態が変わる度に毎回、全ての共有がアンマウントされてしまいます。}}

以下のスクリプトは、特定のネットワークから予期せずに切断されてしまった時に、全ての SMB 共有のアンマウントを試みます:

{{hc|/etc/NetworkManager/dispatcher.d/40-umount-smb.sh|<nowiki>
#!/bin/sh

if [ "$CONNECTION_UUID" = "uuid" ]; then
if [ "$2" = "down" ]; then
umount -a -l -t cifs
fi
fi
</nowiki>}}

{{Note|
* NetworkManager 0.9.8 から、''pre-down'' と ''down'' のイベントはシャットダウン時や再起動時に実行されなくなりました。詳細は[https://bugzilla.gnome.org/show_bug.cgi?id=701242 このバグレポート]を見てください。
* 上記 2 つの ''umount'' スクリプトでは、マウントに実際にアクセスしているアプリケーションが 'ハング' してしまう傾向が依然としてあります。
}}

代替案は、[[NFS#NetworkManager dispatcher を使う]] にあるスクリプトを使うことです:

{{hc|/etc/NetworkManager/dispatcher.d/30-smb.sh|<nowiki>
#!/bin/sh

# 接続 UUID はターミナルで "nmcli connection show" を実行して確認してください。
# 全種類の NetworkManager 接続がサポートされています: 無線、VPN、有線など。
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"

if [ "$CONNECTION_UUID" = "$WANTED_CON_UUID" ]; then

# スクリプトパラメータ $1: ネットワークインターフェイス名 (未使用)
# スクリプトパラメータ $2: ディスパッチされたイベント

case "$2" in
"up")
mount -a -t cifs
;;
"down"|"pre-down"|"vpn-pre-down")
umount -l -a -t cifs >/dev/null
;;
esac
fi
</nowiki>}}

{{Note|このスクリプトは {{ic|noauto}} オプションのマウントは無視します。これらのマウントをディスパッチャが管理できるようにするには、このオプションを取り除くか、{{ic|auto}} を使ってください。}}

{{ic|pre-down}} イベントをキャッチできるようにするために {{ic|/etc/NetworkManager/dispatcher.d/pre-down/}} 内にシンボリックリンクを作成してください:

# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh

==== NFS 共有をマウントする ====

[[NFS#NetworkManager dispatcher を使う]] を見てください。

==== ディスパッチャを使って、LAN ケーブルが挿入されているかに応じて Wi-Fi を自動的にオンオフする ====

アイディアとしては、LAN ケーブルが抜かれた時にのみ Wi-Fi をオンにし (例えば、ラップトップのドックから取り外された時など)、LAN ケーブルが挿入されたら Wi-Fi を自動的に無効化します。

以下のディスパッチャスクリプトを作成してください[https://superuser.com/questions/233448/disable-wlan-if-wired-cable-network-is-available]。{{ic|''Your_Ethernet_Interface''}} の部分は実際のイーサネットインターフェイスのデバイス名に変更してください。

{{Note|[[#nmcli 例|nmcli]] を使えばインターフェイスのリストを取得できます ({{ic|nmcli d {{!}} grep ethernet}})。イーサネットインターフェイスは {{ic|en}} か {{ic|eth}} で始まります (例: {{ic|enp0s5}}、{{ic|eth0}})。}}

このスクリプトを[[実行可能属性|実行可能]]にすることを忘れないでください。{{ic|NetworkManager.service}} を[[再起動]]し、{{ic|ip a}} を実行して {{ic|wlp3s0}} (実際の Wi-Fi インターフェイス名) が {{ic|state DOWN}} であればうまく行っています。予想外の動作が起こった場合は、{{ic|NetworkManager-dispatcher.service}} の [[journal]] を確認してください。

{{hc|/etc/NetworkManager/dispatcher.d/99-wifi-auto-toggle.sh|2=
#!/bin/sh

LOG_PREFIX="WiFi Auto-Toggle"
ETHERNET_INTERFACE="''Your_Ethernet_Interface''"

if [ "$1" = "$ETHERNET_INTERFACE" ]; then
case "$2" in
up)
echo "$LOG_PREFIX ethernet up"
nmcli radio wifi off
;;
down)
echo "$LOG_PREFIX ethernet down"
nmcli radio wifi on
;;
esac
elif [ "$(nmcli -g GENERAL.STATE device show $ETHERNET_INTERFACE)" = "20 (unavailable)" ]; then
echo "$LOG_PREFIX failsafe"
nmcli radio wifi on
fi
}}

{{Note|コンピュータが最後にオンであったときに接続されていた LAN インターフェイスが、コンピュータがオフになったときに切断された場合のフェイルセーフ機構が存在します。つまり、LAN インターフェイスが切断されている状態でコンピュータがオンに戻ったときにも無線がオフのままになるということです。この場合、ネットワークに接続されていない状態になります。}}

==== ディスパッチャを使って、ネットワーク接続が確立された後に VPN に接続する ====

この例では、特定の Wi-Fi ネットワークに接続した後に、以前定義された VPN 接続に自動的に接続したいと思います。最初にすべきことは、そのネットワークに接続した後にすることを定義するディスパッチャスクリプトを作成することです。

{{Accuracy|A scripting without {{ic|iwgetid}} does work too and may be more reliable? (議論: [[:en:Talk:NetworkManager#Fixes for automatic VPN dispatcher script]])}}

{{Note|このスクリプトでは {{ic|iwgetid}} を使うために {{Pkg|wireless_tools}} を必要とします。}}

{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki>
#!/bin/sh
VPN_NAME="NetworkManager に定義されている VPN 接続の名前"
ESSID="Wi-Fi ネットワークの ESSID (接続名ではない)"

interface=$1 status=$2
case $status in
up|vpn-down)
if iwgetid | grep -qs ":\"$ESSID\""; then
nmcli connection up id "$VPN_NAME"
fi
;;
down)
if iwgetid | grep -qs ":\"$ESSID\""; then
if nmcli connection show --active | grep "$VPN_NAME"; then
nmcli connection down id "$VPN_NAME"
fi
fi
;;
esac
</nowiki>}}

全ての Wi-Fi ネットワークで VPN への接続を試みたい場合は、次の ESSID 定義を使用できます: {{ic|1=ESSID=$(iwgetid -r)}}。スクリプトのパーミッションを[[#ネットワークサービスで NetworkManager dispatcher を使用する|適宜]]設定することを忘れないでください。

[https://developer.gnome.org/NetworkManager/0.9/secrets-flags.html VPN の機密情報が保管される方法]により、上記のスクリプトで VPN への接続しようとしても、{{ic|NetworkManager-dispatcher.service}} が 'no valid VPN secrets' というエラーで失敗する場合があります。幸運なことに、スクリプトから VPN のパスワードにアクセスする方法は他にもあります。

1: それらの方法の1つでは、VPN 接続の設定ファイルを編集して、[https://bugzilla.redhat.com/show_bug.cgi?id=710552 root からはアクセスできない]キーリングではなく自身で機密情報を保存させるように NetworkManager を設定する必要があります: {{ic|/etc/NetworkManager/system-connections/''VPN接続の名前''.nmconnection}} を開き、{{ic|password-flags}} と {{ic|secret-flags}} を {{ic|1}} から {{ic|0}} に変更してください。

それだけではうまく行かない場合は、以下の内容で {{ic|passwd-file}} を安全な場所にディスパッチャスクリプトと同じパーミッションと所有権で作成する必要があるかもしれません:

{{hc|/path/to/passwd-file|
vpn.secrets.password:パスワード
}}

ファイルからパスワードを得られるようにするために、スクリプトは適宜変更する必要があります:

{{hc|/etc/NetworkManager/dispatcher.d/vpn-up|<nowiki>
#!/bin/sh
VPN_NAME="NetworkManager に定義されている VPN 接続の名前"
ESSID="Wi-Fi ネットワークの ESSID (接続名ではない)"

interface=$1 status=$2
case $status in
up|vpn-down)
if iwgetid | grep -qs ":\"$ESSID\""; then
nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file
fi
;;
down)
if iwgetid | grep -qs ":\"$ESSID\""; then
if nmcli connection show --active | grep "$VPN_NAME"; then
nmcli connection down id "$VPN_NAME"
fi
fi
;;
esac
</nowiki>}}

2: あるいは、{{ic|password-flags}} を変更して、設定ファイル内に {{ic|vpn-secrets}} セクションを追加してパスワードを直接書き込むという方法もあります:

[vpn]
....
password-flags=0

[vpn-secrets]
password=''パスワード''

{{Note|NetworkManager の接続エディタを再び開き、VPN のパスワード/機密情報を保存し直す必要があるかもしれません。}}

==== ディスパッチャを使って、VPN プロバイダの接続時に IPv6 を無効化する ====

多くの[[:カテゴリ:VPN プロバイダー|商用 VPN プロバイダー]]は IPv4 のみをサポートしています。つまり、IPv6 のトラフィックは全て VPN をバイパスし、事実上、使い物にならなくなります。ディスパッチャを使って、VPN に接続されている時は全ての IPv6 トラフィックを無効化することで、この問題を回避できます。

{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki>
#!/bin/sh

case "$2" in
vpn-up)
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
;;
vpn-down)
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6
;;
esac
</nowiki>}}

{{Note|WireGuard では、NetworkManager が {{ic|vpn-up/down}} イベントを出さないため、上記のスクリプトは動作しません。代わりに、[https://gist.github.com/TheDcoder/85e1ec99a31180e20ba8e4896024f265] のコードのように WireGuard インターフェイスに対しては汎用イベントに頼る必要があります。}}

代替案としては、ディスパッチャを使って、VPN 接続に使用しているデバイスの IPv6 モードを一時的に {{ic|link-local}} に設定することもできます。これにより、NetworkManager が、IPv6 が無効化されていることについて警告をログに大量出力することを防ぐことができます。このスクリプトは、複数のデバイスや接続が IPv6 接続を提供している場合、動作しません。しかし、複数のデバイスを反復させることで応用することができます。注意点として、接続に対して何らかの変更が加えられた場合 ({{man|1|nmcli}} や[[デスクトップ環境]]の機能を使った場合)、そのデバイスに対する接続全体が再適用され、IPv6 が再有効化されます (その接続で有効化されている場合)。

{{hc|/etc/NetworkManager/dispatcher.d/10-vpn-ipv6|<nowiki>
#!/bin/sh

case "$2" in
vpn-up)
nmcli device modify "${DEVICE_IFACE}" ipv6.method link-local
;;
vpn-down)
nmcli device reapply "${DEVICE_IFACE}"
;;
esac
</nowiki>}}

==== OpenNTPD ====

[[OpenNTPD#NetworkManager dispatcher を使う]] を参照してください。

==== systemd-timesyncd で DHCP 経由で受信した NTP サーバを動的に設定する ====

異なるネットワーク間 (例: 会社の LAN、自宅の Wi-Fi、その他の様々な Wi-Fi) でローミングする場合、timesyncd によって使用されている NTP サーバを DHCP によって提供されているものに設定したい場合があります。ただし、NetworkManager 自体は systemd-timesyncd と通信して NTP サーバを設定することはできません。

ディスパッチャを使うことで、この問題を回避できます。

systemd-timesyncd の設定ようのオーバーレイディレクトリ {{ic|/etc/systemd/timesyncd.conf.d}} を[[作成]]してください (まだ存在していない場合)。{{ic|/etc/NetworkManager/dispatcher.d}} 内に以下を追加してください:

{{hc|/etc/NetworkManager/dispatcher.d/10-update-timesyncd|<nowiki>
#!/bin/sh

[ -z "$CONNECTION_UUID" ] && exit 0
INTERFACE="$1"
ACTION="$2"

case $ACTION in
up | dhcp4-change | dhcp6-change)
# `DHCP6_DHCP6_NTP_SERVERS` with double `DHCP6` is the correct variable name as varified by `printenv` as of NetworkManager 1.56.0-1
set -- ${DHCP6_DHCP6_NTP_SERVERS-} ${DHCP4_NTP_SERVERS-}
servers=$*
[ -n "$servers" ] || exit 0
mkdir -p /etc/systemd/timesyncd.conf.d
cat <<-THE_END >"/etc/systemd/timesyncd.conf.d/${CONNECTION_UUID}.conf"
[Time]
NTP=$servers
THE_END
systemctl restart systemd-timesyncd.service
;;
down)
rm -f "/etc/systemd/timesyncd.conf.d/${CONNECTION_UUID}.conf"
systemctl restart systemd-timesyncd.service
;;
esac
</nowiki>}}

NetworkManager が新しいネットワーク接続を設定する ({{ic|1=ACTION=up}}) か、既存の接続の更新を取得する ({{ic|1=ACTION=dhcp4-change}} または {{ic|1=ACTION=dhcp6-change}}) 度に、接続データに NTP サーバ ({{ic|DHCP6_DHCP6_NTP_SERVERS}} と {{ic|DHCP4_NTP_SERVERS}}) に関する情報が含まれていると、接続固有のオーバーレイ設定ファイルが {{ic|/etc/systemd/timesyncd.conf.d}} に書き込まれ、このファイルには、提供された NTP サーバ (1台または複数) の情報が記述されます。提供された NTP サーバが含まれます。接続が停止される ({{ic|1=ACTION=down}}) と、接続固有のオーバーレイファイルは削除されます。systemd-timesyncd の設定が変更されるたびに、サービスは再起動され、更新された設定を取得します。NetworkManager で 2つ以上の接続を並行して管理する場合、{{ic|up}}、{{ic|dhcp4-change}}、{{ic|dhcp6-change}}、そして {{ic|down}} アクションが任意の順序で来るかもしれないので、設定内の異なる NTP サーバ名が上書きされないように接続固有の設定ファイルを意図的に使用しています。

{{Note|NetworkManager 1.56.0-1 の時点では、{{ic|1=DHCP6}} が2つある {{ic|1=DHCP6_DHCP6_NTP_SERVERS}} は、{{ic|1=printenv}} で確認できるように正しい変数名です。}}

== テスト ==

NetworkManager アプレットはログイン時にロードされるようになっているので、ほとんどのユーザにとって追加の設定は必要ないはずです。以前のネットワーク設定を無効化し、ネットワークから切断されているならば、NetworkManager が動作するかどうかをテストできます。まず始めに、{{ic|NetworkManager.service}} を[[起動]]してください。

一部のアプレットは、NetworkManager アプレットをアプリケーションメニューからロードできるようにするために、{{ic|.desktop}} ファイルを提供しています。デスクトップファイルが提供されていない場合は、アプレットを使用するためのコマンドを見つけるか、アプレットをロードするために一度ログアウトして再度ログインする必要があります。アプレットが開始されれば、DHCP サーバを使って自動設定によるネットワーク接続のポーリングが開始されるでしょう。

[[awesome]] などの XDG 非互換のウィンドウマネージャで GNOME のアプレットを開始するには:

nm-applet --sm-disable &

固定 IP アドレスの場合は、NetworkManager にそのことを伝えなければなりません。手順としては通常、アプレットを右クリックし、'接続を編集する' ('Edit Connections') などのような項目を選択します。

== ヒントとテクニック ==

=== Wi-Fi パスワードの暗号化 ===

デフォルトでは、NetworkManager はパスワードを平文で {{ic|/etc/NetworkManager/system-connections/}} 内の設定ファイルに保存します。保存されているパスワードを表示するには、以下のコマンドを使ってください:

# grep -r '^psk=' /etc/NetworkManager/system-connections/

パスワードは root ユーザからファイルシステムでアクセス可能であり、さらに GUI (例: {{ic|nm-applet}}) を通して設定にアクセスできるユーザからもアクセス可能です。

パスワードは、平文ではなく、キーリングの中で暗号化された形で保存するのが望ましいです。しかし、これの欠点は、それぞれのユーザで接続をセットアップしなけれならないことです。

キーリングを読み書きするために、利用可能なシークレットエージェントが存在していなければなりません。いかのどれかを使用できます:

* {{ic|nmcli}} で {{ic|--ask}} オプションを使う。
* [[#フロントエンド]] に挙げられているグラフィカルインターフェイス

シークレットエージェントが利用できないと、{{ic|no secrets: No agents were available for this request.}} というエラーで認証が失敗します。

==== GNOME Keyring を使う ====

以下の方法を使うには、GNOME Keyring のキーリングデーモンが開始されていて、キーリングがアンロックされている必要があります。

さらに、全ユーザのパスワードを保存しないように NetworkManager を設定する必要があります。GNOME の {{Pkg|network-manager-applet}} を使って、ターミナルから {{ic|nm-connection-editor}} を実行し、ネットワーク接続を選択し、''編集'' (''Edit'') をクリックし、''Wi-Fi セキュリティー'' (''Wi-Fi Security'') タブを選択し、パスワード入力欄の右のアイコンをクリックして、''このユーザーのパスワードのみ保存する'' (''Store the password only for this user'') にチェックを入れてください。

==== KDE Wallet を使う ====

KDE の {{Pkg|plasma-nm}} を使う場合、アプレットをクリックし、右上の ''設定'' アイコンをクリックし、ネットワーク接続を選択し、''一般設定'' (''General configuration'') タブを選択し、''すべてのユーザはこのネットワークに接続可能'' (''All users may connect to this network'') のチェックを外してください。このオプションにチェックが入っていると、たとえキーリングデーモンが実行されていたとしても、パスワードが平文で保存されてしまいます。

以前このオプションにチェックが入っていて、後にチェックを外した場合、ファイルからパスワードを消すために {{ic|reset}} オプションを使用する必要がある場合があります。あるいは、接続を削除し、再度セットアップしてください。

=== Wi-Fi でインターネット接続を共有する ===

数クリックでインターネット接続 (例: 3G、有線) を共有することができます。ただし、[[ファイアウォール]]はインターネット共有を妨害する場合があることに注意してください。

AP モードをサポートする Wi-Fi カードが必要になります。詳細は [[ソフトウェアアクセスポイント#Wi-Fi デバイスが AP モードをサポートしていること]] を見てください。

接続を共有できるようにするために {{Pkg|dnsmasq}} パッケージを[[インストール]]してください。NetworkManager は ({{ic|dnsmasq.service}} とは独立に) 独自の ''dnsmasq'' インスタンスを DHCP サーバとして開始することに注意してください。これに関する注意事項は [[#dnsmasq]] を見てください。

共有された接続を作成してください:

* アプレットをクリックし、''新規 Wi-Fi ネットワークを作成'' (''Create new wireless network'') を選んでください。
* ウィザードに従ってください (WPA2 以上を選んでください。パスワードは 8 文字以上にしてください。さもないと失敗します)。
* Wi-Fi モードとして[[Fedora:Features/RealHotspot|ホットスポット]]かアドホックを選択してください。

これで、次回必要になるときのために接続は保存されます。

{{Note|Android はアドホックネットワークへの接続をサポートしていません。Android と接続を共有するには、インフラストラクチャモードを使用してください (つまり、Wi-Fi モードを "ホットスポット" に設定する)。}}

=== イーサネットでインターネット接続を共有する ===

シナリオ: デバイスが Wi-Fi 経由でインターネットに接続されていて、イーサネットで他のデバイスとインターネット接続を共有したいと考えている場合。

要件:

* 接続を共有できるようにするために {{Pkg|dnsmasq}} パッケージと {{Pkg|nm-connection-editor}} パッケージを[[インストール]]してください。NetworkManager は ({{ic|dnsmasq.service}} とは独立に) 独自の ''dnsmasq'' インスタンスを DHCP サーバとして開始することに注意してください。これに関する注意事項は [[#dnsmasq]] を見てください。
* インターネットに接続されたデバイスとその他のデバイスが適切なイーサネットケーブルで接続されていること (これは通常、間をクロスオーバーケーブルやスイッチで繋ぐことを意味します)。
* インターネット共有が[[ファイアウォール]]によってブロックされていないこと。

手順:

* ターミナルから {{ic|nm-connection-editor}} を実行してください。
* 新しいイーサネット接続を追加してください。
* 何かわかりやすい名前を付けてください。例えば "Shared Internet"。
* "IPv4 設定" ("IPv4 Settings") を開いてください。
* "メソッド:" ("Method:") で "他のコンピューターへ共有" ("Shared to other computers") を選択してください。
* 保存

これで、NetworkManager の有線接続に "Shared Internet" という新しいオプションができたはずです。

=== cron ジョブやスクリプトでネットワークが立ち上がっているか確認する ===

{{Out of date|''nm-tool'' は NetworkManager から削除されました [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/bb8c75bd536d4f8fb80a4366025a279078f0ec81]。代わりに ''nmcli'' を使用するべきです。}}

一部の ''cron'' ジョブではネットワークが立ち上がっている必要があり、ネットワークが落ちている状態でそのようなジョブを実行したくない場合があります。そうするには、NetworkManager の ''nm-tool'' にクエリして、ネットワークの状態をチェックする '''if''' テストを追加してください。このテストは、何らかのインターフェイスが立ち上がっていれば成功し、インターフェイスが全て落ちている場合は失敗します。これは、ある時は有線接続されていて、ある時は無線で、またある時はネットワークから切断されているようなノート PC で便利です。

{{bc|<nowiki>
if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then
# ネットワークがオンラインの時に実行したいコード
else
# ネットワークがオフラインの時に実行したいコード (注記: この部分と上の else は任意です)
fi
</nowiki>}}

これは、例えば F-Prot ウイルススキャナのシグネチャを更新するために ''fpupdate'' を実行する {{ic|cron.hourly}} で便利です。また、''nm-tool'' の出力の様々な部分を使えば、ネットワークを識別することもできます。例えば、アクティブなワイヤレスネットワークにはアスタリスクが付くので、ネットワーク名を grep して、その後でアスタリスクを grep しますs。

=== ブート時にシークレットを使ってネットワークに接続する ===

デフォルトでは、NetworkManager はシークレットを要求するネットワークにはブート時に自動的に接続しません。NetworkManager では、そのようなネットワークは、そのネットワークをデフォルトで使用するユーザがログインした後にのみ、接続されるからです。この動作を変更するには、以下を行ってください:

# パネルの {{ic|nm-applet}} のアイコンを右クリックし、"接続を編集する" を選択し、Wi-Fi タブを開いてください。
# 使いたい接続を選択し、編集ボタンをクリックしてください。
# “Connect Automatically” と “Available to all users” のボックスにチェックを入れてください。
# 加えて、"Wi-Fi Security" タブで "Store password for all users (not encrypted)" が選択されていることを確認してください。

ログアウトし、ログインし直せば完了です。

=== OpenConnect で KWallet 内のパスワードを使う ===

接続時にユーザ名とパスワードを入力することはできますが、{{Pkg|plasma-nm}} 0.9.3.2-1 から、[[KWallet]] から直接 OpenConnect のユーザ名とパスワードを取得することが可能になりました。

"KDE Wallet Manager" を開き、"Network Management|Maps" で対象の OpenConnect VPN 接続を見つけてください。"Show values" をクリックし、認証情報を以下の形式で "VpnSecrets" に入力してください (''ユーザ名'' と ''パスワード'' の部分は適宜置き換えてください):

form:main:username%SEP%''ユーザ名''%SEP%form:main:password%SEP%''パスワード''

次回の接続時に、ユーザ名とパスワードが "VPN secrets" ダイアログボックスに入力されるはずです。

=== 特定のデバイスを無視する ===

NetworkManager で特定のデバイスを無視し、そのデバイスに対してはアドレスとルート (route) の設定を試みないようにすることが望ましい場合があります。{{ic|/etc/NetworkManager/conf.d/unmanaged.conf}} で以下のオプションを使うことで、MAC またはインターフェイス名によって特定のデバイスを無視することができます:

[keyfile]
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0

ファイルを編集したら、{{ic|nmcli general reload}} を root として実行してください。その後、NetworkManager があなたの設定を変更することなく、インターフェイスを構成できるようになっているはずです。

=== MAC アドレスのランダム化を設定する ===

{{Note|1=(安定した) リンク接続[https://bbs.archlinux.org/viewtopic.php?id=220101]や、MAC アドレスに基づいてデバイスを制限したりネットワーク容量に制限を設けているネットワークへの接続には、MAC アドレスのランダム化を無効化する必要がある場合があります。}}

MAC アドレスのランダム化は、本物の MAC アドレスをネットワークに開示しないことで、プライバシーを向上させることができます。

NetworkManager は2種類の MAC アドレスランダム化をサポートしています: スキャン中のランダム化とネットワーク接続におけるランダム化です。どちらのモードも、{{ic|/etc/NetworkManager/NetworkManager.conf}} を変更するか、{{ic|/etc/NetworkManager/conf.d/}} 内に別の設定ファイルを作成することで設定できます (前者は NetworkManager によって上書きされる場合があるので、後者が推奨されます)。

Wi-Fi スキャン中のランダム化はデフォルトで有効化されていますが、以下の行を {{ic|/etc/NetworkManager/NetworkManager.conf}} か {{ic|/etc/NetworkManager/conf.d}} 内の別の設定ファイルに追加することで無効化することができます:

{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=
[device]
wifi.scan-rand-mac-address=no
}}

ネットワーク接続における MAC アドレスランダム化は、無線インターフェイスとイーサネットインターフェイスで別々のモードを設定することができます。モードに関する詳細は [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME のブログ記事]を参照してください。

MAC アドレスランダム化に関して、最も重要なモードは {{ic|stable}} と {{ic|random}} です。{{ic|stable}} は、新しいネットワークに接続した時にランダムな MAC アドレスを生成し、そのネットワークと MAC アドレスを永続的に関連付けます。これはつまり、そのネットワークに接続すると毎回同じ MAC アドレスが使用されることを意味します。それとは対照的に、{{ic|random}} は、ネットワークに接続する度に、そのネットワークが新しかろうが既知であろうが、新しい MAC アドレスを生成します。{{ic|/etc/NetworkManager/conf.d}} 内に設定ファイルを追加してこの MAC アドレスランダム化を設定することができます:

{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=
[device-mac-randomization]
# "yes" は既にスキャンにおけるデフォルトです。
wifi.scan-rand-mac-address=yes

[connection-mac-randomization]
# 全てのイーサネット接続に対して MAC をランダム化する
ethernet.cloned-mac-address=random
# 各 Wi-Fi に対してランダムな MAC を生成し、それらを関連付ける。
wifi.cloned-mac-address=stable
}}

特定の接続に対して MAC ランダム化を設定するには (例えば、そのネットワークでランダムな MAC アドレスを使えない場合)、[[#接続を編集する|接続を編集して]] {{ic|802-11-wireless.cloned-mac-address}} に所望のモード (例: {{ic|stable}}、{{ic|random}}) を設定してください。

詳細は [https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ GNOME ブログ記事]を参照してください。

=== ホスト名の送信をオフにする ===

デフォルトでは、NetworkManager は DHCP サーバにホスト名を送ります。

DHCP サーバへのホスト名の送信をグローバルに無効化するには、{{ic|/etc/NetworkManager/conf.d/}} 内の設定ファイルで2つのオプション {{ic|ipv4.dhcp-send-hostname{{=}}0}} と {{ic|ipv6.dhcp-send-hostname{{=}}0}} を設定してください。例:

{{hc|/etc/NetworkManager/conf.d/dhcp-send-hostname.conf|2=
[connection]
ipv4.dhcp-send-hostname=0
ipv6.dhcp-send-hostname=0
}}

特定の接続においてのみ DHCP サーバへのホスト名の送信を無効化するには (あるいは、グローバルに無効化しておいて、特定の接続では有効化するには)、以下をネットワーク接続ファイルに追加してください:

{{hc|/etc/NetworkManager/system-connections/''your_connection_file''.nmconnection|2=
...
[ipv4]
dhcp-send-hostname=false
...
[ipv6]
dhcp-send-hostname=false
...
}}

{{Note|デフォルトでは、[[#DHCP クライアント|内部 DHCP クライアント]]のみがこれらのオプションに従います。NetworkManager を dhcpcd と共に使用する際にホスト名の送信を省略するには、{{ic|/etc/dhcpcd.conf}} を編集して最後の行に {{ic|anonymous}} を挿入してください。}}

=== IPv6 プライバシー拡張を有効にする ===

[[IPv6#NetworkManager]] を参照してください。

=== 接続ごとに一意の DUID を設定する ===

DHCPv6 Unique Identifier (DUID) は、DHCPv6 クライアントが DHCPv6 サーバに対して自身を識別するために使用する値です。NetworkManager は3種類の DUID をサポートしています:

* DUID-UUID ([[RFC:6355|RFC 6355]]): Universally Unique IDentifier (UUID) から生成されます。
* DUID-LL ([[RFC:3315|RFC 3315]]): リンク層アドレス (別名 MAC アドレス) から生成されます。
* DUID-LLT ([[RFC:3315|RFC 3315]]): リンク層アドレスとタイムスタンプから生成されます。

NetworkManager の内部 DHCP クライアントが使用されている場合 (デフォルト)、machine-id ({{ic|/etc/machine-id}}) から生成されたグローバルで永続的な DUID-UUID で自身を識別します。これは、すべての接続が同じ UUID を共有することを意味し、プライバシーの侵害となる可能性があります。

幸いなことに、NetworkManager は、接続の stable-id とホストごとの一意のキーから派生した、接続ごとの一意の DUID を提供できます。{{ic|/etc/NetworkManager/conf.d}} 内に次の設定を追加することで、これを有効にすることができます:

{{hc|/etc/NetworkManager/conf.d/duid.conf|2=
[connection]
ipv6.dhcp-duid=stable-uuid
}}

{{ic|stable-ll}} および {{ic|stable-llt}} の値もサポートされています。詳細については、{{man|5|nm-settings|ipv6 setting}} の {{ic|dhcp-duid}} の説明を参照してください。

=== 有線接続の操作 ===

NetworkManager は、デフォルトで、有線イーサネット接続を検出するたびにそれぞれに対して接続プロファイルを生成します。接続を生成する時点では、利用可能なイーサネットアダプターがさらにあるかどうかはわかりません。そのため、最初の有線接続は "有線接続 1" となります。{{ic|no-auto-default}} ({{man|5|NetworkManager.conf}} を参照) を設定するか、単に削除することで、この接続を生成しないようにできます。そうすれば、NetworkManager はこのインターフェイスの接続を二度と生成しないように記憶します。

また、接続を編集 (およびディスクに永続化) したり、削除したりすることもできます。NetworkManager は新しい接続を再生成することはありません。それから、名前を好きなものに変更することができます。この作業には {{Pkg|nm-connection-editor}} などを使うことができます。

=== Wi-Fi バックエンドとして iwd を使用する ===

{{Note|1=<nowiki/>
* {{ic|iwd.service}} を有効化したり、[[iwd]] を手動で構成したりしないでください。NetworkManager は自身で iwd を開始し、管理します。
* ''iwd'' に切り替える前に、[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=iwd 既知の問題]を考慮してください。}}

[https://archive.kernel.org/oldwiki/iwd.wiki.kernel.org/networkmanager.html 実験的な iwd バックエンド]を有効化するには、{{Pkg|iwd}} を[[インストール]]してから、以下の設定ファイルを作成してください:

{{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=
[device]
wifi.backend=iwd
}}

または、{{AUR|networkmanager-iwd}} をインストールすることもできます。これは、''iwd'' のみで動作する ''NetworkManager'' をビルドするように設定された修正パッケージです。主な違いは、''iwd'' が必要であり、''wpa_supplicant'' はビルド後にアンインストールできることです。

{{Note|1=''iwd'' に切り替えた後、[https://archive.kernel.org/oldwiki/iwd.wiki.kernel.org/networkmanager.html#converting_network_profiles 既存の NetworkManager ネットワークプロファイルを変換する]必要がある場合があります。}}

=== ネットワーク名前空間内で実行する ===

ネットワーク名前空間内で NetworkManager を実行する場合 (たとえば、選択したアプリケーションで使用する必要がある特定のデバイスを管理する場合)、その名前空間に移動させる前にデバイスを落としてください:

$ ip link set dev ''MY_DEVICE'' down
$ ip link set dev ''MY_DEVICE'' netns ''MY_NAMESPACE''
$ ip netns exec ''MY_NAMESPACE'' NetworkManager
...
$ ip netns exec ''MY_NAMESPACE'' killall NetworkManager

そうしないと、NetworkManager は後で {{ic|device is strictly unmanaged}} エラーにより接続の確立に失敗します。

=== VPN に自動的に接続する ===

NetworkManager は、インターネットへの接続時に VPN に自動的に接続するように (ネットワーク毎に) 設定できます。VPN 接続自体は、GNOME の NetworkManager フロントエンドで追加できますが、VPN を自動的に使用するようにするには、{{ic|nmcli}} を使用しなければなりません。他のフロントエンドにはこの制限はない場合があります。

まず、対象の VPN が全ユーザで利用可能であることを確認してください。GNOME では、{{ic|details}} タブ内のあるボックスにチェックを入れれば良いです。{{ic|Identity}} タブのパスワード入力欄内の右側にあるアイコンをクリックし、{{ic|Store the password for all users}} を選択してください。

そして、VPN 接続の UUID を見つけ、インターネット接続の {{ic|connection.secondaries}} にその UUID を追加してください:

# UUID=$(nmcli --get-values connection.uuid connection show ''VPN接続の名前'')
# nmcli connection modify ''インターネット接続の名前'' connection.secondaries "$UUID"

NetworkManager を再起動して、設定したインターネット接続に接続したら、自動的に VPN に接続されるようになっているはずです。

== トラブルシューティング ==

=== セキュアな Wi-Fi ネットワークのパスワードプロンプトが表示されない ===

セキュアな Wi-Fi ネットワークに接続しようとすると、パスワードのプロンプトが表示されず、接続が確立されません。これは、キーリングのパッケージがインストールされていない時に起こります。簡単な解決法は、{{Pkg|gnome-keyring}} をインストールすることです。パスワードを暗号化して保存したい場合は、[[GNOME Keyring]] に書かれてある指示に従い、''gnome-keyring-daemon'' をセットアップしてください。

=== Network management disabled ===

時々、NetworkManager を終了したときに pid (state) ファイルが削除されずに {{ic|Network management disabled}} というメッセージが表示されることがあります。これが発生した場合は、そのファイルを手動で削除してください:

# rm /var/lib/NetworkManager/NetworkManager.state

=== 内蔵 DHCP クライアントに関する問題 ===

内臓の DHCP クライアントを使用すると IP アドレスの取得に問題が発生する場合、他の DHCP クライアントを使用することを検討してください (手順は [[#DHCP クライアント]] を見てください)。この回避策は、eduroam などの巨大なワイヤレスネットワークにおける問題を解決するかもしれません。

=== dhclient における DHCP の問題 ===

DHCP での IP アドレス取得に問題が発生する場合、以下を {{ic|/etc/dhclient.conf}} に追加してみてください:

interface "eth0" {
send dhcp-client-identifier 01:''aa:bb:cc:dd:ee:ff'';
}

{{ic|''aa:bb:cc:dd:ee:ff''}} は NIC の MAC アドレスです。この MAC アドレスは {{Pkg|iproute2}} パッケージの {{ic|ip link show ''インターフェイス''}} コマンドを使って確認できます。

=== 3G モデムが検知されない ===

[[USB 3G モデム#NetworkManager]] を参照してください。

=== ノートパソコンで WLAN をオフにする ===

時々、ノートパソコンに付いているスイッチを使って Wi-Fi アダプタを無効化し、再び有効化しようとすると NetworkManager が機能しなくなることがあります。これは、しばしば ''rfkill'' の問題であることがあります。ドライバが ''rfkill'' にワイヤレスアダプタの状態について通知しているかどうか確認するには、以下のコマンドを使ってください:

$ watch -n1 rfkill list all

アダプタを切り替えた後にどれかの識別子がブロックされたままになる場合、手動でアンロックしてみることができます (X の部分は、上記のコマンドで得られた識別子の番号です):

# rfkill event unblock X

=== 固定 IP アドレスの設定が DHCP に戻る ===

とある未解決のバグにより、デフォルトの接続を固定 IP アドレスに変更すると、{{ic|nm-applet}} が設定の変更を適切に保存せずに、自動 DHCP に戻ってしまいます。

この問題を回避するには、{{ic|nm-applet}} でデフォルトの設定 (例: "Auto eth0") を編集し、接続名を変更 (例: "my eth0") し、"Available to all users" チェックボックスのチェックを外し、固定 IP アドレスの設定を好きに変更し、'''Apply''' をクリックしてください。これで、指定した名前で新しい接続が保存されます。

そうしたら、デフォルトの接続に自動的に接続しないようにしたいと思うでしょう。そうするには、まず {{ic|nm-connection-editor}} を実行してください (root としてでは'''ありません''')。接続エディタで、デフォルトの接続 (例: "Auto eth0") を編集し、"Connect automatically" のチェックを外してください。'''Apply''' をクリックし、接続エディタを閉じてください。

=== 通常ユーザとして接続を編集できない ===

[[#PolicyKit のパーミッションをセットアップする]] を参照してください。

=== 隠されたワイヤレスネットワークを削除する ===

隠されたネットワークはワイヤレスの選択リストに表示されないので、GUI から削除することができません。以下のコマンドでそのようなネットワークを削除できます:

# rm /etc/NetworkManager/system-connections/''SSID''.nmconnection

これは、他の接続でも使えます。

=== VPN が GNOME で動作しない ===

GNOME を使用している時に NetworkManager で OpenConnect や vpnc の接続をセットアップすると、ダイアログボックスが表示されず、以下のエラーが {{ic|/var/log/errors.log}} に現れることがあります:

localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.

これは、GNOME NetworkManager Applet が、ダイアログスクリプトが {{ic|/usr/lib/gnome-shell}} にあると想定していることが原因です (NetworkManager のパッケージはダイアログスクリプトを {{ic|/usr/lib/networkmanager}} 内に置きます)。"一時的な" 修正として (このバグはしばらく前から存在しています)、以下のシンボリックリンクを作成してください:

* OpenConnect の場合: {{ic|ln -s /usr/lib/nm-openconnect-auth-dialog /usr/lib/gnome-shell/}}
* VPNC (つまり Cisco VPN) の場合: {{ic|ln -s /usr/lib/nm-vpnc-auth-dialog /usr/lib/gnome-shell/}}

これは、他の NetworkManager VPN プラグインでも行う必要がある場合がありますが、上記が最も一般的です。

=== 検出されてはいるのにヨーロッパのワイヤレスネットワークに接続できない ===

WLAN チップにはデフォルトの[[ネットワーク設定/ワイヤレス#規制範囲に従う|規制範囲]]が設定されています。アクセスポイントがその規制内で動作しない場合、そのネットワークに接続することはできません。これは簡単に解決できます:

# {{Pkg|wireless-regdb}} を[[インストール]]してください。
# {{ic|/etc/conf.d/wireless-regdom}} で適切な国名コードをアンコメントしてください。
# システムを再起動してください。この設定はブート時にしか読み込まれないからです。

=== ブート時の VPN への自動接続が機能しない ===

この問題は、システム (つまり、root ユーザとして動作している NetworkManager) が VPN 接続を確立しようと試みたが、パスワードが特定のユーザの GNOME Keyring 内に保存されているためにアクセスできなかった場合に発生します。

解決策は、[[#ディスパッチャを使って、ネットワーク接続が確立された後に VPN に接続する]] の手順 2 で説明されている通りに、VPN のパスワードを平文で保存することです。

{{ic|nm-applet}} GUI で新しい "auto-connect VPN" オプションを使用している場合は、自動接続するために手順 1 で説明されているディスパッチャを使用する必要はありません。

=== systemd のボトルネック ===

時が立つにつれてログファイル ({{ic|/var/log/journal}}) が膨大になってしまうことがあります。そうすると NetworkManager を使う場合にブートパフォーマンスに大きな影響を与えます。参照: [[systemd#少しづつ起動時間が長くなっている]]。

=== 定期的なネットワーク接続断、遅延、パケットロス (Wi-Fi) ===

NetworkManager は2分ごとにスキャンを行います。

一部の Wi-Fi ドライバは、接続/アソシエーション中にベースステーションのスキャンを行うと問題が発生します。症状としては、VPN 接続断/再接続、パケットロス、ウェブページのロードに失敗してリフレッシュすると良くなるなどがあります。

{{ic|journalctl -f}} を root として実行すると、スキャンが行われていることがわかります。以下のようなメッセージが定期的にログに現れます:

NetworkManager[410]: <info> (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))

ローミングが重要でないならば、Wi-Fi 接続プロファイルでアクセスポイントの BSSID をロックすることにより、定期的なスキャンの挙動を無効化することができます。

=== Lenovo ラップトップ (IdeaPad、Legion など) で Wi-Fi をオンにできない ===

これは、Wi-Fi ドライバがソフトブロックを誤って報告することによる、一部の Lenovo モデルにおける {{ic|ideapad_laptop}} モジュールの問題です。カードは依然として {{ic|netctl}} で操作できますが、NetworkManager などのマネージャーは機能しません。この問題が発生しているかどうかを確認するには、ハードウェアのスイッチをオンオフしたあとで {{ic|rfkill list}} の出力を確認し、ソフトブロックされ続けるかどうか確認してください。

{{Accuracy|rfkill の問題を解決するには、{{ic|rfkill.default_state}} と {{ic|rfkill.master_switch_mode}} を使用してみてください ([https://docs.kernel.org/admin-guide/kernel-parameters.html kernel-parameters.html] を参照))。}}

{{ic|ideapad_laptop}} モジュールを[[modprobe|アンロード]]すれば、この問題は解決するはずです。('''警告''': これにより、ラップトップのキーボードとタッチパッドも無効になる可能性があります!)

=== nm-applet が i3wm で消える ===

通知に {{ic|xfce4-notifyd.service}} を使用する場合は、そのユニットを[[編集]]して、以下を追加する必要があります:

{{hc|/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf|2=
[Service]
Environment="DISPLAY=:0.0"
}}

デーモンをロードし直したら、{{ic|xfce4-notifyd.service}} を[[再起動]]してください。i3 を終了し、再び起動すると、アプレットがトレイに表示されているはずです。

=== Unit dbus-org.freedesktop.resolve1.service not found ===

{{ic|systemd-resolved.service}} が開始されていない場合、NetworkManager は D-Bus を使用して開始しようとし、失敗します:

dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")

これは、NetworkManager が {{man|5|NetworkManager.conf}} の {{ic|1=main.dns=}} 設定に関係なく、DNS 情報を [[systemd-resolved]] に送信しようとするためです。[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383]

これは、{{ic|/etc/NetworkManager/conf.d/}} 内の設定ファイルで無効にできます:

{{hc|/etc/NetworkManager/conf.d/no-systemd-resolved.conf|2=
[main]
systemd-resolved=false
}}

{{Bug|62138}} を参照してください。

=== Secrets were required, but not provided ===

ネットワークに接続しようとして以下のエラーが発生する場合:

{{hc|$ nmcli device wifi connect ''SSID'' password ''パスワード''|
Error: Connection activation failed: (7) Secrets were required, but not provided
}}

このエラーの原因となりうるものはたくさんあり、[[journal]] を読む必要があります ({{ic|-u NetworkManager}} で出力をフィルタしてください)。例えば、接続の確立に時間がかかりすぎると、NetworkManager はパスワードが正しくなかったと結論づけます:

{{bc|
NetworkManager[1372]: <warn> [1643991888.3808] device (wlan0): Activation: (wifi) association took too long
NetworkManager[1372]: <info> [1643991888.3809] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
NetworkManager[1372]: <warn> [1643991888.3838] device (wlan0): Activation: (wifi) asking for new secrets
}}

接続プロファイルを削除し、新しいプロファイルを作成してみてください:

$ nmcli connection delete ''SSID''
$ nmcli device wifi connect ''SSID'' password ''パスワード''

また、MAC アドレスランダム化を無効化してみるのも良いでしょう:

{{hc|/etc/NetworkManager/conf.d/wifi_rand_mac.conf|2=
[device]
wifi.scan-rand-mac-address=no
}}

=== iwd での WPA Enterprise 接続 ===

[[#Wi-Fi バックエンドとして iwd を使用する|iwd バックエンド]]と NetworkManager で 'eduroam' などの WPA Enterprise ネットワークに接続しようとした際に、NetworkManager sで以下のエラーが発生します:

Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)

NetworkManager は WPA Enterprise ネットワークを設定できないことが原因です。なので、[[iwd#WPA Enterprise]] で説明されているように iwd の設定ファイル {{ic|/var/lib/iwd/''essid''.8021x}} を使って設定する必要があります。

=== Failed to request VPN secrets ===

以下のエラーが発生する場合:

Failed to request VPN secrets #1: No agents were available for this request.

パスワードが空であるか、[[#PolicyKit のパーミッションをセットアップする|PolicyKit のパーミッションをセットアップする]]必要があるかのどちらかです。

=== OpenVPN 接続が "secrets: failed to request VPN secrets" という警告で失敗する ===

GNOME-Shell と統合させる場合、{{Pkg|networkmanager-openvpn}} パッケージは {{Pkg|libnma-gtk4}} と任意で {{Pkg|libnma}} (Gtk3) も必要とします。{{Pkg|libnma}} が必要であるが、インストールされていない場合、以下のようなメッセージがログに出力されます:

{{bc|
NetworkManager[642]: <warn> [...] vpn[..."name_of_vpn_profile VPN"]: secrets: failed to request VPN secrets #3: No agents were available for this request.
}}

=== OpenSSL の "ca md too weak" エラーで OpenVPN の接続に失敗する ===

{{Pkg|openssl}} がバージョン3に更新されたため、レガシーな暗号化アルゴリズムで生成された証明書はデフォルトで拒否されます。このような設定で {{Pkg|networkmanager-openvpn}} を使用しようとすると、ログに次のエラーが記録される可能性があります:

{{bc|
nm-openvpn[14359]: OpenSSL: error:0A00018E:SSL routines::ca md too weak
nm-openvpn[14359]: Cannot load certificate file /home/archie/.local/share/networkmanagement/certificates/my_issued_cert.crt
nm-openvpn[14359]: Exiting due to fatal error
}}

正しいアプローチは、OpenVPN サーバの管理者に、より安全な証明書を生成して再発行してもらうことです。ただし、当面の回避策として、OpenVPN には {{ic|1=tls-cipher "DEFAULT:@SECLEVEL=0"}} が必要です。この設定は、プラグイン GUI からでは無理かもしれませんが、''nmcli'' からなら可能です。これとは別に、OpenSSL で''レガシー''なプロバイダを有効化する必要もあります。

まず、以下のコマンドの出力から、問題のある VPN 接続の名前を取得してください:

$ nmcli connection show

接続の名前は ''vpn.example.com'' であると仮定します。以下のように ''nmcli'' を使ってください:

$ nmcli connection modify vpn.example.com +vpn.data tls-cipher=DEFAULT:@SECLEVEL=0

変更は即座に {{ic|/etc/NetworkManager/system-connections/vpn.example.com.nmconnection}} に反映されるはずです。

OpenSSL に関しては、[https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers OpenSSL wiki] で説明されている通りに {{ic|/etc/ssl/openssl.cnf}} を編集してください。

具体的には、{{ic|[provider_sect]}} セクションの最後に {{ic|1=legacy = legacy_sect}} を追加してください。{{ic|[default_sect]}} で {{ic|1=activate = 1}} のコメントを外してください。最後に、{{ic|1=activate = 1}} という行も含む新しいセクション {{ic|[legacy_sect]}} を追加してください。他のほとんどの既存の構成セクションを除外すると、最終結果は次のようになります:

{{hc|/etc/ssl/openssl.cnf|2=
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1
}}

最後に、{{ic|NetworkManager.service}} を[[再起動]]して、新しい OpenSSL 設定を有効化してください。

=== OpenSSL の "unsupported protocol" エラーで WPA Enterprise の接続の認証に失敗する ===

{{Pkg|openssl}} がバージョン 3 に更新されたため、[https://www.openssl.org/news/openssl-3.0-notes.html デフォルトで] SSL 3、TLS 1.0、TLS 1.1、そして DTLS 1.0 はセキュリティレベル 0 でのみ動作するようになりました。それよりも古い標準しかサポートしていない Wi-Fi ネットワークでの認証は、ログに以下のエラーを吐いて失敗します:

{{bc|
wpa_supplicant[3320]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version
wpa_supplicant[3320]: OpenSSL: openssl_handshake - SSL_connect error:0A000102:SSL routines::unsupported protocol
wpa_supplicant[3320]: wlp3s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
}}

正しい方法は、設備の管理者を説得して、暗号化されたネットワークトンネルのプロトコルを TLS 1.3 にアップグレードし、任意で TLS 1.0/1.1、DTLS 1.0、SSL 1-3 を含む非推奨となっているセキュリティ標準のサポートを落としてもらうことです。しかし、当面の回避策として、TLS 1.0 や 1.1 をデフォルトで許可する方法は複数あります。一つは、手動で OpenSSL にパッチを当てるか、破壊的な変更をもとに戻すことです ([https://github.com/openssl/openssl/commit/7bf2e4d7f0c7ae19b7a8c416910886a7171e9820])。これは、OpenSSL レベル 1 を使用する他の全てのプログラムのセキュリティも低下してしまうため、推奨されません。代わりに、([https://bbs.archlinux.org/viewtopic.php?id=286417#p2104492 BBS#286417] で説明されているように) wpa_supplicant によって使用されるレベルを直接設定することができます。問題のある接続設定ファイルの {{ic|1=[802-1x]}} セクションで {{ic|1=phase1-auth-flags=32}} または {{ic|1=phase1-auth-flags=64}} を設定することで、その接続のみを変更できます。これは GUI からは無理かもしれませんが、''nmcli'' でなら可能です。

まず、以下のコマンドの出力から、問題のある Wi-Fi 接続の名前を手に入れてください:

$ nmcli connection show

この接続では TLS 1.0 が使用され、接続名は ''Example Wi-Fi'' であるとします。以下のように ''nmcli'' を使用してください:

$ nmcli connection modify 'Example Wi-Fi' 802-1x.phase1-auth-flags 32

TLS 1.1 接続に対しては、代わりに "64" を使用してください:

$ nmcli connection modify 'Example Wi-Fi' 802-1x.phase1-auth-flags 64

{{Note|1=ここで入力した数字は、2 の '''n''' 乗です。ただし、'''n''' はネットワーク認証ビットオクテットのインデックス (右から左に数えます) です。5番目のビットを1にすると TLS 1.0 が有効になり ('''[log(2) 32]''')、6番目のビットを1にすると TLS 1.1 が有効になります ('''[log(2) 64]''')。}}

変更は即座に {{ic|/etc/NetworkManager/system-connections/Example Wi-Fi.nmconnection}} に反映されるはずです。

最後に、{{ic|NetworkManager.service}} を[[再起動]]して、新しい OpenSSL の設定を有効化してください。

== 参照 ==

* [https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1/ NetworkManager for Administrators Part 1]

{{TranslationStatus|NetworkManager|2026-05-04|872001}}

Mkinitcpio

2026-05-03T10:19:57Z

AshMyzk: 同期

{{Lowercase title}}
[[Category:initramfs]]
[[Category:カーネル]]
[[Category:Arch プロジェクト]]
[[Category:コマンド]]
[[de:Mkinitcpio]]
[[en:Mkinitcpio]]
[[fr:Mkinitcpio]]
[[hu:Mkinitcpio]]
[[pt:Mkinitcpio]]
[[ru:Mkinitcpio]]
[[zh-hans:Mkinitcpio]]
{{Related articles start}}
{{Related|/Initramfs の最小化}}
{{Related|Booster}}
{{Related|ブートデバッグ}}
{{Related|カーネルモジュール}}
{{Related|ユニファイドカーネルイメージ}}
{{Related|dracut}}
{{Related articles end}}

[https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio mkinitcpio] は、[[initramfs]] イメージを作成するために使用される [[Bash]] スクリプトです。初期 RAM ディスクフェーズで行われる処理の実行方法については、2つあります:

; systemd ベースの初期 RAM ファイルシステム
: [[systemd]] は、初期 RAM ディスクフェーズの最初に起動されます。通常の systemd ユニットファイルによって、実行されるべき処理が決定されます。[https://www.freedesktop.org/software/systemd/man/latest/bootup.html systemd bootup process] を参照。
: '''長所''':
:* systemd エコシステムの他の部分と密接に統合されており、より一貫していて合理的なブートプロセスとなっています。
:* 特定のブート処理がより効率的に並列化されており、場合によっては全体的なブート時間がより早くなることがあります。
:* {{ic|/etc/crypttab.initramfs}} を使用する [[dm-crypt/システム設定#systemd-cryptsetup-generator を使う|systemd-cryptsetup-generator]] や [[Systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]]など、使用できる機能はより包括的です。
: '''短所''':
:* 依存関係が増え、サイズも増加します: 一般に、systemd 関連のバイナリや依存関係が含まれるため、initramfs のサイズは増加します。これにより、ブート時間がわずかに増加する可能性があります。
; Busybox ベースの初期 RAM ファイルシステム
: 実行すべきスクリプト (ランタイムフックと呼ばれます) を探すために初期 RAM ディスクのファイルシステムをスキャンする init スクリプトが開始されます。
: '''長所''':
:* 軽量で、サイズも小さく、依存関係も少ないです。
:* Init スクリプトとランタイムフックは、順番に実行されます。これにより、ブート中に問題が発生した際は、どのステップが原因なのかをより簡単に特定できます。

これらは、{{ic|/etc/mkinitcpio.conf}} 内の {{ic|HOOKS}} 配列に {{ic|systemd}} フックがあるかないかで決まります。詳細は [[#フックのリスト]] を参照してください。

''mkinitcpio'' は、Arch Linux の[https://archlinux.org/people/developers/ 開発者たち]とコミュニティによる貢献によって開発されています。

== インストール ==

{{Pkg|mkinitcpio}} パッケージは、[[カーネル#公式サポートカーネル|カーネル]]のパッケージの依存関係なので、ほとんどの環境では既に[[インストール]]されています。

== イメージ作成とアクティベーション ==

=== 自動生成 ===

カーネルがインストールまたはアップグレードされるたびに、[[pacman フック]]は {{ic|/etc/mkinitcpio.d/}} 内に保存される ''.preset'' ファイルを自動的に生成します。例えば、公式の安定版 {{Pkg|linux}} カーネルパッケージの場合は {{ic|linux.preset}} です。プリセットは、様々なパラメーターや出力ファイルの場所を手動で指定する手間を省き、初期 RAM ディスクイメージを作成するために必要な情報のリストです。デフォルトでは、以下の最初のイメージを作成する命令のみが含まれており、2つ目のイメージを作成するには[[#フォールバック initramfs の生成|明示的に有効化する]]必要があります:

# ''default'' RAM ディスクイメージ。このイメージの内容は、[[#設定|設定]]で指定されたディレクティブに従って生成されます。
# ''fallback'' RAM ディスクイメージ。作成時に ''autodetect'' フックがスキップされることを除いて上記と同じであるため、ほとんどのシステムをサポートするすべてのモジュールが含まれます。

プリセットを作成した後、pacman フックは、プリセットで提供された情報を使用してイメージを生成する ''mkinitcpio'' スクリプトを呼び出します。

{{Note|''.preset'' ファイルは、カーネルの更新後に initramfs を自動的に再生成するために使用されます。編集するときは注意してください。}}

=== 手動生成 ===

スクリプトを手動で実行するには、マニュアルページ {{man|8|mkinitcpio}} で手順を確認してください。特に、カーネルパッケージによって提供されるプリセットに基づく initramfs イメージを(再)生成するには、使用するプリセットを {{ic|-p}}/{{ic|--preset}} オプションで指定してください。例えば、{{Pkg|linux}} パッケージの場合、次のコマンドを使用してください:

# mkinitcpio -p linux

既存のすべてのプリセットに基づく initramfs イメージを(再)生成するには、{{ic|-P}}/{{ic|--allpresets}} スイッチを使用してください。これは通常、グローバルな[[#設定|設定]]の変更後にすべての initramfs イメージを再生成するために使用されます:

# mkinitcpio -P

ユーザーは、さまざまな構成で initramfs イメージをいくつでも作成できます。生成したいイメージは、それぞれの[[ブートローダー]]の設定ファイルで指定する必要があります。

=== 生成のカスタマイズ ===

ユーザーは、代替の設定ファイルを使用してイメージを生成できます。次の例では、{{ic|/etc/mkinitcpio-custom.conf}} に記述されている指示に従って初期 RAM ディスクイメージを生成し、{{ic|/boot/initramfs-custom.img}} として保存します。

# mkinitcpio --config /etc/mkinitcpio-custom.conf --generate /boot/initramfs-custom.img

現在実行中のカーネル以外のカーネルのイメージを生成する場合は、カーネルリリースバージョンをコマンドラインに追加してください。インストールされているカーネルリリースは {{ic|/usr/lib/modules/}} にあり、構文は各カーネルのコマンド {{ic|uname -r}} の出力と一致しています。

# mkinitcpio --generate /boot/initramfs-custom2.img --kernel 5.7.12-arch1-1

=== ユニファイドカーネルイメージ ===

''mkinitcpio'' は、それ自体または {{Pkg|systemd-ukify}} 経由で[[ユニファイドカーネルイメージ]] (UKI) を作成することができます。{{Pkg|systemd-ukify}} が存在しないか、{{ic|--no-ukify}} によって明示的に無効化されている場合、UKI は mkinitcpio 自体によって構築されます。この場合、''ukify'' の高度な機能は利用できません。

UKI 生成については [[ユニファイドカーネルイメージ]] を参照してください。

== 設定 ==

''mkinitcpio'' のプライマリ設定ファイルは、{{ic|/etc/mkinitcpio.conf}} です。ドロップインの設定ファイル (例: {{ic|/etc/mkinitcpio.conf.d/myhooks.conf}}) もサポートされています (ドロップインファイルは、mkinitcpio が {{ic|-c}}/{{ic|--config}} オプションと共に実行された場合や、{{ic|ALL_config}} を含んでいるプリセットを使用した場合には使用されません)。さらに、カーネルパッケージによって提供されるプリセット定義が {{ic|/etc/mkinitcpio.d}} ディレクトリにあります (例: {{ic|/etc/mkinitcpio.d/linux.preset}})。

ユーザーは、設定ファイルの中にある7つの変数を変更できます (詳細は {{man|5|mkinitcpio.conf|VARIABLES}} を見てください):

; {{ic|MODULES}}: ブートフックが実行される前にロードされるカーネルモジュール。
; {{ic|BINARIES}}: initramfs イメージに含める追加のバイナリ。
; {{ic|FILES}}: initramfs イメージに含める追加のファイル。
; {{ic|HOOKS}}: フックは初期 RAM ディスクで実行するスクリプトです。
; {{ic|COMPRESSION}}: initramfs イメージを圧縮する際に使用されます。
; {{ic|COMPRESSION_OPTIONS}}: {{ic|COMPRESSION}} のプログラムに渡す追加の引数。この設定の使用は推奨されません。''mkinitcpio'' は圧縮プログラムに対する特殊な要件を処理するため (例: xz には {{ic|1=--check=crc32}} を指定します)、誤って利用するとシステムが起動できなくなる可能性があります。
; {{ic|MODULES_DECOMPRESS}}: ロード可能なカーネルモジュールとファームウェアのファイルを解凍しておくか、もとの圧縮した状態のままにしておくかを設定します。

{{Note|
* システムが必要とする場合があるフックのいくつか ('''lvm2'''、'''mdadm_udev'''、'''encrypt''' など) は、デフォルトで有効化されて'''いません'''。これに関する指示は [[#HOOKS]] セクションを注意深く読んでください。
* バージョン 36 より前の ''mkinitcpio'' によって作成されたプリセットファイルでは、{{ic|ALL_config}} 変数が定義されており、この変数が存在しているとドロップインの設定ファイルが読み込まれません。ドロップインファイルを有効化するには、古いプリセットファイルにある {{ic|1=ALL_config="/etc/mkinitcpio.conf"}} 行をコメントアウトしてください。
}}

=== MODULES ===

{{ic|MODULES}} 配列では、何か他のことが行われる前にロードするモジュールを指定します。

モジュールの後ろに {{ic|?}} を付けると、モジュールが見つからなかったときでもエラーを投げません。これは、フックや設定ファイルにリストアップされたモジュールを含んでコンパイルするカスタムカーネルで有益かもしれません。

{{Note|
* Out-of-tree のファイルシステムを初期ユーザー空間でマウントするつもりであるならば (例えば、そのようなファイルシステムをルートファイルシステムとしてを使用する場合)、そのファイルシステムのモジュール ({{ic|zfs}} など) を {{ic|MODULES}} 配列に'''追加しておかなければなりません'''。
* '''encrypt''' や '''sd-encrypt''' を使用し、かつ ''mkinitcpio'' が実行されるシステムと生成されたイメージが使用されるシステムが異なる場合、システムの起動中に LUKS デバイスをアンロックするために必要なキーボードモジュールやファイルシステムを {{ic|MODULES}} 配列に追加する必要があります。例えば、使用するキーファイルが ext2 ファイルシステム上にあるが、''mkinitcpio'' が実行されたときには ext2 ファイルシステムがマウントされていなかった場合、{{ic|ext2}} を追加してください。詳細は [[Dm-crypt/システム設定#cryptkey]] を見てください。
* LUKS デバイスをアンロックするために USB 3 ハブのキーボードを使いたい場合、{{ic|usbhid xhci_hcd}} を追加してください。一部のノート PC では、搭載されているキーボードを使用するために {{ic|i2c_hid_acpi}} モジュールが必要です。
* ドッキングステーションに接続されているディスプレイを使用する場合、initrd の出力を見えるようにするためにあなたのグラフィックカードのモジュールを追加する必要があるかもしれません (例: ほとんどの Intel カードでは {{ic|i915}})。
}}

=== BINARIES と FILES ===

以下のオプションを使ってイメージにファイルを追加することができます。{{ic|BINARIES}} と {{ic|FILES}} はフックが実行される前に追加され、フックによって使用/提供されるファイルを上書きすることがあります。{{ic|BINARIES}} は標準の {{ic|PATH}} に自動で配置され、依存関係がパースされます。つまり必要なライブラリも全て追加されます。{{ic|FILES}} は''そのままの状態で''追加されます。例:

FILES=(/etc/modprobe.d/modprobe.conf)

BINARIES=(kexec)

{{ic|BINARIES}} と {{ic|FILES}} は両方とも [[Bash]] 配列です。なので、スペースで区切ることで複数のエントリを追加することができます。

=== HOOKS ===

{{ic|HOOKS}} 配列は、設定ファイルの中で最も重要な設定です。フックとは、initramfs イメージに何を追加するかが記述されている小さなスクリプトです。一部のフックには、通称ランタイムフックというものが付いており、これはデーモンを起動したり、スタックドブロックデバイスをアセンブルしたりといったスタートアップ機能を提供しています。

フックは名前で指定し、設定ファイル内の {{ic|HOOKS}} 配列に記述した通りの順番で実行されます。自分が何をしているのか理解していない限り、[[#フックのリスト|フックのリスト]]の推奨される順番に従うのが良いです。

ほとんどのシンプルな単一ディスク環境では、デフォルトの {{ic|HOOKS}} 設定で十分なはずです。ルートファイルシステムが、[[LVM]]、[[RAID]]、[[dm-crypt]] などといった、スタックドデバイスベースであったり、複数のデバイスにまたがる場合は、関連する wiki ページを見て必要な設定を調べて下さい。

==== ビルドフック ====

ビルドフック (インストールフックとも) とは、''mkinitcpio'' の実行中に bash シェルによって source されるシェルスクリプトファイルであり、通常、{{ic|build}} と {{ic|help}} という2つの関数を含んでいます。{{ic|build}} 関数には、initramfs イメージに追加すべきモジュール、バイナリ、その他のファイルが記述されています。これらのアイテムの追加を用意にする API ({{man|8|mkinitcpio}} にドキュメント化されています) が存在しています。{{ic|help}} 関数は、そのフックの機能と使用方法の短い説明文を出力します。

すべてのフックを一覧するには:

$ mkinitcpio -L

特定のフックのヘルプを出力するには ''mkinitcpio'' の {{ic|-H}}/{{ic|--hookhelp}} オプションを使って下さい、例えば:

$ mkinitcpio -H udev

ビルドフックは {{ic|/usr/lib/initcpio/install/}} にあり、カスタムのビルドフックは {{ic|/etc/initcpio/install/}} に置くことができます。

==== ランタイムフック ====

{{ic|HOOKS}} にあるビルドフックには、同じ名前のランタイムフックが付属している場合があります。ランタイムフックとは、initramfs フェーズで busybox の {{ic|ash}} シェルによって source されるシェルスクリプトです。これは、デーモンの起動、スタックドブロックデバイスのアセンブルといった、スタートアップ処理を担います。ビルドフックは、{{ic|add_runscript}} を呼び出すことで、対応するランタイムフックをインストールします。ランタイムフックには、複数の機能が含まれていることがあります:

ランタイムフックは {{ic|/usr/lib/initcpio/hooks/}} にあります。カスタムランタイムフックは {{ic|/etc/initcpio/hooks/}} に配置します。全てのランタイムフックには同じ名前のビルドフックが存在している必要があり、そのビルドフックは {{ic|add_runscript}} をコールしてランタイムフックをイメージに追加します。これらのファイルは初期ユーザ空間で busybox の ash シェルによって実行されます。cleanup フックを除いて全てのフックは {{ic|HOOKS}} 設定の順番で実行されます。ランタイムフックには複数の関数を含めることができます:

{{ic|run_earlyhook}}: API ファイルシステムがマウントされカーネルコマンドラインがパースされたときに、この名前の関数が実行されます。一般的に udev など初期ユーザ空間が始まったときに必要になる追加のデーモンはこの関数に置きます。

{{ic|run_hook}}: 初期のフックの後すぐに、この名前の関数が実行されます。一番一般的なフックポイントで、スタックブロックデバイスのアセンブリなどのオペレーションはここで行なって下さい。

{{ic|run_latehook}}: root デバイスがマウントされた後、この名前の関数が実行されます。root デバイスの後のセットアップや {{ic|/usr}} など他のファイルシステムのマウントなどに控えめに使われます。

{{ic|run_cleanuphook}}: できる限り最後に、この名前の関数が実行されます。設定ファイルの {{ic|HOOKS}} の順番とは逆に実行されます。これらのフックは初期のフックによって起動したデーモンのシャットダウンなど、最後のクリーンアップに使われます。

{{ic|run_cleanuphook}} を除き、これらの関数は、{{ic|HOOKS}} 配列に記述された、対応するビルドフックと同じ順番で実行されます。ランタイムフックは {{ic|/usr/lib/initcpio/hooks/}} に配置されており、カスタムのランタイムフックは {{ic|/etc/initcpio/hooks/}} に置くことができます。

{{Note|ランタイムフックは busybox init でのみ使用されます。systemd ベースの initramfs ({{ic|HOOKS}} 配列に {{ic|systemd}} が存在する場合) では、ランタイムフックは実行されず、代わりに systemd ユニットが使用されます。}}

==== ポストフック ====

ポストフックとは、署名などといった追加の処理を行うために、イメージが (再) 生成された後に実行されるシェルスクリプトです。

スクリプトには、以下の引数が以下の順番で渡されます:

# 使用された'''カーネル''' (一部の状況では空になる場合があります)
# 生成された '''initramfs イメージ'''
# (オプション) 生成された'''ユニファイドカーネルイメージ'''

さらに、以下の環境変数も設定されます:

{{ic|KERNELVERSION}}: カーネルの完全なバージョン
{{ic|KERNELDESTINATION}}: カーネルが起動されるために配置されるべきデフォルトの場所。

ポストフックは、{{ic|/usr/lib/initcpio/post/}} (パッケージによって提供されているフック) と {{ic|/etc/initcpio/post/}} (カスタムのフック) に置かれます。

==== フックのリスト ====

以下は、フックと、それらがイメージの作成とランタイムに与える影響をまとめた表です。

{| class="wikitable"
! busybox init !! systemd init !! [[#ビルドフック|ビルドフック]] !! [[#ランタイムフック|ランタイムフック]] (busybox init のみ)
|-
| {{C|'''base'''}} || {{Grey|''任意''}} || 全ての初期ディレクトリをセットアップし、基本のユーティリティとライブラリをインストールします。'''systemd''' フックを使用していない場合にこのフックは重要な busybox init を提供するので、何をしようとしているか理解していない限りはこのフックを常に1番最初に置いてください。

'''systemd''' フックを使用する際は、このフックは busybox のリカバリシェルを提供するだけなので、任意です。シェルを使用するには、'''base''' を有効化することに加え、{{ic|SYSTEMD_SULOGIN_FORCE{{=}}1}} を[[カーネルパラメータ]]に追加する必要があります。
| {{-}}
|-
| {{C|'''udev'''}} ||rowspan="3" {{C|'''systemd'''}} || イメージに udevd, udevadm, そして udev ルールの小さなサブセットを追加します。 || udev デーモンを起動して、カーネルからの uevent を処理します; デバイスノードを作成します。ブートプロセスの単純化として、必要なモジュールを明示的に指定する必要をなくすため、udev フックの使用が推奨されています。
|-
| {{C|'''usr'''}} || {{ic|/usr}} の分割パーティションのサポートを追加します。詳細は [[#/usr を別のパーティションに分割する]] を見てください。 || 本物のルートファイルシステムがマウントされた後に {{ic|/usr}} パーティションをマウントします。
|-
|-
| {{C|'''resume'''}} || ハイバネートイメージにカーネルのコンパイル時デフォルト以外の圧縮アルゴリズムを使用する際に復帰できるようにするために、{{ic|lzo}} と {{ic|lz4}} カーネルモジュールを (initramfs に) 追加します。{{ic|HibernateLocation}} UEFI 変数で指定されたハイバネートイメージから復帰できるようにするために {{man|8|systemd-hibernate-resume}} バイナリを追加します。|| "ハイバネート" (suspend to disk) 状態からの復帰を試みます。詳しい設定方法は [[ハイバネート]] を見てください。
|-
| {{C|'''btrfs'''}} || {{Grey|–}} || [[Btrfs]] を有効にして、Btrfs でフォーマットされた複数のデバイスを使用するために必要なモジュールを設定します。このフックを使うには、{{Pkg|btrfs-progs}} をインストールする必要があります。単一のデバイスで Btrfs を使うだけならこのフックは不要であり、{{ic|filesystems}} フックで十分です。 || udev フックが存在しないときに {{ic|btrfs device scan}} を実行してマルチデバイスの Btrfs root ファイルシステムを構築します。このフックを使うには {{Pkg|btrfs-progs}} パッケージが必要です。
|-
|colspan="2" {{C|'''autodetect'''}} || sysfs のスキャンによってモジュールのホワイトリストを作成して initramfs を小さくします。含まれているモジュールが正しく、欠けているものがないか確認してください。自動検知の利点を活かすためにこのフックは他の subsystem フックより前に実行してください。'autodetect' より前に置かれたフックは完全にインストールされます。 || {{-}}
|-
|colspan="2" {{C|'''microcode'''}} || Intel 及び AMD プロセッサ向けの[[マイクロコード]]早期アップデートファイルを未圧縮 initramfs イメージの先頭に埋め込みます。これは、利用可能であれば {{ic|/usr/lib/firmware/amd-ucode/}} と {{ic|/usr/lib/firmware/intel-ucode/}} にあるマイクロコードファイルを使用します。これらのファイルが利用できない場合は、{{ic|/boot/amd-ucode.img}} と {{ic|/boot/intel-ucode.img}} を展開して使用します。

'''autodetect''' フックがこのフックより前に実行される場合、イメージをビルドする際に使用したシステムに搭載されているプロセッサ向けのマイクロコードの早期アップデートファイルのみが追加されます。

このフックは、非推奨となっている {{ic|--microcode}} フラグと、プリセットファイルの {{ic|microcode}} オプションの機能を置き換えるものです。また、このフックによって、メインの initramfs イメージにマイクロコードのアップデートが埋め込まれるようになるため、マイクロコードを読み込む {{ic|initrd}} 行をブートローダーの設定に追加する必要が無くなります。
| {{-}}
|-
|colspan="2" {{C|'''modconf'''}} || {{ic|/etc/modprobe.d/}} と {{ic|/usr/lib/modprobe.d/}} から modprobe 設定ファイルをロードします。 || {{-}}
|-
|colspan="2" {{C|'''kms'''}} || [[カーネルモード設定#設定|KMS の早期開始]] を提供する GPU モジュールを追加します。加えて、一部のノート PC の LCD パネルに組み込まれているプライバシースクリーンに必要なモジュールも追加します。|| {{-}}
|-
|colspan="2" {{C|'''keyboard'''}} || キーボードデバイスに必要なモジュールを追加します。あなたが USB キーボードを使っていて、それを初期ユーザ空間で使う必要があるとき (暗号化のパスフレーズを入力したりインタラクティブシェルを使う場合) はこのフックを使って下さい。副作用としてキーボード以外の入力デバイス用のモジュールが追加されることがありますが、困ることはないはずです。

{{Note|異なるハードウェア構成で起動されるシステム(たとえば、外部キーボードと内部キーボードを備えたラップトップまたは [[Wikipedia:Headless computer|ヘッドレスシステム]]) の場合、起動時にキーボードを利用できるようにするために (例えば、{{ic|encrypt}} フックが使用されている場合に暗号化済みデバイスをアンロックするために)、このフックを '''autodetect''' の前に配置する必要があります。}}

| {{-}}
|-
| {{C|'''keymap'''}} ||rowspan="2" {{C|'''sd-vconsole'''}} || {{ic|/etc/vconsole.conf}} から initramfs に、指定した[[コンソールでのキーボード設定#永続的な設定|コンソールキーマップ]]を追加します。[[Dm-crypt/システム全体の暗号化|システム暗号化]]を使用する場合 (特にフルディスク暗号化) 、{{ic|1=encrypt}} フックよりも前に追加するようにしてください。 || 初期ユーザ空間で {{ic|/etc/vconsole.conf}} から指定されたキーマップをロードします。
|-
| {{C|'''consolefont'''}} || {{ic|/etc/vconsole.conf}} から initramfs に、指定した[[コンソールでのキーボード設定#永続的な設定|コンソールフォント]]を追加します。 || 初期ユーザ空間で {{ic|/etc/vconsole.conf}} から指定されたコンソールフォントをロードします。
|-
|colspan="2" {{C|'''block'''}} || ブロックデバイスのモジュールを追加します。'''autodetect''' フックがこのフックより前に実行される場合、このフックはシステム上で使用されているブロックデバイスのモジュールのみを追加します。例外は {{ic|ahci}}、{{ic|sd_mod}}、{{ic|usb_storage}}、{{ic|uas}}、{{ic|mmc_block}}、{{ic|nvme}}、{{ic|virtio_scsi}}、{{ic|virtio_blk}} モジュールで、これらは無条件に必ず追加されます。 || {{-}}
|-
| {{C|'''net'''}} || {{Grey|''未実装''}} || ネットワークデバイスに必要なモジュールを追加します。このフックを使うには {{Pkg|mkinitcpio-nfs-utils}} をインストールしなければなりません。詳細は [[#net を使う]] を見てください。 || NFS の root ファイルシステムの管理を提供します。
|-
| {{C|'''dmraid'''}} || {{Grey|''?''}} || fakeRAID root デバイスのサポートを提供します。これを使うには {{Pkg|dmraid}} をインストールする必要があります。コントローラがサポートしている場合、fakeRAID では ''mdadm_udev'' フックと一緒に [[mdadm]] を使うことが推奨されます。詳細は [[#RAID を使う]] を見てください。 || {{ic|dmraid}} を使用して fakeRAID ブロックデバイスを検索・構築します。
|-
|colspan="2" {{C|'''mdadm_udev'''}} || udev を使って RAID アレイの構築をサポートします。このフックを使うには {{Pkg|mdadm}} をインストールする必要があります。詳細は [[RAID#mkinitcpio を設定する]] を見てください。 || {{-}}
|-
| {{C|'''encrypt'''}} || {{C|'''sd-encrypt'''}} || {{ic|dm_crypt}} カーネルモジュールと {{ic|cryptsetup}} ツールをイメージに追加します。これを使うには {{Pkg|cryptsetup}} をインストールする必要があります。{{Note|暗号化されたデバイスを起動時にアンロックするための ''keyboard'' フックの注意書きや、ファイルをアンロックする際はファイルシステムについての [[#MODULES]] にある注意書きを見てください。}} || 暗号化された root パーティションを検知してアンロックします。設定については [[#ランタイムのカスタマイズ]] を見て下さい。
'''sd-encrypt''' については [[Dm-crypt/システム設定#sd-encrypt フックを使う]]を見てください。
|-
|colspan="2" {{C|'''lvm2'''}} || device mapper カーネルモジュールと {{ic|lvm}} ツールをイメージに追加します。これを使うには {{Pkg|lvm2}} をインストールする必要があります。ルートファイルシステムを [[LVM]] 上に置いている場合、このフックは必須です。 || {{-}}
|-
|colspan="2" {{C|'''filesystems'''}} || イメージに必要なファイルシステムモジュールを含めます。ファイルシステムモジュールを {{ic|MODULES}} で指定していない限りこのフックが'''必要'''になります。 || {{-}}
|-
|colspan="2" {{C|'''fsck'''}} || fsck バイナリとファイルシステム固有のヘルパーを追加し、マウント前にルードデバイスに対して fsck を実行できるようにします。'''autodetect''' フックの後ろにこのフックを追加した場合、root ファイルシステムのヘルパーだけが追加されます。このフックの使用は'''強く'''推奨されており、{{ic|/usr}} パーティションを分割する場合は必須です。このフックを含める場合、初期ユーザ空間でキーボードが動作することを保証するために必要なモジュールも追加することを強く推奨します。

このフックを使用するには、[[カーネルコマンドライン]]にパラメータ {{ic|rw}} を設定する必要があります ([https://bbs.archlinux.org/viewtopic.php?pid=1307895#p1307895 議論])。詳細は [[fsck#ブート時のチェック]] を見てください。
| {{-}}
|-
|colspan="2" {{C|'''acpi_override'''}} || {{ic|/usr/initcpio/acpi_override/}} と {{ic|/etc/initcpio/acpi_override/}} ディレクトリ内にある ACPI Machine Language (''.aml'') ファイルを未圧縮早期 initramfs イメージに追加します。そうすることで、カーネルがブートの非常に早い段階で ACPI テーブル (例えば [[DSDT]]) をオーバーライドできるようにします。[https://docs.kernel.org/admin-guide/acpi/initrd_table_override.html] || {{-}}
|}

{{Note|パッケージがカスタムのフックを提供していることがあるため、この表は完全ではありません。}}

=== COMPRESSION ===

カーネルは、initramfs の圧縮にいくつかの形式をサポートしています: {{Pkg|gzip}}、{{Pkg|bzip2}}、lzma ({{Pkg|xz}})、{{Pkg|xz}}、lzo ({{Pkg|lzop}})、{{Pkg|lz4}}、{{Pkg|zstd}}。mkinitcpio はデフォルトで zstd 圧縮イメージを使用します。mkinitcpio はデフォルトで、カーネル 5.9 及びそれ以降に対しては zstd 圧縮を、5.9 より前のカーネルバージョンに対しては gzip を使用します。

提供されている {{ic|mkinitcpio.conf}} には、さまざまな {{ic|COMPRESSION}} オプションがコメントアウトされています。別の圧縮方法に切り替える場合は、コメントを解除し、対応する圧縮ユーティリティがインストールされていることを確認してください。何も指定しない場合は、デフォルトのメソッドが使用されます。非圧縮イメージを作成する場合は、設定ファイルで {{ic|1=COMPRESSION='''cat'''}} を指定するか、コマンドラインで {{ic|-z cat}} を使用します。

{{Tip|
* lz4 と xz 圧縮ユーティリティはデフォルトでマルチスレッド化されており、zstd はマルチスレッドモードで実行されます ({{ic|-T0}} オプションが使用され、検出されたコアと同じ数のスレッドを作成しようと試みます)。
* lz4 は、高圧縮モード ({{ic|-9}}) のイメージの圧縮率は通常約2.5で、最速の解凍速度を達成しています。zstd は、マルチスレッド圧縮と、オプションによる幅広い圧縮レベルにより、多用途のソリューションを提供します - {{man|1|zstd|Operation Modifiers}} を参照。xz は、その高圧縮プリセット ({{ic|-9}}) で約5の縮小率により最小サイズを実現しますが、その代償として展開速度がかなり遅くなります。
}}

=== COMPRESSION_OPTIONS ===

{{ic|COMPRESSION}} で指定したプログラムに渡す追加のフラグを記述します、例:

COMPRESSION_OPTIONS=(-9)

このオプションは空のままにしておくことができます。''mkinitcpio'' は、サポートされている圧縮メソッドに、機能するイメージを生成するために必須なフラグを渡すことを保証しています。

{{Warning|このオプションを間違って使用すると、カーネルが生成されたイメージを解凍できない場合、''システムが起動不能になる''場合があります。}}

デフォルトの zstd 圧縮では、カスタムカーネルのスペースを節約するために (特に[[デュアルブート]]環境で、EFI システムパーティションを {{ic|/boot}} として使用する場合)、{{ic|--long}} オプションは非常に効果的です。ただし、RAM の限られたシステムは、このオプションをした場合に initramfs を解凍できない場合があります。また、{{ic|-v}} オプションは、initramfs の生成中に詳細を見たい場合に必要になるかもしれません。例:

COMPRESSION="zstd"
COMPRESSION_OPTIONS=(-v -5 --long)

xz で圧縮レベル {{ic|-9e}} を使用し、ローダブルなカーネルモジュールとファームウェアを解凍しておくことで、圧縮速度が最も遅くなりますが、圧縮率を最大に高めることができます:

COMPRESSION="xz"
COMPRESSION_OPTIONS=(-9e)
MODULES_DECOMPRESS="yes"

=== MODULES_DECOMPRESS ===

{{ic|MODULES_DECOMPRESS}} は、initramfs の作成時にカーネルモジュールとファームウェアのファイルを解凍しておくかを決めます。デフォルトは {{ic|no}} です。

Arch では[[カーネルモジュール]]と {{Pkg|linux-firmware}} を zstd でレベル 19 で圧縮しています。Initramfs でより高い圧縮率を使用する場合、{{ic|1=MODULES_DECOMPRESS="yes"}} を設定することで、initramfs のサイズをさらに小さくすることができます。しかし、カーネルが個々のモジュールとファームウェアをロード時に解凍する場合よりも、initramfs イメージ全体を解凍するのにより多くの時間が掛かるようになるため、ブートの初期段階で RAM と CPU の使用率を増加させ、RAM 容量が限られていて CPU の性能が低いシステムで悪影響を及ぼします。

{{Tip|Initramfs の生成プロセスの終わりあたりになると、二重圧縮を防ぐために、残りの ''.bz2''、''.gz''、''.lz4''、''.lzma''、''.lzo''、''.xz''、''.zst'' ファイルは全て未圧縮早期 initramfs イメージに移動されます。}}

== ランタイムのカスタマイズ ==

ランタイム設定オプションはカーネルコマンドラインを通して {{ic|init}} や特定のフックに渡すことができます。カーネルコマンドラインパラメータはブートローダによって与えられることがほとんどです。下で書かれているオプションをカーネルコマンドラインに追加することでデフォルトの挙動を変えることができます。詳しくは [[カーネルパラメータ]] や [[Arch ブートプロセス]] を見て下さい。

=== base フックの init ===

; {{ic|1=root=}}: カーネルコマンドラインで指定する一番重要なパラメータであり、どのデバイスを root デバイスとしてマウントするかを決めます。''mkinitcpio'' は柔軟に様々な形式を使うことができるようになっています。形式の例は [[永続的なブロックデバイスの命名#カーネルパラメータ]] を見てください。

{{Note|以下のブートパラメーターは initramfs 環境における {{ic|init}} のデフォルトの挙動を変更します。詳しくは {{ic|/usr/lib/initcpio/init}} を参照。{{ic|systemd}} フックが使われている場合 {{ic|base}} フックの {{ic|init}} は置き換わるため機能しません。}}

; {{ic|break}}: {{ic|break}} や {{ic|1=break=premount}} が指定された場合、(フックをロードした後、root ファイルシステムをマウントする前に) {{ic|init}} はブートプロセスを停止してトラブルシューティングに使うことができるインタラクティブシェルを起動します。{{ic|1=break=postmount}} と指定することで root がマウントされた後にこのシェルを起動することもできます。シェルを終了すると通常通りに起動が行われます。

; {{ic|1=disablehooks=}}: {{ic|1=disablehooks=hook1[,hook2,...]}} を追加すると実行時にフックを無効化します。例: {{bc|1=disablehooks=resume}}

; {{ic|1=earlymodules=}}: {{ic|1=earlymodules=mod1[,mod2,...]}} という風に先にロードするモジュールを指定することでモジュールがロードされる順番を変更することができます (例えば、複数のネットワークインターフェイスの順番を適切に確定したいときなどに使います)。

他のパラメータについては [[ブートデバッグ]] や {{man|8|mkinitcpio}} を見て下さい。

=== RAID を使う ===

[[RAID#mkinitcpio の設定]] を見てください。

=== net を使う ===

{{Note|NFSv4 はまだサポートされていません {{Bug|28287}}。}}

'''必要なパッケージ'''

{{ic|net}} は {{Pkg|mkinitcpio-nfs-utils}} パッケージを必要とします。

'''カーネルパラメータ'''

公式の[https://docs.kernel.org/admin-guide/nfs/nfsroot.html カーネルドキュメント]に包括的で最新の情報が載っています。

'''ip='''

このパラメータはカーネルに、デバイスの IP アドレスの設定方法と、IP ルーティングテーブルの設定方法を指定します。コロンで区切った9つまでの引数を指定できます: {{ic|1=ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>}}。

カーネルコマンドラインにこのパラメータが存在しなかった場合、全てのフィールドが空とされて、[https://docs.kernel.org/admin-guide/nfs/nfsroot.html カーネルドキュメント]に書かれているデフォルト設定が適用されます。一般的にはカーネルは自動設定を使って全てを設定しようとします。

{{ic|<autoconf>}} パラメータは {{ic|ip}} パラメータの唯一の値として指定できます (前の全ての {{ic|:}} 文字を排除)。値が {{ic|1=ip=off}} や {{ic|1=ip=none}} の場合、自動設定は行われません。そうでないなら、自動的に設定されます。最も一般的な使い方は {{ic|1=ip=dhcp}} です。

パラメータの説明は、[https://docs.kernel.org/admin-guide/nfs/nfsroot.html カーネルドキュメント]を参照してください。

例:

ip=127.0.0.1:::::lo:none --> ループバックインターフェイスを有効化。
ip=192.168.1.1:::::eth2:none --> 静的 eth2 インターフェイスを有効化。
ip=:::::eth0:dhcp --> eth0 構成に対して dhcp プロトコルを有効化。

{{Note|{{ic|<device>}} パラメータにはカーネルのデバイス名を使用してください (例: {{ic|eth0}})、永続的な名前のデバイス名 (例: {{ic|enp2s0}}) では動作しません。詳細は [[ネットワーク設定#ネットワークインターフェイス]] を見てください。}}

'''BOOTIF='''

複数のネットワークカードを使っているときは、このパラメータに起動するインターフェイスの MAC アドレスを含めることができます。インターフェイスの数字が変わってしまったり、pxelinux の IPAPPEND 2 や IPAPPEND 3 オプションを使うときに便利です。指定しなかった場合、{{ic|eth0}} が使われます。

例:

BOOTIF=01-A1-B2-C3-D4-E5-F6 # 先頭の "01-" と大文字に注意

'''nfsroot='''

{{ic|nfsroot}} パラメータがコマンドラインで指定されなかった場合、デフォルトで {{ic|/tftpboot/%s}} が使われます。

nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

パラメータの説明を見るには {{ic|mkinitcpio -H net}} を実行してください。

=== LVM を使う ===

root デバイスを [[LVM]] 上に置く場合は、[[LVM に Arch Linux をインストールする#mkinitcpio フックを追加する]] を見てください。

=== 暗号化されたルートを使う ===

[[Dm-crypt/システム全体の暗号化|root を暗号化]]している場合、どのフックを含めるべきかに関する詳細な情報は [[Dm-crypt/システム設定#mkinitcpio]] を見て下さい。

=== /usr を別のパーティションに分割する ===

{{ic|/usr}} のパーティションを別にする場合、以下を行う必要があります:

* 起動時にこのパーティションのチェックを実行するために、{{ic|fsck}} フックを追加して、{{ic|/etc/fstab}} で {{ic|/usr}} の {{ic|passno}} を {{ic|2}} にする。起動時に {{ic|/usr}} を fsck したい場合は必須です (これはすべてのユーザに推奨されます)。このフックが存在しないと、{{ic|/usr}} は永遠に fsck されません。
* systemd フックを使っていない場合、{{ic|usr}} フックを追加する。ルートがマウントされた後に {{ic|/usr}} パーティションがマウントされるようになります。

== ヒントとテクニック ==

=== フォールバック initramfs の生成 ===

[[#自動生成|フォールバック]] initramfs の生成は、デフォルトで無効化されています。有効化するには:

* {{ic|/etc/mkinitcpio.d/}} 内のそれぞれの '''.preset''' ファイルを修正する
** {{ic|1=PRESETS=('default')}} を無効化し、代わりに {{ic|1=PRESETS=('default' 'fallback')}} を有効化する
** {{ic|1=fallback_image="/boot/initramfs-linux-fallback.img"}} を有効化する
** {{ic|1=fallback_options="--skiphooks autodetect"}} を有効化する
* initramfs を再生成する
* [[ブートローダー]]の設定を更新する

{{Note|フォールバック initramfs が無いと、デフォルトの initramfs でシステムの起動が失敗した場合に、システムを起動するためのもう一つの手段が失われることになります。システムリカバリのための起動可能[[USB インストールメディア|インストールメディア]]を作成しておいてください。}}

== トラブルシューティング ==

=== イメージの展開 ===

initramfs イメージの中に何が入っているか気になるときは、イメージを展開して中に入っているファイルを調べることができます。

initramfs イメージは SVR4 CPIO アーカイブであり、''find'' と ''bsdcpio'' コマンドによって生成されています。また、任意で、カーネルが対応した圧縮方法によって圧縮されています。圧縮方法について詳しくは [[#COMPRESSION]] を見て下さい。

{{Pkg|mkinitcpio}} パッケージには {{man|1|lsinitcpio}} というユーティリティが含まれており initramfs イメージの中身を一覧・展開することができます。

イメージ内のファイルを一覧するには:

# lsinitcpio /boot/initramfs-linux.img

カレントディレクトリにファイルを全て展開するには:

# lsinitcpio --extract /boot/initramfs-linux.img

イメージの重要なパーツについて読みやすいリストを取得することもできます (カーネルバージョン、初期 CPIO の存在、含まれているモジュールやバイナリなど):

# lsinitcpio --analyze /boot/initramfs-linux.img

=== 展開して修正を加えたイメージの再圧縮 ===

{{ic|/usr/bin/mkinitcpio}} スクリプトの {{ic|build_image}} 関数を以下のパラメータで実行してください:

build_image ''出力ファイル'' ''圧縮方式''

{{ic|build_image}} 関数の内容で新しいスクリプトを作成することでこれを実行できます。
これはカレントディレクトリ内の内容を {{ic|''出力ファイル''}} というファイルに圧縮します。

{{Warning|上書きするまえに自動生成された {{ic|/boot/initramfs-linux.img}} の名前を変更することで、簡単に元に戻すことができるようになります。何か問題が発生して起動できなくなった場合、fallback イメージやブート CD で起動して、{{ic|mkinitcpio}} を実行して元のイメージに戻してください。あるいは、自分で修正してイメージを再圧縮してください。}}

=== マウントされているのに "/dev must be mounted" と表示される ===

{{ic|/dev}} がマウントされているかどうか確認するために mkinitcpio は {{ic|/dev/fd/}} が存在するかどうかを確かめます。問題がないようでしたら、手動で作成することができます:

# ln -s /proc/self/fd /dev/

(当然 {{ic|/proc}} のマウントも必要です。''mkinitcpio'' によって次にチェックされます。)

=== Possibly missing firmware for module XXXX ===

カーネルのアップデート後に initramfs を再生成する際、以下のような警告が表示されることがあります:

==> WARNING: Possibly missing firmware for module: '<nowiki/>''module_name''<nowiki/>'

''default'' initramfs イメージを生成するときに同じようなメッセージが表示される場合、警告メッセージが言っている通り、追加のファームウェアをインストールする必要があるかもしれません。ほとんどの一般的なファームウェアファイルは {{Pkg|linux-firmware}} パッケージを[[インストール]]することで入手できます。ファームウェアを提供する他のパッケージについては、以下の表を見るか、[[公式リポジトリ]]や [[AUR]] でモジュール名を検索してみてください。

メッセージが ''fallback'' initramfs イメージの生成時にのみ表示される場合は、以下の2つの選択肢があります:

* 影響を受けるハードウェアを使用しないことがわかっている場合は、警告を安全に無視できます。
* 警告を抑制したい場合、不足しているファームウェアをインストールできます。メタパッケージ {{AUR|mkinitcpio-firmware}} には、ほどんどのオプションのファームウェアが含まれています。あるいは、手動で必要なパッケージをインストールしてください:
:{| class="wikitable"
|-
! モジュール !! パッケージ
|-
| aic94xx || {{AUR|aic94xx-firmware}}
|-
| ast || {{AUR|ast-firmware}}
|-
| bfa || {{Pkg|linux-firmware-qlogic}}
|-
| bnx2x || {{Pkg|linux-firmware-broadcom}}
|-
| liquidio || {{Pkg|linux-firmware-liquidio}}
|-
| mlxsw_spectrum || {{Pkg|linux-firmware-mellanox}}
|-
| nfp || {{Pkg|linux-firmware-nfp}}
|-
| qat_420xx || {{Pkg|linux-firmware-intel}}
|-
| qed || {{Pkg|linux-firmware-qlogic}}
|-
| qla1280 || {{Pkg|linux-firmware-qlogic}}
|-
| qla2xxx || {{Pkg|linux-firmware-qlogic}}
|-
| wd719x || {{AUR|wd719x-firmware}}
|-
| xhci_pci xhci_pci_renesas || {{AUR|upd72020x-fw}}
|}
* 警告を取り除きたいが、必要ないファームウェアパッケージのためにシステムの空き領域を無駄にしたくない場合、[[#フォールバック initramfs の生成|フォールバック initramfs の生成]]を無効化することができます。

利用できないファームウェアに関しては、ダミーのファイルを作成することで警告を消すことができます。例えば:

# echo 'Silence the "Possibly missing firmware for module" message' \
| tee /usr/lib/firmware/qat_6xxx{,_mmp}.bin >/dev/null

=== No PS/2 controller found ===

一部のマザーボードで (ほとんどの場合、古いもの。しかし、一部の新しいものでも起こります)、i8042 コントローラが自動検出できません。稀なケースですが、キーボードが使えなくなってしまうことがあります。この状況を事前に察知することができます。PS/2 ポートがあり、{{ic|i8042: PNP: No PS/2 controller found. Probing ports directly}} というメッセージが表示される場合、{{ic|MODULES}} 配列に {{ic|atkbd}} を追加してください。[https://archlinux.org/news/linux-313-warning-ps2-keyboard-support-is-now-modular/]

=== あるマシンでは起動できるが他のマシンでは起動できない ===

''mkinitcpio'' の {{ic|autodetect}} フックは {{ic|/sys}} をスキャンして、ロードされている[[カーネルモジュール]]を確認して不要なカーネルモジュールを排除します。{{ic|/boot}} ディレクトリを他のマシンに移動して、初期ユーザー空間でブートが失敗する場合、カーネルモジュールが存在しないために新しいハードウェアが検出されていないのが原因かもしれません。USB 2.0 と 3.0 では必要なカーネルモジュールが異なるので注意してください。

修正するには、[[ブートローダー]]から [[#イメージ作成とアクティベーション|fallback]] イメージを選択してください (fallback は {{ic|autodetect}} によるフィルタリングがされていません) 起動したら、新しいマシンで ''mkinitcpio'' を実行して適切なモジュールでイメージを再生成してください。fallback イメージで起動できない場合、Arch Linux のライブ CD/USB で起動して、chroot し、新しいマシンで ''mkinitcpio'' を実行して下さい。それでも駄目な場合、initramfs にモジュールを[[#MODULES|手動]]で追加します。

=== コンソールにアクセスできない、ルートアカウントがロックされている ===

{{ic|systemd}} フックは、[https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/commit/292cdf8a2f7dd7c6c7d91d2b59617391935c837c (initramfs の) ルートアカウントを無効化します]。緊急シェルを有効化するには、一時的に {{ic|SYSTEMD_SULOGIN_FORCE{{=}}1}} を[[カーネルパラメータ]]に追加してください。

あるいは、{{AUR|initcpio-hook-shadowcopy}} を使う方法もあります。このパッケージをインストールし、{{ic|/etc/mkinitcpio.conf}} の {{ic|systemd}} フックの後に {{ic|shadowcopy}} フックを追加し、{{ic|mkinitcpio -P}} で initramfs を再生成してください。ドキュメントは [https://github.com/iTrooz/initcpio-hook-shadowcopy GitHub リポジトリ]にあります。

== 参照 ==

* Linux カーネルドキュメント [https://docs.kernel.org/filesystems/ramfs-rootfs-initramfs.html#what-is-rootfs initramfs, "What is rootfs?"]
* Linux カーネルドキュメント [https://docs.kernel.org/admin-guide/initrd.html initrd]
* Wikipedia 記事 [[wikipedia:ja:initrd|initrd]]

{{TranslationStatus|mkinitcpio|2026-05-03|870746}}

カーネル

2026-04-11T21:11:20Z

AshMyzk: 同期

[[Category:カーネル]]
[[Category:ソフトウェア一覧]]
[[bs:Kernel]]
[[en:Kernel]]
[[fr:Kernel]]
[[hu:Kernel]]
[[pt:Kernel]]
[[ru:Kernel]]
[[zh-hans:内核]]
{{Related articles start}}
{{Related|/Arch build system}}
{{Related|/伝統的なコンパイル方法}}
{{Related|カーネルモジュールのコンパイル}}
{{Related|カーネルモジュール}}
{{Related|kernel-install}}
{{Related|sysctl}}
{{Related articles end}}

Wikipedia によると:
:[[Wikipedia:ja:Linuxカーネル|Linux カーネル]]とは、モノリシックで Unix ライクなオープンソースのコンピュータ[[Wikipedia:ja:カーネル|オペレーティングシステムカーネル]]である。

[[Arch Linux]] は Linux カーネルをベースにしています。Arch Linux では最新の安定版カーネルに加え、様々な代替 Linux カーネルを利用することができます。この記事では、リポジトリで利用可能な選択肢のいくつかを、それぞれの簡単な説明とともにリストアップしています。また、システムのカーネルに適用できるパッチについての説明もあります。記事の最後には、カスタムカーネルのコンパイルについての概要と、様々な方法へのリンクがあります。

カーネルパッケージは、パス {{ic|/usr/lib/modules/}} に[[インストール]]され、その後 {{ic|/boot/}} 内へ [[Wikipedia:ja:vmlinuz|vmlinuz]] 実行可能イメージをコピーするために使用されます。[https://archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/]
別のカーネルをインストールする場合や複数のカーネルを切り替える場合は、それに応じて[[ブートローダー]]を設定する必要があります。
カーネルを古いバージョンにダウングレードする方法については、[[パッケージのダウングレード#カーネルのダウングレード|カーネルのダウングレード]]を参照してください。

== 公式サポートカーネル ==

公式にサポートされているカーネルについては、[https://bbs.archlinux.org/viewforum.php?id=22 フォーラム]でのコミュニティサポートと[[バグ報告ガイドライン|バグレポート]]を利用できます。

* {{App|Stable|いくつかのパッチを適用したバニラな Linux カーネル。|https://www.kernel.org/|{{Pkg|linux}}}}
* {{App|Hardened|カーネルおよびユーザ空間の脆弱性を緩和するための一連の堅牢化パッチを適用した、セキュリティ特化の Linux カーネルです。また、{{Pkg|linux}} よりも多くの上流のカーネル堅牢化機能を有効にします。|https://github.com/anthraxx/linux-hardened|{{Pkg|linux-hardened}}}}
* {{App|Longterm|長期サポート (LTS) Linux カーネル及びモジュール。最新の安定版カーネルと互換性のあるバージョンがタイムリーにリリースされないような out-of-tree のモジュールを使用する際に有用です。|https://www.kernel.org/|{{Pkg|linux-lts}}}}
* {{App|[[リアルタイムカーネル]]|[[Wikipedia:en:Ingo Molnár|Ingo Molnár]] 率いるコア開発者の小グループによって維持されています。このパッチを使用すると、コードのいくつかの非常に小さな領域("raw_spinlock クリティカル領域")を除いて、ほぼすべてのカーネルをプリエンプトできます。これは、ほとんどのカーネルスピンロックを優先度継承をサポートするミューテックスに置き換え、すべての割り込みとソフトウェア割り込みをカーネルスレッドに移動することによって行われます。|https://wiki.linuxfoundation.org/realtime/start|{{Pkg|linux-rt}}, {{Pkg|linux-rt-lts}}}}

: {{Note|1=リアルタイムカーネルサポートは [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=baeb9a7d8b60b021d907127509c44507539c15e5 Linux 6.12] にマージされました。}}

* {{App|Zen Kernel|カーネルハッカーの共同作業により、日常的なシステムに最適な Linux カーネルです。より詳細な情報は [https://github.com/zen-kernel/zen-kernel/wiki/FAQ FAQ] と [https://github.com/zen-kernel/zen-kernel/wiki/Detailed-Feature-List Detailed Feature List] を参照してください。|https://github.com/zen-kernel/zen-kernel|{{Pkg|linux-zen}}}}

== コンパイル ==

次の方法を使って、独自のカーネルをコンパイルできます。

; [[カーネル/Arch build system|Arch Build System]]: 既存の {{Pkg|linux}} [[PKGBUILD]] の高い品質と[[Wikipedia:Package management system|パッケージ管理]]の利点を生かします。
; [[カーネル/伝統的なコンパイル方法|伝統的な方法]]: 手動でソースの tarball をダウンロードし、ホームディレクトリで通常のユーザーとしてコンパイルする必要があります。

{{Warning|
* カスタムカーネルを使用すると、データの損失など、あらゆる種類の安定性と信頼性の問題が発生する可能性があります。[[バックアップ]]をとることを強くお勧めします。
* Arch Linux は [[#公式サポートカーネル]]のみを公式にサポートしています。別のカーネルを使用する場合は、サポートリクエストにその旨を記載してください。
}}

{{Tip|
* システムの速度を上げる最良の方法は、まず、カーネルの設定をアーキテクチャやプロセッサの種類に合わせることです。
* 自分が持っていないもの、使っていないもののサポートを含まないようにすることで、カーネルのサイズ (つまりビルド時間) を小さくすることができます。例えば、Bluetooth、video4linux、1000Mbit イーサネットなどのサポートです。

Arch のカーネルパッケージ設定ファイルは Arch のパッケージのソースファイルに含まれています。例えば {{Pkg|linux}} の場合 [https://gitlab.archlinux.org/archlinux/packaging/packages/linux] にリンクがあります。今現在動かしているカーネルのコンフィグファイルはファイルシステムの {{ic|/proc/config.gz}} に存在します (カーネルオプションの {{ic|CONFIG_IKCONFIG_PROC}} が有効になっている場合。)
}}

リストにあるパッケージの中には、[[非公式ユーザーリポジトリ]]からバイナリパッケージを入手できるものもあります。

=== kernel.org カーネル ===

* {{App|Git|Linus Torvalds の git リポジトリから得たソースを使ってビルドする Linux カーネルとモジュール。|https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git|{{AUR|linux-git}}}}
* {{App|Mainline|すべての新機能が導入されるカーネル、2〜3ヶ月ごとにリリースされます。|https://www.kernel.org/|{{AUR|linux-mainline}}}}
* {{App|Next|次の mainline リリースにマージされる予定の機能を持つ最先端のカーネル。|https://www.kernel.org/doc/man-pages/linux-next.html|{{AUR|linux-next-git}}}}
* {{App|DRM|最先端の GPU ドライバ付き Linux カーネル。|https://gitlab.freedesktop.org/drm|{{AUR|linux-drm-tip-git}}, {{AUR|linux-drm-next-git}}}}
* {{App|Longterm|長期サポート (LTS) Linux カーネルとモジュール。|https://www.kernel.org/|{{AUR|linux-lts612}}, {{AUR|linux-lts66}}, {{AUR|linux-lts61}}, {{AUR|linux-lts515}}, {{AUR|linux-lts510}}}}

=== 非公式カーネル ===

* {{App|linux-cachyos|SCHED-EXT + BORE + "Cachy sauce" が組み合わされた Linux カーネル。これら以外のパッチや改良が施されたカーネルやモジュールも組み合わされています。|https://github.com/CachyOS/linux-cachyos|{{AUR|linux-cachyos}}}}
* {{App|[[Wikipedia:Linux-libre|Libre]]|[[Wikipedia:ja:難読化 (ソフトウェア)|難読化された]]デバイスドライバや[[Wikipedia:ja:バイナリ・ブロブ|プロプライエタリ]]のデバイスドライバーを使用しません。|https://www.fsfla.org/ikiwiki/selibre/linux-libre/|{{AUR|linux-libre}}}}
* {{App|Liquorix|Debian をターゲットとした設定と Zen カーネルソースを使用して構築されたカーネル代替品。デスクトップ、マルチメディア、ゲームなどのワークロード向けに設計されており、Debian Linux の性能代替カーネルとしてよく利用されます。Liquorix パッチセットのメンテナである Damentz は、同様に Zen パッチセットの開発者でもあります。|https://liquorix.net|{{AUR|linux-lqx}}}}
* {{App|pf-kernel|カーネルメインラインにマージされない、ほんの少しの素晴らしい機能を提供します。カーネルエンジニアによって管理されています。新しいカーネルのための含まれるパッチのポートが公式にリリースされていない場合、パッチセットは新しいカーネルへのパッチポートを提供し、サポートします。linux-pf の現在の最も代表的なパッチは、UKSM、DDCCI、v4l2loopback、そして BBRv3 です。|https://pfkernel.natalenko.name|パッケージ:}}
:* [[非公式ユーザーリポジトリ#post-factum kernels|リポジトリ]]: pf-kernel の開発者 [https://aur.archlinux.org/account/post-factum post-factum] による {{AUR|linux-pf}}
* {{App|Project C|Alfred Chen 氏の Project C パッチセット (BMQ スケジューラと PDS スケジューラ) を当てたカーネル。|https://gitlab.com/alfredchen/projectc|{{AUR|linux-prjc}}}}
* {{App|Nitrous|Skylake 及びそれ以降に対して最適化された修正版 Linux カーネル。|https://gitlab.com/xdevs23/linux-nitrous|{{AUR|linux-nitrous}}}}
* {{App|Tachyon|Intel の Clear Linux プロジェクトからのパッチが含まれています。Clear Linux プロジェクトは放棄されたため、現在は新しいプロジェクトにフォークされています。パフォーマンスとセキュリティの最適化を提供します。|https://git.staropensource.de/StarOpenSource/Linux-Tachyon|{{AUR|linux-tachyon}}}}
* {{App|tkg|デスクトップやゲームのパフォーマンスを向上させるためのパッチや調整を提供する、高度にカスタマイズ可能なカーネルビルドシステム。Etienne Juvigny によってメンテナンスされています。他のパッチの中で、様々な CPU スケージューラを提供しています: CFS、Project C PDS、Project C BMQ、MuQSS、CacULE。|https://github.com/Frogging-Family/linux-tkg|[[非公式ユーザーリポジトリ#chaotic-aur|chaotic-aur]] リポジトリで利用可能}}
* {{App|VFIO|Alex Williamson によって作成されたいくつかのパッチ(acs オーバーライドおよび i915)により、一部のマシンで KVM を使用して PCI パススルーを実行できるようになります。|https://lwn.net/Articles/499240/|{{AUR|linux-vfio}}, {{AUR|linux-vfio-lts}}}}
* {{App|XanMod|高性能ワークステーション、ゲーミングデスクトップ、メディアセンターなどで最大限に活用されることを目指し、より強固で応答性の高い、スムーズなデスクトップ体験を提供するために構築されています。このカーネルでは、BFQ I/O スケジューラ、[https://github.com/google/bbr/tree/v3 TCP BBRv3] 輻輳制御、x86_64 高度命令セットのサポート、部分的な Clear Linux パッチセットが使用されており、また一部のデフォルトも変更されています。|https://xanmod.org/|{{AUR|linux-xanmod}}, {{AUR|linux-xanmod-lts}}, {{AUR|linux-xanmod-rt}}, {{AUR|linux-xanmod-bore}}}}

これらの非公式カーネルの多くには、手動で有効化する必要のある機能が含まれています。パッチ自体に含まれるドキュメントを読むか (これらの多くはカーネルソース内の {{ic|Documentation/}} ディレクトリに変更点が含まれています)、ウェブ上でパッチセットの名前を検索してみましょう。

== トラブルシューティング ==

=== カーネルパニック ===

Linux カーネルが回復不能な障害状態になると、''カーネルパニック''が発生します。この状態は通常、バグのあるハードウェアドライバーが原因で、マシンがデッドロックされ、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときの''マシンの状態''、障害を検出したカーネルの関数までの ''呼び出しトレース''、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン (公式リポジトリで提供されているものなど) を使用してカーネルパニックが発生することはあまりありませんが、発生した場合に備えて対処方法を知る必要があります。

{{Note|カーネルパニックは、''oops'' または''カーネル oops'' と呼ばれることもあります。パニックと oops は両方とも障害状態の結果として発生するものですが、oops はより一般的なものであり、必ずしもマシンがデッドロックするわけではありません。問題のあるタスクを強制終了して実行を継続することで、カーネルが oops から回復できる場合があります。}}

{{Tip|回復可能な oops で代わりにパニックを発生させることを強制するには、カーネルパラメータ {{ic|1=oops=panic}} を起動時に渡すか、{{ic|/proc/sys/kernel/panic_on_oops}} に {{ic|1}} を書き込んでください。oops リカバリによってシステムが不安定になり将来のエラーの診断が困難になることを懸念しているのであれば、これは推奨される方法です。}}

==== パニックメッセージの検証 ====

ブートプロセスの非常に早い段階でカーネルパニックが発生すると、{{ic|Kernel panic - not syncing:}} という文字列が含まれるメッセージがコンソールに表示されます。ただし、[[systemd]] が実行され始めると、カーネルのメッセージはたいていキャプチャーされ、システムログに書き込まれます。しかし、パニックが発生した際、カーネルによる診断メッセージは''ほとんどの場合において''ディスク上のログファイルには書き込まれません。{{ic|system-journald}} がディスクにログを書き込む前に、マシンがデッドロックしてしまうためです。

===== ブルースクリーン上の QR コード =====

{{Pkg|linux}} 6.10 から ({{ic|drm_panic}} により)、カーネルはパニックをブルースクリーン上の [[Wikipedia:ja:QRコード|QR コード]]として表示するようになりました。QR コードによって与えられた URL で''スタックトレース''を見ることができます。Arch Linux では、QR コードは https://panic.archlinux.org/panic_report へのリンクとなっています。URL には、gzip によって圧縮され、[[Wikipedia:URL fragment|URL フラグメント]] 内にエンコードされた様々な情報やスタックトレースが含まれています。この情報はサーバには転送されません (クライアントサイドで処理されます)。

この[https://bbs.archlinux.org/viewtopic.php?pid=2256536#p2256536 フォーラムの投稿]にパニックのスクリーンショット例があります。

{{ic|drm}} カーネルモジュールにパラメータ {{ic|panic_screen{{=}}kmsg}} (あるいは[[カーネルパラメータ]]として {{ic|drm.panic_screen{{=}}kmsg}}) を渡すことで、コンソールにスタックトレースを表示する以前の挙動に戻すことができます。

===== コンソールによる方法 =====

コンソール上にクラッシュを表示される「以前の」スタイルは依然として使用できます (''kdump crashkernel'' のセットアップをする必要はありません)。以下のカーネルパラメータで起動すると、tty1 上でパニックを表示しようとします:

systemd.journald.forward_to_console=1 console=tty1

{{Tip|パニックメッセージが速くスクロールしすぎて検証できない場合、起動時にカーネルパラメータ {{ic|1=pause_on_oops=''秒数''}} を渡してみてください。}}

===== 例: 不良モジュール =====

診断メッセージの情報を使って、何のサブシステムやモジュールがパニックを引き起こしているかを推測できます。この例では、とある架空のマシンで起動中にパニックが発生してしまいました。'''太字'''で強調した行に注目してください。

{{bc|'''kernel: BUG: unable to handle kernel NULL pointer dereference at (null)''' 1
'''kernel: IP: fw_core_init+0x18/0x1000 [firewire_core]''' 2
kernel: PGD 718d00067
kernel: P4D 718d00067
kernel: PUD 7b3611067
kernel: PMD 0
kernel:
kernel: Oops: 0002 [#1] PREEMPT SMP
'''kernel: Modules linked in: firewire_core(+) crc_itu_t cfg80211 rfkill ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_ipv4 ...''' 3
kernel: CPU: 6 PID: 1438 Comm: modprobe Tainted: P O 4.13.3-1-ARCH #1
kernel: Hardware name: Gigabyte Technology Co., Ltd. H97-D3H/H97-D3H-CF, BIOS F5 06/26/2014
kernel: task: ffff9c667abd9e00 task.stack: ffffb53b8db34000
kernel: RIP: 0010:fw_core_init+0x18/0x1000 [firewire_core]
kernel: RSP: 0018:ffffb53b8db37c68 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
kernel: RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffc16d3af4
kernel: RBP: ffffb53b8db37c70 R08: 0000000000000000 R09: ffffffffae113e95
kernel: R10: ffffe93edfdb9680 R11: 0000000000000000 R12: ffffffffc16d9000
kernel: R13: ffff9c6729bf8f60 R14: ffffffffc16d5710 R15: ffff9c6736e55840
kernel: FS: 00007f301fc80b80(0000) GS:ffff9c675dd80000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000000 CR3: 00000007c6456000 CR4: 00000000001406e0
kernel: Call Trace:
'''kernel: do_one_initcall+0x50/0x190''' 4
kernel: ? do_init_module+0x27/0x1f2
kernel: do_init_module+0x5f/0x1f2
kernel: load_module+0x23f3/0x2be0
kernel: SYSC_init_module+0x16b/0x1a0
kernel: ? SYSC_init_module+0x16b/0x1a0
kernel: SyS_init_module+0xe/0x10
kernel: entry_SYSCALL_64_fastpath+0x1a/0xa5
kernel: RIP: 0033:0x7f301f3a2a0a
kernel: RSP: 002b:00007ffcabbd1998 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
kernel: RAX: ffffffffffffffda RBX: 0000000000c85a48 RCX: 00007f301f3a2a0a
kernel: RDX: 000000000041aada RSI: 000000000001a738 RDI: 00007f301e7eb010
kernel: RBP: 0000000000c8a520 R08: 0000000000000001 R09: 0000000000000085
kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000c79208
kernel: R13: 0000000000c8b4d8 R14: 00007f301e7fffff R15: 0000000000000030
kernel: Code: <c7> 04 25 00 00 00 00 01 00 00 00 bb f4 ff ff ff e8 73 43 9c ec 48
kernel: RIP: fw_core_init+0x18/0x1000 [firewire_core] RSP: ffffb53b8db37c68
kernel: CR2: 0000000000000000
kernel: ---[ end trace 71f4306ea1238f17 ]---
'''kernel: Kernel panic - not syncing: Fatal exception''' 5
kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff
kernel: ---[ end Kernel panic - not syncing: Fatal exception}}

# パニックを引き起こしたエラーの種類を示しています。この場合、プログラマのバグです。
# モジュール ''firewire_core'' 内の ''fw_core_init'' という関数でパニックが発生したことを示しています。
# ''firewire_core'' は最後にロードされたモジュールであることを示しています。
# ''fw_core_init'' 関数を呼んだ関数は ''do_one_initcall'' であったことを示しています。
# この ''oops'' メッセージが実際にカーネルパニックであり、システムがデッドロックしていることを示しています。

以上のメッセージにより、''firewire_core'' モジュールがロードされたときの初期ルーチン中にパニックが発生したということを推測できます。(マシンのファームウェアハードウェアは、プログラマのエラーによりこのバージョンのファームウェアドライバモジュールと互換性が無いかもしれないことが推測でき、新しいリリースを待つ必要があることになります。) その間、マシンを再び走らせる最も簡単な方法は、モジュールがロードされないようにすることです。以下の方法のうち1つを取ってください:

* モジュールが ''initramfs'' の実行中にロードされる場合、[[カーネルパラメータ]] {{ic|1=rd.blacklist=firewire_core}} を設定して再起動してください。
* それ以外の場合、カーネルパラメータ {{ic|1=module_blacklist=firewire_core}} を設定して再起動してください。

==== 再起動して root シェルに入り問題を修正する ====

{{Out of date|[https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/commit/292cdf8a2f7dd7c6c7d91d2b59617391935c837c initramfs の root アカウントはロックされているため]、{{ic|rd.rescue}} と {{ic|rd.emergency}} は動作しません。}}

{{Accuracy|{{ic|rd.emergency}} ではキーボードは動作しないため、使用できません。}}

システムに変更を加えてパニックが起こらないようにするには、root シェルが必要です。パニックが起動時に発生する場合、マシンがデッドロックする前に root シェルに入るための戦略が複数あります:

* カーネルパラメータ {{ic|emergency}} か {{ic|rd.emergency}} か {{ic|-b}} を設定して再起動する。これで、root ファイルシステムがマウントされて {{ic|systemd}} が起動した直後にログインプロンプトが表示されます。

: {{Note|この時点では、root ファイルシステムは'''読み取り専用'''でマウントされます。ファイルシステムに変更を加えるには、{{ic|mount -o remount,rw /}} を root ユーザとして実行してください。}}

* カーネルパラメータ {{ic|rescue}}、{{ic|rd.rescue}}、{{ic|single}}、{{ic|s}}、{{ic|S}}、{{ic|1}} のどれか設定して再起動する。これで、ローカルのファイルシステムがマウントされた直後にログインプロンプトが表示されます。
* カーネルパラメータ {{ic|1=systemd.debug_shell}} を設定して再起動する。これで、非常に初期の root シェルが tty9 で表示されます。{{ic|Ctrl+Alt+F9}} を押してそのシェルに切り替えてください。
* パニックを引き起こしているカーネルの機能を無効化するために、異なるカーネルパラメータの組で再起動して実験する。"定番" の {{ic|1=acpi=off}} と {{ic|nolapic}} を試してみてください。

: {{Tip|すべてのカーネルパラメータは [https://docs.kernel.org/admin-guide/kernel-parameters.html kernel-parameters.html] を参照して下さい。}}

* 最後の手段として、[[インストールガイド#インストールメディアの準備|Arch Linux インストールメディア]]を起動し、ルートファイルシステムを {{ic|/mnt}} にマウントし、{{ic|arch-chroot /mnt}} を root ユーザとして実行する。
* パニックを引き起こしているサービスやプログラムを無効化する。不具合のあるアップデートをロールバックする。設定の問題を修正する。

{{Tip|[[Wikipedia:Initial ramdisk|初期 RAM ディスク]]イメージが破損している場合、新しいイメージを生成する必要があるかもしれません。イメージの破損は、カーネルアップデートが中断された場合に起こる可能性があります。新しいイメージを作成する方法は、[[mkinitcpio#イメージ作成とアクティベーション]] を参照してください。}}

=== リグレッションをデバッグする ===

[[一般的なトラブルシューティング#リグレッションをデバッグする]] を参照してください。

{{AUR|linux-mainline}} を試して、その問題が既に上流で修正されているかどうかを確認してください。ピン留めされたコメントは既にビルドされたカーネルを含むリポジトリにも言及しているので、時間がかかる手動でのビルドは必要ないかもしれません。

最近発生しなかった問題をデバッグするために LTS カーネル ({{Pkg|linux-lts}}) を試してみることも検討する価値があるかもしれません。LTS カーネルの古いバージョンは [[Arch Linux Archive]] で見つけることができます。

引き続き問題が発生する場合は、{{AUR|linux-git}} カーネルを [[bisect]] し、Linux カーネルにおける[https://docs.kernel.org/admin-guide/reporting-regressions.html リグレッション報告]の方法に従ってバグを報告してください。[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS {{ic|MAINTAINERS}}] ファイル内の Bugtracker ({{ic|B:}}) エントリによっては、サブシステムのメーリングリスト、Kernel Bugzilla、あるいは DRM Gitlab などの他のイシュートラッカーでイシューを開く必要があります。パッチと関係ないことを確認するために、パッチなしの "バニラ"バージョンを試すことが重要です。もしパッチが問題を引き起こすなら、そのパッチの作者に報告してください。

{{Note|カーネルの bisect は何度も作り直さなければならないので、かなりの時間がかかるかもしれません。}}

==== より小さなカーネルを構築する ====

[[modprobed-db]] か {{ic|make localmodconfig}} を使って、ローカルシステムに必要なモジュールだけをビルドしたり、によってカーネルビルド時間を短縮したりできます。もちろん、ネットワークの問題をデバッグするために、サウンドドライバなど、無関係なドライバを完全に削除することも可能です。

== 参照 ==

* [http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (フリーの電子書籍)
* [http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/ What stable kernel should I use?] by Greg Kroah-Hartman
* [https://docs.kernel.org/index.html Linux カーネルのドキュメント]

{{TranslationStatus|Kernel|2026-04-12|870571}}

環境変数

2026-03-29T09:32:42Z

AshMyzk: リンクを修正

[[Category:システム管理]]
[[de:Umgebungsvariablen]]
[[en:Environment variables]]
[[es:Environment variables]]
[[hu:Environment variables]]
[[pt:Environment variables]]
[[ru:Environment variables]]
[[zh-hans:Environment variables]]
{{Related articles start}}
{{Related|デフォルトアプリケーション}}
{{Related|systemd/ユーザー#環境変数}}
{{Related articles end}}
環境変数は、1つ以上のアプリケーションによって使用されるデータを含む名前付きのオブジェクトです。簡単に言えば、名前と値を持つ変数です。環境変数の値には、例えばファイルシステム内のすべての実行可能ファイルの場所、使用すべきデフォルトのエディタ、またはシステムロケールの設定などが含まれます。Linux に不慣れなユーザーは、このような設定の管理方法を少し扱いづらいと感じることがよくあります。しかし、環境変数は、複数のアプリケーションやプロセス間で設定を共有する簡単な方法を提供します。

== ユーティリティ ==

{{Pkg|coreutils}} パッケージには {{man|1|printenv}} と {{man|1|env}} というプログラムが含まれています。現在の環境変数とその値を一覧表示するには:

$ printenv

{{Note|環境変数の中にはユーザ個別のものも存在します。{{ic|printenv}} の出力を非特権ユーザの場合と root ユーザの場合で比較して確認してみましょう。}}

''env'' ユーティリティを使うことで、環境変数を変更してコマンドを実行することができます。以下の例では、環境変数 {{ic|EDITOR}} を {{ic|vim}} に設定して ''xterm'' を起動します。以下のコマンドを実行しても、グローバルな {{ic|EDITOR}} 変数には影響を与えません。

$ env EDITOR=vim xterm

[[シェル]] の {{man|1p|set}} 組み込みコマンドを使えば、シェルオプションの値を変更したり、位置のパラメータを設定したり、シェル変数の名前とその値を出力したりできます。

各プロセスはその環境変数を {{ic|/proc/$PID/environ}} ファイルに保存しています。このファイルには、ヌル文字 ({{ic|\x0}}) で区切られたキーと値のペアが含まれています。[[sed]] を使用すると、より読み易い形式で取得できます。例: {{ic|sed 's:\x0:\n:g' /proc/$PID/environ}}。

== 変数の定義 ==

環境を不必要に汚染しないために、変数のスコープを制限するように努めるべきです。実際、グラフィカルセッションや systemd サービスでは、変数を有効にするために特定の場所で設定することが要求されます。環境変数のスコープは、それらが影響を与えるコンテキストに分けられます:

* [[#グローバル|グローバル]]: あらゆるユーザが実行する全プログラム。Systemd サービスは含まれません。
* [[#ユーザーごと|ユーザ別]]: 特定のユーザが実行する全プログラム。Systemd ユーザサービス ([[systemd/ユーザー#環境変数]] を参照) やグラフィカルアプリケーション ([[#グラフィック環境]] を参照) は含まれません。

=== グローバル ===

==== シェルの初期化ファイルを使う ====

大半の Linux ディストリビューションは、あなたに {{ic|/etc/profile}} 等のファイルに環境変数の追加・変更を行うよう指示します。また、{{ic|/etc/locale.conf}} のような変数設定を含むパッケージ固有の設定ファイルがあることも覚えておいてください。環境変数の維持・管理は必ず行い、環境変数を含むことができる多数のファイルに注意を払うようにしてください。原則的に、あらゆるシェルスクリプトは環境変数の初期化に使うことができますが、以下のような UNIX の慣例に従い特定のファイルでのみ行われるべきです。

以下のファイルは、システムのグローバルな環境変数を定義するために使用できますが、それぞれに異なる制限があります:

* {{ic|/etc/environment}} は [[#pam_env を使う|pam_env モジュール]]によって使用され、シェルに依存しないため、スクリプトやグロブ展開は使用できません。このファイルは、{{ic|1=''変数=値''}} という形式しか受け入れません。
* {{ic|/etc/profile}} は、ログインシェル''のみ''に対して変数を初期化します。しかし、このファイルはスクリプト (例: {{ic|/etc/profile.d/}} 内にあるファイル) を実行し、すべての [[wikipedia:ja:Bourne Shell|Bourne shell]] 互換シェルで使用することができます。
* シェル固有の設定ファイル - [[シェル]]のグローバルな設定ファイルで、変数の初期化やスクリプトの実行を行います。例えば [[Bash#設定ファイル]] (例: {{ic|~/.bashrc}})) や [[Zsh#スタートアップ/シャットダウンファイル]] (例: {{ic|~/.zshrc}}) です。

以下の Bash ヘルパ関数を使えば、複数のディレクトリを {{ic|PATH}} 環境変数に末尾追加することができます。環境変数を定義しているファイル ({{ic|~/.bashrc}} など) の戦闘にこの関数を追加してください。この関数は、ファイルシステム上に実際に存在するディレクトリのみを追加し、重複するエントリは作成しません。

{{bc|<nowiki>
add_paths() {
for d in "$@"; do
[[ -d "$d" && ! "$PATH" =~ (^|:)$d(:|$) ]] && PATH="$PATH:$d"
done
}

add_paths ~/bin ~/scripts
</nowiki>}}

ほとんどのシェル (Bash、Zsh、[[fish]] を含む) では、{{ic|export}} コマンドを使って環境に変数を追加することができます。これにより、{{ic|~/my-environment.sh}} などのように通常のファイルで環境変数を定義することができます:

{{hc|~/my-environment.sh|2=
export EDITOR=vim
export XDG_CACHE_HOME="$HOME/.cache"
export XDG_CONFIG_HOME="$HOME/.config"
export XDG_DATA_HOME="$HOME/.local/share"
export XDG_STATE_HOME="$HOME/.local/state"
}}

このファイルは、シェルのスタートアップファイルから source することができます:

{{hc|~/.bashrc|source ~/my-environment.sh}}
{{hc|~/.config/fish/config.fish|source ~/my-environment.sh}}

==== pam_env を使う ====

{{man|8|pam_env}} [[PAM]] モジュールは、環境変数の設定を以下のファイルから順番にロードします: {{ic|/etc/security/pam_env.conf}} と {{ic|/etc/environment}} の順です。

{{Note|
* これらのファイルは、他のファイル、特に、{{ic|~/.profile}}、{{ic|~/.bash_profile}}、{{ic|~/.zshenv}} より前に読み込まれます。
* 非推奨の {{ic|~/.pam_environment}} はもう読み込まれません。{{Bug|68945}} を参照してください。
}}

{{ic|/etc/environment}} では、{{ic|1=''変数''=''値''}} というペアを1行に1つずつ記述しなければなりません。例:

{{hc|/etc/environment|2=
EDITOR=nano
}}

{{ic|/etc/security/pam_env.conf}} は以下の形式で記述します:

{{hc|/etc/security/pam_env.conf|2=
VARIABLE [DEFAULT=''value''] [OVERRIDE=''value'']
}}

{{ic|@{HOME} }} と {{ic|@{SHELL} }} は、{{ic|/etc/passwd}} で定義されているものに拡張される特別な変数です。次の例は、{{ic|HOME}} 環境変数を別の変数に展開する方法を示しています:

{{hc|/etc/security/pam_env.conf|2=
XDG_CONFIG_HOME DEFAULT=@{HOME}/.config
}}

{{Note|変数 {{ic|${HOME} }} および {{ic|${SHELL} }} は、{{ic|HOME}} および {{ic|SHELL}} 環境変数にはリンクされていません。これらはデフォルトでは設定されていません。}}

また、この形式では、{{ic|${''VARIABLE''} }} を使って、既に定義されている変数を他の変数の値で展開することができます。例えば:

GOPATH DEFAULT=${XDG_DATA_HOME}/go

{{ic|1=''VARIABLE''=''value''}} のペアも可能ですが、これらのペアでは変数の展開はサポートされていません。詳しくは {{man|5|pam_env.conf}} を参照してください。

=== ユーザーごと ===

環境変数をグローバルに定義したくないという時もあるでしょう。例えば、{{ic|PATH}} に {{ic|/home/my_user/bin}} を追加したいが、システム上の他のユーザーには同じ {{ic|PATH}} を使って欲しくないという場合が考えられます。様々なファイルを使うことでローカルに環境変数を定義することができます:

* [[シェル]]のユーザ設定ファイル。例えば、[[Bash#設定ファイル]] や [[Zsh#スタートアップ/シャットダウンファイル]]。
** あなたが開くターミナル (例: コマンドラインアプリケーションのみ) に変数のスコープを制限しない限り、ログインシェルの変数も変更されます。
* [[systemd/ユーザー#環境変数|systemd ユーザ環境変数]]は {{ic|~/.config/environment.d/*.conf}} から読み込まれます。

ローカルで使用するディレクトリを {{ic|PATH}} に追加するには、{{ic|~/.bash_profile}} に次のように記述します:

export PATH="${PATH}:/home/my_user/bin"

変数をアップデートするために、再ログインするかファイルを [[source]] してください: {{ic|$ source ~/.bash_profile}}

{{Note|dbus デーモンや systemd のユーザインスタンスは、{{ic|~/.bashrc}} などのような場所で設定された環境変数を継承しません。これはつまり、dbus によってアクティブ化されたプログラム ([[GNOME Files]] など) は、そのような変数をデフォルトで使用しないことを意味します。[[Systemd/ユーザー#環境変数]] を参照してください。}}

{{Tip|{{ic|export -p}} を実行することで、ユーザセッションに対して宣言されたグローバルな環境変数とローカルな環境変数を見ることができます。}}

==== グラフィック環境 ====

環境変数がグラフィカルなアプリケーションにしか影響しない場合は、グラフィカルセッション内でのみ設定することにより、その範囲を制限することができます。スコープを大きい順に並べると:

* [[#Xorg セッションごと]] および [[#Wayland セッションごと]] - DE を含むグラフィカルセッション全体に影響します。
* [[#デスクトップ環境セッションごと]] - グラフィカルセッション内で生成されたアプリケーションに影響を与えます。DE 自体にも影響を与える可能性があります。
* [[#アプリケーションごと]] - 特定のグラフィカルアプリケーションだけに影響します。

===== デスクトップ環境セッションごと =====

一部のグラフィカル環境 (例えば [[KDE Plasma]]) は、ログイン時のシェルスクリプト実行をサポートしており、環境変数の設定に利用することができます。例としては [[KDE#自動起動]] を参照してください。

===== Xorg セッションごと =====

Xorg セッションの環境を変更する手順は、Xorg セッションの起動方法によって異なります:
* ほとんどの[[ディスプレイマネージャ]]は [[xprofile]] を読み込みます。
* [[startx]] と [[SLiM]] は [[xinitrc]] を実行します。
* [[XDM]] は {{ic|~/.xsession}} を実行します: [[XDM#セッションの定義]] を参照して下さい。
* [[LightDM]][https://gitlab.archlinux.org/archlinux/packaging/packages/lightdm/-/blob/main/Xsession]、[[Plasma Login Manager]][https://github.com/KDE/plasma-login-manager/blob/master/data/scripts/Xsession]、[[SDDM]][https://github.com/sddm/sddm/blob/master/data/scripts/Xsession] は、ログインシェルのスタートアップスクリプトも読み込みます。例えば、[[bash]] の場合は {{ic|~/.bash_profile}}、[[zsh]] の場合は {{ic|~/.zprofile}} および {{ic|~/.zlogin}} です。

スクリプトの終わりはどのファイルであるかに依存し、高度な構文は使用するシェルに依存しますが、基本的な使い方は普遍的です:

{{hc|~/.xprofile, ~/.xinitrc, or ~/.xsession|2=
...
export ''GUI_VAR''=''value''
...
}}

===== Wayland セッションごと =====

[[Wayland]] は Xorg 関連のファイルを起動しないので、[[GDM]] と [[KDE Plasma]] は代わりに [[systemd/ユーザー#環境変数|systemd ユーザ環境変数]]を読み込みます。

{{hc|~/.config/environment.d/envvars.conf|2=
''GUI_VAR''=''value''
}}

Wayland セッションをサポートする他のディスプレイマネージャ (例: [[SDDM]]) は、まだこれを直接はサポートしていません。しかし、[[LightDM]]、[[Plasma Login Manager]]、[[SDDM]] はログインシェルのスタートアップスクリプトを Wayland セッションでも読み込みます。

[[greetd]] も {{ic|/etc/profile}} および {{ic|~/.profile}} を読み込みます。この動作は、デフォルトで有効になっている {{ic|source_profile}} 設定によって制御されます。

{{ic|~/.bash_profile}} などのスタートアップスクリプトを読み込むディスプレイマネージャを使用していて、{{ic|environment.d}} を使用したい場合、以下のように読み込むことができます:

{{hc|~/.bash_profile|
# systemd-environment-d-generator(8) を使用して環境を生成し、その変数をエクスポートする
set -o allexport
source <(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)
set +o allexport
}}
{{Note|{{ic|/usr/lib/systemd/user-environment-generators}} にある他のジェネレーター、例えば {{ic|60-flatpak}} は環境変数の値を引用符で囲まない場合があります。この場合、出力は {{ic|export -- "$(/usr/lib/systemd/user-environment-generators/60-flatpak)"}} を使用して読み込む必要があります。}}

===== アプリケーションごと =====

セッション全体ではなく、特定のアプリケーションにのみ環境変数を設定するには、そのアプリケーションの ''.desktop'' ファイルを編集してください。その方法は [[デスクトップエントリ#環境変数の変更]] を参照してください。

[[Steam]] ゲームでは、起動オプションを編集することでプログラムの環境を設定することができます。[[Steam#起動オプション]] を参照してください。

=== セッションまたはシェルごと ===

時として、一時的な変数のみが必要である場合もあります。特定のディレクトリ内の実行ファイルを実行する際に一時的に絶対パスを入力する手間を省きたい場合や、一時的な短いシェルスクリプトでそのパスを使用したい場合があるでしょう。

例えば、セッション固有のディレクトリを {{ic|PATH}} に追加するには:

$ export PATH="${PATH}:/home/my_user/tmp/usr/bin"

シェル固有のディレクトリのみを {{ic|PATH}} に追加するには:

$ PATH="${PATH}:/home/my_user/tmp/usr/bin"

Bash では、{{ic|PATH}} は既にデフォルトで export されているので、上記のどちらの方法を用いても、変数を上書きしない限り、変数の変更がサブプロセスから見えてしまいます。export された変数とされていない変数の違いをよりわかりやすく比較するには、以下を実行してみてください:

$ MYVAR="shell-only"
$ bash -c 'echo $MYVAR' # 何も表示されない

$ export MYVAR="session-wide"
$ bash -c 'echo $MYVAR' # 表示される。すなわち、セッション全体に反映されている

== 例 ==

以下のセクションでは Linux システムで一般的に使われている環境変数を並べており、それぞれの値について説明しています。

=== デスクトップ環境の検出 ===

; XDG_CURRENT_DESKTOP:
コロンで区切られた文字列リストを含む [[freedesktop.org]] 変数。現在の[[デスクトップ環境]]を示します[https://specifications.freedesktop.org/mime-apps-spec/latest/file.html]。活発に開発されているデスクトップ環境の標準化された値として次があります: {{ic|GNOME}}、{{ic|GNOME-Flashback}}、{{ic|KDE}}、{{ic|LXDE}}、{{ic|LXQt}}、{{ic|MATE}}、{{ic|TDE}}、{{ic|Unity}}、{{ic|XFCE}}、{{ic|EDE}}、{{ic|Cinnamon}}、{{ic|Pantheon}}、{{ic|DDE}} [https://specifications.freedesktop.org/menu-spec/latest/onlyshowin-registry.html]。
{{Tip|
* Cinnamon は、他のデスクトップ環境[https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/commit/be0c630a19aa1788ef731def911770ce497d6ba3 より後に]登録されました。そのため、[[Qt]][https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixtheme.cpp#L156] など一部のソフトウェアは、登録前の値である {{ic|X-CINNAMON}} を期待します。
* {{ic|Hyprland}} は、[[Hyprland]] 用として非公式に認められています。
}}
; XDG_SESSION_DESKTOP:
{{ic|XDG_CURRENT_DESKTOP}} と似ていますが、単一の文字列しか許可しません。その名前にも関わらず、[https://gitlab.gnome.org/GNOME/gtk/-/issues/1224#note_270915 これは freedesktop.org によって標準化されたものではありません]。
; DE:
使用中のデスクトップ環境 (''d''esktop ''e''nvironment) を示すレガシーな変数です。どのような値を取りうるかについての中心的なドキュメントはありませんが、[[xdg-utils#環境変数|xdg-utils]] は多くのデスクトップ環境についてのリファレンスを提供しています。
; DESKTOP_SESSION:
これもレガシーな変数です。{{ic|DE}} に似ていますが、それよりは一般的ではありません。セッションの ({{ic|/usr/share/xsessions/}} 内の) [[デスクトップエントリ]]へのパスを格納できます [https://github.com/qt/qtbase/blob/6.3/src/gui/platform/unix/qgenericunixservices.cpp#L92-L107]。
; WINDOW_MANAGER:
デスクトップ環境で使用する[[ウィンドウマネージャ]]を''選択''するために時々使われる変数です。他のプログラムが読み取るために、既に選択されているディスプレイマネージャやデスクトップ環境によって設定される他の変数とは対照的です。
; DISPLAY:
ホスト、ディスプレイ、スクリーンを指定するために X Window System によって使用されます。形式は {{ic|''ホスト名'':''ディスプレイ''.''スクリーン''}} です。ディスプレイとは、共通の入力デバイス群 (キーボードやマウスなど) を共有するスクリーンの集まりを指します。ホスト名は、ディスプレイが接続されるマシンの名前を指定するためにかつて使用されていましたが、X クライアントと同じコンピュータ上で X サーバが実行される場合は空欄になっているはずです。詳細は {{man|7|X}} を参照してください。
; WAYLAND_DISPLAY:
Wayland における {{ic|DISPLAY}} のようなものです。コンポジタによって設定されます。これが設定されていない場合、アプリケーションは {{ic|wayland-0}} を使おうと試みます。
; XAUTHORITY:
{{ic|.Xauthority}} ファイルへのパスです。このファイルには、X Window Server にアクセスするための資格情報が入っています。これは、認証のために X サーバに送られるクッキー (任意のデータ) の形で保存されます (例: {{ic|MIT-MAGIC-COOKIE-1}})。

=== システムやセッションのパス ===

; HOME:
現在のユーザのホームディレクトリへのパスが格納されます。この変数は、アプリケーションが現在のユーザに関連した設定ファイル等を見つけるために使うことができます。
; PATH:
コロンで区切られたディレクトリのリストが格納されています。システムは、この変数に登録されているディレクトリから実行ファイルを探索します。通常のコマンド (''ls''、''systemctl''、''pacman'' など) がシェル (''bash'' や ''zsh'' など) によって解釈される際、シェルは {{ic|PATH}} のリスト内のディレクトリからそのコマンドと同じ名前の実行ファイルを探索し、それを実行します。{{ic|PATH}} に含まれないディレクトリにある実行ファイルを実行するには、実行ファイルへの相対パスや絶対パスを指定する必要があります。例えば、{{ic|./a.out}} や {{ic|/bin/ls}} といった形です。
{{Note|セキュリティ上の理由により {{ic|PATH}} にはカレント作業ディレクトリ ({{ic|.}}) を含めないことが推奨されます。ユーザが騙されて、悪意のあるコマンドを実行してしまうかもしれないからです。}}
; PWD:
[[Wikipedia:ja:Pwd|作業ディレクトリへのパス]]が入ります。
; OLDPWD:
前の作業ディレクトリへのパスが入ります。つまり、最後に ''cd'' を実行する前の {{ic|PWD}} です。
; MAIL:
受信したメールの保存場所が入ります。伝統的な設定は {{ic|/var/spool/mail/$LOGNAME}} です。

=== ネットワークプロキシ ===

; ftp_proxy:
FTP [[プロキシサーバー]]が入ります。
ftp_proxy="<nowiki>ftp://192.168.0.1:21</nowiki>"
;http_proxy:
HTTP [[プロキシサーバー]]が入ります。
http_proxy="<nowiki>http://192.168.0.1:80</nowiki>"

=== ドキュメントのパス ===

; MANPATH:
''man'' が man ページを探索するディレクトリのリストがコンマで区切られて格納されます。
{{Note|{{ic|/etc/profile}} に "Man is much better than us at figuring this out" (man は我々よりずっと上手くこれを解決する) と書いてあるとおり、一般的にこの変数はデフォルトのままにしておくべきです。 {{man|5|manpath}} を参照。}}
; INFODIR:
''info'' コマンドが info ページを探索するディレクトリのリストがコンマで区切られて格納されます。例: {{ic|/usr/share/info:/usr/local/share/info}}。

=== デフォルトプログラム ===

; SHELL:
ユーザの[https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#tag_08_03 優先シェル]へのパスが含まれます。この変数の値は、現在実行中のシェルである必要はないことに注意してください。この変数に値がない場合、[[Bash]] は自動的に {{ic|/etc/passwd}} で定義されているユーザのログインシェルに設定するか、判断できない場合は {{ic|/bin/sh}} にします。
; PAGER:
ファイルの内容を一覧表示するために使用されるプログラムを実行するコマンドが含まれます。例: {{ic|/bin/less}}。
; EDITOR:
ファイルの編集に使用される軽量プログラムを実行するコマンドが含まれています (例:{{ic|/usr/bin/nano}})。例えば、以下の例のように、[[X]] 下では ''gedit'' を使い、それ以外では ''nano'' を使うように設定するインタラクティブスイッチを記述することができます:
[ -n "$DISPLAY" ] && export EDITOR=gedit || export EDITOR=nano
; VISUAL:
メールの編集などより高度な作業に使われる本格的なエディタを実行するコマンドが含まれています (例: {{ic|vi}}、[[vim]]、[[emacs]] など)。
; TERMINAL:
ユーザの優先ターミナルエミュレータを実行するコマンドが含まれます。これは、現在実行中のターミナル ({{ic|TERM}}) と同じであるとは限りません。
; BROWSER:
ウェブブラウザへのパスが含まれています。グラフィカル環境 ([[X]] など) が利用できるかに応じてこの変数を動的に変更するようなコードをインタラクティブシェルの設定ファイルに記述しておくと便利です:
[ -n "$DISPLAY" ] && export BROWSER=firefox || export BROWSER=links
{{Tip|{{ic|WAYLAND_DISPLAY}} 環境変数を使うことで、[[Wayland#コンポジタ|Wayland コンポジタ]]が実行されているかどうかに応じてこれらのデフォルトプログラムを設定することができます。}}

=== その他 ===

; TERM:
実行中のターミナル (''term''inal) の種類が格納されます (例: {{ic|xterm-256color}})。この変数は、ターミナル固有の機能を期待する、ターミナル内で実行されるプログラムによって使用されます ({{man|5|terminfo}} を参照)。この変数は、ターミナルエミュレータによって設定されるため、シェルから上書きすることは推奨されません。
; TZ:
ユーザ毎にシステムのタイムゾーンとは異なるタイムゾーンを設定するために使用することができます。{{ic|/usr/share/zoneinfo/}} 内にはタイムゾーンが列挙されているので、これをリファレンスとして使用することができます (例: {{ic|1=TZ=":/usr/share/zoneinfo/Pacific/Fiji"}})。{{ic|TZ}} 変数に zoneinfo ファイルを指定する場合、[https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html GNU マニュアル] に従ってコロンで始める必要があります。

=== シェル環境の検出 ===

シェル環境を検出するテストは、[https://gitlab.com/jdorel-documentation/shell-environment-detection シェル環境の検出に関して書かれたリポジトリ]を見てください。これには、ログイン/インタラクティブシェル、Xorg セッション、TTY、SSH セッションの検出も含まれています。

== 参照 ==

* [[Gentoo:Handbook:X86/Working/EnvVar]]
* [https://help.ubuntu.com/community/EnvironmentVariables Ubuntu Community Wiki - Environment Variables]

{{TranslationStatus|Environment variables|2026-03-29|869026}}

Plasma Login Manager

2026-03-29T09:31:47Z

AshMyzk: ページの作成:「Category:KDE Category:ディスプレイマネージャ en:Plasma Login Manager it:Plasma Login Manager zh-hans:Plasma Login Manager {{Related articles start}} {{Related|ディスプレイマネージャ}} {{Related|KDE}} {{Related articles end}} [https://invent.kde.org/plasma/plasma-login-manager/ Plasma Login Manager 上流]のページより (日訳): :Plasma Login は、KDE Plasma のためのディスプレイマネージャを提供…」

[[Category:KDE]]
[[Category:ディスプレイマネージャ]]
[[en:Plasma Login Manager]]
[[it:Plasma Login Manager]]
[[zh-hans:Plasma Login Manager]]
{{Related articles start}}
{{Related|ディスプレイマネージャ}}
{{Related|KDE}}
{{Related articles end}}

[https://invent.kde.org/plasma/plasma-login-manager/ Plasma Login Manager 上流]のページより (日訳):

:Plasma Login は、KDE Plasma のための[[ディスプレイマネージャ]]を提供します。[[SDDM]] からフォークされ、greeter、壁紙プラグインの統合、システム設定モジュール ([[KDE#KCM|KCM]]) を提供する新しいフロントエンドを搭載しています。

== インストール ==

{{Pkg|plasma-login-manager}} パッケージを[[インストール]]してください。

[[ディスプレイマネージャ#ディスプレイマネージャをロードする]] に従って Plasma Login Manager を起動時に起動してください。

{{Tip|
SDDM から移行する場合は、先に {{ic|sddm.service}} を[[無効化]]することを忘れないでください。

移行完了後、コマンド {{ic|userdel -r sddm}} を root ユーザとして実行することで、もはや使用されない {{ic|sddm}} ユーザをクリーンアップし削除することもできます。
}}

== 設定 ==

インストール後、システム設定アプリに ''Login Screen'' という新しいセクションが追加されます。ここから、設定をグラフィカルに行うことができます。

手動で設定を変更するには、設定ファイル {{ic|/etc/plasmalogin.conf}} を作成してください。あるいは、{{ic|/etc/plasmalogin.conf.d/}} 内に設定ファイルを追加してください。

=== カスタム壁紙のプラグイン ===

Plasma Login Manager の KCM (システム設定モジュール) には、サードパーティあるいはカスタムの壁紙プラグインが ({{ic|/usr/share/plasma/wallpapers/}} に正しくインストールされていたとしても) 表示されない場合があります。

そのような場合にカスタムの壁紙プラグインを使用するには、設定ファイルでプラグイン ID を手動で指定してください。プラグイン ID を調べてください ({{ic|/usr/share/plasma/wallpapers/}} 内のフォルダ名、あるいはプラグインの {{ic|metadata.json}} ファイル内の {{ic|Id}} フィールドです)。設定ファイルを以下のように[[編集]]してください:

{{hc|/etc/plasmalogin.conf|2=
[Greeter]
WallpaperPluginId=''your.plugin.id''
}}

ファイルを保存し、変更を適用するためにログアウトか再起動してください。

=== 自動ログイン ===

Plasma Login は、設定ファイルで自動ログインを設定できます。例:

{{hc|/etc/plasmalogin.conf.d/autologin.conf|2=
[Autologin]
User=john
Session=plasma.desktop
}}

この設定により、システムのブート時に KDE Plasma セッションが {{ic|john}} ユーザで開始されます。使用できるセッションの種類は、X については {{ic|/usr/share/xsessions/}} で、Wayland については {{ic|/usr/share/wayland-sessions/}} で確認できます。

セッションをロックすると同時に KDE Plasma に自動的にログインするには (自動起動されたアプリの準備ができるまで待つためなど)、[[KDE#ロックスクリーン]] を見てください。

=== パスワードレスログイン ===

Plasma Login では、パスワードなしで一部のアカウントにログインできるようにすることができます。これは、ユーザはログインするアカウントを選択する必要のある自動ログインとは異なり、またアカウントのパスワードを空の文字列する (この場合、インタラクティブユーザしかログインできず、[[SSH]] 経由などリモートユーザはログインできません) こととも異なります。

Plasma Login は [[PAM]] を経由するため、PAM 用の Plasma Login 設定ファイル {{ic|/etc/pam.d/plasmalogin}} を作成する必要があります:

{{hc|/etc/pam.d/plasmalogin|2=
#%PAM-1.0
auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
auth include system-login
account include system-login
session include system-login
password include system-login
}}

KDE Plasma のロックスクリーンをパスワードなしでアンロックできるようにするために、PAM 用の KDE 設定ファイル {{ic|/etc/pam.d/kde}} も作成してください:

{{hc|/etc/pam.d/kde|2=
#%PAM-1.0
auth sufficient pam_succeed_if.so user ingroup nopasswdlogin
auth include system-login
account include system-login
session include system-login
password include system-login
}}

さらに、パスワードを入力せずにインタラクティブにログインできるようにするために、{{ic|nopasswdlogin}} [[ユーザグループ]]に自身のユーザを追加する必要があります。

=== ログイン時に KDE Wallet を自動的にアンロックする ===

[[KDE Wallet#ログイン時に KDE ウォレットを自動的にアンロック]] を参照してください。

== 参照 ==

* [[Arch ブートプロセス]]
* [[:Category:ブートスプラッシュ]] — ブート過程の見た目をよりスムーズに変化させるために

{{TranslationStatus|Plasma Login Manager|2026-03-29|868599}}

環境変数

2026-03-29T08:59:08Z

AshMyzk: /* デスクトップ環境の検出 */ 修正

[[Category:システム管理]]
[[de:Umgebungsvariablen]]
[[en:Environment variables]]
[[es:Environment variables]]
[[hu:Environment variables]]
[[pt:Environment variables]]
[[ru:Environment variables]]
[[zh-hans:Environment variables]]
{{Related articles start}}
{{Related|デフォルトアプリケーション}}
{{Related|systemd/ユーザー#環境変数}}
{{Related articles end}}
環境変数は、1つ以上のアプリケーションによって使用されるデータを含む名前付きのオブジェクトです。簡単に言えば、名前と値を持つ変数です。環境変数の値には、例えばファイルシステム内のすべての実行可能ファイルの場所、使用すべきデフォルトのエディタ、またはシステムロケールの設定などが含まれます。Linux に不慣れなユーザーは、このような設定の管理方法を少し扱いづらいと感じることがよくあります。しかし、環境変数は、複数のアプリケーションやプロセス間で設定を共有する簡単な方法を提供します。

== ユーティリティ ==

{{Pkg|coreutils}} パッケージには {{man|1|printenv}} と {{man|1|env}} というプログラムが含まれています。現在の環境変数とその値を一覧表示するには:

$ printenv

{{Note|環境変数の中にはユーザ個別のものも存在します。{{ic|printenv}} の出力を非特権ユーザの場合と root ユーザの場合で比較して確認してみましょう。}}

''env'' ユーティリティを使うことで、環境変数を変更してコマンドを実行することができます。以下の例では、環境変数 {{ic|EDITOR}} を {{ic|vim}} に設定して ''xterm'' を起動します。以下のコマンドを実行しても、グローバルな {{ic|EDITOR}} 変数には影響を与えません。

$ env EDITOR=vim xterm

[[シェル]] の {{man|1p|set}} 組み込みコマンドを使えば、シェルオプションの値を変更したり、位置のパラメータを設定したり、シェル変数の名前とその値を出力したりできます。

各プロセスはその環境変数を {{ic|/proc/$PID/environ}} ファイルに保存しています。このファイルには、ヌル文字 ({{ic|\x0}}) で区切られたキーと値のペアが含まれています。[[sed]] を使用すると、より読み易い形式で取得できます。例: {{ic|sed 's:\x0:\n:g' /proc/$PID/environ}}。

== 変数の定義 ==

環境を不必要に汚染しないために、変数のスコープを制限するように努めるべきです。実際、グラフィカルセッションや systemd サービスでは、変数を有効にするために特定の場所で設定することが要求されます。環境変数のスコープは、それらが影響を与えるコンテキストに分けられます:

* [[#グローバル|グローバル]]: あらゆるユーザが実行する全プログラム。Systemd サービスは含まれません。
* [[#ユーザーごと|ユーザ別]]: 特定のユーザが実行する全プログラム。Systemd ユーザサービス ([[systemd/ユーザー#環境変数]] を参照) やグラフィカルアプリケーション ([[#グラフィック環境]] を参照) は含まれません。

=== グローバル ===

==== シェルの初期化ファイルを使う ====

大半の Linux ディストリビューションは、あなたに {{ic|/etc/profile}} 等のファイルに環境変数の追加・変更を行うよう指示します。また、{{ic|/etc/locale.conf}} のような変数設定を含むパッケージ固有の設定ファイルがあることも覚えておいてください。環境変数の維持・管理は必ず行い、環境変数を含むことができる多数のファイルに注意を払うようにしてください。原則的に、あらゆるシェルスクリプトは環境変数の初期化に使うことができますが、以下のような UNIX の慣例に従い特定のファイルでのみ行われるべきです。

以下のファイルは、システムのグローバルな環境変数を定義するために使用できますが、それぞれに異なる制限があります:

* {{ic|/etc/environment}} は [[#pam_env を使う|pam_env モジュール]]によって使用され、シェルに依存しないため、スクリプトやグロブ展開は使用できません。このファイルは、{{ic|1=''変数=値''}} という形式しか受け入れません。
* {{ic|/etc/profile}} は、ログインシェル''のみ''に対して変数を初期化します。しかし、このファイルはスクリプト (例: {{ic|/etc/profile.d/}} 内にあるファイル) を実行し、すべての [[wikipedia:ja:Bourne Shell|Bourne shell]] 互換シェルで使用することができます。
* シェル固有の設定ファイル - [[シェル]]のグローバルな設定ファイルで、変数の初期化やスクリプトの実行を行います。例えば [[Bash#設定ファイル]] (例: {{ic|~/.bashrc}})) や [[Zsh#スタートアップ/シャットダウンファイル]] (例: {{ic|~/.zshrc}}) です。

以下の Bash ヘルパ関数を使えば、複数のディレクトリを {{ic|PATH}} 環境変数に末尾追加することができます。環境変数を定義しているファイル ({{ic|~/.bashrc}} など) の戦闘にこの関数を追加してください。この関数は、ファイルシステム上に実際に存在するディレクトリのみを追加し、重複するエントリは作成しません。

{{bc|<nowiki>
add_paths() {
for d in "$@"; do
[[ -d "$d" && ! "$PATH" =~ (^|:)$d(:|$) ]] && PATH="$PATH:$d"
done
}

add_paths ~/bin ~/scripts
</nowiki>}}

ほとんどのシェル (Bash、Zsh、[[fish]] を含む) では、{{ic|export}} コマンドを使って環境に変数を追加することができます。これにより、{{ic|~/my-environment.sh}} などのように通常のファイルで環境変数を定義することができます:

{{hc|~/my-environment.sh|2=
export EDITOR=vim
export XDG_CACHE_HOME="$HOME/.cache"
export XDG_CONFIG_HOME="$HOME/.config"
export XDG_DATA_HOME="$HOME/.local/share"
export XDG_STATE_HOME="$HOME/.local/state"
}}

このファイルは、シェルのスタートアップファイルから source することができます:

{{hc|~/.bashrc|source ~/my-environment.sh}}
{{hc|~/.config/fish/config.fish|source ~/my-environment.sh}}

==== pam_env を使う ====

{{man|8|pam_env}} [[PAM]] モジュールは、環境変数の設定を以下のファイルから順番にロードします: {{ic|/etc/security/pam_env.conf}} と {{ic|/etc/environment}} の順です。

{{Note|
* これらのファイルは、他のファイル、特に、{{ic|~/.profile}}、{{ic|~/.bash_profile}}、{{ic|~/.zshenv}} より前に読み込まれます。
* 非推奨の {{ic|~/.pam_environment}} はもう読み込まれません。{{Bug|68945}} を参照してください。
}}

{{ic|/etc/environment}} では、{{ic|1=''変数''=''値''}} というペアを1行に1つずつ記述しなければなりません。例:

{{hc|/etc/environment|2=
EDITOR=nano
}}

{{ic|/etc/security/pam_env.conf}} は以下の形式で記述します:

{{hc|/etc/security/pam_env.conf|2=
VARIABLE [DEFAULT=''value''] [OVERRIDE=''value'']
}}

{{ic|@{HOME} }} と {{ic|@{SHELL} }} は、{{ic|/etc/passwd}} で定義されているものに拡張される特別な変数です。次の例は、{{ic|HOME}} 環境変数を別の変数に展開する方法を示しています:

{{hc|/etc/security/pam_env.conf|2=
XDG_CONFIG_HOME DEFAULT=@{HOME}/.config
}}

{{Note|変数 {{ic|${HOME} }} および {{ic|${SHELL} }} は、{{ic|HOME}} および {{ic|SHELL}} 環境変数にはリンクされていません。これらはデフォルトでは設定されていません。}}

また、この形式では、{{ic|${''VARIABLE''} }} を使って、既に定義されている変数を他の変数の値で展開することができます。例えば:

GOPATH DEFAULT=${XDG_DATA_HOME}/go

{{ic|1=''VARIABLE''=''value''}} のペアも可能ですが、これらのペアでは変数の展開はサポートされていません。詳しくは {{man|5|pam_env.conf}} を参照してください。

=== ユーザーごと ===

環境変数をグローバルに定義したくないという時もあるでしょう。例えば、{{ic|PATH}} に {{ic|/home/my_user/bin}} を追加したいが、システム上の他のユーザーには同じ {{ic|PATH}} を使って欲しくないという場合が考えられます。様々なファイルを使うことでローカルに環境変数を定義することができます:

* [[シェル]]のユーザ設定ファイル。例えば、[[Bash#設定ファイル]] や [[Zsh#スタートアップ/シャットダウンファイル]]。
** あなたが開くターミナル (例: コマンドラインアプリケーションのみ) に変数のスコープを制限しない限り、ログインシェルの変数も変更されます。
* [[systemd/ユーザー#環境変数|systemd ユーザ環境変数]]は {{ic|~/.config/environment.d/*.conf}} から読み込まれます。

ローカルで使用するディレクトリを {{ic|PATH}} に追加するには、{{ic|~/.bash_profile}} に次のように記述します:

export PATH="${PATH}:/home/my_user/bin"

変数をアップデートするために、再ログインするかファイルを [[source]] してください: {{ic|$ source ~/.bash_profile}}

{{Note|dbus デーモンや systemd のユーザインスタンスは、{{ic|~/.bashrc}} などのような場所で設定された環境変数を継承しません。これはつまり、dbus によってアクティブ化されたプログラム ([[GNOME Files]] など) は、そのような変数をデフォルトで使用しないことを意味します。[[Systemd/ユーザー#環境変数]] を参照してください。}}

{{Tip|{{ic|export -p}} を実行することで、ユーザセッションに対して宣言されたグローバルな環境変数とローカルな環境変数を見ることができます。}}

==== グラフィック環境 ====

環境変数がグラフィカルなアプリケーションにしか影響しない場合は、グラフィカルセッション内でのみ設定することにより、その範囲を制限することができます。スコープを大きい順に並べると:

* [[#Xorg セッションごと]] および [[#Wayland セッションごと]] - DE を含むグラフィカルセッション全体に影響します。
* [[#デスクトップ環境セッションごと]] - グラフィカルセッション内で生成されたアプリケーションに影響を与えます。DE 自体にも影響を与える可能性があります。
* [[#アプリケーションごと]] - 特定のグラフィカルアプリケーションだけに影響します。

===== デスクトップ環境セッションごと =====

一部のグラフィカル環境 (例えば [[KDE Plasma]]) は、ログイン時のシェルスクリプト実行をサポートしており、環境変数の設定に利用することができます。例としては [[KDE#自動起動]] を参照してください。

===== Xorg セッションごと =====

Xorg セッションの環境を変更する手順は、Xorg セッションの起動方法によって異なります:
* ほとんどの[[ディスプレイマネージャ]]は [[xprofile]] を読み込みます。
* [[startx]] と [[SLiM]] は [[xinitrc]] を実行します。
* [[XDM]] は {{ic|~/.xsession}} を実行します: [[XDM#セッションの定義]] を参照して下さい。
* [[LightDM]][https://gitlab.archlinux.org/archlinux/packaging/packages/lightdm/-/blob/main/Xsession]、[[Plasma login manager]][https://github.com/KDE/plasma-login-manager/blob/master/data/scripts/Xsession]、[[SDDM]][https://github.com/sddm/sddm/blob/master/data/scripts/Xsession] は、ログインシェルのスタートアップスクリプトも読み込みます。例えば、[[bash]] の場合は {{ic|~/.bash_profile}}、[[zsh]] の場合は {{ic|~/.zprofile}} および {{ic|~/.zlogin}} です。

スクリプトの終わりはどのファイルであるかに依存し、高度な構文は使用するシェルに依存しますが、基本的な使い方は普遍的です:

{{hc|~/.xprofile, ~/.xinitrc, or ~/.xsession|2=
...
export ''GUI_VAR''=''value''
...
}}

===== Wayland セッションごと =====

[[Wayland]] は Xorg 関連のファイルを起動しないので、[[GDM]] と [[KDE Plasma]] は代わりに [[systemd/ユーザー#環境変数|systemd ユーザ環境変数]]を読み込みます。

{{hc|~/.config/environment.d/envvars.conf|2=
''GUI_VAR''=''value''
}}

Wayland セッションをサポートする他のディスプレイマネージャ (例: [[SDDM]]) は、まだこれを直接はサポートしていません。しかし、[[LightDM]]、[[Plasma login manager]]、[[SDDM]] はログインシェルのスタートアップスクリプトを Wayland セッションでも読み込みます。

[[greetd]] も {{ic|/etc/profile}} および {{ic|~/.profile}} を読み込みます。この動作は、デフォルトで有効になっている {{ic|source_profile}} 設定によって制御されます。

{{ic|~/.bash_profile}} などのスタートアップスクリプトを読み込むディスプレイマネージャを使用していて、{{ic|environment.d}} を使用したい場合、以下のように読み込むことができます:

{{hc|~/.bash_profile|
# systemd-environment-d-generator(8) を使用して環境を生成し、その変数をエクスポートする
set -o allexport
source <(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)
set +o allexport
}}
{{Note|{{ic|/usr/lib/systemd/user-environment-generators}} にある他のジェネレーター、例えば {{ic|60-flatpak}} は環境変数の値を引用符で囲まない場合があります。この場合、出力は {{ic|export -- "$(/usr/lib/systemd/user-environment-generators/60-flatpak)"}} を使用して読み込む必要があります。}}

===== アプリケーションごと =====

セッション全体ではなく、特定のアプリケーションにのみ環境変数を設定するには、そのアプリケーションの ''.desktop'' ファイルを編集してください。その方法は [[デスクトップエントリ#環境変数の変更]] を参照してください。

[[Steam]] ゲームでは、起動オプションを編集することでプログラムの環境を設定することができます。[[Steam#起動オプション]] を参照してください。

=== セッションまたはシェルごと ===

時として、一時的な変数のみが必要である場合もあります。特定のディレクトリ内の実行ファイルを実行する際に一時的に絶対パスを入力する手間を省きたい場合や、一時的な短いシェルスクリプトでそのパスを使用したい場合があるでしょう。

例えば、セッション固有のディレクトリを {{ic|PATH}} に追加するには:

$ export PATH="${PATH}:/home/my_user/tmp/usr/bin"

シェル固有のディレクトリのみを {{ic|PATH}} に追加するには:

$ PATH="${PATH}:/home/my_user/tmp/usr/bin"

Bash では、{{ic|PATH}} は既にデフォルトで export されているので、上記のどちらの方法を用いても、変数を上書きしない限り、変数の変更がサブプロセスから見えてしまいます。export された変数とされていない変数の違いをよりわかりやすく比較するには、以下を実行してみてください:

$ MYVAR="shell-only"
$ bash -c 'echo $MYVAR' # 何も表示されない

$ export MYVAR="session-wide"
$ bash -c 'echo $MYVAR' # 表示される。すなわち、セッション全体に反映されている

== 例 ==

以下のセクションでは Linux システムで一般的に使われている環境変数を並べており、それぞれの値について説明しています。

=== デスクトップ環境の検出 ===

; XDG_CURRENT_DESKTOP:
コロンで区切られた文字列リストを含む [[freedesktop.org]] 変数。現在の[[デスクトップ環境]]を示します[https://specifications.freedesktop.org/mime-apps-spec/latest/file.html]。活発に開発されているデスクトップ環境の標準化された値として次があります: {{ic|GNOME}}、{{ic|GNOME-Flashback}}、{{ic|KDE}}、{{ic|LXDE}}、{{ic|LXQt}}、{{ic|MATE}}、{{ic|TDE}}、{{ic|Unity}}、{{ic|XFCE}}、{{ic|EDE}}、{{ic|Cinnamon}}、{{ic|Pantheon}}、{{ic|DDE}} [https://specifications.freedesktop.org/menu-spec/latest/onlyshowin-registry.html]。
{{Tip|
* Cinnamon は、他のデスクトップ環境[https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/commit/be0c630a19aa1788ef731def911770ce497d6ba3 より後に]登録されました。そのため、[[Qt]][https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixtheme.cpp#L156] など一部のソフトウェアは、登録前の値である {{ic|X-CINNAMON}} を期待します。
* {{ic|Hyprland}} は、[[Hyprland]] 用として非公式に認められています。
}}
; XDG_SESSION_DESKTOP:
{{ic|XDG_CURRENT_DESKTOP}} と似ていますが、単一の文字列しか許可しません。その名前にも関わらず、[https://gitlab.gnome.org/GNOME/gtk/-/issues/1224#note_270915 これは freedesktop.org によって標準化されたものではありません]。
; DE:
使用中のデスクトップ環境 (''d''esktop ''e''nvironment) を示すレガシーな変数です。どのような値を取りうるかについての中心的なドキュメントはありませんが、[[xdg-utils#環境変数|xdg-utils]] は多くのデスクトップ環境についてのリファレンスを提供しています。
; DESKTOP_SESSION:
これもレガシーな変数です。{{ic|DE}} に似ていますが、それよりは一般的ではありません。セッションの ({{ic|/usr/share/xsessions/}} 内の) [[デスクトップエントリ]]へのパスを格納できます [https://github.com/qt/qtbase/blob/6.3/src/gui/platform/unix/qgenericunixservices.cpp#L92-L107]。
; WINDOW_MANAGER:
デスクトップ環境で使用する[[ウィンドウマネージャ]]を''選択''するために時々使われる変数です。他のプログラムが読み取るために、既に選択されているディスプレイマネージャやデスクトップ環境によって設定される他の変数とは対照的です。
; DISPLAY:
ホスト、ディスプレイ、スクリーンを指定するために X Window System によって使用されます。形式は {{ic|''ホスト名'':''ディスプレイ''.''スクリーン''}} です。ディスプレイとは、共通の入力デバイス群 (キーボードやマウスなど) を共有するスクリーンの集まりを指します。ホスト名は、ディスプレイが接続されるマシンの名前を指定するためにかつて使用されていましたが、X クライアントと同じコンピュータ上で X サーバが実行される場合は空欄になっているはずです。詳細は {{man|7|X}} を参照してください。
; WAYLAND_DISPLAY:
Wayland における {{ic|DISPLAY}} のようなものです。コンポジタによって設定されます。これが設定されていない場合、アプリケーションは {{ic|wayland-0}} を使おうと試みます。
; XAUTHORITY:
{{ic|.Xauthority}} ファイルへのパスです。このファイルには、X Window Server にアクセスするための資格情報が入っています。これは、認証のために X サーバに送られるクッキー (任意のデータ) の形で保存されます (例: {{ic|MIT-MAGIC-COOKIE-1}})。

=== システムやセッションのパス ===

; HOME:
現在のユーザのホームディレクトリへのパスが格納されます。この変数は、アプリケーションが現在のユーザに関連した設定ファイル等を見つけるために使うことができます。
; PATH:
コロンで区切られたディレクトリのリストが格納されています。システムは、この変数に登録されているディレクトリから実行ファイルを探索します。通常のコマンド (''ls''、''systemctl''、''pacman'' など) がシェル (''bash'' や ''zsh'' など) によって解釈される際、シェルは {{ic|PATH}} のリスト内のディレクトリからそのコマンドと同じ名前の実行ファイルを探索し、それを実行します。{{ic|PATH}} に含まれないディレクトリにある実行ファイルを実行するには、実行ファイルへの相対パスや絶対パスを指定する必要があります。例えば、{{ic|./a.out}} や {{ic|/bin/ls}} といった形です。
{{Note|セキュリティ上の理由により {{ic|PATH}} にはカレント作業ディレクトリ ({{ic|.}}) を含めないことが推奨されます。ユーザが騙されて、悪意のあるコマンドを実行してしまうかもしれないからです。}}
; PWD:
[[Wikipedia:ja:Pwd|作業ディレクトリへのパス]]が入ります。
; OLDPWD:
前の作業ディレクトリへのパスが入ります。つまり、最後に ''cd'' を実行する前の {{ic|PWD}} です。
; MAIL:
受信したメールの保存場所が入ります。伝統的な設定は {{ic|/var/spool/mail/$LOGNAME}} です。

=== ネットワークプロキシ ===

; ftp_proxy:
FTP [[プロキシサーバー]]が入ります。
ftp_proxy="<nowiki>ftp://192.168.0.1:21</nowiki>"
;http_proxy:
HTTP [[プロキシサーバー]]が入ります。
http_proxy="<nowiki>http://192.168.0.1:80</nowiki>"

=== ドキュメントのパス ===

; MANPATH:
''man'' が man ページを探索するディレクトリのリストがコンマで区切られて格納されます。
{{Note|{{ic|/etc/profile}} に "Man is much better than us at figuring this out" (man は我々よりずっと上手くこれを解決する) と書いてあるとおり、一般的にこの変数はデフォルトのままにしておくべきです。 {{man|5|manpath}} を参照。}}
; INFODIR:
''info'' コマンドが info ページを探索するディレクトリのリストがコンマで区切られて格納されます。例: {{ic|/usr/share/info:/usr/local/share/info}}。

=== デフォルトプログラム ===

; SHELL:
ユーザの[https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#tag_08_03 優先シェル]へのパスが含まれます。この変数の値は、現在実行中のシェルである必要はないことに注意してください。この変数に値がない場合、[[Bash]] は自動的に {{ic|/etc/passwd}} で定義されているユーザのログインシェルに設定するか、判断できない場合は {{ic|/bin/sh}} にします。
; PAGER:
ファイルの内容を一覧表示するために使用されるプログラムを実行するコマンドが含まれます。例: {{ic|/bin/less}}。
; EDITOR:
ファイルの編集に使用される軽量プログラムを実行するコマンドが含まれています (例:{{ic|/usr/bin/nano}})。例えば、以下の例のように、[[X]] 下では ''gedit'' を使い、それ以外では ''nano'' を使うように設定するインタラクティブスイッチを記述することができます:
[ -n "$DISPLAY" ] && export EDITOR=gedit || export EDITOR=nano
; VISUAL:
メールの編集などより高度な作業に使われる本格的なエディタを実行するコマンドが含まれています (例: {{ic|vi}}、[[vim]]、[[emacs]] など)。
; TERMINAL:
ユーザの優先ターミナルエミュレータを実行するコマンドが含まれます。これは、現在実行中のターミナル ({{ic|TERM}}) と同じであるとは限りません。
; BROWSER:
ウェブブラウザへのパスが含まれています。グラフィカル環境 ([[X]] など) が利用できるかに応じてこの変数を動的に変更するようなコードをインタラクティブシェルの設定ファイルに記述しておくと便利です:
[ -n "$DISPLAY" ] && export BROWSER=firefox || export BROWSER=links
{{Tip|{{ic|WAYLAND_DISPLAY}} 環境変数を使うことで、[[Wayland#コンポジタ|Wayland コンポジタ]]が実行されているかどうかに応じてこれらのデフォルトプログラムを設定することができます。}}

=== その他 ===

; TERM:
実行中のターミナル (''term''inal) の種類が格納されます (例: {{ic|xterm-256color}})。この変数は、ターミナル固有の機能を期待する、ターミナル内で実行されるプログラムによって使用されます ({{man|5|terminfo}} を参照)。この変数は、ターミナルエミュレータによって設定されるため、シェルから上書きすることは推奨されません。
; TZ:
ユーザ毎にシステムのタイムゾーンとは異なるタイムゾーンを設定するために使用することができます。{{ic|/usr/share/zoneinfo/}} 内にはタイムゾーンが列挙されているので、これをリファレンスとして使用することができます (例: {{ic|1=TZ=":/usr/share/zoneinfo/Pacific/Fiji"}})。{{ic|TZ}} 変数に zoneinfo ファイルを指定する場合、[https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html GNU マニュアル] に従ってコロンで始める必要があります。

=== シェル環境の検出 ===

シェル環境を検出するテストは、[https://gitlab.com/jdorel-documentation/shell-environment-detection シェル環境の検出に関して書かれたリポジトリ]を見てください。これには、ログイン/インタラクティブシェル、Xorg セッション、TTY、SSH セッションの検出も含まれています。

== 参照 ==

* [[Gentoo:Handbook:X86/Working/EnvVar]]
* [https://help.ubuntu.com/community/EnvironmentVariables Ubuntu Community Wiki - Environment Variables]

{{TranslationStatus|Environment variables|2026-03-29|869026}}

環境変数

2026-03-29T08:58:22Z

AshMyzk: 同期

[[Category:システム管理]]
[[de:Umgebungsvariablen]]
[[en:Environment variables]]
[[es:Environment variables]]
[[hu:Environment variables]]
[[pt:Environment variables]]
[[ru:Environment variables]]
[[zh-hans:Environment variables]]
{{Related articles start}}
{{Related|デフォルトアプリケーション}}
{{Related|systemd/ユーザー#環境変数}}
{{Related articles end}}
環境変数は、1つ以上のアプリケーションによって使用されるデータを含む名前付きのオブジェクトです。簡単に言えば、名前と値を持つ変数です。環境変数の値には、例えばファイルシステム内のすべての実行可能ファイルの場所、使用すべきデフォルトのエディタ、またはシステムロケールの設定などが含まれます。Linux に不慣れなユーザーは、このような設定の管理方法を少し扱いづらいと感じることがよくあります。しかし、環境変数は、複数のアプリケーションやプロセス間で設定を共有する簡単な方法を提供します。

== ユーティリティ ==

{{Pkg|coreutils}} パッケージには {{man|1|printenv}} と {{man|1|env}} というプログラムが含まれています。現在の環境変数とその値を一覧表示するには:

$ printenv

{{Note|環境変数の中にはユーザ個別のものも存在します。{{ic|printenv}} の出力を非特権ユーザの場合と root ユーザの場合で比較して確認してみましょう。}}

''env'' ユーティリティを使うことで、環境変数を変更してコマンドを実行することができます。以下の例では、環境変数 {{ic|EDITOR}} を {{ic|vim}} に設定して ''xterm'' を起動します。以下のコマンドを実行しても、グローバルな {{ic|EDITOR}} 変数には影響を与えません。

$ env EDITOR=vim xterm

[[シェル]] の {{man|1p|set}} 組み込みコマンドを使えば、シェルオプションの値を変更したり、位置のパラメータを設定したり、シェル変数の名前とその値を出力したりできます。

各プロセスはその環境変数を {{ic|/proc/$PID/environ}} ファイルに保存しています。このファイルには、ヌル文字 ({{ic|\x0}}) で区切られたキーと値のペアが含まれています。[[sed]] を使用すると、より読み易い形式で取得できます。例: {{ic|sed 's:\x0:\n:g' /proc/$PID/environ}}。

== 変数の定義 ==

環境を不必要に汚染しないために、変数のスコープを制限するように努めるべきです。実際、グラフィカルセッションや systemd サービスでは、変数を有効にするために特定の場所で設定することが要求されます。環境変数のスコープは、それらが影響を与えるコンテキストに分けられます:

* [[#グローバル|グローバル]]: あらゆるユーザが実行する全プログラム。Systemd サービスは含まれません。
* [[#ユーザーごと|ユーザ別]]: 特定のユーザが実行する全プログラム。Systemd ユーザサービス ([[systemd/ユーザー#環境変数]] を参照) やグラフィカルアプリケーション ([[#グラフィック環境]] を参照) は含まれません。

=== グローバル ===

==== シェルの初期化ファイルを使う ====

大半の Linux ディストリビューションは、あなたに {{ic|/etc/profile}} 等のファイルに環境変数の追加・変更を行うよう指示します。また、{{ic|/etc/locale.conf}} のような変数設定を含むパッケージ固有の設定ファイルがあることも覚えておいてください。環境変数の維持・管理は必ず行い、環境変数を含むことができる多数のファイルに注意を払うようにしてください。原則的に、あらゆるシェルスクリプトは環境変数の初期化に使うことができますが、以下のような UNIX の慣例に従い特定のファイルでのみ行われるべきです。

以下のファイルは、システムのグローバルな環境変数を定義するために使用できますが、それぞれに異なる制限があります:

* {{ic|/etc/environment}} は [[#pam_env を使う|pam_env モジュール]]によって使用され、シェルに依存しないため、スクリプトやグロブ展開は使用できません。このファイルは、{{ic|1=''変数=値''}} という形式しか受け入れません。
* {{ic|/etc/profile}} は、ログインシェル''のみ''に対して変数を初期化します。しかし、このファイルはスクリプト (例: {{ic|/etc/profile.d/}} 内にあるファイル) を実行し、すべての [[wikipedia:ja:Bourne Shell|Bourne shell]] 互換シェルで使用することができます。
* シェル固有の設定ファイル - [[シェル]]のグローバルな設定ファイルで、変数の初期化やスクリプトの実行を行います。例えば [[Bash#設定ファイル]] (例: {{ic|~/.bashrc}})) や [[Zsh#スタートアップ/シャットダウンファイル]] (例: {{ic|~/.zshrc}}) です。

以下の Bash ヘルパ関数を使えば、複数のディレクトリを {{ic|PATH}} 環境変数に末尾追加することができます。環境変数を定義しているファイル ({{ic|~/.bashrc}} など) の戦闘にこの関数を追加してください。この関数は、ファイルシステム上に実際に存在するディレクトリのみを追加し、重複するエントリは作成しません。

{{bc|<nowiki>
add_paths() {
for d in "$@"; do
[[ -d "$d" && ! "$PATH" =~ (^|:)$d(:|$) ]] && PATH="$PATH:$d"
done
}

add_paths ~/bin ~/scripts
</nowiki>}}

ほとんどのシェル (Bash、Zsh、[[fish]] を含む) では、{{ic|export}} コマンドを使って環境に変数を追加することができます。これにより、{{ic|~/my-environment.sh}} などのように通常のファイルで環境変数を定義することができます:

{{hc|~/my-environment.sh|2=
export EDITOR=vim
export XDG_CACHE_HOME="$HOME/.cache"
export XDG_CONFIG_HOME="$HOME/.config"
export XDG_DATA_HOME="$HOME/.local/share"
export XDG_STATE_HOME="$HOME/.local/state"
}}

このファイルは、シェルのスタートアップファイルから source することができます:

{{hc|~/.bashrc|source ~/my-environment.sh}}
{{hc|~/.config/fish/config.fish|source ~/my-environment.sh}}

==== pam_env を使う ====

{{man|8|pam_env}} [[PAM]] モジュールは、環境変数の設定を以下のファイルから順番にロードします: {{ic|/etc/security/pam_env.conf}} と {{ic|/etc/environment}} の順です。

{{Note|
* これらのファイルは、他のファイル、特に、{{ic|~/.profile}}、{{ic|~/.bash_profile}}、{{ic|~/.zshenv}} より前に読み込まれます。
* 非推奨の {{ic|~/.pam_environment}} はもう読み込まれません。{{Bug|68945}} を参照してください。
}}

{{ic|/etc/environment}} では、{{ic|1=''変数''=''値''}} というペアを1行に1つずつ記述しなければなりません。例:

{{hc|/etc/environment|2=
EDITOR=nano
}}

{{ic|/etc/security/pam_env.conf}} は以下の形式で記述します:

{{hc|/etc/security/pam_env.conf|2=
VARIABLE [DEFAULT=''value''] [OVERRIDE=''value'']
}}

{{ic|@{HOME} }} と {{ic|@{SHELL} }} は、{{ic|/etc/passwd}} で定義されているものに拡張される特別な変数です。次の例は、{{ic|HOME}} 環境変数を別の変数に展開する方法を示しています:

{{hc|/etc/security/pam_env.conf|2=
XDG_CONFIG_HOME DEFAULT=@{HOME}/.config
}}

{{Note|変数 {{ic|${HOME} }} および {{ic|${SHELL} }} は、{{ic|HOME}} および {{ic|SHELL}} 環境変数にはリンクされていません。これらはデフォルトでは設定されていません。}}

また、この形式では、{{ic|${''VARIABLE''} }} を使って、既に定義されている変数を他の変数の値で展開することができます。例えば:

GOPATH DEFAULT=${XDG_DATA_HOME}/go

{{ic|1=''VARIABLE''=''value''}} のペアも可能ですが、これらのペアでは変数の展開はサポートされていません。詳しくは {{man|5|pam_env.conf}} を参照してください。

=== ユーザーごと ===

環境変数をグローバルに定義したくないという時もあるでしょう。例えば、{{ic|PATH}} に {{ic|/home/my_user/bin}} を追加したいが、システム上の他のユーザーには同じ {{ic|PATH}} を使って欲しくないという場合が考えられます。様々なファイルを使うことでローカルに環境変数を定義することができます:

* [[シェル]]のユーザ設定ファイル。例えば、[[Bash#設定ファイル]] や [[Zsh#スタートアップ/シャットダウンファイル]]。
** あなたが開くターミナル (例: コマンドラインアプリケーションのみ) に変数のスコープを制限しない限り、ログインシェルの変数も変更されます。
* [[systemd/ユーザー#環境変数|systemd ユーザ環境変数]]は {{ic|~/.config/environment.d/*.conf}} から読み込まれます。

ローカルで使用するディレクトリを {{ic|PATH}} に追加するには、{{ic|~/.bash_profile}} に次のように記述します:

export PATH="${PATH}:/home/my_user/bin"

変数をアップデートするために、再ログインするかファイルを [[source]] してください: {{ic|$ source ~/.bash_profile}}

{{Note|dbus デーモンや systemd のユーザインスタンスは、{{ic|~/.bashrc}} などのような場所で設定された環境変数を継承しません。これはつまり、dbus によってアクティブ化されたプログラム ([[GNOME Files]] など) は、そのような変数をデフォルトで使用しないことを意味します。[[Systemd/ユーザー#環境変数]] を参照してください。}}

{{Tip|{{ic|export -p}} を実行することで、ユーザセッションに対して宣言されたグローバルな環境変数とローカルな環境変数を見ることができます。}}

==== グラフィック環境 ====

環境変数がグラフィカルなアプリケーションにしか影響しない場合は、グラフィカルセッション内でのみ設定することにより、その範囲を制限することができます。スコープを大きい順に並べると:

* [[#Xorg セッションごと]] および [[#Wayland セッションごと]] - DE を含むグラフィカルセッション全体に影響します。
* [[#デスクトップ環境セッションごと]] - グラフィカルセッション内で生成されたアプリケーションに影響を与えます。DE 自体にも影響を与える可能性があります。
* [[#アプリケーションごと]] - 特定のグラフィカルアプリケーションだけに影響します。

===== デスクトップ環境セッションごと =====

一部のグラフィカル環境 (例えば [[KDE Plasma]]) は、ログイン時のシェルスクリプト実行をサポートしており、環境変数の設定に利用することができます。例としては [[KDE#自動起動]] を参照してください。

===== Xorg セッションごと =====

Xorg セッションの環境を変更する手順は、Xorg セッションの起動方法によって異なります:
* ほとんどの[[ディスプレイマネージャ]]は [[xprofile]] を読み込みます。
* [[startx]] と [[SLiM]] は [[xinitrc]] を実行します。
* [[XDM]] は {{ic|~/.xsession}} を実行します: [[XDM#セッションの定義]] を参照して下さい。
* [[LightDM]][https://gitlab.archlinux.org/archlinux/packaging/packages/lightdm/-/blob/main/Xsession]、[[Plasma login manager]][https://github.com/KDE/plasma-login-manager/blob/master/data/scripts/Xsession]、[[SDDM]][https://github.com/sddm/sddm/blob/master/data/scripts/Xsession] は、ログインシェルのスタートアップスクリプトも読み込みます。例えば、[[bash]] の場合は {{ic|~/.bash_profile}}、[[zsh]] の場合は {{ic|~/.zprofile}} および {{ic|~/.zlogin}} です。

スクリプトの終わりはどのファイルであるかに依存し、高度な構文は使用するシェルに依存しますが、基本的な使い方は普遍的です:

{{hc|~/.xprofile, ~/.xinitrc, or ~/.xsession|2=
...
export ''GUI_VAR''=''value''
...
}}

===== Wayland セッションごと =====

[[Wayland]] は Xorg 関連のファイルを起動しないので、[[GDM]] と [[KDE Plasma]] は代わりに [[systemd/ユーザー#環境変数|systemd ユーザ環境変数]]を読み込みます。

{{hc|~/.config/environment.d/envvars.conf|2=
''GUI_VAR''=''value''
}}

Wayland セッションをサポートする他のディスプレイマネージャ (例: [[SDDM]]) は、まだこれを直接はサポートしていません。しかし、[[LightDM]]、[[Plasma login manager]]、[[SDDM]] はログインシェルのスタートアップスクリプトを Wayland セッションでも読み込みます。

[[greetd]] も {{ic|/etc/profile}} および {{ic|~/.profile}} を読み込みます。この動作は、デフォルトで有効になっている {{ic|source_profile}} 設定によって制御されます。

{{ic|~/.bash_profile}} などのスタートアップスクリプトを読み込むディスプレイマネージャを使用していて、{{ic|environment.d}} を使用したい場合、以下のように読み込むことができます:

{{hc|~/.bash_profile|
# systemd-environment-d-generator(8) を使用して環境を生成し、その変数をエクスポートする
set -o allexport
source <(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)
set +o allexport
}}
{{Note|{{ic|/usr/lib/systemd/user-environment-generators}} にある他のジェネレーター、例えば {{ic|60-flatpak}} は環境変数の値を引用符で囲まない場合があります。この場合、出力は {{ic|export -- "$(/usr/lib/systemd/user-environment-generators/60-flatpak)"}} を使用して読み込む必要があります。}}

===== アプリケーションごと =====

セッション全体ではなく、特定のアプリケーションにのみ環境変数を設定するには、そのアプリケーションの ''.desktop'' ファイルを編集してください。その方法は [[デスクトップエントリ#環境変数の変更]] を参照してください。

[[Steam]] ゲームでは、起動オプションを編集することでプログラムの環境を設定することができます。[[Steam#起動オプション]] を参照してください。

=== セッションまたはシェルごと ===

時として、一時的な変数のみが必要である場合もあります。特定のディレクトリ内の実行ファイルを実行する際に一時的に絶対パスを入力する手間を省きたい場合や、一時的な短いシェルスクリプトでそのパスを使用したい場合があるでしょう。

例えば、セッション固有のディレクトリを {{ic|PATH}} に追加するには:

$ export PATH="${PATH}:/home/my_user/tmp/usr/bin"

シェル固有のディレクトリのみを {{ic|PATH}} に追加するには:

$ PATH="${PATH}:/home/my_user/tmp/usr/bin"

Bash では、{{ic|PATH}} は既にデフォルトで export されているので、上記のどちらの方法を用いても、変数を上書きしない限り、変数の変更がサブプロセスから見えてしまいます。export された変数とされていない変数の違いをよりわかりやすく比較するには、以下を実行してみてください:

$ MYVAR="shell-only"
$ bash -c 'echo $MYVAR' # 何も表示されない

$ export MYVAR="session-wide"
$ bash -c 'echo $MYVAR' # 表示される。すなわち、セッション全体に反映されている

== 例 ==

以下のセクションでは Linux システムで一般的に使われている環境変数を並べており、それぞれの値について説明しています。

=== デスクトップ環境の検出 ===

; XDG_CURRENT_DESKTOP:
コロンで区切られた文字列リストを含む [[freedesktop.org]] 変数。現在の[[デスクトップ環境]]を示します[https://specifications.freedesktop.org/mime-apps-spec/latest/file.html]。活発に開発されているデスクトップ環境の標準化された値として次があります: {{ic|GNOME}}、{{ic|GNOME-Flashback}}、{{ic|KDE}}、{{ic|LXDE}}、{{ic|LXQt}}、{{ic|MATE}}、{{ic|TDE}}、{{ic|Unity}}、{{ic|XFCE}}、{{ic|EDE}}、{{ic|Cinnamon}}、{{ic|Pantheon}}、and {{ic|DDE}} [https://specifications.freedesktop.org/menu-spec/latest/onlyshowin-registry.html]。
{{Tip|
* Cinnamon は、他のデスクトップ環境[https://gitlab.freedesktop.org/xdg/desktop-file-utils/-/commit/be0c630a19aa1788ef731def911770ce497d6ba3 より後に]登録されました。そのため、[[Qt]][https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixtheme.cpp#L156] など一部のソフトウェアは、登録前の値である {{ic|X-CINNAMON}} を期待します。
* {{ic|Hyprland}} は、[[Hyprland]] 用として非公式に認められています。
}}
; XDG_SESSION_DESKTOP:
{{ic|XDG_CURRENT_DESKTOP}} と似ていますが、単一の文字列しか許可しません。その名前にも関わらず、[https://gitlab.gnome.org/GNOME/gtk/-/issues/1224#note_270915 これは freedesktop.org によって標準化されたものではありません]。
; DE:
使用中のデスクトップ環境 (''d''esktop ''e''nvironment) を示すレガシーな変数です。どのような値を取りうるかについての中心的なドキュメントはありませんが、[[xdg-utils#環境変数|xdg-utils]] は多くのデスクトップ環境についてのリファレンスを提供しています。
; DESKTOP_SESSION:
これもレガシーな変数です。{{ic|DE}} に似ていますが、それよりは一般的ではありません。セッションの ({{ic|/usr/share/xsessions/}} 内の) [[デスクトップエントリ]]へのパスを格納できます [https://github.com/qt/qtbase/blob/6.3/src/gui/platform/unix/qgenericunixservices.cpp#L92-L107]。
; WINDOW_MANAGER:
デスクトップ環境で使用する[[ウィンドウマネージャ]]を''選択''するために時々使われる変数です。他のプログラムが読み取るために、既に選択されているディスプレイマネージャやデスクトップ環境によって設定される他の変数とは対照的です。
; DISPLAY:
ホスト、ディスプレイ、スクリーンを指定するために X Window System によって使用されます。形式は {{ic|''ホスト名'':''ディスプレイ''.''スクリーン''}} です。ディスプレイとは、共通の入力デバイス群 (キーボードやマウスなど) を共有するスクリーンの集まりを指します。ホスト名は、ディスプレイが接続されるマシンの名前を指定するためにかつて使用されていましたが、X クライアントと同じコンピュータ上で X サーバが実行される場合は空欄になっているはずです。詳細は {{man|7|X}} を参照してください。
; WAYLAND_DISPLAY:
Wayland における {{ic|DISPLAY}} のようなものです。コンポジタによって設定されます。これが設定されていない場合、アプリケーションは {{ic|wayland-0}} を使おうと試みます。
; XAUTHORITY:
{{ic|.Xauthority}} ファイルへのパスです。このファイルには、X Window Server にアクセスするための資格情報が入っています。これは、認証のために X サーバに送られるクッキー (任意のデータ) の形で保存されます (例: {{ic|MIT-MAGIC-COOKIE-1}})。

=== システムやセッションのパス ===

; HOME:
現在のユーザのホームディレクトリへのパスが格納されます。この変数は、アプリケーションが現在のユーザに関連した設定ファイル等を見つけるために使うことができます。
; PATH:
コロンで区切られたディレクトリのリストが格納されています。システムは、この変数に登録されているディレクトリから実行ファイルを探索します。通常のコマンド (''ls''、''systemctl''、''pacman'' など) がシェル (''bash'' や ''zsh'' など) によって解釈される際、シェルは {{ic|PATH}} のリスト内のディレクトリからそのコマンドと同じ名前の実行ファイルを探索し、それを実行します。{{ic|PATH}} に含まれないディレクトリにある実行ファイルを実行するには、実行ファイルへの相対パスや絶対パスを指定する必要があります。例えば、{{ic|./a.out}} や {{ic|/bin/ls}} といった形です。
{{Note|セキュリティ上の理由により {{ic|PATH}} にはカレント作業ディレクトリ ({{ic|.}}) を含めないことが推奨されます。ユーザが騙されて、悪意のあるコマンドを実行してしまうかもしれないからです。}}
; PWD:
[[Wikipedia:ja:Pwd|作業ディレクトリへのパス]]が入ります。
; OLDPWD:
前の作業ディレクトリへのパスが入ります。つまり、最後に ''cd'' を実行する前の {{ic|PWD}} です。
; MAIL:
受信したメールの保存場所が入ります。伝統的な設定は {{ic|/var/spool/mail/$LOGNAME}} です。

=== ネットワークプロキシ ===

; ftp_proxy:
FTP [[プロキシサーバー]]が入ります。
ftp_proxy="<nowiki>ftp://192.168.0.1:21</nowiki>"
;http_proxy:
HTTP [[プロキシサーバー]]が入ります。
http_proxy="<nowiki>http://192.168.0.1:80</nowiki>"

=== ドキュメントのパス ===

; MANPATH:
''man'' が man ページを探索するディレクトリのリストがコンマで区切られて格納されます。
{{Note|{{ic|/etc/profile}} に "Man is much better than us at figuring this out" (man は我々よりずっと上手くこれを解決する) と書いてあるとおり、一般的にこの変数はデフォルトのままにしておくべきです。 {{man|5|manpath}} を参照。}}
; INFODIR:
''info'' コマンドが info ページを探索するディレクトリのリストがコンマで区切られて格納されます。例: {{ic|/usr/share/info:/usr/local/share/info}}。

=== デフォルトプログラム ===

; SHELL:
ユーザの[https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#tag_08_03 優先シェル]へのパスが含まれます。この変数の値は、現在実行中のシェルである必要はないことに注意してください。この変数に値がない場合、[[Bash]] は自動的に {{ic|/etc/passwd}} で定義されているユーザのログインシェルに設定するか、判断できない場合は {{ic|/bin/sh}} にします。
; PAGER:
ファイルの内容を一覧表示するために使用されるプログラムを実行するコマンドが含まれます。例: {{ic|/bin/less}}。
; EDITOR:
ファイルの編集に使用される軽量プログラムを実行するコマンドが含まれています (例:{{ic|/usr/bin/nano}})。例えば、以下の例のように、[[X]] 下では ''gedit'' を使い、それ以外では ''nano'' を使うように設定するインタラクティブスイッチを記述することができます:
[ -n "$DISPLAY" ] && export EDITOR=gedit || export EDITOR=nano
; VISUAL:
メールの編集などより高度な作業に使われる本格的なエディタを実行するコマンドが含まれています (例: {{ic|vi}}、[[vim]]、[[emacs]] など)。
; TERMINAL:
ユーザの優先ターミナルエミュレータを実行するコマンドが含まれます。これは、現在実行中のターミナル ({{ic|TERM}}) と同じであるとは限りません。
; BROWSER:
ウェブブラウザへのパスが含まれています。グラフィカル環境 ([[X]] など) が利用できるかに応じてこの変数を動的に変更するようなコードをインタラクティブシェルの設定ファイルに記述しておくと便利です:
[ -n "$DISPLAY" ] && export BROWSER=firefox || export BROWSER=links
{{Tip|{{ic|WAYLAND_DISPLAY}} 環境変数を使うことで、[[Wayland#コンポジタ|Wayland コンポジタ]]が実行されているかどうかに応じてこれらのデフォルトプログラムを設定することができます。}}

=== その他 ===

; TERM:
実行中のターミナル (''term''inal) の種類が格納されます (例: {{ic|xterm-256color}})。この変数は、ターミナル固有の機能を期待する、ターミナル内で実行されるプログラムによって使用されます ({{man|5|terminfo}} を参照)。この変数は、ターミナルエミュレータによって設定されるため、シェルから上書きすることは推奨されません。
; TZ:
ユーザ毎にシステムのタイムゾーンとは異なるタイムゾーンを設定するために使用することができます。{{ic|/usr/share/zoneinfo/}} 内にはタイムゾーンが列挙されているので、これをリファレンスとして使用することができます (例: {{ic|1=TZ=":/usr/share/zoneinfo/Pacific/Fiji"}})。{{ic|TZ}} 変数に zoneinfo ファイルを指定する場合、[https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html GNU マニュアル] に従ってコロンで始める必要があります。

=== シェル環境の検出 ===

シェル環境を検出するテストは、[https://gitlab.com/jdorel-documentation/shell-environment-detection シェル環境の検出に関して書かれたリポジトリ]を見てください。これには、ログイン/インタラクティブシェル、Xorg セッション、TTY、SSH セッションの検出も含まれています。

== 参照 ==

* [[Gentoo:Handbook:X86/Working/EnvVar]]
* [https://help.ubuntu.com/community/EnvironmentVariables Ubuntu Community Wiki - Environment Variables]

{{TranslationStatus|Environment variables|2026-03-29|869026}}

Zsh

2026-03-29T08:05:47Z

AshMyzk: 同期

[[Category:コマンドラインシェル]]
[[de:Zsh]]
[[en:Zsh]]
[[es:Zsh]]
[[hu:Zsh]]
[[pt:Zsh]]
[[ru:Zsh]]
[[zh-hans:Zsh]]
[https://www.zsh.org/ Zsh] は対話式シェルとしてもスクリプト言語のインタプリタとしても使えるパワフルな[[シェル]]です。POSIX sh と互換性がありながら (デフォルトではありません、{{ic|emulate sh}} を実行した時だけです)、[https://zsh.sourceforge.io/Guide/zshguide06.html タブ補完]の改善や [https://zsh.sourceforge.io/Doc/Release/Expansion.html グロビング]などの利点があります。

[https://zsh.sourceforge.io/FAQ/zshfaq01.html#l4 Zsh FAQ] には他にも Zsh をあなたのシェルとして使うべき理由が列挙されています。

== インストール ==

インストールをする前に現在使っているシェルが何なのか知っておくとよいでしょう:

$ echo $SHELL

{{Pkg|zsh}} パッケージを[[インストール]]してください。追加の補完定義を使いたい場合は、{{pkg|zsh-completions}} パッケージもインストールします。

=== 初期設定 ===

ターミナルで次のコマンドを実行して Zsh が正しくインストールされたか確認してください:

$ zsh

基本的な設定を説明する ''zsh-newuser-install'' が表示されるはずです。これをスキップしたい場合、{{ic|q}} を押して下さい。表示されない場合は、次のコマンドで手動で呼び出すことができます:

$ autoload -Uz zsh-newuser-install
$ zsh-newuser-install -f

{{Note|あなたのターミナルのサイズが少なくとも 72×15 であることを確認してください。そうでないと ''zsh-newuser-install'' は実行されません。}}

=== Zsh をデフォルトのシェルにする ===

シェルを {{ic|/usr/bin/zsh}} に変更してください。[[コマンドラインシェル#デフォルトシェルを変更する]] を見てください。

{{Tip|{{Pkg|bash}} を置き換える場合、{{ic|~/.bashrc}} から {{ic|~/.zshrc}} に (例: プロンプトと[[Bash#エイリアス|エイリアス]]) また {{ic|~/.bash_profile}} から {{ic|~/.zprofile}} に (例: [[ログイン時に X を起動|X Window System を起動するコード]]) にコードを移動するとよいでしょう。}}

== スタートアップ/シャットダウンファイル ==

{{Tip|インタラクティブシェルとログインシェルの説明、およびスタートアップファイルに何を入れるかについては、[https://zsh.sourceforge.io/Guide/zshguide02.html A User's Guide to the Z-Shell] を参照してください。
}}

{{Note|
* {{ic|$ZDOTDIR}} が設定されていない場合は、代わりに {{ic|$HOME}} が使用されます。
* {{ic|RCS}} オプションが以下のファイルのどれかで unset された場合、そのファイル以降、設定ファイルは読み込まれません。
* {{ic|GLOBAL_RCS}} オプションが以下のファイルのどれかで unset された場合、そのファイル以降、グローバルな設定ファイル ({{ic|/etc/zsh/*}}) は読み込まれません。
}}

デフォルトで、Zsh は起動時に以下のファイルを以下の順番で実行します (存在しているもののみ実行されます)。

* {{ic|/etc/zsh/zshenv}} すべてのユーザに対して[[環境変数]]を設定するために使用されます。このファイルには、出力を行うコマンドや、シェルが TTY に接続されていることを期待するコマンドを含めるべきではありません。このファイルが存在する場合、このファイルは '''''常に''''' 読み込まれます。この挙動を上書きすることはできません。
* {{ic|$ZDOTDIR/.zshenv}} ユーザの[[環境変数]]を設定するために使用されます。このファイルには、出力を行うコマンドや、シェルが TTY に接続されていることを期待するコマンドを含めるべきではありません。このファイルが存在する場合、このファイルは '''''常に''''' 読み込まれます。
* {{ic|/etc/zsh/zprofile}} すべてのユーザに対して起動時にコマンドを実行するために使用されます。'''''ログインシェル'''''として起動した場合に、このファイルは読み込まれます。Arch Linux においては、このファイルには、{{ic|/etc/profile}} を source する [https://gitlab.archlinux.org/archlinux/packaging/packages/zsh/-/blob/main/zprofile 1行]がデフォルトで含まれていることを留意しておいてください。その行を削除したい場合は以下の警告を先に読んでください!
** {{ic|/etc/profile}} POSIX sh 互換のシェルはすべて、このファイルをログイン時に source する必要があります。このファイルは {{ic|$PATH}} や他の環境変数を設定し、ログイン時にはアプリケーション固有 ({{ic|/etc/profile.d/*.sh}}) の設定を行います。
* {{ic|$ZDOTDIR/.zprofile}} 起動時にユーザのコマンドを実行するために使用されます。'''''ログインシェル'''''として起動した場合に、このファイルは読み込まれます。通常、グラフィカルセッションを自動起動し、セッションの環境変数を設定するために使用されます。
* {{ic|/etc/zsh/zshrc}} すべてのユーザに対して、インタラクティブシェルを設定したりコマンドを実行したりするために使用されます。'''''インタラクティブシェル'''''として起動した場合に、このファイルは読み込まれます。
* {{ic|$ZDOTDIR/.zshrc}} ユーザのインタラクティブシェルを設定したり、コマンドを実行したりするために使用されます。'''''インタラクティブシェル'''''として起動した場合に、このファイルは読み込まれます。
* {{ic|/etc/zsh/zlogin}} すべてのユーザに対して初期化処理の最後にコマンドを実行するために使用されます。'''''ログインシェル'''''として起動した場合に、このファイルは読み込まれます。
* {{ic|$ZDOTDIR/.zlogin}} 初期化処理の最後にユーザのコマンドを実行するために使用されます。'''''ログインシェル'''''として起動した場合に、このファイルは読み込まれます。通常、コマンドラインユーティリティを自動起動するために使用されます。グラフィカルセッションを自動起動するために使用するべきではありません (この時点では、インタラクティブシェルにおいてのみ意味を持つ設定がセッションに含まれているかもしれないからです)。
* {{ic|$ZDOTDIR/.zlogout}} '''''ログインシェル''''' が '''終了''' する時にコマンドを実行するために使用されます。
* {{ic|/etc/zsh/zlogout}} '''''ログインシェル''''' が '''終了''' する時にすべてのユーザに対してコマンドを実行するために使用されます。

[https://web.archive.org/web/20241008050626/https://blog.flowblok.id.au/2013-02/shell-startup-scripts.html#implementation この流れを図で表したもの]も参照してください。

{{Note|{{ic|$HOME/.profile}} は Zsh のスタートアップファイルの一部ではありません。さらに、Zsh によって '''source されません''' (Zsh が {{ic|sh}} か {{ic|ksh}} として実行され、ログインシェルとして起動しない限り)。sh や [[ksh]] との互換性モードに関する詳細は {{man|1|zsh|COMPATIBILITY}} を見てください。}}

{{Warning|{{ic|/etc/zsh/zprofile}} 内にデフォルトで存在する [https://gitlab.archlinux.org/archlinux/packaging/packages/zsh/-/blob/main/zprofile 一行]を削除しないでください。さもないと、{{ic|/etc/profile.d/}} 内へスクリプトを提供するパッケージの整合性が破壊されてしまいます。}}

== Zsh の設定 ==

Zsh は何も設定しなくても使うことができますが、ほとんどのユーザが使いたいと思うようには設定されていないことはほぼ確実です。ただし、Zsh で利用できるカスタマイズの量は膨大で、Zsh を設定するのは大変で時間を浪費する経験となるでしょう。自動的に設定するには [[#サードパーティ拡張]] を見てください。

=== シンプルな .zshrc ===

以下は設定ファイルのサンプルです。デフォルトのオプションの適切なセットと共に、Zsh でカスタマイズ可能な方法の例を提供します。この設定を使うには、{{ic|.zshrc}} という名前のファイルに保存してください。

{{Tip|ログアウトせずに変更を適用するには {{ic|source ~/.zshrc}} を実行してください。}}

これはシンプルな {{ic|.zshrc}} です:

{{hc|~/.zshrc|
autoload -Uz compinit promptinit
compinit
promptinit

# デフォルトのプロンプトを walters テーマに設定する
prompt walters
}}

プロンプトテーマシステムに関する詳細は [[#プロンプトテーマ]] を見てください。

=== $PATH の設定 ===

Zsh は {{ic|PATH}} 変数を {{ic|path}} 配列に結びつけます。これにより、{{ic|path}} 配列を変更するだけで {{ic|PATH}} 変数を操作することができます。詳細は [https://zsh.sourceforge.io/Guide/zshguide02.html#l24 A User's Guide to the Z-Shell] を見てください。

{{ic|~/.local/bin/}} を {{ic|PATH}} に追加するには:

{{hc|~/.zshenv|2=
typeset -U path PATH
path=(~/.local/bin $path)
export PATH
}}

=== コマンド補完 ===

Zsh の一番魅力的な機能はおそらく先進的な自動補完機能でしょう。少なくとも {{ic|.zshrc}} で自動補完を有効化してください。自動補完を有効にするには、以下を {{ic|~/.zshrc}} に追加してください:

{{hc|~/.zshrc|
autoload -Uz compinit
compinit
}}

上記の設定には ssh/scp/sftp ホスト名の補完が含まれていますが、この機能を動作させるためにはユーザは ssh のホスト名ハッシュ化 (つまり、ssh クライアントの設定の {{ic|HashKnownHosts}} オプション) を有効化してはなりません。

矢印キーを使うインターフェイスで自動補完を行うには、以下を追加してください:

{{hc|~/.zshrc|
zstyle ':completion:*' menu select
}}

メニューをアクティブにするには、{{ic|Tab}} を2回押してください。

特権が与えられたコマンドで特権環境の自動補完を有効化するには (例えば、[[sudo]] で始まるコマンドを補完する場合、補完スクリプトは sudo の補完もしようと試みます)、以下を追加してください:

{{hc|~/.zshrc|
zstyle ':completion::complete:*' gain-privileges 1
}}

{{Warning|これにより、Zsh の補完スクリプトが sudo 特権でコマンドを実行できてしまいます。信頼できない補完スクリプトを使用する場合はこれを有効化すべきではありません。}}

{{Note|この特殊な種類の文脈依存の補完は、少数のコマンドでしか利用できません。}}

==== カスタムの補完 ====

カスタムの補完を自分で作ることもできます。詳細は {{man|1|zshcompsys}} man ページを参照してください。

公式のドキュメントは難解かもしれません。簡単なスタートポイントとして、よりシンプルな [https://github.com/zsh-users/zsh-completions/blob/master/zsh-completions-howto.org zsh-completion-howto] チュートリアルもあります。

=== キーバインド ===

Zsh は [[readline]] を使用しません。代わりに、よりパワフルな独自の Zsh Line Editor (ZLE) を使用します。ZLE は {{ic|/etc/inputrc}} と {{ic|~/.inputrc}} のどちらも読み込みません。ZLE 設定のイントロダクションは [https://sgeb.io/posts/2014/04/zsh-zle-custom-widgets/ A closer look at the zsh line editor and creating custom widgets] を読んでください。

ZLE には [[Emacs]] モードと [[vi]] モードがあります。{{ic|VISUAL}} か {{ic|EDITOR}} のどちらか一方の[[環境変数]]に {{ic|vi}} という文字列が含まれている場合、vi モードが使用されます。それ以外の場合、Emacs モードをデフォルトで使用します。{{ic|bindkey -e}} (Emacs モード) や {{ic|bindkey -v}} (vi モード) でモードを明示的に設定することもできます。デフォルトでは、vi モードでの Esc キーを押した時の遅延は 0.4 秒ですが、{{ic|1=export KEYTIMEOUT=5}} でより短く (0.05 秒) することができます。

キーバインドは、キープレスに対応するエスケープシーケンスを ZLE ウィジェットにマッピングすることにより割り当てます。利用可能なウィジェットは {{man|1|zshzle|STANDARD WIDGETS}} と {{man|1|zshcontrib|ZLE FUNCTIONS}} にリストアップされています (アクションとデフォルトのキーバインドの説明付き)。

Zsh でキーバインドを設定する方法として推奨されるのは、{{man|5|terminfo}} の文字列ケーパビリティを使用することです。例えば [https://web.archive.org/web/20180704181216/http://zshwiki.org/home/zle/bindkeys][https://www.zsh.org/mla/users/2010/msg00065.html]:

{{hc|~/.zshrc|2=
# zkbd と互換性のあるハッシュテーブルを作成し、
# 他のキーをこのハッシュテーブルに追加する (man 5 terminfo を参照)
typeset -g -A key

key[Home]="${terminfo[khome]}"
key[End]="${terminfo[kend]}"
key[Insert]="${terminfo[kich1]}"
key[Backspace]="${terminfo[kbs]}"
key[Delete]="${terminfo[kdch1]}"
key[Up]="${terminfo[kcuu1]}"
key[Down]="${terminfo[kcud1]}"
key[Left]="${terminfo[kcub1]}"
key[Right]="${terminfo[kcuf1]}"
key[PageUp]="${terminfo[kpp]}"
key[PageDown]="${terminfo[knp]}"
key[Shift-Tab]="${terminfo[kcbt]}"

# 適宜キーを設定する
[[ -n "${key[Home]}" ]] && bindkey -- "${key[Home]}" beginning-of-line
[[ -n "${key[End]}" ]] && bindkey -- "${key[End]}" end-of-line
[[ -n "${key[Insert]}" ]] && bindkey -- "${key[Insert]}" overwrite-mode
[[ -n "${key[Backspace]}" ]] && bindkey -- "${key[Backspace]}" backward-delete-char
[[ -n "${key[Delete]}" ]] && bindkey -- "${key[Delete]}" delete-char
[[ -n "${key[Up]}" ]] && bindkey -- "${key[Up]}" up-line-or-history
[[ -n "${key[Down]}" ]] && bindkey -- "${key[Down]}" down-line-or-history
[[ -n "${key[Left]}" ]] && bindkey -- "${key[Left]}" backward-char
[[ -n "${key[Right]}" ]] && bindkey -- "${key[Right]}" forward-char
[[ -n "${key[PageUp]}" ]] && bindkey -- "${key[PageUp]}" beginning-of-buffer-or-history
[[ -n "${key[PageDown]}" ]] && bindkey -- "${key[PageDown]}" end-of-buffer-or-history
[[ -n "${key[Shift-Tab]}" ]] && bindkey -- "${key[Shift-Tab]}" reverse-menu-complete

# 最後に、zle がアクティブのときにターミナルがアプリケーションモードになるようにする。
# そのときにだけ、$terminfo の値が有効になる。
if (( ${+terminfo[smkx]} && ${+terminfo[rmkx]} )); then
autoload -Uz add-zle-hook-widget
function zle_application_mode_start { echoti smkx }
function zle_application_mode_stop { echoti rmkx }
add-zle-hook-widget -Uz zle-line-init zle_application_mode_start
add-zle-hook-widget -Uz zle-line-finish zle_application_mode_stop
fi
}}

==== 修飾キー Shift、Alt、Ctrl、Meta ====

xterm 互換端末は {{man|5|user_caps}} からの拡張キー定義を使うことができます。キー定義は、{{ic|Shift}}、{{ic|Alt}}、{{ic|Ctrl}}、{{ic|Meta}} と、{{ic|Up}}、{{ic|Down}}、{{ic|Left}}、{{ic|Right}}、{{ic|PageUp}}、{{ic|PageDown}}、{{ic|Home}}、{{ic|End}}、{{ic|Del}} のどれかを組み合わせたものです。修飾キーとキーの組み合わせに推奨される名前の一覧については、[https://sourceforge.net/p/zsh/code/ci/master/tree/Functions/Misc/zkbd zkbd のソース] を参照してください。

たとえば、 {{ic|Ctrl+Left}} で前の単語の先頭に移動し、{{ic|Ctrl+Right}} で次の単語の先頭に移動させるには:

{{hc|~/.zshrc|2=
key[Control-Left]="${terminfo[kLFT5]}"
key[Control-Right]="${terminfo[kRIT5]}"

[[ -n "${key[Control-Left]}" ]] && bindkey -- "${key[Control-Left]}" backward-word
[[ -n "${key[Control-Right]}" ]] && bindkey -- "${key[Control-Right]}" forward-word
}}

=== 履歴 ===

空白で始まるコマンドを履歴リストで無視するには、コマンドプロンプトか {{ic|.zshrc}} で {{ic|setopt HIST_IGNORE}} を実行してください。ただし、{{ic|setopt HIST_IGNORE}} では、別のコマンドが実行されるまで、最後に実行したコマンドは、{{ic|Up}} キーを押すなどして再度表示させることができます。{{ic|setopt ''OPT''}} コマンドを取り消すには、{{ic|unsetopt ''OPT''}} を実行してください。

デフォルトでは、履歴は {{ic|HISTSIZE}} (30) のサイズまで保持されます。これは、ターミナル毎に分かれており、リストからエントリを削除することはできず、セッション毎に保存もされません。{{ic|HISTFILE}} を設定することで、履歴リストをセッション毎に保存することができます。

==== 履歴検索 ====

以下の手順を使うには、{{ic|key}} 配列を設定し、ZLE がアプリケーションモードとなるようにする必要があります。[[#キーバインド]] を見てください。

履歴検索を有効化するには、以下を {{ic|.zshrc}} ファイルに追加してください:

{{hc|~/.zshrc|
autoload -Uz up-line-or-beginning-search down-line-or-beginning-search
zle -N up-line-or-beginning-search
zle -N down-line-or-beginning-search

[[ -n "${key[Up]}" ]] && bindkey -- "${key[Up]}" up-line-or-beginning-search
[[ -n "${key[Down]}" ]] && bindkey -- "${key[Down]}" down-line-or-beginning-search
}}

これにより、{{ic|Up}} か {{ic|Down}} を押したときに、現在の行のカーソル位置までにマッチする過去のコマンドだけが表示されます。

=== プロンプト ===

Zsh は2つの選択肢を提供します: プロンプトテーマを使用するか、テーマに不満がある (または、テーマの使いやすさを自分で拡張したい) ユーザはカスタムのプロンプトを構築できます。

==== プロンプトテーマ ====

プロンプトテーマは、Zsh で色付きのプロンプトを設定するための手っ取り早く簡単な方法です。プロンプトテーマや、プロンプトテーマを自分で記述する方法については {{man|1|zshcontrib|PROMPT THEMES}} を参照してください。

テーマを使用するには、プロンプトテーマシステムが自動でロードされるように {{ic|.zshrc}} で設定されていることを確認してください。自動ロードを行うには、以下の行を追加します:

{{hc|~/.zshrc|
autoload -Uz promptinit
promptinit
}}

以下のコマンドで、利用可能なプロンプトテーマをリストアップできます:

$ prompt -l

例えば、{{ic|walters}} テーマを使うには:

$ prompt walters

利用可能なテーマをすべてプレビューするには:

$ prompt -p

===== プロンプトテーマを手動でインストールする =====

外部の設定管理ツールを使わずに、テーマを手動でインストールすることもできます。ローカルにインストールする場合、まずフォルダを作成し、そのフォルダのパスを {{ic|fpath}} 配列に追加してください。例えば:

$ mkdir ~/.zprompts
$ fpath=("$HOME/.zprompts" "$fpath[@]")

次に、このフォルダ内にテーマファイルのシンボリックリンクを作成します:

$ ln -s mytheme.zsh ~/.zprompts/prompt_mytheme_setup

代わりにテーマをグローバルにインストールする場合は、次のようにします:

# ln -s mytheme.zsh /usr/share/zsh/functions/Prompts/prompt_mytheme_setup

これで、次のコマンドを使ってアクティブ化できるはずです:

$ prompt mytheme

すべてが機能する場合は、{{ic|.zshrc}} を適宜編集することができます。

===== テーマごとにファイルを分けずにプロンプトテーマを追加する =====

プロンプトテーマは、テーマのファイルを使って追加するだけでなく、ある1つのファイル (例えば {{ic|.zshrc}}) 内からテーマを追加することもできます。例えば:

{{hc|~/.zshrc|2=
# promptinit をロードする
autoload -Uz promptinit && promptinit

# テーマを定義する
prompt_mytheme_setup() {
PS1="%~%# "
}

# promptsys にそのテーマを追加する
prompt_themes+=( mytheme )

# テーマをロードする
prompt mytheme
}}

==== プロンプトのカスタマイズ ====

すべてのシェルで一般的な主要な左側のプロンプト {{ic|PS1}} ({{ic|PROMPT}}、{{ic|prompt}}) に加えて、Zsh では右側のプロンプト {{ic|RPS1}} ({{ic|RPROMPT}}) もサポートしています。これら2つの変数は、好きな値にカスタムできます。

他の特殊な目的のためのプロンプト ({{ic|PS2}} ({{ic|PROMPT2}})、{{ic|PS3}} ({{ic|PROMPT3}})、{{ic|PS4}} ({{ic|PROMPT4}})、{{ic|RPS1}} ({{ic|RPROMPT}})、{{ic|RPS2}} ({{ic|RPROMPT2}})、{{ic|SPROMPT}} など) は {{man|1|zshparam|PARAMETERS USED BY THE SHELL}} で説明されています。

すべてのプロンプトは、プロンプトエスケープでカスタマイズできます (例えば、{{ic|%n}} はユーザ名になります)。利用可能なプロンプトエスケープは {{man|1|zshmisc|EXPANSION OF PROMPT SEQUENCES}} でリストアップされています。

===== 色 =====

Zsh は、[[Bash/プロンプトのカスタマイズ|Bash]] とは異なる方法で色を設定します。ANSI エスケープシーケンスや、{{man|5|terminfo}} のターミナルケーパビリティを多用する必要はありません。Zsh は、前景色、背景色、他の視覚エフェクトを設定するための便利なプロンプトエスケープを提供します。エスケープのリストや説明は {{man|1|zshmisc|Visual effects}} を見てください。

[https://zsh.sourceforge.io/FAQ/zshfaq03.html#l42 色]を指定する方法は3つあります: 10進数の整数、8つの広くサポートされている色の名前、# のあとに16進数の RGB トリプレット。詳細は {{man|1|zshzle|CHARACTER HIGHLIGHTING}} 内の fg=colour の説明を見てください。

ほとんどのターミナルは以下の色を名前でサポートしています:

{| class="wikitable"
|-
! 名前 !! 番号
|-
| {{ic|black}} || {{ic|0}}
|-
| {{ic|red}} || {{ic|1}}
|-
| {{ic|green}} || {{ic|2}}
|-
| {{ic|yellow}} || {{ic|3}}
|-
| {{ic|blue}} || {{ic|4}}
|-
| {{ic|magenta}} || {{ic|5}}
|-
| {{ic|cyan}} || {{ic|6}}
|-
| {{ic|white}} || {{ic|7}}
|}

xterm 256 color と互換性のあるターミナルエミュレータの色番号 0 から 255 は、[https://upload.wikimedia.org/wikipedia/commons/1/15/Xterm_256color_chart.svg xterm-256color チャート]で見られます。

TERM 環境変数が正しく設定されていれば、ターミナルのサポートする色の最大数は、{{man|5|terminfo}} データベースから {{ic|echoti colors}} を使って確認することができます。[https://github.com/termstandard/colors/blob/master/README.md 24-bit カラー]の場合は、{{ic|print $COLORTERM}} を使って COLORTERM 環境変数も確認してください。{{ic|24bit}} か {{ic|truecolor}} を返した場合、たとえ terminfo がより少ない数値を表示したとしても、あなたのターミナルは 16777216 (224) 色をサポートしています。

{{Note|
* 0 から 15 の色は、ターミナルエミュレータやカラースキームごとに異なる場合があります。
* 多くのターミナルエミュレータは、太文字を明るい色で表示します。
}}

{{Tip|
* プロンプトのエスケープは {{ic|print -P ''"prompt escapes"''}} コマンドでテストできます。例えば、{{bc|$ print -P '%B%F{red}co%F{green}lo%F{blue}rs%f%b'}}
* 24 ビットカラーを使用する場合、24 ビットカラーをサポートしていないターミナルでは {{ic|zsh/nearcolor}} モジュールをロードする必要があるかもしれません。例えば: {{bc|<nowiki>[[ "$COLORTERM" == (24bit|truecolor) || "${terminfo[colors]}" -eq '16777216' ]] || zmodload zsh/nearcolor</nowiki>}} {{ic|zsh/nearcolor}} モジュールに関する詳細は {{man|1|zshmodules|THE ZSH/NEARCOLOR MODULE}} を見てください。
}}

===== 例 =====

これは、シンプルな色無しのプロンプトの例です:

PROMPT='%n@%m %~ %# '

以下のように出力されます:

<div class="mw-no-invert" style="font-family: monospace, monospace; white-space: pre; padding: 1em; background-color: #000; border: 1px solid #bcd; color: #c0c0c0; overflow:hidden;">username@host ~ % </div>

これは、色付きの左右両方のプロンプトの例です:

PROMPT='%F{green}%n%f@%F{magenta}%m%f %F{blue}%B%~%b%f %# '
RPROMPT='[%F{yellow}%?%f]'

以下のように出力されます:

<div class="mw-no-invert" style="font-family: monospace, monospace; white-space: pre; padding: 1em; background-color: #000; border: 1px solid #bcd; color: #c0c0c0; overflow: hidden;">username@host ~ % [0]</div>

16-255 の範囲の色は、欲しい色に割り当てた 0 から 255 までの数値を使うことで使用できます。また、24 ビットトゥルーカラーは16進数のカラーコードを使うことで使用できます:

PROMPT='%F{2}%n%f@%F{5}%m%f %F{4}%B%~%b%f %# '
RPROMPT='[%F{3}%?%f]'

PROMPT='%F{#c0c0c0}%n%f@%F{#008000}%m%f %F{#800080}%B%~%b%f %# '
RPROMPT='[%F{#0000ff}%?%f]'

=== サンプルの .zshrc ファイル ===

* [https://www.archlinux.jp/download/ 月次 ISO リリース] (デフォルトで Zsh を使用します) と同じセットアップにするには、{{Pkg|grml-zsh-config}} をインストールしてください。これには、[https://grml.org/zsh/ grml] の多くの調整と高度な最適化が含まれています。
* https://github.com/MrElendig/dotfiles-alice/blob/master/.zshrc - ベーシックなセットアップ。動的なプロンプトとウィンドウのタイトル/hardinfo。

さらに見たい場合は [[ドットファイル#ユーザーリポジトリ]] を見てください。

== ヒントとテクニック ==

=== ログイン時に X を自動起動 ===

[[xinit#ログイン時に X を自動起動]]を参照してください。

=== プログラムが異常終了した後、端末の設定を復元する ===

多くのプログラムはターミナルの状態を変更し、異常終了したときにターミナルの設定を復元しないことがあります (例えば、クラッシュしたときや、SIGINT を受け取ったとき)。

通常、これは {{man|1|reset}} を実行することで解決できます:

$ reset

以下のセクションでは、手動でターミナルをリセットする手間を省く方法について説明します。

==== ttyctl コマンド ====

[https://zsh.sourceforge.io/Doc/Release/Shell-Builtin-Commands.html#index-tty_002c-freezing ttyctl] コマンドを使ってターミナルを "freeze/unfreeze" することができます。起動時にインタラクティブシェルを freeze させるには、以下を使用してください:

{{hc|~/.zshrc|
ttyctl -f
}}

==== エスケープシーケンスで端末をリセットする ====

[https://www.in-ulm.de/~mascheck/various/alternate_charset/ 代替の線画文字セット]は、ttyctl が防ぐことができない方法でターミナルを台無しにしてしまうことがあります。

シンプルな解決法は、ターミナルをリセットするエスケープシーケンスを {{ic|precmd}} フック関数から出力することです。そうすれば、プロンプトが描画される前に毎回、そのエスケープシーケンスが出力されます。例えば、[https://www.in-ulm.de/~mascheck/various/alternate_charset/#solution エスケープシーケンス] {{ic|\e[0m\e(B\e)0\017\e[?5l\e7\e[0;0r\e8}} を使うと:

{{hc|~/.zshrc|2=

autoload -Uz add-zsh-hook

function reset_broken_terminal () {
printf '%b' '\e[0m\e(B\e)0\017\e[?5l\e7\e[0;0r\e8'
}

add-zsh-hook -Uz precmd reset_broken_terminal
}}

うまく行くか試すには、以下を実行してください:

$ print '\e(0\e)B'

=== 最近のディレクトリを記憶させる ===

==== Dirstack ====

Zsh は、最後に訪れたフォルダのうち DIRSTACKSIZE 個を記憶するように設定できます。この機能を活用すれば、それらのフォルダへ非常に素早く ''cd'' することができます。設定ファイルにいくつかの行を追加する必要があります:

{{hc|~/.zshrc|<nowiki>
autoload -Uz add-zsh-hook

DIRSTACKFILE="${XDG_CACHE_HOME:-$HOME/.cache}/zsh/dirs"
if [[ -f "$DIRSTACKFILE" ]] && (( ${#dirstack} == 0 )); then
dirstack=("${(@f)"$(< "$DIRSTACKFILE")"}")
[[ -d "${dirstack[1]}" ]] && cd -- "${dirstack[1]}"
fi
chpwd_dirstack() {
print -l -- "$PWD" "${(u)dirstack[@]}" > "$DIRSTACKFILE"
}
add-zsh-hook -Uz chpwd chpwd_dirstack

DIRSTACKSIZE='20'

setopt AUTO_PUSHD PUSHD_SILENT PUSHD_TO_HOME

## 重複するエントリを削除する
setopt PUSHD_IGNORE_DUPS

## +/- 演算子をもとに戻す。
setopt PUSHD_MINUS
</nowiki>}}

これで、以下のコマンドを使えば dirstack を出力できます。

$ dirs -v

訪れたフォルダに戻るには {{ic|cd -<NUM>}} を使ってください。ダッシュ記号の後でオートコンプリートを使ってください。オートコンプリートメニューを使う場合に便利です。

{{Note|
* 2つ以上の ''zsh'' セッションを開いていて {{ic|cd}} を試みた場合、両方のセッションが同じファイルに書き込むことで競合が発生するため、これは機能しません。
* {{ic|no such file or directory}} エラーが発生しないように、{{ic|$HOME/.cache/zsh}} ディレクトリを作成して下さい。
}}

==== cdr ====

cdr により、自動的に管理されるリストを使って現在の作業ディレクトリから以前の作業ディレクトリに移動することができます。cdr は、現在のセッションでセッション間および (デフォルトで) ターミナルエミュレータ間で管理されるファイルにすべてのエントリを保存します。

セットアップの手順は {{man|1|zshcontrib|REMEMBERING RECENT DIRECTORIES}} を見てください。

==== zoxide ====

{{Pkg|zoxide}} は、よりスマートな ''cd'' コマンドで、数個のキーストロークで好きな場所に移動できます。zoxide は、頻繁に使用されるディレクトリを記憶し、スコアリングメカニズムを使って、あなたが行きたい場所を推測します。

詳細は [https://github.com/ajeetdsouza/zoxide] か {{man|1|zoxide}} を参照してください。

=== ヘルプコマンド ===

[[Bash]] とは違い、Zsh は組み込みの {{ic|help}} コマンドを有効化しておらず、代わりに {{ic|run-help}} を提供しています。デフォルトでは、{{ic|run-help}} は {{ic|man}} のエイリアスとなっています。コマンドの前に {{ic|run-help}} と付けることで実行できますし、または今タイプしたコマンドに対してキーボードショートカット {{ic|Alt+h}} か {{ic|Esc}} {{ic|h}} を入力することでも実行できます。

デフォルトでは [[man]] のエイリアスとなっているので、外部コマンドに対してしか動作しません。シェルの組み込みコマンドやシェルの他の機能でも動作するようにするには、{{ic|run-help}} 関数を使う必要があります。{{ic|run-help}} や補助関数については {{man|1|zshcontrib}} を見てください。

まず、{{ic|run-help}} 関数をロードし、その次に既存の {{ic|run-help}} エイリアスを削除してください。{{ic|help}} は {{ic|run-help}} へのエイリアスにすることもできます。例えば、以下を {{ic|zshrc}} に追加してください:

autoload -Uz run-help
(( ${+aliases[run-help]} )) && unalias run-help
alias help=run-help

補助関数は別で有効化する必要があります:

autoload -Uz run-help-git run-help-ip run-help-openssl run-help-p4 run-help-sudo run-help-svk run-help-svn

例えば、{{ic|run-help git commit}} コマンドは、{{man|1|git}} ではなく {{man|1|git-commit}} の [[man ページ]]を開きます。

=== 継続的に rehash する ===

たいてい、{{man|1|zshcompsys|Use of compinit}} の {{ic|compinit}} は {{ic|$PATH}} 内の新しい実行ファイルを自動的には見つけません。例えば、新しいパッケージをインストールした後、{{ic|/usr/bin/}} 内に追加された新しいファイルは即座に、または自動的には補完に含まれないでしょう。なので、そのような新しい実行ファイルを補完に含めるには、以下を実行してください:

$ rehash

この 'rehash' は、自動的に実行するよう設定できます。[https://github.com/robbyrussell/oh-my-zsh/issues/3440] 以下を {{ic|zshrc}} に追加するだけです:

{{hc|~/.zshrc|
zstyle ':completion:*' rehash true
}}

==== 必要なときにだけ rehash する ====

しかし、[[pacman フック]]を使って、自動的に {{ic|rehash}} を要求するように設定できます。こうすれば、先のセクションのように継続的に rehash してパフォーマンスが劣化してしまうようなことは起こりません。これを有効化するには、{{ic|/etc/pacman.d/hooks}} ディレクトリと {{ic|/var/cache/zsh}} ディレクトリを作成し、フックファイルを作成してください:

{{hc|head=/etc/pacman.d/hooks/zsh-rehash.hook|output=
[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Path
Target = usr/bin/*
[Action]
Depends = zsh
When = PostTransaction
Exec = /usr/bin/install -Dm644 /dev/null /var/cache/zsh/pacman
}}

これは、{{ic|/var/cache/zsh/pacman}} ファイルの変更日時を、最後にパッケージをインストール/アップグレード/アンインストールした時間に合わせます。次に、{{ic|zsh}} のコマンドキャッシュが古くなったときにコマンドキャッシュを rehash するように設定します。以下を {{ic|~/.zshrc}} に追加してください:

{{hc|~/.zshrc|<nowiki>
zshcache_time="$(date +%s%N)"

autoload -Uz add-zsh-hook

rehash_precmd() {
if [[ -a /var/cache/zsh/pacman ]]; then
local paccache_time="$(date -r /var/cache/zsh/pacman +%s%N)"
if (( zshcache_time < paccache_time )); then
rehash
zshcache_time="$paccache_time"
fi
fi
}

add-zsh-hook -Uz precmd rehash_precmd
</nowiki>}}

{{ic|/var/cache/zsh/pacman}} が更新されるまえに {{ic|precmd}} フックがトリガーされた場合、新しいプロンプトが始まるまで補完が効かないかもしれません。そういうときは、空のコマンドを実行すれば良いはずです (例えば、{{ic|enter}} を押す)。

==== SIGUSR1 を使って必要なときにだけ rehash する ====

フックファイルは以下のようになります。

{{hc|/etc/pacman.d/hooks/zsh-rehash.hook|output=
[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Path
Target = usr/bin/*

[Action]
Depends = zsh
Depends = procps-ng
When = PostTransaction
Exec = /usr/bin/pkill zsh --signal=USR1
}}

{{Warning|このフックは、実行中の {{ic|zsh}} インスタンスすべてに SIGUSR1 を送信します。注意すべきなのは、SIGUSR1 のデフォルトの挙動は「終了」だということです。なので、このフックを先に設定してしまうと、すべてのユーザの実行中の {{ic|zsh}} インスタンス (ログインシェルも含む) のうち以下のトラップを source していないものが、終了してしまいます。}}

{{hc|~/.zshrc|
TRAPUSR1() { rehash }
}}

この ''関数トラップ'' は、''リストトラップ'' {{ic|trap 'rehash' USR1}} に置き換えることもできます。トラップの種類の違いについては {{man|1|zshmisc|Trap Functions}} を見てください。

この方法は、すべての {{ic|zsh}} インスタンスを即座に {{ic|rehash}} します。なので、{{ic|precmd}} をトリガーするためにエンターキーを押す必要がありません。

=== ncurses アプリケーションにキーをバインド ===

ncurses アプリケーションをキーストロークにバインドしますが、対話を受け入れません。これを動作させるには {{ic|BUFFER}} 変数を使用します。次の例では、{{ic|Alt+\}} を使用して [[ncmpcpp]] を開くことができます。

{{hc|~/.zshrc|2=
ncmpcppShow() {
BUFFER="ncmpcpp"
zle accept-line
}
zle -N ncmpcppShow
bindkey '^[\' ncmpcppShow
}}

アプリケーションを呼び出す前に、行に入力した内容をすべて保持する別の方法

{{hc|~/.zshrc|2=
ncmpcppShow() {
ncmpcpp <$TTY
zle redisplay
}
zle -N ncmpcppShow
bindkey '^[\' ncmpcppShow
}}

=== ファイルマネージャ風のキーバインド ===

グラフィックファイルマネージャで使われているようなキーバインドが便利かもしれません。1つ目はディレクトリ履歴 ({{ic|Alt+Left}}) に戻り、2つ目はユーザを親ディレクトリ ({{ic|Alt+Up}}) に移動させます。また、ディレクトリの内容も表示されます。

{{hc|~/.zshrc|<nowiki>
cdUndoKey() {
popd
zle reset-prompt
print
ls
zle reset-prompt
}

cdParentKey() {
pushd ..
zle reset-prompt
print
ls
zle reset-prompt
}

zle -N cdParentKey
zle -N cdUndoKey
bindkey '^[[1;3A' cdParentKey
bindkey '^[[1;3D' cdUndoKey
</nowiki>}}

=== xterm のタイトル ===

あなたのターミナルエミュレータがサポートしていれば、Zsh からターミナルのタイトルを設定できます。これにより、タイトルを動的に変更し、シェルの状態に関する状態 (例えば、ユーザ名とカレントディレクトリや現在実行中のコマンド) を表示できます。

xterm のタイトルは [https://www.tldp.org/HOWTO/Xterm-Title-3.html#ss3.1 xterm の制御シーケンスオペレーティングシステムコマンド]である {{ic|\e]2;}}{{ic|\a}} か {{ic|\e]2;}}{{ic|\e\\}} で設定します。例えば:

$ print -n '\e]2;My xterm title\a'

このコマンドは、タイトルを以下に設定します:

My xterm title

タイトルを動的にするシンプルな方法は、{{ic|precmd}} フック関数と {{ic|preexec}} フック関数でタイトルを設定することです。利用可能なフック関数リストと説明は {{man|1|zshmisc|Hook Functions}} を見てください。

{{ic|print -P}} を使えば、さらに Zsh のプロンプトエスケープも使用できます。

{{Tip|
* タイトルの表示は複数のコマンドに分けることができます。ただし、コマンドは連続していなければなりません。
* [[GNU Screen]] は、xterm のタイトルを hardstatus ({{ic|%h}}) に送信します。Screen の[https://www.gnu.org/software/screen/manual/html_node/String-Escapes.html 文字列エスケープ]を使いたい場合 (例えば、色を付けたい場合など)、エスケープシーケンス {{ic|\e_}}{{ic|\e\\}} を使って hardstatus を設定する必要があります。文字列エスケープを {{ic|\e]2;}}{{ic|\a}} 内で使用した場合、ターミナルエミュレータは、Screen の文字列エスケープを解釈できないため、タイトルが文字化けしてしまいます。
}}

{{Note|
* 変数を表示するときに {{ic|print}} の {{ic|-P}} オプションは使用しないでください。変数がプロンプトエスケープとしてパースされてしまいます。
* 変数を表示するときには、[https://zsh.sourceforge.io/Doc/Release/Expansion.html#Parameter-Expansion-Flags パラメータ展開フラグ] {{ic|q}} を使用してください。変数がエスケープシーケンスとしてパースされないようにするためです。
}}

{{hc|~/.zshrc|<nowiki>
autoload -Uz add-zsh-hook

function xterm_title_precmd () {
print -Pn -- '\e]2;%n@%m %~\a'
[[ "$TERM" == 'screen'* ]] && print -Pn -- '\e_\005{2}%n\005{-}@\005{5}%m\005{-} \005{+b 4}%~\005{-}\e\\'
}

function xterm_title_preexec () {
print -Pn -- '\e]2;%n@%m %~ %# ' && print -n -- "${(q)1}\a"
[[ "$TERM" == 'screen'* ]] && { print -Pn -- '\e_\005{2}%n\005{-}@\005{5}%m\005{-} \005{+b 4}%~\005{-} %# ' && print -n -- "${(q)1}\e\\"; }
}

if [[ "$TERM" == (Eterm*|alacritty*|aterm*|foot*|gnome*|konsole*|kterm*|putty*|rxvt*|screen*|wezterm*|tmux*|xterm*) ]]; then
add-zsh-hook -Uz precmd xterm_title_precmd
add-zsh-hook -Uz preexec xterm_title_preexec
fi
</nowiki>}}

==== ターミナルエミュレータのタブのタイトル ====

一部のターミナルエミュレータとマルチプレクサは、タブのタイトルの設定をサポートしています。そのためのエスケープシーケンスはターミナルによります:

{| class="wikitable sortable"
! ターミナル
! エスケープシーケンス
! 説明
|-
! [[GNU Screen]]
| {{ic|\ek}}{{ic|\e\\}}
| Screen のウィンドウタイトル ({{ic|%t}})。
|-
! [[Konsole]]
| {{ic|\e]30;}}{{ic|\a}}
| Konsole のタブタイトル。
|}

=== シェル環境の検出 ===

[[環境変数#シェル環境の検出]] を見てください。

=== /dev/tcp と等価な ztcp ===

{{ic|zsh/net/tcp}} モジュールを使用してください:

$ zmodload zsh/net/tcp

これで、TCP 接続を確立できます:

$ ztcp example.com 80

詳細は {{man|1|zshmodules|THE_ZSH/NET/TCP_MODULE}} と {{man|1|zshtcpsys}} で見られます。

=== コマンドラインに文字があるときにもシェルを終了するショートカット ===

デフォルトでは、コマンドラインに文字が入力されている場合、{{ic|Ctrl+d}} はシェルを終了しません。これを修正するには:

{{hc|.zshrc|
exit_zsh() { exit }
zle -N exit_zsh
bindkey '^D' exit_zsh
}}

=== pacman -F "command not found" ハンドラー ===

[[pacman]] には、あるファイルを含むパッケージを検索する機能があります。以下の command-not-found ハンドラは、不明なコマンドが実行されたときに、pacman を直接使用してマッチするパッケージを検索します。

{{hc|1=~/.zshrc|2=
...
function command_not_found_handler {
local purple='\e[1;35m' bright='\e[0;1m' green='\e[1;32m' reset='\e[0m'
printf 'zsh: command not found: %s\n' "$1"
local entries=(
${(f)"$(/usr/bin/pacman -F --machinereadable -- "/usr/bin/$1")"}
)
if (( ${#entries[@]} ))
then
printf "${bright}$1${reset} may be found in the following packages:\n"
local pkg
for entry in "${entries[@]}"
do
# (repo package version file)
local fields=(
${(0)entry}
)
if [[ "$pkg" != "${fields[2]}" ]]
then
printf "${purple}%s/${bright}%s ${green}%s${reset}\n" "${fields[1]}" "${fields[2]}" "${fields[3]}"
fi
printf ' /%s\n' "${fields[4]}"
pkg="${fields[2]}"
done
fi
return 127
}
...
}}

{{Note|pacman のファイルデータベースは、通常の同期データベースから分離されており、{{ic|pacman -Fy}} を使ってフェッチする必要があります。詳細は [[pacman#パッケージ・データベースに問い合わせる]] を見てください。}}

[[pkgfile]] を使う代替としては、[[#pkgfile の "command not found" ハンドラー]] を見てください。

=== キーバインドを使ってバックバッファをクリアする ===

デフォルトでは、画面をクリアするキーバインドは、ほとんどのターミナルエミュレータでバックバッファ (上にスクロールしないと見えない部分) をクリアしません。この問題の解決策とｈしては:

{{hc|~/.zshrc|2=
...
function clear-screen-and-scrollback() {
printf '\x1Bc'
zle clear-screen
}

zle -N clear-screen-and-scrollback
bindkey '^L' clear-screen-and-scrollback
...
}}

== サードパーティ拡張 ==

=== 設定フレームワーク ===

{{Note|フレームワークは、抽象化と複雑化のレベルを導入します。それらは未定義の挙動をもたらす可能性があり、シェルが壊れた場合、''最初の'' デバッグステップは、プレーンなシェルに戻ることです。}}

* {{App|oh-my-posh|Oh My Posh は、関数か変数でプロンプト文字列を変更することのできる任意のシェルのためのカスタムプロンプトエンジンです。|https://github.com/JanDeDobbeleer/oh-my-posh|{{AUR|oh-my-posh}}}}
* {{App|oh-my-zsh|Zsh の設定を管理するためのコミュニティ運営の人気なフレームワークです。たくさんの便利な関数、ヘルパー、プラグイン、テーマをバンドルしています。|https://github.com/ohmyzsh/ohmyzsh|{{AUR|oh-my-zsh-git}}}}
* {{App|Prezto|Zsh 用の設定フレームワークです。モジュールが同梱されており、適切なデフォルト、エイリアス、関数、オートコンプリート、プロンプトテーマでコマンドラインインターフェイス環境を充実させることができます。|https://github.com/sorin-ionescu/prezto|{{AUR|prezto-git}}}}
* {{App|ZIM|驚異的なスピードとモジュール式拡張機能の付いた設定フレームワークです。Zim はとても簡単にカスタマイズでき、スピードと機能性を犠牲にせず、モジュールと機能の豊富なセットが付属しています。|https://github.com/zimfw/zimfw|{{AUR|zsh-zim-git}}}}

=== プラグインマネージャー ===

* {{App|Antidote|レガシーな Antibody プラグインマネージャの完全な Zsh 実装です。|https://github.com/mattmc3/antidote|{{AUR|zsh-antidote}}}}
* {{App|zinit (旧 "zplugin")|柔軟な Zsh プラグインマネージャ。クリーンな fpath、レポート、補完管理、ターボモードが付いています。[https://github.com/zdharma-continuum/I_WANT_TO_HELP 復活しました]|https://github.com/zdharma-continuum/zinit|{{AUR|zinit}}}}
* {{App|zi (旧 "zplugin")|zplugin の代替フォークです。zinit のようにオリジナルのプロジェクトの保持やメンテナンスではなく、オリジナルのプロジェクトを拡張することを目的としています。|https://github.com/z-shell/zi}}
* {{App|sheldon|高速で設定可能なシェルプラグインマネージャです。Rust で書かれています。[https://github.com/rossmacarthur/sheldon]|https://github.com/rossmacarthur/sheldon|{{Pkg|sheldon}}}}
* {{App|Antigen|Zsh 用のプラグインマネージャ。oh-my-zsh と vundle にインスパイアされました。[https://github.com/zsh-users/antigen/issues/673 放棄されています]|https://github.com/zsh-users/antigen|{{AUR|antigen-git}}}}
* {{App|zgen|Zsh 用の軽量でシンプルなプラグインマネージャ。[https://github.com/tarjoilija/zgen/issues/123 放棄されています]|https://github.com/tarjoilija/zgen|{{AUR|zgen-git}}}}
* {{App|zplug|Zsh 用の次世代プラグインマネージャ。[https://github.com/zplug/zplug/issues/403#issuecomment-477520784 放棄されています]|https://github.com/zplug/zplug|{{AUR|zplug}}}}

=== Fish のようなシンタックスハイライトとオートサジェスト ===

[[Fish]] には強力なシェルシンタックスハイライトとオートサジェスト機能があります。これらの機能を zsh で使うには、{{pkg|zsh-syntax-highlighting}} と {{pkg|zsh-autosuggestions}} をインストールし、提供されたスクリプトの一方または両方を zshrc の末尾から [[source]] してください ({{pkg|zsh-syntax-highlighting}} が {{pkg|zsh-autosuggestions}} よりも後で source されるようにするためです[https://github.com/zsh-users/zsh-syntax-highlighting#why-must-zsh-syntax-highlightingzsh-be-sourced-at-the-end-of-the-zshrc-file]):

{{hc|1=~/.zshrc|2=
source /usr/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh
source /usr/share/zsh/plugins/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh
}}

=== pkgfile の "command not found" ハンドラー ===

[[pkgfile]] には、{{ic|command_not_found_handler}} 関数を提供する Zsh スクリプトファイルが含まれています。この関数は、認識されないコマンドが入力されたときに、pkgfile のデータベースを自動的に検索します。

この関数を有効化するには、そのスクリプトを [[source]] する必要があります。例えば:

{{hc|1=~/.zshrc|2=
source /usr/share/doc/pkgfile/command-not-found.zsh
}}

{{Note|pkgfile のデータベースは、この機能を使う前に更新が必要な場合があります。詳細は [[pkgfile#インストール]] を見てください。}}

pacman のネイティブな機能を使う代替は、[[#pacman -F "command not found" ハンドラー]] を見てください。

== トラブルシューティング ==

=== IOT instruction ===

{{ic|IOT instruction}} というメッセージは、単にアプリケーションがシグナル 6 (SIGABRT、Signal Abort) で終了したという意味です。[https://zsh.org/workers/51602 修正パッチ]は既に上流に上がっており (なので {{AUR|zsh-git}} で利用できます)、バージョン 5.10 で適用されるでしょう。詳細は、[https://stackoverflow.com/questions/75842144/can-anyone-explain-what-iot-instruction-core-dumped-refers-to/75844316#75844316]、[https://zsh.org/workers/51601]、{{man|7|signal|Standard signals}} を参照してください。

== 参照 ==

* [[Wikipedia:ja:Z Shell]]
* [https://zsh.sourceforge.io/Intro/intro_toc.html Z Shell イントロダクション]
* [https://zsh.sourceforge.io/Guide/zshguide.html ZSH ユーザガイド]
* [https://zsh.sourceforge.io/Doc/Release/index-frame.html Z Shell マニュアル] ([https://zsh.sourceforge.io/Doc/ このページ]とは形式が異なります)
* [https://zsh.sourceforge.io/FAQ/zshfaq01.html Zsh FAQ]
* {{man|1|zsh-lovers}} ({{pkg|zsh-lovers}} パッケージとして利用可能)
* [[Gentoo: Zsh/Guide]]
* [https://www.bash2zsh.com/zsh_refcard/refcard.pdf Bash2Zsh Reference Card]

{{TranslationStatus|Zsh|2026-03-29|867199}}

NVIDIA/トラブルシューティング

2026-03-29T05:07:00Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[en:NVIDIA/Troubleshooting]]
[[ru:NVIDIA (Русский)/Troubleshooting]]
[[zh-hans:NVIDIA/Troubleshooting]]

== 起動に失敗する ==

=== ドライバをインストールした後にシステムが起動しない ===

[[NVIDIA]] ドライバをインストールした後、ディスプレイマネージャに到達する前にシステムがハングする場合、[[カーネルモード設定#モード設定を無効にする|カーネルモード設定を無効]]にしてみてください。

=== Xorg がロードに失敗する、またはレッドスクリーンになる ===

GRUB を使っていてレッドスクリーンになる場合は、{{ic|/etc/default/grub}} を編集して {{ic|1=GRUB_TERMINAL_OUTPUT=console}} をアンコメントして GRUB のフレームバッファを無効にしてください。詳しくは [[GRUB/ヒントとテクニック#フレームバッファの無効化]] を参照。

=== X の起動時に黒画面 / X のシャットダウン時にマシンの電源が切れる ===

NVIDIA ドライバーを更新した後に、Xorg の起動時に画面が黒くなったり、Xorg をシャットダウンするとマシンの電源がオフになるようになった場合、以下の回避策を試してください:

* [[xinitrc]] の先頭に {{ic|xrandr --auto}} を追加する。
* {{ic|1=rcutree.gp_init_delay=1}} [[カーネルパラメータ]]を使用する。
* {{ic|nvidia}} モジュールを直接 [[mkinitcpio.conf]] に追加してみることもできます。

=== 画面は認識されるが、設定が全くできない ===

ときに NVIDIA と X が有効な画面を確認できないことがあります。グラフィックカードに複数の出力端子がある場合、モニターを別の端子に接続してみてください。ノートパソコンの場合、グラフィックカードに VGA/TV 出力が存在することが原因の可能性があります。Xorg.0.log に詳しい情報が出力されます。

無効な {{ic|Option "ConnectedMonitor"}} を {{ic|Section "Device"}} にわざと追加することで Xorg にエラーを投げさせ、修正するにはどうすればよいかを Xorg に出力させるという方法もあります。ConnectedMonitor 設定に関する詳細は [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/xconfigoptions.html#ConnectedMonitor ドキュメント]を参照してください。

X を再起動した後に Xorg.0.log を確認して正しい CRT-x,DFP-x,TV-x の値を見てください。

{{ic|nvidia-xconfig --query-gpu-info}} で役に立つ情報が得られることもあります。

=== "Failing initialization of X screen" により X が起動しない ===

もし {{ic|/var/log/Xorg.0.log}} に、X server がスクリーンの初期化に失敗したと書き込まれる場合

(EE) NVIDIA(G0): GPU screens are not yet supported by the NVIDIA driver
(EE) NVIDIA(G0): Failing initialization of X screen

そして ''nvidia-smi'' が {{ic|No running processes found}} と書き込む場合

解決策は、まず始めに最新の {{Pkg|nvidia-utils}} を再インストールして、{{ic|/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf}} を {{ic|/etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf}} へとコピーします。その後、{{ic|/etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf}} を編集して {{ic|Option "PrimaryGPU" "yes"}} という行を追加してください。コンピューターを再起動すれば、この問題は解決します。

=== Xorg がブート時に失敗し、ブート完了後は起動できる ===

起動時間がとても短いシステムの場合、NVIDIA ドライバーが完全に初期化される前に systemd がディスプレイマネージャを起動してしまうことがあります。起動時に Xorg が実行された時にだけ、ログに以下のようなメッセージが表示されます:

{{hc|/var/log/Xorg.0.log|output=
[ 1.807] (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. Please see the
[ 1.807] (EE) NVIDIA(0): system's kernel log for additional error messages and
[ 1.808] (EE) NVIDIA(0): consult the NVIDIA README for details.
[ 1.808] (EE) NVIDIA(0): *** Aborting ***
}}

このような場合、ディスプレイマネージャから DRI デバイスまでの順番付けをする必要があります。まず、新しい [[udev]] ルールファイルを作成して DRI デバイスのデバイスユニットを作成してください:

{{hc|/etc/udev/rules.d/99-systemd-dri-devices.rules|output=
ACTION=="add", KERNEL=="card*", SUBSYSTEM=="drm", TAG+="systemd"
}}

次にディスプレイマネージャからデバイスまでの依存関係を作成します:

{{hc|/etc/systemd/system/display-manager.service.d/10-wait-for-dri-devices.conf|output=
[Unit]
Wants=dev-dri-card0.device
After=dev-dri-card0.device
}}

デスクトップに必要な追加カードが存在する場合は、Wants と After にスペースで区切って記述してください。

=== 統合 GPU が載っている環境で黒画面 ===

統合 GPU (例: Intel HD 4000、VIA VX820 Chrome 9、AMD Cezanne) のあるシステムを使用していて、{{AUR|nvidia-580xx-dkms}} かこれより古いパッケージをインストールしている場合、起動時、仮想ターミナル切り替え時、X セッションの終了時に黒画面が発生する場合があります。これは、グラフィックモジュール間の競合が原因かもしれません。関連する GPU モジュールをブラックリストに入れることで解決できます。{{ic|/etc/modprobe.d/blacklist.conf}} を作成し、起動時に関連するモジュールがロードされないように設定してください:

{{hc|/etc/modprobe.d/blacklist.conf|
install i915 /usr/bin/false
install intel_agp /usr/bin/false
install viafb /usr/bin/false
install radeon /usr/bin/false
install amdgpu /usr/bin/false
}}

=== 複数の GPU を使うと "no screens found" によって X が起動しない ===

複数の GPU が搭載されているようなシステムで X が以下のメッセージによって起動しない場合:

[ 76.633] (EE) No devices detected.
[ 76.633] Fatal server error:
[ 76.633] no screens found

ディスクリートカードの BusID を X の設定に追加してください。これは、Intel CPU と内蔵 GPU があるシステムや、2つ以上の Nvidia カードが接続されているシステムで起こりえます。BusID を確認するには:

{{hc|# lspci -d ::03xx|
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M / Quadro M500M] (rev a2)
}}

X の設定ファイル内でカードの Device セクションに追加することで修正できます。例:

{{hc|/etc/X11/xorg.conf.d/10-nvidia.conf|
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BusID "PCI:1:0:0"
EndSection
}}

{{Note| BusID のフォーマットが重要です! }}

上の例では、{{ic|01:00.0}} が {{ic|1:0:0}} のように短縮されて記述されています。しかし、BusID の変換はより複雑になることもあります。{{ic|lspci}} の出力は16進法ですが、設定ファイルでは BusID は10進法で記述されるのです! これはつまり、BusID が9よりも大きい場合に16進数から10進数に変換する必要があるということです!

例: lspci での {{ic|5e:00.0}} は {{ic|PCI:94:0:0}} となります。

=== linux >= 4.8 で Modprobe エラー: "Could not insert 'nvidia': No such device" ===

linux 4.8 ではディスクリートカードを使おうとすると次のエラーが発生することがあります:

{{hc|# modprobe nvidia -vv|
modprobe: INFO: custom logging function 0x409c10 registered
modprobe: INFO: Failed to insert module '/lib/modules/4.8.6-1-ARCH/extramodules/nvidia.ko.gz': No such device
modprobe: ERROR: could not insert 'nvidia': No such device
modprobe: INFO: context 0x24481e0 released
insmod /lib/modules/4.8.6-1-ARCH/extramodules/nvidia.ko.gz
}}

{{hc|# dmesg|
...
NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:139b)
NVRM: installed in this system is not supported by the 370.28
NVRM: NVIDIA Linux driver release. Please see 'Appendix
NVRM: A - Supported NVIDIA GPU Products' in this release's
NVRM: README, available on the Linux driver download page
NVRM: at www.nvidia.com.
...
}}

この問題は Linux カーネルの PCIe 電源管理に関連する不適切なコミットによるものです( [https://devtalk.nvidia.com/default/topic/971733/-370-28-with-kernel-4-8-on-gt-2015-machines-driver-claims-card-not-supported-if-nvidia-is-not-primary-card/ この NVIDIA DevTalk スレッド] でドキュメント化されています)。

回避策は {{ic|1=pcie_port_pm=off}} を[[カーネルパラメータ]]に追加することです。これにより、すべてのデバイスにおける PCIe 電源管理が無効化されることに注意してください。

=== システムがサスペンドから復帰しない ===

以下のようなログが発生するとき:

kernel: nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices
kernel: nvidia-modeset: ERROR: GPU:0: Failed detecting connected display devices
kernel: nvidia-modeset: WARNING: GPU:0: Failure processing EDID for display device DELL U2412M (DP-0).
kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DELL U2412M (DP-0)
kernel: nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device DELL U2412M (DP-0).

[https://forums.developer.nvidia.com/t/solution-for-nvidia-sleep-wake-issue-in-linux/110911] から考えられる解決策があります:

以下のコマンドを実行して {{ic|''version''}} の文字列を取得してください:

# strings /sys/firmware/acpi/tables/DSDT | grep -i 'windows ' | sort | tail -1

{{ic|1=acpi_osi=! "acpi_osi=''version''"}} [[カーネルパラメータ]]を[[ブートローダー]]の設定に追加してください。

この問題を引き起こす他の可能性として、{{Pkg|nvidia-open}} パッケージを使用しているというものもあります。以下で説明されています:
* https://bbs.archlinux.org/viewtopic.php?pid=2047692
* https://github.com/NVIDIA/open-gpu-kernel-modules/issues/450
* https://github.com/NVIDIA/open-gpu-kernel-modules/issues/223
* https://github.com/NVIDIA/open-gpu-kernel-modules/issues/94

=== サスペンドから復帰すると黒画面 ===

黒画面の問題が発生し、以下のようなログに出力がある場合:

archlinux kernel: NVRM: GPU at PCI:0000:08:00: GPU-926ecdb0-adb1-6ee9-2fad-52e7214c5011
archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi>
archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi>
archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi>
archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi>
archlinux kernel: NVRM: Xid (PCI:0000:08:00): 13, pid='<unknown>', name=<unknown>, Graphi>

[[NVIDIA/ヒントとテクニック#サスペンド後にビデオメモリを保持する]] で説明されているように NVIDIA のサスペンド、ハイバネート、スリープに関連するサービスを有効化する必要があります。

== クラッシュやハング ==

=== クラッシュの一般的な対処方法 ===

* [[#GSP ファームウェア|GSP ファームウェアを無効]]にしてみる.
* xorg.conf で {{ic|RenderAccel}} を無効にしてみる。
* Xorg が {{ic|"conflicting memory type"}} や {{ic|"failed to allocate primary buffer: out of memory"}} というエラーを出力する場合、あるいは nvidia-96xx ドライバーを使用しているときに "Signal 11" でクラッシュする場合、[[カーネルパラメータ]]に {{ic|nopat}} を追加してください。
* NVIDIA のコンパイラが、カーネルをコンパイルしたのに使用した GCC と現在使っている GCC のバージョンが異なるというエラーを出力する場合、{{ic|/etc/profile}} に以下を追加してください:
export IGNORE_CC_MISMATCH=1
* フルスクリーンのアプリケーションがフリーズ/クラッシュする場合、あなたの使用しているデスクトップ環境の設定で {{ic|Display Compositing}} と {{ic|Direct fullscreen rendering}} を有効化してみてください。

=== メッシュシェーダーのサポートの問題 ===

このバグは、メッシュシェーダーに依存している新しいゲーム (例: Final Fantasy VII Rebirth) にのみ存在します。これは、NVIDIA GPU を使用している場合に環境が存在しないことによるもので、最新のベータ版ドライバを使用していても発生します。[https://github.com/ValveSoftware/Proton/issues/8408]

しかし、[https://github.com/ValveSoftware/Proton/issues/8408#issuecomment-2657340142 pyroveil] を使えば、NVIDIA からフィックスがリリースされるまでの間、SPIR-V の問題を回避することができます。

[https://github.com/HansKristian-Work/pyroveil#pyroveil GitHub のチュートリアル]に従って、このツールをコンパイルしインストールする必要があります。その後、{{ic|1=PYROVEIL=1}} と {{ic|1=PYROVEIL_CONFIG=''/path/to/pyroveil''/hacks/''ffvii-rebirth-nvidia''/pyroveil.json}} [[環境変数]]を設定してゲームを実行してください。

=== OpenGL アプリケーションで視覚的な不具合、ハング、エラー ===

最近の CPU (Intel Sandy Bridge (2011) 以降や AMD Zen (2017) 以降) を使用している場合、その CPU にはマイクロ op キャッシュが搭載されています。マイクロ op キャッシュを使用すると、Cache Aliasing が原因で OpenGL で NVIDIA ドライバとの問題が発生する可能性があります [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/knownissues.html]。通常、マイクロ op キャッシュは BIOS で無効化できますが、パフォーマンスが犠牲になってしまいます [https://chipsandcheese.com/2021/07/03/how-zen-2s-op-cache-affects-performance/]。マイクロ op キャッシュを無効化すると、Xwayland アプリケーションの最も深刻なグラフィックの不具合にも効果がありますが、問題を完全に解決できるわけではありません [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/wayland-issues.html]。

=== システムの更新時や再起動時にカーネルパニック ===

これは NVIDIA 550 シリーズのドライバに存在する既知のバグです。[https://forums.developer.nvidia.com/t/series-550-freezes-laptop/284772] 今のところ原因は不明ですが、ノート PC でしか起こらないようです。詳細は [https://bbs.archlinux.org/viewtopic.php?id=293400&p=3 BBS#293400] を見てください。

この問題の回避策は、ハードウェアによってサポートされている場合は {{Pkg|nvidia-open-dkms}} を、そうでない場合は {{AUR|nvidia-535xx-dkms}} を使用することです。

=== GSP ファームウェア ===

[https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/gsp.html GSP ファームウェア]を使用すると (2024年6月にリリースされた NVIDIA ドライババージョン 555 からデフォルトで有効化されています)、[[Vulkan]] の障害やシステムのクラッシュを含む[https://bbs.archlinux.org/viewtopic.php?pid=2181317 様々な問題]が発生することが知られています。

無効化するには、{{ic|nvidia}} カーネルモジュールに {{ic|1=NVreg_EnableGpuFirmware=0}} [[モジュールパラメータ]]を使用してください。このパラメータはプロプライエタリな NVIDIA ドライバにしか使えません (オープンソースドライバから切り替える方法は [[NVIDIA#インストール]] を参照してください)。

必要に応じて [[Initramfs を再生成する]]のを忘れないでください。このカーネルモジュールオプションを有効にするために、再移動してください。

== 視覚的な問題 ==

=== Xorg で画面のティアリングを防止する ===

{{Note|
* この方法は一部の OpenGL アプリケーションでパフォーマンスの低下が報告されており、WebGL で問題が発生することがあります。また、ドライバがロード後にクロックダウンする時間が大幅に増加します。([https://forums.developer.nvidia.com/t/if-you-have-gpu-clock-boost-problems-please-try-gl-experimentalperfstrategy-1/71762 NVIDIA Support Thread])
* {{ic|ForceFullCompositionPipeline}} は、NVIDIA ドライバ 535 で Proton 下で Vulkan を使用する[https://github.com/ValveSoftware/Proton/issues/6869 一部のゲームの機能を破壊する]ことが知られています。
* {{ic|ForceCompositionPipeline}} は、一部のフルスクリーンのアプリケーションが即座にフリーズする問題を引き起こすことが知られています。これにより、タブアウトするまでシステムが応答しなくなります。一つの回避策は、プログラムを [[Gamescope]] 内で枠無しウィンドウ ({{ic|-b}}) で動作させ、少なくとも一つの他のウィンドウ (タスクバーや何らかのグラフィカルアプリケーション) をスクリーン上に表示させておくことです。
}}

NVIDIA ドライバは、条件付きで、画像を表示するために [https://www.reddit.com/r/linux_gaming/comments/6voivr/comment/dm1uz2j/ composition パイプライン]を使用します。これは、ウィンドウ表現を担う[[コンポジットマネージャ]]とは異なります (コンポジットマネージャはまた、VSync によって画面のティアリングを緩和します)。デフォルトでは、composition パイプラインが使用されるのは、現在の画面変換によって必要とされる場合に限ります。このパイプラインは、可能であれば GPU の特殊化されたディスプレイエンジンを使用し、無理であればより汎用のグラフィックスエンジンを使用します。この挙動を制御する方法は2つあります:

* {{ic|ForceCompositionPipeline}} は、composition パイプラインの使用を強制します (詳細は [[#マルチモニタ]] で説明されています)。
* {{ic|ForceCompositionPipelineFull}} は、composition パイプラインの使用を強制し、かつ、それをグラフィックスエンジンで処理することを強制します。

Xorg でのティアリングは、{{ic|ForceCompositionPipelineFull{{=}}On}} を設定することにより、防止可能です。このオプションが機能するかどうかをテストするには、以下を実行してください:

$ nvidia-settings --assign CurrentMetaMode="nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"

または、''X Server Display Configuration'' メニューオプションにある ''Advanced'' を押してください。''Force Composition Pipeline'' か ''Force Full Composition Pipeline'' のどちらか一方を選択して、''Apply'' をクリックしてください。

この変更を永続化させるには、[[Xorg]] 設定ファイルの {{ic|"Screen"}} セクションにこの設定を追加してください。そうする場合、ドライバーの設定で {{ic|TripleBuffering}} を有効化して、{{ic|AllowIndirectGLXProtocol}} を無効化するべきです。以下の設定例を見てください:

{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|2=
Section "Device"
Identifier "NVIDIA Card"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce GTX 1050 Ti"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
Option "ForceFullCompositionPipeline" "on"
Option "AllowIndirectGLXProtocol" "off"
Option "TripleBuffer" "on"
EndSection
}}

[[Xorg]] の設定ファイルが存在しない場合、{{ic|nvidia-xconfig}} を使って、現在使用しているハードウェア用の設定ファイルを作成することができます ([[NVIDIA#自動設定]]を参照してください)。そして、作成したファイルを {{ic|/etc/X11/xorg.conf}} から適当な場所 ({{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}}) に移動してください。

{{Note|{{ic|nvidia-xconfig}} を使って {{ic|20-nvidia.conf}} に生成された設定オプションの多くはドライバーによって自動的に設定され、必須ではありません。コンポジションパイプラインを有効化するためだけにこのファイルを使用するのであれば、{{ic|Identifier}} と {{ic|Option}} の値の行を含んでいる {{ic|"Screen"}} セクションだけが必須です。残りのセクションはファイルから削除できます。}}

==== マルチモニタ ====

マルチモニタ環境においては、それぞれのディスプレイに対して {{ic|1=ForceCompositionPipeline=On}} を指定する必要があります。例えば:

$ nvidia-settings --assign CurrentMetaMode="DP-2: nvidia-auto-select +0+0 {ForceCompositionPipeline=On}, DP-4: nvidia-auto-select +3840+0 {ForceCompositionPipeline=On}"

こうしないと、{{ic|nvidia-settings}} コマンドはサブモニタを無効化してしまいます。

{{ic|--query}} を使えば、現在のスクリーン名とオフセットを入手できます:

$ nvidia-settings --query CurrentMetaMode

先のコマンドは、2台の 3840x2160 モニタが DP-2 と DP-4 に接続されている場合です。{{ic|xorg.conf}} をエクスポートして正しい {{ic|CurrentMetaMode}} を手に入れ、使用しているそれぞれのディスプレイに対して {{ic|ForceCompositionPipeline}} を追加する必要があります。{{ic|ForceCompositionPipeline}} の設定は対象にしたディスプレイにのみ影響します。

{{Tip|異なるモデルのモニタを使用しているマルチモニタ環境では、リフレッシュレートが若干異なることがあります。垂直同期がドライバによって有効化されている場合、ドライバは複数あるモニタのリフレッシュレートの内たった一つに同期します。これにより、正しく同期できていないモニタではスクリーンのティアリングが発生する可能性があります。主要なモニタのディスプレイを同期させると、他のモニタは正しく同期されません。よって、どのモニタを同期させるか選択する必要があります。このような設定は、{{ic|~/.nvidia-settings-rc}} 内で {{ic|1=0/XVideoSyncToDisplayID=}} を使用するか、{{pkg|nvidia-settings}} をインストールしてグラフィカルな設定方法を使用することにより可能です。}}

=== サスペンドやハイバネートからの復帰後にスクリーンがおかしくなる ===

サスペンドやハイバネートからの復帰後に外部モニターが待機状態から復帰していない可能性もあります。

[[NVIDIA/ヒントとテクニック#サスペンド後にビデオメモリを保持する]] を見てください。

[[GDM]] サービスを使用している際にサスペンド後に画面がおかしくなるバグは nvidia 515.43.04 ドライバで解決されました [https://forums.developer.nvidia.com/t/corrupted-graphics-upon-resume-gnome-41-x-org-495-44-driver/194565/18]。

=== 画面が崩れる: "Six screens" 問題 ===

GeForce GT 100M を使用している場合、X を起動した後に画面が6つに分割されて解像度が 640x480 になってしまうことがあります。同じ問題は Quadro 2000 や高解像度ディスプレイでも報告されています。

この問題を解決するには、{{ic|Device}} セクションで Validation Mode {{ic|NoTotalSizeCheck}} を有効にしてください:
Section "Device"
...
Option "ModeValidation" "NoTotalSizeCheck"
...
EndSection

=== nvidia-470 でテキストやアイコンが見えない ===

GTK4 のアップデートにより、古いグラフィックカードを使うために nvidia-470 ドライバを使用している場合に問題が発生するようになりました。GTK4 をアップデートすると、テキストやアイコンがランダムに消え、ウィンドウ上にカーソルをかざすと再び見えるようになります。[https://forums.developer.nvidia.com/t/multiple-apps-do-not-invalidate-repaint-screen-correctly-with-geforce-gt-730-and-v470-driver-on-ubuntu-24-04/291106/2]

回避策は [https://bbs.archlinux.org/viewtopic.php?pid=2159644#p2159644 Arch Linux のフォーラム]を見てください。

=== スリープから復帰した際に GNOME Shell でグラフィックがおかしくなる問題を解決する ===

スリープから復帰した際に [[GNOME Shell]] でフォントがおかしくなったり、グラフィックのバグが発生する場合、以下の[[カーネルパラメータ]]を設定して電源管理を有効化してみてください:

nvidia.NVreg_DynamicPowerManagement=0x02

詳細: https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/dynamicpowermanagement.html

=== ディスプレイのオフ時や復帰時にシステムがフリーズする ===

デスクトップ環境がディスプレイをオフにした時 (DPMS) や、サスペンドからの復帰時にシステムがフリーズあるいはクラッシュし、dmesg/ジャーナルに以下のような GSP タイムアウトの記録がある場合:

NVRM: _kgspLogXid119: ********************************* GSP Timeout **********************************
NVRM: Xid (PCI:0000:01:00): 119, Timeout after 6s of waiting for RPC response from GPU0 GSP! Expected function 76 (GSP_RM_CONTROL) sequence 1321

GPU が、電源状態の推移時に不安定な低クロック状態になっているのかもしれません。

回避策は、nvidia-smi で GPU やメモリの最小クロックをより高い値に固定することです。

{{ic|nvidia-persistenced.service}} を[[有効化]]/[[起動]]してください。

Find supported clock values (use these to pick valid min/max pairs):

以下で、サポートされているクロック値を見つけてください (有効な最小値と最大値のペアを探してください):

nvidia-smi -q -d SUPPORTED_CLOCKS
nvidia-smi -q -d CLOCK

一時的なテスト

Set minimum clocks (example values; adjust to your GPU’s max supported clocks):

最小クロックを設定 (以下は例の値です。使用中の GPU の最大クロックに調整してください):

nvidia-smi -lgc 800,2100
nvidia-smi -lmc 800,10000

DPMS とサスペンド/復帰をテストして、問題が解決したかしらべてください。
変更を元に戻すには:

nvidia-smi -rgc
nvidia-smi -rmc

永続的な設定 (systemd)

以下の {{ic|nvidia-clocks.service}} のようなユニットを作成してください:

{{hc|/etc/systemd/system/nvidia-clocks.service|2=
[Unit]
Description=Set NVIDIA GPU minimum clocks to avoid GSP timeouts
Requires=nvidia-persistenced.service
After=nvidia-persistenced.service

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -lgc 500,2100
ExecStart=/usr/bin/nvidia-smi -lmc 500,10000
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
}}

最小クロックを調整することで、先の 800 よりも小さくしてアイドル時の電力消費量を下げることができます。値を小さくしすぎると問題が再発することに注意してください。

最後に、{{ic|nvidia-clocks.service}} [[有効化]]/[[起動]]してください。

=== X11 でコンポジタでちらつく (nvidia-open) ===

{{Remove|The release of [https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/commit/b314b7b3873c7dbe66e2b68fed7773e7f8e58267 nvidia-utils 595.58.3-1] on 24-Mar-2026 fixed this issue.}}

Versions of {{Pkg|nvidia-open}} tracking the 590.x version introduced a regression in the GLX vblank path that causes window flickering when a compositor is active under X11. This affects xfwm4, and potentially other compositors relying on GLX for vertical sync.

Users can use the {{AUR|nvidia-580xx-utils}} package which tracks the production versioned driver which is not affected by this bug or continue using the repo packages (which track the new features versioned drivers) implementing the below work-around until upstream fixes the issue.

The default {{ic|vblank_mode}} in xfwm4 is {{ic|auto}}, which resolves to {{ic|glx}} on NVIDIA hardware and triggers the bug.

A good work-around is to change the vblank_mode to a setting of either '''xpresent''' or to '''off'''

For xfwm4, apply the setting persistently with:

$ xfconf-query -c xfwm4 -p /general/vblank_mode -s off

Then restart the X session. Alternatively, {{ic|xpresent}} can be used to retain vblank sync at the cost of slightly higher GPU usage:

$ xfconf-query -c xfwm4 -p /general/vblank_mode -s xpresent

{{Note|Tearing may be visible with {{ic|off}}. If this is unacceptable, prefer {{ic|xpresent}}. See [[#ForceCompositionPipeline]] to address tearing at the Xorg level alongside either setting.}}

See also: [https://bbs.archlinux.org/viewtopic.php?id=311088 Flickering XFCE (X11 with compositor) and nvidia-open-dkms] (Arch Linux Forums)

== パフォーマンスの問題 ==

=== 新しいバージョンのドライバーをインストールした後にパフォーマンスが悪くなる ===

古いドライバーと比べて FPS が落ちている場合、まずダイレクトレンダリングがオンになっているか確認してください ({{ic|glxinfo}} は {{Pkg|mesa-demos}} に含まれています):

$ glxinfo | grep direct

上のコマンドで以下のように表示されるなら:

direct rendering: No

前にインストールしたバージョンのドライバーに戻して再起動すれば解決することがあります。

=== Xorg が極端にラグい ===

{{Accuracy|[https://gitlab.gnome.org/GNOME/mutter/-/issues/2233#note_1538392 ある NVIDIA 開発者]によると、この問題は GNOME 固有ではなく、この問題に関するコメントにはマルチモニタ環境に言及していません。}}

Mutter の一般的な問題は、[https://gitlab.gnome.org/GNOME/mutter/-/issues/2233 アニメーション、動画再生、ゲーミングが Xorg 上でデスクトップの極端なラグを生じさせる]ことです。

[[NVIDIA/ヒントとテクニック#サスペンド後にビデオメモリを保持する]] を参照してください。

これでこの問題を解決できるはずですが、できない場合、おそらく運がないのでしょう。この問題を軽減する1つの方法は、以下のオプションを追加することです:

{{hc|/etc/environment|2=
CLUTTER_DEFAULT_FPS=''メインディスプレイのリフレッシュレート''
__GL_SYNC_DISPLAY_DEVICE=''メインディスプレイの出力名''
}}

そして、NVIDIA Settings で ''Sync to VBlank'' と ''Allow flipping'' をオフにし、NVIDIA Settings を起動時に {{ic|--load-config-only}} フラグを使って起動するようにしてください。
これでもデスクトップの挙動がラグいでしょうが (特に最後の2番目 (または3番目) のモニタ)、遥かにマシになっているはずです。

=== 400 シリーズのカードで CPU 使用率のスパイクが発生する ===

400 シリーズのカードで時々 CPU の使用率が急上昇するような場合、PowerMizer が GPU のクロック周波数を断続的に変更しているのが原因です。以下を Xorg 設定の {{ic|Device}} セクションに追加して、PowerMizer の設定を Adaptive から Performance にしてください:

Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x3322; PowerMizerDefaultAC=0x1"

== その他の問題 ==

=== アプリケーション開始時に Vulkan のエラーが発生する ===

{{Accuracy|他のユーザによる確認が必要}}

Vulkan アクセラレーションを必要とするアプリケーションの実行時に、以下のエラーが発生する場合
Vulkan call failed: -4
{{ic|~/.nv}} か {{ic|~/.cache/nvidia}} ディレクトリを削除してみてください。

=== HDMI で音が出ない ===

時々 nvidia の HDMI オーディオデバイスが以下のコマンドで表示されないことがあります:

$ aplay -l

何かしらの理由により一部の新しいマシンでは NVIDIA GPU のオーディオチップがブート時に無効化されます。詳しくは、[https://devtalk.nvidia.com/default/topic/1024022/linux/gtx-1060-no-audio-over-hdmi-only-hda-intel-detected-azalia/?offset=4 NVIDIA のウェブサイト]や[https://bbs.archlinux.org/viewtopic.php?id=230125 フォーラムの投稿]を読んでください。

オーディオを有効化して NVIDIA デバイスを再読み込みする必要があります。そうするためには、(ノート PC/Bumblebee の場合) GPU がオンになっていることや、GPU がリセットされるので GPU 上で X を実行していないことを確認してください:

# setpci -s 01:00.0 0x488.l=0x2000000:0x2000000
# rmmod nvidia-drm nvidia-modeset nvidia
# echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
# echo 1 > /sys/bus/pci/devices/0000:00:01.0/rescan
# modprobe nvidia-drm
# xinit -- -retro

NVIDIA 上で TTY を実行している場合、スクリーンが表示されなくなってしまわないように上記のコマンドを1つのスクリプトに記述してください。

=== バックライトがオフにならないことがある ===

デフォルトでは、タイムアウトを設定したり xset を実行すると DPMS はバックライトをオフにします。しかしながら、プロプライエタリの Nvidia ドライバーのバグによって、黒画面になるだけで節電ができないことがあります。バグが修正されるまで、対応策として root で {{ic|vbetool}} を使う方法があります。

{{Pkg|vbetool}} パッケージをインストールしてください。

画面をオフにして、何かキーを押したときにバックライトを再度オンにするには:

vbetool dpms off && read -n1; vbetool dpms on

もしくは、xrandr でモニターの出力を有効化・無効化できます (root 権限は不要です):

xrandr --output DP-1 --off; read -n1; xrandr --output DP-1 --auto

==== HardDPMS ====

プロプライエタリの 415 ドライバには [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/xconfigoptions.html#HardDPMS HardDPMS] という新機能が含まれています。これは DisplayPort で接続されたモニターのサスペンドに関する問題を解決することが一部のユーザによって報告されています。

これは 440.26 からデフォルトで有効化されています。古いバージョンのドライバを使っている場合は、{{ic|HardDPMS}} オプションは {{ic|Device}} か {{ic|Screen}} セクション内で設定することができます。例:

{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|
Section "Device"
...
Option "HardDPMS" "true"
...
EndSection

Section "Screen"
...
Option "HardDPMS" "true"
...
EndSection
}}

{{ic|HardDPMS}} は {{ic|BlankTime}} のようなスクリーンセーバーの設定にトリガーされます。以下の {{ic|ServerFlags}} は何も操作せずに 10 分経つとモニターをサスペンドします。

{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|
Section "ServerFlags"
Option "BlankTime" "10"
EndSection
}}

=== xrandr BadMatch ===

[[xrandr]] を使って DELL U2515H のような WQHD モニターを設定しようとしたときに、{{ic|xrandr --addmode}} が {{ic|X Error of failed request: BadMatch}} というエラーを吐く場合、プロプライエタリの NVIDIA ドライバーが HDMI 出力のピクセルクロック最大周波数を 225 MHz 以下に制限しているのが原因かもしれません。モニターを最大解像度に設定するには [[nouveau]] ドライバーをインストールする必要があります。[[カーネルパラメータ]]で {{ic|1=nouveau.hdmimhz=297}} (あるいは {{ic|330}}) を設定することで強制的に特定のピクセルクロック周波数を使うことができます。

もしくは、モニターの EDID が誤っている可能性があります。[[#EDID を上書きする]]を参照してください。

他に考えられる理由としては、デフォルトで現在の NVIDIA ドライバは EDID によって明示的に報告されたモードのみを許可しますが、モニタによって報告されていないリフレッシュレートや解像度のほうが望ましい場合もあります (とは言え、EDID 情報は正しいです。現在の NVIDIA ドライバの制限が厳しすぎるだけなのです)。

そのような場合、非 EDID モードを許可するオプションを {{ic|xorg.conf}} に追加すると良いかもしれません:

{{bc|
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
...
Option "ModeValidation" "AllowNonEdidModes"
...
EndSection
}}

これは出力毎に設定できます。詳細は [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/xconfigoptions.html#ModeValidation README - Appendix B. X Config Options] を参照してください。

=== EDID を上書きする ===

[[カーネルモード設定#モードと EDID を強制する]]、[[Xrandr#トラブルシューティング]]、[[:en:Qnix QX2710#Fixing X11 with Nvidia]] を参照してください。

=== nvidia-settings GUI によるオーバークロックが機能しない ===

[[NVIDIA/ヒントとテクニック#nvidia-settings からオーバークロックを有効化する]]に書かれているように、オーバークロックを有効にした後、nvidia-settings の CLI を使って変数を設定することでオーバークロックできます。詳しくは {{man|1|nvidia-settings}} を参照。

全ての変数を確認する例:

nvidia-settings -q all

パフォーマンスモードを優先するように PowerMizerMode を設定する例:

nvidia-settings -a [gpu:0]/GPUPowerMizerMode=1

ファンスピードを 21% 固定に設定する例:

nvidia-settings -a [gpu:0]/GPUFanControlState=1 -a [fan:0]/GPUTargetFanSpeed=21

複数の変数を同時に設定する例 (50MHz だけ GPU をオーバークロック、50MHz だけビデオメモリをオーバークロック、100mV だけ GPU 電圧を上昇):

nvidia-settings -a GPUGraphicsClockOffsetAllPerformanceLevels=50 -a GPUMemoryTransferRateOffsetGPUGraphicsClockOffsetAllPerformanceLevels=50 -a GPUOverVoltageOffset=100

=== Unknown Error によりオーバークロックが動作しない ===

Xorg を非 root ユーザとして実行していて NVIDIA GPU をオーバークロックしようとした場合、以下と似たようなエラーが発生します:

{{hc|1=$ nvidia-settings -a "[gpu:0]/GPUGraphicsClockOffset[3]=10"|2=
ERROR: Error assigning value 10 to attribute 'GPUGraphicsClockOffset' (trinity-zero:1[gpu:0]) as specified in assignment
'[gpu:0]/GPUGraphicsClockOffset[3]=10' (Unknown Error).
}}

この問題を避けるためには、Xorg を root ユーザとして実行しなければなりません。詳しくは [[Xorg#Rootless Xorg]] をご覧ください。

=== 電力消費 ===

ドライバの使用状況を確認するには:

{{hc|# lsof /dev/nvidia*|
kwin_wayl 867 user 17u CHR 195,0 0t0 418 /dev/nvidia
kwin_wayl 867 user 18u CHR 195,0 0t0 418 /dev/nvidiactl
}}

NVIDIA のカーネルモジュールで省電力が設定されている場合:

{{hc|$ grep . /sys/bus/pci/devices/0000:01:00.0/power/*|
/sys/bus/pci/devices/0000:01:00.0/power/control:auto
/sys/bus/pci/devices/0000:01:00.0/power/runtime_active_time:445933
/sys/bus/pci/devices/0000:01:00.0/power/runtime_status:active
/sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time:1266
/sys/bus/pci/devices/0000:01:00.0/power/wakeup:disabled
}}

# rmmod nvidia_drm

{{hc|$ grep . /sys/bus/pci/devices/0000:01:00.0/power/*|
/sys/bus/pci/devices/0000:01:00.0/power/control:auto
/sys/bus/pci/devices/0000:01:00.0/power/runtime_active_time:461023
/sys/bus/pci/devices/0000:01:00.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:01:00.0/power/runtime_suspended_time:1064192
/sys/bus/pci/devices/0000:01:00.0/power/wakeup:disabled
}}

=== ソフトウェア GL をテストする ===

バイナリの NVIDIA ドライバは Mesa の {{ic|1=LIBGL_ALWAYS_SOFTWARE=1}} 環境変数を尊重しませんが、以下の[[環境変数]]を設定することで libglvnd と EGL に Mesa を使うように指定することができます:

__GLX_VENDOR_LIBRARY_NAME=mesa
__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json

これらを設定することにより、GLX と EGL に Mesa の libgm が使用され、ソフトウェア GL になります。これで、現在遭遇しているバグが NVIDIA の GL ライブラリに関連するものであるかを検証するのに役立ちます。

=== リフレッシュレートが120Hzまでしか上がらない ===

新しいバージョンのドライバ (550xxより後) では、8bpc 出力の帯域が浪費され、仕様帯域上限を超えて信号が送られることにより、より高いリフレッシュレートのモードに繰り替えることができなくなっている[https://bbs.archlinux.org/viewtopic.php?id=302969 ようです]。

{{ic|1=nvidia-modeset.hdmi_deepcolor=0}} を[[カーネルパラメータ]]か [[modprobe]] で設定してください。

ただし、HDR モニターにおいては deep color が必要であることに注意してください。

=== HDMI で Wayland 上で 60Hz にすると誤った色空間が使用される ===

一部のケースで (1660 Super グラフィックスカードを HDMI ケーブルで 60 Hz で使用するなど)、ドライバが出力の色空間を誤って推定してしまうようです。これにより、色が通常よりも暗くなってしまいます。Wayland では色空間を明示的に設定する簡単な方法が存在しないため、{{ic|nvidia-modeset.debug_force_color_space{{=}}2}} を[[カーネルパラメータ]]あるいは [[modprobe]] で設定する方法が一つの回避策になります。

{{TranslationStatus|NVIDIA/Trableshooting|2026-03-29|869863}}

NVIDIA/ヒントとテクニック

2026-03-29T01:18:12Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[en:NVIDIA/Tips and tricks]]
[[ru:NVIDIA/Tips and tricks]]
[[zh-hans:NVIDIA/提示和技巧]]

== ターミナルの解像度を修正する ==

[[NVIDIA#fbdev]] がデフォルトで有効であるため、[[Linux コンソール]]は追加の設定無しでモニタのネイティブな解像度を使用するはずです。

{{ic|fbdev}} を無効化していたり、古いドライバを使用していたりする場合は、解像度が予想より小さい場合があります。回避策として、[[ブートローダー]]の設定で解像度を設定することができます。

GRUB を使用している場合、[[GRUB/ヒントとテクニック#フレームバッファの解像度を設定する]]を見てください。

[[systemd-boot]] を使用している場合、{{ic|''esp''/loader/loader.conf}} 内で {{ic|console-mode}} を設定してください。詳しくは [[systemd-boot#ローダー設定]] をご覧ください。[https://forums.fedoraforum.org/showthread.php?t=306271] [https://web.archive.org/web/20170405115954/https://www.reddit.com/r/archlinux/comments/4gwukx/nvidia_drivers_and_high_resolution_tty_possible/]

[[rEFInd]] を使用している場合、{{ic|''esp''/EFI/refind/refind.conf}} で {{ic|use_graphics_for +,linux}} を設定してください。ちょっとした注意事項としては、これによりブート中にカーネルパラメータが表示されなくなります。

{{Tip|上記の方法でターミナルの解像度を修正できない場合、UEFI の設定で Legacy BIOS モード (しばしば、Compatibility Support Module、CSM、Legacy Boot と呼ばれます) を完全に無効化する必要があるかもしれません。無効化する前に、すべてのデバイスが UEFI ブートを使用するように設定されていることを確認してください。}}

== TV 出力を使う ==

[[Wikibooks:NVIDIA/TV-OUT]] を見てください。

== X で TV (DFP) を唯一のディスプレイとして使う ==

モニターが自動的に検出されない場合、X サーバーは何かしらのデフォルトの解像度 (通常であれば 640x480) にフォールバックします。これは、DVI/HDMI/DisplayPort 接続の TV をメインディスプレイとして使用していて TV がオフまたは切断されているときに X が起動すると問題になります。

NVIDIA に正しい解像度を強制するには、EDID のコピーをファイルシステムのどこかに保存して、X がディスプレイから EDID を読み込まずにそのファイルをパースできるようにします。

EDID を取得するには、{{ic|nvidia-settings}} を起動します。ツリー形式で情報が表示されますが、今は設定は無視して GPU を選択し (対応するエントリは ''GPU-0'' などのような名前であるはずです)、''DFP'' セクションをクリックして (''DFP-0'' などのような名前です)、''Acquire Edid...'' ボタンをクリックしてファイルをどこかに保存してください (例: {{ic|/etc/X11/dfp0.edid}})。

フロントエンドにマウスやキーボードが接続されていない場合、コマンドラインを使って EDID を取得することもできます。EDID ブロックも出力するように引数を指定して X サーバーを起動します:

$ startx -- -logverbose 6

X サーバーが初期化を完了したら、サーバーを閉じ、''nvidia-xconfig'' を使って [[Xorg#一般|Xorg のログファイル]]から EDID ブロックを抽出してください:

$ nvidia-xconfig --extract-edids-from-file ~/.local/share/xorg/Xorg.0.log --extract-edids-output-file ./dfp0.bin

Xorg の設定で以下を {{ic|Device}} セクションに追加してください:

{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|
Option "ConnectedMonitor" "DFP"
Option "CustomEDID" "DFP-0:/etc/X11/dfp0.bin"
}}

{{ic|ConnectedMonitor}} オプションはドライバーに強制的に DFP を認識させます。{{ic|CustomEDID}} にはデバイスの EDID データを指定してください。TV/DFP が接続されているかのように X が起動するようになります。

ブート時に自動的にディスプレイマネージャを起動して適切な X ディスプレイが設定されてから TV の電源を入れることができます。

== ヘッドレス (モニターなし) 解像度 ==

ヘッドレスモードでは解像度は VNC や Steam Link で利用される 640x480 に落ちます。より高い解像度(例えば、1920x1080)で開始するには、{{ic|xorg.conf}} 内の {{ic|Screen}} サブセクションの下にある {{ic|Virtual}} エントリで指定します:

Section "Screen"
[...]
SubSection "Display"
Depth 24
Virtual 1920 1080
EndSubSection
EndSection

{{Tip|ヘッドレスモードは扱いづらく、エラーが発生しがちかもしれません。例えば、ヘッドレスモードではデスクトップ環境や {{Pkg|nvidia-utils}} は解像度を変更するためのグラフィカルな手段を提供しません。解像度の設定を容易にするためには、ポートにモニターが接続されているように見せかける、ダミーの DP や HDMI アダプターを使うことができます。そうすれば、VNC や Steam Link のようなリモートセッションを使って、解像度を普通に変更できます。}}

== 電源を確認 ==

NVIDIA の X.org ドライバーを使って GPU の現在の電源を検出することもできます。現在の電源を表示するには、読み取り専用パラメータの 'GPUPowerSource' をチェックしてください (0 - AC, 1 - バッテリー):

{{hc|$ nvidia-settings -q GPUPowerSource -t|1}}

== ACPI イベントを Listen する ==

NVIDIA ドライバーは自動的に [[acpid]] デーモンに接続して、バッテリー電源やドッキング、ホットキーなどの ACPI イベントを listen します。接続が失敗した場合、X.org は以下のような警告を出力します:

{{hc|~/.local/share/xorg/Xorg.0.log|
NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
NVIDIA(0): may not be running or the "AcpidSocketPath" X
NVIDIA(0): configuration option may not be set correctly. When the
NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will
NVIDIA(0): try to use it to receive ACPI event notifications. For
NVIDIA(0): details, please see the "ConnectToAcpid" and
NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X
NVIDIA(0): Config Options in the README.
}}

上記の警告は完全に無害ですが、{{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} で {{ic|ConnectToAcpid}} オプションを無効にすることでメッセージを消すことができます:

Section "Device"
...
Driver "nvidia"
Option "ConnectToAcpid" "0"
...
EndSection

ノートパソコンを使っている場合、代わりに [[acpid]] デーモンをインストールして有効化すると良いかもしれません。

== GPU の温度をシェルに表示する ==

GPU の温度を確認する方法は3つあります。''nvidia-settings'' は X を使用する必要があります。X を使っていない場合は ''nvidia-smi'' や ''nvclock'' による方法を使って下さい。また、''nvclock'' は GeForce 200 シリーズのカードや Zotac IONITX の 8800GS などの内蔵 GPU など新しい NVIDIA カードでは機能しません。

=== nvidia-settings ===

GPU の温度をシェルに表示するには、以下のように ''nvidia-settings'' を使って下さい:

{{hc|$ nvidia-settings -q gpucoretemp|
Attribute 'GPUCoreTemp' (hostname:0[gpu:0]): 49.
'GPUCoreTemp' is an integer attribute.
'GPUCoreTemp' is a read-only attribute.
'GPUCoreTemp' can use the following target types: GPU.
}}

上記の場合、ボードの GPU 温度は 49 °C になります。

''rrdtool'' や ''conky'' などのユーティリティで使うために温度だけを表示したいときは:

{{hc|$ nvidia-settings -q gpucoretemp -t|49}}

=== nvidia-smi ===

X を全く使わず (例: Wayland を実行している場合やヘッドレスサーバの場合) GPU から直接温度を読み込むことができる ''nvidia-smi'' を使います。

GPU の温度をシェルに表示するには、''nvidia-smi'' を使って下さい:

{{hc|$ nvidia-smi|<nowiki>
Wed Feb 28 14:27:35 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14 Driver Version: 550.54.14 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce GTX 1660 Ti Off | 00000000:01:00.0 On | N/A |
| 0% 49C P8 9W / 120W | 138MiB / 6144MiB | 2% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 223179 G weston 120MiB |
+-----------------------------------------------------------------------------------------+
</nowiki>}}

温度だけ見るには:

{{hc|$ nvidia-smi -q -d TEMPERATURE|2=
==============NVSMI LOG==============

Timestamp : Wed Feb 28 14:27:35 2024
Driver Version : 550.54.14
CUDA Version : 12.4

Attached GPUs : 1
GPU 00000000:01:00.0
Temperature
GPU Current Temp : 49 C
GPU T.Limit Temp : N/A
GPU Shutdown Temp : 95 C
GPU Slowdown Temp : 92 C
GPU Max Operating Temp : 90 C
GPU Target Temperature : 83 C
Memory Current Temp : N/A
Memory Max Operating Temp : N/A
}}

''rrdtool'' や ''conky'' などのユーティリティで使うために温度だけを取得したいときは:

{{hc|1=$ nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader,nounits|2=49}}

=== nvclock ===

{{AUR|nvclock}} パッケージを[[インストール]]してください。

{{Note|''nvclock'' は Geforce 200 シリーズなどの新しい NVIDIA カードの温度センサーにはアクセスできません。}}

たまに ''nvclock'' と ''nvidia-settings''/''nv-control'' が報告する温度が食い違うことがあります。''nvclock'' の作者 (thunderbird) による [https://sourceforge.net/projects/nvclock/forums/forum/67426/topic/1906899 この投稿] によると、''nvclock'' の値のほうが正確なようです。

== オーバークロックと冷却 ==

{{Warning| オーバークロックによってハードウェアに永久的な損傷が発生するかもしれません。警告しましたよ。}}

=== nvidia-settings からオーバークロックを有効化する ===

{{Note|
* rootless モードで Xorg サーバを実行している場合、一部のオーバークロックの設定は適用できません。[[Xorg#root として Xorg を実行|Xorg を root として実行]]することを検討してください。
* ''nvidia-settings'' は root として実行する必要があるかもしれません。
* DRM カーネルモードセッティングを有効にすると Coolbits の値に関わらずオーバークロックができなくなる場合があります。
}}

ドライバのバージョンによっては、一部のオーバークロック機能がデフォルトで有効になっています。一部のサポートされていないオーバークロック機能は {{ic|Device}} セクションで ''Coolbits'' オプションで有効化する必要があります:

Option "Coolbits" "''値''"

{{Tip| ''Coolbits'' オプションは、Xorg の設定ファイルを操作する ''nvidia-xconfig'' を使って簡単に設定できます: {{bc|1=# nvidia-xconfig --cool-bits=''value''}}}}

''Coolbits'' の値は2進数の構成ビットを足し合わせたものです。構成ビットは以下のとおりです:

* {{ic|8}} (ビット3) - ''nvidia-settings'' の ''PowerMizer'' ページの追加のオーバークロック機能を有効化します。Fermi や Fermi より新しいアーキテクチャでバージョン 337.12 から利用可能です。[https://www.phoronix.com/scan.php?px=MTY1OTM&page=news_item]
* {{ic|16}} (ビット4) - ''nvidia-settings'' の CLI のオプションを使ってオーバーボルテージできるようにします。Fermi や Fermi より新しいアーキテクチャでバージョン 346.16 から利用可能です。[https://www.phoronix.com/scan.php?page=news_item&px=MTg0MDI]

サポートされていないバージョンのドライバを使用している場合は、以下のビットも使用する必要があるかもしれません:

* {{ic|1}} (ビット0) - ''nvidia-settings'' の ''Clock Frequencies'' ページで古い(Fermi以前)コアをオーバークロックできるようにします。バージョン 343.13 で削除されました。
* {{ic|2}} (ビット1) - このビットがセットされると、ドライバは「ビデオメモリの容量が異なる複数の GPU を使用するときに SLI の初期化を試みます。」バージョン 470.42.01 で削除されました。
* {{ic|4}} (ビット2) - ''nvidia-settings'' の ''Thermal Monitor'' ページで GPU ファンの速度を手動設定できるようにします。バージョン 470.42.01 で削除されました。

複数の機能を有効化するには ''Coolbits'' の値に上記の値を足し合わせてください。例えば、Fermi コアのオーバークロックとオーバーボルテージを有効化する場合は {{ic|Option "Coolbits" "24"}} をセットします。

''Coolbits'' に関するドキュメントは {{ic|/usr/share/doc/nvidia/html/xconfigoptions.html}} と[https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/xconfigoptions.html#Coolbits ここ]にあります。

{{Note| 別の手段としては DOS(推奨) 内から、あるいは [https://www.techpowerup.com/download/nvidia-nvflash/ nvflash] と [https://www.guru3d.com/files-details/nvidia-bios-editor-download-nibitor.html NiBiTor 6.0] を Win32 環境内で使って、GPU BIOS を編集しリフラッシュするというものがあります。BIOS をフラッシュする利点は電圧制限を上げられることだけでなく、一般に Coolbit のようなソフトウェアオーバークロッキングの方法で安定性が向上することです。[https://ivanvojtko.blogspot.sk/2014/03/how-to-overclock-geforce-460gtx-fermi.html Fermi BIOS modification tutorial]}}

=== 静的な 2D/3D クロックを設定する ===

[[カーネルモジュールパラメータ]]を使用して PowerMizer を最大パフォーマンスレベルで有効化してください (この設定がないと VSync が機能しません):

{{hc|/etc/modprobe.d/nvidia.conf|2=
options nvidia NVreg_RegistryDwords="PerfLevelSrc=0x2222"
}}

=== GPU のブーストクロックを下げる ===

[https://nouveau.freedesktop.org/CodeNames.html#NV140 Volta (NV140/GVXXX)] GPU 及びそれ以降では、クロックブーストが異なる方法で動作します。最大クロックはブート時に、サポートされている最も高い制限値に設定されます。これが望ましい動作である場合は、設定は必要ありません。

これの欠点は、電力効率が低いことです。クロックが上がると、安定性のために電圧を上げる必要があります。その結果として、電力消費量、発熱、ファンの音量が非線形的に増加します。なので、ブーストクロックの制限を下げることで、電力効率を上げることができます。

ブーストクロックの制限は ''nvidia-smi'' を使用して変更できます:

* サポートされているクロックレートを表示: {{bc|$ nvidia-smi -q -d SUPPORTED_CLOCKS}}
* GPU のブーストクロックの制限を 1695 MHz に設定: {{bc|1=# nvidia-smi --lock-gpu-clocks=0,1695 --mode=1}}
* メモリのブーストクロックの制限を 5001 MHz に設定: {{bc|1=# nvidia-smi --lock-memory-clocks=0,5001}}

電力効率の最適化をするには、ゲームをプレイしながら ''nvidia-smi'' で GPU 使用率を確認してください。VSync はオンにしておく必要があります。ブーストクロックの制限を下げると、GPU 使用率が増加します。遅い GPU では、各フレームを描画するのにより長い時間がかかるからです。GPU 使用率が 100% になり、かつ、カクつきが発生しない程度にまでクロックを下げれば、効率は最大になります。このとき、各フレームはリフレッシュレートを維持するのにちょうど十分なほど高速に描画できていることになります。

例として、RTX 3090 Ti でデフォルトから上記の設定に変更した場合、Hitman 3 を 4K 60 FPS でプレイしたところ、電力消費量が 30% 減少し、温度は 75 度から 63 度に、ファンの速度は 73% から 57% に低下しました。

=== オーバークロックの設定を保存する ===

通常、''nvidia-settings'' インターフェイスで設定したクロックと電圧のオフセットは保存されず、再起動すると消えてしまいます。幸い、プロプライエタリドライバにおいてオーバークロック用のインターフェイスを提供し、ユーザのオーバークロック設定を保存することが可能で、起動時に自動的に設定を適用するツールがあります。以下にその一部を挙げます:

* {{AUR|gwe}} - グラフィカル。デスクトップセッションの開始時に設定を適用します。
* {{AUR|nvclock}} と {{AUR|systemd-nvclock-unit}} - グラフィカル。システムの起動時に設定を適用します。
* {{AUR|nvoc}} - テキストベース。プロファイルは {{ic|/etc/nvoc.d/}} 下の設定ファイルです。デスクトップセッション開始時に設定を適用します。

あるいは、{{ic|GPUGraphicsClockOffset}} 属性と {{ic|GPUMemoryTransferRateOffset}} 属性を[[自動起動|起動時に]] ''nvidia-settings'' のコマンドラインインターフェイスでセットすることができます。例えば:

$ nvidia-settings -a "GPUGraphicsClockOffset[''performance_level'']=''offset''"
$ nvidia-settings -a "GPUMemoryTransferRateOffset[''performance_level'']=''offset''"

{{ic|''performance_level''}} は最も高いパフォーマンスレベルとなります。マシンに複数の GPU が存在する場合、GPU ID を指定する必要があります: {{ic|1=[gpu:''gpu_id'']GPUGraphicsClockOffset[''performance_level'']=''offset''}}。

=== カスタムの TDP 制限 ===

{{Accuracy|It seems that not all cards support this. Among the 3 cards available to me: a desktop 3080 Ti, a mobile 1650 MaxQ, and a mobile 500 Ada, this only worked on the 3080 Ti; on the two laptops I got "not supported for GPU" warnings. Is this feature unavailable for mobile GPUs?}}

最近の NVIDIA グラフィックカードは TDP と温度が制限内に収まるように周波数を調整します。パフォーマンスを上げるために TDP 制限を変更できます。これにより温度が上昇し、電力消費量が増加するでしょう。

例えば、電力制限を 160.30W に設定するには:

# nvidia-smi -pl 160.30

(ドライバの永続化なしで)電力制限を起動時に設定するには:

{{hc|/etc/systemd/system/nvidia-tdp.timer|2=
[Unit]
Description=Set NVIDIA power limit on boot

[Timer]
OnBootSec=5

[Install]
WantedBy=timers.target
}}

{{hc|/etc/systemd/system/nvidia-tdp.service|2=
[Unit]
Description=Set NVIDIA power limit

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -pl 160.30
}}

そして、{{ic|nvidia-tdp.timer}} を[[有効化]]してください。

=== ログイン時にファンの速度を設定する ===

{{Accuracy|GPU のファン速度を手動設定するには (たとえ Xorg が root として実行されていたとしても) ''nvidia-settings'' を root として実行する必要があるため、以下の方法はうまく行きません。}}

''nvidia-settings'' のコンソールインターフェイスを使ってグラフィックカードのファンの速度を調整することができます。まず、Xorg 設定の [[#nvidia-settings からオーバークロックを有効化する|Coolbits]] オプションでビット2を有効化していることを確認してください。

{{Note| 現在 GeForce 400/500 シリーズのカードではこの方法を使ってログイン時にファンの速度を設定することはできません。この方法では ''nvidia-settings'' を使って現在の X セッション内でファンのスピードを変更することしかできません。}}

Xorg が起動した時にファンを調整するには以下の行を [[xinitrc]] ファイルに記述します。{{ic|''n''}} は設定したいファンの速度のパーセンテージに置き換えて下さい。

nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=''n''"

GPU とファンの番号を増やすことで二番目の GPU を設定することもできます。

nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''" \
-a "[gpu:1]/GPUFanControlState=1" -a [fan:1]/GPUCurrentFanSpeed=''n''" &

[[GDM]] や [[KDM]] などのログインマネージャを使用している場合、デスクトップエントリファイルを作成して設定をさせることもできます。{{ic|~/.config/autostart/nvidia-fan-speed.desktop}} を作成してその中に以下のテキストを入力してください。{{ic|''n''}} は速度のパーセンテージに置き換えて下さい。

[Desktop Entry]
Type=Application
Exec=nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''"
X-GNOME-Autostart-enabled=true
Name=nvidia-fan-speed

{{Note|ドライバーのバージョン 349.16 から、{{ic|GPUCurrentFanSpeed}} は {{ic|GPUTargetFanSpeed}} に置き換わっています [https://devtalk.nvidia.com/default/topic/821563/linux/can-t-control-fan-speed-with-beta-driver-349-12/post/4526208/#4526208]。}}

複数のグラフィックカードのファン速度を調整できるようにしたい場合、以下のコマンドを実行:

$ nvidia-xconfig --enable-all-gpus
$ nvidia-xconfig --cool-bits=4

{{Note|一部のラップトップ(ThinkPad [https://devtalk.nvidia.com/default/topic/1052110/linux/can-t-control-gtx-1050-ti-max-q-fan-on-thinkpad-x1-extreme-laptop/post/5340658/#5340658 X1 Extreme] や [https://devtalk.nvidia.com/default/topic/1048624/linux/how-to-set-gpu-fan-speed/post/5321818/#5321818 P51/P52] を含む)においては、2つのファンがあるものの、どちらも nvidia によって制御されません。}}

=== NVML によるシンプルなオーバークロックスクリプト ===

Nvidia Management Library (NVML) は、GPU のコアとメモリのクロックオフセットと電力制限値を管理できる API を提供しています。これを使うには、{{Pkg|python-nvidia-ml-py}} をインストールし、以下の Python スクリプトを所望の設定で使用してください。このスクリプトは、起動のたびに root として実行してオーバークロック/低電圧の設定を適用し直す必要があります。

{{bc|1=
#!/usr/bin/env python

from pynvml import *

nvmlInit()

# 調節対象の GPU を指定する。以下でエラーが発生する場合や、複数の GPU が存在する場合、1 に設定するか、他の値を試してください
myGPU = nvmlDeviceGetHandleByIndex(0)

# 以下の行の "000" の部分を所望の GPU クロックオフセット値に置き換えてください。
nvmlDeviceSetGpcClkVfOffset(myGPU,000)

# 以下の行の "000" の部分を、所望のメモリクロックオフセット値の「2倍」に置き換えてください。
# 例えば、オフセットが 500 である場合、以下の行には 1000 と記述してください。
nvmlDeviceSetMemClkVfOffset(myGPU,000)

# 以下に電力制限値を mW で設定してください。例えば、216W は 216000 (mW) になります。電力制限値を調整したくない場合は以下の行を削除してください。
nvmlDeviceSetPowerManagementLimit(myGPU, 000000)
}}

=== NVML で低電圧化 ===

NVML API を用いることで GPU の低電圧化もできます。これにより、電力消費量を減らし、温度を下げることができます。パフォーマンスのロスは最小限であり、それどころか逆にパフォーマンスが向上することもあります。特にノート PC においては、低電圧化が望ましいかもしれません。

{{Note|極度に低電圧化すると、深刻な安定性の問題を生じる可能性があります。特に、ファームウェアから直接設定した場合、コンピュータが起動不能になることもあります。一部のマザーボードには、これを防ぐための低電圧保護の設定が存在します。低電圧化を行う際は、この設定を事前に無効にしておく必要があります (Alienware m16 R1 がその例です)。(低電圧化による) 恩恵は、マザーボードのブランドとモデルにより異なります。

さらに、オーバークロックの場合と同じく、電圧は少しずつ調整して、そのたびに[[ストレステスト|システムの安定性をテスト]]するべきです。}}

{{Pkg|python-nvidia-ml-py}} を[[インストール]]し、以下のスクリプトを[[作成]]、そして[[実行可能属性|実行可能に]]してください。

{{hc|/usr/local/sbin/nvidia-undervolt.py|2=
#!/bin/env python

from pynvml import *
from ctypes import byref

nvmlInit()

# 電圧を調整する GPU の選択。複数 GPU の環境でエラーになる場合は、1など他の値に設定してください。
myGPU = nvmlDeviceGetHandleByIndex(0)
##print(f"myGPU value: {myGPU}")

# 許容最小・最大電力の取得。
##min_power, max_power = nvmlDeviceGetPowerManagementLimitConstraints(myGPU)
##print(f"Allowed range: {min_power} mW to {max_power} mW")

# この行で電力制限を mW 単位で設定できます (例: 216W は 216000 になります)。
# この値は、許容最小・最大電力の制限内に収まっていなければなりません。
# 電力制限を設定しない場合は、以下の行を削除あるいはコメントアウトしてください。
nvmlDeviceSetPowerManagementLimit(myGPU, 000000)

# 許容最小・最大クロックの定義。
# GPU によってサポートされているクロックは次のコマンドで確認できます:
# nvidia-smi -q -d SUPPORTED_CLOCKS
nvmlDeviceSetGpuLockedClocks(myGPU,''210'',''2340'')

####################################
# ============ P0 State ============
####################################

# ============ メモリ ============
# 必要に応じて以下のコードをアンコメント、編集してください。
# 注意: メモリクロックのオフセットは「2倍する」必要があります。
# 例えば、オフセットを 500 に設定したい場合は、
# clockOffsetMHz に 1000 を代入してください。

##infoMemP0 = c_nvmlClockOffset_t()
##infoMemP0.version = nvmlClockOffset_v1
##infoMemP0.type = NVML_CLOCK_MEM
##infoMemP0.pstate = NVML_PSTATE_0
##infoMemP0.clockOffsetMHz = ''2000''
### このオフセットは、メモリをどれだけより速くするかを表しています。
### 例えば、この場合、メモリは 8000 MHz ではなく、
### 8000 + (2000 / 2) = 9000 MHz で動作します。

##nvmlDeviceSetClockOffsets(myGPU, byref(infoMemP0))

# ============ グラフィックス =============
infoGraphicsP0 = c_nvmlClockOffset_t()
infoGraphicsP0.version = nvmlClockOffset_v1
infoGraphicsP0.type = NVML_CLOCK_GRAPHICS
infoGraphicsP0.pstate = NVML_PSTATE_0
infoGraphicsP0.clockOffsetMHz = ''270''
## このオフセットの値は、周波数-電圧曲線が 270 MHz 上に上がることを意味します。
## 例えば、本来 2070 MHz で動作する電圧では、
## この設定により 2070 + 270 = 2340 MHz で動作するようになります。

nvmlDeviceSetClockOffsets(myGPU, byref(infoGraphicsP0))

nvmlShutdown()
}}

使用した関数の詳細は [https://docs.nvidia.com/deploy/nvml-api/index.html NVML API ドキュメント] Section 5.18 にあります。[https://www.reddit.com/r/linux_gaming/comments/1fm17ea/comment/lo7mo09/ この Reddit の投稿]では、低電圧化をクロックオフセットで行う理由について説明されています。

このスクリプトは、GPU の最も高い [https://docs.nvidia.com/gameworks/content/gameworkslibrary/coresdk/nvapi/group__gpupstate.html P-state] における低電圧化しか行いません。P0 以外の P-state で設定したい場合は、[https://www.reddit.com/r/linux_gaming/comments/1fm17ea/comment/n4vmb4k この Reddit の投稿]を参考にしてください。

{{Note|残念ながら、一部の GPU は、NVML API による電力制限の変更をサポートしていません。コマンド {{ic|nvidia-smi -pl ''000''}} を root ユーザとして実行することで、サポートの有無を確認できます。

サポートがない場合は、スクリプトから電力制限の部分を削除あるいはコメントアウトし、最後の手段として [[#Dynamic_Boost|Dynamic Boost を設定]]する方法があります。}}

スクリプトを root ユーザとして手動で実行して GPU に設定を適用させ、[[ストレステスト|設定のテスト]]を行ってください。'''テストして問題が無いこと (つまり、設定が安定している) を確認せずに、設定を永続化しないでください。'''

良い設定値を見つけたら、起動毎に設定を適用させる必要があります。一つの方法は、systemd サービスです:

{{hc|/etc/systemd/system/nvidia-undervolt.service|2=
[Unit]
Description=Undervolt the NVIDIA GPU

[Service]
Type=oneshot
ExecStart=/bin/python ''/usr/local/sbin/''nvidia-undervolt.py
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=graphical.target
}}

最後に、システムの起動時に設定を適用するために、このサービスを[[有効化]]してください。

== カーネルモジュールパラメータ ==

一部のオプションはカーネルモジュールパラメータから設定できます。パラメータの完全なリストは {{ic|modinfo nvidia}} を実行するか {{ic|nv-reg.h}} を見てください。[[Gentoo:NVidia/nvidia-drivers/ja#カーネルモジュールのパラメーター]] も見てください。

例えば、以下を有効化すると PAT 機能 [https://docs.kernel.org/arch/x86/pat.html] が有効になります。PAT 機能はメモリの割り当て方に影響を及ぼします。PAT は Pentium III に初めて導入され [https://www.kernel.org/doc/ols/2008/ols2008v2-pages-135-144.pdf]、それよりも新しい CPU の殆どでサポートされています([[wikipedia:Page attribute table#Processors]] を参照)。あなたのシステムでこの機能がサポートされている場合、パフォーマンスが向上するはずです。

{{hc|/etc/modprobe.d/nvidia.conf|2=
options nvidia NVreg_UsePageAttributeTable=1
}}

一部のノートパソコンでは NVIDIA の設定を有効化するために以下のオプションを含めなければなりません。さもないと "Setting applications clocks is not supported" などと表示されます。

{{hc|/etc/modprobe.d/nvidia.conf|2=
options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1"
}}

{{Note|[[カーネルモジュール#/etc/modprobe.d/ 内のファイルを使う]] にある通り、[[NVIDIA#DRM カーネルモード設定|early KMS]] を使用している場合は [[Initramfs を再生成する]]必要があります。}}

== サスペンド後にビデオメモリを保持する ==

デフォルトでは、システムのサスペンドと復帰時に NVIDIA の Linux ドライバーは必須のビデオメモリの割り当てのみを保存し復元します。NVIDIA 曰く:
:結果として生じるビデオメモリの内容の消失は、ユーザスペースの NVIDIA ドライバや一部のアプリケーションによって部分的に補われます。しかし、電源管理サイクルの終了時にレンダリングの破損やアプリケーションのクラッシュなどの機能不全が発生する可能性があります。

"まだ実験段階の" インターフェイスを使用すれば、(ディスクまたは RAM に十分な領域があれば) ビデオメモリ全てを保存できるようになります。

ビデオメモリの内容を全て保存し復元するようにするには、{{ic|nvidia}} カーネルモジュールに対して {{ic|1=NVreg_UseKernelSuspendNotifiers=1}} [[カーネルモジュールパラメータ]]を設定する必要があります。NVIDIA はこのパラメータをデフォルトで設定していませんが、一方 Arch Linux では、サポートされているドライバにおいてこのパラメータがデフォルトで設定されており、ビデオメモリはデフォルトで保持されます。

{{ic|NVreg_UseKernelSuspendNotifiers}} が有効であるかを調べるには、以下を実行してください:

# sort /proc/driver/nvidia/params

{{ic|UseKernelSuspendNotifiers: 1}} という行と、{{ic|TemporaryFilePath: "/var/tmp"}} という行があるはずです (これらのパラメータについては以下で説明されています)。

上流の要件通り、サポートされているドライバ上では、サービス {{ic|nvidia-suspend.service}}、{{ic|nvidia-hibernate.service}}、{{ic|nvidia-resume.service}} はデフォルトで無効化されています。バージョン 595 以降のオープンソースなカーネルモジュールでは、ビデオメモリの保持は、カーネルの suspend notifier によって処理されます。これにより、NVIDIA のサスペンド/ハイバネートサービスは必要ありません。

詳細は [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/powermanagement.html NVIDIA のドキュメント]を参照してください。

{{Note|
* [[NVIDIA#DRM カーネルモード設定|Early KMS]] を使用する場合 (つまり、{{ic|nvidia}} モジュールのロードが initramfs の段階で起こる場合)、モジュールは {{ic|NVreg_TemporaryFilePath}} (前回のビデオメモリを保持しているパス) にアクセスできません。よって、ハイバネートを使用する場合は、early KMS を使用するべきではありません。
* [[カーネルモジュール#/etc/modprobe.d/ 内のファイルを使う]] にある通り、early KMS を使用している場合は [[initramfs を再生成する]]必要があります。
* 上流のデフォルトでは、ビデオメモリの内容は ([[tmpfs]] である) {{ic|/tmp}} に保存されます。NVIDIA は、最高のパフォーマンスを得るために[https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/powermanagement.html#PreserveAllVide719f0 他のファイルシステムを使うことを推奨]しています。また、{{ic|/tmp}} のサイズがメモリの容量に対して不十分である場合も、他のファイルシステムを使う必要があります。このような理由から、Arch Linux では、サポートされているドライバにおいて {{ic|1=nvidia.NVreg_TemporaryFilePath=/var/tmp}} パラメータがデフォルトで設定されています。
* ビデオメモリの内容を保存するファイルシステムは、無名一時ファイルをサポートし (例えば、ext4 や XFS)、かつビデオメモリの割り当てを保存するのに十分な容量がある必要があります (つまり、すべての NVIDIA GPU のメモリ容量合計の 1.05 倍以上)。コマンド {{ic|1=nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits}} を使えば、システム上のすべての GPU ビデオメモリの容量を一覧表示できます。
}}

== Dynamic Boost ==

主なシステム要件は、Ampere (及びそれより新しい) GPU が搭載されているラップトップであることです。

Dynamic Boost は、システムのワークロードに応じて GPU 及び CPU の電力消費を管理する、システム全体で動作する電力制御ソフトウェアです。[https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/dynamicboost.html] 適宜、電力制限を上げることによって、特に GPU を使用するアプリケーションでパフォーマンスを向上させることができます。

詳細は [[CPU 周波数スケーリング#nvidia-powerd]] を参照してください。

{{Tip|電力制限を手動で設定できない人にとっては特に役立つでしょう。[[NVIDIA Optimus#消費電力 (TDP) が低いままになる]] を参照してください。}}

== ドライバーの持続 ==

NVIDIA はブート時に任意で実行できるデーモンを用意しています。標準的な単一 GPU の X デスクトップ環境では持続デーモンは必要ではなく、むしろ問題を引き起こします [https://devtalk.nvidia.com/default/topic/1044421/linux/nvidia-persistenced-causing-60-second-reboot-delays]。詳細については NVIDIA ドキュメントの [https://docs.nvidia.com/deploy/driver-persistence/index.html#persistence-daemon Driver Persistence] 章をご覧ください。

ブート時に持続デーモンを開始するには {{ic|nvidia-persistenced.service}} を[[有効化]]してください。手動での使用については[https://docs.nvidia.com/deploy/driver-persistence/index.html#usage 上流のドキュメント]をご覧ください。

== YCbCr 4:2:0 サブサンプリングを強制する ==

[[Wikipedia:HDMI#Refresh frequency limits for standard video|古い出力規格の制限]]に悩まされているが、YUV 4:2:0 を使用することで問題を緩和できるような場合は、NVIDIA ドライバに YUV420 を強制するためのドキュメント化されていない X11 オプションがあります:

Option "ForceYUV420" "True"

これで、より高い解像度とリフレッシュレートを利用できますが、画質に悪影響を及ぼします。

== GPU を使ってレンダリングするようにアプリケーションを設定する ==

[[PRIME#GPU を使ってレンダリングするようにアプリケーションを設定する]] を参照してください。

{{TranslationStatus|NVIDIA/Tips and tricks|2026-03-29|870075}}

Pacman

2026-03-15T06:35:47Z

AshMyzk: 同期

{{Lowercase title}}
[[Category:Arch プロジェクト]]
[[Category:パッケージマネージャー]]
[[de:Pacman]]
[[en:Pacman]]
[[es:Pacman]]
[[fi:Pacman]]
[[fr:Pacman]]
[[it:Pacman]]
[[hu:Pacman]]
[[pt:Pacman]]
[[ru:Pacman]]
[[sv:Pacman]]
[[zh-hans:Pacman]]
{{Related articles start}}
{{Related|/パッケージの署名}}
{{Related|/Pacnew と Pacsave}}
{{Related|/ローカルデータベースの復元}}
{{Related|/比較表}}
{{Related|/ヒントとテクニック}}
{{Related|Arch User Repository}}
{{Related|パッケージの作成}}
{{Related|パッケージのダウングレード}}
{{Related|namcap}}
{{Related|FAQ#パッケージ管理}}
{{Related|システムメンテナンス}}
{{Related|Package Proxy Cache}}
{{Related articles end}}

[https://pacman.archlinux.page/ pacman] [[Wikipedia:ja:パッケージ管理システム|パッケージマネージャ]]は [[Arch Linux]] の主要な機能のひとつです。pacman はシンプルなバイナリのパッケージ形式と簡単に利用できる [[Arch build system]] から成っています。pacman のゴールはパッケージ管理を楽にすることであり、[[公式リポジトリ]]にあるパッケージや、ユーザー自身が作成したパッケージを容易に管理することができます。

''pacman'' はマスターサーバーと同期してシステムを最新に保ちます。このサーバー・クライアントモデルによって、シンプルなコマンドだけで必要な依存性を解決してパッケージのダウンロード・インストールをすることができます。

''pacman'' は [[C]] 言語で書かれており、パッケージングに {{man|1|bsdtar}} [[Wikipedia:ja:tar|tar]] フォーマットを使用します。

{{Tip|1={{Pkg|pacman}} パッケージには [[makepkg]] や {{man|8|vercmp}} などのツールが含まれています。[[#Pactree|pactree]] や [[checkupdates]] など、他の有用なツールは {{Pkg|pacman-contrib}} パッケージに含まれています ([https://gitlab.archlinux.org/pacman/pacman/commit/0c99eabd50752310f42ec808c8734a338122ec86 以前]は ''pacman'' パッケージに含まれていました)。ツールの一覧を見るには {{ic|pacman -Ql pacman pacman-contrib {{!}} grep -E 'bin/.+'}} を実行してください。}}

== 使い方 ==

pacman で何ができるかをちゃんと学びたい場合、{{man|8|pacman}} を参照してください。以下にあるのは pacman でできることのほんの一例です。

{{Tip|他の Linux ディストリビューションを使ったことがある場合、[[Pacman/比較表]]の記事が役に立つでしょう。}}

=== パッケージのインストール ===

パッケージとは、以下を含むアーカイブです:

* アプリケーションの (コンパイルされた) 全ファイル
* アプリケーションのメタデータ (アプリケーション名、バージョン、依存関係など)
* ''pacman'' によって使用されるインストールファイル及びディレクティブ

Arch のパッケージマネージャである ''pacman'' は、このようなパッケージをインストール、アップデート、そして削除することができます。プログラムを自分でコンパイルしてインストールする代わりにパッケージを使用することには、様々な利点があります:

* 簡単なアップデート: ''pacman'' は、アップデートが利用可能になるとすぐに既存のパッケージを更新します。
* 依存関係のチェック: ''pacman'' は依存関係を処理してくれます。あなたがすべきことは、インストールしたいプログラムを指定することだけです。''pacman'' はそのプログラムと一緒に他の必要なプログラムもインストールします。
* 綺麗にアンインストール: ''pacman'' は、パッケージに含まれる全ファイルのリストを保持します。これにより、パッケージを削除する際に意図せずファイルが残留することはありません。

{{Note|
* パッケージには、[[PKGBUILD#optdepends|任意の依存パッケージ]]が設定されていることがあります。必ずインストールする必要はありませんが、インストールすることで機能が追加されます。''pacman'' は、パッケージのインストール時に任意の依存パッケージのリストを表示しますが、そのリストは {{ic|pacman.log}} に残りません。[[#パッケージ・データベースに問い合わせる]] コマンドを使うことで、パッケージの任意の依存パッケージを見ることができます。
* 他のパッケージの (任意の) 依存パッケージとしてパッケージをインストールする場合 (つまり、そのパッケージ自体は必要としていない場合)、{{ic|--asdeps}} オプションを使用することを推奨します。詳しくは [[#インストール理由]] セクションを参照。
}}

{{Warning|1=Arch でパッケージのインストールをする際に、[[#パッケージのアップグレード|システムのアップグレード]]をせずにパッケージリストを更新することは避けてください (例えば、公式リポジトリで[[#インストール時にパッケージを取得できない|パッケージが見つからなくなった]]時など)。実際の場面でいうと、{{ic|pacman -Sy'''u''' ''パッケージ名''}} の代わりに {{ic|pacman -Sy ''パッケージ名''}} を実行しては'''いけない'''ということです。後者を実行すると依存関係に問題が発生する可能性があります。[[システムメンテナンス#部分的なアップグレードはサポートされていません]] や [https://bbs.archlinux.org/viewtopic.php?id=89328 BBS#89328] を参照。}}

==== 特定のパッケージのインストール ====

ひとつ、あるいは複数のパッケージを、依存パッケージも含めてインストールするには、以下のコマンドを実行してください:

# pacman -S ''パッケージ名1'' ''パッケージ名2'' ...

{{Tip|このコマンドは、パッケージを再インストールする際にも使えます。}}

正規表現を使ってパッケージをインストールするには ([https://bbs.archlinux.org/viewtopic.php?id=7179 このフォーラムスレッド] を参照):

# pacman -S $(pacman -Ssq ''パッケージのパターン'')

別々のリポジトリ (例: ''extra'' と ''extra-testing'') 内に同一のパッケージの複数のバージョンが存在していることがあります。この場合、パッケージ名の前にリポジトリ名を明示する必要があります。例えば ''extra'' リポジトリ内のバージョンをインストールするには:

# pacman -S extra/''パッケージ名''

名前に類似パターンが存在するパッケージをインストールしたい場合、波括弧を使ってパッケージ名を展開することができます。例えば:

# pacman -S plasma-{desktop,mediacenter,nm}

必要に応じて更に複雑なパターンを指定することもできます:

# pacman -S plasma-{workspace{,-wallpapers},pa}

===== 仮想パッケージ =====

仮想パッケージとは、それ自体は存在していないが、1つ以上のパッケージによって [[PKGBUILD#provides|provides (提供)]] 指定されている特殊なパッケージです。仮想パッケージが存在していることにより、あるパッケージの依存関係として複数の候補が存在している場合に、パッケージは特定のパッケージを依存関係として指定する必要がなくなります。仮想パッケージはその名前を使ってインストールすることはできません。仮想パッケージを ''provide (提供)'' するパッケージをインストールすると、その仮想パッケージがシステムにインストールされたことになります。例としては [[D-Bus#実装|dbus-units]] パッケージがあります。

{{Tip|複数の候補が存在する場合、候補のリストは、{{ic|pacman.conf}} 内に現れる[[リポジトリ]]の順番でソートされ、そして同一のリポジトリ内にも複数の候補が存在する場合はさらにアルファベット順にソートされます。}}

==== パッケージグループのインストール ====

[[パッケージグループ]]に属しているパッケージをすべて同時にインストールすることができます。例えば:

# pacman -S gnome

を実行すると {{Grp|gnome}} グループからインストールしたいパッケージを選択するように表示されます。

パッケージグループには大量のパッケージが含まれており、しばしばインストールしたいパッケージはそのうちの少しだけということがあるかもしれません。インストールするパッケージの番号を全て入力するという方法でもよいですが、以下のような構文を使うことで簡単にパッケージを選択することが可能です:

Enter a selection (default=all): 1-10 15

以上で1番から10番までと15番のパッケージがインストールされます。

Enter a selection (default=all): ^5-8 ^2

以上で5番から8番までと2番のパッケージ以外の全てのパッケージをインストールします。

どのパッケージが gnome グループに属しているか見るには:

$ pacman -Sg gnome

どのようなパッケージグループがあるかは https://www.archlinux.jp/groups/ を見て下さい。

{{Note|グループの中にインストール済みのパッケージがある場合でも、グループにあわせて再インストールされます。{{ic|--needed}} オプションを使うことで無視できます。}}

=== パッケージの削除 ===

依存パッケージをすべて残したままパッケージを削除するには:

# pacman -R ''パッケージ名''

削除したいパッケージと、そのパッケージだけが必要としている依存パッケージを一緒に削除するには:

# pacman -Rs ''パッケージ名''

{{Warning|グループ (例えば ''gnome'') を削除する場合、このコマンドはそのグループ内のパッケージのインストール理由を無視します。グループを指定した場合、そのグループ内のパッケージを分けて指定したかのように振る舞うからです。依存関係のインストール理由は依然として考慮されます。}}

上記のコマンドは、必要とされているパッケージを含んでいるグループを削除する際に、実行を拒否する場合があります。そのような場合は、以下を試してください:

# pacman -Rsu ''パッケージ名''

削除したいパッケージと、そのパッケージの依存パッケージ、さらに削除したいパッケージに依存しているパッケージを削除するには:

{{Warning|この操作は再帰的です。潜在的に必要とされているパッケージも削除してしまう可能性があるので、注意して使用しなければなりません。}}

# pacman -Rsc ''パッケージ名''

他のパッケージによって必要とされているパッケージを、必要としているパッケージを削除せずに削除するには:

{{Warning|以下の操作はシステムを破壊する可能性があり、使用は避けるべきです。[[システムメンテナンス#特定の pacman コマンドを避けてください]] を参照してください。}}

# pacman -Rdd ''パッケージ名''

''pacman'' は、特定のアプリケーションを削除する際に、重要な設定ファイルを削除せずに ''.pacsave'' 拡張子を付けてバックアップします。これらのバックアップファイルの作成を行わないようにするには、{{ic|-n}} オプションを付けてください:

# pacman -Rn ''パッケージ名''

{{Note|''pacman'' は、アプリケーション自身が作成した設定ファイルを削除しません (例えば、ホームディレクトリ内の "ドットファイル")。}}

=== パッケージのアップグレード ===

{{Warning|
* Arch ユーザーは、[[システムメンテナンス#システムのアップグレード]] セクションのガイダンスに従ってシステムを定期的にアップグレードすることが期待されます。以下のコマンドを闇雲に実行するべきではありません。
* Arch Linux は完全なシステムアップグレードのみをサポートしています。詳細は [[システムメンテナンス#部分的なアップグレードはサポートされていません]] と [[#パッケージのインストール]] を参照してください。
}}

''pacman'' はコマンド一つでシステム上の全パッケージをアップデートできます。この処理に掛かる時間は、システムがどれだけ新しいかによります。以下のコマンドは、リポジトリデータベースを同期し、''かつ''、システム内のパッケージをアップデートします (ただし、リポジトリに無い"ローカル"のパッケージを除く):

# pacman -Syu

=== パッケージ・データベースに問い合わせる ===

''pacman'' からローカルデータベースに問い合わせるときは {{ic|-Q}} フラグを、同期データベースに問い合わせるときは {{ic|-S}} フラグを、ファイルデータベースに問い合わせるときは {{ic|-F}} フラグを使います。それぞれのフラグのサブオプションについては {{ic|pacman -Q --help}}、{{ic|pacman -S --help}}、{{ic|pacman -F --help}} を見てください。

{{Note|最新の結果を得るには、問い合わせる前にファイルデータベースを同期してください:

# pacman -Fy
}}

{{Tip|{{ic|pacman-filesdb-refresh.timer}} ({{Pkg|pacman-contrib}} パッケージに含まれています) を[[有効化/起動]]することで、''pacman'' のファイルデータベースを週ごとに更新できます。}}

''pacman'' はデータベースからパッケージを検索することができます。パッケージ名と説明の両方を検索するには:

$ pacman -Ss ''検索ワード1'' ''検索ワード2'' ...

場合によっては、{{Ic|-s}} の組み込みの ERE (拡張正規表現) によって、余計な検索結果が大量に出てきてしまうことがあるでしょう。そのようなときは検索対象をパッケージ名だけに絞ってみてください:

$ pacman -Ss '^vim-'

既にインストール済みのパッケージから検索するには:

$ pacman -Qs ''検索ワード1'' ''検索ワード2'' ...

リモートパッケージからパッケージファイルの名前で検索するには:

$ pacman -F ''検索ワード1'' ''検索ワード2'' ...

パッケージ名を指定して詳細な情報を得るには (例: そのパッケージの依存関係など):

$ pacman -Si ''パッケージ名''

ローカルにインストールされているパッケージの詳細な情報を得るには:

$ pacman -Qi ''パッケージ名''

{{ic|-i}} フラグを2つ付けることで、バックファイルのリストとバックアップファイルの変更状態も同時に表示できます:

$ pacman -Qii ''パッケージ名''

あるパッケージによってインストールされたファイルの一覧を得るには:

$ pacman -Ql ''パッケージ名''

リモートパッケージによってインストールされるファイルのリストを得るには:

$ pacman -Fl ''パッケージ名''

あるパッケージによってインストールされたファイルが存在しているか確認するには:

$ pacman -Qk ''パッケージ名''

{{ic|k}} フラグを2つ付けると、より徹底したチェックが行われます。

データベースを検索して、あるファイルがどのパッケージに属しているかを調べるには:

$ pacman -Qo ''/パス/ファイル名''

あるファイルがどのリモートパッケージに属しているかデータベースに問い合わせるには:

$ pacman -F ''/パス/ファイル名''

他のパッケージに必要とされていないパッケージ (孤児) の一覧を得るには:

$ pacman -Qdt

明示的にインストールしたパッケージで、依存関係として必要とされていないパッケージを全て表示するには:

$ pacman -Qet

その他の例については [[pacman/ヒントとテクニック]] を参照してください。

高度な使い方をしたい場合、[[pkgfile]] をインストールしてください。これは、すべてのファイルとそれらと関連するパッケージを記録している個別のデータベースを使用します。

==== Pactree ====

{{Note|{{man|8|pactree}} は {{Pkg|pacman}} パッケージの一部ではなくなりました。代わりに、{{Pkg|pacman-contrib}} でインストールできます。}}

あるパッケージの依存関係ツリー (dependency tree、つまり、そのパッケージ'''が'''必要としているパッケージの木) を表示するには:

$ pactree ''パッケージ名''

あるパッケージの被依存ツリー (dependant tree、つまり、そのパッケージ'''を'''必要としているパッケージの木) を表示するには、逆フラグ {{ic|-r}} を ''pactree'' に渡てください。

==== データベースの構造 ====

''pacman'' データベースは通常、{{ic|/var/lib/pacman/sync}} にあります。{{ic|/etc/pacman.conf}} で指定された各リポジトリに対して、対応するデータベースファイルがこのディレクトリ内に存在します。データベースファイルは、パッケージごとに 1 つのディレクトリを含む gzip 圧縮された tar アーカイブです。たとえば、{{Pkg|which}} パッケージの場合は次のようになります:

{{hc|$ tree which-2.21-5|
which-2.21-5
{{!}}-- desc
}}

{{ic|desc}} ファイルには、パッケージの説明、依存関係、ファイルサイズ、MD5 ハッシュなどのメタデータが含まれています。

=== パッケージキャッシュの削除 ===

''pacman'' は、ダウンロードしたファイルを {{ic|/var/cache/pacman/pkg/}} に保存しますが、これらは古くなってもアンインストールされても自動的に削除されません。これにはいくつかの利点があります:

# パッケージを[[ダウングレード]]する際に、他の方法 ([[Arch Linux Archive]] など) によって以前のバージョンを入手する必要がない。
# アンインストールされたパッケージをキャッシュディレクトリから簡単に直接再インストールでき、リポジトリから新しくダウンロードする必要がない。

しかし、ディレクトリのサイズが大きくなりすぎないようにするために、定期的にキャッシュを手動でクリーンアップする必要があります。

{{Pkg|pacman-contrib}} パッケージで提供されている {{man|8|paccache}} スクリプトは、インストール済みパッケージとアンインストール済みパッケージのキャッシュ済みバージョンを、最も新しい3つを残して全て削除します (オプションを何も指定しなかった場合):

# paccache -r

{{ic|paccache.timer}} を[[有効化]]し[[起動]]すれば、週に1度、未使用のパッケージキャッシュを削除してくれます。{{ic|/etc/conf.d/pacman-contrib}} でこのサービスへの引数を設定することもできます。例えば、以下の2つの例で言えば、{{ic|1=PACCACHE_ARGS='-k1'}} や {{ic|1=PACCACHE_ARGS='-uk0'}} となります。

{{Tip|1=''pacman'' のトランザクションの度にこの操作を自動で実行する[[#フック|フック]]を作成することもできます。フックを導入する {{AUR|paccache-hook}} を[[インストール]]することもできます。[https://bbs.archlinux.org/viewtopic.php?pid=1694743#p1694743 フックの例]もあります。}}

何個の新しいバージョンのキャッシュを保持するかを指定することも可能です。最も新しいバージョン1つだけを保持するには:

# paccache -rk1

{{ic|-u}}/{{ic|--uninstalled}} スイッチを加えれば、アンインストールされたパッケージに対象を絞ることもできます。例えば、アンインストールされたパッケージのキャッシュを全て削除するには:

# paccache -ruk0

その他のオプションは {{ic|paccache -h}} を見てください。

また、''pacman'' にも、パッケージキャッシュと、{{ic|/etc/pacman.conf}} 設定ファイルにもはや存在しないリポジトリの残留データベースファイルをクリーンアップする組み込みコマンドが存在します。しかし、''pacman'' では、パッケージキャッシュのバージョンをいくつ残すか指定することができないため、''paccache'' のデフォルトオプションよりも強引です。

現在インストールされていないパッケージのキャッシュと、未使用の同期データベースをを全て削除するには:

# pacman -Sc

全てのキャッシュファイルを削除するには、{{ic|c}} スイッチを2度使用してください。これは最も強引なアプローチであり、キャッシュディレクトリには何も残りません:

# pacman -Scc

{{Warning|ディスクの空き容量がどうしても必要でない限り、インストール済みパッケージとアンインストール済みパッケージのキャッシュを全て削除することは避けるべきです。さもないと、パッケージをダウングレードしたり再インストールしたりするためにファイルを再ダウンロードしなければならなくなってしまいます。}}

さらに、キャッシュをクリーンアップするツールとして {{AUR|pkgcacheclean}} と {{AUR|pacleaner}} もあります。

=== その他のコマンド ===

パッケージをダウンロードするが、インストールはしない:

# pacman -Sw ''パッケージ名''

リモートリポジトリ以外の'ローカル'のパッケージをインストールする (例えば、[[AUR]] のパッケージ):

# pacman -U ''/path/to/package/package_name-version.pkg.tar.zst''

ローカルパッケージのコピーを ''pacman'' のキャッシュに保持するには:

# pacman -U file:///''path/to/package/package_name-version.pkg.tar.zst''

(''pacman'' の設定ファイルに記述されているリポジトリ以外の) 'リモート'パッケージをインストールする:

# pacman -U ''<nowiki>http://www.example.com/repo/example.pkg.tar.zst</nowiki>''

==== ドライラン ====

''pacman'' は'''常に'''、インストールされるパッケージと削除されるパッケージを一覧表示して、操作を行う前にユーザに許可を求めます。

{{ic|--print}} (短いバージョンは {{ic|-p}}) を使用することで、{{ic|-S}}、{{ic|-U}}、{{ic|-R}} のアクションを行わずに、パッケージの一覧を処理可能な形式で表示できます。

{{ic|--print-format}} を追加すれば、このリストを様々な形にフォーマットできます。例えば、{{ic|--print-format %n}} は、パッケージのバージョン無しでパッケージの一覧を表示します。

=== インストール理由 ===

''pacman'' データベースでは、インストールしたパッケージはインストール理由によって2つのグループに分別されます:

*'''明示的にインストール''': ''pacman'' の {{ic|-S}} や {{ic|-U}} コマンドによって文字通り指定されたパッケージ。
*'''依存パッケージ''': ''pacman'' のインストールコマンドにパッケージの名前は指定されず、明示的にインストールした他のパッケージから[[PKGBUILD#依存関係|必要]]とされたためにインストールされたパッケージ。

パッケージのインストール時、以下のようにすることでインストール理由を''依存パッケージ''に強制的に変えることができます:

# pacman -S --asdeps ''パッケージ名''

明示的にインストールしたパッケージが、必須でない機能のための[[optdepends|任意の依存パッケージ]]を提供している場合があります。大抵、このコマンドはそのようなパッケージをインストールするために使用されます。

{{Tip|任意の依存パッケージを {{ic|--asdeps}} でインストールすると、[[pacman/ヒントとテクニック#使用していないパッケージ (孤立したパッケージ) の削除|孤立したパッケージを削除]]するときに ''pacman'' によって任意の依存パッケージも削除されるようになります。}}

パッケージの'''再'''インストールを行っても、デフォルトではインストール理由は変更されません。

明示的にインストールしたパッケージのリストは {{ic|pacman -Qe}} で表示でき、依存パッケージのリストは {{ic|pacman -Qd}} で表示できます。

既にインストールしたパッケージのインストール理由を変更したい場合、以下のコマンドを実行してください:

# pacman -D --asdeps ''パッケージ名''

Use {{ic|--asexplicit}} to do the opposite operation.

{{Note|{{ic|pacman -Syu ''パッケージ名'' --asdeps}} のように、アップグレードをするときに {{ic|--asdeps}} や {{ic|--asexplicit}} オプションを使用するのは推奨されません。インストールされるパッケージだけでなく、アップグレードされるパッケージのインストール理由まで変更されてしまうためです。}}

=== パッケージのインストール/アップグレード/アンインストール時に起こること ===

成功時のトランザクションは、5つのステップと、トランザクション前と後のフックで構成されます:

# データベースがロックされていない場合、トランザクションを初期化する。
# トランザクション中に追加/削除すべきパッケージを選択する。
# 同期データベース、パッケージ、及びパッケージ間の依存関係のサニティチェックを行い、コマンドラインフラグに基づいてトランザクションの準備をする。
# トランザクションを実行する:
## 必要に応じてパッケージをダウンロードする ({{ic|_alpm_sync_load}})。
## ''pacman'' の既存の {{ic|PreTransaction}} フックが適用される場合、それらのフックを実行する。
## 最終的に置き換えられるパッケージ、衝突するパッケージ、明示的に削除するように指定されたパッケージを削除する。
## 追加するべきパッケージが存在する場合、各パッケージに対して以下を実行する:
### パッケージにインストールスクリプトが存在する場合、そのスクリプトの {{ic|pre_install}} 関数を実行する (アップグレードする場合は {{ic|pre_upgrade}} が、削除される場合は {{ic|pre_remove}} が代わりに実行されます)。
### 以前のバージョンのパッケージのファイルを全て削除する (パッケージをアップグレードまたは削除する場合)。ただし、パッケージによって設定ファイルであると指定されたファイルに関しては、削除しない ([[pacman/Pacnew と Pacsave]] を参照)。
### パッケージを解凍し、含まれているファイルをファイルシステムに保存する (パッケージをインストールまたはアップグレードする場合)。新しいパッケージのファイルが、ファイルシステム上の手動で変更された設定ファイル (前のステップを参照) を上書きしてしまう場合、パッケージ側のファイルに別の名前 (''.pacnew'') を付けて保存する。
### パッケージにインストールスクリプトが存在する場合、{{ic|post_install}} 関数を実行する (アップグレードする場合は {{ic|post_upgrade}} が、削除される場合は {{ic|post_remove}} が代わりに実行されます)。
## トランザクションの終わりの時点で存在している {{ic|PostTransaction}} フックが適用される場合、それらのフックを実行する。
# トランザクション及びトランザクションリソース (つまり、データベースロック) を解放する。

== 設定 ==

''pacman'' の設定は {{ic|/etc/pacman.conf}} に記述します。ここで、pacman がどのように動作するかを設定することができます。この設定ファイルに関するより詳しい情報は {{man|5|pacman.conf}} にあります。

=== 全般設定 ===

全般的な設定は {{ic|[options]}} セクションにあります。ここで設定できる項目については {{man|5|pacman.conf}} を読むか、デフォルトの {{ic|pacman.conf}} ファイルを見てください。

==== アップデートする前にバージョンを比較 ====

利用可能なパッケージの新旧のバージョンを確認したい場合、{{ic|/etc/pacman.conf}} の "VerbosePkgLists" という行をアンコメントしてください。{{ic|pacman -Syu}} の出力が以下のようになります:

パッケージ (6) 古いバージョン新しいバージョン最終的な変化ダウンロード容量

extra/libmariadbclient 10.1.9-4 10.1.10-1 0.03 MiB 4.35 MiB
extra/libpng 1.6.19-1 1.6.20-1 0.00 MiB 0.23 MiB
extra/mariadb 10.1.9-4 10.1.10-1 0.26 MiB 13.80 MiB

==== 並列ダウンロード ====

並列 (すなわち同時) にダウンロードするパッケージの数は、{{ic|/etc/pacman.conf}} の {{ic|[options]}} セクション内の {{ic|ParallelDownloads}} オプションで設定できます。{{Pkg|pacman}} パッケージに同梱されている {{ic|/etc/pacman.conf}} では、このオプションはすでに {{ic|5}} に設定されています。このオプションが設定されていない場合、パッケージは1つずつダウンロードされます。

==== アップグレードさせないパッケージを設定 ====

{{Warning|[[部分的なアップグレード]]はサポートされていないので、パッケージのアップグレードをスキップする際は気をつけてください。。}}

システムを[[#パッケージのアップグレード|アップグレード]]する際に特定のパッケージをアップグレードしないようにするには、{{ic|[options]}} セクションに以下の行を追加してください:

IgnorePkg=linux

複数のパッケージを指定する場合は、スペースで区切るか、{{ic|IgnorePkg}} 行を追加してください。また、[[Wikipedia:ja:グロブ|グロブ]]パターンも使用できます。一度に限ってパッケージをアップグレードしないようにするには、コマンドラインで {{ic|--ignore}} オプションを使用してください (複数のパッケージを指定する場合は、コンマで区切ってください)。

{{ic|pacman -S}} を使えば、依然として対象のパッケージをアップグレードすることが可能です。この場合、''pacman'' はパッケージが {{ic|IgnorePkg}} 文に含まれていることを知らせてくれます。

==== アップグレードさせないパッケージグループを設定 ====

{{Warning|[[部分的なアップグレード]]はサポートされていないので、パッケージグループのアップグレードをスキップする際は気をつけてください。。}}

パッケージの場合と同様に、アップグレードさせないパッケージグループを指定することもできます:

IgnoreGroup=gnome

==== アップグレードさせないファイルを設定 ====

{{Ic|NoUpgrade}} ディレクティブで指定されたファイルは、パッケージのインストール/アップグレードの際に変更を加えられなくなり、代わりに新しいファイルは ''.pacnew'' 拡張子が付けられてインストールされます。

NoUpgrade=''path/to/file''

以下のようにして複数のファイルを指定することができます:

NoUpgrade=''path/to/file1 path/to/file2''

{{Note|パスはパッケージアーカイブ内のファイルを示します。なので、一番最初にスラッシュを置かないでください。}}

==== インストールさせないファイルを設定 ====

特定のディレクトリまたはファイルをインストールさせないようにするには、{{Ic|NoExtract}} リストにそのディレクトリを加えてください。例えば、bash の補完スクリプトをインストールしないようにするには:

NoExtract=usr/share/bash-completion/completions/*

後ろのルールは前のルールを上書きします。また、{{ic|!}} を前に付けることでルールを無効化できます。

==== 複数の設定ファイルを使用 ====

設定ファイルが複数あって (メインの設定と [[testing]] リポジトリを有効にした設定がある場合など)、設定ファイルのオプションを共有したい場合、設定ファイルで {{ic|Include}} オプションを宣言することができます。例:

Include = ''/path/to/common/settings''

{{ic|''/path/to/common/settings''}} は共有したいオプションが存在するファイルに置き換えてください。

==== フック ====

''pacman'' は {{ic|/usr/share/libalpm/hooks/}} ディレクトリ内に存在するフックをトランザクションの前後に実行することができます。その他のフックディレクトリを指定したい場合は、{{ic|pacman.conf}} 内で {{ic|HookDir}} オプションを使ってください (デフォルトは {{ic|/etc/pacman.d/hooks}} です)。フックファイルの名前には必ず ''.hook'' を後ろに付ける必要があります。''pacman'' フックはインタラクティブではありません。

''pacman'' フックは様々なことに使われています。例えば、{{ic|systemd-sysusers}} と {{ic|systemd-tmpfiles}} を組み合わせてパッケージのインストール時に自動的にシステムユーザーを作成します。例として {{AUR|tomcat8}} パッケージでは {{ic|tomcat8}} という名前のシステムユーザーが必要だと指定されており、特定のディレクトリの所有者がこのユーザーになるように設定されています。''pacman'' フックの {{ic|systemd-sysusers.hook}} と {{ic|systemd-tmpfiles.hook}} は、{{AUR|tomcat8}} にユーザが指定されているファイルと一時ファイルが存在していることを認識し、{{ic|systemd-sysusers}} と {{ic|systemd-tmpfiles}} を実行します。

alpm のフックに関する詳細は {{man|5|alpm-hooks}} を参照してください。

=== リポジトリとミラー ===

特殊な [[#全般設定|[options]]] セクションを除いて、{{ic|pacman.conf}} 内の他の {{ic|[セクション]}} には、使用するパッケージリポジトリを定義します。''リポジトリ''とはパッケージの''論理的な''集合であり、それらのパッケージは1つ以上のサーバに''物理的に''保存されています。このような理由から、各サーバはリポジトリの''ミラー''と呼ばれます。

リポジトリは[[公式リポジトリ|公式]]と[[非公式ユーザーリポジトリ|非公式]]に分けられています。設定ファイル内でのリポジトリの順番は重要です。2つのリポジトリに同じ名前のパッケージが存在する場合、それらのバージョン番号に関わらず、設定ファイル内で最初に来るリポジトリが、その後に来るリポジトリよりも優先されます。リポジトリを使用するには、そのリポジトリを追加した後に、まずシステム全体を[[#パッケージのアップグレード|アップグレード]]する必要があります。

各リポジトリセクションではミラーのリストを定義します: ミラーのリストを直接記述することもできますし、{{ic|Include}} ディレクティブを使って外部の専用のファイルを使うこともできます。例えば、公式リポジトリのミラーは {{ic|/etc/pacman.d/mirrorlist}} からインクルードされます。ミラーの設定については記事 [[ミラー]] を参照してください。

==== パッケージのキャッシュディレクトリ ====

Pacman は、ダウンロードしたパッケージファイルをキャッシュに保存します。キャッシュは、{{ic|pacman.conf}} の [[#全般設定|[options]]] セクション内の {{ic|CacheDir}} で示されるディレクトリ内です (設定されていない場合、{{ic|/var/cache/pacman/pkg/}} がデフォルトで使用されます)。

キャッシュディレクトリは、(たとえ、インストールされているパッケージの最新のバージョンのみを保持しているとしても) 時間とともに肥大化する場合があります。

キャッシュディレクトリを他のより好都合な場所に移動したい場合は、以下のどれかを行ってください:

* {{ic|pacman.conf}} 内の {{ic|CacheDir}} オプションで新しいディレクトリを設定する。末尾のスラッシュを残しておくことを忘れないでください。'''これが推奨される方法です'''。
* {{ic|/var/cache/pacman/pkg/}} に専用のパーティションや [[Btrfs#サブボリューム|Btrfs サブボリューム]]をマウントする。
* 選択したディレクトリを {{ic|/var/cache/pacman/pkg/}} でバインドマウントする。

{{Warning|{{ic|/var/cache/pacman/pkg/}} ディレクトリを他の場所への'''シンボリックリンクにしないでください'''。''pacman'' の誤動作の'''原因になります'''。特に、''pacman'' が自分自身をアップデートしようとしている場合です。}}
{{Warning|{{ic|CacheDir}}を/tmp以下に設定する事は、あなたが早さやディスクスペース,ストレージの寿命に敏感な場合にのみ推奨されます。}}

==== パッケージのセキュリティ ====

''pacman'' はパッケージの署名をサポートしていて、パッケージにセキュリティレイヤーを加えています。デフォルトの設定では {{ic|1=SigLevel = Required DatabaseOptional}} によって全てのリポジトリで全てのパッケージの署名検証が有効にされています。リポジトリ毎に {{ic|SigLevel}} を使うことでこの設定を上書きすることができます。パッケージに署名する方法や署名の検証について詳しくは、[[pacman-key]] を見てください。

==トラブルシューティング==

=== "Failed to commit transaction (conflicting files)" エラー ===

次のエラーが表示される場合: [https://bbs.archlinux.org/viewtopic.php?id=56373]

エラー: 処理を完了できませんでした (衝突しているファイル)
''package'': ''/path/to/file'' がファイルシステムに存在しています
エラーが発生したため、パッケージは更新されませんでした。

これは、''pacman'' がファイルの衝突を検出し、仕様によりファイルを上書きしないために発生します。これは仕様によるものであり、欠陥ではありません。

通常、この問題の解決法は自明です (とはいえ、なぜこれらのファイルがそこに存在しているのかを念の為に調べてみるべきでしょう)。まず、他のパッケージがそのファイルを所有していないか調べるのが安全です ({{ic|pacman -Qo ''/path/to/file''}})。そのファイルが他のパッケージによって所有されている場合、[[バグ報告ガイドライン|バグレポートを提出]]してください。そのファイルが他のパッケージのよって所有されていない場合、"ファイルシステムに存在している"方のファイルの名称を変更し、アップデートのコマンドを再度実行してください。問題がなければ、そのファイルは削除しても良いです。

何らかのプログラムを ''pacman'' を使用せずに (例えば {{ic|make install}} などで) 手動でインストールしている場合、プログラム自体とそのプログラムに属するファイルを全て削除しなければなりません。[[pacman/ヒントとテクニック#どのパッケージにも所有されていないファイルを特定する]] も参照してください。

インストールされたパッケージは、そのパッケージに関するメタデータを含む {{ic|/var/lib/pacman/local/''package-version''/files}} ファイルを提供します。このファイルが破損している、空である、または存在しない場合、パッケージの更新時に {{ic|file exists in filesystem}} エラーが発生します。そのようなエラーは通常、1つのパッケージだけが原因です。原因のパッケージに属するファイルの名前を変えて後で削除する代わりに、{{ic|pacman -S --overwrite ''glob'' ''package''}} を実行して {{ic|''glob''}} にマッチするファイルを上書きすることもできます。

{{Warning|通常、{{ic|--overwrite}} スイッチの使用は避けてください。[[システムメンテナンス#特定の pacman コマンドを避けてください]] を参照してください。}}

=== "Failed to commit transaction (invalid or corrupted package)" エラー ===

{{ic|/var/cache/pacman/pkg/}} から ''.part'' ファイル (部分的にダウンロードされたパッケージ) を探し、そのファイルを削除してください (これは、{{ic|pacman.conf}} でカスタムの {{ic|XferCommand}} を使用した場合に起こりやすいです):

# find /var/cache/pacman/pkg/ -iname "*.part" -delete

また、''archlinux-keyring'' が古く、''pacman'' が署名を検証できない場合にも、このエラーが発生することがあります。この問題を解決方法と防止方法は [[pacman/パッケージの署名#システムの定期的な更新]] を参照してください。

=== "Failed to init transaction (unable to lock database)" エラー ===

''pacman'' がパッケージデータベースを変更する際に (パッケージのインストール時など)、''pacman'' はロックファイル {{ic|/var/lib/pacman/db.lck}} を作成します。これにより、複数の ''pacman'' インスタンスが同時にパッケージデータベースを変更してしまうことを防ぎます。

''pacman'' がデータベースの変更中に中断されてしまった場合、古いロックファイルが残ってしまう可能性があります。''pacman'' インスタンスが実行中でないことが確実である場合は、ロックファイルを削除してください:

# rm /var/lib/pacman/db.lck

{{Tip|{{ic|fuser /var/lib/pacman/db.lck}} を root として実行すれば、ロックファイルを使用しているプロセスが存在するか調べることができます。}}

=== インストール時にパッケージを取得できない ===

具体的には次のようなエラーです: {{ic|Not found in sync db}}、{{ic|対象が見つかりませんでした}}、{{ic|ファイルの取得に失敗しました}}。

まず、パッケージが実際に存在することを確認してください。パッケージが存在することが確実であるならば、パッケージデータベースが古いのかもしれません。{{ic|pacman -Syu}} を実行して、パッケージデータベースを更新してシステムをアップグレードしてみてください。また、[[ミラー]]が最新であり、[[#リポジトリとミラー|リポジトリ]]が正しく設定されていることも確認してください。[[Reflector]] を使うことで、ミラーを最新に保つことができます。

''pacman'' が、更新すべきものがないと報告するにもかかわらず、{{ic|ファイルを取得するのに失敗しました}} というエラーが表示され続ける場合、{{ic|pacman -Syyu}} で[[ミラー#pacman にパッケージリストを更新させる|強制的にデータベースをダウンロード]]してみてください。これが通常の状況で必要になることは決してないため、[[ミラー#ミラーの動作不良|問題のミラーのステータスと一貫性]]を調査してください。

また、インストールしたいパッケージが含まれているリポジトリがシステムで有効化されていない可能性もあります。例えば、パッケージが [[multilib]] リポジトリにあるが、{{ic|pacman.conf}} で ''multilib'' が有効化されていない場合、このエラーが発生します。

[[FAQ#公式リポジトリにある共用ライブラリはそれぞれどうして一つのバージョンしか用意されてないんですか？]] も参照してください。

=== アップグレードの中断によって起動できなくなったシステムを修復する ===

{{Accuracy|これには複数の潜在的な問題があります。[[:en:Talk:pacman#More details in pacman crashes during an update]] を参照。}}

電源断やカーネルパニック、ハードウェア障害によって、アップデートが中断されてしまうことがあります。ほとんどの場合、システムが大きなダメージを負うことはありませんが、起動できなくなってしまうことはあります。

# [[USB インストールメディア]] を用意して、それを起動してください。
# ルートファイルシステムと [[ESP]] を[[マウント]]してください。
# マウントしたルートファイルシステムに {{ic|arch-chroot}} してください。
# 次に、アップデートを完全にやり直します。{{ic|/var/log/pacman.log}} を確認し、中断されたトランザクション中にアップグレードされていたパッケージ''全ての''リストを {{ic|pacman -Syu}} に渡してください。これで、もとのアップデートの戻しつつ、再インストールできるようになります。例:

# pacman -Syu $(grep "\[''2025-07-27T22.*''\] \[ALPM\] upgraded" /var/log/pacman.log | cut -d " " -f4 | tr "\n" " ")

アップグレードを''完全に''やり直すのは、適切なスクリプトレットとフックが実行されるようにするために必要だからです。

=== アップグレード中に pacman がクラッシュしてしまった ===

''pacman'' が "database write" (データベース書き込み) エラーが発生してクラッシュし、その後、パッケージのアンインストール/再インストール/アップグレードができなくなってしまった場合、以下を行ってください:

# Arch Linux の [[USB インストールメディア]]を起動してください。システム上の ''pacman'' と同じバージョンかより新しいものを使うために、最近のメディアを使うことが望ましいです。
# システムのルートファイルシステムをマウントしてください (例えば、{{ic|mount /dev/sdaX /mnt}} を root として実行してください)。そして、{{ic|df -h}} を実行してファイルシステムに十分な空き領域が存在することを確認してください。
# ファイルシステム proc、sys、dev もマウントしてください: {{ic|mount -t proc proc /mnt/proc; mount --rbind /sys /mnt/sys; mount --rbind /dev /mnt/dev}}
# システムにおいてデータベースの場所とディレクトリの場所がデフォルトである場合、{{ic|1=pacman --root=/mnt --cachedir=/mnt/var/cache/pacman/pkg -Syu}} を root として実行すればシステムの ''pacman'' データベースを更新してシステムをアップグレードすることができます。
#* アップデート/アップグレードができない場合、[[pacman/ヒントとテクニック#全てのパッケージの再インストール]] を参照してください。
# アップグレードしたら、アップグレードされていない壊れているパッケージがないかチェックしてください: {{ic|find /mnt/usr/lib -size 0}}
# そのようなパッケージが依然として存在する場合は、そのパッケージを再インストールしてください: {{ic|1=pacman --root /mnt --cachedir=/mnt/var/cache/pacman/pkg -S ''package''}}。

==== pacman: command not found ====

{{ic|/var/cache/pacman/pkg}} がシンボリックリンクである場合、''pacman'' は自己アップデート時に同じディレクトリを作成しようとするため、このシンボリックリンクは削除されます。これにより、アップデートが失敗します。その結果、{{ic|/usr/bin/pacman}} と {{Pkg|pacman}} パッケージに含まれる他のコンテンツが消えてしまいます (訳注: [[#パッケージのインストール/アップグレード/アンインストール時に起こること]] の 4.2 を参照)。

{{ic|/var/cache/pacman/pkg}} は ''pacman'' によって管理されているため、シンボリックリンクにしないでください。代わりに {{ic|CacheDir}} オプションを使うか、このディレクトリをバインドマウントしてください ([[#パッケージのキャッシュディレクトリ]] を参照)。

この問題が既に発生していて、システムが壊れてしまっている場合、''pacman'' パッケージに含まれる {{ic|/usr}} 内のコンテンツを手動で展開して ''pacman'' を復元し、その後、適切に ''pacman'' を再インストールしてください。詳細は {{Bug|73306}} や[https://bbs.archlinux.org/viewtopic.php?id=241213 関連するフォーラムのスレッド]を参照してください。

=== Pacman の手動再インストール ===

==== pacman-static を使う ====

{{AUR|pacman-static}} は ''pacman'' を静的にコンパイルしたものなので、システム上のライブラリが機能していなくても実行できます。これは、[[部分的なアップグレード]]によって ''pacman'' が実行できなくなってしまった場合にも便利です。

{{AUR|pacman-static}} パッケージのページにある固定コメントと PKGBUILD には、バイナリを直接ダウンロードする方法が記されています。''pacman'' を再インストールしたり、部分的なアップグレードが起こった際にシステム全体をアップグレードしたりする際にこの方法が使えます。

===== PKGBUILD のビルドが失敗したときにコンパイル済みの pacman-static バイナリを使う =====

場合によっては、システムがあまりに壊れていて ''makepkg'' を実行することも、{{AUR|pacman-static}} パッケージをビルドすることもできないようなこともあるかもしれません (ライブラリが無い、あるいは互換性が無いなど)。この場合、信頼できるソースから事前コンパイル済みの ''pacman-static'' バイナリをダウンロードすることができます。この静的バイナリは、システムのライブラリに依存せず、システム上の ''pacman'' を復元させることができます。

古いバージョンのバイナリは https://pkgbuild.com/~morganamilo/pacman-static/x86_64/bin/pacman-static で配布されています。

これをダウンロードし、[[実行可能属性|実行可能]]にしたうえで、以下を実行してください:

# ./pacman-static -Syu pacman

これにより、システムがアップデートされ、{{Pkg|pacman}} が再インストールされます。これにより、存在しない共有ライブラリに関連する依存関係の壊れが修正されます。

==== 外部の pacman を使う ====

''pacman-static'' でさえも動作しない場合は、外部の ''pacman'' を使用してリカバリできます。最も簡単な方法の一つは、[[archiso]] を使い、{{ic|--sysroot}} か {{ic|--root}} で、操作を行うシステム上のマウントポイントを指定することです。{{ic|--sysroot}} に必要なファイルシステムをマウントする方法については、[[Chroot#chroot を使う]] を参照してください。

==== 手動で抽出する ====

{{Warning|この方法では、一歩間違うとシステムの状態をさらに悪化させてしまいます。[[#アップグレード中に pacman がクラッシュしてしまった]] に書かれてある方法を使えない場合の最後の手段としてのみ、以下を行ってください。}}

''pacman'' がどうしようもなく破壊されたとしても、最新のパッケージを手動でダウンロードして適切な場所に展開することで修復が可能です。以下のような手順で行います:

# インストールすべき {{Pkg|pacman}} の依存関係を調べる。
# それぞれの依存パッケージを[[ミラー]]からダウンロードする。
# 各パッケージをルートディレクトリに展開する。
# {{ic|pacman -S --overwrite}} を実行してパッケージデータベースを更新することで、パッケージを再インストールする。
# システムの完全なアップグレードを行う。

正常に動作している Arch システムがあれば、以下のコマンドで ''pacman'' の依存関係リストを見ることができます:

$ pacman -Q $(pactree -u pacman)

しかし、発生している問題によっては、それらの依存パッケージのうち数個だけをアップデートすれば良い場合もあります。パッケージは以下のようにして展開します:

# tar -xvpwf ''package.tar.zst'' -C / --exclude .PKGINFO --exclude .INSTALL --exclude .MTREE --exclude .BUILDINFO

注意点として、{{ic|w}} フラグを使用してインタラクティブモードにしてください。非インタラクティブモードでは、重要なファイルが問答無用で上書きされてしまうかもしれないので、非常に危険です。また、パッケージを展開する順番には注意を払ってください (つまり、依存パッケージを先に展開してください)。[https://bbs.archlinux.org/viewtopic.php?id=95007 このフォーラムの投稿]には、''pacman'' のいくつかの依存関係だけが壊れてしまった場合のこの手順の例が書かれてあります。

=== 再起動後に "Unable to find root device" エラー ===

[[カーネル]]の更新中に [[initramfs]] が破損してしまった可能性が高いです (''pacman'' の {{ic|--overwrite}} オプションを不適切に使用すると、起こることがあります)。この状況から抜け出す方法は2つあります。1つ目は、''fallback'' エントリです。

{{Tip|''Fallback'' エントリを削除してしまった場合、ブートローダのパラメータを変えれば ''Fallback'' イメージを起動できます。ブートローダのメニューが表示されたときに、Syslinux の場合は {{ic|Tab}} を、GRUB と systemd-boot の場合は {{ic|e}} を押してエントリの編集画面を開き、''initramfs'' イメージ名を {{ic|initramfs-linux-fallback.img}} に変更して {{ic|Enter}} か {{ic|b}} (キーは[[ブートローダー]]に依ります) を押してください。}}

システムが起動したら、コンソールかターミナルから以下のコマンドを実行して initramfs イメージを再ビルドしてください (以下のコマンドは標準の {{Pkg|linux}} カーネルの場合です):

# mkinitcpio -p linux

これでうまく行かなかった場合、最新の Arch リリース (CD/DVD あるいは USB スティック) を起動し、ルートパーティションとブートパーティションをそれぞれ {{ic|/mnt}} と {{ic|/mnt/boot}} に[[マウント]]してください。そして、''arch-chroot'' を使ってルートパーティションに [[chroot]] してください:

# arch-chroot /mnt
# pacman -Syu mkinitcpio systemd linux

{{Note|
* 最新の Arch リリースを持っていない場合や、Arch 以外の "ライブ" Linux ディストリビューションしかない場合、昔ながらの方法で [[chroot]] することができます。当然、{{ic|arch-chroot}} スクリプトを実行する場合よりも、たくさん入力しなければなりません。
* ''pacman'' が {{ic|Could not resolve host}} というエラーで失敗してしまう場合、[[ネットワーク設定#接続の確認|インターネット接続を確認してください]]。
* パッケージを再インストールする必要があるが、arch-chroot や chroot の環境に入れない場合、コマンド {{ic|pacman --sysroot /mnt -Syu foo bar}} を使えば、別のルートパーティションから {{ic|pacman}} を使うことができます。
}}

カーネル ({{Pkg|linux}} パッケージ) を再インストールすれば、{{ic|mkinitcpio -p linux}} が実行されて initramfs イメージが再生成されます。イメージの再生成を別途行う必要はありません。

その後、{{ic|exit}}、{{ic|umount /mnt/{boot,} }}、そして {{ic|reboot}} を実行することが推奨されます。

=== "Warning: current locale is invalid; using default "C" locale" エラー ===

このエラーメッセージが言っている通り、ロケールが正しく設定されていません。[[ロケール]]の記事を参照してください。

=== ロケールが存在しないという警告メッセージ ===

{{Pkg|bleachbit}} や {{AUR|localepurge}} などのツールによってロケールファイルが意図的に削除される場合、パッケージの更新中に {{ic|pacman}} が、ロケールが存在しないという警告を表示する場合があります。

この警告を表示しないようにするには、{{ic|pacman.conf}} 内の {{ic|CheckSpace}} オプションをコメントアウトしてください。ただし、CheckSpace をオフにすると、パッケージのインストール時に空きスペースのチェック機能もオフになることに注意してください。なので、この回避策を取る場合は、他の方法でディスク領域を監視する必要があります。

=== pacman がプロキシの設定に従わない ===

関連する環境変数 ({{ic|$http_proxy}}、{{ic|$ftp_proxy}} など) が設定されていることを確認してください。''pacman'' を [[sudo]] で実行する場合、[[sudo#環境変数|環境変数を pacman に渡す]]ように sudo を設定する必要があります。また、[[GnuPG#鍵サーバー|dirmngr]] の設定ファイル {{ic|/etc/pacman.d/gnupg/dirmngr.conf}} で、鍵をリフレッシュする際にプロキシの設定に従うようにする {{ic|honor-http-proxy}} オプションが存在していることも確認してください。

=== パッケージが明示的にインストールされたか依存関係としてインストールされたかの情報を保持しつつ、全パッケージを再インストールするには? ===

ネイティブなパッケージ (つまり、同期データベース内に存在するパッケージ) を全て再インストールするには、{{ic|pacman -Qnq {{!}} pacman -S -}} か {{ic|pacman -S $(pacman -Qnq)}} を実行してください ({{ic|-S}} オプションはデフォルトでインストール理由を維持します)。

次に、外部のパッケージを全て再インストールする必要があります。これらのパッケージの一覧は {{ic|pacman -Qmq}} で得られます。

=== "Cannot open shared object file" エラー ===

どうやら、以前の ''pacman'' トランザクションで、''pacman'' 自体が必要とする共有ライブラリが削除されたか破損したようです。

この問題を解決するには、必要なライブラリをファイルシステム上に手動で展開する必要があります。まず、必要なライブラリを含むパッケージを調べ、''pacman'' キャッシュ ({{ic|/var/cache/pacman/pkg/}}) からそのパッケージを見つけてください。そして、その共有ライブラリをファイルシステム上へ展開してください。これで ''pacman'' が実行できるようになりました。

その後、壊れたパッケージを[[#特定のパッケージのインストール|再インストール]]する必要があります。注意点として、システムファイルがファイルシステム上に展開されたことを ''pacman'' は知らないため、{{ic|--overwrite}} フラグを使用する必要があります。Pacman は、先程の共有ライブラリファイルをパッケージのものに適切に置き換えてくれます。

やるべきことは以上です。あとはシステムの残りも更新してください。

===パッケージのダウンロード時にフリーズする===

''pacman'' がリポジトリのアップデートや同期をできないというネットワークの問題がいくつか報告されています [https://bbs.archlinux.org/viewtopic.php?id=68944] [https://bbs.archlinux.org/viewtopic.php?id=65728]。Arch Linux のインストール時にこの問題が発生する場合、''pacman'' のデフォルトのファイルダウンローダを置き換えることで解決します (詳しくは [[pacman のパフォーマンスの向上]]を参照)。[[VirtualBox]] で Arch Linux をゲスト OS としてインストールする時にこの問題が起こる場合、マシンのプロパティで ''NAT'' の代わりに ''Host interface'' を使うことで解決します。

=== Failed retrieving file 'core.db' from mirror ===

[[ミラー]]を正しく設定しているにも関わらずこのエラーが発生する場合、別の[[Resolv.conf|ネームサーバー]]を設定してみてください。

=== error: 'local-package.pkg.tar': permission denied ===

{{ic|pacman -U}} を使用して sshfs のマウントポイント上にパッケージをインストールしようとしてこのエラーが発生する場合、インストールしたいパッケージをローカルのディレクトリに移動し、もう一度インストールしてみてください。

=== error: could not determine cachedir mount point /var/cache/pacman/pkg ===

Chroot 環境内で {{ic|pacman -Syu}} などを実行した際に以下のエラーが発生する場合:

エラー: キャッシュディレクトリ /var/cache/pacman/pkg のマウントポイントを決定できませんでした
エラー: 処理を完了できませんでした (空き容量が足りません)

このエラーのよくある原因は、chroot したディレクトリがマウントポイントでないことです。解決策は、[[既存の Linux からインストール#基本ツールをダウンロード]] に書かれてあるノートを見てください。また、{{man|8|arch-chroot}} には、バインとマウントを使って chroot ディレクトリをマウントポイント化する方法について例と共に説明されています。

=== error: GPGME error: No data ===

パッケージを更新できず、このエラーが発生する場合は、更新する前に {{ic|rm -r /var/lib/pacman/sync/}} を実行してみてください。

Sync ファイルを削除しても問題が解決しない場合は、更新する前に {{ic|file /var/lib/pacman/sync/*}} を実行して sync ファイルが {{ic|gzip compressed data}} であることを確認してください。ルーターかプロキシが、ダウンロードしたデータを破損させているのかもしれません。破損は HTML タイプであるかもしれません。

Sync ファイルが正しい種類であった場合、ミラーサーバー側に問題があるのかもしれません。{{ic|pacman-conf -r core}} と {{ic|pacman-conf -r extra}} でミラーサーバーを確認してください。表示された URL の一番最初のものをブラウザの URL 欄にペーストし、ファイルの一覧が表示されるか確かめてください。ミラーがエラーを返した場合、{{ic|/etc/pacman.d/mirrorlist}} 内のそのミラーをコメントアウトしてください。[[ミラー]]を更新したり、再ランク付けしたりできます。

=== error: GPGME error: General error and ":: File /var/cache/pacman/pkg/<package>.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).===

このエラーが発生して、システムやパッケージを一切更新できない場合、{{ic|DISPLAY}} が空白に設定されているのかもしれません。これが空白に設定されていると、GPG-Flow は機能しなくなるようです。

上記の他の方法で問題が解決しなかった場合、{{ic|unset DISPLAY}} を実行するか、この変数を任意の値に設定することで、高い確率で再び更新できるようになります。詳細は[https://bbs.archlinux.org/viewtopic.php?pid=2204786 この投稿]を参照してください。

=== 壊れている、または同期されていないパッケージを再インストールする ===

{{ic|pacman -Qk $pkg}} コマンドを使えば、{{ic|$pkg}} パッケージのインストールされたファイルがデータベースのバージョンに含まれているファイルと一致するかどうかを確認することができます。複数のパッケージに対しては、以下のようなループを使うことで、存在しないファイルがあるパッケージを再インストールすることができます:

# LC_ALL=C.UTF-8 pacman -Qk 2>/dev/null | grep -v ' 0 missing files' | cut -d: -f1 |
while read -r package; do
pacman -S "$package" --noconfirm
done

(部分的なダウングレードなどにより) {{ic|/var/lib/pacman}} のローカルデータベースが {{ic|/}} ファイルシステムにインストールされているパッケージよりも新しい場合、これはルートファイルシステムをローカルデータベースと再同期させる最適な方法です。

== 参照 ==

* {{man|3|libalpm}}
* {{man|8|pacman}}
* {{man|5|pacman.conf}}
* {{man|8|repo-add}}

{{TranslationStatus|pacman|2026-03-15|866480}}

パフォーマンスの向上

2026-03-12T03:46:26Z

AshMyzk: 同期

[[Category:ハードウェア]]
[[Category:システム管理]]
[[en:Improving performance]]
[[es:Improving performance]]
[[fr:Improving performance]]
[[hu:Improving performance]]
[[pl:Improving performance]]
[[pt:Improving performance]]
[[ru:Improving performance]]
[[zh-hans:Improving performance]]
{{Related articles start}}
{{Related|パフォーマンスの向上/ブートプロセス}}
{{Related|Pacman ヒント#パフォーマンス}}
{{Related|OpenSSH#SSH の高速化}}
{{Related|OpenOffice#OpenOffice の高速化}}
{{Related|ノートパソコン}}
{{Related|Preload}}
{{Related articles end}}

この記事では、知覚または計測できるシステムパフォーマンスの向上を最終目的として、パフォーマンスに関連する基本的なシステム診断、及び、リソース消費量の削減やシステム最適化のための手順に関する情報を提供しています。ゲーミングおよび低レイテンシに特有のその他のアドバイスは [[ゲーム#パフォーマンスを向上させる]] も参照してください。

== 基本 ==

=== システムを知る ===

システムをチューンするには、全体のスピードを下げているボトルネックやサブシステムに狙いを定めるがベストな方法です。システムの仕様を知ることは、それらを特定することに役立ちます。

* (LibreOffice や Firefox などの) 巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の容量が十分であるか確認してください。以下のコマンドを使って、"available" 列の値を確認してください: {{bc|$ free -h}}
* 起動時間が長い場合、または、アプリケーションを初めて起動するとき (だけ) にロードに長い時間が掛かる場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには {{ic|hdparm}} コマンドを使うことができます: {{bc|# hdparm -t /dev/sd''X''}} {{Note|{{Pkg|hdparm}} で出力されるのはハードドライブの純粋な読み込み速度なので、有効なベンチマークとは言えませんが、平均的なコンピュータでは (アイドル状態のときに) 40MB/s より高い数値が出るのが妥当です。}}
* 十分な RAM が利用できる時でも CPU 負荷が一貫して高い場合、不要な[[デーモン]]やプロセスを無効化するなどして CPU 使用量を減らすことを試みてください。{{Pkg|htop}} や {{ic|pstree}} などの[[アプリケーション一覧/ユーティリティ#システム監視|システム監視ツール]]で CPU 負担をモニタすることができます: {{bc|$ htop}}
* ダイレクトレンダリングを使うアプリケーション (つまり、ビデオプレイヤ、ゲーム、[[ウィンドウマネージャ]]などの GPU を使うアプリケーション) が遅い場合、GPU パフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。{{ic|glxinfo}} コマンドを使うことで確認できます ({{Pkg|mesa-utils}} パッケージに含まれています)。次のコマンドを実行すると {{ic|direct rendering: Yes}} と表示される必要があります: {{bc|$ glxinfo {{!}} grep "direct rendering"}}
* [[デスクトップ環境]]を動かしている場合、(不要な) 視覚デスクトップ効果を無効化することで GPU 使用率を削減できる場合があります。現在使用しているものがハードウェアや個人の要件に合わない場合、より軽量な環境を使用するか、[[デスクトップ環境#カスタム環境|カスタムの環境]]を作成しましょう。
* 最適化された[[カーネル]]を使用することでパフォーマンスを向上できます。一般に {{Pkg|linux-zen}} が良い選択肢です。しかし、この記事の特定の部分で説明されているように、デフォルトのカーネルを調節することで良いパフォーマンスを得られます。

=== ベンチマーク ===

最適化の効果を判断できないことがたびたびあります。そういった場合は[[ベンチマーク]]ツールで計測することができます。

== ストレージデバイス ==

=== セクタサイズ ===

NVMe ドライブや Advanced Format ハードディスクが[[アドバンスドフォーマット|適切な論理セクタサイズ]]を使用していることを確認してください。

=== パーティショニング ===

パーティションが[[パーティショニング#パーティションアライメント|適切にアライメントされている]]ことを確認してください。

==== 複数のドライブ ====

複数のドライブを持っているのであれば、ソフトウェア [[RAID]] を組んでパフォーマンスを劇的に向上させることができます。

[[スワップ]]を別のディスク上に作成することでもパフォーマンスを多少向上させることができます。特に、スワップが頻繁に発生する場合です。

===== SSD を HDD のキャッシュとして使う =====

ハードディスクから移行することができない場合、ソリッドステートドライブをキャッシュレイヤとして使うことで読み書き速度を向上させ、ランダムアクセスによるパフォーマンスの低下を減らすことができます。方法としては、[[LVM#キャッシュ]]、[[Bcache]]、[[Bcachefs#SSD キャッシング]] があります。

==== HDD でのレイアウト ====

従来の回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター（ディスクの外周の近く）は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さく (15~20GiB、必要に応じて調節) して、できるだけドライブの最初に配置することが推奨されます。他のデータ（画像・動画など）は別のパーティションに置くべきです。通常、システム ({{ic|/}}) から home ディレクトリ ({{ic|/home}}) を分割することでこれを達成できます。

{{Note|このページのすべてのアドバイスにおいて言えることですが、得られる利益を計測してください: ハードドライブを[https://blog.stuffedcow.net/2019/09/hard-disk-geometry-microbenchmarking/#shortstroke ショートストローク]したり、合計容量の数％しか使わないようにしたりしない限り、一般的な使用においては読み書き操作が依然としてドライブ全体に及ぶため、パーティションを分割してもほんの数%しかアクセス時間は改善されません。それと比べて、SSD にアップグレードするとパフォーマンスが1桁以上向上します。}}

=== ファイルシステムの選択とチューニング ===

ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。[[ファイルシステム]]の記事に人気のあるファイルシステムの簡単な説明がされています。[[:カテゴリ:ファイルシステム]]から関連記事も見ることができます。

==== マウントオプション ====

様々な [[fstab#atime オプション|*atime]] オプションが、{{ic|strictatime}} のパフォーマンスのペナルティを軽減することができます。

他のマウントオプションはファイルシステム固有なので、ファイルシステムの関連記事を参照してください:

* [[Ext3]]
* [[Ext4#パフォーマンスの向上]]
* [[JFS#最適化]]
* [[XFS#パフォーマンス]]
* [[Btrfs#デフラグメンテーション]]、[[Btrfs#圧縮]]、{{man|5|btrfs}}
* [[ZFS#チューニング]]
* [[NTFS#パフォーマンスの向上]]

===カーネルパラメータの調整===

ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは [[sysctl#仮想メモリ]] を見て下さい。

=== I/O スケジューラの設定 ===

==== 背景情報 ====

入出力 ''(I/O)'' スケジューラはストレージデバイスにブロック I/O の操作を送信するときの順番を決めるカーネルコンポーネントです。I/O スケジューラの目的は読み込みリクエストを最適な方法で扱うことであるため、以下の2つのドライブの特徴を押さえておくことが重要です:

* HDD は回転ディスクでありヘッドが物理的に必要な場所に移動します。そのため、ランダムアクセスは 3〜12ms と非常に遅くなります (ハイエンドサーバーのドライブなのかノートパソコンのドライブなのか、あるいはディスクコントローラの書き込みバッファを迂回するかなどで速度は変わります)。逆に連続アクセスなら高いスループットを得ることが可能です。連続アクセスならヘッドはほとんど動かなくてよいためです。典型的な HDD は毎秒200回ほどの I/O リクエストを処理することができます ''(IOPS)''。

* SSD には物理的に移動する部品がありません。ランダムアクセスはシーケンシャルアクセスと同じ速度が出ます (0.1ms 未満)。SSD は複数のリクエストを一度にこなすこともできます。典型的な SSD のスループットは 10,000 IOPS を超えるため、大抵の場合は必要な仕事量を上回ります。

プロセスを大量に実行してストレージの様々な場所の I/O リクエストを発生させているとき (つまりランダムアクセスをしている状態)、数千の IOPS が生成されますが、普通の HDD では 200 IOPS までしか対応できません。ストレージにアクセスできるまで待機するリクエストの待ち行列が作られることになります。I/O スケジューラはこの待ち行列を最適化します。

==== スケジューリングアルゴリズム ====

スループットを改善する方法の一つとして、待機リクエストの順番を論理アドレスで並び替えてできるだけ一番近いリクエストを通すことで、アクセスをリニア化する方法があります。これが [[w:ja:エレベータアルゴリズム|elevator]] スケジューラと呼ばれる Linux の最初の I/O スケジューラでした。

エレベータアルゴリズムの問題点はシーケンシャルアクセスをするプロセスが上手く動かなくなることです。そのようなプロセスは、データブロックを読み取って数マイクロ秒で処理してから次のブロックを読み出します。エレベータスケジューラはプロセスが近くのブロックを呼びだそうとしていることを知らないため、他の場所のリクエストに移ってしまいます。[[w:Anticipatory_scheduling|anticipatory]] IO スケジューラはこの問題を解決します。このスケジューラは、他のリクエストを処理する前に、近くで別の読み取り操作が発生することを予測して、数ミリ秒待機します。

上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて [[w:Deadline_scheduler|deadline]] スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターアルゴリズムと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。

[[w:CFQ|Completely Fair Queuing (CFQ)]] は別のアプローチで問題に取り組みました。CFQ はプロセスの優先度に基づくキューを使ってタイムスライスと許容するリクエストの数を割り当てます。さらに [[cgroups]] のサポートを追加することで特定のプロセスグループに一定の IO を予約できるようにしました。これは共有・クラウドサーバーで特に役立ちます。ユーザーはリソースが必要なときに料金を払って IOPS を得られるのです。また、同期 I/O で近くの操作を待機するという ''anticipatory'' スケジューラの機能を改良して取り入れています。''anticipatory'' と ''elevator'' スケジューラは Linux カーネルから外され、下記のより高度な代替スケジューラに置き換えられました。

[https://docs.kernel.org/block/bfq-iosched.html Budget Fair Queuing (BFQ)] は CFQ のコードをベースにいくつか改善を加えています。各プロセスに固定長のタイムスライスを与えるかわりに、プロセスのセクタ数から計算した "budget" を割り当ててヒューリスティックを用います。BFQ は想定的に複雑なスケジューラであるため、オーバーヘッドが大きく、回転ドライブや低速 SSD に適しています。特に遅い CPU と組み合わせたときに高速なデバイスの足を引っ張ってしまうような場合に有用です。BFQ は個人用のシステムでインタラクティブな作業を行うときに、ストレージデバイスがまるで待機状態のときのように素早く反応することを目標としています。デフォルト設定ではスループットの最大化よりもレイテンシの最小化が優先されているのが特徴です。これにより、ハードドライブにおいて[https://www.phoronix.com/review/linux-50hdd-io/2 アプリケーションの起動を劇的に加速化]させられる場合があります。

[https://lwn.net/Articles/720675/ Kyber] はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。

==== カーネルの I/O スケジューラ ====

初期のアルゴリズムには既にメインラインから外されているものもあります。公式の Linux カーネルはいくつかの I/O スケジューラをサポートしています。[https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mechanism_(blk-mq) Multi-Queue Block I/O Queuing Mechanism (blk-mq)] は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。このフレームワークでは以下のスケジューラが使えます:

*''None''、キューイングアルゴリズムは適用されません。
*''mq-deadline'' は deadline スケジューラ (下記を参照) をマルチスレッドに対応させたスケジューラです。
*''Kyber''
*''BFQ''

==== I/O スケジューラの変更 ====

{{Note|スケジューラーの最適な選択は、デバイスとワークロードの正確な性質の両方によって異なります。また、MB/秒単位のスループットだけがパフォーマンスの指標ではありません。デッドラインや公平性は全体的なスループットを低下させますが、システムの応答性を向上させる可能性があります。 [[ベンチマーク]] は、各 I/O スケジューラのパフォーマンスを示すのに役立つ場合があります。}}

特定のデバイスで利用可能なスケジューラとアクティブなスケジューラを表示するには (アクティブなスケジューラは角括弧の中):

{{hc|$ cat /sys/block/'''''sda'''''/queue/scheduler|
mq-deadline kyber [bfq] none
}}

全デバイスで利用可能なスケジューラを表示するには:

{{hc|$ grep "" /sys/block/'''*'''/queue/scheduler|
/sys/block/pktcdvd0/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none
}}

デバイス ''sda'' のアクティブな I/O スケジューラを ''bfq'' に変更するには:

# echo '''''bfq''''' > /sys/block/'''''sda'''''/queue/scheduler

I/O スケジューラの変更プロセスは、ディスクが回転式か否かに応じて自動化することができ、起動毎に永続化させることができます。例えば、以下の [[udev]] ルールは、回転ドライブに対しては ''bfq'' を、[[SSD]]/eMMC ドライブに対しては ''bfq'' を、[[NVMe]] に対しては ''none'' を設定します:

{{hc|/etc/udev/rules.d/60-ioschedulers.rules|<nowiki>
# HDD
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

# SSD
ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"

# NVMe SSD
ACTION=="add|change", KERNEL=="nvme[0-9]*", ENV{DEVTYPE}=="disk", ATTR{queue/scheduler}="none"
</nowiki>}}

再起動するか、強制的に[[udev#新しいルールをロードする|新しいルールをロード]]してください。

==== IO スケジューラの調整 ====

カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用います。
設定項目と説明は [https://docs.kernel.org/block/index.html カーネルドキュメント] で確認できます。

特定のデバイスで設定可能なパラメータを確認するには (以下の例では ''sdb'' は ''deadline'' を使用しています):

{{hc|$ ls /sys/block/'''''sdb'''''/queue/iosched|
fifo_batch front_merges read_expire write_expire writes_starved}}

レイテンシを犠牲に ''deadline'' のスループットを高めるには以下のコマンドで {{ic|fifo_batch}} を増やします:

{{bc|# echo ''32'' > /sys/block/'''''sdb'''''/queue/iosched/'''fifo_batch'''}}

=== 電源管理設定とライトキャッシュ ===

従来の回転ディスク (HDD) を使用する場合は、省電力機能を完全に無効にするか下げるかし、書き込みキャッシュが有効になっているかどうかを確認すると良いかもしれません。

[[Hdparm#電源管理の設定]] と [[Hdparm#ライトキャッシュ]] を参照してください。

後で、起動時にこれらを適用する [[Hdparm#udev ルールによる永続的な設定|udev ルール]] を作成することができます。

{{Tip|[[GNOME]] では、"ディスク" アプリケーションからこれらのパラメータのいくつかを設定でき、udev ルールは必要ありません。}}

{{Note|一部の機能はあなたのハードドライブではサポートされていないかもしれません。その場合、Hdparm が通知します。なので、この特定の機能の設定を無視してください。}}

=== ディスクの読み書きを減らす ===

遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。

{{Note|書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、'''毎日 10GB のデータ書き込みを行うと'''、'''8年間で寿命が尽きる'''とされます。この数字はもっと[https://kcall.co.uk/ssd/ 容量が大きい SSD] を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときは[https://web.archive.org/web/20161124030749/http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead この耐久実験]も参照してください。}}

==== ディスクの書き込みを表示する ====

{{Pkg|iotop}} パッケージはプログラムをディスクの書き込み数でソートして、どれくらいの頻度でどれだけディスクに書き込んでいるか表示します。詳しくは {{man|8|iotop}} を見てください。

==== ファイルを tmpfs に再配置する ====

ブラウザプロファイルなどのファイルを [[tmpfs]] ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます:

* ブラウザプロファイルを同期させる方法については [[Profile-sync-daemon]] を参照してください。特定のブラウザには注意が必要な場合があります。例えば [[Firefox Ramdisk]] を参照してください。
* 任意の指定されたフォルダを同期させる方法については [[Anything-sync-daemon]] を参照してください。
* tmpfs 内でパッケージをビルドすることでコンパイル時間を減らす方法については [[Makepkg#ビルド時間を短縮する]] を参照してください。

==== ファイルシステム ====

対応する[[ファイルシステム]]ページを参照して、パフォーマンス改善に関する指示があるか見てください。[[#ファイルシステムの選択とチューニング]] に挙げられているファイルシステムのリストも参照してください。

==== スワップ領域 ====

詳細は [[スワップ#パフォーマンス]] を見てください。

==== ライトバックの間隔とバッファサイズ ====

詳細は [[Sysctl#仮想メモリ]] を見てください。

==== コアダンプを無効化する ====

[[コアダンプ#自動的なコアダンプの無効化]] を見てください。

=== ionice によるストレージ I/O スケジューリング ===

バックアップなど多くのタスクにおいては、そのタスクを実行するために、ストレージ I/O の遅延が短かったり、ストレージ I/O の帯域が大きかったりする必要はありません。そのようなタスクはバックグラウンドタスクに分類することができます。一方、デスクトップにおいて高速な I/O は UI の応答性を高める上で必須です。ゆえに、他のタスクがストレージ I/O を必要としている間は、バックグラウンドタスクによって利用できるストレージ帯域幅を減らすことが有益です。これは、プロセスごとに異なる優先度を設定できる Linux I/O スケジューラ BFQ を使用することで実現できます。

以下のようにバックグラウンドプロセスを実行することで、プロセスの I/O 優先度 "Idle" レベルまで落とすことができます:

$ ionice -c 3 ''command''

詳細は [https://www.cyberciti.biz/tips/linux-set-io-scheduling-class-priority.html a short introduction to ionice] や {{man|1|ionice}} を参照してください。

=== トリム ===

最適なパフォーマンスを得るには、SSD の空きブロックを定期的に discard (トリム) してランダム書き込みの速度を最適化するべきです。詳細は [[ソリッドステートドライブ#TRIM]] を参照してください。

== ネットワーク ==

=== 一般情報 ===

* カーネルネットワーキング: [[Sysctl#パフォーマンスを向上させる]] を参照
* NIC: [[ネットワーク設定#MTU とキューの長さの設定]] を参照
* DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。[[ドメイン名前解決#DNS サーバ]] を参照
* Samba: [[Samba#スループットを向上させる]] を参照

=== 規制範囲 ===

無線ネットワークサービスには国毎に異なる標準があります。たいてい、ネットワーク構成に応じて正しい範囲を設定すれば、シグナルをより強くできます。これはセットアップ時に設定することが一般的ですが、[https://community.frame.work/t/responded-amd-rz616-wifi-card-doesnt-work-with-6ghz-on-kernel-6-7/43226 設定が正しく適用されない]場合もあります。{{ic|/sys/module/cfg80211/parameters/ieee80211_regdom}} の内容を確認してください; 値が {{ic|00}} (グローバルな設定であることを示し、通常、制限がより強くなります) である場合や、間違った範囲に設定されている場合、以下の[[カーネルパラメータ]]を追加してみてください。ただし、{{ic|''XX''}} は正しい国コード (例: 日本の場合は {{ic|JP}} です):

cfg80211.ieee80211_regdom=''XX''

その後、一旦再起動してください。

=== 電源管理 ===

特定のデバイスには、使用中であるにもかかわらずネットワークアダプタが誤って省電力モードに入り、パフォーマンスが低下したり接続が切断されたりする問題があります。そのような場合、パッケージを[[アップグレード]]し、必要なファームウェアアップデートを受けられるようにしてください。そして、[[電源管理#ネットワークインターフェイス]] を見てください。

== CPU ==

=== オーバークロック ===

[[Wikipedia:ja:オーバークロック|オーバークロック]]は、CPU クロック周波数の上限を上げることにより、CPU の計算パフォーマンスを向上させます。オーバークロックできるかどうかは、CPU モデルとマザーボードモデルの組み合わせに依存します。オーバークロックは BIOS を介して行うのが最も一般的です。オーバークロックには欠点とリスクもあります。ここでは推奨も非推奨もしないでおきましょう。

Intel 製のチップの多くは acpi_cpufreq などや他のほとんどのユーティリティに正しいクロック周波数を伝えません。この結果、[[dmesg]] は極端なメッセージを表示します (これは、{{ic|acpi_cpufreq}} カーネルモジュールをアンロードしてブラックリスト化することで回避可能です)。クロック速度を読むには、{{AUR|i7z}} パッケージの ''i7z'' を使用してください。オーバークロックされた CPU が正しく動作していることを確認する方法として、[[ストレステスト]]が推奨されます。

=== 周波数スケーリング ===

[[CPU 周波数スケーリング]]を見てください。

=== CPU スケジューラ ===

メインライン Linux カーネルのデフォルトの CPU スケジューラは [https://lwn.net/Articles/925371/ EEVDF] です。

* {{App|[https://cchalpha.blogspot.com/2020/05/project-c-announcement.html Project C]|BMQ を Project C にリファクタリングするためのクロスプロジェクト。Project C コードベースに基づいて PSD を再作成します。よって、これは2つのプロジェクトのマージであり、その後 PDS が Project C として更新されます。より最近の開発として推奨されます。|https://cchalpha.blogspot.com/|{{AUR|linux-prjc}}}}
* {{App|BORE|BORE スケジューラは、対話型タスクにおいてある程度の公平性を犠牲にして低レイテンシを実現することに焦点を当てています。CFS の上に構築されており、vruntime コード更新だけに調整されています。なので、他の非公式 CPU スケジューラと比較して、全体的な変更は非常に小さいです。|https://github.com/firelzrd/bore-scheduler|{{AUR|linux-cachyos-bore}}}}
* {{App|SCX|システムをリセットせずに様々な CPU スケジューラを動的にロードできるようにします。|https://github.com/sched-ext/scx|{{Pkg|scx-scheds}}}}

=== リアルタイムカーネル ===

(TV チューナーカードをフル HD 解像度 (1080p) で実行するなど) 一部の使用用途では、[[リアルタイムカーネル]]を使うと利益を得られる場合があります。

=== プロセスの優先順位を設定 ===

{{man|1|nice}} と {{man|1|renice}} も参照してください。

==== Ananicy ====

[https://gitlab.com/ananicy-cpp/ananicy-cpp Ananicy CPP] は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、{{Pkg|ananicy-cpp}} や {{AUR|ananicy-cpp-git}} パッケージで利用可能です。nice レベルとは、CPU リソースを配分するときの実行可能ファイルの優先度を表すものです。

{{Warning|1=[[Gamemode]] と [https://gitlab.com/ananicy-cpp/ananicy-cpp Ananicy CPP] はどちらもプロセスの nice レベルを調整しようとします。これらのツールを組み合わせて使用することは推奨されていません。[https://github.com/CachyOS/ananicy-rules/blob/master/README.md#gamemode--ananicy-cpp--bad-idea]}}

==== cgroups ====

[[cgroups]] を見てください。

==== LimitCPU ====

[https://limitcpu.sourceforge.net/ LimitCPU] は特定のプロセスの CPU 使用率を制限するプログラムです。{{AUR|limitcpu}} をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:

$ limitcpu -l 50 -p 5081

=== irqbalance ===

{{Pkg|irqbalance}} はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。{{ic|irqbalance.service}} で[[systemd#ユニットを使う|操作]]することが可能です。

{{Warning|1=一部のケースでは、irqbalance が省電力機能に干渉し、ビデオゲームでのスタッタリングやフレームレート低下を引き起こす可能性があります。[https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1833322/comments/4]}}

=== CPU の脆弱性の緩和策をオフにする ===

{{Warning|1=以下の設定を使うときは問題の脆弱性について確認してください。特に、緩和策が無効化されている場合、'''信頼できないプログラムを隔離する方法として仮想マシンを使ってはなりません'''。詳しくは [https://phoronix.com/scan.php?page=news_item&px=Linux-Improve-CPU-Spec-Switches こちら] や [https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_CPUs こちら] のページを参照。}}

CPU の脆弱性の緩和策をオフにすることで、パフォーマンスが向上する場合があります。以下の[[カーネルパラメータ]]ですべての緩和策が無効になります:

mitigations=off

このパラメータによって切り替えられるすべてのスイッチについての説明は、[https://docs.kernel.org/admin-guide/kernel-parameters.html kernel.org] で見られます。{{AUR|spectre-meltdown-checker}} や {{man|1|lscpu}} ({{Pkg|util-linux}} に同梱) を使うことで、脆弱性チェックを行うことができます。

{{Note|1=第10世代およびそれ以降の Intel CPU、または AMD Ryzen シリーズ 1000 およびそれ以降の CPU を使用している場合、緩和策を無効化することにより得られるパフォーマンスの向上は、最大でも 5% にとどまります。一方、それ以前の世代の CPU では、最大 25% まで向上します。[https://www.phoronix.com/scan.php?page=article&item=3-years-specmelt 2021 初頭における総評]、[https://www.phoronix.com/scan.php?page=article&item=spectre-rocket-lake Rocket Lake におけるテスト]、[https://www.phoronix.com/scan.php?page=article&item=alder-lake-mitigations Alder Lake におけるテスト] を参照。}}

=== CPU に合わせてコンパイルをチューニングする ===

CPU によっては、ソフトウェアのコンパイル時に {{ic|1=-march=native}} フラグを使って、搭載されている CPU の[[Wikipedia:ja:マイクロアーキテクチャ|マイクロアーキテクチャ]]に合わせてソフトウェアのコンパイルをチューニングすると、パフォーマンスを少し向上できる場合があります。ただし、このフラグを使ってコンパイルしたバイナリは、他の CPU マイクロアーキテクチャ上では遅くなってしまうか、正しく動作しません。このオプションを使用していて、なおかつ CPU を変更あるいはアップグレードしたい場合は、バイナリを再コンパイルするか、新しい CPU には今の CPU と同じマイクロアーキテクチャのものを選ぶ必要があります。[[Makepkg#最適化|このオプションは makepkg でデフォルトとして設定することもできます]]。

[[カーネル#コンパイル|カーネルを自身でコンパイルする]]場合は、{{ic|CONFIG_X86_NATIVE_CPU}} オプションでカーネルのコンパイル中にこのフラグを有効化できます。しかし、通常のバイナリでパフォーマンス向上の寄与度が大きい拡張ベクトル命令を Linux カーネルは汎用のコード内で[https://github.com/torvalds/linux/blob/e5f0a698b34ed76002dc5cff3804a61c80233a7a/arch/x86/Makefile#L77 禁じている]ため、カーネルのパフォーマンス向上はより小さいでしょう。そのため、カーネルのパフォーマンス向上のほとんどは、[https://github.com/gcc-mirror/gcc/blob/ffa98429b93934be87f58bc3af481a69310aedaf/gcc/config/i386/x86-tune-costs.h より小さなマイクロ最適化]によるものになります。

== グラフィック ==

=== Xorg の設定 ===

グラフィックパフォーマンスは {{man|5|xorg.conf}} の設定に依存している場合があります。[[NVIDIA]]、[[AMDGPU]]、[[Intel]] の記事を参照してください。不適切な設定は Xorg が動作しなくなる原因になるため、注意しましょう。

=== Mesa の設定 ===

Mesa ドライバのパフォーマンスは [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ drirc] で設定できます。{{Pkg|adriconf}} (Advanced DRI Configurator) はオプションを設定して標準の drirc ファイルに書き込むことで MESA ドライバを設定する GUI ツールです。

=== ハードウェアビデオアクセラレーション ===

[[ハードウェアビデオアクセラレーション]]により、ビデオカードに動画のデコード/エンコードをさせることができます。

=== オーバークロック ===

CPU と同様に、(GPU の) オーバークロックは直接的にパフォーマンスを向上できますが、一般には推奨されません。いくつかのパッケージがあります: {{AUR|rovclock}} (ATI カード)、{{Pkg|rocm-smi-lib}} (最近の AMD カード)、{{AUR|nvclock}} (古い NVIDIA カード - Geforce 9 まで)、{{Pkg|nvidia-utils}} (最近の NVIDIA カード)。

[[AMDGPU#オーバークロック]] や [[NVIDIA/ヒントとテクニック#オーバークロックを有効化する]] を参照してください。

=== PCIe resizable BAR を有効化する ===

{{Note|
* 一部のシステムでは、PCIe resizable BAR を有効化するとパフォーマンスが大幅に劣化する可能性があります。システムのベンチマークを行って、PCI resizable BAR がパフォーマンスを向上させていることを確認してください。ただし、新しい Intel Arc の専用 GPU では、resizable BAR は Intel によって推奨されており、ほとんどの場合でパフォーマンスを向上させるでしょう。
* 効果を発揮させるには、[[Wikipedia:Unified Extensible Firmware Interface#CSM booting|Compatibility Support Module (CSM)]] を無効化しなければなりません。
}}

PCI の仕様では、PCI デバイスのメモリを PCI コントローラに公開するために、より大きい[[Wikipedia:PCI configuration space#Standardized registers|ベースアドレスレジスタ]] (BAR) を使用できます。そうすることで、ビデオカードのパフォーマンスを向上できる可能性があります。ビデオメモリ全体にアクセスすることでパフォーマンスを向上できますし、グラフィックドライバの最適化も可能になります。Resizable BAR、above 4G decoding、そしてドライバ最適化の組み合わせを、AMD は [https://www.amd.com/en/gaming/technologies/smart-technologies.html AMD Smart Access Memory] と呼んでおり、初期は AMD Series 500 チップセットマザーボードで利用できましたが、後に UEFI アップデートを通して AMD Series 400 と Intel Series 300 以降に拡張されました。この設定はすべてのマザーボードで利用できるわけではなく、特定のボードではブート問題を引き起こすことが知られています。

BAR のサイズが 256M の場合、この機能は有効化されていないか、サポートされていません:

{{hc|1=# journalctl -k --grep=BAR=|2=
[drm] Detected VRAM RAM=8176M, BAR=256M
}}

有効化するには、マザーボード設定で "Above 4G Decode" か ">4GB MMIO" という名前の設定を有効化してください。BAR が大きくなっていることを確認するには:

{{hc|1=# journalctl -k --grep=BAR=|2=
[drm] Detected VRAM RAM=8176M, BAR=8192M
}}

{{Note|NVIDIA GPU においては、ファームウェアで有効化されていたとしても、[[NVIDIA]] ドライバは Resizable BAR を自動的に有効化しません。UEFI で Above 4G Decoding と Resizable BAR を有効化することに加えて、Resizable BAR をドライバ側で明示的に有効化する必要があります:

{{hc|/etc/modprobe.d/nvidia-rebar.conf|2=
options nvidia NVreg_EnableResizableBar=1
}}

その後、[[initramfs を再生成]]してください。そうすることで、ブート時の早期段階で NVIDIA カーネルモジュールがロードされるときにこのオプションが適用されます。

PCIe Resizable BAR を完全に有効化するには、シャットダウンし、なおかつ一旦電源を切る必要があるかもしれません。
}}

Resizable BAR の状態は {{ic|lspci -vv}} で確認できます。GPU の BAR サイズが 256 MB よりも大きくなっているはずです (例は 16 GB VRAM を搭載した NVIDIA 4070Ti Super です):

{{hc|1=# lspci -vv -d ::03xx {{!}} grep BAR|2=
Capabilities: [bb0 v1] Physical Resizable BAR
BAR 0: current size: 16MB, supported: 16MB
BAR 1: current size: '''16GB''', supported: 64MB 128MB 256MB 512MB 1GB 2GB 4GB 8GB 16GB
BAR 3: current size: 32MB, supported: 32MB
}}

== RAM、スワップ、OOM 処理 ==

=== クロック周波数とタイミング ===

RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリのメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。[[#オーバークロック]]を参照。

=== RAM オーバーレイ上に root を置く ===

{{Out of date|liveroot スクリプトはメンテナンスされていないようです。しかし、このアプローチは依然として機能するはずです。}}

書き込みが遅いメディア (USB や回転 HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。{{AUR|liveroot}} を見て下さい。

=== zram 内のスワップや zswap ===

[[zswap]] や [[zram#スワップとしての使用|zram 内のスワップ]]を使うことで、似たような利点を (同じくらいのコストで) 得られます。これら2つは一般に意図が似ていますが、動作が異なります:

* zswap は、圧縮された RAM キャッシュとして動作し、ユーザ空間の設定をあまり必要としません (と同時に許可もしていません)。スワップデバイスと組み合わせて、スワップのキャッシュとして動作します。スワップに入りそうなページは、代わりに zswap に入る可能性があります。

* zram は、RAM 内に圧縮されたブロックデバイスを作成できるカーネルモジュールです。この圧縮されたブロックデバイスはスワップデバイスとして使用でき、他のスワップデバイスと組み合わせる必要はありません。多くの設定オプションがあり、例えばコールドページを保持しておくバッキングデバイスを使用するかどうかも指定できます。

両方とも[[スワップ]]サブシステムを呼び出すため、スワップに影響を与える設定はこれらのシステムにも影響を与えます。例えば、[[swappiness]] は、メモリが圧迫している状況で、カーネルがファイルキャッシュをドロップするか、ページをスワップに移動させるかのどちらを優先させるかを指定します。Zswap はページのスワップへの移動動作をインターセプトし、zram もスワップとして動作するため、このオプションはこれら2つのメカニズムがどれくらいの頻度で使用されるかにも影響を与えます。

=== グラフィックカードの RAM を使う ===

稀なケースとして、RAM 容量が非常に小さいが、ビデオ RAM に余りがある場合、後者をスワップとして使用できます。[[ビデオメモリにスワップ]] を参照してください。

=== メモリ不足の状況におけるシステムのレスポンスを改善する ===

従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の out-of-memory (OOM) killer がトリガーされるか、十分な量のメモリが開放される (システムが応答しない場合、メモリを大量消費するアプリケーションを閉じることは難しいため、これはすぐには起こり得ないでしょう) まで、システム全体のレスポンスがほぼ使用不能な状態まで低下します。挙動は特定の環境や条件に依存しており、通常のレスポンス状態に戻るまでには数秒から30分以上かかる場合があります。会議でのプレゼンテーションなどのような重要な状況においては、待つのが苦痛になるでしょう。

[https://lore.kernel.org/lkml/d9802b6a-949b-b327-c4a6-3dbca485ec20@gmx.com/T/ カーネル]と[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ Fedora] のメーリングリストで議論されている通り、メモリ不足の状況におけるカーネルとユーザ空間の挙動は将来的に改善されるかもしれませんが、ユーザは、システムのハードリセットや {{ic|vm.overcommit_*}} [[sysctl]] パラメータの調整よりも実行可能で効果的なオプションを使うことができます:

* [https://docs.kernel.org/admin-guide/sysrq.html Magic SysRq キー] ({{ic|Alt+SysRq+f}}) で手動でカーネルの OOM killer をトリガーする。
* ユーザ空間の OOM デーモンを使ってこれに自動的 (または対話的) に対処する。

{{Warning|OOM killer をトリガーして実行中のアプリケーションを kill すると、保存されていない作業が失われる場合があります。アプリケーションが最終的に通常通りメモリを開放してくれることを期待して辛抱強く待つか、あるいは応答がないシステムを可能な限り早く通常に戻したいと望むかは、あなた次第です。}}

カーネルの OOM killer では終了する (しない) プロセスに優先順位を付けられないので、SysRq よりも OOM デーモンのほうが好ましい場合もあります。いくつかの OOM デーモンをリストアップしました:

* {{App|systemd-oomd|[[systemd]] によって {{ic|systemd-oomd.service}} として提供されています。cgroups-v2 と pressure stall information (PSI) を使用してプロセスを監視し、カーネル空間で OOM が発生する前にアクションを取ります。|https://github.com/systemd/systemd, {{man|8|systemd-oomd}}|{{Pkg|systemd}}}}
* {{App|earlyoom|C で書かれた、シンプルなユーザ空間の OOM killer 実装です。|https://github.com/rfjakob/earlyoom|{{Pkg|earlyoom}}}}
* {{App|oomd|[https://lwn.net/Articles/759781/ PSI] ベースの OOM killer 実装です。Linux カーネルバージョン 4.20+ を必要とします。設定は JSON で行い、非常に複雑です。Facebook の本番環境において動作確認済み。|https://github.com/facebookincubator/oomd|{{AUR|oomd}}}}
* {{App|nohang|Python で書かれた、洗練された OOM ハンドラ。オプションで PSI サポートあり。earlyoom よりも設定可能です。|https://github.com/hakavlad/nohang|{{AUR|nohang-git}}}}
* {{App|low-memory-monitor|GNOME 開発者の取り組み。ユーザ空間のアプリケーションにメモリ不足の状態を伝えるためのより良いコミュニケーションを提供することを目的としており、さらにカーネルの OOM killer をトリガーするように設定することができます。PSI ベースで、Linux 5.2+ を必要とします。|https://gitlab.freedesktop.org/hadess/low-memory-monitor/|{{AUR|low-memory-monitor-git}}}}
* {{App|uresourced|アクティブなグラフィカルユーザセッションに対して、cgroup ベースのリソース保護を有効化する小さなデーモン。|https://gitlab.freedesktop.org/benzea/uresourced|{{AUR|uresourced}}}}
* {{App|bustd|非常に軽量な OOM killer。低速なマシンで便利です。PSI をベースとしており、Linux 4.2+ が必要です。|https://github.com/vrmiguel/bustd|{{AUR|bustd}}}}

== 参照 ==

* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Performance_Tuning_Guide/index.html Red Hat Performance Tuning Guide]
* [https://www.thomas-krenn.com/en/wiki/Linux_Performance_Measurements_using_vmstat Linux Performance Measurements using vmstat]

{{TranslationStatus|Improving performance|2026-03-12|864653}}

利用者・トーク:Kgx

2026-03-06T03:26:43Z

AshMyzk: 古いスレッドを削除

Wayland

2026-02-16T23:54:32Z

AshMyzk: 同期

[[Category:Wayland]]
[[de:Wayland]]
[[en:Wayland]]
[[es:Wayland]]
[[hu:Wayland]]
[[pt:Wayland]]
[[ru:Wayland]]
[[zh-hans:Wayland]]
{{Related articles start}}
{{Related|画像処理装置}}
{{Related|カーネルモード設定}}
{{Related|Xorg}}
{{Related|スクリーンショットの取得#Wayland}}
{{Related articles end}}

[https://wayland.freedesktop.org/ Wayland] は、[[Wikipedia:Windowing system#Display server|ディスプレイサーバ]]プロトコルです。[[Xorg|X Window System]] の後継として広く確立されています[https://blogs.kde.org/2025/11/26/going-all-in-on-a-wayland-future/] [https://blogs.gnome.org/alatiera/2025/06/08/the-x11-session-removal/] [https://discourse.ubuntu.com/t/ubuntu-25-10-drops-support-for-gnome-on-xorg/62538] [https://pagure.io/fesco/issue/3408]。[[Wikipedia:Wayland (display server protocol)#Differences between Wayland and X|Wikipedia に Wayland と Xorg との比較]]があります。

Wayland プロトコルを使用するディスプレイサーバは、[[Wikipedia:ja:コンポジット型ウィンドウマネージャ|コンポジット型ウィンドウマネージャ]] としても機能するため、'''コンポジタ''' と呼ばれます。以下に[[#コンポジタ|Wayland コンポジタのリスト]]を示します。

ネイティブな X11 アプリケーションをシームレスに動かすための後方互換性として、[[#Xwayland|Xwayland]] を使うことができます。これは Wayland に X サーバを提供します。

== 要件 ==

Wayland というのは単なるプロトコルです。[[Xorg]] とは違い、インストールすべき共通の「ディスプレイサーバ」は存在しません。Wayland を使用するために必要になるのは、互換性のあるディスプレイドライバ (この章) とコンポジタ (次の章)、あるいは Wayland プロトコルを実装している[[デスクトップ環境]] (例: [[GNOME]]、[[Plasma]]) のみです。ほとんどの Wayland コンポジタは、[[カーネルモード設定]]を使用しているシステム上でのみ動作します。

[[画像処理装置|GPU ドライバ]]と Wayland コンポジタは、同一のバッファ API に対応している場合に互換性があります。主要な API は2つ存在します: [[Wikipedia:Generic Buffer Management|GBM]] と [https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API EGLStreams] です。

{| class="wikitable"
! バッファ API !! GPU ドライバーのサポート !! Wayland コンポジタのサポート
|-
| GBM || [[NVIDIA]] < 495* 以外の全てのドライバー || 全て
|-
| EGLStreams || [[NVIDIA]] || [[GNOME]]
|}

: * Nvidia ≥ 495 は EGLStreams と GBM の両方をサポートします。[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-495.44-Linux-Driver]

NVIDIA が GBM のサポートを導入して以来、NVIDIA ≥ 495 で多くのコンポジタ (Mutter と KWin を含む) がデフォルトで GBM を使用し始めました。GBM は一般的にベターでより幅広いサポートがあると考えられています。EGLStreams がサポートされていた理由は、NVIDIA GPU をプロプライエタリドライバで Wayland 下で使用する代替の方法を NVIDIA が提供しなかったからだけです。さらに、GBM が NVIDIA に導入された後、KWin は [https://invent.kde.org/plasma/kwin/-/merge_requests/1638 EGLStreams のサポートを打ち切りました]。

人気なデスクトップ環境/コンポジタと、NVIDIA によってまだサポートされている GPU を使用している場合、おそらくすでに GBM バックエンドを使用しています。確認するには、次を実行してください: {{ic|journalctl -b 0 --grep "renderer for"}}。GBM をバックエンドとして強制的に使用させるには、次の[[環境変数]]を設定してください:

GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia

== コンポジタ ==

'''スタック型'''、'''タイル型'''、'''ダイナミック型''' の違いについては、[[ウィンドウマネージャ#種類]] を参照してください。

=== スタック型 ===

* {{App|[[COSMIC]] コンポジタ|COSMIC デスクトップ環境のコンポジタ。|https://github.com/pop-os/cosmic-comp|{{Pkg|cosmic-comp}}}}
* {{App|hikari|FreeBSD で活発に開発されている [[cwm]] にインスパイアされた wlroots ベースのコンポジタ。Linux もサポートしています。|http://hikari.acmelabs.space/|{{AUR|hikari}}}}
* {{App|KDE [[w:KWin|KWin]]|[[KDE#Plasma の起動]] を参照。|https://userbase.kde.org/KWin|{{Pkg|kwin}}}}
* {{App|[[labwc]]|Openbox にインスパイアされた wlroots ベースのコンポジタ。|https://github.com/labwc/labwc|{{Pkg|labwc}}}}
* {{App|[[w:Mutter (software)|Mutter]]|[[GNOME#GNOME の起動]] を参照。|https://gitlab.gnome.org/GNOME/mutter|{{Pkg|mutter}}}}
* {{App|waybox|Openbox をモデルとした最小主義の Wayland コンポジタ。|https://github.com/wizbright/waybox|{{AUR|waybox}}}}
* {{App|wayfire|[[Compiz]] にインスパイアされた、wlroots ベースの 3D コンポジタ。|https://wayfire.org/|{{AUR|wayfire}}}}
* {{App|[[Weston]]|正しさ、信頼性、予測可能性、性能のために設計された Wayland コンポジタ。|https://gitlab.freedesktop.org/wayland/weston|{{Pkg|weston}}}}
* {{App|wio|Plan 9 のリオデスクトップのルックアンドフィールを複製することを目的とする wlroots ベースのコンポジタ。|https://gitlab.com/Rubo/wio|{{AUR|wio-wl}}}}
* {{App|wlmaker|[[Window Maker]] からインスパイアされた wlroots ベースのコンポジタ。|https://phkaeser.github.io/wlmaker/|{{AUR|wlmaker}}}}
* {{App|woodland|Wayland 用の wlroots ベースの、最小かつ軽量のウィンドウスタッキングコンポジタ。Wayfire と TinyWl にインスパイアされています。|https://github.com/DiogenesN/woodland|{{AUR|woodland}}}}

=== タイル型 ===

* {{App|[[Cagebreak]]|cage をベースに、[[ratpoison]] にインスパイアされています。|https://github.com/project-repo/cagebreak|{{AUR|cagebreak}}}}
* {{App|jay|Rust 製の Wayland コンポジタ。外観はデフォルトの i3 をベースとしています。Jay は、宣言型の TOML ファイルか、コンポジタにインジェクトされる共有ライブラリで設定できます。|https://github.com/mahkoh/jay|{{AUR|jay}}}}
* {{App|miracle-wm|Mir ベースの Wayland コンポジた。i3 や sway のスタイルですが、swayfs のように、これらよりも派手で機能に富んでいます。|https://github.com/miracle-wm-org/miracle-wm|{{AUR|miracle-wm}}}}
* {{App|[[niri]]|スクロール可能なタイル型 Wayland コンポジタ。|https://github.com/YaLTeR/niri/|{{Pkg|niri}}}}
* {{App|[[Qtile]]|Python で記述および設定されたフル機能のハッキング可能なタイリングウィンドウマネージャーと Wayland コンポジタ。|https://github.com/qtile/qtile|{{Pkg|qtile}}}}
* {{App|[[Sway]]|wlroots ベースの [[i3]] 互換 Wayland コンポジタ。|https://github.com/swaywm/sway|{{Pkg|sway}}}}
* {{App|SwayFx|魅力的な視覚効果機能を追加した [[Sway]]。|https://github.com/WillPower3309/swayfx|{{AUR|swayfx}}}}
* {{App|Velox|swc ベースのシンプルなウィンドウマネージャです。dwm と [[xmonad]] の影響を受けています。|https://github.com/michaelforney/velox|{{AUR|velox-git}}}}

=== ダイナミック型 ===

* {{App|[[cwc]]|wlroots ベースの [[awesome]] ライクな Wayland コンポジタ。|https://cudiph.github.io/cwc/apidoc/| {{AUR|cwc}}}}
* {{App|[[Mangowc]]|[[dwl]] ベースのコンポジタ。標準的な設定ファイル、オプションのスクロールレイアウト、素晴らしいデザイン構築可能。|https://github.com/DreamMaoMao/mangowc|{{AUR|mangowc}}}}
* {{App|[[dwl]]|wlroots ベースの [[dwm]] ライクな Wayland コンポジタ。|https://codeberg.org/dwl/dwl|{{AUR|dwl}}}}
* {{App|[[Hyprland]]|見た目を犠牲にしないダイナミックなタイリング Wayland コンポジタ。|https://hypr.land|{{Pkg|hyprland}}}}
* {{App|japokwm|wlroots ベースの、レイアウト作成を中心とした動的な Wayland タイリングコンポジタ。|https://github.com/werererer/japokwm|{{AUR|japokwm-git}}}}
* {{App|[[river]]|dwm と [[bspwm]] にインスパイアされた動的なタイル型 Wayland コンポジタ。|https://codeberg.org/river/river|{{Pkg|river}}}}
* {{App|pinnacle-comp|Smithay ベースの Wayland コンポジタ。AwesomeWM にインスパイアされています。Lua あるいは Rust で設定できます。|https://github.com/pinnacle-comp/pinnacle|{{AUR|pinnacle-comp}}}}

=== その他 ===

* {{App|Cage|キオスクのような単一のフルスクリーンアプリケーションを表示します。|https://www.hjdskes.nl/projects/cage/|{{Pkg|cage}}}}
* {{App|GNOME Kiosk|Mutter ベースのコンポジタ。特定の用途のみに使用する場合や、ウォールディスプレイや POS システムなどの単一アプリケーションの環境に最適です。|https://gitlab.gnome.org/GNOME/gnome-kiosk|{{AUR|gnome-kiosk}}}}
* {{App|phoc|モバイル端末のための wlroots ベースの小さなコンポジタ。|https://gitlab.gnome.org/World/Phosh/phoc|{{Pkg|phoc}}}}
* {{App|Wayback|Wayland のコンポーネントを使用する完全な X11 デスクトップ環境を実行することのできる、X11 互換レイヤ。試験的で、開発の初期段階にあります。|https://wayback.freedesktop.org/|{{AUR|wayback-x11}}}}

上記のいくつかは [[ディスプレイマネージャ]] をサポートする場合があります。
それらがどのように開始されるかを {{ic|/usr/share/wayland-sessions/''compositor''.desktop}} を見て確認してください。

== ディスプレイマネージャ ==

Wayland コンポジタの実行をサポートしている[[ディスプレイマネージャ]]は以下の表の通りです。

{| class="wikitable sortable"
! 名前
! 何で動作するか
! 説明
|-
| {{Pkg|emptty}}
| TTY
| TTY で動作するシンプルな CLI ディスプレイマネージャ。
|-
| [[GDM]]
| Wayland
| [[GNOME]] ディスプレイマネージャ。
|-
| [[greetd]]
| Wayland/Xorg/TTY
[[Greetd#Greeter]] を参照。
| 最小でありながら柔軟なログインデーモン。
|-
| {{Pkg|lemurs}}
| TTY
| Rust で書かれた TUI ディスプレイマネージャ。
|-
| {{AUR|lidm}}
| TTY
| C で書かれた、完全にカラフルでカスタマイズ可能な TUI ディスプレイマネージャ。
|-
| [[LightDM]]
| Xorg[https://github.com/canonical/lightdm/issues/267]
| 様々なデスクトップに対応したディスプレイマネージャ。
|-
| {{Pkg|ly}}
| TTY
| Zig で書かれた TUI ディスプレイマネージャ。
|-
| [[SDDM]]
| Wayland/Xorg
| QML ベースのディスプレイマネージャ。
|-
| {{AUR|tbsm}}
| TTY
| bash のみに依存するシンプルな CLI セッションランチャー。
|-
| [[uwsm]]
| TTY
| スタンドアローンなコンポジタのための、セッションと XDG autostart のマネージャ。
TUI メニューを提供しますが、他のディスプレイマネージャと共に使用することもできます。
|}

== Xwayland ==

{{man|1|Xwayland}} は、Wayland の下で実行される X サーバーで、Wayland サポートをまだ提供していないネイティブな [[X11]] アプリケーションに互換性を提供します。これを使用するには、{{Pkg|xorg-xwayland}} パッケージを[[インストール]]します。

Xwayland はコンポジタを介して開始されるため、あなたの使用しているコンポジタのドキュメントを読み、Xwayland との互換性についてや、Xwayland の起動方法に関する指示を確認しておく必要があります。

{{Note|
* セキュリティ: Xwayland は X サーバーであるため、 Wayland のセキュリティ機能はありません。
* パフォーマンス: ほとんどのケースで Xwayland は X11 と[https://openbenchmarking.org/result/2202053-NE-NVIDIARTX35 ほぼ同等のパフォーマンス]を発揮します。
* 互換性: Xwayland は X11 と完全な後方互換性があるわけではありません。一部のアプリケーションは Xwayland 下では正しく動作しない場合があります。}}

=== Wayback ===

[https://wayback.freedesktop.org/ Wayback] ({{AUR|wayback-x11}}、{{AUR|wayback-x11-git}}) は、Wayland のコンポネントを使用する完全な X11 デスクトプ環境を実行できるようにする、X11 互換レイヤです。最終的には従来の X.Org サーバを置き換えることを目的としており、X11 アプリケーションのメンテナンスコストを減少させます。

=== NVIDIA ドライバ ===

{{Note|バージョン 470 より前の Nvidia ドライバ(例: {{aur|nvidia-390xx-dkms}}) はハードウェア支援のある Xwayland をサポートしておらず、非 Wayland ネイティブなアプリケーションは Wayland セッションでのパフォーマンスが低下します。}}

なお、[[NVIDIA#DRM カーネルモード設定|DRM KMS]] を有効にする必要があります。また、お使いのディスプレイマネージャ(例: [[GDM#Wayland と独自の NVIDIA ドライバ|GDM]])の[https://download.nvidia.com/XFree86/Linux-x86_64/515.48.07/README/xwayland.html 公式ドキュメント]に記載されている情報も見てください。

=== Xwayland アプリケーションを検出する ===

アプリケーションが Xwayland 経由で実行されているかどうかを判断するには、{{pkg|xorg-xeyes}} を使用して、アプリケーションウィンドウ上でマウスポインタを移動するときに目が動いているかどうかで確認できます。

他の方法として、({{Pkg|xorg-xwininfo}} の) ''xwininfo'' をターミナルウィンドウで実行するというものがあります。Xwayland ウィンドウ上にマウスポインタをホバーすると、マウスポインタが + マークに変わります。ウィンドウをクリックすると、xwininfo は情報を表示して終了しますが、ネイティブな Wayland ウィンドウでは何も起こりません。{{ic|Ctrl+C}} を押すことで xwininfo を終了できます。

あるいは、''xlsclients'' ({{Pkg|xorg-xlsclients}} パッケージ) を使用することもできます。Xwayland で動作中のアプリケーションを全てリストアップするには、{{ic|xlsclients -l}} を実行してください。

あるいは、{{AUR|extramaus}} を実行して、アプリケーションのウィンドウ上でマウスポインタを動かすことでも確認できます。赤いマウスが動けば、アプリケーションは Xwayland で動いています。

{{Tip|KDE Plasma の場合は、[[KDE#KWin デバッグコンソール]] でウィンドウを調査できます。}}

== GUI ライブラリ ==

=== GTK ===

{{Pkg|gtk3}} と {{Pkg|gtk4}} パッケージは Wayland バックエンドが有効になっています。GTK ではデフォルトで Wayland バックエンドを使いますが、[[環境変数]]を設定することで Xwayland を使うように上書きできます: {{ic|1=GDK_BACKEND=x11}}。

テーマの問題は [[GTK#Wayland バックエンド]] を見てください。

=== Qt ===

[[Qt]] 5 で Wayland のサポートを有効化するには、{{Pkg|qt5-wayland}} パッケージをインストールしてください。これで、Qt 5 アプリケーションは Wayland セッション上では Wayland で動作するようになります。

必須ではないはずですが、明示的に Wayland プラグインを使って Qt 5 アプリケーションを動作させるには、[https://wiki.qt.io/QtWayland#How_do_I_use_QtWayland.3F] にあるように、{{ic|1=-platform wayland}} を使用するか、[[環境変数]] {{ic|1=QT_QPA_PLATFORM=wayland}} をセットして下さい。

一方、Wayland セッション上で [[X11]] を使用させるには、{{ic|1=QT_QPA_PLATFORM=xcb}} と設定してください。これは、システムの Qt の実装を使用しない一部のプロプライエタリアプリケーションで必要になる場合があります。
また、{{ic|1=QT_QPA_PLATFORM="wayland;xcb"}} を使用すると、Qt が Wayland を利用できない場合に、代わりに xcb (X11)プラグインを使用させることができます。[https://www.qt.io/blog/2018/05/29/whats-new-in-qt-5-11-for-the-wayland-platform-plugin]

[[sway]] などの一部のコンポジターでは、ネイティブに実行されている Qt アプリケーションの機能が不足している場合があります。たとえば、[https://keepassxc.org KeepassXC] はトレイに最小化できません。これは、アプリケーションを実行する前に {{Pkg|qt5ct}} をインストールし、{{ic|1=QT_QPA_PLATFORMTHEME=qt5ct}} を設定することで解決できます。

Qt WebEngine のバグ ([https://bugreports.qt.io/browse/QTBUG-113574 Incorrect sizing and bad text rendering with WebEngine using fractional scaling on Wayland]) のため、Qt WebEgine を使用するアプリケーション (例: [https://bugs.launchpad.net/calibre/+bug/2018658 Calibre]) では荒いフォントが表示される場合があります。
回避策は、{{ic|1=QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor}} [[環境変数]]を設定してアプリケーションを起動することです。
これにより、アプリケーションのウィンドウが分数スケーリングされなくなります。

=== Clutter ===

Clutter ツールキットには Wayland バックエンドがあり、Clutter を Wayland のクライアントとして動作させることが可能です。このバックエンドは {{AUR|clutter}} パッケージで有効になっています。

Clutter アプリを Wayland 上で動作させるには、環境変数 {{ic|1=CLUTTER_BACKEND=wayland}} を設定する必要があります。

=== SDL ===

[[SDL|SDL3]] では、コンポジタが [https://wayland.app/protocols/fifo-v1 fifo-v1 プロトコル]をサポートしている場合、デフォルトで Wayland が使用されます。[https://github.com/libsdl-org/SDL/blob/8c54961de02d8f62ed155925cb334efcaa2d1f95/src/video/wayland/SDL_waylandvideo.c#L536C9-L536C20] そうでない場合、順に X11 と Wayland が試行されます。環境変数 {{ic|1=SDL_VIDEO_DRIVER=x11}} あるいは {{ic|1=SDL_VIDEO_DRIVER=wayland}} を使用することで、どちらか一方を強制することができます (あるいは、より優先度の低い、SDL2 用の環境変数もあります。下記を参照)。[https://github.com/libsdl-org/SDL/blob/8c54961de02d8f62ed155925cb334efcaa2d1f95/docs/README-migration.md?plain=1#L802].

{{Pkg|sdl2-compat}} は、[https://github.com/libsdl-org/sdl2-compat/blob/8b85f95bbcc3411c78c1f2cbd62b23b7f96093c2/src/sdl2_compat.c#L504-L538 アプリケーション固有の例外]を除いて、上記の SDL3 と同じルールに従います。SDL2 自体に関しては (例: {{AUR|sdl2}})、{{ic|1=SDL_VIDEODRIVER=wayland}} を設定してください。

{{ic|1=SDL_VIDEODRIVER="wayland,x11"}} とすることにより、Wayland が利用できない場合に代わりに X11 ビデオドライバを使用するように SDL2 を設定できます [https://wiki.libsdl.org/SDL2/FAQUsingSDL]。ウィンドウ装飾を有効化するために {{Pkg|libdecor}} をインストールすると良いかもしれません (例えば、GNOME で)。

詳細は[https://wiki.libsdl.org/SDL3/README/wayland 公式のドキュメント]を参照してください。

=== GLFW ===

{{Pkg|glfw}} パッケージには Wayland に対するサポートがあります。{{ic|1=XDG_SESSION_TYPE}} が {{ic|1=wayland}} に設定されていて、かつアプリケーションの開発者が特定のバックエンドを使用するようにしていなければ、Wayland バックエンドが使用されます。

詳細は GLFW の[https://github.com/glfw/glfw/blob/3.4/src/platform.c#L87-L99 ソースコード]を参照してください。

=== GLEW ===

{{AUR|glew-wayland-git}} パッケージが GLEW ベースのアプリケーションで動かない場合、唯一の選択肢は Xwayland で {{Pkg|glew}} を使うことです。{{Bug|62713}} を参照してください。

=== EFL ===

Enlightenment には[https://www.enlightenment.org/about-wayland 完全な Wayland サポート]があります.

EFL ベースのアプリケーションを Wayland 上で動作させるには、{{ic|1=ELM_DISPLAY=wl}} を設定してください。

=== winit ===

Winit は [[Rust]] で書かれたウィンドウ管理ライブラリです。デフォルトでは Wayland が X11 より優先される仕様ですが、環境変数を設定することで Xwayland を使うように上書きすることができます:

* バージョン 0.29.2 より前の場合、{{ic|1=WINIT_UNIX_BACKEND=x11}} を設定してください。
* バージョン 0.29.2 以降の場合、{{ic|1=WAYLAND_DISPLAY}} を unset してください。そうすることで、強制的に {{ic|1=DISPLAY}} 変数を使用して X にフォールバックされます。[https://github.com/rust-windowing/winit/blob/baf10de95843f156b0fbad6b10c3137f1ebd4f1e/src/changelog/v0.29.md?plain=1#L134]

=== Electron ===

{{Note|[[KDE|Plasma]] では、一部の Electron アプリケーションがウィンドウに間違ったアイコン (デフォルトの Wayland アイコン) を使用することがあります (タスクバーには正しいアイコンが表示されます)。そのアプリケーションのデスクトップファイル名を強制する特殊なアプリケーション/ウィンドウルールを作成することで、解決できます。}}

Wayland サポートは、コマンドラインフラグか環境変数で有効化できます。

==== コマンドラインフラグ ====

{{Note|一部のパッケージは、Electron に対してフラグを渡さないため、そのアプリケーションの開発者が解決策を実装する必要があります。}}

Wayland で動作させるために必要なコマンドラインフラグは [[Chromium#ネイティブ Wayland サポート]] を見てください。ただし、Electron 38 以降、コマンドラインフラグ {{ic|1=--ozone-platform-hint=auto}} は機能しないことに注意してください。

これらのフラグを手動で渡すこともできますが、[[Electron#設定ファイル|Electron の設定ファイル]]でフラグを永続化したり、[[デスクトップエントリ#desktop ファイルの変更|~/.local/share/applications の .desktop ファイル]]内の {{ic|1=Exec=}} 行にフラグを追加することでフラグを渡したりもできます。

{{Accuracy|Old version of Electron needs {{ic|1=--enable-features=WebRTCPipeWireCapturer}} But what version is it enable by default? Also default behavior of Electron vendored by non-free software would be wrong.}}

Electron は、デフォルトで PipeWire による WebRTC スクリーンキャプチャを有効化しています。キャプチャは {{Pkg|xdg-desktop-portal}} をベースとしています。

トップバーが表示されない場合は、{{ic|1=--enable-features=WaylandWindowDecorations}} で解決できます。これは、例として [[GNOME]] で必要となります ([https://github.com/electron/electron/pull/29618 electron17] からサポートされています)。

==== 環境変数 ====

バージョン 28 から 37 の間の Electron を使用するアプリケーションは、[[環境変数]] {{ic|ELECTRON_OZONE_PLATFORM_HINT}} を {{ic|auto}} または {{ic|wayland}} に設定することで、Wayland モードを使用することができます。

コマンドラインのほうが、環境変数よりも優先されます。

=== Java ===

[[Java]] プラットフォームのオープンソース実装である OpenJDK は、まだ Wayland のネイティブサポートを備えていません。
OpenJDK に Wayland を実装することを目的としたプロジェクトである [https://openjdk.java.net/projects/wakefield/ Wakefield] が実用できるようになるまでは、Xwayland を代わりに使用できます。

[[Debian:Wayland#Java Programs (supported since OpenJDK 16?)]] を参照してください:

:OpenJDK 16から、JRE は (Wayland をサポートしている) GTK3 を動的にロードできるようになりました。この[https://stackoverflow.com/questions/39197208/java-gui-support-on-wayland 議論]によると、これがサポートされているかもしれません。
:{{ic|_JAVA_AWT_WM_NONREPARENTING}} [[環境変数]]を "1" に設定することで、アプリケーションが空白の画面で起動する不具合を修正することができます。

XWayland は機能的に Wayland と同等ではないので、Wakefield が実用的になるまでは、[https://wiki.openjdk.org/display/wakefield/Pure+Wayland+toolkit+prototype WLToolkit] で機能の差を埋めることができます。これは {{ic|1=-Dawt.toolkit.name=WLToolkit}} でアクティブ化できます。[https://blog.jetbrains.com/platform/2024/07/wayland-support-preview-in-2024-2/ JetBrains IDE] といった一部のプログラムはこれをサポートしています。

== ヒントとテクニック ==

=== 自動化 ===

* [https://github.com/ReimuNotMoe/ydotool ydotool] ({{Pkg|ydotool}}) - 汎用のコマンドラインツール (wayland 以外でも利用可能)。{{ic|ydotool.service}} [[ユーザーユニット]]を[[起動/有効化]]してください。{{man|8|ydotoold}}、{{man|1|ydotool}} を参照。
* [https://github.com/atx/wtype wtype] ({{Pkg|wtype}}) - Wayland 用 xdotool type。{{man|1|wtype}} を参照。
* [https://github.com/boppreh/keyboard keyboard] - Windows と Linux で動作する Python ライブラリ。実験的な OS X サポートあり。[https://github.com/boppreh/mouse mouse] ライブラリも参照。
* [https://git.sr.ht/~brocellous/wlrctl wlrctl] ({{AUR|wlrctl}}) - 雑多な wlroots 拡張のためのコマンドラインユーティリティ (foreign-toplevel-management、virtual-keyboard、virtual-pointer をサポート)。

=== キーボードやマウスキーのリマップ ===

[[入力リマップユーティリティ]] を見てください。

=== スクリーンキャスト ===

[[スクリーンキャプチャ#スクリーンキャスト]] と [[スクリーンキャプチャ#X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする]] を見てください。

=== アプリが閉じた後もクリップボードの内容を保持する ===

Wayland の設計思想上、クリップボードのデータはソースクライアントのメモリ内に保存されます。クライアントが閉じると、クリップボードのデータは失われます。{{Pkg|wl-clip-persist}} を使うことで、この問題を解決できます。これはバックグラウンドで動き、クリップボードのデータを読んで、ソースクライアントからは独立した自身のメモリに保存します。

=== Wayland コンポジタを systemd サービスとして自動的に起動する ===

{{Note|[[Universal Wayland Session Manager]] は、使用中のコンポジタの systemd ユニットを自動的に生成します。さらに、[[Universal Wayland Session Manager#アプリケーションと自動起動|グラフィカルアプリケーションを systemd と統合する]]際にも役立ちます。}}

ディスプレイマネージャーやシェルを使いたくなければ、Waylandコンポジタを[[systemd]] サービスを使って自動的に起動できます。{{ic|ExecStart}} 行を使いたいコンポジタに変えて下さい。以下は [[KDE Plasma]] の例です:

{{hc|/etc/systemd/system/wayland-compositor.service|2=
[Unit]
After=graphical.target systemd-user-sessions.service modprobe@drm.service
Conflicts=getty@tty1.service

[Service]
User=''username''
WorkingDirectory=~

PAMName=login
TTYPath=/dev/tty1
UnsetEnvironment=TERM

StandardOutput=journal
ExecStart=/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

[Install]
WantedBy=graphical.target
}}

=== wlroots ベースのコンポジタで他のレンダラーを使用する ===

wlroots ベースのコンポジタに対して {{ic|WLR_RENDERER}} [[環境変数]]を設定することで vulkan などといった他の [https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master/render wlroots レンダラー]を使用することができます。利用可能なレンダラーのリストは [https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/docs/env_vars.md wlroots のドキュメント]にあります。

== トラブルシューティング ==

=== 色補正 ===

[[バックライト#色補正]]を参照。

=== 動作が遅い、表示がおかしい、クラッシュする ===

Gnome-shell で X から Wayland に切り替えるとグラフィック表示に問題が発生することがあります。原因として Xorg ベースの gnome-shell 用に {{ic|1=CLUTTER_PAINT=disable-clipped-redraws:disable-culling}} が設定されている可能性があります。{{ic|/etc/environment}} や rc ファイルから該当箇所を削除してみてください。

=== リモートディスプレイ ===

* ([[sway]] で使用されている) {{Pkg|wlroots0.18}} と {{Pkg|wlroots0.19}} は、バージョン 0.10 より、{{Pkg|wayvnc}} による VNC バックエンドを提供しています。RDP バックエンドは削除されました [https://github.com/swaywm/wlroots/releases/tag/0.10.0]。
* {{pkg|mutter}} はコンパイル時にリモートデスクトップが有効化されています。詳細は [https://wiki.gnome.org/Projects/Mutter/RemoteDesktop] と {{Pkg|gnome-remote-desktop}} を見てください。
* {{pkg|krfb}} は {{pkg|kwin}} に VNC サーバを提供します。{{ic|krfb-virtualmonitor}} を使えば、他のデバイスを外部モニタとしてセットアップすることが可能です。
* 2013年に FreeRDP が Weston にマージされました。コンパイルフラグで有効化されています。{{Pkg|weston}} パッケージは、バージョン 6.0.0 より、FreeRDP が有効化されています。
* {{Pkg|waypipe}} は Wayland アプリケーションの透過プロキシです。[[SSH]] 上で動作するラッパーコマンドあり。
** 以下は、Plasma デスクトップでリモートの KDE kcalc を起動する例です:
::{{bc|1=$ waypipe ssh example.local env QT_QPA_PLATFORM=wayland QT_QPA_PLATFORMTHEME=KDE dbus-launch kcalc}}

=== ゲームやリモートデスクトップ、仮想マシンウィンドウでの入力捕捉 ===

Xorg と異なり、Wayland では入力デバイスを独占 (グラブ) することができません (例: [https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html キーボード]、[https://tronche.com/gui/x/xlib/input/XGrabPointer.html マウス])。キーボードショートカットやポインタデバイスをアプリケーションウィンドウに渡すのは Wayland コンポジタの役目となっています。

入力グラブが変わったことで以下のように既存のアプリケーションで問題が発生します:

* ホットキーや修飾キーがコンポジタによって認識されてしまい、リモートデスクトップや仮想マシンのウィンドウに送信されなくなります。
* マウスポインタがアプリケーションウィンドウに制限されなくなるため、仮想マシンやリモートデスクトップのウィンドウ内のマウスポインタの位置がホスト環境のマウスポインタとずれるようになります。

Wayland と Xwayland にプロトコル拡張を追加することで解決を図っていますが、Wayland コンポジタが拡張をサポートしている必要があり、ネイティブの Wayland クライアントの場合、ウィジェットツールキット (例: GTK, Qt) やアプリケーション自身が拡張に対応していなければなりません。Xorg アプリケーションの場合、Xwayland のサポートで十分であるため、アプリケーションやウィジェット・ツールキットに変更を加える必要はありません。

これらの拡張はすでに {{pkg|wayland-protocols}} に含まれており、{{pkg|xorg-xwayland}} によってサポートされています。

関連する拡張:

* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml Xwayland keyboard grabbing protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml Compositor shortcuts inhibit protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/relative-pointer/relative-pointer-unstable-v1.xml Relative pointer protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml Pointer constraints protocol]

サポートしている Wayland コンポジタ:

* Mutter, [[GNOME]] のコンポジタ ([https://bugzilla.gnome.org/show_bug.cgi?id=783342 リリース 3.28] 以降)。
* wlroots (Relative pointer protocols と Pointer constraints protocol に対応)
* Kwin
** [[KDE#Wayland で X11 のショートカットが衝突する]]
** [https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/keyboard_shortcuts_inhibit_v1_interface.cpp Keyboard shortcuts inhibit]

サポートしているウィジェットツールキット:

* GTK (リリース 3.22.18 以降)

=== GTK テーマが動かない ===

https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland を参照してください。

=== NVIDIA モジュールを読み込まないようにする ===

[[sway]] などの Wayland コンポジターを起動する前に {{ic|1=__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json}} を [[環境変数]] として追加します。

=== 拡大/サーフェススケーリング ===

スクリーンの拡大は、まだ解決していません。[https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/145 wp-surface-scale プロトコルを提供する]プルリクエストが2022年半ばにマージされました。

=== カーネル 6.11.2 以降、Wayland にラグ/スタッタリングが発生する (AMD) ===

将来のカーネルリリースでこの問題が修正されるまで、回避策は、カーネルのコマンドラインに {{ic|1=amdgpu.dcdebugmask=0x400}} を追加することです。

こちらを参照: https://community.frame.work/t/wayland-lag-stuttering-since-kernel-6-11-2/59422

=== 仮想デスクトップの切り替え時にゲームやアプリケーションが止まる ===

ワークスペースを変更した時や、{{ic|Alt+Tab}} を押した時に、ゲーム (あるいは他のグラフィカルアプリケーション) が止まる、変な状態になる、部分的に停止します。これには、VRR アプリケーションや VSync がオンのアプリケーションが含まれますが、それらに限りません。症状としては、ゲームのウィンドウがフォーカスされていないときにのみ、音声が部分的に途切れる、ゲームが進まなくなる、ping が高くなる、ネットワークが途切れるなどがあります。これは、VSync がオンのアプリケーションにのみ影響します。

It is possible some games can work around this issue by changing to a window, but some do not. This is extremely annoying in more complex games which require heavy usage of web browsing, documentation and 3rd party tools or if the gameplay is interrupted for some reason.

回避策としては、環境変数 {{ic|1=MESA_VK_WSI_PRESENT_MODE=immediate}} と {{ic|1=vk_xwayland_wait_ready=false}} の片方/両方を設定することです。しかし、これらの変数は VSync あるいは VRR の機能を破壊します。

== 参照 ==

* [https://wayland.freedesktop.org/docs/html/ Wayland オンラインドキュメント]
* [https://gitlab.freedesktop.org/wayland 公式リポジトリ]
* [[Fedora:How to debug Wayland problems]]
* [https://wearewaylandnow.com/ We are Wayland now!] - "Are we Wayland yet?" の更新されたバージョン
* [https://awesomeopensource.com/projects/wayland Awesome Wayland projects]
* [[カーソルテーマ]]
* [https://bbs.archlinux.org/viewtopic.php?id=107499 Arch Linux forum discussion]
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide#common-x11-apps-used-on-i3-with-wayland-alternatives i3 Migration Guide - Common X11 apps used on i3 with Wayland alternatives]
* [https://wayland.app/protocols/ Wayland Explorer - A better way to read Wayland documentation]
* [https://askubuntu.com/questions/1393618/how-can-i-tell-if-an-application-is-using-xwayland How can I tell if an application is using XWayland]

{{TranslationStatus|Wayland|2026-02-17|865727}}

Xorg

2026-02-15T05:34:27Z

AshMyzk: 同期

[[Category:X サーバー]]
[[de:X]]
[[es:Xorg]]
[[en:Xorg]]
[[fr:Xorg]]
[[hu:Xorg]]
[[lv:Xorg]]
[[pt:Xorg]]
[[ru:Xorg]]
[[uk:Xorg]]
[[zh-hans:Xorg]]
{{Related articles start}}
{{Related|自動起動}}
{{Related|カーソルテーマ}}
{{Related|デスクトップ環境}}
{{Related|ディスプレイマネージャ}}
{{Related|フォント設定}}
{{Related|ウィンドウマネージャ}}
{{Related|XDMCP}}
{{Related|xinit}}
{{Related|xrandr}}
{{Related articles end}}

[[Wikipedia:ja:X.Org Server|X.Org Server]] (一般的には単に '''X''' と呼ばれる)は、[[Wikipedia:ja:X Window System|X Window System]] ('''X11''') [[Wikipedia:Windowing system#Display server|ディスプレイサーバー]]の [[Wikipedia:ja:X.Org Foundation|X.Org Foundation]] 実装であり、Linux ユーザーの間で最も人気のあるディスプレイサーバーです。その普遍性により、GUI アプリケーションにとって Xorg は欠かせない存在となり、ほとんどのディストリビューションで広く採用されています。

Xorg の代替かつ後継については [[Wayland]] を参照してください。

== インストール ==

Xorg は {{Pkg|xorg-server}} パッケージで[[インストール]]できます。

また、設定作業などに必要なパッケージのいくつかが {{Grp|xorg-apps}} グループに入っており、それぞれ関連するセクションで説明しています。

{{Grp|xorg}} グループも利用できます。このグループには Xorg サーバのパッケージや {{Grp|xorg-apps}} のパッケージ、フォントが含まれています。

=== ドライバ ===

使用中のハードウェアを調べ、適切なドライバを見つけるには、[[画像処理装置#インストール]] を参照してください。

ハードウェア固有の DDX はレガシーとみなされています。[[カーネルモード設定]]を使用し、最近のハードウェアでうまく動作する汎用の {{man|4|modesetting}} DDX ドライバが {{Pkg|xorg-server}} に含まれています。modesetting DDX ドライバは 2D アクセラレーションに [https://www.freedesktop.org/wiki/Software/Glamor/ Glamor][https://gitlab.freedesktop.org/xorg/xserver/-/tree/server-21.1-branch/glamor] を使用し、これは OpenGL を必要とします。

他の DDX ドライバをインストールしたい場合、Xorg はインストール済みの DDX ドライバを自動的に検索してくれることを留意しておいてください:

* 使用しているハードウェアに合うドライバー（[[画像処理装置#インストール]] に記載）がインストールされていない場合、Xorg はまず最初に ''fbdev'' ({{pkg|xf86-video-fbdev}}) を検索します。
* ''fbdev'' が存在しなかった場合、次に汎用ドライバーである ''vesa'' ({{pkg|xf86-video-vesa}}) を検索します。''vesa'' はほとんどのチップセットで動作しますが 2D や 3D のアクセラレーションは含まれていません。
* ''vesa'' も見つからない場合、Xorg は {{man|4|modesetting}} DDX ドライバにフォールバックします。

== 起動 ==

{{man|1|Xorg}} コマンドを直接実行することは通常ありません。代わりに、[[ディスプレイマネージャ]] か [[xinit]] を用いて X サーバを起動します。

{{Tip| たいてい、X の機能を補完するために [[ウィンドウマネージャ]] や [[デスクトップ環境]] をインストールすることになるでしょう。}}

== 設定 ==

{{Note|Arch はデフォルトの設定ファイルを {{ic|/usr/share/X11/xorg.conf.d}} に配置しており、ほとんどの場合、追加の設定は必要ありません。}}

Xorg は初期設定に {{ic|xorg.conf}} という名前の設定ファイルと {{ic|.conf}} が末尾につくファイルを使います: これらのファイルが検索されるフォルダの完全なリストは {{man|5|xorg.conf}} で見られます(利用可能なすべてのオプションの詳細な説明付き)。

=== .conf ファイルを使う ===

{{ic|/etc/X11/xorg.conf.d/}} ディレクトリにはホスト固有の設定を保存します。あなたは自由に設定ファイルをそのディレクトリに追加することができますが、ファイル名には {{ic|.conf}} 拡張子がなければなりません。さらに、これらのファイルは ASCII 順で読み込まれます。これらのファイル名は {{ic|XX-}} (2桁の整数とハイフン)で始めるのが慣例です(例えば 10 は 20 よりも早く読み込まれます)。これらのファイルは X サーバーの起動時にパースされオリジナルの {{ic|xorg.conf}} 設定ファイルの一部として扱われます。設定が競合した場合は、一番最後のファイルが処理されることに注意してください。これにより、最も一般的な設定ファイルは名前順で一番最初にあるべきです。{{ic|xorg.conf}} ファイル内の設定エントリは一番最後に処理されます。

設定オプションの例は [[Fedora:Input device configuration#xorg.conf.d]] を見てください。

=== xorg.conf を使う ===

{{ic|/etc/X11/xorg.conf}} や {{ic|/etc/xorg.conf}} で Xorg を設定することもできます。{{ic|xorg.conf}} のスケルトンを生成するには

# Xorg :0 -configure

上のコマンドで {{ic|/root/}} に {{ic|xorg.conf.new}} ファイルが作られるはずです。これを {{ic|/etc/X11/xorg.conf}} にコピーして上書きすることができます。

{{Tip|既に X サーバーを動作させている場合は、別のディスプレイを使って下さい、例: {{ic|Xorg :2 -configure}}。}}

もしくは、あなたのビデオカードドライバに自動で Xorg を設定するツールが含まれているかもしれません。詳しくは、あなたの使っているビデオカードの記事 ([[NVIDIA]]) を見て下さい。

{{Note|設定ファイルは大文字・小文字を区別しません、また “_” は無視されます。(Option など) 設定ファイル内のほとんどの文字列も大文字・小文字・空白・“_” を区別しません。}}

== 入力デバイス ==

入力デバイスのドライバーについては、X サーバーはデフォルトで libinput ドライバー ({{Pkg|xf86-input-libinput}}) を使用しますが、{{Pkg|xf86-input-evdev}} と関連するドライバーも使用できます [https://www.archlinux.jp/news/xorg-server-1191-is-now-in-extra/]。

[[Udev]] があなたのハードウェアを検知し、{{ic|/usr/share/X11/xorg.conf.d/}} ディレクトリに入っているデフォルト設定ファイル {{ic|10-evdev.conf}} と {{ic|40-libinput.conf}} によって、evdev と [[libinput]] がほとんど全てのデバイスのホットプラグ・インプットドライバーとして動作します。[[Udev]] は {{Pkg|systemd}} によって提供されています。

X サーバーの起動後、ログファイルを確認することで、どちらのドライバーがデバイスによってホットプラグされているか確認できます (ログファイルの名前は違っているかもしれません):
$ grep -e "Using input driver " Xorg.0.log

evdev や libinput があなたの持っているデバイスをサポートしていないときは、必要なドライバーを {{Grp|xorg-drivers}} グループからインストールしてください。

ホットプラグの動作については[[#設定]]を見てください。

より詳細な手順については、[[libinput]] の記事や以下に述べる記事、より多くの例は [[Fedora:Input device configuration]] を見てください。

=== 入力の識別 ===

[[キーボード入力#Xorg でキーコードを確認する]] を見てください。

=== マウスのアクセラレーション ===

[[マウスのアクセラレーション]] を見てください。

=== 特殊なマウスボタン ===

[[全てのマウスボタンを動作させる]] を見てください。

=== タッチパッド ===

[[libinput]] または [[Synaptics タッチパッド]] を見てください。

=== タッチスクリーン ===

[[タッチスクリーン]] を見てください。

=== キーボードの設定 ===

[[Xorg でのキーボード設定]] を見てください。

== モニターの設定 ==

=== 手動設定 ===

{{Note|
* Xorg の新しいバージョンは自動設定されます。なので、手動設定は必要ないはずです。
* Xorg がモニタを検出できない場合や自動設定をしたくない場合、設定ファイルを使用することができます。これが必要になる一般的なケースとしては、モニタ無しで起動し、Xorg が自動的に起動するヘッドレスなシステムに[[仮想端末に自動ログイン|仮想コンソール]]や[[ディスプレイマネージャ]]を使用して[[xinit#ログイン時に X を自動起動|ログイン]]する場合です。
}}

ヘッドレスな環境においては、{{pkg|xf86-video-dummy}} ドライバが必須です; それを[[インストール]]し、例えば以下のような設定ファイルを作成してください:

{{hc|/etc/X11/xorg.conf.d/10-headless.conf|
Section "Monitor"
Identifier "dummy_monitor"
HorizSync 28.0-80.0
VertRefresh 48.0-75.0
Modeline "1920x1080" 172.80 1920 2040 2248 2576 1080 1081 1084 1118
EndSection

Section "Device"
Identifier "dummy_card"
VideoRam 256000
Driver "dummy"
EndSection

Section "Screen"
Identifier "dummy_screen"
Device "dummy_card"
Monitor "dummy_monitor"
SubSection "Display"
EndSubSection
EndSection
}}

=== マルチモニター ===

一般的な情報は[[マルチディスプレイ]]を見て下さい。

==== 複数のグラフィックカード ====

利用するドライバを正しく定めてグラフィックカードのバス ID を(10進数表記で)入力する必要があります。

{{bc|
Section "Device"
Identifier "Screen0"
Driver "intel"
BusID "PCI:0:2:0"
EndSection

Section "Device"
Identifier "Screen1"
Driver "nouveau"
BusID "PCI:1:0:0"
EndSection
}}

(16進数の) バス ID を取得するには:

{{hc|$ lspci -d ::03xx|
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04)
01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev a1)
}}

この場合、バス ID は {{ic|0:2:0}} と {{ic|1:0:0}} となります。

=== 画面サイズと DPI ===

[https://gitlab.freedesktop.org/xorg/xserver/-/commit/fff00df94d7ebd18a8e24537ec96073717375a3f 2009-01-30] 以降、Xorg はデフォルトで常に DPI を 96 に設定します。適切な DPI の自動検出を行うためにバージョン 21.1 で変更が加えられましたが、後に[https://gitlab.freedesktop.org/xorg/xserver/-/commit/35af1299e73483eaf93d913a960e1d1738bc7de6 元に戻されました]。

X サーバの DPI は {{ic|-dpi}} コマンドラインオプションで設定できます。

細かなディーテールが要求される場面(フォントレンダリングなど)では、正しい DPI を設定すると役に立つことがあります。以前は、メーカーは 96 DPI を標準として作成していました (10.3" モニターなら 800x600、13.2" モニターなら 1024x768)。最近では、画面の DPI は様々であり、縦横で等しくないこともあります。例えば、19" ワイドスクリーン LCD が 1440x900 なら DPI が 89x87 になります。

ディスプレイのサイズと DPI が正しく検出・計算されているか確認するには:

$ xdpyinfo | grep -B2 resolution

寸法がディスプレイサイズと一致しているかチェックしてください。

スクリーンの物理的な大きさがわかっているときは、Xorg の設定ファイルに入力することで正しい DPI が計算されます(実際の xrandr の出力に合わせて Identifier を調整してください):

{{bc|
Section "Monitor"
Identifier "DVI-D-0"
DisplaySize 286 179 # ミリメートル単位
EndSection
}}

フルの xorg.conf を作成'''しないで'''モニタの仕様の入力だけを行いたい場合は新しい設定ファイルを作成してください。例えば ({{ic|/etc/X11/xorg.conf.d/90-monitor.conf}}):

{{bc|
Section "Monitor"
Identifier "<default monitor>"
DisplaySize 286 179 # In millimeters
EndSection
}}

{{Note|プロプライエタリな NVIDIA ドライバを使用している場合、上記の変更を反映させるために、{{ic|Device}} か {{ic|Screen}} セクションに {{ic|Option "UseEdidDpi" "FALSE"}} を追加する必要がある場合があります。}}

スクリーンの横と縦の物理的な長さがわからないときは（最近は対角線の長さ（インチ数）しかわからないことも多い）、モニターの最大解像度（またはアスペクト比）と対角線の長さを使って縦と横の長さを計算できます。ピタゴラスの定理を使って最大解像度1280x800（もしくはアスペクト比16:10）、13.3インチのスクリーンの場合:

$ echo 'scale=5;sqrt(1280^2+800^2)' | bc # 1509.43698

このコマンドでピクセルの対角線の長さがわかり、この値を使うことで物理的な縦と横の長さを知ることができます (そしてそれをミリメートルに変換できます):

$ echo 'scale=5;(13.3/1509)*1280*25.4' | bc # 286.43072
$ echo 'scale=5;(13.3/1509)*800*25.4' | bc # 179.01920

{{Note|上記の計算はピクセルアスペクト比が1:1のモニターでは上手く行きますが、モニターによってはアスペクト比が潰されることがあります (例: 16:10 のアスペクト解像度が 16:9 のモニターに適用される)。その場合、画面の大きさを手動で計測する必要があります。}}

==== 手動で DPI を設定する ====

{{Note|DPI は自由に設定することができ、Qt や GTK を使用しているアプリケーションはそれにあわせてスケールしますが、スケールによる画像の乱れがビットマップを使用する GUI に現れないように DPI は '''96''' (100%、スケーリング無し)、'''120''' (25% 増分)、'''144''' (50% 増分)、'''168''' (75% 増分)、'''192''' (100% 増分) などに設定するのを推奨します。また、アイコンの最低 DPI は基本的に 96 になっているので、96 DPI 未満に設定しても GUI のグラフィックのサイズは小さくなりません。}}

RandR に対応しているドライバ (例えばオープンソースの ATI ドライバ) なら、次のコマンドで設定できます:

$ xrandr --dpi 144

{{Note|変更はすぐにはアプリケーションに適用されません。再起動する必要があります。}}

設定を永続的にするには [[自動起動#Xorg のスタートアップ]] を見て下さい。

===== プロプライエタリの NVIDIA ドライバー =====

{{ic|Device}} か {{ic|Screen}} セクション下にオプションを追加することで DPI を手動で設定できます:

Option "DPI" "96 x 96"

===== Manual DPI Setting Caveat =====

GTK はしばしば、オプションの [[X resource]] {{ic|Xft.dpi}} を通して Xorg サーバの DIP を上書きします。これがあなたの環境で起こっているかどうかを確認するには:

$ xrdb -query | grep dpi

GTK ライブラリのバージョン 3.16 以降、この変数が明示的に設定されていない場合、GTK はこの変数の値を 96 に設定します。GTK アプリがサーバの DPI に従うようにするには、{{ic|Xft.dpi}} の値をサーバのもとと同じに明示的に設定する必要があります。{{ic|Xft.dpi}} リソースは、一部のデスクトップ環境の個人設定で DIP を特定の値に強制的に設定する手段です。[[KDE]] と [[TDE]] がその例です。

=== Display Power Management ===

[[DPMS]] はコンピュータが使われていない時にモニターを省電力モードに移行させる技術です。一定時間後にモニタを自動で待機状態にすることができます。

== コンポジット ==

X の Composite 拡張によってウィンドウ階層のサブツリー全体がオフスクリーンバッファにレンダリングされます。アプリケーションはバッファの内容を取得できるようになります。オフスクリーンバッファは親のウィンドウに自動的にマージされるか、コンポジットマネージャと呼ばれる外部のプログラムによってマージされます。詳しくは次のページを見て下さい: [[Wikipedia:ja:コンポジット型ウィンドウマネージャ]]。

ウィンドウマネージャによっては、コンポジットマネージャをインストールしなくてもコンポジットが行われます (例: [[Compiz]]、[[Enlightenment]]、[[KWin]]、{{Pkg|marco}}、{{Pkg|metacity}}、{{Pkg|muffin}}、{{Pkg|mutter}}、[[Xfwm]])。そうでないウィンドウマネージャの場合、スタンドアロンのコンポジットマネージャを使用します。

=== コンポジットマネージャ一覧 ===

* {{App|[[Picom]]|影、高度なぼかし、フェード機能を搭載した軽量なコンポジタ。Compton からフォークされました。|https://github.com/yshui/picom|{{Pkg|picom}}}}
* {{App|[[Xcompmgr]]|X.org 向けのウィンドウ効果ができるコンポジットマネージャ。|https://gitlab.freedesktop.org/xorg/app/xcompmgr/|{{Pkg|xcompmgr}}}}
* {{App|fastcompmgr|高速さに重点をおいた X11 用の軽量コンポジタ。|https://github.com/tycho-kirchner/fastcompmgr|{{AUR|fastcompmgr}}}}
* {{App|[[Gamescope]]|Valve のマイクロコンポジタ。FSR アップスケーリングなどのゲーム志向の機能が搭載されています。steamos-compositor からフォークされました。|https://github.com/ValveSoftware/gamescope|{{Pkg|gamescope}}}}
* {{App|steamos-compositor-plus|Valve のコンポジタ。いくつかの調整と修正が加えられています。|https://github.com/chimeraos/steamos-compositor-plus|{{AUR|steamos-compositor-plus}}}}

==ヒントとテクニック==

=== 自動化 ===

このセクションでは、キーボード/マウスの入力やウィンドウ操作(移動、リサイズ、レイズなど)の自動化のためのユーティリティを挙げています。

{| class="wikitable"
! ツール !! パッケージ !! マニュアル !! [[Keysym]] インプット !! ウィンドウ 操作 !! 備考
|-
! xautomation
| {{Pkg|xautomation}} || {{man|1|xte}} || {{Yes}} || {{No}} || スクリーンスクレイピングツールも同梱。{{ic|F13}} などのシミュレート不可。
|-
! xdo
| {{Pkg|xdo}} || {{man|1|xdo}} || {{No}} || {{Yes}} || ウィンドウの基本的なアクションを行う小さな X ユーティリティ。
|-
! xdotool
| {{Pkg|xdotool}} || {{man|1|xdotool}} || {{Yes}} || {{Yes}} || [https://github.com/jordansissel/xdotool/issues バグが多く]、活発に開発されていない。例: CLI パースが壊れている[https://github.com/jordansissel/xdotool/issues/14#issuecomment-327968132][https://github.com/jordansissel/xdotool/issues/71]
|-
! xvkbd
| {{AUR|xvkbd}} || {{man|1|xvkbd|url=http://t-sato.in.coocan.jp/xvkbd/#option}} || {{Yes}} || {{No}} || Xorg のための仮想キーボード。文字を送るための {{ic|-text}} オプションもあり。
|-
! AutoKey
| {{AUR|autokey-qt}} {{AUR|autokey-gtk}} || [https://github.com/autokey/autokey#documentation ドキュメント] || {{Yes}} || {{Yes}} || 高レベルで強力なマクロとスクリプトユーティリティ。Qt と Gtk の両方のフロントエンドあり。
|}

[[クリップボード#ツール]] と [https://venam.nixers.net/blog/unix/2019/01/07/win-automation.html X 自動化ツールの概要] も参照してください。

=== ネストした X セッション　===
他のデスクトップ環境に入れ子になったセッションを起動するには:

$ /usr/bin/Xnest :1 -geometry 1024x768+0+0 -ac -name Windowmaker & wmaker -display :1

上記で現在の X セッションの中に 1024x768 のウィンドウの Window Maker セッションが起動します。

このためには {{Pkg|xorg-server-xnest}} パッケージをインストールする必要があります。

X セッションをネストする、よりモダンな方法は [[Xephyr]] です。

=== ウィンドウマネージャ無しでアプリケーションを起動する ===

[[xinit#ウィンドウマネージャを使わずにアプリケーションを起動]] を見てください。

===リモートで GUI プログラムを実行する===

次の記事を参照してください: [[OpenSSH#X11 フォワーディング]]

===必要に応じて入力ソースを有効化・無効化===

''xinput'' を使えば一時的に入力ソースを有効化・無効化することができるようになります。ThinkPad のように複数のマウスがあって、どちらか片方だけ使いたい時などに役立ちます。

{{Pkg|xorg-xinput}} パッケージを[[インストール]]してください。

無効化したいデバイスの ID を調べて下さい:

$ xinput

例えば Lenovo ThinkPad T500 では、出力は以下のようになります:

{{hc|$ xinput|<nowiki>
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=11 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=10 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=9 [slave keyboard (3)]
↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)]
</nowiki>}}

{{ic|xinput --disable ''device_id''}} (''device_id'' は無効化したいデバイスの ID) でデバイスを無効にします。次の例では　Synaptics Touchpad の ID 10 を無効にします:

$ xinput --disable 10

デバイスを有効にするには、次のコマンドを実行してください:

$ xinput --enable 10

もしくはデバイス名を使うこともできます。タッチパッドを無効化するコマンドは:

$ xinput --disable "SynPS/2 Synaptics TouchPad"

=== 入力ソースを永続的に無効化する ===

以下の設定スニペットを使用することで、特定の入力ソースを無効化できます:

{{hc|/etc/X11/xorg.conf.d/30-disable-''device''.conf|
Section "InputClass"
Identifier "disable-''device''"
Driver "''driver_name''"
MatchProduct "''device_name''"
Option "Ignore" "True"
EndSection
}}

{{ic|''device''}} は任意の名前です。{{ic|''driver_name''}} は入力ドライバの名前です (例: {{ic|libinput}})。{{ic|''device_name''}} は、適切なデバイスとマッチするように使用されるものです。正しいデバイスを指定する他の方法 ([[libinput]] の {{ic|MatchIsTouchscreen}} など) は、使用している入力ドライバのドキュメントを調べてください。この例では libinput を使用していますが、これはドライバに依存しない方法であり、対象のデバイスがドライバに伝達されないようにします。

=== ホットキーでアプリケーションを終了 ===

ホットキーでスクリプトを実行:

#!/bin/sh
windowFocus=$(xdotool getwindowfocus)
pid=$(xprop -id "$windowFocus" | grep PID)
kill -9 "$pid"

依存パッケージ: {{Pkg|xorg-xprop}}, {{Pkg|xdotool}}

[[#視覚的にアプリケーションを kill する]] も参照。

=== TTY へのアクセスをブロック ===

X から tty へのアクセスをブロックしたい場合、以下を {{ic|xorg.conf}} に追加してください:

{{bc|
Section "ServerFlags"
Option "DontVTSwitch" "True"
EndSection
}}

これは、信頼できないユーザによる、システムのコマンドラインへのアクセスを制限するのに役立ちます。

=== ユーザーが X を終了できないようにする ===

X が動作しているときにユーザーから kill されないようにしたい場合、以下を [[#設定|xorg.conf]] に追加してください:

{{bc|
Section "ServerFlags"
Option "DontZap" "True"
EndSection
}}

{{Note|{{ic|Ctrl+Alt+Backspace}} ショートカットは、直接 X サーバの kill をトリガーするものではなく、キーマップの {{ic|Terminate_Server}} アクションをトリガーします。通常、これはデフォルトで設定されていません。[[Xorg でのキーボード設定#Ctrl+Alt+Backspace で Xorg を終了する]] を見てください。}}

=== 視覚的にアプリケーションを kill する ===

アプリケーションが誤動作したり固まったりした場合、ターミナルから {{ic|kill}} や {{ic|killall}} を使うためにプロセス ID や名前を見つける代わりに、{{Pkg|xorg-xkill}} を使えばアプリケーションをクリックして X サーバとの接続を閉じることができます。多くの既存のアプリケーションは、X サーバとの接続が閉じるとアボートしますが、一部のアプリケーションは実行し続ける可能性があります。

=== Rootless Xorg ===

Xorg は root の代わりに標準的なユーザー権限で実行することができます (いわゆる "rootless" Xorg)。これは root で実行するよりもセキュリティ上重要な改善です。一部の人気な[[ディスプレイマネージャ]] (例: [https://github.com/canonical/lightdm/issues/18 LightDM] や [[XDM]]) はルートレス Xorg をサポートしていないことに注意してください。

Xorg がどのユーザーとして実行されているかは {{ic|1=ps -o user= -C Xorg}} で確認できます。

{{man|1|Xorg.wrap}}, {{man|8|systemd-logind}}, [[Systemd/ユーザー#systemd のユーザーサービスとしての Xorg|systemd のユーザーサービスとしての Xorg]], [[Fedora:Changes/XorgWithoutRootRights]] , {{Bug|41257}} も参照して下さい。

==== xinitrc の使用 ====

[[xinitrc]] を使ってルートレス Xorg を設定するには:

* {{ic|startx}} を直接実行し、{{ic|exec startx}} を使用しないでください。
* [[Xinit#xserverrc|.xserverrc]] を介して {{ic|$XDG_VTNR}} で logind から渡されたパーミッションの仮想コンソールを Xorg が使用することを確認してください。
* 特定のプロプライエタリなディスプレイドライバを使用している場合、[[Kernel Mode Setting|カーネルモードセッティング]]の[https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/xorg-wrapper.c#L222 自動検出]は失敗します。その場合は、{{ic|/etc/X11/Xwrapper.config}} で {{ic|1=needs_root_rights = no}} を設定する必要があります。

{{ic|exec }} 無しで {{ic|startx}} を直接実行すろと、xorg のクラッシュ時にシェルが開いたままになります。一部の画面ロックプログラムは xorg 内で実行されるため、(xorg クラッシュ時に) 実行中のユーザーへの完全なアクセスを得ることができてしまいます。

==== GDM の使用 ====

[[カーネルモード設定]]を使用する場合、[[GDM]] はデフォルトで root 権限なしに Xorg を実行します。

==== セッションログのリダイレクト ====

Xorg をルートレスモードで実行すると、Xorg のログは、{{ic|~/.local/share/xorg/Xorg.log}} に保存されます。しかし、Xorg セッションからの stdout と stderr の出力はこのログにリダイレクトされません。リダイレクトを再度有効にするには、Xorg を {{ic|-keeptty}} フラグで起動し、stdout と stderr の出力をファイルにリダイレクトします。

startx -- -keeptty >~/.xorg.log 2>&1

もしくは、{{ic|/etc/X11/xinit/xserverrc}} を {{ic|~/.xserverrc}} にコピーして、{{ic|-keeptty}} を追加します。[https://bbs.archlinux.org/viewtopic.php?pid=1446402#p1446402] を参照してください。

=== root として Xorg を実行 ===

上記の通り、rootless Xorg がデフォルトであるような状況が存在します。rootless Xorg がデフォルトである環境で Xorg を root として実行する必要がある場合、{{man|1|Xorg.wrap}} を設定して root を要求するようにできます。

{{Warning| Xorg を root として実行するとセキュリティ上の問題を引き起こします。さらなる議論については [[#Rootless Xorg]] を見てください。}}

{{hc|1=/etc/X11/Xwrapper.config|2=
needs_root_rights = yes
}}

=== Wayback ===

Wayback は、Wayland コンポーネントを使用しつつ完全な X11 デスクトップ環境 (及びウィンドウマネージャ) を実行できるようにする X11 互換レイヤです。AUR から {{AUR|wayback-x11}} パッケージでインストールできます。

=== 12to11 ===

12to11 は、Wayland にしか対応していないアプリケーションを X11 でシームレスに実行できるようにします。AUR から {{AUR|12to11-git}} パッケージでインストールできます。最高のパフォーマンスを得るには EGL レンダラーで実行してください:

$ RENDERER=egl 12to11

== トラブルシューティング ==

=== 一般 ===

何か問題が発生したらログを確認してください。ログは {{ic|/var/log/}} または (v1.16 からデフォルトのルートレス X の場合) {{ic|~/.local/share/xorg/}} の中に保存されています。[[GDM]] を使っている場合は [[systemd/ジャーナル|systemd のジャーナル]]をチェックしてください [https://bbs.archlinux.org/viewtopic.php?id=184639]。

ログファイルの名前は {{ic|Xorg.n.log}} という形式を取ります: {{ic|n}} はディスプレイ番号です。デフォルト設定のシングルユーザーマシンの場合は {{ic|Xorg.0.log}} を確認すれば良いですが、他の構成の場合は見るべきログは違うかもしれません。X サーバーのセッションが起動したときのタイムスタンプと X が起動するのに使われたコンソールを確認することで適切なログファイルを見分けられます。例:

{{hc|$ grep -e Log -e tty Xorg.0.log|2=
[ 40.623] (==) Log file: "/home/archuser/.local/share/xorg/Xorg.0.log", Time: Thu Aug 28 12:36:44 2014
[ 40.704] (--) controlling tty is VT number 1, auto-enabling KeepTty
}}

{{Tip|読みやすいタイムスタンプをログに追加するには、{{man|1|tail}} の出力を {{man|1|ts}} ({{Pkg|moreutils}} パッケージに含まれています) にパイプで繋ぐことができます。ただし、コマンドが実行されている時にログに追加された行にしか正しいタイムスタンプは追加されません。例:
$ tail -f ~/.local/share/xorg/Xorg.0.log {{!}} ts
}}

* ログファイルの中に {{ic|(EE)}} で始まる行が存在しないか確認してください。{{ic|(EE)}} はエラーです。また、{{ic|(WW)}} は警告です。
* {{ic|$HOME}} に存在する {{ic|.xinitrc}} ファイルが空の場合、X を起動するにはファイルを削除するか正しく編集する必要があります。空の場合、X は画面を表示せず {{ic|Xorg.0.log}} にエラーも出力されません。ファイルを削除するとデフォルトの X 環境が起動します。
* 画面がブラックアウト場合、異なる仮想コンソールに切り替えて(例: {{ic|Ctrl+Alt+F6}})、スクリーンの出力無しで root としてログインできます。そうするには、{{ic|root}} と入力し(その後 {{ic|Enter}} を押して)、root のパスワードを入力してください(その後、再び {{ic|Enter}} を押してください)。

: 次のコマンドで X サーバーを終了させることが可能です:
: {{bc|# pkill -x X}}
: 上記のコマンドが機能しない場合、再起動してください:
: {{bc|# reboot}}

* キーボード・マウス・タッチパッドなどに問題がおこる場合は [[:カテゴリ:入力デバイス]] 内のそれぞれのページを見て下さい。
* [[AMDGPU]]、[[Intel Graphics]]、[[NVIDIA]] の記事に問題の解決方法が載ってないか調べてください。

=== 一部またはすべてのユーザで黒画面、No protocol specified、Resource temporarily unavailable ===

X は設定ファイルと一時ファイルをユーザーのホームディレクトリに作成します。あなたのホームディレクトリが入っているパーティションに十分な空き容量があることを確認してください。悪いことに、ディスク容量が不足していることを X サーバーは何も知らせません。

=== Matrox カードで DRI が停止する ===

Matrox カードを使っていて Xorg をアップグレードすると DRI が停止する場合、次の行を {{ic|xorg.conf}} のビデオカードの Device セクションに追加してください:

Option "OldDmaInit" "On"

=== フレームバッファモード問題 ===

以下のログメッセージを残して X の起動が失敗する場合:
{{bc|<nowiki>
(WW) Falling back to old probe method for fbdev
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading /usr/lib/xorg/modules/linux//libfbdevhw.so
(II) Module fbdevhw: vendor="X.Org Foundation"
compiled for 1.6.1, module version=0.0.2
ABI class: X.Org Video Driver, version 5.0
(II) FBDEV(1): using default device

Fatal server error:
Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
</nowiki>}}
{{pkg|xf86-video-fbdev}} パッケージを[[pacman#パッケージの削除|アンインストール]]してください。

=== プログラムが "font '(null)'" を要求する ===

エラーメッセージ: {{ic|unable to load font `(null)'}}

いくつかのプログラムはビットマップフォントでだけ動作します。２つの主要なビットマップフォントのパッケージがあります、{{Pkg|xorg-fonts-75dpi}} と {{Pkg|xorg-fonts-100dpi}} です。両方は必要ありません、片方だけで十分です。どちらがあなたに適しているか調べるには、{{Pkg|xorg-xdpyinfo}} の {{ic|xdpyinfo}} を試してください:

$ xdpyinfo | grep resolution

そして、出力された値に最も近い方のフォントを使用してください。

=== リカバリ: GUI ログインの前に Xorg を無効化 ===

Xorg を自動的に起動するように設定していて、なんらかの理由でログイン・ディスプレイマネージャが表示される前に Xorg が起動するのを防ぎたい場合（例えば、システムを間違って設定したせいで Xorg がマウスやキーボード入力を受け付けない場合）、以下の2つの方法でこれを達成できます。

* デフォルトのターゲットを rescue.target に変更してください。[[systemd#起動時のデフォルトターゲットを変更する]] を参照。
* 誤ってシステムを設定して Xorg を使えなくしただけでなく、GRUB メニューの待ち時間をゼロに設定、または起動時から Xorg を無効にするのに GRUB を使えない場合、Arch Linux のライブ CD を使って下さい。[[インストールガイド#パーティションのマウント|インストールガイド]]に従ってインストールした Arch Linux をマウントして chroot します。もしくは、{{ic|Ctrl+Alt}} + function キー (通常は X によって使用されていない {{ic|F1}} から {{ic|F7}}) を使って [[Getty|tty]] を切り替えてから root でログインして以下を行います。

設定に応じて、以下の作業のどれか、または複数を行う必要があります:
* [[ディスプレイマネージャ]]を[[systemd#ユニットを使う|無効化]]。
* [[ログイン時に X を起動|X の自動起動]]を無効化。
* {{ic|~/.xinitrc}} の名前を変更するか {{ic|exec}} 行をコメントアウト。

=== "su" で X クライアントの起動が失敗する ===

"Client is not authorized to connect to server" と表示される場合、次の行を {{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} に追加して下さい:

session optional pam_xauth.so

{{ic|pam_xauth}} が正しく環境変数を設定し {{ic|xauth}} キーを管理します。

=== X が起動できない: Keyboard initialization failed ===

ファイルシステム(特に {{ic|/tmp}})が満杯の場合、{{ic|startx}} は失敗します。ログファイルには以下のように出力されます:

{{bc|
(EE) Error compiling keymap (server-0)
(EE) XKB: Could not compile keymap
(EE) XKB: Failed to load keymap. Loading default keymap instead.
(EE) Error compiling keymap (server-0)
(EE) XKB: Could not compile keymap
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
Fatal server error:
Failed to activate core devices.
...
}}

関連するファイルシステムにいくらかの空き領域を作れば X は起動するでしょう。

=== 動画を視聴しようとすると緑色の画面が表示される ===

色深度の設定が間違っています。例えば、16ではなく24に設定する必要があります。

=== SocketCreateListener エラー ===

{{ic|SocketCreateListener() failed}} というエラーメッセージを吐いて X が落ちてしまう場合、{{ic|/tmp/.X11-unix}} 内のソケットファイルを削除する必要があります。この問題は、(例えば {{ic|xorg.conf}} を生成するために)前回に Xorg を root として実行した場合に発生することがあります。

=== プログラムを root として実行しようとした際に Invalid MIT-MAGIC-COOKIE-1 key ===

このエラーは、現在のユーザのみが X サーバへのアクセス権を持っていることを意味しています。解決策は root にアクセス権を与えることです:

$ xhost +si:localuser:root

このコマンドは、root 以外のユーザに X へのアクセス権を与える際にも使用できます。

== 参照 ==

* [https://magcius.github.io/xplain/article/ Xplain] - X Window System の詳しい解説
* {{man|1|Xorg}}
* [https://developer.ibm.com/tutorials/l-lpic1-106-1/ Prepare for LPIC-1 exam 2 - topic 106.1: X11] - アーキテクチャ、[[#設定]]、[[デスクトップ環境]]、リモートでの使用、[[Wayland]] に関して簡単に説明しています。
* {{man|5|xorg.conf}}
* [[Gentoo:Xorg/Guide/ja#設定]]

{{TranslationStatus|Xorg|2026-02-15|864190}}

インテルグラフィックス

2026-02-15T05:18:02Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[de:Intel]]
[[en:Intel graphics]]
[[es:Intel graphics]]
[[ru:Intel graphics]]
[[zh-hans:Intel graphics]]
{{Related articles start}}
{{Related|Xorg}}
{{Related|カーネルモード設定}}
{{Related|Xrandr}}
{{Related|ハイブリッドグラフィック}}
{{Related|Vulkan}}
{{Related|GPGPU}}
{{Related articles end}}

Intel はオープンソースドライバの提供とサポートを行なっているので、インテルグラフィックスは基本的にプラグアンドプレイです。

Intel GPU のモデルや関連するチップセットと CPU の包括的なリストは、[[Wikipedia:Intel Graphics Technology]] と [[Gentoo:Intel#Feature support]] を見てください。

{{Note|
* PowerVR ベースのグラフィックカード (GMA 3600 シリーズ) はオープンソースドライバではサポートされていません。
* Intel 第 ''N'' 世代 (Gen ''N'') ハードウェアという記述は、CPU の世代を指すものではなく、[[Wikipedia:List of Intel graphics processing units|GPU の世代]]を指しています。これは CPU の世代とは異なります。
* あなたのカードを特定する方法については [[画像処理装置#インストール]] を参照してください。
}}

== インストール ==

* 以下のパッケージのうち1つを[[インストール]]してください。これらは、3D アクセラレーションのための [[wikipedia:ja:ダイレクト・レンダリング・インフラストラクチャ|DRI]] ドライバを提供します。
** {{Pkg|mesa}} は、第3世代ハードウェアおよびそれ以降用のモダンな Gallium3D ドライバを含む最新の [[Mesa]] パッケージです。これを使うことが推奨されます。
** {{Pkg|mesa-amber}} は、第2世代から第11世代までのハードウェア用のクラシックドライバ (Gallium3d でない) です。このドライバは、第7世代及びそれ以前のハードウェアにおいて高いパフォーマンスや安定性をもたらすかもしれませんが、メンテナンスされていません。
* 32ビットアプリケーションのサポートは、[[multilib]] リポジトリから {{Pkg|lib32-mesa}} か {{Pkg|lib32-mesa-amber}} パッケージもインストールしてください。
* [[Xorg]] で 2D アクセラレーションを提供する [[wikipedia:X.Org_Server#DDX|DDX]] ドライバに関しては、以下のうち1つを使ってください:
** {{Pkg|xorg-server}} パッケージに含まれる ''modesetting'' ドライバは、第3世代及びそれ以降のハードウェアにおいて推奨されます。これは、''glamor'' モジュール経由で DRI ドライバを使用してアクセラレーションを提供します。
** {{Pkg|xf86-video-intel}} パッケージは、第2世代から第9世代までのハードウェアにおいてレガシーな Intel DDX ドライバを提供します。一般に、このパッケージを使用することは推奨されません。下記のノートを参照してください。
* [[Vulkan]] サポート (Broadwell 及びそれ以降; それより古いチップにおけるサポートは[https://gitlab.freedesktop.org/mesa/mesa/-/issues/8249#note_1758622 不完全であるか存在しません]) については、{{Pkg|vulkan-intel}} パッケージをインストールしてください。32 ビット [[Vulkan]] サポートについては、{{Pkg|lib32-vulkan-intel}} パッケージをインストールしてください。

[[ハードウェアビデオアクセラレーション]]も見てください。

{{Note|1=<nowiki/>
* 一部のディストリビューション ([https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu]、[https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora]、[https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) では、{{Pkg|xf86-video-intel}} ドライバのインストールが推奨されておらず、代わりに modesetting ドライバにフォールバックさせることが推奨されています。[https://web.archive.org/web/20160714232204/https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/]、[https://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1]、[[Xorg#インストール]]、{{man|4|modesetting}} を参照してください。しかし、modesetting ドライバは次のような問題を引き起こす可能性があります: [https://gitlab.freedesktop.org/xorg/xserver/-/issues/1364 XFCE での画面のチラツキやマウスのジッタリング]、[https://bugs.chromium.org/p/chromium/issues/detail?id=370022 仮想デスクトップの切り替えを行ったときに Chromium でアーティファクトが発生する]、[https://gitlab.freedesktop.org/xorg/xserver/-/issues/928 vsync のジッタリング、mpv での動画のスタッタリング]。
* {{Pkg|xf86-video-intel}} ドライバには、第11世代及びそれ以降のハードウェアに対する適切なサポートがありません。それによって、アクセラレーションが提供されなかったり、レンダリングの問題が発生したりし、その結果として Plasma Desktop がほぼ利用不能な状態になります。[https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/commit/7181c5a41c3f00eaf996caa156523c708a18081e] を参照してください。
* {{Pkg|xf86-video-intel}} がインストールされている場合、グラフィックススタック全体がハードフリーズし、({{ic|Ctrl+Alt+F''n''}} を押して) 他の仮想コンソールに切り替えることすらできなくなり、[[SysRq]] でユーザプロセスを kill することしかできなくなるという問題が2件報告されています [https://bbs.archlinux.org/viewtopic.php?id=263323] [https://github.com/qutebrowser/qutebrowser/issues/4641]。
}}

== ローディング ==

Intel カーネルモジュールは、システムの起動時に自動的に正常にロードされるはずです。

正常にロードされない場合は:

* Intel はカーネルモード設定を必要とするので、[[カーネルパラメータ]] に {{ic|nomodeset}} を指定して '''いない''' ことを確認してください。
* また、{{ic|/etc/modprobe.d/}} や {{ic|/usr/lib/modprobe.d/}} で modprobe ブラックリストを使って Intel を無効にしていないか確認してください。

=== 早期 KMS ===

[[カーネルモード設定]] (KMS) は {{ic|i915}} ドライバと {{ic|xe}} ドライバによってサポートされており、[[mkinitcpio]] v32 から {{ic|kms}} [[mkinitcpio#通常のフック|フック]]がデフォルトで使用されているため (ブートの) 早い段階で有効化されます。他の環境で KMS をブートプロセスのできるだけ早い段階で有効化する方法については [[カーネルモード設定#KMS の早期開始]] を見てください。

=== GuC/HuC ファームウェアのロードを有効にする ===

第9世代から (Skylake およびそれ以降)、Intel GPU には以下の機能を提供する ''Graphics micro (μ) Controller'' (GuC) が搭載されています:

* 一部のメディアデコード機能を CPU から ''HEVC/H.265 micro (µ) Controller'' (HuC) にオフロードする。[[ハードウェアビデオアクセラレーション]]に {{Pkg|intel-media-driver}} を使用する場合にのみ、適用可能です。第9世代から導入されました。
* GuC をスケジューリング、コンテキスト送信、電源管理に使用する。第12世代、Alder Lake-P (Mobile) で導入されました。

この機能を使うには、まず、{{Pkg|linux-firmware-intel}} が[[インストール]]されていることを確認してください。このパッケージは、GuC と HuC のファームウェアファイルを提供するからです。

次に、GuC ファームウェアをロードする必要があります。HuC のサポートに関しては、一部のビデオ機能 (SKL 低電力エンコードモードでの CBR レート制御) が、HuC ファームウェアのロードも必要とします[https://github.com/intel/media-driver#known-issues-and-limitations]。

[[#試験的な新しい Xe ドライバをテストする|新しい試験的な]] {{ic|xe}} ドライバは、GuC と HuC の機能がデフォルトで有効化されています。

{{ic|i915}} ドライバに関しては、GuC の機能は {{ic|enable_guc}} [[カーネルモジュールパラメータ]]によって制御されています。これの使用方法は以下のとおりです:

{{Accuracy|Intel のドキュメントに反し、Tiger Lake と Rocket Lake の GPU は実際 {{ic|1=enable_guc=3}} をサポートし、{{ic|1=enable_guc=1}} がデフォルトとなっている場合があります。[[:en:Talk:Intel graphics#TGL/RKL GuC Submission]] }}

{| class="wikitable"
! enable_guc の値 !! GuC 送信 !! HuC ファームウェアのロード !! デフォルトとなっているプラットフォーム !! サポートされているプラットフォーム
|-
|0 || {{No}} || {{No}} || Tiger Lake、Rocket Lake、Gen12 以前 [https://github.com/torvalds/linux/blob/b3454ce0b2c8a56e760e6baa88ed10278585072b/drivers/gpu/drm/i915/gt/uc/intel_uc.c#L26-L36] || すべて
|-
|1 || {{Yes}} || {{No}} || {{-}} || Alder Lake-P (Mobile) およびそれ以降
|-
|2 || {{No}} || {{Yes}} || Alder Lake-S (Desktop) [https://github.com/torvalds/linux/blob/b3454ce0b2c8a56e760e6baa88ed10278585072b/drivers/gpu/drm/i915/gt/uc/intel_uc.c#L38-L42] [https://lore.kernel.org/all/87ee6wit2r.fsf@intel.com/T/] || Gen9 およびそれ以降
|-
|3 || {{Yes}} || {{Yes}} || Alder Lake-P (Mobile) 及びそれ以降 || Gen 9.5 及びそれ以降 (一部個体ではこちらがより良い)
|}

GuC 送信や HuC ファームウェアのロードがあなたの GPU ではデフォルトで有効になっていない場合、手動で有効化できます。

{{Warning|1=GuC / HuC ファームウェアのロードを手動で有効化すると、[https://bugs.freedesktop.org/show_bug.cgi?id=111918 たとえその機能がサポートされていない場合でも]、カーネルに汚染マークが付きます。さらに、GuC/HuC ファームウェアのロードを有効化すると、一部のシステムで問題が発生する可能性があります。(ハイバネートから復帰したあとなどに) フリーズが発生する場合は、無効化してください。}}

{{ic|1=enable_guc=}} [[カーネルモジュールパラメータ]] を設定してください。例えば:

{{hc|/etc/modprobe.d/i915.conf|2=
options i915 enable_guc=3
}}

[[Initramfs を再生成する|Initramfs を再生成]] してください。次回の起動時に [[dmesg]] を使うことで GuC と HuC が両方有効化されていることを確認できます:

{{hc|# dmesg {{!}} grep -i -e 'huc' -e 'guc'|2=
[30130.586970] i915 0000:00:02.0: [drm] GuC firmware i915/icl_guc_33.0.0.bin version 33.0 submission:disabled
[30130.586973] i915 0000:00:02.0: [drm] HuC firmware i915/icl_huc_9.0.0.bin version 9.0 authenticated:yes
}}

あなたのグラフィックアダプタで GuC と HuC がサポートされていない場合、以下が出力されます

{{hc|# dmesg {{!}} grep -i -e 'huc' -e 'guc'|2=
[ 0.571339] i915 0000:00:02.0: [drm] Incompatible option enable_guc=2 - GuC is not supported!
[ 0.571340] i915 0000:00:02.0: [drm] Incompatible option enable_guc=2 - HuC is not supported!
}}

あるいは、以下で確認できます:

# less /sys/kernel/debug/dri/*/gt0/uc/guc_info
# less /sys/kernel/debug/dri/*/gt0/uc/huc_info

{{Note|1=GuC/HuC が有効化されている場合に {{ic|1=enable_gvt=1}} を設定して [[Intel GVT-g|GVT-g graphics virtualization]] を使用することは、Linux 4.20.11 現在ではサポートされていません。システムのジャーナルに出力される通り、i915 モジュールの初期化に失敗します。

{{hc|# journalctl|
... kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission
... kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)
... kernel: i915: probe of 0000:00:02.0 failed with error -5
... kernel: snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19)
}}

[https://github.com/intel/gvt-linux/issues/77#issuecomment-707541069] で説明されているように、関連する警告は深刻なものではないことに注意してください:

{{hc|# journalctl -b |
... kernel: i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x5916_rid_0x02.golden_hw_state failed with error -2
}}
}}

== Xorg の設定 ==

たいてい、[[Xorg]] を実行するために設定は特に必要ありません。

しかし、ドライバのオプションを活用したい場合や、[[Xorg]] が起動しない場合などは、Xorg の設定ファイルを作成することができます。

=== modesetting ドライバを使う ===

{{Pkg|xf86-video-intel}} をインストールしたが、DDX ドライバを優先させずに modesetting ドライバを明示的にロードさせたい場合 (DDX ドライバと modesetting ドライバを比較したい場合など) は、以下のような設定ファイルを使用できます:

{{hc|/etc/X11/xorg.conf.d/20-intel.conf|
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
}}

=== Intel ドライバを使う ===

{{Note|以下は {{Pkg|xf86-video-intel}} が必要です。}}

以下のような Xorg 設定ファイルを作成してください:

{{hc|/etc/X11/xorg.conf.d/20-intel.conf|
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
EndSection
}}

その他のオプションは {{ic|Driver}} の下の新しい行にユーザが追加します。
オプションの完全なリストは {{man|4|intel}} の man ページを参照してください。

{{Note|上に挙げたものよりも多くの device セクションを追加する必要があるかもしれません。必要であれば示します。}}

==== AccelMethod ====

設定ファイルを作成する際に、{{ic|Option "AccelMethod"}} を指定する必要がある場合があります。古典的なオプションは、{{ic|UXA}}、{{ic|SNA}} (デフォルト)、{{ic|BLT}} です。

デフォルトの {{ic|SNA}} で問題が発生した場合。(例: ピクセル化したグラフィック、壊れたテキストなど)、代わりに {{ic|UXA}} を使ってみてください、これは [[#Xorg の設定|Xorg 設定ファイル]] に次の行を追加することで可能です:

Option "AccelMethod" "uxa"

{{man|4|intel|CONFIGURATION DETAILS}} の "AccelMethod" オプションをご覧ください。

==== 最近の GPU で Intel DDX ドライバを使用する ====

第8世代 (Broadwell) からの Intel GPU では、Iris Mesa ドライバが必要です:

Option "DRI" "iris"

==== TearFree、TripleBuffer、SwapbuffersWait を無効化する ====

コンポジタを使用している場合 (GNOME、KDE Plasma、Xfce などの最近のデスクトップ環境ではデフォルトです)、通常、TearFree、TripleBuffer、SwapbuffersWait を無効化することでパフォーマンスを向上させ、電力消費量を削減することができます。

Option "TearFree" "false"
Option "TripleBuffer" "false"
Option "SwapbuffersWait" "false"

== モジュールベースのオプション ==

{{ic|i915}} カーネルモジュールにより、[[カーネルモジュール#モジュールオプションを設定する|モジュールオプション]] を介して設定できます。一部のモジュールオプションは、省電力に影響を与えます。

次のコマンドを使用して、すべてのオプションのリストと簡単な説明およびデフォルト値を生成できます:

$ modinfo -p i915

現在有効になっているオプションを確認するには、

# systool -m i915 -av

多くのオプションのデフォルトは-1であるため、チップごとの省電力のデフォルトになります。ただし、[[カーネルモジュール#モジュールオプションを設定する|モジュールオプション]] を使用して、より積極的な省電力を構成することも可能です。

{{Note|1=Linux 3.18 以降、これらのデフォルトから逸脱すると、カーネルが [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] (汚染された) としてマークされます。これは基本的に、チップごとのデフォルト以外のオプションの使用は実験的なものと見なされ、開発者によってサポートされていないことを意味します。}}

=== フレームバッファー圧縮 (enable_fbc) ===

フレームバッファ圧縮 (FBC) は、スクリーンのリフレッシュ中の電力消費量とメモリの帯域幅の使用量を削減できる機能です。

この機能は、ハードウェアによってサポートされている場合、自動的に有効化されます。以下のコマンドを実行することで、この機能が有効化されているかどうか確認できます:

{{hc|$ modinfo i915 {{!}} grep enable_fbc|
parm: enable_fbc:Enable frame buffer compression for power savings (default: -1 (use per-chip default)) (int)
}}

parm が {{ic|-1}} に設定されている場合、何もする必要はありません。{{ic|-1}} でない場合、{{ic|1=i915.enable_fbc=1}} を[[カーネルパラメータ]]に追加するか、以下の内容で {{ic|/etc/modprobe.d/i915.conf}} を作成することで、FBC を強制的に有効化できます:

{{hc|/etc/modprobe.d/i915.conf|2=
options i915 enable_fbc=1
}}

{{Note|
フレームバッファー圧縮は、Sandy Bridge(第6世代)より前の Intel GPU 世代では信頼できないか、使用できない場合があります。これにより、次のようなメッセージがシステムジャーナルに記録されます:

[drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling
[drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this

解決策は、フレームバッファー圧縮を無効にすることです。これにより、消費電力僅かに増加します (+約 0.06 W)。無効にするには、[[カーネルパラメータ]] {{ic|1=i915.enable_fbc=0}} を追加します。[https://web.archive.org/web/20200228230053/https://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/]
}}

=== Fastboot ===

{{Note|1=Skylake およびそれ以降[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d6535cbed4a4b029602ff83efb2adec7cb8d28b]、さらに Bay- と Cherry-Trail (VLV/CHV)[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7360c9f6b857e22a48e545f4e99c79630994e932] では、Linux 5.1 からこのパラメータがデフォルトで有効化されていました [https://kernelnewbies.org/Linux_5.1#Graphics]。その後、Linux 6.7 でこのパラメータは完全に削除され[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58883680a8416661b48a800e5530e2efcea64a4a]、Linux 6.9 から fastboot は全ての GPU 世代 (Skylake よりも古い世代を含む) に対して有効化されました。[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b923307a1b0067a302b394e73311aeaebc06f65]}}

Intel Fastboot の目標は、BIOS または [[ブートローダー]] によってセットアップされたフレームバッファーを保持して、 [[Xorg]] が開始されるまでちらつきを回避することです。[https://lists.freedesktop.org/archives/intel-gfx/2012-May/017653.html][https://www.phoronix.com/scan.php?page=news_item&px=MTEwNzc]

fastboot がデフォルトでないプラットフォーム上で fastboot を有効にするには、{{ic|1=i915.fastboot=1}} を [[カーネルパラメータ]] として設定するか、{{ic|/etc/modprobe.d/i915.conf}} に以下を設定します:

{{hc|/etc/modprobe.d/i915.conf|2=
options i915 fastboot=1
}}

=== Intel GVT-g グラフィック仮想化のサポート===

詳細については [[Intel GVT-g]] を参照してください。

=== パフォーマンスサポートを有効化する ===

第6世代から (Sandy Bridge およびそれ以降) Intel GPU は、内部のパフォーマンスデータをドライバに公開するために使用されるパフォーマンスカウンタを提供しています。ドライバとハードウェアレジスタではこのインフラを ''Observation Architecture'' (内部的には "OA") と呼んでいますが [https://www.phoronix.com/scan.php?page=news_item&px=Intel-HSW-Observation-Arch]、Intel のドキュメントではこの機能をより一般的に ''Observability Performance Counters'' を提供するものとしています [https://01.org/sites/default/files/documentation/observability_performance_counters_haswell.pdf] [https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol14-observability.pdf]。

デフォルトでは、[https://lwn.net/Articles/486306/ CAP_SYS_ADMIN] (root と等価です) や [https://lwn.net/Articles/812719/ CAP_PERFMON] [[ケイパビリティ]]で実行されているプログラムのみが observation architecture を利用できます [https://github.com/torvalds/linux/blob/b14ffae378aa1db993e62b01392e70d1e585fb23/drivers/gpu/drm/i915/i915_perf.c#L267] [https://github.com/torvalds/linux/blob/b14ffae378aa1db993e62b01392e70d1e585fb23/drivers/gpu/drm/i915/i915_perf.c#L3481-L3484]。ほとんどのアプリケーションはこれらのケイパビリティを持たずに実行されるため、以下の警告が出力されます:

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

これらのケイパビリティ (または root) を使わずにパフォーマンスサポートを有効化するには、[[sysctl]] で説明されているように、(上記の警告で示されている) カーネルパラメータを設定してください。

{{Warning|アプリケーションにパフォーマンスデータへのアクセスを許してしまうなどのリスクが存在するため、{{ic|perf_event_paranoid}} ファミリのオプションには制限的なデフォルトが存在します [https://docs.kernel.org/admin-guide/perf-security.html]。とはいえ、{{ic|dev.i915.perf_stream_paranoid}} は GPU パフォーマンスカウンタへのアクセスにしか影響せず、CPU アーキテクチャ実行コンテキストレジスタなどと比べれば低リスクです。}}

== ヒントとテクニック ==

=== スケーリングモードを設定する ===

フルスクリーンを使うアプリケーションで有用かもしれません:

$ xrandr --output LVDS1 --set PANEL_FITTING ''param''

選べる {{ic|''param''}} は:

* {{ic|center}}: 解像度は定義した通りに固定され、スケーリングは無効になります
* {{ic|full}}: 画面いっぱいまで解像度がスケールします
* {{ic|full_aspect}}: アスペクト比を維持したまま解像度を可能な限り最大までスケールします

うまく行かない場合は、以下を試してみてください:

$ xrandr --output LVDS1 --set "scaling mode" ''param''

{{ic|''param''}} は {{ic|"Full"}}、{{ic|"Center"}}、{{ic|"Full aspect"}} のいずれかです。

{{Note|1=上記のオプションは外部ディスプレイは現在のところ機能しません (例: VGA, DVI, HDMI, DP) [https://bugs.freedesktop.org/show_bug.cgi?id=90989]。}}

=== 報告される OpenGL のバージョンを上書き ===

{{ic|MESA_GL_VERSION_OVERRIDE}} [[環境変数]]を使うことで、アプリケーションに報告される OpenGL のバージョンを上書きできます。例えば、{{ic|1=MESA_GL_VERSION_OVERRIDE=4.5}} と設定することで OpenGL 4.5 と報告されるようになります。

{{Note|上記の変数を使って既知の OpenGL バージョンなら、たとえ GPU によってサポートされていないバージョンでも使うこともできます。設定することで、アプリケーションによってクラッシュがなおったり、あるいはクラッシュが増えたりする可能性があります。全てのアプリケーションで同じ変数を使わない方が良いでしょう。}}

=== モニタリング ===

[[ハードウェアビデオアクセラレーション#確認]] を見てください。

=== 明るさとガンマ値の設定 ===

[[バックライト]] を見てください。

=== 試験的な新しい Xe ドライバをテストする ===

(試験的な) [https://docs.kernel.org/gpu/xe/index.html 新しい Xe ドライバ]を試すには、以下が必要です:

* {{Pkg|linux}} 6.8 以上
* [[Wikipedia:ja:Tiger Lake|Tiger Lake]] 及びそれ以降の統合グラフィックス、またはディスクリートグラフィックカード。
* {{Pkg|mesa}}。

以下のコマンドで PCI ID を確認してください:

{{hc|$ lspci -nnd ::03xx|
00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:'''9a49'''] (rev 01)
}}

そして、適切な PCI ID を使って以下を[[カーネルパラメータ]]に追加してください:

... i915.force_probe=!'''9a49''' xe.force_probe='''9a49'''

必要なときに元に戻すためのブート手段を確保しておいてください。

== トラブルシューティング ==

=== ティアリング ===

==== Intel ドライバを使う ====

SNA アクセラレーションメソッドを取っている場合、一部のマシン上でティアリングが発生します。これを修正するには、以下の行を[[#Xorg の設定|設定ファイル]]に追加して {{Pkg|xf86-video-intel}} ドライバの {{ic|TearFree}} オプションを有効化してください:

{{hc|/etc/X11/xorg.conf.d/20-intel.conf|
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "TearFree" "true"
EndSection}}

詳細は[https://bugs.freedesktop.org/show_bug.cgi?id=37686 元のバグレポート]を見てください。

{{Note|1=<nowiki/>
* このオプションは、{{ic|SwapbuffersWait}} が {{ic|false}} のときに動作しない場合があります。
* このオプションはメモリアロケーションを増加させ、パフォーマンスが低下する場合があります。[https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]
* このオプションは、vsync のタイミングに厳しいアプリケーション (例えば、[[Wikipedia:Super Meat Boy|Super Meat Boy]]) において問題が発生する場合があります。
* このオプションはUXA アクセラレーションメソッドでは動作しません。SNA でしか使えません。
* Intel UHD 620 または 430 では、{{ic|TearFree}} を動作させるために {{ic|Option "TripleBuffer" "true"}} を追加する必要があります。
}}

==== modesetting ドライバを使う ====

TearFree サポートが modesetting ドライバに[https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1006 追加されました] [https://www.phoronix.com/news/xf86-video-modesetting-TearFree][https://www.phoronix.com/news/Modesetting-TearFree-Merged]。XWayland でないサーバーに対する最後のリリースは2021年のバージョン 21.1 ですが、このパッチはまだ安定リリースに至っていません。なので、安定化されるまで {{AUR|xorg-server-git}} を使う必要があります。

{{hc|/etc/X11/xorg.conf.d/20-intel.conf|
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
Option "TearFree" "true"
EndSection}}

=== 垂直同期 (VSYNC) を無効化する ===

以下のような場合に便利です:

* Chromium/Chrome が、GPU のせいでラグくパフォーマンスが悪く、--disable-gpu スイッチを使うとスムーズに動作する場合。
* glxgears テストが期待するほどのパフォーマンスを発揮してくれない場合。

intel ドライバは垂直同期に [https://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] を使用します。これは、完全なパフォーマンスとティアリングの回避を可能にします。垂直同期をオフにするには (例えば、ベンチマークのために)、以下の {{ic|.drirc}} をホームディレクトリ内に追加してください:

{{hc|~/.drirc|2=
<device screen="0" driver="dri2">
<application name="Default">
<option name="vblank_mode" value="0"/>
</application>
</device>
}}

=== DRI3 の問題 ===

{{Pkg|xf86-video-intel}} では DIR バージョンのデフォルトは ''DRI3'' です。一部の環境では DRI3 によって問題が発生することがあります [https://bugs.chromium.org/p/chromium/issues/detail?id=370022]。''DRI2'' を使うには[[#Xorg の設定|設定ファイル]]に以下の行を追加してください:

Option "DRI" "2"

{{ic|modesetting}} ドライバーでは上記の方法で DRI3 を無効化することはできません。代わりに {{ic|1=LIBGL_DRI3_DISABLE=1}} 環境変数を設定してください。

=== GTK アプリケーションでグリフが表示されない ===

GTK アプリケーションでフォントの文字が表示されなくなってしまう場合、以下の方法で直る可能性があります。{{ic|/etc/environment}} を[[編集]]して以下の行を追加してください:

{{hc|/etc/environment|output=
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer
}}

[https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584] も参照。

=== グラフィックがおかしい、固まる ===

一部のアプリケーションでグラフィックがおかしい/固まる問題が発生する場合は (アプリケーションのウィンドウがランダムな色で埋まる、ひどくぼやける、ラグが無いにも関わらず他のタスクを実行中にアプリケーションのグラフィックの更新が行われなくなるなど)、問題の起こるアプリケーションを [[Vulkan]] ではなく [[OpenGL]] で実行してみてください。このような問題は Intel Arc GPU の一部構成で起こります。

=== Intel ドライバで X がフリーズ/クラッシュする ===

X のクラッシュを伴う問題、GPU のハングアップ、X のフリーズに関する問題は、{{ic|NoAccel}} オプションを使って GPU の使用を無効化することで修復できる場合があります。以下の行を[[#Xorg の設定|設定ファイル]]に追加してください:

Option "NoAccel" "True"

あるいは、{{ic|DRI}} オプションを使って 3D アクセラレーションだけを無効化してみてください:

Option "DRI" "False"

=== 認識されない解像度を追加する ===

この問題は、[[Xrandr#検出されない解像度を追加する|Xrandr のページ]] で扱っています。

=== バックライトを調整できない ===

サスペンドから復帰したあとにホットキーを使用してスクリーンの輝度を変更できない場合、[[バックライト]]の記事を見てあなたの設定ファイルをチェックしてみてください。

問題が解消されない場合は、以下の[[カーネルパラメータ]]のうち1つを試してください:

acpi_osi=Linux
acpi_osi="!Windows 2012"
acpi_osi=

また、fastboot モード ({{ic|i915.fastboot}} カーネルパラメータ) を使用していないことを確認してください。これは、バックライト制御を破壊することが[https://www.phoronix.com/forums/forum/software/mobile-linux/1066447-arch-linux-users-with-intel-graphics-can-begin-enjoying-a-flicker-free-boot 知られています]。

=== Chromium や Firefox の表示がおかしい/応答しない ===

Chromium や Firefox で表示の乱れ、応答なし、ラグ、低パフォーマンスが発生する場合、以下のような解決策があります。

* [[#AccelMethod|AccelMethod を "uxa" に設定する]]
* [[#垂直同期 (VSYNC) を無効化する|VSYNC を無効化する]]
* [[#ティアリング|TearFree オプションを有効化する]]
* "DRI" とアクセラレーションのメソッドを無効にする (第10世代でテスト済み): {{bc|<nowiki>
Option "NoAccel" "True"
Option "DRI" "False"
</nowiki>}}

=== Broadwell/Core-M チップでカーネル 4.0 以上を使っている場合にクラッシュする ===

X/Wayland がロードされた数秒後、マシンがフリーズして、[[journalctl]] に以下のようなインテルグラフィックスに関連するカーネルのクラッシュログが残ることがあります:

Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)
...
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1
...
Jun 16 17:54:03 hostname kernel: Call Trace:
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)

この問題は execlist のサポート (カーネル 4.0 からデフォルトに変更されました) を無効化することで解決します。以下の[[カーネルパラメータ]]を追加してください:

i915.enable_execlists=0

これは、カーネル 4.0.5 以上で壊れていることが知られています。

=== Windows をゲストとした場合にラグが発生する ===

VirtualBox でホスト側から（マウスカーソルを動かすなどして）画面を更新しないと Windows ゲストのビデオ出力が止まってしまうことがあります。{{ic|1=enable_fbc=1}} オプションを削除すれば問題は解決します。

=== 画面がちらつく ===

Intel iGPU で使用される省電力機能 Panel Self Refresh (PSR) は、一部の例でちらつきを発生させることが知られています {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}。一時的な解決策は、[[カーネルパラメータ]] {{ic|1=i915.enable_psr=0}} または {{ic|1=xe.enable_psr=0}} を使ってこの機能を無効化することです。

この方法は、{{ic|[i915] *ERROR* CPU pipe A FIFO underrun}} のようなエラーメッセージを解決します。

=== i915 ドライバで OpenGL 2.1 ===

{{Pkg|mesa-amber}} パッケージに含まれる第3世代 GPU 用の古い mesa ドライバは、デフォルトでは OpenGL 2.0 が利用可能であると報告します。これは、対象のハードウェアが OpenGL 2.1 とは完全に互換性がないことが原因です。[https://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop] OpenGL 2.1 のサポートは、{{ic|/etc/drirc}} または {{ic|~/.drirc}} で以下のようなオプションを設定することにより、手動で有効化することができます:

{{hc|/etc/drirc|output=
<driconf>
...
<device driver="i915">
<application name="Default">
<option name="'''stub_occlusion_query'''" value="'''true'''" />
<option name="'''fragment_shader'''" value="'''true'''" />
</application>
</device>
...
</driconf>
}}

{{Note|
* OpenGL のバージョンが戻ってしまう理由は、Chromium と他のアプリケーションでエクスペリエンスが悪化するためでした。必要であれば、drirc ファイルを編集して特定のアプリケーションに対して OpenGL 2.1 を {{ic|chromium}} 実行ファイルなどで無効化することもできます ([https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ 参照])。
* {{Pkg|mesa}} パッケージに含まれる新しい Gallium ベースの i915 ドライバは、常に OpenGL 2.1 が利用可能であると報告します。なので、このドライバに対しては上記の設定は不要です。
}}

=== KMS の問題: コンソールが小さい領域に制限される ===

低解像度のビデオポートの1つが起動時に有効になっていて、そのせいでターミナルがスクリーンの小さい領域を使っているのかもしれません。修正するには、ブートローダーでカーネルコマンドラインパラメータの {{ic|1=video=SVIDEO-1:d}} を使って i915 モジュールの設定でそのポートを明示的に無効化してください。詳細は [[カーネルパラメータ]] を見てください。

これでうまく行かない場合、SVIDEO-1 ではなく TV1 か VGA1 を無効化してみてください。ビデオポートの名前は [[xrandr]] でリストアップできます。

=== Haswell CPU で HDMI 経由で音声が出ない ===

[https://bugzilla.kernel.org/show_bug.cgi?id=60769 Linux カーネルの issue] によると、{{ic|1=intel_iommu=on}} を設定している場合には HDMI から音声が出力されないそうです。この問題を修正するには、以下の[[カーネルパラメータ]]を設定してください:

intel_iommu=on,igfx_off

あるいは、IOMMU を無効化してください:

intel_iommu=off

=== 低消費電力 Intel CPU でクラッシュ/フリーズ ===

低消費電力 Intel プロセッサやノート PC プロセッサは、低消費電力 Intel チップで使用されている電源管理機能に関する問題によりランダムにハングアップ/クラッシュする傾向にあります。そのようなクラッシュが発生する場合、この問題を報告するログは見られないでしょう。以下の[[カーネルパラメータ]]を追加することで、この問題を解決できるかもしれません。

{{Note|以下のカーネルパラメータを3つすべて一緒に使用することは推奨されません。}}

intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1

{{ic|1=ahci.mobile_lpm_policy=1}} は、いくつかの Lenovo ノート PC や一部の Acer ノートブックにおける、SATA コントローラーの問題のある電源管理に起因するハングアップを修正します。この回避策はインテルグラフィックスと厳密には関連していませんが、関連する問題を解決します。このカーネルパラメータを追加すると、''l''ink ''p''ower ''m''anagement をファームウェアのデフォルトから最大パフォーマンスに変更し、特定の Lenovo マシンでディスプレイ輝度を変更した際にハングする問題を解決しますが、modern ultrabook でアイドル時の電力消費量が 1~1.5W 増加します。詳細 (特に他の状態に関するもの) については、[https://lore.kernel.org/lkml/20171211165216.5604-1-hdegoede@redhat.com/ Linux カーネルメーリングリスト]や [https://access.redhat.com/documentation/en-en/red_hat_enterprise_linux/6/html/power_management_guide/alpm Red Hat ドキュメント]を見てください。

{{ic|1=i915.enable_dc=0}} は、GPU の電源管理を無効化します。これは、特定の Intel システム (特に、Goldmount と Kaby Lake Refresh チップ) におけるランダムなハングを解決します。このパラメータを使用すると、電力消費量が増え、ノート PC/notebook のバッテリー寿命が短くなります。これで問題が解決した場合は、DC 制限をより細かく設定してみてください ({{ic|1=modinfo i915 {{!}} grep enable_dc}} で設定可能な値を調べられます)。

{{ic|1=intel_idle.max_cstate=1}} は、プロセッサのスリープ状態を制限し、プロセッサがディープスリープ状態に移行するのを防ぎます。これは絶対に理想的ではなく、電力消費量の増加とバッテリーの短命化を招きます。しかし、多くの Intel システムでランダムなハングを解決します。Intel Baytrail や Kaby Lake Refresh チップを使用している場合は、このパラメータを使用してください。Intel "Baytrail" チップは、このカーネルパラメータを使用しないと、[https://bugzilla.kernel.org/show_bug.cgi?id=109051#c752 ファームウェアの欠陥]によりランダムにハングしてしまうことが知られていましたが、理論的には [https://gitlab.freedesktop.org/drm/i915/kernel/-/commit/a75d035fedbdecf83f86767aa2e4d05c8c4ffd95 2019-04-26] に修正されました。
max_cstate パラメータに関する詳細は[https://docs.kernel.org/admin-guide/pm/intel_idle.html#kernel-command-line-options-and-module-parameters カーネルドキュメント]で、cstate に関する一般的な情報は [https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7 GitHub 上の記事]で見られます。

頻繁にハングする問題を解決するために {{ic|1=intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1}} を追加して問題が解決した場合は、その後パラメータを一つずつ取り除いて、どのパラメータが実際に問題の解決になっているかを確かめるべきです。実際の問題が SATA の電源管理に関係していて、問題を実際に解決するパラメータが {{ic|1=ahci.mobile_lpm_policy=1}} である場合、cstate やディスプレイの電源管理が無効化されている状態でマシンを走らせることは推奨されていません。

詳細は [https://linuxreviews.org/Intel_graphics#Kernel_Parameters Linux Reviews] を見てください。

==== 高い C ステートで S3 スリープから復帰しなくなってしまう ====

システムが低頻度で復帰後に黒画面になるが、たいていは正常に復帰できてジャーナルに {{ic|CPU pipe A FIFO underrun}} というメッセージ記録され、かつ {{ic|1=intel_idle.max_cstate=1}} で C ステートを制限すると正常に復帰できるようになる場合、[[電源管理/サスペンドとハイバネート#スリープフック|スリープフック]]と {{man|1|cpupower-idle-set}} を使えば、{{ic|-D0}} と {{ic|-E}} オプションでサスペンドサイクル中に C ステートを効果的に制御することができます。[https://bbs.archlinux.org/viewtopic.php?pid=2175597#p2175597] そうすることで、CPU を常に低い C ステートで動作させる必要がなくなります。

=== 165Hz モニタのサポートを追加する ===

一部の 165Hz モニタで、''xrandr'' が 165Hz のオプションを表示しない場合があり、さらに [[#認識されない解像度を追加する]] の方法ではこれを解決できません。この場合、[https://unix.stackexchange.com/questions/680356/i915-driver-stuck-at-40hz-on-165hz-screen i915-driver-stuck-at-40hz-on-165hz-screen] を見てください。

{{Note|{{ic|/etc/initramfs-tools/hooks/edid}} を作成する以外にも、[[mkinitcpio]] フックを作成する必要があります:

{{hc|/etc/initcpio/install/edid|
#!/bin/bash

build() {
add_file /lib/firmware/edid/edid.bin
}

help() {
cat <<HELPEOF
This hook add support for 165Hz
HELPEOF
}
}}

そして、{{ic|/etc/mkinitcpio.conf}} の HOOKS 配列に ''edid'' を末尾に追加してください。以下のように:

{{hc|/etc/mkinitcpio.conf|2=
HOOKS=(... fsck edid)
}}

そして、[[Initramfs を再生成する|initramfs を再生成]]してください。
}}

=== Raptor Lake と Alder Lake-P 上でスリープ/サスペンドから復帰するとフリーズする ===

Raptor Lake 及び Alder Lake-P の 12 世代モバイルプロセッサを搭載する、様々な製造者のノート PC は、サスペンドからの復帰後にフリーズや黒画面が発生すると報告されています。これは、多くのノート PC 製造者が、iGPU に接続されているポートが間違って記述されている、不適切な VBT (Video BIOS Table) を使用しているからです (freedesktop のイシュー [https://gitlab.freedesktop.org/drm/intel/-/issues/5531 5531] [https://gitlab.freedesktop.org/drm/intel/-/issues/6401 6401] で説明されています)。この場合、ドキュメント化されているケースは全て、重複した eDP エントリに関連しています。

ほとんどの製造者が、Windows が正しく動作するノート PC に向けて BIOS アップデートをリリース[https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/7402 しない]ことを考えれば、この問題はカーネル側から対処するしかありません。この問題を防ぐ推奨される方法は、[https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/7709 変更した VBT を読み込む]ことです。アイデアとしては、重複した eDP エントリを VBT から削除し、initramfs に変更した VBT を入れ、その VBT をカーネルパラメータ経由で i915 ドライバに渡します。

以下のコマンドの出力を解析して、重複した eDP エントリを特定する必要があります:

{{hc|# intel_vbt_decode /sys/kernel/debug/dri/1/i915_vbt|
Child device info:
Device handle: 0x0008 (LFP 1 (eDP))
Device type: 0x1806 (unknown)
...
Child device info:
Device handle: 0x0080 (LFP 2 (eDP))
Device type: 0x1806 (unknown)
}}

VBT をコピーし、16進数エディタで編集して、重複しているデバイスハンドルに対応するデバイスタイプを {{ic|00 00}} に変更します:

$ cat /sys/kernel/debug/dri/0/i915_vbt > vbt

--- vbt
+++ modified_vbt
@@ -22,10 +22,10 @@
00000150 00 08 00 20 00 08 00 10 00 08 00 02 00 08 00 01 |... ............|
00000160 00 08 00 00 01 08 00 00 00 04 00 00 00 40 00 00 |.............@..|
00000170 00 20 00 00 00 10 00 00 00 02 00 00 00 01 00 00 |. ..............|
-00000180 00 00 01 00 00 02 8b 01 02 04 00 00 27 08 00 06 |............'...|
-00000190 18 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 |................|
+00000180 00 00 01 00 00 02 8b 01 02 04 00 00 27 08 00 00 |............'...|
+00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 |................|
000001a0 03 00 00 00 c0 00 40 00 20 00 00 00 00 00 00 00 |......@. .......|
-000001b0 00 00 20 00 80 00 06 18 00 00 00 00 00 00 00 00 |.. .............|
+000001b0 00 00 20 00 80 00 00 00 00 00 00 00 00 00 00 00 |.. .............|
000001c0 00 00 00 00 07 00 00 00 00 00 00 c0 00 10 00 20 |............... |
000001d0 00 00 00 00 00 00 00 00 00 20 00 04 00 d2 60 00 |......... ....`.|
000001e0 10 10 00 23 21 10 00 00 00 00 00 07 00 00 02 00 |...#!...........|

変更した VBT を読み込むには、{{ic|/lib/firmware/i915/modified_vbt}} に VBT をコピーし、そのファイルを initramfs に入れてください。[[mkinitcpio]] の場合は、{{ic|/etc/mkinitcpio.conf}} 内の {{ic|FILES}} 配列を使うことができます:

FILES=(/lib/firmware/i195/modified_vbt)

[[Initramfs を再生成]]し、カーネルパラメータ {{ic|i915.vbt_firmware{{=}}i915/modified_vbt}} を使って新しいテーブルを i915 に渡してください。

=== 色が抜けた ===

デフォルトでは、一部のモニターは Intel GPU から適切に認識されず、フルレンジ RGB モードにならないため、色が抜けてしまうことがあります。

==== Wayland での色の問題を修正する ====

{{hc|/etc/udev/rules.d/80-i915.rules|2=
ACTION=="add", SUBSYSTEM=="module", KERNEL=="i915", RUN+="/usr/local/bin/intel-wayland-fix-full-color"
}}

{{hc|/usr/local/bin/intel-wayland-fix-full-color|<nowiki>
#!/bin/bash

readarray -t proptest_result <<<"$(/usr/bin/proptest -M i915 -D /dev/dri/card0 | grep -E 'Broadcast|Connector')"

for ((i = 0; i < ${#proptest_result[*]}; i += 2)); do
connector=$(echo ${proptest_result[i]} | awk '{print $2}')
connector_id=$(echo ${proptest_result[i + 1]} | awk '{print $1}')

/usr/bin/proptest -M i915 $connector connector $connector_id 1
done
</nowiki>}}

[[GNOME]] を使用している場合、{{ic|<rgbrange>full</rgbrange>}} を {{ic|~/.config/monitors.xml}} 設定ファイルに追加する[https://gitlab.gnome.org/GNOME/mutter/-/issues/1871#note_2090262 代替案]もあります。例:

{{hc|~/.config/monitors.xml|<nowiki>
<monitors version="2">
<configuration>
<layoutmode>logical</layoutmode>
<logicalmonitor>
<x>0</x>
<y>0</y>
<primary>yes</primary>
<monitor>
<monitorspec>
<connector>HDMI-1</connector>
<vendor>MetaProduct's Inc.</vendor>
<product>MetaMonitor</product>
<serial>0x123456</serial>
</monitorspec>
<mode>
<width>1920</width>
<height>1080</height>
<rate>60.000</rate>
</mode>
<rgbrange>full</rgbrange>
</monitor>
</logicalmonitor>
</configuration>
</monitors>
</nowiki>}}

{{Note|
* ディスプレイのレンジが変わったり、その他の方法でディスプレイの設定が変更されたりした場合、新しいレイアウトが {{ic|<rgbrange>full</rgbrange>}} タグ無しで {{ic|monitors.xml}} に追加されるかもしれません。異なるレイアウトでも RGB レンジを一貫して設定するために、論理モニタの全てのエントリにこのタグを追加することを検討してください。
* GDM ログイン画面がフル RGB レンジを使用していない場合、ユーザーの {{ic|monitors.xml}} を gdm のホームディレクトリにコピーしてください。[[GDM#デフォルトのモニター設定をセットアップする]] を参照してください。
}}

==== X11/Xorg での色の問題を修正する ====

# xrandr --output NAME_OF_YOUR_OUTPUT --set "Broadcast RGB" "Full"

=== B580 で "bus error" により一部のプログラムを実行できない ===

(vainfo、falkon、mpv など) 一部のプログラムを実行すると以下のようなエラーが発生する場合:

1234 bus error : vaapi

考えられる原因は、BIOS/UEFI で ReBar (Resizable BAR) が無効化されていることです。一部のマザーボードでは、レガシーサポートが無い場合、UEFI モードがアクティブであるときにしか ReBar を有効化できません。

== 参照 ==

* https://01.org/linuxgraphics/documentation (サポートされているハードウェア一覧など)

{{TranslationStatus|Intel graphics|2026-02-15|859434}}

ハードウェアビデオアクセラレーション

2026-02-13T22:54:11Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[en:Hardware video acceleration]]
[[ru:Hardware video acceleration]]
[[zh-hans:Hardware video acceleration]]
[[Wikipedia:Graphics processing unit#GPU accelerated video decoding and encoding|ハードウェアビデオアクセラレーション]]により、ビデオカードで動画をデコード/エンコードすることができ、CPU の負担を下げて電力を節約することができます。

Linux でこれを実現する方法は複数存在します:

* [[Wikipedia:Video Acceleration API|Video Acceleration API]] (VA-API) はハードウェア支援による動画エンコード・デコードの両方を実現する仕様とオープンソースライブラリです。Intel によって開発されました。
* [[Wikipedia:VDPAU|Video Decode and Presentation API for Unix]] (VDPAU) は GPU ビデオハードウェアに動画のデコードやポストプロセス処理をオフロードするオープンソースのライブラリです。NVIDIA によって開発されました。
* [https://gpuopen.com/advanced-media-framework/ Advanced Media Framework SDK] (AMF) は、マルチメディア処理のために AMD GPU に「部分的に」アクセスできるようにするオープンソースのフレームワークです。AMD によって開発されました。
* [[Wikipedia:Nvidia NVDEC|NVDEC]]/[[Wikipedia:Nvidia NVENC|NVENC]] - Fermi 以降の NVIDIA GPU によって使われている、ハードウェアビデオアクセラレーションのためのプロプライエタリ API。
* [https://www.khronos.org/blog/an-introduction-to-vulkan-video Vulkan Video] は、ハードウェアアクセラレートされたビデオエンコードとデコードをサポートするために開発された [[Vulkan]] グラフィックス API の拡張です。

ドライバとアプリケーションのサポートの包括的な概要については、[[#比較一覧]] を参照してください。

== インストール ==

=== Intel ===

==== VA-API ====

[[Intel Graphics]] オープンソースドライバーは VA-API に対応しています:

* [https://github.com/intel/media-driver/#supported-platforms Broadwell] [[wikipedia:Template:Intel_processor_roadmap|(2014)]] 及びそれ以降の HD Graphics シリーズ (例: Intel Arc) は {{Pkg|intel-media-driver}} によってサポートされています。
* [[wikipedia:Coffee_Lake|Coffee Lake]] (2017) までの GMA 4500 (2008) は {{Pkg|libva-intel-driver}} によってサポートされています。
* [[Wikipedia:Haswell (microarchitecture)#Haswell Refresh|Haswell Refresh]] から Skylake までの VP9 デコードと、Broadwell から Skylake までのハイブリッド VP8 エンコードは {{AUR|intel-hybrid-codec-driver-git}} によってサポートされています。

{{Note|Skylake 及びそれ以降は {{Pkg|linux-firmware-intel}} も必要です。}}

[https://www.intel.com/content/www/us/en/developer/articles/technical/linuxmedia-vaapi.html VAAPI がサポートするハードウェアと機能] もご覧ください。

==== Vulkan Video ====

ANV オープンソース [[vulkan]] ドライバは、{{Pkg|vulkan-intel}} 経由で Vulkan Video のサポートを提供しています。

{{Note|Vulkan Video を有効化するには、追加の設定が必要です。[[#Vulkan Video の設定]] を参照してください。}}

==== Intel Video Processing Library (Intel VPL) ====

[https://github.com/intel/libvpl Intel VPL] を使用するには、ベースライブラリである {{Pkg|libvpl}} に加えて、以下のランタイム実装のうち少なくとも一つを[[インストール]]してください:

* {{Pkg|vpl-gpu-rt}}: Tiger Lake 及びそれ以降の GPU に対するサポートを提供します
* {{Pkg|intel-media-sdk}} (開発中止): それより古い Intel GPU に対するサポートを提供します

=== NVIDIA ===

[[Nouveau]] オープンソースドライバーは VA-API に対応しています:

* GeForce GTX 750 までの GeForce 8 シリーズ及びそれ以降の GPU は {{Pkg|mesa}} によってサポートされています。
* (現在 NVIDIA のバイナリドライバーから抽出される) {{AUR|nouveau-fw}} ファームウェアパッケージが [https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware 必要] です。

[[NVIDIA]] プロプライエタリドライバは {{Pkg|nvidia-utils}} によって以下をサポートしています:

* [[Wikipedia:GeForce 8 series|GeForce 8 シリーズ]]及びそれ以降の GPU における VDPAU
* [[Wikipedia:Fermi (microarchitecture)|Fermi]] 及びそれ以降の GPU における NVDEC [https://developer.download.nvidia.com/assets/cuda/files/NVIDIA_Video_Decoder.pdf]
* [[Wikipedia:Kepler (microarchitecture)|Kepler]] 及びそれ以降の GPU における NVENC
* [[Wikipedia:Pascal (microarchitecture)|Pascal]] 及びそれ以降の GPU における Vulkan Video [https://developer.nvidia.com/vulkan/video/get-started]

=== AMD/ATI ===

[[AMD]] と [[ATI]] オープンソースドライバーは {{Pkg|mesa}} によって VA-API をサポートしています:

* VA-API は Radeon HD 2000 及びそれ以降の GPU。

RADV オープンソース [[vulkan]] ドライバは、{{Pkg|vulkan-radeon}} 経由で Vulkan Video サポートを提供しています。

{{Out of date|最新の AMD Media Framework は、オープンソースドライバ以外に追加のプロプライエタリなパッケージをもはや必要としていません。しかし、AUR のパッケージは更新されておらず、オープンな [[AMDGPU]] ドライバを使用する新しい ''amf'' パッケージもアップロードされていません。}}

* [[Wikipedia:Radeon Rx 300 series|Fiji]] 及びそれ以降の GPU における AMF は {{AUR|amf-amdgpu-pro}} によってサポートされています。

{{Note|
* [[Wikipedia:High Efficiency Video Coding|HEVC]] エンコードは [[Wikipedia:Radeon RX 5000 series|Navi]] より古い GPU では利用できない場合があります。
}}

=== 変換レイヤー ===

* {{App|libvdpau-va-gl|OpenGL/VAAPI バックエンドを用いた VDPAU ドライバ。H.264 のみ。|https://github.com/i-rinat/libvdpau-va-gl|{{Pkg|libvdpau-va-gl}}}}
* {{App|nvidia-vaapi-driver|VA-API を提供する [[CUDA]] NVDEC ベースのバックエンド。|https://github.com/elFarto/nvidia-vaapi-driver/|{{Pkg|libva-nvidia-driver}}}}

{{Note|{{Pkg|libva-nvidia-driver}} 実装によってハードウェアビデオデコードを使えるようにはなりますが、NVIDIA の電源管理に対する現状の制限により、デフォルトの設定では [https://github.com/elFarto/nvidia-vaapi-driver/issues/74 CPU によるビデオデコードよりも多くの電力を消費します]。
回避策は、NVIDIA ドライババージョン 580.105.08 以降を使用し、環境変数 {{ic|CUDA_DISABLE_PERF_BOOST{{=}}1}} を設定することです。}}

== 確認 ==

設定せずともシステムが完璧に動作する場合があります。なので、このセクションから読み始めて、システムの確認をすると良いでしょう。

{{Tip|
* コマンドラインサポートのある [[mpv#ハードウェアデコード|mpv]] は、ハードウェアアクセラレーションをテストするのにぴったりです。{{ic|1=mpv --hwdec=auto ''video_filename''}} のログを見てください。詳細は [https://mpv.io/manual/stable/#options-hwdec hwdec] を参照。
* AMD、Intel、そして NVIDIA の場合、動画を再生しながら {{Pkg|nvtop}} を使うことで "DEC" (デコーダ) の使用率を確認できます。
* Intel GPU の場合、{{pkg|intel-gpu-tools}} を使って、{{ic|intel_gpu_top}} を root として実行することで、ビデオプレイバック中に GPU 使用率をモニタできます。ビデオバーが 0% よりも上にあれば、GPU のビデオデコーダ/エンコーダが使用されていることを示します。([[インテルグラフィックス#試験的な新しい Xe ドライバをテストする|新しい Xe ドライバ]]を使用している場合、{{ic|intel_gpu_top}} が[https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/174 エラーを出します]。確認するには {{ic|gputop}} を実行してみてください。[https://dri.freedesktop.org/docs/drm/gpu/i915.html#intel-gpu-basics vcs (Video Command Streamer) の値]が 0% より大きければ、GPU 動画デコード/エンコードが使用されていることを意味します。)
* AMD GPU の場合、{{Pkg|amdgpu_top}} を使用して GPU 使用率をモニタできます。
* 任意の GPU において、{{Pkg|htop}} のようなツールで CPU 使用率を比較できます。特に、高解像度なビデオ (4k 以上) において、VA-API が有効化されていて動作しているときの CPU 使用率は、ノート PC や他の比較的低電力なデバイスにおいて劇的に低いはずです。
}}

=== VA-API の確認 ===

VA-API の設定は {{Pkg|libva-utils}} パッケージに含まれている {{ic|vainfo}} を実行することで確認できます:

{{hc|$ vainfo|<nowiki>
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.7.3
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
</nowiki>}}

あなたのカードを使ってデコードできるフォーマットが {{ic|VAEntrypointVLD}} で、エンコードできるフォーマットが {{ic|VAEntrypointEncSlice}} で示されます。

上の例では、以下の行があることから {{ic|i965}} ドライバーが使われていることが確認できます:

vainfo: Driver version: Intel '''i965''' driver for Intel(R) Skylake - 1.7.3

{{ic|vainfo}} を実行したときに以下のようなエラーが表示される場合:

libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

適切なドライバーを設定する必要があります。[[#VA-API の設定]] を見てください。

=== VDPAU の確認 ===

{{pkg|vdpauinfo}} をインストールしてから、以下のコマンドを実行してください。VDPAU ドライバーがロードされていることや、現在の設定が確認できます:

{{hc|$ vdpauinfo|<nowiki>
display: :0 screen: 0
API version: 1
Information string: OpenGL/VAAPI backend for VDPAU

Video surface:

name width height types
-------------------------------------------
420 4096 4096 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 NV24 YV24 P010 P016 Y_U_V_444_16
422 4096 4096 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 NV24 YV24 P010 P016 Y_U_V_444_16
444 4096 4096 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 NV24 YV24 P010 P016 Y_U_V_444_16
420_16 4096 4096 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 NV24 YV24 P010 P016 Y_U_V_444_16
422_16 4096 4096 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 NV24 YV24 P010 P016 Y_U_V_444_16
444_16 4096 4096 NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 NV24 YV24 P010 P016 Y_U_V_444_16

Decoder capabilities:

name level macbs width height
----------------------------------------------------
MPEG1 --- not supported ---
MPEG2_SIMPLE --- not supported ---
MPEG2_MAIN --- not supported ---
H264_BASELINE 51 16384 2048 2048
H264_MAIN 51 16384 2048 2048
H264_HIGH 51 16384 2048 2048
VC1_SIMPLE --- not supported ---
VC1_MAIN --- not supported ---
VC1_ADVANCED --- not supported ---
...
</nowiki>}}

=== Vulkan Video の確認 ===

{{pkg|vulkan-tools}} をインストールし、''vulkaninfo'' を使ってビデオ処理拡張が利用可能であるかを確認してください:

{{hc|$ vulkaninfo {{!}} grep VK_KHR_video_|<nowiki>
VK_KHR_video_decode_av1 : extension revision 1
VK_KHR_video_decode_h264 : extension revision 9
VK_KHR_video_decode_h265 : extension revision 8
VK_KHR_video_decode_queue : extension revision 8
VK_KHR_video_encode_h264 : extension revision 14
VK_KHR_video_encode_h265 : extension revision 14
VK_KHR_video_encode_queue : extension revision 12
VK_KHR_video_maintenance1 : extension revision 1
VK_KHR_video_queue : extension revision 8
</nowiki>}}

== 設定 ==

{{Out of date|{{Pkg|mesa}} 25.3.0 以降、オープンソースドライバから VDPAU のサポートが[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36632 削除されました]。以下の例の {{ic|radeonsi}} ドライバもその対象です。}}

ビデオドライバは VA-API と VDPAU の両方に対してハードウェアビデオアクセラレーションのサポートを自動的に有効化するはずですが、場合によっては手動で VA-API/VDPAU を手動で設定する必要があります。[[#確認]] セクションを見た場合にのみ、このセクションを読み進めてください。

(他に設定が存在しない場合に使用される) デフォルトのドライバ名はシステムによって推測されます。しかし、それらはしばしばトリッキーで、機能しないこともあります。推測された値は [[Xorg]] のログファイルに出力されます。ログファイルは、Xorg が rootless の場合は {{ic|~/.local/share/xorg/Xorg.0.log}}、Xorg が root として実行されている場合は {{ic|/var/log/Xorg.0.log}} です。ログファイルからある値を検索するには:

{{hc|$ grep -iE 'vdpau {{!}} dri driver' ''xorg_のログファイル''|
(II) RADEON(0): [DRI2] DRI driver: radeonsi
(II) RADEON(0): [DRI2] VDPAU driver: radeonsi
}}

この出力の場合、{{ic|radeonsi}} が VA-API と VDPAU のデフォルトです。

{{Note|[[GDM]] を使用している場合、代わりに {{ic|1=journalctl -b --grep='vdpau {{!}} dri driver'}} を root として実行してください。}}

しかし、これは ''設定'' を表すものではありません。上記の値は、オーバーライドしたとしても変更されません。

=== VA-API の設定 ===

{{ic|LIBVA_DRIVER_NAME}} [[環境変数]] を使うことで、VA-API 用に使用するドライバをオーバーライドできます:

* [[Intel Graphics]]:
** {{Pkg|libva-intel-driver}} の場合は {{ic|i965}} を使ってください。
** {{Pkg|intel-media-driver}} の場合は {{ic|iHD}} を使ってください。
* NVIDIA:
** [[Nouveau]] の場合は {{ic|nouveau}} を使ってください。
** [[NVIDIA]] NVDEC の場合は {{ic|nvidia}} を使ってください。
* AMD:
** [[AMDGPU]] ドライバの場合は {{ic|radeonsi}} を使ってください。

{{Note|
* インストールされているドライバーは {{ic|/usr/lib/dri/}} ディレクトリを見ることで確認できます。{{ic|/usr/lib/dri/'''${LIBVA_DRIVER_NAME}'''_drv_video.so}} として使われます。
* 一部のドライバーは互換性を保つために異なる名前を使っていることがあります。{{ic|sha1sum /usr/lib/dri/* {{!}} sort}} を実行することで確認できます。
* {{ic|LIBVA_DRIVERS_PATH}} を使うことで VA-API ドライバーのパスを上書きできます。
* バージョン 12.0.1 から Mesa は {{ic|gallium}} の代わりとして {{ic|radeonsi}} を提供しています。
}}

=== VDPAU の設定 ===

{{ic|VDPAU_DRIVER}} [[環境変数]]を使うことで、VDPAU 用に使用するドライバをオーバーライドできます。

適切なドライバ名は、あなたのセットアップに依存します:

* オープンソースの AMD、Intel、Nouveau ドライバの場合、{{ic|va_gl}} に設定する[[#Failed to open VDPAU backend|必要があります]]。
* NVIDIA のプロプライエタリなバージョンの場合、{{ic|nvidia}} に設定してください。

{{Note|
* インストールされているドライバーは {{ic|/usr/lib/vdpau/}} ディレクトリを見ることで確認できます。{{ic|/usr/lib/vdpau/libvdpau_'''${VDPAU_DRIVER}'''.so}} として使われます。
* 一部のドライバーは互換性を保つために異なる名前を使っていることがあります。{{ic|sha1sum /usr/lib/vdpau/*}} を実行することで確認できます。
* ハイブリッド構成 (NVIDIA と AMD の両方のカードが搭載されている) 場合、{{ic|DRI_PRIME}} [[環境変数]]を設定する必要があるかもしれません。詳しくは [[PRIME]] を参照。
}}

=== Vulkan Video の設定 ===

* [[インテルグラフィックス]]: {{Pkg|vulkan-intel}} の Vulkan Video サポートは {{ic|1=ANV_DEBUG=video-decode,video-encode}} [[環境変数]]で有効化できます。
* [[AMD]]: {{Pkg|vulkan-radeon}} の Vulkan Video サポートは、Mesa 25 以降、VCN 2、3、4+ ではデフォルトで有効化されています。それより古いカードでサポートを強制的に有効化するには、{{ic|RADV_PERFTEST}} [[環境変数]]に {{ic|video_decode,video_encode}} を設定してください。

{{Warning|
一部の古い GPU モデルは [[Mesa]] での Vulkan Video のサポートがありません。そのような GPU で Vulkan Video サポートを強制的に有効化すると、一部のアプリケーションがクラッシュします場合があります (例えば、[https://gitlab.archlinux.org/archlinux/packaging/packages/mpv/-/issues/20#note_340586 mpv])。
}}

=== アプリケーションの設定 ===

マルチメディアフレームワーク:

* [[FFmpeg#ハードウェアビデオアクセラレーション]]
* [[GStreamer#ハードウェアアクセラレーション]]

ビデオプレイヤ:

* [[Kodi#ヒントとテクニック]]
* [[MPlayer#ハードウェアアクセラレーション]]
* [[mpv#ハードウェアデコード]]
* [[VLC media player#ハードウェアアクセラレーションのサポート]]

ウェブブラウザ:

* [[Chromium#ハードウェアビデオアクセラレーション]]
* [[Firefox#ハードウェアビデオアクセラレーション]]
* [[GNOME Web#ハードウェアアクセラレーション]]

マルチメディア録画/ストリーミング:

* [[Open Broadcaster Software#ハードウェアアクセラレーション]]

== トラブルシューティング ==

=== Failed to open VDPAU backend ===

適切なドライバを指すように {{ic|VDPAU_DRIVER}} 変数を設定する必要があります。[[#VDPAU の設定]] を参照。

{{Pkg|mesa}} 25.3.0 以降、VDPAU のサポートがオープンソースなドライバから[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36632 削除されました] ({{ic|d3d12}}、{{ic|nouveau}}、{{ic|r600}}、{{ic|radeonsi}}、{{ic|virtio_gpu}})。以前にこれらのドライバを使用していた場合、それらのパッケージを[[#変換レイヤー]]に置き換えるか、VA-API を直接使うようにアプリケーションを設定する必要があります。

=== VAAPI init failed ===

エラーは {{ic|libva: /usr/lib/dri/i965_drv_video.so init failed}} という行で確認できます。[[Wayland]] が正しく認識されていないことが原因で発生します。{{ic|$DISPLAY}} の設定を解除することで mpv, MPlayer, VLC などは X11 であると誤認しないようになります。mpv の場合は {{ic|1=--gpu-context=wayland}} パラメータを追加することでも解決できます。

このエラーは、あなたのハードウェアに合わない VA-API ドライバをインストールした場合にも起こりえます。

=== AMDGPU ドライバーを使用したビデオデコード時の破損や歪み ===

[[AMDGPU]] ドライバーでビデオデコードの破損または歪みが発生する場合は、{{ic|1=allow_rgb10_configs=false}} [[環境変数]]を設定してください。[https://bugs.freedesktop.org/show_bug.cgi?id=106490]

=== iHD 使用時に vainfo が失敗する ===

以下のエラーが発生する場合:

{{hc|$ vainfo|
Trying display: wayland
Trying display: x11
error: can't connect to X server!
Trying display: drm
libva error: dlopen of /usr/lib64/dri/iHD_drv_video.so failed: /usr/lib64/dri/iHD_drv_video.so: undefined symbol: _ZN6GmmLib16GmmClientContext9GmmGetAILEv
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Coffee Lake - 2.4.1
vainfo: Supported profile and entrypoints
[...]
}}

{{AUR|intel-media-driver-legacy}} をレガシーではないパッケージの代わりにインストールしてみてください。これは、{{AUR|intel-compute-runtime-legacy}} とも動作します。[https://aur.archlinux.org/packages/intel-compute-runtime-legacy-bin#comment-1024408]

== 比較一覧 ==

=== VA-API ドライバ ===

{| class="wikitable" style="text-align:center;"
! コーデック
! {{pkg|libva-intel-driver}} [https://github.com/01org/intel-vaapi-driver/blob/master/README]
! {{pkg|intel-media-driver}} [https://github.com/intel/media-driver/blob/master/README.md]
! {{pkg|mesa}} [https://www.x.org/wiki/RadeonFeature/] [https://nouveau.freedesktop.org/wiki/VideoAcceleration/]
! {{Pkg|libva-nvidia-driver}} (NVDEC アダプタ)
|-
! colspan=5 | デコード
|-
! MPEG-2
| {{G|GMA 4500 から Ice Lake}}
| {{G|Broadwell 及びそれより新しいもの}}
| {{G|Radeon HD 6000 - Radeon RX 6000 GeForce 8 から GTX 750}}
| rowspan=10 | [[#NVIDIA ドライバのみ]] を参照
|-
! H.263/MPEG-4 Visual1
| {{No}}
| {{No}}
| {{G|Radeon HD 6000 - Radeon RX 6000}}
|-
! VC-1
| {{G|Sandy Bridge から Ice Lake}}
| rowspan=2 {{G|Broadwell 及びそれより新しいもの}}
| {{G|Radeon HD 2000 - Radeon RX 6000 GeForce 9300 から GTX 750}}
|-
! H.264/MPEG-4 AVC
| {{G|Ironlake から Ice Lake}}
| {{G|Radeon HD 2000 及びそれより新しいもの GeForce 8 から GTX 750}}
|-
! H.265/HEVC 8bit
| {{G|Cherryview/Braswell から Ice Lake}}
| {{G|Skylake and newer}}
| {{G|Radeon R9 Fury 及びそれより新しいもの}}
|-
! H.265/HEVC 10bit
| {{G|Broxton から Ice Lake}}
| {{G|Broxton/Apollo Lake 及びそれより新しいもの}}
| {{G|Radeon 400 及びそれより新しいもの}}
|-
! VP8
| {{G|Broadwell から Ice Lake}}
| {{G|Broadwell 及びそれより新しいもの}}
| {{No}}
|-
! VP9 8bit
| {{G|Broxton から Ice Lake Hybrid: Haswell refresh から Skylake2}}
| {{G|Broxton/Apollo Lake 及びそれより新しいもの}}
| rowspan=2 {{G|Raven Ridge + Radeon RX 5000 及びそれより新しいもの}}
|-
! VP9 10bit & 12bit
| {{G|Kaby Lake から Ice Lake}}
| {{G|Kaby Lake 及びそれより新しいもの}}
|-
! AV1 8bit & 10bit
| {{No}}
| {{G|Tiger Lake 及びそれより新しいもの}}
| {{G|Radeon RX 6600 以上/それより新しいもの }}
|-
! colspan=5 | エンコード
|-
! MPEG-2
| {{G|Ivy Bridge から Ice Lake}}
| {{G|Broadwell 及びそれより新しいもの Broxton/Apollo Lake を除く}}
| {{No}}
| rowspan=8 {{No}}3
|-
! H.264/MPEG-4 AVC
| {{G|Sandy Bridge から Ice Lake}}
| {{G|Broadwell 及びそれより新しいもの}}
| {{G|Radeon HD 7000 及びそれより新しいもの}}
|-
! H.265/HEVC 8bit
| {{G|Skylake から Ice Lake}}
| {{G|Skylake 及びそれより新しいもの}}
| {{G|Radeon 400 及びそれより新しいもの}}
|-
! H.265/HEVC 10bit
| {{G|Kaby Lake から Ice Lake}}
| rowspan=2 {{G|Kaby Lake 及びそれより新しいもの}}
| {{G|Raven Ridge + Radeon RX 5000 及びそれより新しいもの}}
|-
! VP8
| {{G|Cherryview/Braswell から Ice Lake Hybrid: Haswell から Skylake2}}
| rowspan=3 {{No}}
|-
! VP9 8bit
| {{G|Kaby Lake から Ice Lake}}
| rowspan=2 {{G|Ice Lake 及びそれより新しいもの}}
|-
! VP9 10bit & 12bit
| rowspan=2 {{No}}
|-
! AV1 8bit & 10bit
| {{G|Alchemist 及びそれより新しいもの}}
| {{G|Radeon RX 7900 以上/それより新しいもの}}
|}

# VA-API の制限により MPEG-4 Part 2 はデフォルトで無効化されています。それでも使用してみるには、[[環境変数]] {{ic|1=VAAPI_MPEG4_ENABLED=true}} を設定してください。
# Hybrid VP8 エンコーダと VP9 デコーダは {{AUR|intel-hybrid-codec-driver-git}} によってサポートされています。
# NVIDIA CUDA アダプタコーデックのサポートは活発に開発中であり、これは変更される可能性があります [https://github.com/elFarto/nvidia-vaapi-driver/issues/116]。

=== VDPAU ドライバ ===

{| class="wikitable" style="text-align:center;"
! コーデック
! 色深度
! {{pkg|nvidia-utils}}
! {{pkg|libvdpau-va-gl}} (VA-API アダプタ)
|-
! colspan=4 | デコード
|-
! MPEG-2
! 8bit
| {{G|GeForce 8 及びそれより新しいもの}}
| rowspan=3 {{No}}
|-
! H.263/MPEG-4 Visual
! 8bit
| {{G|GeForce 200 及びそれより新しいもの}}
|-
! VC-1
! 8bit
| {{G|GeForce 8 及びそれより新しいもの1}}
|-
! H.264/MPEG-4 AVC
! 8bit
| {{G|GeForce 8 及びそれより新しいもの}}
| [[#VA-API ドライバ]] を参照
|-
! rowspan=2 | H.265/HEVC
! 8bit
| {{G|GeForce 900 及びそれより新しいもの2}}
| rowspan=6 {{No}}
|-
! 10bit
| {{No}}3
|-
! rowspan=2 | VP9
! 8bit
| {{G|GeForce 900 及びそれより新しいもの2}}
|-
! 10bit/12bit
| {{No}}3
|-
! rowspan=2 | AV1
! 8bit
| {{G|RTX 30 series 及びそれより新しいもの}}4
|-
! 10bit
| {{No}}3
|}

# GeForce 8800 Ultra、8800 GTX、8800 GTS (320/640 MB) は[[Wikipedia:Nvidia PureVideo|除く]]。
# GeForce GTX 970 と GTX 980 は除く。
# NVIDIA の実装は8ビットストリームまでに制限されています [https://forums.developer.nvidia.com/t/vdpau-expose-hevc-main10-support-where-available-on-die/43163] [https://us.download.nvidia.com/XFree86/Linux-x86_64/410.57/README/vdpausupport.html#vdpau-implementation-limits]。
# ドライババージョン 510 から [https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-510-Linux-Beta]

=== NVIDIA ドライバのみ ===

{| class="wikitable" style="text-align:center;"
! rowspan=2 | コーデック
! colspan=2 | {{Pkg|nvidia-utils}} [https://developer.nvidia.com/nvidia-video-codec-sdk]
|-
! NVDEC
! NVENC
|-
! MPEG-2
| rowspan=3 {{G|Fermi 以降1}}
| rowspan=2 {{No}}
|-
! VC-1
|-
! H.264/MPEG-4 AVC
| {{G|Kepler 以降2}}
|-
! H.265/HEVC 8bit
| rowspan=2 {{G|Maxwell (GM206) 以降}}
| {{G|Maxwell (2nd Gen) 以降}}
|-
! H.265/HEVC 10bit
| {{G|Pascal 以降}}
|-
! VP8
| {{G|Maxwell (2nd Gen) 以降}}
| rowspan=3 {{No}}
|-
! VP9 8bit
| {{G|Maxwell (GM206) 以降}}
|-
! VP9 10bit & 12bit
| {{G|Pascal 以降}}
|-
! AV1 8bit & 10bit
| {{G|Ampere 以降3}}
| {{G|Ada Lovelace 以降}}
|}

# GM108 は除く (未サポート)
# GM108 と GP108 は除く (未サポート)
# A100 は除く (未サポート)

=== アプリケーションサポート ===

{| class="wikitable"
! rowspan=2 | アプリケーション
! colspan=4 | デコード
! colspan=3 | エンコード
! rowspan=2 | ドキュメント
|-
! VA-API
! VDPAU
! NVDEC
! Vulkan
! VA-API
! NVENC
! Vulkan
|-
! [[FFmpeg]]
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| [[FFmpeg#ハードウェアビデオアクセラレーション]]
|-
! [[GStreamer]]
| {{Yes}}
| {{No|1=https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/393}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| [[GStreamer#ハードウェアアクセラレーション]]
|-
! [[Kodi]]
| {{Yes}}
| {{Yes}}
| {{No}}
| {{No}}
| {{-}}
| {{-}}
| {{-}}
| [[Kodi#ヒントとテクニック]]
|-
! [[mpv]]
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{-}}
| {{-}}
| {{-}}
| [[mpv#ハードウェアデコード]]
|-
! [[VLC media player]]
| {{Yes}}
| {{Yes}}
| {{No}}
| {{No|1=https://code.videolan.org/videolan/vlc/-/issues/28362}}
| {{-}}
| {{-}}
| {{-}}
| [[VLC media player#ハードウェアアクセラレーションのサポート]]
|-
! [[MPlayer]]
| {{No}}
| {{Yes}}
| {{No}}
| {{No}}
| {{-}}
| {{-}}
| {{-}}
| [[MPlayer#ハードウェアアクセラレーション]]
|-
! [[Chromium]]
| {{Yes}}
| {{No}}
| {{No}}
| {{No}}
| {{Yes}}
| {{No}}
| {{No}}
| [[Chromium#ハードウェアビデオアクセラレーション]]
|-
! [[Firefox]]
| {{Yes}}
| {{No}}
| {{No}}
| {{No|1=https://bugzilla.mozilla.org/show_bug.cgi?id=1753129}}
| {{No|1=https://bugzilla.mozilla.org/show_bug.cgi?id=1658900}}
| {{No}}
| {{No}}
| [[Firefox#ハードウェアビデオアクセラレーション]]
|-
! [[GNOME/Web]]
| colspan=4 {{C|GStreamer}}
| {{C|?}}
| {{C|?}}
| {{C|?}}
| [[GNOME Web#ビデオ]]
|}

{{TranslationStatus|Hardware video acceleration|2026-02-14|865193}}

AMDGPU

2026-02-13T21:57:32Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[de:AMDGPU]]
[[hu:AMDGPU]]
[[en:AMDGPU]]
[[ru:AMDGPU]]
[[zh-hans:AMDGPU]]
{{Related articles start}}
{{Related|ATI}}
{{Related|Xorg}}
{{Related|Vulkan}}
{{Related articles end}}

[[Wikipedia:AMDGPU|AMDGPU]] は [[wikipedia:ja:Graphics Core Next|Graphics Core Next]] ファミリの AMD Radeon グラフィックカード向けのオープンソースグラフィックドライバです。

== 適切なドライバーの選択 ==

自身のハードウェアを確認し、[[画像処理装置#インストール]] を読んで適切なドライバを探してください。このドライバは [https://www.x.org/wiki/RadeonFeature/ Southern Islands] (GCN 1。2012年リリース。) 及びそれ以降のカードをサポートしています。AMD には GCN より前の GPU をサポートする計画はありません。

サポートされない GPU については、オープンソースの [[ATI]] ドライバを使用できます。

== インストール ==

{{Pkg|mesa}} パッケージを[[インストール]]してください。これには、3D アクセラレーションのための DRI ドライバーと、[[#ビデオアクセラレーション|動画デコードのアクセラレーション]]のための VA-API/VDPAU ドライバの両方が含まれています。

* 32ビットアプリケーションのサポートに関しては、[[multilib]] リポジトリから {{Pkg|lib32-mesa}} パッケージもインストールしてください。
* [[Xorg]] における 2D アクセラレーションに関しては、AMD 固有の DDX ドライバを提供する {{Pkg|xf86-video-amdgpu}} パッケージを任意でインストールしてもよいです。{{ic|amdgpu}} カーネルドライバを使用するほとんどの Xorg システムは、{{Pkg|xorg-server}} に組み込まれている汎用の ''modesetting'' DDX で正常に動作します。しかし、{{Pkg|xf86-video-amdgpu}} は、{{ic|TearFree}} などの機能を使用する場合や、''Southern Islands'' などの一部の AMD ハードウェアでのハードウェア固有の問題を解決するために、必要となることがあります。[[インテルグラフィックス#インストール]] に書かれているノートを参照してください。
* [[Vulkan]]をサポートするには、{{Pkg|vulkan-radeon}} (32ビットアプリケーションの場合は {{Pkg|lib32-vulkan-radeon}}) をインストールしてください。

=== 試験的 ===

一部のユーザーにとっては、mesa の上流の試験的ビルドを使用する価値があるかもしれません。

{{AUR|mesa-git}} パッケージをインストールしてください。これは 3D アクセラレーション用の DRI ドライバーを提供します。

* 32 ビットアプリケーションのサポートに関しては、''mesa-git'' リポジトリ、または [[AUR]] から {{AUR|lib32-mesa-git}} もインストールしてください。
* ([[Xorg]] で 2D アクセラレーションを提供する) DDX ドライバに関しては、{{AUR|xf86-video-amdgpu-git}} パッケージをインストールしてください。
* ''mesa-git'' リポジトリを使用する [[Vulkan]] サポートに関しては、''vulkan-radeon-git'' パッケージをインストールしてください。任意で、32 ビットアプリケーションをサポートするために ''lib32-vulkan-radeon-git'' パッケージもインストールしてください。AUR から {{AUR|mesa-git}} をビルドする場合、これは必要ないはずです。

{{Tip|{{AUR|mesa-git}} パッケージのコンパイルを行いたくない場合は、[[非公式ユーザーリポジトリ#mesa-git|mesa-git]] 非公式リポジトリを使用できます。}}

=== Southern Islands (SI) と Sea Islands (CIK) のサポートを有効化 ===

[[カーネル#公式サポートカーネル|公式サポートカーネル]]では、Southern Islands (GCN 1。2012年リリース。) 及び Sea Islands (GCN 2。2013年リリース。) のカードの AMDGPU サポートが有効化されています。{{ic|amdgpu}} カーネルドライバは [[ATI|radeon]] ドライバより前にロードされる必要があります。どのカーネルドライバがロードされているかは {{ic|lspci -k}} で確認できます。以下のように出力されるはずです:

{{hc|$ lspci -k -d ::03xx|
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]
Subsystem: Gigabyte Technology Co., Ltd Device 226c
Kernel driver in use: amdgpu
Kernel modules: radeon, amdgpu
}}

{{ic|amdgpu}} ドライバが使用されていない場合、次のセクションの指示に従ってください。

==== amdgpu ドライバをロード ====

{{ic|amdgpu}} モジュールと {{ic|radeon}} モジュールの両方の[[モジュールパラメータ]]は {{ic|1=cik_support=}} と {{ic|1=si_support=}} です。

これらは、カーネルパラメータまたは ''modprobe'' 設定ファイルで設定する必要があり、カードの GCN バージョンによって異なります。

どのカーネルカードを使用しているか不確かな場合は、両方のパラメータを使うことができます。

{{Tip|[[dmesg]] は、使用すべき正しい方のカーネルパラメータを示してくれる場合があります: {{ic|1=[..] amdgpu 0000:01:00.0: Use radeon.cik_support=0 amdgpu.cik_support=1 to override}}}}

===== カーネルコマンドラインでモジュールパラメータを設定 =====

次のいずれかの[[カーネルパラメータ]]を設定してください:

* Southern Islands (SI): {{ic|1=radeon.si_support=0 amdgpu.si_support=1}}
* Sea Islands (CIK): {{ic|1=radeon.cik_support=0 amdgpu.cik_support=1}}

さらに、統合 Sea Island (GCN 1.1) カードと AMD A10 APU を使用する場合、正しくブートさせるには Radeon Dynamic Power Management を無効化しておく必要がある場合があります。この機能には、グラフィックコアのクロックを動的に調整することで、APU の温度を下げ、静音性を高める目的があります。しかし、この機能のせいで再起動の無限ループに陥ることがあります。無効化するには、上記の手順に従い、{{ic|1=radeon.dpm=0}} をブートオプションに追加してください。

==== 正しいモジュール順序を指定 ====

{{ic|amdgpu}} が [[Mkinitcpio#MODULES]] 配列の1番目のモジュールとして設定されていることを確認してください。例えば、{{ic|1=MODULES=(amdgpu radeon)}}。

===== カーネルモジュールパラメータを設定 =====

Southern Islands (SI) の場合は {{ic|1=si_support=1}} [[カーネルモジュールパラメータ]]を、Sea Islands (CIK) の場合は {{ic|1=cik_support=1}} を使用してください:

{{hc|/etc/modprobe.d/amdgpu.conf|2=
options amdgpu si_support=1
options amdgpu cik_support=1
}}

{{hc|/etc/modprobe.d/radeon.conf|2=
options radeon si_support=0
options radeon cik_support=0
}}

{{ic|modconf}} が {{ic|/etc/mkinitcpio.conf}} の {{ic|HOOKS}} 配列にあることを確認し、[[Initramfs を再生成する|initramfs を再生成]]してください。

===== amdgpu ドライバをサポートするカーネルをコンパイル =====

[[カーネル]]をビルド/コンパイルする場合、{{ic|1=CONFIG_DRM_AMDGPU_SI=Y}} と {{ic|1=CONFIG_DRM_AMDGPU_CIK=Y}} の一方/両方を config で設定する必要があります。

=== ACO コンパイラ ===

[https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200 ACO コンパイラ]はオープンソースのシェーダコンパイラであり、[https://llvm.org/ LLVM コンパイラ]や [https://github.com/GPUOpen-Drivers/AMDVLK AMDVLK ドライバ]、[[wikipedia:ja:Microsoft Windows 10|Windows 10]] に直接対抗するために [[wikipedia:ja:Valve Corporation|Valve Corporation]] によって作成・開発されています。LLVM と AMDVLK よりも短いコンパイル時間と、ゲームでのより良いパフォーマンスを提供します。

いくつかのベンチマークは [https://gist.github.com/pendingchaos/aba1e4c238cf039d17089f29a8c6aa63 GitHub] や Phoronix [https://www.phoronix.com/scan.php?page=article&item=radv-aco-llvm&num=1][https://www.phoronix.com/scan.php?page=article&item=radv-aco-gcn10&num=1] で見られます。

{{Pkg|mesa}} バージョン [https://docs.mesa3d.org/relnotes/20.2.0.html#new-features 20.2] から、ACO はデフォルトのシェーダコンパイラとなっています。

== ロード ==

{{ic|amdgpu}} カーネルモジュールはシステムの起動時に自動的にロードされることになっています。

ロードされない場合:

* 必要な場合は [[#Southern Islands (SI) と Sea Islands (CIK) のサポートを有効化]]していることを確認してください。
* 最新の {{Pkg|linux-firmware-amdgpu}} パッケージがインストールされていることを確認してください。このドライバは、正しくブートするために各モデルの最新のファームウェアを必要とします。
* [[カーネルパラメータ]]に {{ic|nomodeset}} や {{ic|1=vga=}} を指定して'''いない'''ことを確認してください。{{ic|amdgpu}} は [[KMS]] を必要とするからです。
* [[カーネルモジュール#ブラックリスト|カーネルモジュールのブラックリスト]]で {{ic|amdgpu}} が無効になっていないことを確認してください。

読み込むことはできるが、X サーバが必要とする時よりも後になってしまう場合、[[カーネルモード設定#KMS の早期開始]] を見てください。

== Xorg の設定 ==

[[Xorg]] は自動的にドライバをロードし、モニタの EDID を使ってネイティブの解像度を設定してくれます。設定が必要になるのは、ドライバをチューニングする場合のみです。

手動で設定したい場合、{{ic|/etc/X11/xorg.conf.d/20-amdgpu.conf}} を作成して、以下を記述してください:

{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=
Section "OutputClass"
Identifier "AMD"
MatchDriver "amdgpu"
Driver "amdgpu"
EndSection
}}

このセクションを使って、機能を有効化したりドライバの設定を調整したりできます。ドライバオプションを設定する前に、まず {{man|4|amdgpu}} を見てください。

=== TearFree レンダリング ===

''TearFree'' は、ハードウェアのページフリッピング機構を使ってティアリング防止を制御します。デフォルトでは、TearFree は、回転された出力、RandR 変換が適用された出力、RandR 1.4 スレーブ出力に対してオンになり、それら以外ではオフになります。{{ic|true}} か {{ic|false}} を指定することで、常にオンにしたり、常にオフにしたりもできます。

Option "TearFree" "true"

[[xrandr]] を使用して TearFree を一時的に有効にすることもできます:

$ xrandr --output ''output'' --set TearFree on

{{ic|''output''}} は {{ic|DisplayPort-0}} や {{ic|HDMI-A-0}} のような形式である必要があります。この値は {{ic|xrandr -q}} で取得できます。

=== DRI レベル ===

''DRI'' は、有効にする DRI の最大レベルを設定します。有効な値は、DRI2 の場合は ''2''、 DRI3 の場合は ''3'' です。 [[Xorg]] バージョンが 1.18.3 以降の場合、DRI3 のデフォルトは ''3'' です。それ以外の場合、 DRI2 が使用されます:

Option "DRI" "3"

=== 可変リフレッシュレート ===

[[可変リフレッシュレート]] を参照してください。

=== 10 ビットカラー ===

{{Warning|10 ビットカラーを有効化すると、多くのアプリケーションでグラフィックの乱れやクラッシュを引き起こす場合があります。これには特に [[Steam/トラブルシューティング#Steam: An X Error occurred|Steam]] が含まれ、X Error によりクラッシュします。}}

新しい AMD カードは 10bpc カラーをサポートしていますが、デフォルトは 24 ビットカラーであり、30 ビットカラーは明示的に有効にする必要があります。アプリケーションがこれもサポートしている場合、これを有効にすると、グラデーションの目に見えるバンディング/グラフィックの乱れを減らすことができます。モニターがサポートしているかどうかを確認するには、[[Xorg#一般|Xorg ログファイル]]で ''EDID'' を検索してください (例:{{ic|/var/log/Xorg.0.log}} または {{ic|~/.local/share/xorg/Xorg.0.log}}):

[ 336.695] (II) AMDGPU(0): EDID for output DisplayPort-0
[ 336.695] (II) AMDGPU(0): EDID for output DisplayPort-1
[ 336.695] (II) AMDGPU(0): Manufacturer: DEL Model: a0ec Serial#: 123456789
[ 336.695] (II) AMDGPU(0): Year: 2018 Week: 23
[ 336.695] (II) AMDGPU(0): EDID Version: 1.4
[ 336.695] (II) AMDGPU(0): Digital Display Input
'''[ 336.695] (II) AMDGPU(0): 10 bits per channel'''

現在有効になっているかどうかを確認するには、''Depth'' を検索してください:

[ 336.618] (**) AMDGPU(0): Depth 30, (--) framebuffer bpp 32
[ 336.618] (II) AMDGPU(0): Pixel depth = 30 bits stored in 4 bytes (32 bpp pixmaps)

デフォルトの設定では、24 であると表示されます (24 ビットが 4 バイトに格納されている)。

10ビットが機能するかどうかを確認するには、Xorg を実行している場合は終了し、白黒の縞模様を表示する {{ic|Xorg -retro}} を実行し、{{ic|Ctrl-Alt-F1}} と {{ic|Ctrl-C}} を押して X を終了し、{{ic|Xorg -depth 30 -retro}} を実行してください。これが正常に機能する場合は、10ビットが機能しています。

{{ic|startx}} を介して10ビットで起動するには、{{ic|startx -- -depth 30}} を使用してください。永続的に有効にするには、以下を作成または追加してください:

{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=
Section "Screen"
Identifier "asdf"
DefaultDepth 30
EndSection
}}

=== 出力のレイテンシを減らす ===

レイテンシを最小化したい場合、ページフリッピングや TearFree を無効化できます:

{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=
Section "OutputClass"
Identifier "AMD"
MatchDriver "amdgpu"
Driver "amdgpu"
Option "EnablePageFlip" "off"
Option "TearFree" "false"
EndSection
}}

レイテンシを更に減らしたい場合は [[ゲーム#DRI の遅延を軽減する]] を見てください。

{{Note|これらのオプションを設定すると、ティアリングや短時間のアーティファクトが発生する場合があります。}}

== 機能 ==

=== ビデオアクセラレーション ===

[[ハードウェアビデオアクセラレーション#AMD/ATI]] を見てください。

=== モニタリング ===

GPU の温度や P-state を確認したい場合に GPU のモニタリングはしばしば行われます。CLI ツールと GUI ツールのリストは [[画像処理装置#モニタリング]] を見てください。

個々のパーツを手動でモニタリングしたい場合は (例えば、スクリプト内で使いたい場合)、情報は全て {{ic|/sys/}} で入手できます。その他のパーツや詳細については、[https://docs.kernel.org/gpu/amdgpu/thermal.html The Linux Kernel - GPU Power/Thermal Controls and Monitoring] を参照してください。

以下のコマンドでは、システム内にある GPU の数によっては {{ic|card0}} の部分を他の値 (例: {{ic|card1}}) に置き換える必要があるかもしれません。

GPU の P-state を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/pp_od_clk_voltage

GPU をモニタリングするには、以下を実行:

# watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info

GPU 使用率 (%) を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/gpu_busy_percent

GPU のクロックを確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/pp_dpm_sclk

GPU 温度 (ミリ°C) を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/hwmon/hwmon*/temp1_input

VRAM のクロックを確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/pp_dpm_mclk

VRAM の使用量 (バイト) を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/mem_info_vram_used

VRAM のサイズ (バイト) を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/mem_info_vram_total

=== オーバークロック ===

Linux 4.17 以降、以下の機能をブート時に有効化すると、{{ic|/sys/class/drm/card0/device/pp_od_clk_voltage}} を介してグラフィックカードのクロックと電圧を調整できるようになります。

==== ブートパラメータ ====

{{ic|1=amdgpu.ppfeaturemask=0xffffffff}} [[カーネルパラメータ]] を追加して、sysfs でクロックと電圧を調整するアクセスをアンロックする必要があります。

すべてのビットが定義されているわけではありません。今後、新しい機能が追加されるかもしれません。32ビットすべてを設定すると、不安定な機能が有効化され、画面のチラツキやサスペンドからの復帰に失敗するなどの問題が発生する場合があります。デフォルトの ppfeaturemask と共に PP_OVERDRIVE_MASK ビット (0x4000) を設定すれば十分なはずです。あなたのシステムにおいて適切なパラメータを計算するには、以下を実行してください:

$ printf 'amdgpu.ppfeaturemask=0x%x\n' "$(($(cat /sys/module/amdgpu/parameters/ppfeaturemask) | 0x4000))"

==== 手動 ====

{{Note|sysfs では、{{ic|/sys/class/drm/...}} のようなパスはただのシンボリックリンクで、起動するごとに変化するかもしれません。永続的なパスは {{ic|/sys/devices/}} にあります (例: {{ic|/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/}})。信頼性の高い結果を得るには、コマンドを適宜調整してください。}}

利用可能なオプションに関する詳細は、カーネルドキュメントの [https://docs.kernel.org/gpu/amdgpu/thermal.html#pp-od-clk-voltage amdgpu サーマルコントロール]に関する部分を読んでください。

手動オーバークロックを有効にするには、[[#パフォーマンスレベル]] で説明されているように {{ic|manual}} パフォーマンスレベルを選択してください。

例えば、Polaris GPU で最大 P-state 7 で GPU クロックを 1209MHz、電圧を 900mV に設定するには、以下を実行してください:

# echo "s 7 1209 900" > /sys/class/drm/card0/device/pp_od_clk_voltage

同じ手順を VRAM に対しても適用できます (例えば、Polaris 5xx シリーズカードでの最大 P-state 2):

# echo "m 2 1850 850" > /sys/class/drm/card0/device/pp_od_clk_voltage

{{Warning|入力した値をダブルチェックしてください。間違うと即座にハードウェアに深刻なダメージを引き起こすかもしれません!}}

適用するには:

# echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage

機能していることを確認するには、3D の負荷をかけている状態で、クロックと電圧を見てください:

# watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info

以下でデフォルトの値にリセットできます:

# echo "r" > /sys/class/drm/card0/device/pp_od_clk_voltage

例えば、超省電力 P-state における (画面のちらつきやカクつきなどの) 問題を回避した場合などは、ドライバが特定の P-state へ切り替えるのを禁止することも可能です。最も高い VRAM P-state を強制し、GPU 自体は引き続き低いクロックで動作できるようにするには、まず利用可能な最も高い P-state を調べ、それを設定してください:

{{hc|$ cat /sys/class/drm/card0/device/pp_dpm_mclk|
0: 96Mhz *
1: 456Mhz
2: 675Mhz
3: 1000Mhz
}}

# echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
# echo "3" > /sys/class/drm/card0/device/pp_dpm_mclk

上位3つの GPU P-state のみを許可するには:

# echo "5 6 7" > /sys/class/drm/card0/device/pp_dpm_sclk

GPU の最大電力消費量を設定するには (例えば 50 ワット):

# echo '''50'''000000 > /sys/class/drm/card0/device/hwmon/hwmon0/power1_cap

{{Note|上記の手順は Polaris RX 560 カードでテストされました。別の GPU では、異なる挙動やバグが存在するかもしれません。}}

==== アシスト付き ====

GPU を手動でオーバークロックしたくない場合、AMD GPU のオーバークロックやモニタリングをアシストするいくつかのツールがコミュニティによって提供されています。

===== CLI ツール =====

* {{App|amdgpu-clocks|AMD GPU のモニタリングやカスタムの P-state を設定するために使用できるスクリプト。起動時に自動的に設定を適用する systemd サービスもあります。|https://github.com/sibradzic/amdgpu-clocks|{{AUR|amdgpu-clocks-git}}}}
* {{App|ruby-amdgpu_fan|amdgpu Linux ドライバと対話するための Ruby で書かれた CLI ツール|https://github.com/HarlemSquirrel/amdgpu-fan-rb|{{AUR|ruby-amdgpu_fan}}}}

===== GUI ツール =====

* {{App|TuxClocker|Qt5 のモニタリング・オーバークロックツール|https://github.com/Lurkki14/tuxclocker|{{AUR|tuxclocker}}}}
* {{App|CoreCtrl|アプリケーション毎のプロファイルをサポートする、WattMan ライクな UI の GUI オーバークロックツール。|https://gitlab.com/corectrl/corectrl|{{Pkg|corectrl}}}}
* {{App|LACT|AMD GPU の情報を見たり制御したりするための GTK ツール。|https://github.com/ilya-zlobintsev/LACT|{{Pkg|lact}}}}
* {{App|Radeon Profile|AMD Radeon カードの現在のクロックを読み込んだり変更したりする Qt5 ツール。|https://github.com/emerge-e-world/radeon-profile|{{AUR|radeon-profile-git}}}}

==== ブート時のスタートアップ ====

方法としては、一つは systemd ユニットを使うことです。起動時に設定を自動的に適用したい場合、起動時に設定を構成・適用することに関するこの [https://www.reddit.com/r/Amd/comments/agwroj/how_to_overclock_your_amd_gpu_on_linux/ Reddit スレッド]を見てみることを検討してください。

もう一つの方法は udev ルールです。例えば、パフォーマンスレベルを落とす値を設定して電力消費量を削減するには:

{{hc|/etc/udev/rules.d/30-amdgpu-low-power.rules|2=
ACTION=="add", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="low"
}}

=== パフォーマンスレベル ===

AMDGPU にはいくつかのパフォーマンスレベルがあります。このレベルは power_dpm_force_performance_level ファイルで調整/確認することができます。以下のレベルから選択できます:

* '''auto''': 現在の条件に合わせて、ドライバー内で最適な電源プロファイルを動的に選択します。
* '''low''': クロック数は最低のパワーステートに強制されます。
* '''high''': クロック数は最高のパワーステートに強制されます。
* '''manual''': ユーザーは、各クロックドメインに対してどのパワーステートを有効化するかを手動で選択することができます ([[#電源プロファイル]]を設定する際に使用します)。
* '''profile_standard'''、'''profile_min_sclk'''、'''profile_min_mclk'''、'''profile_peak''': クロックとパワーのゲーティングが無効化され、クロックはそれぞれのプロファイルに応じて設定されます。このモードは、特定のワークロードに対してプロファイルする際に推奨されます。

以下のコマンドを実行すると、AMDGPU デバイスをパフォーマンスレベル low に設定します:

# echo "low" > /sys/class/drm/card0/device/power_dpm_force_performance_level

{{Note|パフォーマンスレベルは起動のたびに再設定する必要があります。設定を自動化する方法は [[#ブート時のスタートアップ]] を見てください。}}

=== 電源プロファイル ===

AMDGPU は電源プロファイルによるいくつかの最適化を提供します。最も一般的に使用されるのは、OpenCL を多用するアプリケーションのためのコンピュートモードです。利用可能な電源プロファイルは以下のように一覧表示できます:

{{hc|$ cat /sys/class/drm/card0/device/pp_power_profile_mode|
NUM MODE_NAME SCLK_UP_HYST SCLK_DOWN_HYST SCLK_ACTIVE_LEVEL MCLK_UP_HYST MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL
0 BOOTUP_DEFAULT: - - - - - -
1 3D_FULL_SCREEN: 0 100 30 0 100 10
2 POWER_SAVING: 10 0 30 - - -
3 VIDEO: - - - 10 16 31
4 VR: 0 11 50 0 100 10
5 COMPUTE *: 0 5 30 10 60 25
6 CUSTOM: - - - - - -
}}

{{Note|{{ic|card0}} はマシンの特定の GPU を示します。複数の GPU が搭載されている場合、正しい GPU を選ぶように気をつけてください。}}

特定の電源プロファイルを使用するには、まず GPU のマニュアルコントロールを有効化する必要があります:

# echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level

その後、電源プロファイルを選択するには、そのプロファイルと関連付けられた NUM の値を書き込みます。例えば、COMPUTE を有効化するには:

# echo "5" > /sys/class/drm/card0/device/pp_power_profile_mode

電源プロファイルの正確な値と制限は、''powerplay table'' システムを通して管理されています。サポートされているモデル (Polaris から Navi2x まで。Navi3x と Navi4x はカーネルにバグがあります。) でこのテーブルを変更するには {{AUR|upliftpowerplay}} を使用してください。

{{Note|電源プロファイルの変更は起動するたびに適用する必要があります。これを自動化するには [[#ブート時のスタートアップ]] を見てください。}}

=== GPU ディスプレイスケーリングを有効化 ===

モニタのネイティブ解像度を使用しない場合、ディスプレイに内蔵されているスケーラを用いずに、GPU 自体のスケーラを使うには、以下を実行してください:
$ xrandr --output ''output'' --set "scaling mode" ''scaling_mode''

{{ic|"scaling mode"}} に利用できる値は: {{ic|None}}, {{ic|Full}}, {{ic|Center}}, {{ic|Full aspect}}。

* 利用可能な出力と設定を表示するには: {{bc|$ xrandr --prop}}
* 利用可能な全ての出力に {{ic|1=scaling mode = Full aspect}} を設定するには: {{bc|$ for output in $(xrandr --prop {{!}} grep -E -o -i "^[A-Z\-]+-[0-9]+"); do xrandr --output "$output" --set "scaling mode" "Full aspect"; done}}

=== ヘッドレス環境での仮想ディスプレイ ===

AMDGPU はヘッドレス環境向けに、ダミープラグを使用しない、GPU アクセラレートされた仮想モニターを提供しています。これは RDP や {{AUR|sunshine}} といったゲームストリーミングソフトウェアで便利です。

使用する AMD GPU を選択してください:

{{hc|$ lspci -Dd ::03xx|
'''1234:56:78.9''' VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] ''CommercialModelName''
}}

{{ic|amdgpu}} に対して {{ic|1=virtual_display=''1234:56:78.9'',''x''}} [[カーネルモジュールパラメータ]]を追加してください。{{ic|''1234:56:78.9''}} の部分は GPU の PCI アドレスで、{{ic|''x''}} は公開する crtc (仮想モニター) の番号です。このパラメータを使用すると物理出力は無効化されます。[https://bugzilla.kernel.org/show_bug.cgi?id=203339]

以下のように PCI アドレスをセミコロンで区切ることで、複数の GPU を使用することも可能です:

amdgpu.virtual_display=1234:56:78.9,''x'';9876:54:32.1,''y''

=== ユーザーキュー ===

AMDGPU ドライバはユーザーキューをサポートしています。これにより、カーネルドライバのコマンドサブミッション ioctl を介さずに、ジョブを直接 GPU ハードウェアにサブミットすることができます。
この機能を有効化することで、カーネルドライバのオーバヘッドがいくらか回避され、レイテンシを軽減し効率を向上させることができます。

ユーザーキューを有効化するには、以下の環境変数を設定してください:

export AMD_USERQ=1

=== SDMA による転送のみの専用キュー ===

Mesa 26.0 にマージされたコードは、GFX9 (Vega) 及びそれより新しい GPU で動作する、RADV の専用転送キューのサポートが含まれています。現在、この機能を有効化するには {{ic|RADV_PERFTEST{{=}}transfer_queue}} [[環境変数]]を設定する必要があります。DXVK Direct3D-on-Vulkan レイヤーは、Vulkan の転送キューのサポートを活用するためにソフトウェアないに存在しています。しかし、この新しい機能を正当化するようなパフォーマンス/ベンチマークの数値が[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25594 マージリクエスト]には含まれていません。

== トラブルシューティング ==

=== モジュールパラメータ ===

amdgpu モジュールは、いくつかの設定パラメータ ({{ic|modinfo amdgpu {{!}} grep mask}}) を[https://raw.githubusercontent.com/torvalds/linux/master/drivers/gpu/drm/amd/include/amd_shared.h カーネルのソースコード]でしかドキュメント化していないマスク内に隠しています。

=== Xorg やアプリケーションが起動しない ===

* ''glxgears'' を開いた後に "(EE) AMDGPU(0): [DRI2] DRI2SwapBuffers: drawable has no back or front?" エラー。Xorg サーバを開くことはできるが、OpenGL アプリケーションはクラッシュする。
* "(EE) AMDGPU(0): Given depth (32) is not supported by amdgpu driver" エラー。Xorg が起動しない。

Xorg でスクリーンの色深度を 16 か 32 に設定すると問題/クラッシュを引き起こします。これを防ぐには、"screen" セクションに以下を追加して標準的なスクリーン色深度である 24 を使う必要があります:

{{hc|/etc/X11/xorg.conf.d/10-screen.conf|
Section "Screen"
Identifier "Screen"
DefaultDepth 24
SubSection "Display"
Depth 24
EndSubSection
EndSection
}}

=== スクリーンのアーティファクトと周波数の問題 ===

[[ATI#動的電源管理|動的電源管理]]は、(60Hz以上の) 高いリフレッシュレートでモニタを表示させた際にスクリーンのアーティファクトを発生させる場合があります。GPU のクロック速度の管理法に問題があるためです [https://bugs.freedesktop.org/show_bug.cgi?id=96868][https://gitlab.freedesktop.org/drm/amd/-/issues/234]。

回避策[https://bugs.freedesktop.org/show_bug.cgi?id=96868#c13]は、[[#パフォーマンスレベル]] で説明されているようにパフォーマンスレベルを {{ic|high}} あるいは {{ic|low}} に設定することです。

カーネルのバージョンを変更することでもこの問題を解決できる場合があります。例えば、バージョン 6.12.9 では問題は解決されているようです。

==== Chromium でアーティファクト ====

[[Chromium]] でアーティファクトが現れる場合、vulkan ベースのバックエンドの使用を強制すると解決するかもしれません。{{ic|chrome://flags}} を開き、{{ic|#ignore-gpu-blocklist}} と {{ic|#enable-vulkan}} を ''enable'' にしてください。

=== R9 390 シリーズで悪いパフォーマンス/不安定 ===

AMD R9 390 シリーズのグラフィックカードで問題[https://gitlab.freedesktop.org/mesa/mesa/-/issues/1222]が発生する場合、次の[[カーネルパラメータ]]を設定して、radeon ではなく amdgpu ドライバの使用を強制してください: {{ic|1=radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1 amdgpu.dc=1}}

これがうまく行かない場合、DPM を無効化すると解決するかもしれません。次を[[カーネルパラメータ]]に追加してください: {{ic|1=radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1}}

=== "[drm] IP block:gmc_v8_0 is hung!" カーネルエラーでフリーズ ===

GPU が大量の処理を行っている最中にフリーズやカーネルのクラッシュが発生して、"[drm] IP block:gmc_v8_0 is hung!" カーネルエラーが発生する場合 [https://gitlab.freedesktop.org/drm/amd/issues/226]、回避策は [[カーネルパラメータ]] {{ic|1=amdgpu.vm_update_mode=3}} を設定して GPUVM ページテーブルの更新を CPU を用いて行うように強制することです。デメリットはここにリストされています: [https://gitlab.freedesktop.org/drm/amd/-/issues/226#note_308665]。

=== 画面が白く/灰色に点滅する ===

解像度を変更したり外部モニタに接続したりしたときに、画面がちらつく、あるいは白くなったままになる場合、[[カーネルパラメータ]] {{ic|1=amdgpu.sg_display=0}} を追加してください。

=== Vega カード上でのゲーム中にシステムのフリーズ/クラッシュ ===

[[ATI#動的電源管理|動的電源管理]]は、ゲーム中にシステムの完全なフリーズを発生させる場合があります。GPU のクロック速度の管理法に問題があるためです [https://gitlab.freedesktop.org/drm/amd/-/issues/716]。回避策は、[[#パフォーマンスレベル]] で説明されているようにパフォーマンスレベルを {{ic|high}} に設定することです。。

=== WebRenderer (Firefox) の破損 ===

[[:en:Firefox/Tweaks#WebRender|WebRenderer]] がユーザによって強制的に有効化されている場合、アーティファクトやその他の異常が発生する場合があります(例: 拡張機能のオプションを選択できないなど)。回避策は OpenGL コンポジットにフォールバックすることです。

=== 4K@60Hz のデバイスが接続されると音声の速度が2倍になる/音が高くなる/無音 ===

これは、AMDGPU デバイスと、HDMI で接続された 4K ディスプレイとの間の通信の問題により時々発生します。利用可能な回避策は、ディスプレイの組み込み設定から HDR か "Ultra HD Deep Color" を有効化することです。多くの Android ベースのテレビでは、これは "Optimal" ではなく "Standard" を設定することを意味します。

=== ディスクリート amdgpu グラフィックカードにおける電源管理/動的再アクティブ化の問題 ===

カーネルドライバはロードされたが、ゲームでディスクリートグラフィックカードを利用できない、または使用中に無効化されてしまう問題が発生する場合 ([https://gitlab.freedesktop.org/drm/amd/-/issues/1820] に似た問題)、[[カーネルパラメータ]] {{ic|1=amdgpu.runpm=0}} を設定することでこの問題を回避できます。このカーネルパラメータは、dGPU が実行時に動的にオフになることを防止します。

=== ディスプレイが固まる、または応答しなくなる (flip_done timed out) ===

amdgpu ドライバのバグにより、ディスプレイが更新されなくなることがあります[https://gitlab.freedesktop.org/drm/amd/-/issues/4141]。回避策として、{{ic|1=amdgpu.dcdebugmask=0x10}} か {{ic|1=amdgpu.dcdebugmask=0x12}} [[カーネルパラメータ]]を追加することが提案されています。

=== kfd が初期化に失敗する ===

GPU のアーキテクチャによっては、kfd が初期化に失敗することがあります。gfx803 (GCN 4) は PCIe atomics のサポートを必要とします。一方、gfx9xx (Vega) 及びそれ以降のデバイスは、PCIe atomics が必要ありません。kfd は GCN 3 及びそれより古いデバイスをサポートしていません。

[[GPGPU#ROCm|ROCm]] を使用するつもりがないならば、このエラーは安全に無視できます。

==== "[GPU Core Name] not supported in kfd" ====

システムのジャーナルやカーネルのメッセージに、kfd 関連の critical レベルのエラーメッセージが現れることがあります:

{{hc|# dmesg {{!}} grep kfd|
kfd kfd: amdgpu: BONAIRE not supported in kfd
}}

(BONAIRE の部分は GPU 内のコアの名前によって変わります (TOPAZ、HAWAII など)。コア名は GPU を見たり、{{pkg|amdgpu_top}} などのGPU の診断ユーティリティを使うことで分かります。)

このエラーは、kfd は使用中の GPU をサポートしておらず、ROCm で動作しないことを意味しています。[https://github.com/RadeonOpenCompute/ROCm/issues/1148#issuecomment-747849592][https://www.reddit.com/r/linuxquestions/comments/yhbbiz/kfd_kfd_amdgpu_topaz_not_supported_in_kfd/]

==== "PCI rejects atomics" ====

GCN 4 GPU では、CPU が PCIe atomics をサポートしている必要があり、GPU のあるスロットは少なくとも PCIe 3.0 をサポートしている必要があります。[https://github.com/ROCm/ROCm/issues/2224#issuecomment-2299689450] これらの要件が満たされない場合、以下のメッセージが出力されます:

{{hc|# dmesg {{!}} grep kfd|
kfd kfd: amdgpu: skipped device 1002:67e3, PCI rejects atomics 730<0
}}

使用中の CPU が PCIe atomics をサポートしているかどうかは、以下のコマンドで分かります:

grep flags /sys/class/kfd/kfd/topology/nodes/*/io_links/0/properties

使用中の CPU が PCIe atomics をサポートしている (つまり、先の出力が {{ic|1}}) がエラーが発生する場合、GPU のあるスロットを変更してください。そのスロットは、CPU からではなく、チップセットから来ているレーンなのかもしれません。

=== MCLK が MAX (1000Mhz) に固定されてアイドル時に高い電力消費、または MIN (96MHz) に固定されてゲームのパフォーマンスが悪化 (カーネル 6.4) ===

高解像度かつ高リフレッシュレートの場合、MCLK (vram / メモリのクロック) が最も高いクロックレート (1000MHz) に固定されてしまい [https://gitlab.freedesktop.org/drm/amd/-/issues/1403] [https://gitlab.freedesktop.org/drm/amd/-/issues/2646]、アイドル時に GPU の電力消費が増加してしまう場合があります。Linux カーネル 6.4.x では、MCLK クロックが最低値 (96MHz) になって、ゲームのパフォーマンスが低下してしまいます [https://gitlab.freedesktop.org/drm/amd/-/issues/2657] [https://gitlab.freedesktop.org/drm/amd/-/issues/2611]。

これは、モニタが Coordinated Video Timings (CVT) を使用しておらず、影響を受ける解像度とリフレッシュレートに対する V-Blank 値が低いことが原因である可能性があります。回避策は[https://gist.github.com/Rend0e/3bddac4285dc1f4fbe303f326f36f6cc この gist] を見てください。

=== Suspend to RAM に失敗する ===

十分にリフレッシュされない VRAM のデータ消失を防ぐために、{{ic|amdgpu}} カーネルモジュールはシステムが S3 スリープに入るときに VRAM の内容を RAM 内に保存します。

大量の VRAM を使用していて RAM に十分な空き容量がない場合、たとえ十分なスワップメモリが存在していたとしても、[https://gitlab.freedesktop.org/drm/amd/-/issues/2125 このプロセスが失敗する可能性があります] (IO サブシステムがすでにサスペンドされているかもしれないため)。

このとき、以下のようなメッセージが出力されます:

kernel: systemd-sleep: page allocation failure: order:0, mode:0x100c02(GFP_NOIO|__GFP_HIGHMEM|__GFP_HARDWALL), nodemask=(null),cpuset=/,mems_allowed=0
kernel: Call Trace:
kernel: <TASK>
kernel: dump_stack_lvl+0x47/0x60
kernel: warn_alloc+0x165/0x1e0
kernel: __alloc_pages_slowpath.constprop.0+0xd7d/0xde0
kernel: __alloc_pages+0x32d/0x350
kernel: ttm_pool_alloc+0x19f/0x600 [ttm 0bd92a9d9dccc3a4f19554535860aaeda76eb4f4]

回避策としては、システムがサスペンドする前に十分な RAM 領域をスワップアウトして VRAM を格納できるのに十分な空き領域を RAM に確保しておく[https://git.dolansoft.org/lorenz/memreserver ユーザー空間のサービス]を使うというものがります。

=== 間違った GPU クロックにより複数の問題が発生する ===

{{Accuracy|
* Users provide unreliable reports and operate under wrong assumptions. See [https://gitlab.freedesktop.org/drm/amd/-/issues/3131#note_3007563 explanation].
* If you carefully read through the related issues, the problem appear to be caused by some internal setup of GPU power profiles. Which means the shader clock frequency is not the actual issue here, lowering it is more of a workaround, and it decreases performance.
* Patches addressing the problem were already merged a few major kernel releases back.
* If you are still getting crashes with similar dmesg logs, consider disabling GFXOFF (see [https://gitlab.freedesktop.org/drm/amd/-/issues/3067#note_2959002])
}}

amdgpu モジュールにはバグがあり、ビデオコアの周波数が製造業者によって設定された値よりも高くなることがあります。これにより、ゲーム中やスリープからの復帰時、再起動時にシステムが不安定になることがあります。

この問題は、RDNA 3 GPU (7XXX モデル) で報告されています[https://www.reddit.com/r/linux_gaming/comments/1dyhizb/fyi_for_amd_card_owners_the_linux_kernel_is/] [https://wiki.gentoo.org/wiki/AMDGPU#Frequent_and_Sporadic_Crashes] [https://gitlab.freedesktop.org/drm/amd/-/issues/3131]。

dmesg に以下のようなログが出てきます:

amdgpu: [gfxhub] page fault (src_id:0 ring:40 vmid:6 pasid:32830)
amdgpu: in process GameThread pid 100056 thread vkd3d_queue pid 100468)
amdgpu: in page starting at address 0x0000000218a36000 from client 10
amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00641051
amdgpu: Faulty UTCL2 client ID: TCP (0x8)
amdgpu: MORE_FAULTS: 0x1
amdgpu: WALKER_ERROR: 0x0
amdgpu: PERMISSION_FAULTS: 0x5
amdgpu: MAPPING_ERROR: 0x0
amdgpu: RW: 0x1

似たような問題が発生する場合は、システムのビデオコアの最大周波数と製造業者の公式の周波数とを比較してください。最大周波数を下げる方法は、[[#オーバークロック]] を見てください。

=== AMD の専用 GPU の HDMI が Wayland でフリーズする ===

具体例として、AMD CPU と専用 AMD GPU を搭載している ASUS G14 2022 ノート PC があります。最も成功しやすい方法では、dGPU Ultimate power オプションを強制するために Windows で armor crate を使う必要があります。これにより、GPU の順序とノート PC の内部電源ポリシーが切り替わります。これにより HDMI が機能するようになるはずですが、統合 GPU (SDDM と Wayland はこちらをデフォルトで選択します) と専用 GPU とでレンダリングが別々になります。アプリケーションの起動前に {{ic|1=DRI_PRIME=0}} 環境変数を設定することでレンダリングを行う GPU を選択できますが、これは簡便ではありません。以下のように設定を変更することで環境変数を設定できますが、バッテリー駆動時にバッテリーの持ちが悪くなります:

{{hc|/etc/sddm.conf.d/hardware.conf|2=
[General]
DisplayServer=wayland
[Wayland]
CompositorCommand=kwin_wayland --drm --no-lockscreen --no-global-shortcuts
Environment=DRI_PRIME=0
}}

これに加えて、以下のカーネルパラメータを追加する必要があります:

amdgpu.runpm=0 amdgpu.modeset=1

=== ノート PC で色があせて薄い ===

{{Pkg|power-profiles-daemon}} や {{Pkg|tuned}} などの省電力アプリケーションは、Panel Power Savings (PPS) として知られる機能を[https://www.phoronix.com/news/Power-Profiles-Daemon-0.20 有効にする]ようになりました。

PPS はノート PC でサポートされている機能で、ノート PC の GPU に色精度を犠牲にする代わりに省電力にするように命令します。しかし、この機能を使うと、前述の power-profiles-daemon や tuned でより強力な省電力モードを選択すると色があせてしまう傾向にあります。そのため、この機能を完全に無効化する人もいます。

以下の[[カーネルパラメータ]]をゼロに設定することで無効化できます:

amdgpu.abmlevel=0

=== アイドル時にシステムがフリーズしたり再起動したりする ===

いくつかの PowerPlay 機能 ([https://www.phoronix.com/news/AMDGPU-GFXOFF-Patches GFXOFF] など) の問題により、高頻度の回復不可能なドライバのクラッシュが発生することがあります[https://forum.endeavouros.com/t/random-crashes-amdgpu/70453]。これは、複数モニターの環境で GPU のアイドル時、とくにスリープモードからの復帰時に発生します。

よく知られた解決法は、([[#ブートパラメータ]] で説明されているように) PP_GFXOFF_MASK を無効化するカーネルパラメータを追加することです (例: {{ic|1=amdgpu.ppfeaturemask=0xffff7fff}}。これは、他の PowerPlay 機能 (実装されているものも未実装のものも含む) を有効化したままにします)。

もう一つの方法は、GFXOFF 以外の機能も無効化する方法を利用することです:

* {{ic|0xfffd7fff}} で [https://www.reddit.com/r/linux4noobs/comments/1ahb8pf/comment/koppio6/ PP_GFXOFF_MASK と PP_STUTTER_MODE] を無効化する。
* {{ic|0xfffd3fff}} で [https://forum.endeavouros.com/t/random-crashes-amdgpu/70453/7?u=krzeszny PP_GFXOFF_MASK、PP_STUTTER_MODE、PP_OVERDRIVE_MASK] を無効化する。
* {{ic|0xfff73fff}} で [https://forum.endeavouros.com/t/random-crashes-amdgpu/70453/15?u=krzeszny PP_GFXOFF_MASK、PP_GFX_DCS_MASK、PP_OVERDRIVE_MASK] を無効化する。
* {{ic|0}} (あるいは {{ic|0x0}}) で全ての機能を無効化する。ドライバのクラッシュの原因が分からない場合はこれを使うことができます。

[https://miniwebtool.com/bitwise-calculator/?data_type=16&number1=ffffffff&number2=8000&operator=XOR 16進数のビット計算機] (リンク先に例あり) で計算して、{{ic|1=amdgpu.ppfeaturemask=0x}} の後にその計算した8文字のマスクを加えることで自分で機能マスクを作ることができます。{{ic|ffffffff}} (全ビット1) から初めて、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/include/amd_shared.h#n185 マスクしたい機能]を '''XOR''' してください。計算結果に機能を XOR していくことができます。最初のゼロでない文字は全て省略できます。例えば、0x8000 と 0x00008000 は等価です。

カーネルの更新時にパラメータが消されないように注意してください。

=== HDMI 4K が 120Hz までしか上がらない ===

[https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected ライセンス上の問題]により、{{pkg|mesa}} ドライバは HDMI 2.1 をサポートできません。DisplayPort を使う必要があります。ディスプレイが DisplayPort をサポートしていない場合、DisplayPort の入力を HDMI 2.1 の信号に変換する[https://www.reddit.com/r/linux_gaming/comments/1nh5y0f/hdmi_21_works_on_amd_gpu_with_this_converter/ コンバータを使って HDMI 2.1 を使うことができたというユーザがいます]。

== 参照 ==

* [[Gentoo:AMDGPU]]
* [https://gitlab.freedesktop.org/drm/amd AMDGPU イシュートラッカー]

{{TranslationStatus|AMDGPU|2026-02-14|862509}}

画像処理装置

2026-02-13T05:25:17Z

AshMyzk: 修正

[[Category:グラフィックス]]
[[en:Graphics processing unit]]
{{Related articles start}}
{{Related|NVIDIA}}
{{Related|AMDGPU}}
{{Related|Intel}}
{{Related|Wayland}}
{{Related|Xorg}}
{{Related|OpenGL}}
{{Related|Vulkan}}
{{Related|ハードウェアビデオアクセラレーション}}
{{Related|外付け GPU}}
{{Related articles end}}

[[Wikipedia:ja:GPU|画像処理装置]] (GPU) とは、ディスプレイに表示されるビデオフィードを生成する、コンピュータ内のハードウェアです。GPU には、[[Wikipedia:GPU#統合GPU|Integrated Graphics Processors]] (IGP) と専用 GPU (ディスクリート GPU) の2種類があります。特に、後者は[[Wikipedia:ja:グラフィックスカード|グラフィックスカード]]とも呼ばれています。この頭字語は、グラフィックスカード全てを指す言葉としてしばしば用いられます。

GPU は並列計算を得意とするので、[[GPGPU|GPUによる汎用計算]] (GPGPU) にも用いられています。

== インストール ==

Linux カーネルには、オープンソースのビデオドライバが含まれており、ハードウェアアクセラレーション付きのフレームバッファをサポートしています。しかし、[[OpenGL]]、[[Vulkan]]、[[Xorg]] における 2D アクセラレーション、そして[[ハードウェアビデオアクセラレーション]]に関しては、ユーザランドでのサポートが必要です。

まず、使用しているグラフィックスカードを確認してください (''Subsystem'' の部分に固有モデルが表示されます):

$ lspci -vnnd ::03xx

{{Tip|{{ic|::03}} は「[https://admin.pci-ids.ucw.cz/read/PD/03 ディスプレイコントローラ] PCI デバイスクラス」を意味し、{{ic|xx}} は「そのクラス内の全てのサブクラス」を意味します。}}

次に、対応するビデオドライバをインストールする必要があります。以下の表に代表的なベンダー3社が挙げられています。

32ビットのソフトウェアに関しては、[[multilib]] リポジトリを有効化し、''lib32-'' という接頭辞がついたユーザ空間のドライバをインストールしてください (例えば、{{Pkg|lib32-mesa}}、{{Pkg|lib32-vulkan-radeon}}、{{Pkg|lib32-nvidia-utils}} などです)。

X11 に関しては、他の [https://dri.freedesktop.org/wiki/DDX/ Device Dependent X (DDX)] ドライバは、{{Grp|xorg-drivers}} パッケージグループからインストールするか、[https://aur.archlinux.org/packages?K=xf86-video xf86-video] で検索して特定のパッケージをインストールすることができます。ほとんどの場合、DDX ドライバをインストールする必要はありません。詳細は、[[Xorg#ドライバ]] を見てください。

=== AMD ===

AMD はオープンソースのドライバをサポートしています。かつてプロプライエタリなドライバが提供されていましたが、もはやパッケージは存在しません。[https://www.amd.com/en/resources/support-articles/release-notes/RN-AMDGPU-UNIFIED-LINUX-25-10-1.html][https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/P5XHCIBVBY7PBPUC7AV3QD4CTROCRYSG/#KPTEHMZ2GPTRMXR37D25HJ4HY2KYPVKJ]

{{Tip|モデルネーム (例: ''Radeon RX 6600'') を GPU ファミリ (例: ''RDNA 2'') に読み替えるには、[[Wikipedia:List of AMD graphics processing units#Features overview]] を見てください。}}

GPU ファミリ毎の [[VA-API]] のサポートに関しては、[[ハードウェアビデオアクセラレーション#比較一覧]] を見てください。

{| class="wikitable" style="text-align:center"
|-
! ドキュメント
! GPU ファミリ
! DRM ドライバ
! OpenGL
! Vulkan
! DDX ドライバ
|-
| [[AMDGPU]]
| GCN 3 及びそれ以降 (例: RDNA 1-4)
| rowspan="4" | [[Linux]] に同梱
| rowspan="3" | {{Pkg|mesa}}
| {{Pkg|vulkan-radeon}}
| {{Pkg|xf86-video-amdgpu}}2
|-
| [[AMDGPU]]1 / [[ATI]]
| GCN 1&2
| colspan="2" | 使用するドライバによる
|-
| rowspan="3" | [[ATI]]
| R300 から TeraScale まで
| rowspan="2" | 無し
| rowspan="2" | {{Pkg|xf86-video-ati}}2
|-
| R100 & R200
| {{Pkg|mesa-amber}}
|-
| Rage 4 及びそれ以前
| colspan="5" | 利用できません [https://www.x.org/wiki/RadeonFeature/][https://www.phoronix.com/news/Linux-6.3-Dropping-Old-DRM]
|}

# {{Pkg|linux}} ≥ 6.19 でデフォルトで有効化されています。それ以外のバージョンでは、手動で選択できます。
# 問題なく動作させるには、modesetting ドライバを使用する必要があります。

=== Intel ===

Intel は、オープンソースドライバを提供しており、かつサポートしています。ただし、PowerVR ベースのグラフィックス (GMA 3600 シリーズ) はサポートされていません。

{{Tip|Intel の ''N'' 世代ハードウェアという文言は、CPU の世代ではなく、[[Wikipedia:List of Intel graphics processing units|GPU の世代]]を指しています。これは、CPU の世代とは異なります。}}

GPU ファミリ毎の [[VA-API]] のサポートに関しては、[[ハードウェアビデオアクセラレーション#比較一覧]] を見てください。以下は、パッケージのみを記載しています。

{| class="wikitable" style="text-align:center"
|-
! ドキュメント
! GPU ファミリ
! DRM ドライバ
! OpenGL
! Vulkan
! DDX ドライバ
! VA-API
|-
| rowspan="6" | [[Intel graphics]]
| 第12.1世代及びそれ以降
| rowspan="6" | [[Linux]] に同梱
| rowspan="5" | {{Pkg|mesa}}
| rowspan="3" | {{Pkg|vulkan-intel}}1
| rowspan="6" | {{Pkg|xf86-video-intel}}2
| {{pkg|intel-media-driver}}
|-
| 第8世代から第11世代まで
| {{pkg|intel-media-driver}} またはレガシーな {{pkg|libva-intel-driver}}
|-
| 第7世代 & 第7.5世代
| rowspan="2" |{{pkg|libva-intel-driver}}
|-
| 第5世代 & 第6世代
| rowspan="3" | 無し
|-
| 第3世代から第4.5世代まで
| rowspan="2" | 無し
|-
| 第2世代
| {{Pkg|mesa-amber}}
|}

# 第7世代と第7.5世代は[https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan_hasvk/anv_device.c#L1600 サポートが不完全で]、第8世代は Vulkan 1.3 に制限されています。
# 第3世代及びそれ以降のハードウェアでは、''modesetting'' DDX ドライバが推奨されています。詳細は [[インテルグラフィックス#インストール]] を見てください。

=== NVIDIA ===

NVIDIA は完全にオープンソースなドライバをサポートしていません。NVIDIA は2022年からハイブリッドなアプローチ (オープンな DRM ドライバとクローズドなユーザランドドライバ) を取り始めました。

{{Tip|モデルネーム (例: ''RTX 4060'') を GPU ファミリ (例: ''NV190'') に読み替えるには、[https://nouveau.freedesktop.org/CodeNames.html nouveau wiki のコードネームのページ]を見てください。}}

どの API がサポートされているかについては、[[ハードウェアビデオアクセラレーション#NVIDIA]] を見てください。GPU ファミリ毎の詳細は [[ハードウェアビデオアクセラレーション#VDPAU ドライバ]] を見てください。

{| class="wikitable" style="text-align:center"
|-
! ライセンス
! ドキュメント
! GPU ファミリ
! DRM ドライバ
! OpenGL
! Vulkan
! DDX ドライバ
|-
| rowspan="2" | オープン
| rowspan="2" | [[Nouveau]]1
| [https://nouveau.freedesktop.org/CodeNames.html#NVE0 Kepler (NVE0/GKXXX)] 及びそれより新しいもの
| rowspan="2" | [[Linux]] に同梱
| rowspan="2" | {{Pkg|mesa}}
| {{Pkg|vulkan-nouveau}}
| rowspan="2" | {{Pkg|xf86-video-nouveau}}2
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV04 Fahrenheit (NV04/05)] から [https://nouveau.freedesktop.org/CodeNames.html#NVC0 Fermi (NVC0/GF1XX)] まで
| 無し
|-
| オープンな DRM ドライバ、プロプライエタリなユーザランドドライバ
| rowspan="6" | [[NVIDIA]]1
| [https://nouveau.freedesktop.org/CodeNames.html#NV160 Turing (NV160/TUXXX)] 及びそれより新しいもの
| {{Pkg|nvidia-open}}
| colspan="3" | {{Pkg|nvidia-utils}}
|-
| rowspan="5" | プロプライエタリ
| [https://nouveau.freedesktop.org/CodeNames.html#NV110 Maxwell (NV110/GMXXX)] から [https://nouveau.freedesktop.org/CodeNames.html#NV190 Ada Lovelace (NV190/ADXXX)] まで
| {{AUR|nvidia-580xx-dkms}}
| colspan="3" | {{AUR|nvidia-580xx-utils}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVE0 Kepler (NVE0/GKXXX)]
| {{AUR|nvidia-470xx-dkms}}
| colspan="3" | {{AUR|nvidia-470xx-utils}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVC0 Fermi (NVC0/GF1XX)]
| {{AUR|nvidia-390xx-dkms}}
| {{AUR|nvidia-390xx-utils}}
| rowspan="2" | 無し
| {{AUR|nvidia-390xx-utils}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV50 Tesla (NV50/G80-90-GT2XX)]
| {{AUR|nvidia-340xx-dkms}}
| {{AUR|nvidia-340xx-utils}}
| {{AUR|nvidia-340xx-utils}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV40 Curie (NV40/G70)] 及びそれより古いもの
| colspan="6" | パッケージはもう存在しません
|}

# 専用 GPU と合わせて統合ビデオカードを使用する NVIDIA Optimus のあるノート PC については、[[NVIDIA Optimus]] を見てください。
# [https://nouveau.freedesktop.org/CodeNames.html#NV50 NV50 (G80)]及びそれ以降においては、''modesetting'' DDX ドライバが推奨されています。詳細は [[Nouveau#インストール]] を見てください。

== ロード ==

ほとんどのカーネルモジュールドライバは、システムのブート時に自動的にロードされるはずです。

ロードされない場合は:

# [[カーネルパラメータ]]に {{ic|nomodeset}} や {{ic|1=vga=}} が'''含まれていない'''ことを確認してください。ドライバは [[KMS]] を必要とするためです。
# また、[[カーネルモジュール#ブラックリスト|カーネルモジュールブラックリスト]]によってドライバが無効化されていないことを確認してください。

== モニタリング ==

GPU のモニタリングは、GPU の温度、コアと VRAM の使用量、P-state を確認するために行われます。

==== CLI ====

* {{App|amdgpu_top|AMDGPU の使用率を表示するツール|https://github.com/Umio-Yasuno/amdgpu_top|{{Pkg|amdgpu_top}}}}
* {{App|nvtop|AMD、Intel、NVIDIA 用の、GPU プロセスモニタリングツール|https://github.com/Syllo/nvtop|{{Pkg|nvtop}}}}
* {{App|radeontop|GPU 使用率ビューア。全体のアクティビティのパーセンテージと個々のブロックの両方を確認できます。ATI の R600 及びそれより新しい GPU、さらに [[AMDGPU]] ドライバを使用するカードで動作します。|https://github.com/clbr/radeontop|{{Pkg|radeontop}}}}
* {{App|nvidia-smi|NVIDIA のプロプライエタリドライバにバンドルされている、Fermi 及びそれより新しい [[NVIDIA]] GPU 用の CLI モニタリングツール。|https://docs.nvidia.com/deploy/nvidia-smi/index.html|{{pkg|nvidia-utils}}}}

==== GUI ====

* {{App|amdgpu_top|AMDGPU の使用率を表示するツール|https://github.com/Umio-Yasuno/amdgpu_top|{{Pkg|amdgpu_top}}}}
* {{App|AmdGuid|完全に Rust 製の基本的なファン制御 GUI。|https://github.com/Eraden/amdgpud|{{AUR|amdguid-wayland-bin}}, {{AUR|amdguid-glow-bin}}}}
* {{App|Radeon Profile|AMD Radeon カード現在のクロックを読み取ったり変更したりできる Qt5 ツール。|https://github.com/emerge-e-world/radeon-profile|{{AUR|radeon-profile-git}}}}
* {{App|TuxClocker|Qt5 のモニタリング及びオーバークロックツール|https://github.com/Lurkki14/tuxclocker|{{AUR|tuxclocker}}}}
* {{App|Plasma System Monitor|システムのセンサー、プロセス情報、他のシステムリソースをモニタリングするインターフェイス。[[KDE|KDE Plasma]] にバンドルされています。|https://apps.kde.org/plasma-systemmonitor/|{{pkg|plasma-systemmonitor}}}}
* {{App|LACT|Linux システムで AMD、NVIDIA、Intel GPU を制御できます。|https://github.com/ilya-zlobintsev/LACT|{{pkg|lact}}}}

{{TranslationStatus|Graphics processing unit|2026-02-13|859652}}

GPU

2026-02-13T05:24:57Z

AshMyzk: 画像処理装置への転送ページ

#REDIRECT [[画像処理装置]]

画像処理装置

2026-02-13T05:24:14Z

AshMyzk: 初版

[[Category:グラフィックス]]
[[en:Graphics processing unit]]
{{Related articles start}}
{{Related|NVIDIA}}
{{Related|AMDGPU}}
{{Related|Intel}}
{{Related|Wayland}}
{{Related|Xorg}}
{{Related|OpenGL}}
{{Related|Vulkan}}
{{Related|ハードウェアビデオアクセラレーション}}
{{Related|外付け GPU}}
{{Related articles end}}

[[Wikipedia:ja:GPU|画像処理装置]] (GPU) とは、ディスプレイに表示されるビデオフィードを生成する、コンピュータ内のハードウェアです。GPU には、[[Wikipedia:GPU#統合GPU|Integrated Graphics Processors]] (IGP) と専用 GPU (ディスクリート GPU) の2種類があります。特に、後者は[[Wikipedia:ja:グラフィックスカード]]とも呼ばれています。この頭字語は、グラフィックスカード全てを指す言葉としてしばしば用いられます。

GPU は並列計算を得意とするので、[[GPGPU|GPUによる汎用計算]] (GPGPU) にも用いられています。

== インストール ==

Linux カーネルには、オープンソースのビデオドライバが含まれており、ハードウェアアクセラレーション付きのフレームバッファをサポートしています。しかし、[[OpenGL]]、[[Vulkan]]、[[Xorg]] における 2D アクセラレーション、そして[[ハードウェアビデオアクセラレーション]]に関しては、ユーザランドでのサポートが必要です。

まず、使用しているグラフィックスカードを確認してください (''Subsystem'' の部分に固有モデルが表示されます):

$ lspci -vnnd ::03xx

{{Tip|{{ic|::03}} は「[https://admin.pci-ids.ucw.cz/read/PD/03 ディスプレイコントローラ] PCI デバイスクラス」を意味し、{{ic|xx}} は「そのクラス内の全てのサブクラス」を意味します。}}

次に、対応するビデオドライバをインストールする必要があります。以下の表に代表的なベンダー3社が挙げられています。

32ビットのソフトウェアに関しては、[[multilib]] リポジトリを有効化し、''lib32-'' という接頭辞がついたユーザ空間のドライバをインストールしてください (例えば、{{Pkg|lib32-mesa}}、{{Pkg|lib32-vulkan-radeon}}、{{Pkg|lib32-nvidia-utils}} などです)。

X11 に関しては、他の [https://dri.freedesktop.org/wiki/DDX/ Device Dependent X (DDX)] ドライバは、{{Grp|xorg-drivers}} パッケージグループからインストールするか、[https://aur.archlinux.org/packages?K=xf86-video xf86-video] で検索して特定のパッケージをインストールすることができます。ほとんどの場合、DDX ドライバをインストールする必要はありません。詳細は、[[Xorg#ドライバ]] を見てください。

=== AMD ===

AMD はオープンソースのドライバをサポートしています。かつてプロプライエタリなドライバが提供されていましたが、もはやパッケージは存在しません。[https://www.amd.com/en/resources/support-articles/release-notes/RN-AMDGPU-UNIFIED-LINUX-25-10-1.html][https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/P5XHCIBVBY7PBPUC7AV3QD4CTROCRYSG/#KPTEHMZ2GPTRMXR37D25HJ4HY2KYPVKJ]

{{Tip|モデルネーム (例: ''Radeon RX 6600'') を GPU ファミリ (例: ''RDNA 2'') に読み替えるには、[[Wikipedia:List of AMD graphics processing units#Features overview]] を見てください。}}

GPU ファミリ毎の [[VA-API]] のサポートに関しては、[[ハードウェアビデオアクセラレーション#比較一覧]] を見てください。

{| class="wikitable" style="text-align:center"
|-
! ドキュメント
! GPU ファミリ
! DRM ドライバ
! OpenGL
! Vulkan
! DDX ドライバ
|-
| [[AMDGPU]]
| GCN 3 及びそれ以降 (例: RDNA 1-4)
| rowspan="4" | [[Linux]] に同梱
| rowspan="3" | {{Pkg|mesa}}
| {{Pkg|vulkan-radeon}}
| {{Pkg|xf86-video-amdgpu}}2
|-
| [[AMDGPU]]1 / [[ATI]]
| GCN 1&2
| colspan="2" | 使用するドライバによる
|-
| rowspan="3" | [[ATI]]
| R300 から TeraScale まで
| rowspan="2" | 無し
| rowspan="2" | {{Pkg|xf86-video-ati}}2
|-
| R100 & R200
| {{Pkg|mesa-amber}}
|-
| Rage 4 及びそれ以前
| colspan="5" | 利用できません [https://www.x.org/wiki/RadeonFeature/][https://www.phoronix.com/news/Linux-6.3-Dropping-Old-DRM]
|}

# {{Pkg|linux}} ≥ 6.19 でデフォルトで有効化されています。それ以外のバージョンでは、手動で選択できます。
# 問題なく動作させるには、modesetting ドライバを使用する必要があります。

=== Intel ===

Intel は、オープンソースドライバを提供しており、かつサポートしています。ただし、PowerVR ベースのグラフィックス (GMA 3600 シリーズ) はサポートされていません。

{{Tip|Intel の ''N'' 世代ハードウェアという文言は、CPU の世代ではなく、[[Wikipedia:List of Intel graphics processing units|GPU の世代]]を指しています。これは、CPU の世代とは異なります。}}

GPU ファミリ毎の [[VA-API]] のサポートに関しては、[[ハードウェアビデオアクセラレーション#比較一覧]] を見てください。以下は、パッケージのみを記載しています。

{| class="wikitable" style="text-align:center"
|-
! ドキュメント
! GPU ファミリ
! DRM ドライバ
! OpenGL
! Vulkan
! DDX ドライバ
! VA-API
|-
| rowspan="6" | [[Intel graphics]]
| 第12.1世代及びそれ以降
| rowspan="6" | [[Linux]] に同梱
| rowspan="5" | {{Pkg|mesa}}
| rowspan="3" | {{Pkg|vulkan-intel}}1
| rowspan="6" | {{Pkg|xf86-video-intel}}2
| {{pkg|intel-media-driver}}
|-
| 第8世代から第11世代まで
| {{pkg|intel-media-driver}} またはレガシーな {{pkg|libva-intel-driver}}
|-
| 第7世代 & 第7.5世代
| rowspan="2" |{{pkg|libva-intel-driver}}
|-
| 第5世代 & 第6世代
| rowspan="3" | 無し
|-
| 第3世代から第4.5世代まで
| rowspan="2" | 無し
|-
| 第2世代
| {{Pkg|mesa-amber}}
|}

# 第7世代と第7.5世代は[https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan_hasvk/anv_device.c#L1600 サポートが不完全で]、第8世代は Vulkan 1.3 に制限されています。
# 第3世代及びそれ以降のハードウェアでは、''modesetting'' DDX ドライバが推奨されています。詳細は [[インテルグラフィックス#インストール]] を見てください。

=== NVIDIA ===

NVIDIA は完全にオープンソースなドライバをサポートしていません。NVIDIA は2022年からハイブリッドなアプローチ (オープンな DRM ドライバとクローズドなユーザランドドライバ) を取り始めました。

{{Tip|モデルネーム (例: ''RTX 4060'') を GPU ファミリ (例: ''NV190'') に読み替えるには、[https://nouveau.freedesktop.org/CodeNames.html nouveau wiki のコードネームのページ]を見てください。}}

どの API がサポートされているかについては、[[ハードウェアビデオアクセラレーション#NVIDIA]] を見てください。GPU ファミリ毎の詳細は [[ハードウェアビデオアクセラレーション#VDPAU ドライバ]] を見てください。

{| class="wikitable" style="text-align:center"
|-
! ライセンス
! ドキュメント
! GPU ファミリ
! DRM ドライバ
! OpenGL
! Vulkan
! DDX ドライバ
|-
| rowspan="2" | オープン
| rowspan="2" | [[Nouveau]]1
| [https://nouveau.freedesktop.org/CodeNames.html#NVE0 Kepler (NVE0/GKXXX)] 及びそれより新しいもの
| rowspan="2" | [[Linux]] に同梱
| rowspan="2" | {{Pkg|mesa}}
| {{Pkg|vulkan-nouveau}}
| rowspan="2" | {{Pkg|xf86-video-nouveau}}2
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV04 Fahrenheit (NV04/05)] から [https://nouveau.freedesktop.org/CodeNames.html#NVC0 Fermi (NVC0/GF1XX)] まで
| 無し
|-
| オープンな DRM ドライバ、プロプライエタリなユーザランドドライバ
| rowspan="6" | [[NVIDIA]]1
| [https://nouveau.freedesktop.org/CodeNames.html#NV160 Turing (NV160/TUXXX)] 及びそれより新しいもの
| {{Pkg|nvidia-open}}
| colspan="3" | {{Pkg|nvidia-utils}}
|-
| rowspan="5" | プロプライエタリ
| [https://nouveau.freedesktop.org/CodeNames.html#NV110 Maxwell (NV110/GMXXX)] から [https://nouveau.freedesktop.org/CodeNames.html#NV190 Ada Lovelace (NV190/ADXXX)] まで
| {{AUR|nvidia-580xx-dkms}}
| colspan="3" | {{AUR|nvidia-580xx-utils}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVE0 Kepler (NVE0/GKXXX)]
| {{AUR|nvidia-470xx-dkms}}
| colspan="3" | {{AUR|nvidia-470xx-utils}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVC0 Fermi (NVC0/GF1XX)]
| {{AUR|nvidia-390xx-dkms}}
| {{AUR|nvidia-390xx-utils}}
| rowspan="2" | 無し
| {{AUR|nvidia-390xx-utils}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV50 Tesla (NV50/G80-90-GT2XX)]
| {{AUR|nvidia-340xx-dkms}}
| {{AUR|nvidia-340xx-utils}}
| {{AUR|nvidia-340xx-utils}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV40 Curie (NV40/G70)] 及びそれより古いもの
| colspan="6" | パッケージはもう存在しません
|}

# 専用 GPU と合わせて統合ビデオカードを使用する NVIDIA Optimus のあるノート PC については、[[NVIDIA Optimus]] を見てください。
# [https://nouveau.freedesktop.org/CodeNames.html#NV50 NV50 (G80)]及びそれ以降においては、''modesetting'' DDX ドライバが推奨されています。詳細は [[Nouveau#インストール]] を見てください。

== ロード ==

ほとんどのカーネルモジュールドライバは、システムのブート時に自動的にロードされるはずです。

ロードされない場合は:

# [[カーネルパラメータ]]に {{ic|nomodeset}} や {{ic|1=vga=}} が'''含まれていない'''ことを確認してください。ドライバは [[KMS]] を必要とするためです。
# また、[[カーネルモジュール#ブラックリスト|カーネルモジュールブラックリスト]]によってドライバが無効化されていないことを確認してください。

== モニタリング ==

GPU のモニタリングは、GPU の温度、コアと VRAM の使用量、P-state を確認するために行われます。

==== CLI ====

* {{App|amdgpu_top|AMDGPU の使用率を表示するツール|https://github.com/Umio-Yasuno/amdgpu_top|{{Pkg|amdgpu_top}}}}
* {{App|nvtop|AMD、Intel、NVIDIA 用の、GPU プロセスモニタリングツール|https://github.com/Syllo/nvtop|{{Pkg|nvtop}}}}
* {{App|radeontop|GPU 使用率ビューア。全体のアクティビティのパーセンテージと個々のブロックの両方を確認できます。ATI の R600 及びそれより新しい GPU、さらに [[AMDGPU]] ドライバを使用するカードで動作します。|https://github.com/clbr/radeontop|{{Pkg|radeontop}}}}
* {{App|nvidia-smi|NVIDIA のプロプライエタリドライバにバンドルされている、Fermi 及びそれより新しい [[NVIDIA]] GPU 用の CLI モニタリングツール。|https://docs.nvidia.com/deploy/nvidia-smi/index.html|{{pkg|nvidia-utils}}}}

==== GUI ====

* {{App|amdgpu_top|AMDGPU の使用率を表示するツール|https://github.com/Umio-Yasuno/amdgpu_top|{{Pkg|amdgpu_top}}}}
* {{App|AmdGuid|完全に Rust 製の基本的なファン制御 GUI。|https://github.com/Eraden/amdgpud|{{AUR|amdguid-wayland-bin}}, {{AUR|amdguid-glow-bin}}}}
* {{App|Radeon Profile|AMD Radeon カード現在のクロックを読み取ったり変更したりできる Qt5 ツール。|https://github.com/emerge-e-world/radeon-profile|{{AUR|radeon-profile-git}}}}
* {{App|TuxClocker|Qt5 のモニタリング及びオーバークロックツール|https://github.com/Lurkki14/tuxclocker|{{AUR|tuxclocker}}}}
* {{App|Plasma System Monitor|システムのセンサー、プロセス情報、他のシステムリソースをモニタリングするインターフェイス。[[KDE|KDE Plasma]] にバンドルされています。|https://apps.kde.org/plasma-systemmonitor/|{{pkg|plasma-systemmonitor}}}}
* {{App|LACT|Linux システムで AMD、NVIDIA、Intel GPU を制御できます。|https://github.com/ilya-zlobintsev/LACT|{{pkg|lact}}}}

{{TranslationStatus|Graphics processing unit|2026-02-13|859652}}

NVIDIA

2026-02-03T07:29:36Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[de:Nvidia]]
[[en:NVIDIA]]
[[es:NVIDIA]]
[[hu:NVIDIA]]
[[pt:NVIDIA]]
[[ru:NVIDIA]]
[[zh-hans:NVIDIA]]
{{Related articles start}}
{{Related|NVIDIA/ヒントとテクニック}}
{{Related|NVIDIA/トラブルシューティング}}
{{Related|Nouveau}}
{{Related|NVIDIA Optimus}}
{{Related|PRIME}}
{{Related|Bumblebee}}
{{Related|nvidia-xrun}}
{{Related|Vulkan}}
{{Related articles end}}

この記事は公式の [https://www.nvidia.com NVIDIA] グラフィックカードドライバをカバーしています。コミュニティによるオープンソースのドライバに関しては、[[Nouveau]] を見てください。ハイブリッドグラフックスを搭載しているノートパソコンを使っている場合は、[[NVIDIA Optimus]] も見て下さい。

== インストール ==

{{Warning|NVIDIA のウェブサイトで提供されているパッケージを通して NVIDIA ドライバをインストールすることは避けてください。[[pacman]] 経由でインストールすれば、システムをアップデートした際にドライバもアップデートすることができます。}}

{{Note|[[ハイブリッドグラフィックス]]のあるシステム上でデュアルブートする場合は、Windows またはサードパーティのアプリで ([https://www.asus.com/support/faq/1043747/#a14 ASUS Eco mode] のような) ''Eco mode'' を有効化すると NVIDIA のディスクリート GPU が完全に無効化され、検出されなくなります。}}

まず、[https://nouveau.freedesktop.org/CodeNames.html nouveau wiki のコードネームに関するページ]で、以下のコマンドで入手した GPU カードのモデル名/公式名に対応するファミリ名を探してください:

$ lspci -k -d ::03xx

次に、使用しているカードに適したドライバをインストールしてください:

{| class="wikitable"
! GPU ファミリ
! ドライバ
! 状態
|-
| [[Wikipedia:Blackwell (microarchitecture)|Blackwell (GBXXX)]] 及びそれ以降
| {{Pkg|linux}} には {{Pkg|nvidia-open}} {{Pkg|linux-lts}} には {{Pkg|nvidia-open-lts}} {{Pkg|nvidia-open-dkms}} は任意のカーネルで使えます
| [https://developer.nvidia.com/blog/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules/ 上流で推奨されています]。 現行。サポートあり。1
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV160 Turing (NV160/TUXXX)] から [https://nouveau.freedesktop.org/CodeNames.html#NV190 Ada Lovelace (NV190/ADXXX)] まで
| colspan="2" | サポートしているパッケージ:
* {{Pkg|nvidia-open}}、Turing 世代では [[PRIME#PCI-Express Runtime D3 (RTD3) Power Management|RTD3 Power Management]] は利用できません2。 Ampere 世代を搭載したノート PC ではクラッシュする恐れがあります2。
* {{AUR|nvidia-580xx-dkms}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV110 Maxwell (NV110/GMXXX)] から [https://nouveau.freedesktop.org/CodeNames.html#NV140 Volta (NV140/GV100)] まで
| {{AUR|nvidia-580xx-dkms}}
| レガシー。サポートあり。
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVE0 Kepler (NVE0/GKXXX)]
| {{AUR|nvidia-470xx-dkms}}
| rowspan="4" | レガシー。サポートなし。3,4
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVC0 Fermi (NVC0/GF1XX)]
| {{AUR|nvidia-390xx-dkms}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV50 Tesla (NV50/G80-90-GT2XX)]
| {{AUR|nvidia-340xx-dkms}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV40 Curie (NV40/G70)] 及びそれ以前
| パッケージはもはや存在しません。
|}

# これらのパッケージが動作しない場合 (たいていはハードウェアが新しいことが原因です)、{{AUR|nvidia-open-beta}} が、新しいハードウェアをサポートしている新しいドライバのバージョンを提供しているかもしれません。
# NVIDIA の [https://download.nvidia.com/XFree86/Linux-x86_64/580.119.02/README/gsp.html GSP ファームウェア]は問題を引き起こすことが知られています (例えば、[https://github.com/NVIDIA/open-gpu-kernel-modules/issues/640#issuecomment-2188114679 Turing 世代 GPU で最適な電源管理が行われないケース]や、[https://bbs.archlinux.org/viewtopic.php?pid=2217692#p2217692 Ampere 世代 GPU を搭載している一部のノート PC が全く動作しなくなるケース]など)。この問題の影響を受ける場合は、代わりにプロプライエタリなドライバ (例: {{AUR|nvidia-580xx-dkms}}) を使用し、かつ[[モジュールパラメータ]] {{ic|1=NVreg_EnableGpuFirmware=0}} を設定してください。
# [https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/007/indirect-branch-tracking/ Indirect Branch Tracking] との互換性が無いため、[https://web.archive.org/web/20250209200337/https://www.intel.com/content/www/us/en/newsroom/opinion/intel-cet-answers-call-protect-common-malware-threats.html 第11世代及びそれ以降]の Intel CPU を搭載しているシステムで Linux 5.18 (及びそれ以降) においてこれらのドライバは動作しない場合があります。Indirect Branch Tracking は、[[ブートローダー]]から {{ic|1=ibt=off}} [[カーネルパラメータ]]を設定することにより、無効化することができます。ただし、このセキュリティ機能は[https://lwn.net/Articles/889475/ エクスプロイト手法の一種を緩和する]役割があるので注意してください。
# NVIDIA はもはやこれらのカードをアクティブにサポートしておらず、これらのドライバは[https://nvidia.custhelp.com/app/answers/detail/a_id/3142/ 現在の Xorg バージョンを公式にはサポートしていない場合があります]。[[nouveau]] ドライバを使うほうが簡単かもしれません。しかし、NVIDIA のレガシーなドライバは依然として利用可能であり、3D パフォーマンスまたは安定性に関して優れているかもしれません。

:{{Note|
:* {{Pkg|dkms}} をインストールする場合は、[[Dynamic Kernel Module Support#インストール]] を読んでください。
:* [[DKMS]] 版は特定のカーネルと結びついていません。カーネルのヘッダーファイルをインストールすると、そのカーネル用の NVIDIA カーネルモジュールをコンパイルし直すためです。
}}

32ビットアプリケーションのサポートに関しては、対応する ''lib32'' パッケージも [[multilib]] リポジトリからインストールしてください (例: {{Pkg|lib32-nvidia-utils}})。

{{Pkg|nvidia-utils}} パッケージには、再起動後に {{ic|nouveau}} モジュールをブラックリスト化するファイルが含まれています。任意で、{{ic|/etc/mkinitcpio.conf}} 内の {{ic|HOOKS}} 配列から {{ic|kms}} を削除し、その後 [[Initramfs を再生成する|initramfs を再生成]]してもよいです。こうすることで、initramfs に {{ic|nouveau}} モジュールが含まれないようにして、カーネルがこのモジュールを初期ブート中に読み込めないようにします。

{{Note|
* Wayland のユーザは、下記の [[#DRM カーネルモード設定]] を済ませるまで再起動するべきではありません。さもないと、(再起動後に) 黒画面になってしまうかもしれません。その章を済ませたら、[[#Wayland 設定]] に進むことができます。
* Xorg ユーザは、[[#Xorg 設定]] に進むことができます。
}}

=== カスタムカーネル ===

使用中のカーネルで {{ic|1=CONFIG_DRM_SIMPLEDRM=y}} となっていることを確認してください。そして、{{ic|CONFIG_DEBUG_INFO_BTF}} を使用している場合、[[PKGBUILD]] で以下が必要です (カーネル 5.16 以降):

install -Dt "$builddir/tools/bpf/resolve_btfids" tools/bpf/resolve_btfids/resolve_btfids

{{ic|CONFIG_NOVA_CORE}} を有効化してコンパイルされたカーネルでは、新しい NVIDIA GPU ドライバである [https://docs.kernel.org/gpu/nova/index.html Nova] がロードされないようにする必要があるかもしれません。{{Pkg|nvidia-utils}} はデフォルトでこのドライバをブラックリストに追加します。[[カーネルモジュール#モジュールオプションを設定する|systemd-analyze を実行する]]ことで、ロードされていないことを確認できます。別のバージョンのドライバをインストールしている場合は、{{ic|nova_core}} と {{ic|nova_drm}} を手動で[[ブラックリスト|ブラックリストに登録]]する必要があるかもしれません。

=== DRM カーネルモード設定 ===

Wayland コンポジタを正しく動作させるには、[[カーネルモード設定]] (KMS) が必要です。また、デュアル GPU の環境で NVIDIA の dGPU でネイティブな Wayland レンダリングを行うためにも、KMS が必要です。NVIDIA は、DRM ([[Wikipedia:Direct Rendering Manager|Direct Rendering Manager]]) が有効化されていない場合、[[カーネルモード設定#KMS の遅延開始|KMS の自動遅延読み込み]]をサポートしていません。{{Pkg|nvidia-utils}} 560.35.03-5 からは、DRM が[https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/commit/1b02daa2ccca6a69fa4355fb5a369c2115ec3e22 デフォルトで有効化されています]。

DRM が本当に有効化されているか調べるには、以下のコマンドを実行してください:

# cat /sys/module/nvidia_drm/parameters/modeset

正しく設定されていれば、このコマンドは {{ic|N}} ではなく {{ic|Y}} と出力するはずです。

バージョン 560 よりも古いドライバにおいては、{{ic|nvidia_drm}} モジュールに対して {{ic|1=modeset=1}} と[[カーネルモジュールパラメータ]]を手動で設定してください。

[[カーネル#公式サポートカーネル|公式サポートカーネル]]では {{ic|simpledrm}} が有効化されていますが、[[#fbdev|NVIDIA ドライバ固有の fbdev]] が無効化されている場合 (あるいは、バージョン 545 よりも古く利用できない場合)、NVIDIA ドライバは {{ic|efifb}} あるいは {{ic|vesafb}} を必要とします: 問題が発生する場合は、[https://bbs.archlinux.org/viewtopic.php?pid=2269076#p2269076 BBS#307164] に回避策が書かれてあります。

{{Note|[[カーネル#公式サポートカーネル|Arch で公式にサポートされているカーネル]]は {{ic|simpledrm}} を有効化します。しかし、NVIDIA ドライバは、{{ic|1=nvidia_drm.fbdev}} が無効化されている/利用できない場合 (バージョン 545 より前)、{{ic|efifb}} または {{ic|vesafb}} を必要とします。}}

==== 早期ロード ====

基本的な機能については先のカーネルパラメータを追加するだけで十分でしょう。可能な限り早い時にロードさせたい場合や、スタートアップ時に問題 ({{ic|nvidia}} カーネルモジュールが[[ディスプレイマネージャ]]のあとにロードされてしまうなど) が発生する場合には、{{ic|nvidia}}、{{ic|nvidia_modeset}}、{{ic|nvidia_uvm}} そして {{ic|nvidia_drm}} を initramfs に追加することができます。initramfs ジェネレータを設定する方法については [[カーネルモジュール#モジュールの早期ロード]] を見てください。

=== ビデオデコードのハードウェアアクセラレーション ===

VDPAU によるビデオデコードのアクセラレーションは GeForce 8 シリーズ及びそれ以降のカードでサポートされています。NVDEC によるビデオデコードのアクセラレーションは Fermi (~400 シリーズ) 及びそれ以降のカードでサポートされています。詳しくは [[ハードウェアビデオアクセラレーション]] をご覧ください。

=== NVENC によるビデオエンコードのハードウェアアクセラレーション ===

NVENC は {{ic|nvidia_uvm}} モジュールと、関連するデバイスノードが {{ic|/dev}} 下に作成されることを要求します。

最新のドライバーパッケージは、自動的にデバイスノードを作成する [[udev ルール]]を提供するので、追加の操作は必要ありません。

古いドライバ (例えば、{{AUR|nvidia-340xx-dkms}}) を使用している場合、デバイスノードを作成する必要があります。{{ic|nvidia-modprobe}} ユーティリティを実行するとデバイスノードが自動的に作成されます。{{ic|/etc/udev/rules.d/70-nvidia.rules}} を作成して {{ic|nvidia-modprobe}} を自動的に実行させることができます:

{{hc|/etc/udev/rules.d/70-nvidia.rules|2=
ACTION=="add", DEVPATH=="/bus/pci/drivers/nvidia", RUN+="/usr/bin/nvidia-modprobe -c 0 -u"}}

== Wayland 設定 ==

Xwayland に関しては [[Wayland#Xwayland]] を見てください。

その他の設定オプションについては、それぞれの[[Wayland#コンポジタ|コンポジタ]]の wiki ページやドキュメントを見てください。

{{Note|バージョン 555.xx より前のドライバを使用している場合や、{{ic|linux-drm-syncobj-v1}} プロトコルによって Explicit Sync をサポートしていない Wayland コンポジタを使用している場合、ネイティブの Wayland アプリと Xwayland アプリの両方でちらつき、フレーム順序の狂いなどの問題が発生する可能性があります。}}

=== 基本的なサポート ===

{{ic|nvidia_drm}} モジュールの重要なカーネルパラメータは {{ic|modeset}} と {{ic|fbdev}} です。{{Pkg|nvidia-utils}} パッケージを使用している場合、これらは両方とも[https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/blob/3b439109/PKGBUILD#L60 デフォルトで有効化されています]。また、NVIDIA は[https://indico.freedesktop.org/event/6/contributions/287/attachments/210/288/NVIDIA%20Wayland%20Roadmap.pdf 将来のリリースでこれらのパラメータをデフォルトで有効化することを計画しています]。

==== modeset ====

全ての Wayland 構成において {{ic|modeset}} を有効化することは適切に機能させるために必須です。

サポートの無いドライバについては、{{ic|modeset}} を手動で有効化する必要があります。詳細は [[#DRM カーネルモード設定]] と [[Wayland#要件]] を見てください。

==== fbdev ====

サポートされているドライバは、[[フレームバッファ]] を提供しています。もはやサポートされていないレガシーなドライバを使用する場合、Wayland の設定によっては、{{ic|nvidia_drm}} モジュールの {{ic|fbdev}} [[カーネルモジュールパラメータ]]を有効化する必要があるかもしれません。

Linux 6.11 以降においてこれは厳しい要件ですが、これが仕様なのかバグなのかは現在明らかになっていません。詳細は [https://forums.developer.nvidia.com/t/drm-fbdev-wayland-presentation-support-with-linux-kernel-6-11-and-above/307920] を参照してください。

NVIDIA のフレームバッファが有効化されていることを確認するには、以下のコマンドを実行してください:

# cat /sys/module/nvidia_drm/parameters/fbdev

{{ic|fbdev}} が設定されていない場合は、このコマンドは {{ic|N}} を出力するのではなく、ファイルが存在しないことを示すエラーが発生します。

=== サスペンドのサポート ===

Wayland でのサスペンドは X よりもデフォルトの設定の問題が発生しやすいです。詳細は [[NVIDIA/ヒントとテクニック#サスペンド後にビデオメモリを保持する]] を参照してください。

GDM を使用している場合は、[[GDM#Wayland とプロプライエタリな NVIDIA ドライバ]] も参照してください。

=== nvidia-application-profiles-rc.d ===

一部の wayland コンポジタは [https://www.nvidia.com/en-us/drivers/details/237587/ GLVidHeapReuseRatio] アプリケーションプロファイルキーが[https://github.com/NVIDIA/egl-wayland/issues/126#issuecomment-2379945259 アプリケーションのプロセス名に対して適用]されていない場合、デフォルトで大量の VRAM を消費します。例えば、以下のように設定すれば [[niri]] ではアイドル時で VRAM 消費量を約2.5GiB削減できます:

{{hc|/etc/nvidia/nvidia-application-profiles-rc.d/50-limit-free-buffer-pool-in-wayland-compositors.json|2=
{
"rules": [
{
"pattern": {
"feature": "procname",
"matches": "niri"
},
"profile": "Limit free buffer pool on Wayland compositors"
}
],
"profiles": [
{
"name": "Limit free buffer pool on Wayland compositors",
"settings": [
{
"key": "GLVidHeapReuseRatio",
"value": 0
}
]
}
]
}
}}

== Xorg 設定 ==

プロプライエタリな NVIDIA グラフィックドライバは Xorg サーバの設定ファイルを必要としません。[[Xorg#起動|X を起動]]してみて、Xorg サーバが設定ファイル無しで正しく機能するかを確認することができます。しか、様々な設定を調整するために設定ファイル ({{ic|/etc/X11/xorg.conf}} よりも {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} を優先して使用してください) を作成する必要があるかもしれません。この設定は、NVIDIA Xorg 設定ツールによって生成することができますし、手動で作成することもできます。手動で作成した場合、([[Xorg]] サーバに基本的なオプションのみを与えると言う意味で) 最小の設定にすることができますし、あるいは、Xorg の自動検出されたオプションや事前設定されたオプションをバイパスできる設定を含めることもできます。

{{Tip|その他の設定オプションは、[[NVIDIA/トラブルシューティング]] を見てください。}}

=== 自動設定 ===

NVIDIA のパッケージには、Xorg サーバの設定ファイル ({{ic|xorg.conf}}) を作成するための自動設定ツールが含まれています。次のコマンドで実行できます:

# nvidia-xconfig

このコマンドは {{ic|/etc/X11/xorg.conf}} を自動検出し、現在のハードウェアに応じてそのファイルを作成 (すでに存在する場合は編集) します。

デフォルトの深度、水平同期、垂直リフレッシュ、そして解像度が問題ないか {{ic|/etc/X11/xorg.conf}} を二重にチェックしてください。

=== nvidia-settings ===

{{Pkg|nvidia-settings}} は CLI または GUI を使って様々なオプションを設定することができるツールです。何もオプションをつけずに {{ic|nvidia-settings}} を実行すると GUI が起動します。CLI のオプションについては {{man|1|nvidia-settings}} を見てください。

{{Pkg|nvidia-settings}} の CLI/GUI は非 root なユーザとして実行でき、''nvidia-settings Configuration'' タブにある ''Save Current Configuration'' オプションで設定を {{ic|~/.nvidia-settings-rc}} に保存できます。

現在のユーザで {{ic|~/.nvidia-settings-rc}} をロードするには:

$ nvidia-settings --load-config-only

起動時に毎回このコマンドを実行させるには[[自動起動]]を見てください。

{{Note|{{ic|nvidia-settings}} から変更を加えると [[Xorg]] が起動しなくなったりクラッシュするようになったりすることがあります。生成された {{ic|~/.nvidia-settings-rc}} と [[Xorg]] のファイルの両方/片方を調整するか削除することで普通に起動できるようになるはずです。}}

=== 手動設定 ===

設定ファイルを編集することで、([[#自動設定|自動的に]]、または [[#NVIDIA settings|nvidia-settings]]によって有効化できない) いくつかの微調整をすることができます。変更を適用する前に Xorg サーバーを再起動する必要があります。

その他の詳細やオプションについては [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/ NVIDIA Accelerated Linux Graphics Driver README and Installation Guide] をご覧ください。

==== 最小設定 ====

{{ic|20-nvidia.conf}} (もしくは非推奨の {{ic|xorg.conf}}) の基本的な設定ブロックは以下のようになります:

{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|
Section "Device"
Identifier "NVIDIA Card"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce GTX 1050 Ti"
EndSection
}}

==== 起動時のロゴを無効化 ====

古いドライバ ({{AUR|nvidia-340xx-dkms}}) を使用している場合、X の起動時に表示される NVIDIA ロゴスプラッシュスクリーンを無効化しておいたほうがいいかもしれません。{{ic|Device}} セクション内に {{ic|"NoLogo"}} オプションを追加してください:

Option "NoLogo" "1"

==== モニター検出をオーバーライド ====

{{ic|Device}} セクション内の {{ic|"ConnectedMonitor"}} オプションにより、 X サーバーが起動した時にモニター検出をオーバーライドできます。これにより、起動時間を大幅に減らせるかもしれません。利用可能なオプション: アナログ接続用の {{ic|"CRT"}}、デジタルモニター用の {{ic|"DFP"}}、テレビ用の {{ic|"TV"}}。

以下の行は起動時のチェックをバイパスし、モニターを DFP として認識することを NVIDIA ドライバーに強制します:

Option "ConnectedMonitor" "DFP"

{{Note|たとえディスプレイが薄型パネルであろうと、アナログ15ピン VGA 接続に対しては "CRT" を使用してください。"DFP" は DVI や HDMI、DisplayPort のデジタル接続のみを意図しています。}}

==== 輝度調整を有効化 ====

{{Out of date|時代遅れの可能性あり[https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/GXJG7D3ALUQKOE2DT4XCL4UXQUFDDSEC/]。上流のパッケージも古いようです。}}

以下をカーネルパラメータに追加してください:

nvidia.NVreg_RegistryDwords=EnableBrightnessControl=1

あるいは、以下を {{ic|Device}} セクション内に追加してください:

Option "RegistryDwords" "EnableBrightnessControl=1"

もし、この設定で輝度調整がまだ機能しない場合は、{{AUR|nvidia-bl-dkms}} をインストールしてみてください。

{{Note|{{AUR|nvidia-bl-dkms}} をインストールすることにより、バックライト輝度調整用の {{ic|/sys/class/backlight/nvidia_backlight/}} インターフェイスが提供されます。しかし、システムが {{ic|/sys/class/backlight/acpi_video0/}} に対してバックライト制御の変更を発行し続けるかもしれません。この場合の1つの解決策は、例えば、''inotifywait'' を使用して {{ic|acpi_video0/brightness}} の変更を監視し、それを変換して {{ic|nvidia_backlight/brightness}} に対して書き込むことです。[[バックライト#sysfs を変更しても明るさが変更されない]] をご覧ください。}}

==== SLI を有効化 ====

{{Out of date|バージョン 455.23.04 から、一部の SLI モードはもはやサポートされていません。}}

{{Warning|GTX 10xx シリーズ (1080、1070、1060 など) 以降は 2-way SLI のみがサポートされます。3-way や 4-way SLI は CUDA/OpenCL アプリケーションに対しては機能するかもしれませんが、すべての OpenGL アプリケーションに対してはたいてい機能しないでしょう。}}

NVIDIA ドライバーの [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/xconfigoptions.html#SLI README] 付録 B によると: ''このオプションは、サポートされている構成で SLI レンダリングの設定を制御します。'' "サポートされている構成"とは SLI 認定マザーボードと、2基または3基の SLI 認定 GeForce GPU を搭載しているコンピュータのことです。

{{ic|lspci}} を使って1つ目の GPU の PCI Bus ID を調べてください:

{{hc|# lspci -d ::03xx|
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
03:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
04:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M / Quadro M500M] (rev a2)
}}

調べた BusID (前述の例では 3) を {{ic|Device}} セクション内に追加してください:

BusID "PCI:3:0:0"

{{Note|フォーマットが重要です。BusID の値は {{ic|"PCI:<BusID>:0:0"}} のように指定されなければなりません。}}

希望する SLI レンダリングモードの値を {{ic|Screen}} セクション内に追加してください:

Option "SLI" "AA"

以下の表は利用可能なレンダリングモードです。

{| class="wikitable"
! 値 !! 挙動
|-
| 0, no, off, false, Single || レンダリング時にただ1つの GPU を使う。
|-
| 1, yes, on, true, Auto || SLI を有効化し、ドライバーが自動的に適切なレンダリングモードを選択することを許可する。
|-
| AFR || SLI を有効化し、Alternate Frame Rendering モードを使う。
|-
| SFR || SLI を有効化し、Split Frame Rendering モードを使う。
|-
| AA || SLI を有効化し、SLI アンチエイリアシングを使う。この値を Full-Scene アンチエイリアシングと一緒に使うと視覚品質が向上します。
|}

あるいは、''nvidia-xconfig'' ユーティリティを使って、これらの変更を {{ic|xorg.conf}} に追加できます:

# nvidia-xconfig --busid=PCI:3:0:0 --sli=AA

SLI モードが有効化されていることをシェルから確認するには:

{{hc|$ nvidia-settings -q all {{!}} grep SLIMode|
Attribute 'SLIMode' (arch:0.0): AA
'SLIMode' is a string attribute.
'SLIMode' is a read-only attribute.
'SLIMode' can use the following target types: X Screen.
}}

{{Warning|SLI を有効化した後に xorg を起動するとシステムがフリーズしたり、応答しなくなったりするかもしれません。再起動する前にディスプレイマネージャーを無効化することをおすすめします。}}

以上の設定で機能しない場合は、{{ic|nvidia-settings}} で得られる PCI Bus ID を使用する必要があるかもしれません。

{{hc|$ nvidia-settings -q all {{!}} grep -i pcibus|
Attribute 'PCIBus' (host:0[gpu:0]): 101.
'PCIBus' is an integer attribute.
'PCIBus' is a read-only attribute.
'PCIBus' can use the following target types: GPU, SDI Input Device.
Attribute 'PCIBus' (host:0[gpu:1]): 23.
'PCIBus' is an integer attribute.
'PCIBus' is a read-only attribute.
'PCIBus' can use the following target types: GPU, SDI Input Device.
}}

そして、xorg.d 内の PrimaryGPU オプションをコメントアウトしてください:

{{hc|/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf|
...

Section "OutputClass"
...
# Option "PrimaryGPU" "yes"
...
}}

この設定でグラフィカルブートの問題も解決できるかもしれません。

=== マルチモニター ===

一般的な情報は [[マルチディスプレイ]] を見て下さい。

==== NVIDIA Settings を使う ====

[[#nvidia-settings|nvidia-settings]] ツールを使ってマルチモニターを設定できます。

CLI で設定する場合、まずは以下を実行して {{ic|CurrentMetaMode}} を確認してください:

{{hc|$ nvidia-settings -q CurrentMetaMode|2=
Attribute 'CurrentMetaMode' (hostnmae:0.0): id=50, switchable=no, source=nv-control :: DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0}
}}

{{ic|::}} 以降の全て (上記の場合: {{ic|1=DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0}}}) を使って {{ic|1=nvidia-settings --assign "CurrentMetaMode=''your_meta_mode''"}} でディスプレイを再設定できます。

{{Tip|使用するモニターや解像度の設定ごとにシェルのエイリアスを作成すると便利です。}}

==== ConnectedMonitor ====

{{Out of date|{{ic|Option "TwinView"}} はバージョン 302.07 で削除され、TwinView は常に有効になっています。}}

ドライバーがセカンドモニタを正しく認識しない場合は、ConnectedMonitor を使って認識するように強制できます。

{{hc|/etc/X11/xorg.conf|

Section "Monitor"
Identifier "Monitor1"
VendorName "Panasonic"
ModelName "Panasonic MICRON 2100Ex"
HorizSync 30.0 - 121.0 # this monitor has incorrect EDID, hence Option "UseEDIDFreqs" "false"
VertRefresh 50.0 - 160.0
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor2"
VendorName "Gateway"
ModelName "GatewayVX1120"
HorizSync 30.0 - 121.0
VertRefresh 50.0 - 160.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device1"
Driver "nvidia"
Option "NoLogo"
Option "UseEDIDFreqs" "false"
Option "ConnectedMonitor" "CRT,CRT"
VendorName "NVIDIA Corporation"
BoardName "GeForce 6200 LE"
BusID "PCI:3:0:0"
Screen 0
EndSection

Section "Device"
Identifier "Device2"
Driver "nvidia"
Option "NoLogo"
Option "UseEDIDFreqs" "false"
Option "ConnectedMonitor" "CRT,CRT"
VendorName "NVIDIA Corporation"
BoardName "GeForce 6200 LE"
BusID "PCI:3:0:0"
Screen 1
EndSection

}}

{{ic|TwinView}} を使わずに1つのカードで2つのモニターを X で使うために {{ic|Screen}} でデバイスを複製しています。{{ic|nvidia-settings}} は追加した {{ic|ConnectedMonitor}} オプションを全て消してしまうので注意してください。

==== TwinView ====

{{Out of date|{{ic|Option "TwinView"}} はバージョン 302.07 で削除され、TwinView は常に有効になっています。}}

画面を2つ表示するのではなく1つの大きな画面を表示したい場合、{{ic|TwinView}} 引数を {{ic|1}} に設定してください。コンポジットを使いたい場合、このオプションを使用する必要があります。TwinView は全てのモニターが同一のカードに接続されている場合にのみ機能します。

Option "TwinView" "1"

設定例:

{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|
Section "ServerLayout"
Identifier "TwinLayout"
Screen 0 "metaScreen" 0 0
EndSection

Section "Monitor"
Identifier "Monitor0"
Option "Enable" "true"
EndSection

Section "Monitor"
Identifier "Monitor1"
Option "Enable" "true"
EndSection

Section "Device"
Identifier "Card0"
Driver "nvidia"
VendorName "NVIDIA Corporation"

#refer to the link below for more information on each of the following options.
Option "HorizSync" "DFP-0: 28-33; DFP-1 28-33"
Option "VertRefresh" "DFP-0: 43-73; DFP-1 43-73"
Option "MetaModes" "1920x1080, 1920x1080"
Option "ConnectedMonitor" "DFP-0, DFP-1"
Option "MetaModeOrientation" "DFP-1 LeftOf DFP-0"
EndSection

Section "Screen"
Identifier "metaScreen"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
Option "TwinView" "True"
SubSection "Display"
Modes "1920x1080"
EndSubSection
EndSection
}}

[https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/configtwinview.html Device オプション情報]。

SLI に対応しているカードが複数枚存在する場合、別々のカードに接続された複数のモニターを使うことができます (例: 2枚のカードが SLI で、各々のカードにモニターが1台ずつ接続)。SLI モザイクモードと "MetaModes" オプションで有効になります。以下は上記と同じように設定する例で、[[GNOME]] が完璧に動作します:

{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|
Section "Device"
Identifier "Card A"
Driver "nvidia"
BusID "PCI:1:00:0"
EndSection

Section "Device"
Identifier "Card B"
Driver "nvidia"
BusID "PCI:2:00:0"
EndSection

Section "Monitor"
Identifier "Right Monitor"
EndSection

Section "Monitor"
Identifier "Left Monitor"
EndSection

Section "Screen"
Identifier "Right Screen"
Device "Card A"
Monitor "Right Monitor"
DefaultDepth 24
Option "SLI" "Mosaic"
Option "Stereo" "0"
Option "BaseMosaic" "True"
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "Screen"
Identifier "Left Screen"
Device "Card B"
Monitor "Left Monitor"
DefaultDepth 24
Option "SLI" "Mosaic"
Option "Stereo" "0"
Option "BaseMosaic" "True"
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Default"
Screen 0 "Right Screen" 0 0
Option "Xinerama" "0"
EndSection
}}

===== TwinView を使って垂直同期 =====

TwinView と垂直同期 ({{ic|nvidia-settings}} の ''Sync to VBlank'' オプション) を使っている場合、モニターの大きさが異なっていると片方の画面だけが同期されます。{{ic|nvidia-settings}} にはどちらの画面を同期させるか設定するオプション (''Sync to this display device'' オプション) が存在しますが、必ずしも機能するとはいいがたいです。起動時に以下の環境変数を追加することで解決します (例: {{ic|/etc/profile}} に追加):

export __GL_SYNC_TO_VBLANK=1
export __GL_SYNC_DISPLAY_DEVICE=DFP-0
export VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-0

{{ic|DFP-0}} は適切な画面に置き換えてください ({{ic|DFP-0}} は DVI 端子で {{ic|CRT-0}} は VGA 端子です)。ディスプレイの識別名は {{ic|nvidia-settings}} の ''X Server XVideoSettings'' セクションで確認できます。

===== Twinview を使ってゲームを遊ぶ =====

TwinView を使ってフルスクリーンのゲームを遊ぶ場合、2つの画面が1つの大きな画面としてゲームから認識されることがあります。技術的にこれは正しいのですが (仮想的な X スクリーンの横幅は両方の画面を合わせたサイズになります)、ゲームを遊ぶときは両方の画面を使わないようにしたいときもあるでしょう。

SDL 1.2 のこの挙動を修正するには、次を試して下さい:

export SDL_VIDEO_FULLSCREEN_HEAD=1

OpenGL の場合、{{ic|xorg.conf}} の {{ic|Device}} セクションに適切な Metamodes を追加して X を再起動してください:

Option "Metamodes" "1680x1050,1680x1050; 1280x1024,1280x1024; 1680x1050,NULL; 1280x1024,NULL;"

[[ゲーム#別の X サーバーでゲームを起動する|別の X サーバーでゲームを起動する]]方法もあります。上記の方法と一緒に使うことも可能です。

==== モザイクモード ====

モザイクモードは、複数のグラフィクカードでコンポジット有りで3つ以上のモニタを使用する唯一の方法です。ウィンドウマネージャは各モニタの違いを認識するかもしれませんし、しないかもしれません。モザイクモードには、有効な SLI 設定が必要です。SLI を使わずにベースモードを使用する場合でも、GPU は依然として SLI 対応/互換でなければなりません。

===== ベースモザイク =====

ベースモザイクモードは Geforce 8000 シリーズ以上の GPU で動作します。nvidia-setting の GUI から有効にすることはできません。''nvidia-xconfig'' コマンドラインプログラムを使用するか {{ic|xorg.conf}} を手動で編集する必要があります。Metamodes を指定してください。以下は4台の DFP を 2x2 の構成で使用する例です。各々の解像度は 1920x1024 で、2枚のカードにそれぞれ2台の DFP が接続されている場合:

# nvidia-xconfig --base-mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"

{{Note|ドキュメントには 2x2 のモニター構成が記述されていますが、Base Mosaic モードで[https://forums.developer.nvidia.com/t/basemosaic-v295-vs-v310-vs-v325-only-up-to-three-screens/30583#3954733 GeForce カードは人為的にモニタ3台に制限されています]。Quadro カードは4台以上のモニタをサポートしています。2014年9月現在、Windows ドライバはこの人為的な制限を落としましたが、Linux ドライバでは未だに残っています。}}

===== SLI モザイク =====

SLI 構成を使っていて、使用する GPU が Quadro FX 5800 や Quadro Fermi 以降の場合、SLI モザイクモードが利用できます。nvidia-settings の GUI の中から有効化するか、コマンドラインで設定してください:

# nvidia-xconfig --sli=Mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"

== NVswitch ==

NVswitch のあるシステム (AWS の H100x8 など) では、以下が必要です。

* nvidia-fabricmanager をインストールする。
* Fabric manager が必要とする、対応するカーネルモジュールをインストールする。

Fabric manager を使うと、pytorch が GPU が見つからないと報告してきます。

Fabric マネージャをインストールするには:

# Nvidia から tarball をダウンロードする。[https://developer.download.nvidia.com/compute/cuda/redist/fabricmanager/linux-x86_64/ こちら]
# バージョン 555.42.02 は正しく動作します。
# インストールスクリプト sbin/fm_run_package_installer.sh を変更してしてインストール先のパスを修正してください。

対応するカーネルドライバを入手するには:

# nvidia-beta-dkms と nvidia-utils-beta の AUR リポジトリを git clone してください。
# PKGBUILD を変更してバージョン 555.42.02 を使用するようにしてください。
# ビルドし、インストールしてください。
# 再起動してください。

最後に、{{ic|systemctl enable nvidia-fabricmanager}} と {{ic|systemctl start nvidia-fabricmanager}} を実行すれば、pytorch が動くはずです。

== ヒントとテクニック ==

[[NVIDIA/ヒントとテクニック]] を参照。

== トラブルシューティング ==

[[NVIDIA/トラブルシューティング]] を参照。

== 参照 ==

* [https://forums.developer.nvidia.com/t/current-graphics-driver-releases/28500 Current graphics driver releases in official NVIDIA Forum]
* [https://forums.developer.nvidia.com/c/gpu-graphics/linux/148 NVIDIA Developers Forum - Linux Subforum]

{{TranslationStatus|NVIDIA|2026-02-03|862293}}

Podman

2025-09-18T03:55:41Z

AshMyzk: /* ルートレス Podman */ 不要な「の」

[[Category:仮想化]]
[[Category:サンドボックス]]
[[en:Podman]]
[[pt:Podman]]
{{Related articles start}}
{{Related|systemd-nspawn}}
{{Related|Linux Containers}}
{{Related|Docker}}
{{Related|Buildah}}
{{Related|Vagrant}}
{{Related articles end}}
Podman は [[Docker]] の代わりになるプログラムで、同じようなインターフェイスを提供します。ルートレスコンテナと ''docker-compose'' の shim サービスをサポートします。

== インストール ==

{{Pkg|podman}} パッケージを[[インストール]]してください。コンテナイメージを作成したい場合は [[Buildah]] も見てください。

コンテナのネットワーキングに関しては、{{Pkg|cni-plugins}} または v4.0 からは {{Pkg|netavark}} をインストールしてください。

[[Docker]] を置き換えたい場合は、docker バイナリを模倣する {{Pkg|podman-docker}} を man ページと共にインストールできます。

[[Docker]] と異なり、Podman はデーモンを必要としませんが、{{Pkg|cockpit-podman}} を介して [[cockpit]] のようなサービスに API を提供するものは存在します。

デフォルトでは Podman コンテナを実行できるのは root だけです。root 以外のユーザーでコンテナを実行したい場合は [[#ルートレス Podman]] を参照してください。

== 設定 ==

コンテナの挙動を設定する設定ファイルは {{ic|/usr/share/containers/}} にあります。編集する前に {{ic|/etc/containers}} にコピーする必要があります。Podman によって使われるネットワークブリッジインターフェイスを設定したいときは {{ic|/etc/cni/net.d/87-podman.conflist}} を見てください。

=== ルートレス Podman ===

{{Warning|ルートレス Podman は非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) に依存しています。これはいくつかの重大なセキュリティ上の影響があります。詳細は [[セキュリティ#アプリケーションのサンドボックス化]] を参照してください。}}

デフォルトではコンテナ (カーネルの文脈で言うところの名前空間) を実行できるのは {{ic|root}} だけです。ルートレスで Podman を実行すると、攻撃者がシステムに対するルート権限を持たないため、セキュリティが向上します。また、複数の非特権ユーザーが同じマシン上でコンテナを実行できるようになります。{{man|1|podman|Rootless mode}} も参照してください。

==== 追加の依存関係 ====

{{Pkg|slirp4netns}} が、[https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md rootless 環境]内で Podman を実行するための依存パッケージとしてインストールされます。

Podman が {{Pkg|netavark}} ネットワークバックエンド ({{man|5|containers.conf}} を参照) を使用する場合、rootless コンテナで名前解決を行うために {{Pkg|aardvark-dns}} をインストールする必要があります。

==== ネイティブな rootless オーバーレイを有効化する ====

以前は、rootless 環境で [[FUSE]] オーバーレイをマウントするために {{Pkg|fuse-overlayfs}} パッケージを使用しなくてはなりませんでした。しかし、Podman と Linux カーネルの最近のバージョンは''ネイティブな'' rootless オーバーレイを[https://www.redhat.com/sysadmin/podman-rootless-overlay サポート]しており、これはより高パフォーマンスです。{{Pkg|fuse-overlayfs}} から移行するには、次を実行してください:
$ podman system reset

残念ながら、このコマンドは pull されたコンテナをすべて削除してしまいます。また、Podman が {{ic|overlay}} ドライバを使用し、かつ {{man|5|containers-storage.conf}} で {{ic|mount_program}} パラメータが定義されていないことを確認してください。さらに、[[Docker#ネイティブ overlay diff エンジンを有効化する]] の指示に従う必要があるかもしれません。

ネイティブな rootless オーバーレイが有効化されていることを確認するには、次を実行してください:
$ podman info
{{ic|graphDriverName: overlay}} と {{ic|Native Overlay Diff: "true"}} が出力される必要があります。

==== kernel.unprivileged_userns_clone を有効にする ====

まず、次のコマンドを実行して {{ic|kernel.unprivileged_userns_clone}} の値を確認します:

$ sysctl kernel.unprivileged_userns_clone

現在、{{ic|0}} に設定されている場合は、[[sysctl]] または[[カーネルパラメータ]]で {{ic|1}} を設定して有効にします。

{{Note|{{Pkg|linux-hardened}} では {{ic|kernel.unprivileged_userns_clone}} がデフォルトで {{ic|0}} に設定されています。}}

==== subuid と subgid を設定する ====

ルートレスで Podman を動かすには、Podman を使用するユーザー毎に {{man|5|subuid}} と {{man|5|subgid}} の設定エントリが存在していなければなりません。{{man|8|useradd}} を使って作成された新しい[[ユーザー]]には、これらのエントリがデフォルトで存在します。

{{Note|
* {{Pkg|shadow}} {{ic|4.11.1-3}} より前の時点で作成されたユーザーは、{{ic|/etc/subuid}} と {{ic|/etc/subgid}} 内にエントリがデフォルトで存在しません。{{man|8|usermod}} コマンドを使うか、これらのファイルを手動で変更することで、エントリを作成することができます。
:以下のコマンドは、{{ic|''username''}} というユーザとグループが Podman コンテナ (あるいは他の種のコンテナ) を実行できるようにします。このコマンドは、指定された範囲の UID と GID を、指定されたユーザとグループに割り当てます。
:{{bc|# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ''username''}}
:{{ic|''username''}} に対する上記の範囲は、システム上の最初のユーザに対して定義されるため、他のユーザによってすでに取られているかもしれません。わからない場合は、まず {{ic|/etc/subuid}} と {{ic|/etc/subgid}} を調べて、すでに予約されている範囲を見つけてください。
* 多くのイメージはマッピングのために65536個の UID と GID を必要とします (特に busybox や alpine のベースイメージ)。docker との互換性を最大にするため、各ユーザに最低でもその数の UID と GID を割り当てることをお勧めします。
* [[systemd-homed]] を使用している場合、コンテナ用の UID と GID の最小値は 524288 以上でなければなりません ({{ic|userdbctl}} の出力で "begin container users" を確認してください)。[https://www.reddit.com/r/podman/comments/uwgkb1/tip_systemdhomed_with_rootless_subuidsubgid/]
}}

==== subuid と subgid の変更を伝播する ====

ルートレス Podman は非特権名前空間を存続させるために pause プロセスを使用します。これにより、{{ic|/etc/subuid}} および {{ic|/etc/subgid}} ファイルへの変更は、pause プロセスの実行中にルートレスコンテナに伝播されるのを防ぎます。これらの変更を伝播するには、以下のコマンドを実行します。

$ podman system migrate

この後、上記のファイルで指定されたユーザ/グループは、Podman コンテナを起動して実行できるようになります。

==== SYS_CHROOT ケイパビリティを追加する (任意) ====

リリース 4.4 から、以前はデフォルトであった一部のケイパビリティが ({{ic|SYS_CHROOT}} を含めて) 無くなりました ([https://blog.podman.io/2022/12/dropping-capabilities-making-containers-more-secure/ 公式のブログ投稿]で説明されています)。これは、chroot を使用するコンテナ (''archlinux:base'' など) に影響を与え、コンテナ内での pacman の操作 (すなわち、インストール後のスクリプトを実行するパッケージのインストール) が失敗してしまいます。このような問題は、podman でビルドする際にビルド中に以下のようなエラーが発生する場合、特定できます:

...
could not change the root directory (Operation not permitted)
error: command failed to execute correctly
...

これを解決するには、{{ic|/etc/containers/containers.conf}} を編集してリストに {{ic|SYS_CHROOT}} を追加してください:

{{hc|/etc/containers/containers.conf|2=
default_capabilities = [
"CHOWN",
"DAC_OVERRIDE",
"FOWNER",
"FSETID",
"KILL",
"NET_BIND_SERVICE",
"SETFCAP",
"SETGID",
"SETPCAP",
"SETUID",
"SYS_CHROOT",
]
}}

また、{{man|1|podman-build}} を実行する際にコマンドラインから {{ic|--cap-add sys_chroot}} を使うことで、一時的に SYS_CHROOT ケイパビリティを付与することができます。

=== ストレージ ===

コンテナイメージとインスタンスの保存方法と保存場所の設定は、{{ic|/etc/containers/storage.conf}} にあります。

{{Note|[[#ルートレス Podman]] を使用する場合、ストレージ設定のオーバーライドをユーザーごとに {{ic|$XDG_CONFIG_HOME/containers/storage.conf}} に追加できます。}}

ストレージに使用しているファイルシステムに応じて {{ic|driver}} を設定します ({{man|5|containers-storage.conf|STORAGE_TABLE}} を参照)。

=== 外部のアーキテクチャ ===

Podman は、[[Wikipedia:binfmt_misc]] システムを使用することで、使用中のホストとは異なる CPU アーキテクチャ用にビルドされたイメージを実行することができます。

これを有効化するには、{{Pkg|qemu-user-static}} と {{Pkg|qemu-user-static-binfmt}} をインストールしてください。

[[systemd]] には、新しいルールを有効化する {{ic|systemd-binfmt.service}} サービスが同梱されています。

binfmt ルールが追加されたことを確認してください:

{{hc|$ ls /proc/sys/fs/binfmt_misc|
DOSWin qemu-cris qemu-ppc qemu-sh4eb status
qemu-aarch64 qemu-m68k qemu-ppc64 qemu-sparc
qemu-alpha qemu-microblaze qemu-riscv64 qemu-sparc32plus
qemu-arm qemu-mips qemu-s390x qemu-sparc64
qemu-armeb qemu-mipsel qemu-sh4 register
}}

これで、Podman は外部のアーキテクチャのイメージを実行できるようになったはずです。ほとんどのコマンドは、{{ic|--arch}} オプションが渡されたときに、外部のアーキテクチャを使用します。

例:

{{hc|# podman run --arch arm64 'docker.io/alpine:latest' arch|
aarch64
}}

=== Docker Compose ===

Podman 3.0.0 では、''docker-compose'' サポートが追加されました。これには、Docker を模倣する Podman ソケットを有効化する必要があります。{{ic|podman.service}} ユニットを[[起動]]してください。ルートレスコンテナの場合は、代わりに {{ic|podman.service}} [[ユーザーユニット]]を[[起動]]し、{{ic|DOCKER_HOST}} 変数を設定する必要があります:

$ export DOCKER_HOST="unix://$XDG_RUNTIME_DIR/podman/podman.sock"

コンテナ間でのホスト名解決を行うには、{{Pkg|podman-dnsname}} をインストールしてください。

{{Note|1=
buildkit を docker 内で有効化している場合、統合は機能しません。buildkit を無効化する必要があります:

$ export DOCKER_BUILDKIT=0

}}

=== NVIDIA GPU ===

[https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#podman NVIDIA Container Toolkit] は、NVIDIA GPU 用のコンテナランタイムを提供します。{{AUR|nvidia-container-toolkit}} パッケージをインストールしてください。

セットアップをテストしてください:

$ podman run --rm nvidia/cuda:12.0.0-runtime-ubuntu20.04 nvidia-smi

Podman でルートレスコンテナを実行できるようにするには、{{ic|/etc/nvidia-container-runtime/config.toml}} で {{ic|no-cgroups}} の設定を {{ic|true}} に設定しなければなりません。

== イメージ ==

{{Note|イメージのレジストリプレフィックスは省略できます。Podman は {{ic|/etc/containers/registries.conf}} の {{ic|unqualified-search-registries}} に定義されている全てのレジストリからイメージを自動で (定義されている順番で) 検索します。以下に記述しているイメージは設定に {{ic|docker.io}} がなくても使えるように全てプレフィックスを付けています。}}

=== Arch Linux ===

以下のコマンドで [https://hub.docker.com/_/archlinux/ Arch Linux] x86_64 イメージが [https://hub.docker.com/ Docker Hub] から取得されます。

# podman pull docker.io/archlinux

利用可能なタグの全リストや、ビルドツールあるなしのバージョンについては Docker Hub のページを見てください。

[https://gitlab.archlinux.org/archlinux/archlinux-docker/blob/master/README.md README.md] も参照してください。

=== Alpine Linux ===

[https://www.alpinelinux.org/ Alpine Linux] はコンテナイメージとして容量が小さく、静的バイナリとしてコンパイルされたソフトウェアに適しています。以下のコマンドで最新の Alpine Linux イメージが [https://hub.docker.com/ Docker Hub] から取得されます:

# podman pull docker.io/alpine

Alpine Linux はほとんどの Linux ディストリビューションで使われている [https://www.gnu.org/software/libc/ glibc] libc 実装の代わりに [https://musl.libc.org/ musl] libc 実装を使っています。Arch Linux は glibc を使っているため、Arch Linux ホストと Alpine Linux コンテナにはパフォーマンスからソフトウェアの正確性まで様々な影響がある違いが存在します。差異については https://wiki.musl-libc.org/functional-differences-from-glibc.html で文書化されています。

Arch Linux (や glibc を使用する他の環境) で動的リンクでビルドしたソフトウェアは Alpine Linux (や他の libc を使用する環境) で実行したときにバグやパフォーマンスの問題が発生する可能性があります。例としては [https://bugs.python.org/issue32307]、[https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image]、[https://pythonspeed.com/articles/alpine-docker-python] を見てください。

=== CentOS ===

以下のコマンドによって最新の [https://hub.docker.com/_/centos CentOS] イメージが [https://hub.docker.com/ Docker Hub] から取得されます:

# podman pull docker.io/centos

CentOS のリリースを指定するタグについては Docker Hub のページを見てください。

=== Debian ===

以下のコマンドによって最新の [https://hub.docker.com/_/debian Debian] イメージが [https://hub.docker.com/ Docker Hub] から取得されます:

# podman pull docker.io/debian

利用可能なタグについては Docker Hub のページを見てください。各 Debian リリース毎に standard と slim バージョンが存在します。

== トラブルシューティング ==

=== Add pause to process ===

WARN[0000] Failed to add pause process to systemd sandbox cgroup: Process org.freedesktop.systemd1 exited with status 1

これは以下により解決できます: https://github.com/containers/crun/issues/704

# echo +cpu +cpuset +io +memory +pids > /sys/fs/cgroup/cgroup.subtree_control

=== コンテナ DNS が有効化されない ===

WARN[0000] binary not found, container DNS will not be enabled

Podman のネットワークバックエンドとして {{Pkg|netavark}} を使用している場合、{{Pkg|aardvark-dns}} をインストールする必要があります。

=== シェルがログアウトするとコンテナが終了してしまう ===

マシンからログアウトすると、一部のユーザで Podman コンテナが停止されます。これを防ぐには、コンテナを実行しているユーザに対して[[systemd/ユーザー#systemd のユーザーインスタンスを自動起動|linger を有効化]]してください。

{{man|1|podman-auto-update|EXAMPLES}} で説明されているように、ユーザ systemd ユニットを作成することもできます。

=== Failed to move rootless netns ===

{{hc|$ docker-compose up|
ERRO[0000] failed to move the rootless netns slirp4netns process to the systemd user.slice: Process org.freedesktop.systemd1 exited with status 1
}}

{{ic|podman.service}} を[[起動/有効化]]することで解決できます。

=== Podman を 3.x から 4.0 にアップグレードした後に pause イメージのビルドでエラー ===

Error: building local pause image: finding pause binary: exec: "catatonit": executable file not found in $PATH

{{Pkg|catatonit}} パッケージを[[インストール]]すれば、このエラーを修正できます。

3.x から 4.0 へのアップグレードに関する詳細は、公式の[https://podman.io/blogs/2022/02/04/network-usage.html ブログ記事]を参照してください。

=== ルートレスモードでのコミット時にエラー ===

Error committing the finished image: error adding layer with blob "sha256:02823fca9b5444c196f1f406aa235213254af9909fca270f462e32793e2260d8": Error processing tar file(exit status 1) permitted operation

ストレージドライバが[[#ストレージ|ストレージ設定]]でオーバーレイされていることを確認してください。

=== ルートレスモードでブリッジネットワークを使用してコンテナを作成する際にエラー ===

[[AppArmor]] を使用している場合、{{ic|dnsname}} プラグインを有効にしてブリッジネットワークを使用してコンテナを作成すると、問題が発生する可能性があります:

{{hc|$ podman network create foo|
/home/''user''/.config/cni/net.d/foo.conflist
}}

{{hc|1=$ podman run --rm -it --network=foo docker.io/library/alpine:latest ip addr|2=
Error: command rootless-cni-infra [alloc 89398a9315256cb1938075c377275d29c2b6ebdd75a96b5c26051a89541eb928 foo festive_hofstadter ] in container 1f4344bbd1087c892a18bacc35f4fdafbb61106c146952426488bc940a751efe failed with status 1, stdout="", stderr="exit status 3\n"
}}

これは、次の行を {{ic|/etc/apparmor.d/local/usr.sbin.dnsmasq}} に追加することで解決できます:

owner /run/user/[0-9]*/containers/cni/dnsname/*/dnsmasq.conf r,
owner /run/user/[0-9]*/containers/cni/dnsname/*/addnhosts r,
owner /run/user/[0-9]*/containers/cni/dnsname/*/pidfile rw,

そして、AppArmor プロファイルをリロードします:

# apparmor_parser -R /etc/apparmor.d/usr.sbin.dnsmasq
# apparmor_parser /etc/apparmor.d/usr.sbin.dnsmasq

=== イメージが見つからない ===

Podman パッケージ内のファイルは上流からやってくるので、デフォルトではレジストリリストが存在しません。すなわち、デフォルトの状態でレジストリを指定せずにイメージを pull しようとすると、以下のようなエラーが発生してしまうのです:

Error: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

始めの構成は以下のような感じでしょう:

{{hc|/etc/containers/registries.conf.d/00-unqualified-search-registries.conf|2=
unqualified-search-registries = ["docker.io"]
}}

{{hc|/etc/containers/registries.conf.d/01-registries.conf|<nowiki>
[[registry]]
location = "docker.io"
</nowiki>}}

これは docker のデフォルト設定と等価です。

あるいは、あまり便利ではないが、レジストリ名の省略が設定されていないシステムと高い互換性がある方法として、{{ic|Containerfile}} や {{ic|Dockerfile}} で完全なレジストリパスを使用することもできます。

{{hc|Containerfile|
FROM docker.io/archlinux/archlinux
}}

=== Permission denied: OCI permission denied ===

{{hc|$ podman exec openvas_openvas_1 bash|
Error: crun: writing file `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/user.slice/libpod-b3e8048a9b91e43c214b4d850ac7132155a684d6502e12e22ceb6f73848d117a.scope/container/cgroup.procs`: Permission denied: OCI permission denied
}}

以下で解決できます: [https://bbs.archlinux.org/viewtopic.php?id=253966 BBS#253966]

$ env DBUS_SESSION_BUS_ADDRESS= podman ...
$ env DBUS_SESSION_BUS_ADDRESS= podman-compose ...

=== Pushing images to Docker Hub: access denied/authentication required ===

{{ic|podman push}} を使用してコンテナイメージを Docker Hub に push する際に、次のエラーが発生することがあります: {{ic|Requested access to the resource is denied}} または {{ic|Authentication required}}。以下のヒントが問題を修正する助けになるかもしれません:

* ローカルイメージにタグをつける: {{bc|# podman tag <localImage> docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag>}}
* タグ付きイメージを push する: {{bc|# podman push docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag> docker://docker.io/<dockerHubUsername>/<dockerHubRepository>:<Tag>}}
* docker.io、Docker Hub リポジトリ、Docker Hub Registry サーバにログインする:
: {{bc|<nowiki>
# podman login -u <DockerHubUsername> -p <DockerHubPassword> registry-1.docker.io
# podman login -u <DockerHubUsername> -p <DockerHubPassword> docker.io/<dockerHubUsername>/<dockerHubRepository>
# podman login -u <DockerHubUsername> -p <DockerHubPassword> docker.io
</nowiki>}}
* ログイン前に全レジストリからログアウトする。例: {{bc|# podman logout --all}}
* リポジトリの Docker Hub Collaborators タブで {{ic|<dockerHubUsername>}} を協力者 (collaborator) として追加する。

=== WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers ===

ルートレスで実行中の Buildah/Podman は、バインドマウントが共有されていることを期待します。バインドマウントが private に設定されていないか確認してください:

{{hc|$ findmnt -o PROPAGATION /|
PROPAGATION
private
}}

その場合、{{man|8|mount|Shared_subtree_operations}} を参照し、以下を実行して'''一時的に'''マウントを共有させることができます:

# mount --make-shared /

'''恒久的に'''共有させたい場合は、[[Fstab#使用法|/etc/fstab]] を編集して、対象のマウントに ''shared'' オプションを追加し、再起動してください。以下のようなエントリになります:

{{hc|/etc/fstab|2=
# <device> <dir> <type> <options> <dump> <fsck>
UUID=0a3407de-014b-458b-b5c1-848e92a327a3 / ext4 defaults,shared 0 1
}}

== 参照 ==

* [https://podman.io/ 公式ウェブサイト]

{{TranslationStatus|Podman|2023-04-10|775105}}

OpenSSH

2025-07-12T04:11:46Z

AshMyzk: 同期

[[Category:セキュアシェル]]
[[Category:サーバー]]
[[Category:OpenBSD]]
[[de:SSH]]
[[en:OpenSSH]]
[[es:OpenSSH]]
[[fr:OpenSSH]]
[[ru:OpenSSH]]
[[zh-hans:OpenSSH]]
{{Related articles start}}
{{Related|SSH 鍵}}
{{Related|Pam abl}}
{{Related|fail2ban}}
{{Related|sshguard}}
{{Related|Sshfs}}
{{Related|Syslog-ng}}
{{Related|SFTP chroot}}
{{Related|SCP と SFTP}}
{{Related|VPN over SSH}}
{{Related articles end}}
[[Wikipedia:ja:OpenSSH|OpenSSH]] (OpenBSD Secure Shell) は、[[セキュアシェル]] (SSH) プロトコルを用いてコンピュータネットワーク経由の暗号化された通信セッションを提供するコンピュータプログラム群です。OpenSSH は、SSH Communications Security によって提供されているプロプライエタリな Secure Shell ソフトウェアスイートのオープンソースな代替として作成されました。OpenSSH は OpenBSD プロジェクトの一部として開発されており、Theo de Raadt によって率いられています。

OpenSSH は、似た名前の OpenSSL と混同されることがあります。しかし、これらのプロジェクトの目的は異なり、開発チームも異なります。この似たような名前は、ただ単にゴールが似ているからです。

== インストール ==

{{Pkg|openssh}} パッケージを[[インストール]]してください。

== クライアントの使用 ==

サーバに接続するには、以下を実行してください:

$ ssh -p ''ポート'' ''ユーザ''@''サーバアドレス''

サーバが公開鍵認証のみを許可している場合、[[SSH 鍵]] の記事に従ってください。

=== 設定 ===

クライアントは、共通のオプションとホストを保存するように設定することができます。全プションは、グローバルに、あるいは特定のホストに制限して宣言することができます。例えば:

{{hc|~/.ssh/config|# グローバルなオプション
User ''user''

# 特定のホストのオプション
Host ''myserver''
Hostname ''server-address''
Port ''port''
}}

このような設定を用いると、以下の2つのコマンドは等価になります:

$ ssh -p ''port'' ''user''@''server-address''
$ ssh ''myserver''

詳細は {{man|5|ssh_config}} を見てください。

一部のオプションには等価なコマンドラインスイッチがありません。しかし、コマンドラインで {{ic|-o}} フラグを用いることで設定オプションを指定できます。例えば: {{ic|1=-oKexAlgorithms=+diffie-hellman-group1-sha1}}。

== サーバの使用 ==

{{ic|sshd}} は OpenSSH サーバのデーモンです。{{ic|/etc/ssh/sshd_config}} で設定され、{{ic|sshd.service}} によって管理されます。設定を変更する際は、サーバを再起動する前に {{ic|sshd}} をテストモードで使用し、サーバが正しく起動できることを確認してください。設定が有効である場合は、何も出力されません。

# sshd -t

=== 設定 ===

一部のユーザにのみアクセスを許可するには、以下の行を追加してください:

AllowUsers ''user1 user2''

一部のグループにのみアクセスを許可するには:

AllowGroups ''group1 group2''

素晴らしいウェルカムメッセージを ({{ic|/etc/issue}} ファイルなどから) 追加するには、{{ic|Banner}} オプションを設定してください:

Banner /etc/issue

公開ホスト鍵と秘密ホスト鍵は、''sshdgenkeys'' [[#デーモンの管理|サービス]]によって {{ic|/etc/ssh}} 内に自動で生成されます。{{ic|sshd_config}} 内の {{ic|HostKeyAlgorithms}} オプションによって一部の署名アルゴリズムしか許可されていない場合でも、鍵が存在しない場合、再生成されます。[[SSH 鍵#認証鍵の種類を選択|ed25519、ecdsa、そして rsa]] アルゴリズムに基づく3組の鍵のペアが提供されます。sshd に特定の鍵を使用させるには、以下のオプションを指定してください:

HostKey /etc/ssh/ssh_host_ed25519_key

サーバを WAN に公開するつもりであるならば、以下のようにデフォルトのポートを 22 から別のランダムで大きい値に変更することが推奨されます:

Port 39901

{{Tip|
* 一般的なサービスにまだ割り当てられていない代替ポートを探すには、[[Wikipedia:List of TCP and UDP port numbers|TCP と UDP のポート番号一覧]]を見てください。また、{{ic|/etc/services}} にあるローカルのポート番号情報を見ることもできます。デフォルトのポート 22 番からポートを変更すると、自動化された認証試行によるログエントリ数が減るでしょう。しかし、そのような攻撃を排除することはできません。関連する情報は [[ポートノッキング]] を参照してください。
* パスワードログインを完全に無効化することが推奨されます。そうすることで、セキュリティが格段に向上します。詳細は [[#公開鍵認証を強制する]] を参照してください。他の推奨されるセキュリティ手法については [[#保護]] を参照してください。
* 設定ファイル内に複数の {{ic|Port ''port_number''}} 行を記述することにより、OpenSSH に複数のポートをリッスンさせることができます。
* 新しい (或いは存在しない) ホスト鍵ペアは、置き換えたいペアを {{ic|/etc/ssh}} から削除し {{ic|ssh-keygen -A}} を root として実行することで、生成することができます。
}}

=== デーモンの管理 ===

{{ic|sshd.service}} を[[起動/有効化]]してください。これは、SSH デーモンを永続的にアクティブ状態に保ち、各着信接続に対してフォークします。

{{Note|Systemd のソケットアクティベーションを使用する {{ic|sshd.socket}} は、DOS (サービス拒否) の影響を受けやすいため、{{Pkg|openssh}} 8.0p1-3 で削除されました。詳細は {{Bug|62248}} を参照してください。{{Pkg|openssh}} 8.0p1-3 に更新する時に {{ic|sshd.socket}} が有効化されていた場合、{{ic|sshd.socket}} と {{ic|sshd@.service}} ユニットは {{ic|/etc/systemd/system/}} にコピーされ、[[ヘルプ:読み方#systemd ユニットのコントロール|再有効化]]されます。これは、既存のセットアップを破壊しないためだけに行われるのであって、ユーザは依然として {{ic|sshd.service}} に移行することが推奨されます。}}

{{Warning|{{ic|sshd.socket}} の使用を継続するならば、このユニットの問題に注意してください:
* {{ic|sshd.socket}} ユニットは (例えばメモリ不足の状況などにより) 失敗する場合があり、{{ic|1=Restart=always}} はソケットユニットに対しては指定できません。[https://github.com/systemd/systemd/issues/11553 systemd issue 11553] を参照。
* ソケットアクティベーションの使用は、接続が多すぎるとサービスのアクティブ化が拒否される可能性があるため、サービス拒否を引き起こす可能性があります。{{Bug|62248}} を参照。
}}

{{Note|{{ic|sshd.socket}} を使用すると {{ic|ListenAddress}} の設定が無効化され、任意のアドレスを介して接続できるようになってしまいます。{{ic|ListenAddress}} の設定に効力を持たせるには、{{ic|sshd.socket}} を[[編集]]して、ポートと IP の''両方''を {{ic|ListenStream}} で設定しなければなりません (例: {{ic|1=ListenStream=192.168.1.100:22}})。また、{{ic|[Socket]}} セクションに {{ic|1=FreeBind=true}} も追加しなければなりません。さもないと、IP アドレスを設定した時に {{ic|ListenAddress}} を指定した時と同じ欠点が生じます: ネットワークが時間内に立ち上がっていない場合、ソケットは起動に失敗します。}}

{{Tip|ソケットアクティベーションを使用すると、各接続に対して {{ic|sshd@.service}} の一時的なインスタンスが (異なるインスタンス名で) 開始されます。ゆえに、{{ic|sshd.socket}} もデーモンの通常の {{ic|sshd.service}} も、接続試行をログでモニタできません。ソケットアクティベートされた SSH インスタンスのログは、{{ic|journalctl -u "sshd@*"}} を root として実行するか、{{ic|journalctl /usr/bin/sshd}} を root
として実行することで、確認することができます。}}

=== 保護 ===

SSH によるリモートログインを許可することは管理業務においては良いことですが、サーバーのセキュリティに脅威を及ぼすことにもなりえます。総当り攻撃の標的になりやすいので、SSH のアクセスは制限して、第三者がサーバーにアクセスできないようにする必要があります。

{{Pkg|ssh-audit}} は、サーバとクライアントの設定の自動化された解析を提供します。このトピックに関して、いくつか他のガイドやツールが利用できます。例えば:

* [[MozillaWiki:Security/Guidelines/OpenSSH|Mozilla Infosec Team による記事]]
* [https://www.ssh-audit.com/hardening_guides.html SSH 堅牢化ガイド]

==== 公開鍵認証を強制する ====

デフォルトでは、クライアントが公開鍵で認証できない場合、SSH サーバはパスワード認証にフォールバックします。なので、悪意のあるユーザがパスワードの[[#ブルートフォース攻撃に対する保護|ブルートフォース]]によるアクセスを試みることができてしまいます。このような攻撃から保護する最も効果的な方法の1つが、パスワードログインを完全に無効化し、[[SSH 鍵]]の使用を強制することです。これは、デーモンの設定ファイルで以下のオプションを設定することで可能です:

{{hc|/etc/ssh/sshd_config.d/20-force_publickey_auth.conf|
PasswordAuthentication no
AuthenticationMethods publickey
}}

{{Warning|これを設定に追加する前に、SSH アクセスを必要とする全アカウントが、対応する {{ic|authorized_keys}} ファイルで公開鍵認証をセットアップしていることを確認してください。詳細は [[SSH 鍵#リモートサーバーに公開鍵をコピー]] を参照してください。}}

==== 二要素認証と公開鍵 ====

SSH は、認証に複数の方法を要求するようにセットアップすることができます。{{ic|AuthenticationMethods}} オプションを使うことで、どの認証方法を要求するかを指定することができます。これにより、公開鍵と二要素認証を使用することができます。

===== 認証プロバイダ =====

Google Authenticator をセットアップする方法については [[Google Authenticator]] を参照してください。

[https://duo.com/ Duo] の場合、{{ic|pam_duo.so}} モジュールを提供する {{AUR|duo_unix}} を[[インストール]]してください。必須の Duo 認証情報 (Integration Key、Secret Key、API Hostname) をセットアップする方法に関するインストラクションは [https://duo.com/docs/duounix Duo Unix ドキュメント] を参照してください。

===== PAM セットアップ =====

{{Accuracy|1=The distribution defaults to {{ic|KbdInteractiveAuthentication no}} since [https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/commit/1d834b1fb688e148797c39cffd95eac3404ef894]. Later, the lexical order of the defaults was adjusted due to {{Bug|79285}} to allow for higher priority user snippets, which would match below {{ic|20-pam.conf}}. However, a [https://bbs.archlinux.org/viewtopic.php?id=300451 BBS thread] appears to be resolved by ordering custom after {{ic|99-archlinux.conf}} defaults only.}}

[[PAM]] を OpenSSH で使用するには、以下のファイルを編集してください:

{{hc|/etc/ssh/sshd_config.d/20-pam.conf|
KbdInteractiveAuthentication yes
AuthenticationMethods publickey keyboard-interactive:pam
}}

これで、PAM セットアップによって要求されるユーザ認証か公開鍵の'''どちらか一方'''でログインできます。

一方、PAM セットアップによって要求されるユーザ認証と公開鍵の'''両方'''でユーザを認証したい場合、AuthenticationMethods の分割にスペースではなくコンマを使用してください:

{{hc|/etc/ssh/sshd_config.d/20-pam.conf|
KbdInteractiveAuthentication yes
AuthenticationMethods publickey''','''keyboard-interactive:pam
}}

要求される公開鍵と pam 認証の'''両方'''を用いて、パスワード要件を無効化すると良いでしょう:

{{hc|/etc/pam.d/sshd|
auth required pam_securetty.so #disable remote root
#Require google authenticator
auth required pam_google_authenticator.so
#But not password
#auth include system-remote-login
account include system-remote-login
password include system-remote-login
session include system-remote-login
}}

==== ブルートフォース攻撃に対する保護 ====

ブルートフォース (総当り) は単純なコンセプトです: 大量のランダムなユーザ名とパスワードの組み合わせを用いて、あるウェブページやサーバの SSH のようなログインプロンプトに絶え間なくログインを試みるのです。

[[iptables]] については [[ufw#ufw によるレート制限]] や [[シンプルなステートフルファイアウォール#ブルートフォース攻撃]] を参照してください。

バージョン 9.8 以降、[[fail2ban]] に似た基本的な保護機能が実装されました。デフォルトでは {{ic|PerSourcePenalties}} オプションに合理的なデフォルト値が設定されています。様々な条件でソースアドレスによってクライアントにペナルティが掛けられ、接続を一定期間拒否します。

あるいは、ブルートフォースを試みている者を自動でブロックするスクリプトを使うことでブルートフォースから保護することができます。

* 信頼された場所からの着信 SSH 接続のみを許可する。
* [[fail2ban]] か [[sshguard]] を使用して、パスワード認証に失敗しすぎた IP アドレスを自動的にブロックする。
* [https://github.com/h0tw1r3/pam_shield pam_shield] を使用して、特定の時間内に多くのログイン試行を行った IP アドレスをブロックする。[[fail2ban]] や [[sshguard]] とは対照的に、このプログラムはアカウントへのログイン成功や失敗を考慮しません。

==== root ログインの制限 ====

{{Out of date|現在のバージョンでは、root ログインは上流でデフォルトで無効化されています。}}

一般的に、root ユーザが制限無しで SSH を介してログインできることはバッドプラクティスだと考えられています。セキュリティを向上させるために SSH の root アクセスを制限する方法は2つあります。

===== 拒否 =====

Sudo を使うことで、root アカウントの認証を行うことなく、必要に応じて root 権限を選択的に付与することができます。このため SSH による root ログインを拒否して、攻撃者にパスワードに加えて (root でない) ユーザー名も推測させる必要を生じさせることで、ブルートフォース攻撃を困難にすることが可能です。

デーモンの設定ファイルで "Authentication" セクションを編集することで SSH からの root ユーザのログインを拒否するように設定できます。{{ic|PermitRootLogin}} を {{ic|no}} に設定してください:

{{hc|/etc/ssh/sshd_config.d/20-deny_root.conf|PermitRootLogin no}}

次に、SSH デーモンを[[再起動]]してください。

これで、SSH を使って root でログインすることはできなくなります。ただし、通常ユーザーでログインしてから [[su]] や [[sudo]] を使ってシステム管理を行うことは依然として可能です。

===== 制限 =====

自動的な作業の中にも、リモートによるフルシステムバックアップなど、root 権限を必要とするものがあります。セキュアな方法で root を許可したい場合、SSH による root ログインを無効化する代わりに、特定のコマンドだけ root ログインを許可することができます。{{ic|~root/.ssh/authorized_keys}} を編集して、以下のように特定のキーの前にコマンドを記述します:

command="rrsync -ro /" ssh-ed25519 ...

上記の設定で、特定の鍵を使ってログインした場合はクォートで囲ったコマンドを実行できるようになります。

ログイン時に root ユーザーの名前を出すことで攻撃する対象が増えてしまうことに対しては {{ic|sshd_config}} に以下を追加することで埋め合わせができます:

PermitRootLogin forced-commands-only

上記の設定は root が SSH で実行できるコマンドを制限するだけでなく、パスワードの使用も無効化して、root アカウントでは強制的に公開鍵認証を使うようになります。

root で使えるコマンドは制限しないで公開鍵認証の強制だけをするという手もあり、それでもブルートフォース攻撃はほぼ不可能です。その場合、以下を設定:

PermitRootLogin prohibit-password

==== authorized_keys ファイルのロック ====

{{Warning|このファイルをロックしても、ユーザの間違いや特定の単純な対人攻撃からの保護しかできません。この方法は、悪意のあるプログラムや侵入に対するあらゆる保護も提供'''しません'''。多要素認証、ファイアウォール、そして縦深防御を用いて、侵入を未然に防いでください。}}

何らかの理由により、疑いのあるユーザに既存の鍵を追加/変更させるべきではないと思われる場合、そのファイルを操作できないようにできます。

サーバでは、ユーザの {{ic|authorized_keys}} ファイルを読み取り専用にして、他の全パーミッションを禁止してください:

$ chmod 400 ~/.ssh/authorized_keys

ユーザがパーミッションを元に戻せないようにするには、{{ic|authorized_keys}} ファイルに[[ファイルのパーミッションと属性#ファイルの属性|変更不可のビットを設定]]してください。ユーザが {{ic|~/.ssh}} ディレクトリをリネームして新しい {{ic|~/.ssh}} ディレクトリと {{ic|authorized_keys}} ファイルを作成できないようにするには、{{ic|~/.ssh}} ディレクトリにも変更不可のビットを設定してください。鍵を追加/削除するには、{{ic|authorized_keys}} から変更不可のビットを削除して一時的に書き込み可能にする必要があります。

{{Tip|[[Audit フレームワーク#ファイルとディレクトリへのアクセスを監査する|auditd]] などを用いて、{{ic|authorized_keys}} ファイルの変更を記録することが推奨されます。}}

==== SSH 証明書 ====

一般的な SSH 鍵と手動でのフィンガープリントの検証は、一人の管理者によって管理されている少数のホストにおいては簡単でしょうが、この認証方法は拡張性が全くありません。一定数のサーバをいくつかのユーザが SSH を通してアクセスする必要がある場合、全てのホストの SSH 公開鍵フィンガープリントを手動でセキュアかつ確実に検証するのは、ほぼ不可能です。

これに対する解決策は、SSH 証明書を使うことです。SSH 証明書を使えば、SSH のデフォルトの Trust On First Use アプローチよりも拡張性の高い信用の鎖によって、公開鍵の正当性を自動で検証できます。SSH 証明書は、基本的には通常の SSH 公開鍵ですが、信頼されている認証局からの署名が付け加えられおり、これにより鍵の正当性を検証します。

===== インフラストラクチャ用のホスト認証局の鍵を作成する =====

$ ssh-keygen -t ed25519 -f ~/.ssh/ca_host_key -C 'Host certificate authority for *.example.com'

認証局の秘密鍵はセキュアに保存されているべきです。鍵の抽出を防止する機構が備わっている [[Nitrokey]] や [[YubiKey]] といったスマートカードやハードウェアトークン上に保存するのが理想です。

===== サーバの SSH ホスト公開鍵を署名する =====

サーバの公開鍵を、認証局の秘密鍵が保存されているローカルのシステムにコピーし、サーバの公開鍵を署名してください:

$ ssh-keygen -h -s ~/.ssh/ca_key -I certLabel -n server01.example.com ./ssh_host_ed25519_key.pub

===== 新しい証明書を移動し、sshd にそれを使わせる =====

生成された証明書 {{ic|ssh_host_ed25519_key-cert.pub}} は、サーバの {{ic|/etc/ssh/}} にコピーする必要があります。

{{hc|/etc/ssh/sshd_config.d/20-ed25519_key.conf|
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
}}

===== 認証局を信頼するように全てのクライアントを設定する =====

{{hc|~/.ssh/known_hosts|
@cert-authority *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKL8gB/pjuff005YNazwMCqJpgsXAbQ3r4VStd/CRKwU Host certificate authority for *.example.com
}}

{{Warning|サーバが識別用の証明書を提供しないと、デフォルトで公開鍵認証がフォールバックとして使用されてしまいます。}}

===== SSH ユーザ証明書 =====

ユーザの数やデプロイ方法にもよりますが、SSH ユーザ鍵を証明書と共に使用することもできます。多くの ssh ユーザが存在する組織では、この方法でユーザ鍵のデプロイをセキュアに管理することが強く推奨されます。

ユーザ証明書のデプロイは、基本的にはサーバの ID と同じように機能します。詳細と方法については [[Wikibooks:OpenSSH/Cookbook/Certificate-based Authentication]] で見られます。

===== 証明書のデプロイを自動化する =====

多くのオープンソースなツールによって、SSH 証明書のデプロイを自動化する方法が提供されています。人気なものとしては例えば以下があります:

* [https://docs.ansible.com/ansible/latest/collections/community/crypto/openssh_cert_module.html Ansible - openssh_cert module]
* [https://www.privacyidea.org/ privacyIDEA - 認証サーバ]
* [https://theoapp.readthedocs.io/en/latest/ Theo App - 認可された鍵のマネージャ]

==== SSHFP レコード ====

[[Wikipedia:SSHFP record|Secure Shell fingerprint record (SSHFP)]] は、DNS におけるオプションのリソースレコードで、SSH 鍵をホスト名と関連付けます。信用された CA 証明書をサーバー上にアップロードする代わりに DNSSEC を使用することで、公開サーバー上の SSH フィンガープリントを検証することができます。これにより、管理されていないクライアントも鍵のフィンガープリントの有効性を検証することができます。

===== レコードエントリを生成する =====

16進数の鍵フィンガープリントを生成して、DNS レコードに記録するには、対象サーバー上でハッシュ値を作成してください。

$ ssh-keygen -r host.example.com

このコマンドで、指定したドメインの利用可能な全 SSH 鍵を読み出し、有効な SSHFP レコードを出力します。この出力されたレコードを、影響するドメインの DNS エントリに記録することができます。

===== クライアントの設定 =====

SSHFP レコードとして保存されている SSH 鍵フィンガープリントを自動的に取得して信用するには、以下の設定を ssh クライアント側の設定ファイルに追加してください:

{{hc|~/.ssh/config|
# global options
Match all
VerifyHostKeyDNS yes
}}

対象ホストに有効な SSHFP レコードがあり、そのレコードが有効な DNSSEC 署名で検証されると、ホストが本物であるかどうかを尋ねるプロンプトが表示されずに、フィンガープリントが自動的に受理されます。DNS レコードが DNSSEC によって検証されない場合は、フィンガープリントが正しいかどうかを尋ねるプロンプトが代わりに表示されます。

===== SSHFP レコードを生成する =====

ドメインの SSH フィンガープリントを知りたい場合は、''ssh-keyscan'' を使うことで有効な DNS レコードの形式で SSH フィンガープリントを取得できます。(注: デフォルトでは、利用可能な鍵タイプすべてのフィンガープリントが SHA1 と SHA256 の両方で出力されます。)

{{hc|$ ssh-keyscan -D github.com|
; github.com:22 SSH-2.0-babeld-57ca1323
; github.com:22 SSH-2.0-babeld-57ca1323
github.com IN SSHFP 1 1 6f4c60375018bae0918e37d9162bc15ba40e6365
github.com IN SSHFP 1 2 b8d895ced92c0ac0e171cd2ef5ef01ba3417554a4a6480d331ccc2be3ded0f6b
; github.com:22 SSH-2.0-babeld-57ca1323
github.com IN SSHFP 3 1 3358ab5dd3e306c461c840f7487e93b697e30600
github.com IN SSHFP 3 2 a764003173480b54c96167883adb6b55cf7cfd1d415055aedff2e2c8a8147d03
; github.com:22 SSH-2.0-babeld-57ca1323
github.com IN SSHFP 4 1 e9619e2ed56c2f2a71729db80bacc2ce9ccce8d4
github.com IN SSHFP 4 2 f83898df0bef57a4ee24985ba598ac17fccb0c0d333cc4af1dd92be14bc23aa5
; github.com:22 SSH-2.0-babeld-57ca1323
}}

SSH フィンガープリントは一般的には公開鍵の SHA256 ハッシュ値を base64 エンコードしたものですが、SSHFP レコードは鍵のフィンガープリントを16進数で保存します。そのため、通常 SHA256 でフィンガープリントを記録している known_hosts ファイルやその他の文書にある値と比べるために、レコードを base64 の形式に変換する必要があります。

$ echo "SSHFP-fingerprint" | xxd -r -p | base64

鍵タイプ ed25519 の SHA256 フィンガープリントに16進数を使用している github.com の例です。

{{hc|$ echo "f83898df0bef57a4ee24985ba598ac17fccb0c0d333cc4af1dd92be14bc23aa5" {{!}} xxd -r -p {{!}} base64|2=
+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU=
}}

known_hosts エントリと比べるには:

$ ssh-keygen -l -f ~/.ssh/known_hosts

===== DNS から手動で SSHFP レコードを取得する =====

$ dig SSHFP targetdomain.tld +short

== ヒントとテクニック ==

=== 暗号化 SOCKS トンネル ===

暗号化トンネルは、安全でない様々なワイヤレス接続を使用するノートパソコンユーザにとって有用です。必要なのは SSH サーバーが安全な場所 (家や仕事場など) で動作していることだけです。[https://dyn.com/dns/ DynDNS] などのダイナミック DNS サービスを利用すれば IP アドレスを覚える必要もありません。

==== 接続の開始 ====

$ ssh -TND 4711 ''user''@''host''

パスワードを入力すると接続が行われます。{{Ic|N}} フラグはインタラクティブプロンプトを無効化し、{{Ic|D}} フラグは listen するローカルポートを指定します (ポート番号は何でもかまいません)。{{Ic|T}} フラグは疑似 tty アロケーションを無効化します。

verbose ({{Ic|-v}}) フラグを追加することで、接続が成功しているか確認することができます。

==== ブラウザ (或いはその他のプログラム) の設定 ====

上記の手順はウェブブラウザや他のプログラムと組み合わせた場合にのみ有用です。SSH は SOCKS v4 と SOCKS v5 の両方をサポートしているので、どちらかを使用できます。

* Firefox の場合:
# ''設定 > 一般 > ネットワーク設定'' を開き、''接続設定...'' をクリックします。
# 新しくウィンドウが開くので、''手動でプロキシーを設定する'' オプションにチェックを入れ、''SOCKS ホスト'' 欄には {{ic|localhost}} と、''ポート'' 欄にはポート番号 (上記の例では {{ic|4711}}) を入力します。
# Firefox を再起動します。
:{{Note|Firefox は自動的に SOCKS トンネル経由で DNS リクエストを発行しません。''SOCKS vN を使用するときは DNS もプロキシーを使用する'' (v4 か v5) にチェックを入れることでこの問題を回避できます。}}
* Chromium の場合:
# SOCKS の設定は環境変数かコマンドラインオプションで設定できます。例えば、以下の関数のどちらかを {{ic|.bashrc}} に追加することで可能です:
: {{bc|<nowiki>
secure_chromium() {
local port=4711
export SOCKS_SERVER=localhost:$port
export SOCKS_VERSION=5
(chromium > /dev/null 2>&1 &)
}

secure_chromium() {
local port=4711
(chromium --proxy-server="socks://localhost:$port" > /dev/null 2>&1 &)
}
</nowiki>}}
# ターミナルを開き {{bc|$ secure_chromium}} と実行します。

==== ローカルの TUN インターフェイスをセットアップする ====

これは最初はより複雑ですが、SOCKS プロキシを使わせたいアプリケーション全てを手動で設定する必要はありません。ローカルの TUN インターフェイスをセットアップし、このインターフェイス経由でトラフィックをルーティングさせる必要があります。

[[VPN over SSH#badvpn とトンネルインターフェイスをセットアップする]] を見てください。

=== X11 フォワーディング ===

X11 フォワーディングは、リモートシステムで X11 プログラムを動作させて、グラフィカルインターフェイスをローカルのクライアントマシンで表示させるメカニズムです。X11 フォワーディングではリモートホストに X11 システムを完全にインストールさせる必要はなく、''xauth'' をインストールするだけで十分です。''xauth'' は、X11 セッションの認証を行うために必要なサーバーとクライアントによって使用される {{ic|Xauthority}} の設定を管理するユーティリティです ([http://xmodulo.com/2012/11/how-to-enable-x11-forwarding-using-ssh.html ソース])。

{{Warning|X11 フォワーディングにはセキュリティ的に重要な問題があります。{{ic|ssh}}、{{ic|sshd_config}}、そして {{ic|ssh_config}} のマニュアルページの該当するセクションを読んで最低限の知識をつけてください。[https://security.stackexchange.com/questions/14815/security-concerns-with-x11-forwarding この StackExchange の質問] も参照。}}

==== セットアップ ====

===== リモート側 =====

* {{Pkg|xorg-xauth}} パッケージを[[インストール]]してください
* {{ic|/etc/ssh/ssh'''d'''_config}} 内で:
** {{ic|X11Forwarding}} を ''yes'' に設定してください
** {{ic|AllowTcpForwarding}} と {{ic|X11UseLocalhost}} オプションが ''yes'' に設定されおり、{{ic|X11DisplayOffset}} が ''10'' に設定されていることを確認してください (これらの設定は、何も変更していなければ、デフォルト値です。{{man|5|sshd_config}} を参照)。
* そして、[[#デーモンの管理|''sshd'' デーモン]]を再起動してください。

===== クライアント側 =====

* {{Pkg|xorg-xauth}} パッケージを[[インストール]]してください。
* コマンドラインで日和見的な接続を行うための {{ic|-X}} スイッチを指定するか、或いは[[#設定|クライアントの設定]]で {{ic|ForwardX11}} を ''yes'' に設定して、{{ic|ForwardX11}} オプションを有効化してください。

{{Tip|GUI の描画がおかしい場合やエラーが表示されるときは {{ic|ForwardX11Trusted}} オプションを有効にできます (コマンドラインでは {{ic|-Y}} スイッチ)。X11 フォワーディングが [https://www.x.org/wiki/Development/Documentation/Security/ X11 SECURITY 拡張] の制御から外れるようになります。使用するときはセクション冒頭の[[#X11 フォワーディング|警告]]を読んでください。}}

==== 使用方法 ====

通常通りリモートマシンにログオンしてください。クライアントの設定ファイルで ''ForwardX11'' が有効化されていない場合は {{ic|-X}} スイッチを指定してください:

$ ssh -X ''user@host''

グラフィカルアプリケーションを実行しようとしてエラーが発生する場合は、代わりに ''ForwardX11Trusted'' を試してください:

$ ssh -Y ''user@host''

{{ic|X11 forwarding request failed}} と出力される場合、リモートマシンでセットアップをやり直してください。X11 フォワーディングのリクエストが成功したら、リモートサーバ上の任意の X プログラムを実行でき、プログラムがローカルセッションにフォワーディングされます:

$ xclock

{{ic|Can't open display}} という内容が含まれるエラーが出力される場合は、{{ic|DISPLAY}} が適切に設定されていないことを意味します。

一部のアプリケーションは、実行中のインスタンスのチェックをローカルのマシンで行うため、注意してください。[[Firefox]] がその例です: すでに実行中の Firefox を閉じるか、以下の起動パラメータを使用してリモートインスタンスをローカルマシン上で起動してください:

$ firefox --no-remote

接続時に "X11 forwarding request failed on channel 0" と表示される場合 (サーバーの {{ic|/var/log/errors.log}} に "Failed to allocate internet-domain X11 display socket" と出力される場合)、{{Pkg|xorg-xauth}} パッケージがインストールされていることを確認してください。上手く機能しない場合、以下の設定を試してみてください:

* ''サーバ''の {{ic|ssh'''d'''_config}} で {{ic|AddressFamily any}} オプションを有効にする。
* 或いは、''サーバ''の {{ic|ssh'''d'''_config}} で {{ic|AddressFamily}} オプションを inet に設定する。
IPv4 で Ubuntu クライアントを使っている場合は inet に設定することで問題が解決する場合があります。

SSH サーバーの他のユーザーで X アプリケーションを実行するには SSH でログインしているユーザーの {{Ic|xauth list}} の認証行を {{Ic|xauth add}} する必要があります。

{{Tip|{{ic|X11 Forwarding}} の問題をトラブルシューティングする有用なリンクをいくつか挙げます: [https://unix.stackexchange.com/a/12772]、[https://unix.stackexchange.com/a/46748]、[https://superuser.com/a/805060]。}}

=== 他のポートのフォワーディング ===

SSH の X11 の組み込みサポートに加えて、SSH には任意の TCP 接続をセキュアにトンネル化することもできます。ローカルフォワーディングとリモートフォワーディングの両方が使えます。

ローカルフォワーディングはローカルマシンのポートを開き、ローカルマシンに対する接続はリモートホストにフォワーディングされ、リモートホストから指定された宛先に転送されます。転送先をリモートホストと同じにすることで、同一マシンに対してセキュアシェルやセキュアな [[VNC]] 接続を提供します。ローカルフォワーディングは {{Ic|-L}} スイッチで利用することができ {{Ic|<トンネルポート>:<宛先アドレス>:<宛先ポート>}} という形式で転送先を指定します。

ゆえに:

$ ssh -L 1000:mail.google.com:25 192.168.0.100

上記のコマンドは SSH で {{ic|192.168.0.100}} にログインしてシェルを開き、ローカルマシンの TCP ポート 1000 から mail.google.com のポート 25 へのトンネルが作成されます。接続が確立すると {{ic|localhost:1000}} への通信は Gmail の SMTP ポートに接続されます。Google から見ると、{{ic|192.168.0.100}} から接続が来ているように見えます (必ずしも接続と一緒にデータが運ばれるとは限りません)。データはローカルマシンと {{ic|192.168.0.100}} との間でセキュアに運ばれますが、{{ic|192.168.0.100}} と Google との間はセキュアではありません (他の方法を取らない限り)。

似たように:

$ ssh -L 2000:192.168.0.100:6001 192.168.0.100

このコマンドは、{{ic|localhost:2000}} に接続することができ、リモートホストのポート 6001 へ透過的に送信されます。前者の例は、vncserver ユーティリティ ([[tightvnc]] パッケージの一部) を使用して VNC 接続を行う際に便利です。便利とはいえ、セキュリティの問題があります。

リモートフォワーディングは SSH トンネルとローカルマシンを通してリモートホストから任意のホストに接続できるようにします。ローカルフォワーディングとは逆の機能であり、ファイアウォールによってリモートホストの接続が限られている場合などに有用です。リモートフォワーディングは {{Ic|-R}} スイッチで使うことができ {{Ic|<トンネルポート>:<宛先アドレス>:<宛先ポート>}} という形式で転送先を指定します。

ゆえに:

$ ssh -R 3000:irc.libera.chat:6667 192.168.0.200

上記のコマンドは {{ic|192.168.0.200}} にシェルを立ち上げて、{{ic|192.168.0.200}} からローカルホストの 3000 番ポートへの接続をトンネルを通して送信し、それから irc.freenode.net のポート 6667 に転送します。ポート 6667 がブロックされている場合でもリモートホストから IRC プログラムを利用することができるようになります。

ローカルフォワーディングとリモートフォワーディングはどちらもセキュアなゲートウェイとして使用することができます。{{Ic|<tunnel address>:<tunnel port>:<destination address>:<destination port>}} のようにバインドアドレスをつかうことで、SSH や SSH デーモンを動かしていなくても他のコンピュータが SSH トンネルを利用することが可能です。{{Ic|<tunnel address>}} はトンネルの入り口となるマシンのアドレスです: {{Ic|localhost}}, {{Ic|*}} (あるいは空)。特定のアドレス経由の接続、ループバックインターフェイス経由の接続、全てのインターフェイス経由の接続を許可します。デフォルトでは、フォワーディングはトンネルの入り口のマシンからの接続だけに制限されており {{Ic|<tunnel address>}} は {{Ic|localhost}} に設定されています。ローカルフォワーディングは特に設定が必要ありませんが、リモートフォワーディングはリモートサーバーの SSH デーモンの設定によって制限を受けます。詳しくは {{Ic|sshd_config(5)}} の {{Ic|GatewayPorts}} オプションを見てください。

=== 踏み台ホスト ===

場合によっては、接続先の SSH デーモンに直接接続できず、踏み台サーバー ([[Wikipedia:bastion host|要塞サーバー]]とも) を使わざるを得ないことがあります。よって、2つ以上の SSH トンネルを接続して、それぞれのサーバーに対してローカルの鍵で認証します。SSH エージェントの転送 ({{ic|-A}}) と疑似端末の割当 ({{ic|-t}}) を使って以下のようにローカルの鍵を転送します:

$ ssh -A -t -l user1 bastion1 \
ssh -A -t -l user2 intermediate2 \
ssh -A -t -l user3 target

ProxyCommand オプションを使えばこれを自動化することができます:

$ ssh -o ProxyCommand="ssh -W %h:%p bastion.example.org" targetserver.example.org

{{ic|-J}} フラグで ProxyJump オプションを使用すれば、これをより簡単かつセキュアに行うことができます:

$ ssh -J user1@bastion1,user2@intermediate2 user3@target

{{ic|-J}} ディレクティブで指定するホストはカンマで区切り、指定された順番で接続されます。{{ic|user...@}} の部分は必須ではありません。{{ic|-J}} で指定したホストは ssh の設定ファイルを使うため、必要であればホスト毎にオプションを設定することが可能です。

ProxyCommand オプションと ProxyJump オプションの主な違いは、後者は踏み台ホスト上のシェルを必要としないところにあります。その結果、ユーザのログイン認証情報への踏み台サーバでのアクセスや SSH エージェントフォワーディングが必要なくなります。ProxyJump オプションでは、ssh クライアントは踏み台サーバを通して直接ターゲットのサーバへ接続し、エンドツーエンドの暗号化されたチャネルをクライアントとターゲットサーバとの間で確立します。

設定ファイルにも、{{ic|-J}} フラグと等価なものとして {{ic|ProxyJump}} オプションがあります。詳細は {{man|5|ssh_config}} を見てください。

=== リレーを介したリバース SSH ===

アイデアとしては、クライアントは別のリレーを使ってサーバに接続し、サーバはリバース SSH トンネルを使って同じリレーに接続します。これは、サーバが NAT 内にあり、リレーが、ユーザがアクセス可能なプロキシとして使用されている、パブリックにアクセス可能な SSH サーバである場合に便利です。ゆえに、クライアントの鍵がリレーとサーバの両方に対して認可されていることが前提条件であり、サーバはリレーに対してもリバース SSH 接続に対しても認可されている必要があります。

以下の設定例では、{{ic|''user1''}} がクライアント上で使用されているユーザアカウントであり、{{ic|''user2''}} は relay 上のアカウント、{{ic|''user3''}} がサーバー上のアカウントであるとします。まず、以下のコマンドでサーバとリバーストンネルとの接続が確立している必要があります (2222番ポートを使うものとします):

$ ssh -R 2222:localhost:22 -N ''user2''@''relay''

これは、スタートアップスクリプトや systemd サービス、[[#Autossh - SSH セッションとトンネルの自動再起動|autossh]]、{{AUR|sidedoor}} を使って自動化することもできます。

クライアント側では、以下のコマンドで接続を確立させます:

$ ssh -t ''user2''@''relay'' ssh ''user3''@localhost -p 2222

{{Note|{{ic|ssh ''user3''@''relay'' -p 2222}} では、リレーサーバーのファイアウォールで対象のポートを開いておくとともに、他のアドレスからこのポートへの接続を許可しておく必要があります。}}

リバーストンネルとの接続を確立させるためのリモートのコマンドは、relay の {{ic|authorized_keys}} に以下のような {{ic|command}} フィールドを含めることで、定義できます:

{{hc|~/.ssh/authorized_keys|2=command="ssh ''user3''@localhost -p 2222" ''ssh-ed25519'' ''KEY2'' ''user1''@''client''}}

この場合、接続は以下のコマンドで確立できます:

$ ssh ''user2''@''relay''

または、{{ic|RemoteCommand}} と {{ic|RequestTTY}} を指定するエントリを ssh の設定に追加することもできます:

{{hc|~/.ssh/config|
Host ''jump-destination''
Hostname ''relay''
User ''user2''
RemoteCommand ssh ''user3''@localhost -p 2222
RequestTTY yes
}}

この場合、以下のように簡単にできます:

$ ssh ''jump-destination''

{{Note|クライアント側のターミナルでの SCP の自動補完機能は機能しません。一部の構成では、SCP の転送機能自体も機能しません。}}

=== マルチプレクス ===

SSH デーモンは通常はポート 22 番をリッスンします。しかし、公共のインターネット・ホットスポットでは通常の HTTP/HTTPS のポート（80 と 443）以外のトラフィックをブロックしていることが一般的です。そのため SSH 接続がブロックされてしまいます。すぐできる解決策として、{{ic|sshd}} に許可されているポートをリッスンさせるという方法があります：

{{hc|/etc/ssh/sshd_config|
Port 22
Port 443
}}

しかしポート 443 番は HTTPS コンテンツを提供する Web サーバによってすでに使われていることが多いです。その場合は {{Pkg|sslh}} のようなマルチプレクサを使います。これは複数のポートをリッスンし、そこに来るパケットを複数のサービスに賢く振り分けることができます。

=== SSH の高速化 ===

接続をグローバル及び特定のホストに対して高速化させることのできる[[#設定|クライアント設定]]がいくつかあります。これらのオプションに関する完全な説明は {{man|5|ssh_config}} を参照してください。

* ''より高速な暗号を使う'': AESNI 命令セットを持つ最近の CPU では、{{ic|aes128-gcm@openssh.com}} や {{ic|aes256-gcm@openssh.com}} を使うことで openssh のデフォルトの優先暗号 (通常 {{ic|chacha20-poly1305@openssh.com}}) よりも劇的に優れたパフォーマンスを得られるはずです。暗号は {{ic|-c}} フラグで選択できます。永続的に設定するには、{{ic|~/.ssh/config}} 内に {{ic|Ciphers}} オプションを追加し、暗号を優先順に並べて設定してください (例: {{bc|Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr}})。

* ''圧縮を有効化あるいは無効化する'': 圧縮は低速な接続において速度を向上させることができます。{{ic|Compression yes}} オプションか {{ic|-C}} フラグで有効化できます。しかし、使用される圧縮アルゴリズムは比較的低速な {{man|1|gzip}} であり、高速なネットワークにおいてはボトルネックになってしまいます。接続を高速化させるために、ローカルネットワークや高速なネットワークにおいては {{ic|Compression no}} を使うべきでしょう。

* ''接続共有'': 以下のオプションを使用することで、同一ホストに対するセッションをすべて単一の接続に共有させることができます:{{bc|<nowiki>
ControlMaster auto
ControlPersist yes
ControlPath ~/.ssh/sockets/socket-%r@%h:%p
</nowiki>}}
: {{ic|~/.ssh/sockets}} の部分は、他のユーザによって書き込むことができないのであれば、どのディレクトリでも構いません。

* {{ic|ControlPersist}} は、初回のクライアント接続が閉じられてから、新しいクライアントのためにマスターがどれくらいバックグラウンドで待機すべきかを指定します。利用可能な値は:
** {{ic|no}}: 最後のクライアントが切断されたらすぐに接続を閉じます。
** 秒単位の時間
** {{ic|yes}}: 永遠に待ちます。接続は自動的に閉じられなくなります。

* {{ic|AddressFamily inet}} オプションか {{ic|-4}} フラグを使用して IPv6 ルックアップをバイパスすることで、ログインに要する時間を短くすることができます。

* 最後に、SSH を SFTP や SCP のために使用するつもりであれば、[https://www.psc.edu/index.php/hpn-ssh High Performance SSH/SCP] は、SSH バッファサイズを動的に大きくすることで、スループットを劇的に増やすことができます。この改善のパッチが施されたバージョンの OpenSSH である {{AUR|openssh-hpn}} パッケージをインストールしてください。

=== SSHFS でリモートファイルシステムをマウントする ===

sshfs を使って (SSH でアクセスした) リモートのファイルシステムをローカルフォルダにマウントする方法は [[SSHFS]] の記事を参照してください。マウントしたファイルは様々なツールであらゆる操作することができます (コピー、名前の変更、vim で編集など)。基本的に ''shfs'' よりも ''sshfs'' を使用することを推奨します。''sshfs'' は ''shfs'' の新しいバージョンであり、元の ''shfs'' は2004年から更新されていません。

=== キープアライブ ===

デフォルトでは、SSH セッションが一定時間アイドルであった場合、自動的にログアウトします。一定時間データが受信されなかった場合にサーバにキープアライブシグナルを送信することで、セッションを開いたままにすることができます。あるいは対照的に、クライアントからデータが送られてこない場合にサーバが定期的にメッセージを送信することもできます。

* '''サーバ'''側: {{ic|ClientAliveInterval}} はタイムアウトを秒単位で設定します。クライアントからデータが受信されずにその時間経過すると、''sshd'' が応答を促すリクエストを送信します。デフォルトは0であり、メッセージは送信されません。例えば、60秒毎にクライアントに対して応答を要求するには、[[#設定_2|サーバ側の設定]]で {{ic|ClientAliveInterval 60}} オプションを設定してください。{{ic|ClientAliveCountMax}} と {{ic|TCPKeepAlive}} オプションも参照してください。
* '''クライアント'''側: {{ic|ServerAliveInterval}} は、クライアントからサーバに向けて送信されるリクエストの時間間隔を設定します。例えば、120秒毎にサーバに対して応答を要求するには、[[#設定|クライアント側の設定]]で {{ic|ServerAliveInterval 120}} オプションを追加してください。{{ic|ServerAliveCountMax}} と {{ic|TCPKeepAlive}} オプションも参照してください。

{{Note|セッションを開いたままにするためにキープアライブリクエストを送信する必要があるのは、クライアントかサーバの一方のみです。サーバとクライアントの両方を制御できるならば、セッションを永続的にする必要のあるクライアントに対してのみ {{ic|ServerAliveInterval}} を正の値に設定し、その他のクライアントやサーバはデフォルトの設定するのが妥当な選択です。}}

=== systemd で SSH トンネルを自動的に再起動 ===

[[systemd]] を使ってブート時/ログイン時に SSH 接続を自動的に開始して、''さらに''接続が失敗した時に再起動させることができます。SSH トンネルの管理に役立つツールとなります。

以下のサービスでは、[[#設定|ssh の設定]]に保存された接続設定を使って、ログイン時に SSH トンネルを開始します。接続が何らかの理由で閉じられた場合、10秒待機してから再起動します:

{{hc|~/.config/systemd/user/tunnel.service|<nowiki>
[Unit]
Description=SSH tunnel to myserver

[Service]
Type=simple
Restart=always
RestartSec=10
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N myserver
</nowiki>}}

上記の [[systemd/ユーザー]]サービスを[[有効化]]して[[起動]]してください。トンネルがタイムアウトするのを防ぐ方法は [[#キープアライブ]] を見て下さい。起動時にトンネルを開始したい場合、[[systemd#ユニットファイル|ユニットをシステムサービスとして書きなおして下さい]]。

=== Autossh - SSH セッションとトンネルの自動再起動 ===

ネットワークの状態が悪かったりしてクライアントが切断してしまい、セッションやトンネルの接続を維持できない場合、{{Pkg|autossh}} を使って自動的にセッションとトンネルを再起動できます。

使用例:

$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com

[[SSHFS]] と組み合わせる:

$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example

[[プロキシ設定]]で設定した SOCKS プロキシを使って接続:

$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com

{{ic|-f}} オプションで autossh をバックグラウンドプロセスとして実行することができます。ただし対話式でパスフレーズを入力することができなくなります。

セッション中に {{ic|exit}} と入力したり autossh プロセスに SIGTERM、SIGINT、SIGKILL シグナルが送られるとセッションは終了します。

==== systemd を使ってブート時に自動的に autossh を起動する ====

autossh を自動的に起動したい場合、以下の systemd ユニットファイルを作成します:

{{hc|/etc/systemd/system/autossh.service|2=
[Unit]
Description=AutoSSH service for port 2222
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

[Install]
WantedBy=multi-user.target
}}

{{ic|1=AUTOSSH_GATETIME=0}} は接続が成功して ssh が立ち上がったと autossh が認識する秒数です。0に設定すると autossh は ssh の最初の起動失敗を無視します。起動時に autossh を実行する場合は設定するべきです。他の環境変数は man ページを見てください。必要であればもっと複雑に設定することもできますが、{{ic|1=AUTOSSH_GATETIME=0}} を含む {{ic|-f}} は systemd では機能しません。

設定後はサービスを[[起動]]・[[有効化]]してください。

以下のように {{ic|ControlMaster}} を無効化する必要もあるかもしれません:

ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

{{Tip|複数のautosshプロセスを維持し、複数のトンネルを存続させることも簡単です。名前の異なる複数のサービスファイルを作成するだけです。}}

=== SSH デーモンが失敗した場合の代替サービス ===

SSH のみに依存するリモート或いはヘッドレスのサーバにおいて、(システムアップグレード後などに) SSH デーモンの起動に失敗すると、管理アクセスできなくなってしまう場合があります。[[systemd]] は、{{ic|OnFailure}} によるシンプルなソリューションを提供しています。

サーバ上で {{ic|sshd}} が実行されていて、[[telnet]] がフェイルセーフであるとしてます。以下のようにファイルを作成してください。ただし、{{ic|telnet.socket}} は[[有効化]]'''しないでください'''!

{{hc|/etc/systemd/system/sshd.service.d/override.conf|2=
[Unit]
OnFailure=telnet.socket
}}

これだけです。{{ic|sshd}} が実行中である場合、Telnet は実行されません。{{ic|sshd}} が起動に失敗した場合、telnet セッションがリカバリとして開かれます。

=== ホストに基づいてターミナル背景色を設定する ===

異なるホストに接続していることを簡単に判別できるようにするために、[https://bryangilbert.com/post/etc/term/dynamic-ssh-terminal-background-colors/ ホストの種類に応じて異なる背景色]を設定することができます。

このソリューションは一般には適用できません (ZSH 限定)。

=== ネットワーク固有の設定 ===

{{ic|Match exec}} を使うことで、接続先のネットワークに固有のホスト設定を使用することができます。

例えば、{{man|1|nmcli}} を使用していて、接続が検索ドメインを使用するように (手動、あるいは DHCP で) 設定されている場合:

{{hc|head=~/.ssh/config|output=
Match exec "nmcli {{!}} grep domains: {{!}} grep example.com"
CanonicalDomains example.com
# Should you use a different username on this network
#User username
# Use a different known_hosts file (for private network or synchronisation)
#UserKnownHostsFile <network>_known_hosts
}}

{{ic|Match host ... exec "..."}} の例: VPN に接続していない限り、{{ic|internal.example.com}} への接続に ({{ic|ProxyJump}} を用いた) 踏み台/プロキシが必要であるとしましょう。フラグメント {{ic|!exec "host internal.example.com"}} は、{{ic|internal.example.com}} が DNS を介して見つけられない場合にのみ、適用されます。様々な代替案が [https://serverfault.com/q/536043/117525] で議論されています。

{{hc|head=~/.ssh/config|output=
Match host internal.example.com !exec "host internal.example.com"
ProxyJump bastion.example.com
Host internal.example.com
User foobar
}}

=== プライベートネットワークのホスト鍵検証 ===

あるネットワーク上のサーバとそれとは別のネットワーク上のサーバは、互いに同じプライベート IP アドレスを持つ可能性があるため、それらのサーバは異なる方法で処理する必要があるかもしれません。

{{Accuracy|「最適な」ソリューションに、本番環境では別のものを使うべきという警告があるはずがない。}}

最適なソリューションは、[[#ネットワーク固有の設定]] を使用し、接続しているネットワークに応じて異なる {{ic|UserKnownHostsFile}} を使うことです。2つめのソリューションは、プライベートネットワークのホスト鍵を単に無視することです (新しい/プロトタイプのネットワークで作業する際にデフォルトで使用するのが最適です):

{{hc|head=~/.ssh/config|output=
Host 10.* 192.168.*.* 172.31.* 172.30.* 172.2?.* 172.1?.*
# Disable HostKey verification
# Trust HostKey automatically
StrictHostKeyChecking no
# Do not save the HostKey
UserKnownHostsFile=/dev/null
# Do not display: "Warning: Permanently Added ..."
LogLevel Error
}}

{{Accuracy|{{ic|known_hosts}} ファイルは、サーバにアクセスするためにホスト名を使用したとしても、IP アドレスを記録します。}}

{{Warning|本番環境では、ホスト名を使用してホストにアクセスしたり、ネットワーク固有の known_hosts ファイルを使用するようにしてください。}}

=== ログイン時にコマンドを実行 ===

インタラクティブセッションを使用している場合、ログイン時にコマンドを実行する方法は複数存在します:

* リモートホスト上の {{ic|authorized_keys}} ファイルを使用する ({{man|8|sshd|AUTHORIZED_KEYS FILE FORMAT}} を参照)
* サーバで {{ic|PermitUserRC}} オプションが有効化されている場合、リモートホスト上の {{ic|~/.ssh/rc}} を使用する
* リモートホスト上のシェル設定ファイルを使用する (例: {{ic|.bashrc}})

=== エージェントフォワーディング ===

SSH エージェントのフォワーディングにより、サーバに接続している状態でローカルの鍵を使用することができます。選択したホストのみに対してエージェントフォワーディングを許可することが[https://security.stackexchange.com/questions/7480/risks-of-ssh-to-an-untrusted-host#7504 推奨]されます。

{{hc|~/.ssh/config|
Host ''myserver.com''
ForwardAgent yes
}}

次に、[[SSH エージェント]]を構成し、''ssh-add'' を使ってローカル鍵を追加してください。

これで、リモートサーバに接続する場合、あなたのローカル鍵を使用して他のサービスに接続できるようになりました。

=== 新しい鍵の生成 ===

新しいサーバの秘密鍵は以下で生成できます:

# すべての鍵を削除する。例えば: {{bc|# rm /etc/ssh/ssh_host_*_key*}}
# {{ic|sshdgenkeys.service}} を[[再起動]]するか、{{ic|ssh-keygen -A}} を root として実行する。

=== sshd を非特権ユーザとして実行 ===

{{ic|sshd}} をコンテナ内で (或いはテスト目的などで) 非特権ユーザとして実行したい場合もあるでしょう。

非特権ユーザは {{ic|/etc/ssh}} 内のホスト鍵を読むことができないため、新しいホスト鍵を生成しなければなりません:

$ ssh-keygen -q -N "" -t rsa -b 4096 -f ''/path/to/host/keys/ssh_host_rsa_key''
$ ssh-keygen -q -N "" -t ecdsa -f ''/path/to/host/keys/ssh_host_ecdsa_key''
$ ssh-keygen -q -N "" -t ed25519 -f ''/path/to/host/keys/ssh_host_ed25519_key''

{{ic|sshd_config}} を作成してください。以下の例では、1024 より大きい値のポート番号を使用し、ホスト鍵への新しいパスを提供し、PAM を無効化します:

{{hc|''/path/to/sshd_config''|
Port 2022
HostKey ''/path/to/host/keys/ssh_host_rsa_key''
HostKey ''/path/to/host/keys/ssh_host_ecdsa_key''
HostKey ''/path/to/host/keys/ssh/ssh_host_ed25519_key''
UsePAM no
}}

新しく作成した設定で ''sshd'' を実行します。{{ic|-D}} フラグはデーモンモードを無効化し、{{ic|-e}} は出力を標準エラー出力にリダイレクトしてモニタしやすくします:

$ sshd -f ''/path/to/sshd_config'' -D -e

== トラブルシューティング ==

=== チェックリスト ===

まずは以下の単純な問題をチェックしましょう。

# 設定ディレクトリ {{ic|~/.ssh}} のコンテンツが対象ユーザによってのみアクセス可能である必要があります (クライアントとサーバの両方で確認してください)。かつ、対象ユーザのホームディレクトリがそのユーザによってのみ書き込み可能である必要があります: {{bc|<nowiki>
$ chmod go-w ~
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/*
$ chown -R $USER ~/.ssh
</nowiki>}}
# クライアントの公開鍵 (例: {{ic|id_ed25519.pub}}) がサーバ上の {{ic|~/.ssh/authorized_keys}} 内に記述されていることを確認する。
# [[#設定_2|サーバの設定]]の {{ic|AllowUsers}} や {{ic|AllowGroups}} によって SSH のアクセスが制限されていないことを確認する。
# ユーザがパスワードを設定しているかを確認する。サーバにログインしたことのない新しいユーザは、パスワードを持っていないことがあります。
# {{ic|/etc/ssh/sshd_config}} に {{ic|LogLevel DEBUG}} を[[追加]]してみる。
# {{ic|journalctl -xe}} を root として実行して、(エラー) メッセージの取得を試みる。
# {{ic|sshd}} を[[再起動]]し、クライアントとサーバの両方でログアウト/ログインする。

=== 接続の拒否やタイムアウトの問題 ===

==== ポートフォワーディング ====

NAT モードやルータを使っている場合 (VPS を使っていたりパブリックにアドレッシングされたホストを使用していない限り、あり得ます)、ルータが ssh の着信接続をマシンにフォワーディングしていることを確認してください。{{ic|ip addr}} を使ってサーバの内部 IP アドレスを見つけ、SSH ポートの TCP 接続をその IP にフォワーディングするようにルータを設定してください。[https://portforward.com portforward.com] が役に立ちます。

==== SSH が動作していて、リッスンしているか？ ====

[[ss]] ユーティリティは、以下のコマンドラインを使うことで、TCP ポートをリッスンしている全プロセスを表示します:

$ ss --tcp --listening

このコマンドの出力を見て、システムが {{ic|ssh}} ポートをリッスンしていないことが判明した場合、SSH が実行されていないことを意味します。[[Journal]] でエラーなどが出力されていないか確認してください。

==== 接続をブロックするようなファイアウォールのルールが存在しないか？ ====

[[iptables]] によってポート {{ic|22}} の接続がブロックされている可能性があります。次のコマンドで確認してください:
{{bc|# iptables -nvL}}
{{ic|INPUT}} チェインのパケットを拒否するようなルールがないか見て下さい。そして、必要であれば、次のようなコマンドでポートのブロックを解除します:
{{bc|
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
}}
ファイアウォールの設定に関する詳細は[[ファイアウォール]]を見て下さい。

==== トラフィックがコンピュータにまで到達しているか？ ====

以下のように問題のコンピュータのトラフィックを収集してみてください:

# tcpdump -lnn -i any port ssh and tcp-syn

上記は基本的な情報を表示します。トラフィックが表示されるまで待ってください。その後、接続を試行してみてください。何も出力がされない場合、コンピュータの外側にある何かがトラフィックを妨害しています (例: ハードウェアファイアウォールや NAT ルーターなど)。

==== ISP またはサードパーティによってデフォルトのポートがブロックされてないか？ ====

{{Note|このステップは次のことを確認した後で実行してください。ファイアーウォールを何も起動していないこと。DMZ へのルーターを正しく設定している、またはコンピュータへポートを転送していること。それでもまだ動かない場合、ここで診断のステップと解決法が見つかるでしょう。}}

ときどき ISP が SSH のデフォルトポート (22番) をブロックしている場合があります。この場合はあなたが何をしても (ポートを開ける、スタックを強化する、フラッドアタックを防御する、など) 無意味になります。ブロックされているかどうか確認するために、全てのインターフェイス (0.0.0.0) をリッスンするサーバを立ち上げ、リモートから接続してみてください。

このようなエラーメッセージが出る場合：

ssh: connect to host www.inet.hr port 22: Connection refused

これはそのポートが ISP にブロックされて'''いない'''が、そのポートでサーバーの SSH が起動していないことを意味します ([[wikipedia:Security through obscurity|security through obscurity]] を参照)。

しかし、次のようなエラーメッセージが出る場合：

ssh: connect to host 111.222.333.444 port 22: Operation timed out

これは何かがポート 22 での TCP トラフィックを拒否していることを意味します。そのポートはあなたのサーバー上のファイアーウォールか第三者 (ISP など) のどちらかによってステルスされています。自分のサーバーでファイアーウォールが起動していないことが確かなら、また、ルーターやスイッチの中でグレムリンが育っていないことが確かなら、ISP がトラフィックをブロックしています。

ダブルチェックのために、サーバ上で Wireshark を起動してポート 22 でのトラフィックをリッスンしてみましょう。Wireshark はレイヤ 2 のパケット・スニファリング・ユーティリティであり、TCP/UDP はレイヤ 3 以上なので ([[wikipedia:ja:インターネット・プロトコル・スイート|IP ネットワークスタック]]を参照)、もしリモートから接続するときに何も受け取っていなければ、十中八九、第三者がブロックしています。

===== 問題診断 =====

{{Pkg|tcpdump}} または {{Pkg|wireshark-cli}} パッケージで Wireshark を[[インストール]]してください。

tcpdump の場合:

# tcpdump -ni ''interface'' "port 22"

Wireshark の場合:

$ tshark -f "tcp port 22" -i ''interface''

{{ic|''interface''}} は WAN 接続に使っているネットワークインターフェイスに置き換えてください (確認したいときは {{ic|ip a}} を実行)。リモートで接続を試行してもパケットが全く受け取れない場合、ISP によってポート 22 のトラフィックがブロックされている可能性があります。

===== 解決方法 =====

解決方法は、単に ISP がブロックしていない他のポートを使うことです。{{ic|/etc/ssh/sshd_config}} を編集して他のポートを使うようにしましょう。例えば次を追加します:

Port 22
Port 1234

そしてこのファイル中の他の Port 設定をコメントアウトします。「Port 22」をコメントにして「Port 1234」を追加するだけでは、sshd がポート 1234 しかリッスンしなくなるので、この問題は解決しません。この 2 行どちらも使用し、sshd が両方のポートをリッスンするようにします。

{{ic|sshd.service}} サーバを[[再起動]]すれば、あともう少しです。次に、デフォルトのポートではなくもう一つのポートを使用するようにクライアントを設定しなければなりません。その問題に対するソリューションは数多く存在しますが、ここではそれらのうち2つを扱っています。

==== Read from socket failed: connection reset by peer ====

最近のバージョンの OpenSSH は時々、古い ssh サーバに接続する際に上記のエラーメッセージで失敗することがあります。これは、そのホストに対する様々な[[#設定|クライアントオプション]]を設定することにより、回避可能です。以下のオプションに関する詳細は {{man|5|ssh_config}} を見てください。

{{ic|ecdsa-sha2-nistp*-cert-v01@openssh}} 楕円曲線ホスト鍵アルゴリズムが原因である可能性があります。このようなアルゴリズムは、{{ic|HostKeyAlgorithms}} にそれらのアルゴリズムを除いたリストを設定することにより、無効化できます。クライアント側では、{{ic|HostKeyAlgorithms}} のリストの前に {{ic|-}} をつけることで、指定したアルゴリズム (ワイルドカードも可) をデフォルトから外すことができます ({{man|5|ssh_config}} を参照)。

実際に使用されているホスト鍵のアルゴリズムは、{{ic|ssh -v ''server_to_connect_to''}} を実行して、{{ic|kex: host key algorithm:}} と書かれてある行を見ればわかります。

これでうまく行かない場合、暗号のリストが長過ぎる可能性があります。{{ic|Ciphers}} オプションのリストを短くしてください (80 文字未満であれば十分でしょう)。同じように、{{ic|MACs}} のリストも短くしてみてください。

OpenSSH のバグフォーラムにおける[https://web.archive.org/web/20161201015151/https://www.gossamer-threads.com/lists/openssh/dev/51339 議論]も参照してください。

=== "[シェル]: No such file or directory" / ssh_exchange_identification の問題 ===

シェルのバイナリが {{Ic|$PATH}} に登録されているディレクトリ内にあったとしても、特定の SSH クライアントは {{Ic|$SHELL}} に絶対パスを設定する必要があります (パスは {{Ic|whereis -b [あなたのシェル]}} で確認できます)。

=== "Terminal unknown" や "Error opening terminal" エラーメッセージ ===

ログイン時に上記のようなエラーが表示される場合、サーバがターミナルを認識できていないことを意味します。また、nano などの ncurses アプリケーションを実行すると {{ic|Error opening terminal}} というメッセージが表示されることがあります。

クライアントで使用しているターミナルの terminfo ファイルをサーバーにインストールするのが正しい解決方法です。これによってサーバーのコンソールプログラムがターミナルを正しく扱えるようになります。{{ic|infocmp}} を実行してから[[Pacman#パッケージ・データベースに問い合わせる|パッケージを確認]]することで terminfo に関する情報を取得できます。

通常の方法で[[インストール]]できない場合、サーバーのホームディレクトリに terminfo をコピーしてください:

$ ssh myserver mkdir -p ~/.terminfo/${TERM:0:1}
$ scp /usr/share/terminfo/${TERM:0:1}/$TERM myserver:~/.terminfo/${TERM:0:1}/

サーバーから一度ログアウトしてからログインしなおすと問題が解決しているはずです。

==== TERM ハック ====

{{Note|これは最後の手段にするべきです。}}

あるいは、{{ic|1=TERM=xterm}} 環境変数をサーバ側で (例えば {{ic|.bash_profile}} で) 設定してしまうという方法もあります。これでエラーは出なくなり、ncurses アプリケーションを実行できるようになります。しかし、ターミナルの制御シーケンスが xterm のそれと正確に一致しない限り、奇妙な挙動やグラフィックのバグが発生する場合があります。

=== Connection closed by x.x.x.x [preauth] ===

sshd のログでこのエラーが確認できる場合、{{ic|HostKey}} が正しく設定されているか確認してください:

{{hc|/etc/ssh/sshd_config|HostKey /etc/ssh/ssh_host_ed25519_key}}

=== サブシステム要求の失敗 ===

''OpenSSH'' 8.8 以降、''scp'' はデータ転送のデフォルトプロトコルとして ''SFTP'' を使用し、{{ic|sftp}} というサブシステムを要求するようになりました。もし ''scp'' を冗長モード {{ic|scp -v}} で実行すれば、クライアントがどのサブシステムを使っているかがわかります (例: {{ic|Sending subsystem: <subsystem-name>}})。{{ic|subsystem request failed on channel 0}} のようなエラーは、サーバのサブシステムを設定することで修正できるかもしれません。{{man|5|sshd_config|Subsystem}} のように設定します。サーバの設定は、以下の例のようにする必要があります:

{{hc|/etc/ssh/sshd_config|
...
Subsystem subsystem-name /path/to/subsystem-executable
...
}}

=== id_dsa が拒否される ===

OpenSSH 7.0 ではセキュリティ上の理由により DSA 公開鍵が非推奨となっており、OpenSSH 9.8 はデフォルトで DSA 鍵のサポート無しでビルドされています。2025年最初の OpenSSH リリースでは、DSA のサポートが完全になくなる予定です。今のところ、DSA 公開鍵をどうしても使わなくてはならない場合は、{{ic|configure}} に {{ic|--enable-dsa-keys}} フラグを渡して {{Pkg|openssh}} をビルドする必要があります。[https://marc.info/?l=openssh-unix-dev&m=171982945528949&w=2]

=== OpenSSH 7.0 で No matching key exchange method found ===

OpenSSH 7.0 では、Logjam 攻撃からの理論上の脆弱性を理由に diffie-hellman-group1-sha1 鍵アルゴリズムが非推奨になっています (https://www.openssh.com/legacy.html を参照)。特定のホストで鍵アルゴリズムが必要な場合、ssh は以下のようなエラーメッセージを吐きます:

Unable to negotiate with 127.0.0.1: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1

古いアルゴリズムを使用しないようにサーバーをアップグレード/設定することで上記のエラーは解決します。サーバー側の設定を変更できない場合、[[#設定|クライアント設定]]で {{ic|KexAlgorithms +diffie-hellman-group1-sha1}} オプションを使うことでアルゴリズムを有効化できます。

=== SSH から切断したときに tmux/screen セッションがキルされる ===

セッションの終了時にプロセスがキルされる場合、ソケットアクティベーションを使っているために SSH セッションプロセスが終了したときに {{Pkg|systemd}} によって終了されている可能性があります。{{ic|ssh.socket}} の代わりに {{ic|ssh.service}} を使用してソケットアクティベーションを使わないことで解決できます。もしくは {{ic|ssh@.service}} の Service セクションで {{ic|1=KillMode=process}} を設定してください。

{{ic|1=KillMode=process}} は古典的な {{ic|ssh.service}} でも役に立つことがあります。サーバーが停止したり再起動したときに SSH セッションプロセスや {{Pkg|screen}} や {{Pkg|tmux}} のプロセスが終了されることを防ぐことができます。

=== SSH セッションが応答しなくなる ===

SSH は [[Wikipedia:Software flow control|Software flow control]] {{ic|XON}} と {{ic|XOFF}} に反応します。{{ic|Ctrl+s}} を押すとフリーズ/ハングアップ/応答停止します。セッションを再開するには {{ic|Ctrl+q}} を使ってください。

=== Broken pipe ===

接続を作ろうとして {{ic|packet_write_wait}} のレスポンスが {{ic|Broken pipe}} になる場合、デバッグモードで接続を再試行し、出力がエラーで終わるかどうか確認する必要があります:

{{bc|debug3: send packet: type 1
packet_write_wait: Connection to A.B.C.D port 22: Broken pipe
}}

上記の {{ic|send packet}} の行は、応答パケットが受信されなかったことを示しています。つまり、これは ''QoS'' の問題であることがわかります。パケットを落とす可能性を減らすには、{{ic|IPQoS}} を設定してください:

{{hc|/etc/ssh/ssh_config|Match all
IPQoS reliability
}}

サービスタイプ {{ic|reliability}} ({{ic|0x04}}) は、{{ic|0x00}} や {{ic|throughput}} ({{ic|0x08}}) と同様に、このコマンドを解決するはずです。

=== 応答のない SSH 接続を終了する ===

クライアントセッションが応答しなくなり、実行中のプログラム (例えば [[シェル]]) に終了を指示しても終了しない場合、{{ic|Enter}}、{{ic|~}}、そして {{ic|.}} をこの順番で次々に押すと、セッションを終了させることが可能です。

この {{ic|~}} は疑似端末エスケープ文字 ({{man|1|ssh|ESCAPE CHARACTERS}} 参照) であり、終了させるクライアントセッションに応じて複数回付加することが可能です。例えば、A から B へ接続し、B から C へ接続したときに B から C へのセッションがフリーズした場合、{{ic|Enter}} を押して {{ic|~~.}} と入力すれば、B の作業セッションを残して B から C へのセッションを終了させることができます。

=== WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! ===

SSH サーバの鍵が変更されたという警告がクライアントで表示された場合、新しく提供された鍵が本当にサーバオペレータのものであるかどうかを、何らかの信頼された方法 (暗号化されている必要はありません) で確認する必要があります。確認したら、{{ic|known_hosts}} ファイルから古い鍵を {{ic|ssh-keygen -R $SSH_HOST}} で削除し、新しいサーバーに接続するときと同じように鍵を受理してください。

=== 適切な terminfo エントリがないリモートに接続する場合 ===

あなたのターミナルの terminfo エントリが無いホストに接続する場合 (例えば、{{Pkg|ncurses}} に同梱されていない terminfo エントリのターミナルを使用している場合) や、terminfo データベースが限られているホストに接続する場合 (例えば、[[Wikipedia:ja:OpenWrt|OpenWrt]] を実行しているシステム)、{{man|5|terminfo}} に依存しているソフトウェアで様々な問題が発生します。

適切な解決策は、適切な terminfo エントリをホストに設置することです。それが不可能な場合は、リモートホストがサポートし、かつ端末と互換性のある値を {{ic|TERM}} に設定することで解決できます。

OpenSSH 8.7 以降、カスタムの {{ic|TERM}} 環境変数をリモートホストに渡すには、簡単な設定スニペットを使用してください:

{{hc|~/.ssh/config|2=
Host example.com
SetEnv TERM=xterm-256color
}}

=== 踏み台ホストを介する接続が "bash: No such file or directory" で失敗する ===

(踏み台のサーバで) {{ic|SHELL}} 環境変数に有効な完全パスを設定していない場合、以下に似たエラーメッセージで接続は失敗します:

bash: No such file or directory
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

踏み台サーバにおいて有効なシェルの完全パスを {{ic|SHELL}} に設定するか、{{ic|~/.ssh/config}} で各サーバに対して特定の {{ic|SHELL}} を設定することで、この問題を解決できます。

=== ログインしようとすると接続がハングする ===

MTU/フラグメンテーションの問題により接続確立中にハングすることがあります。ルーターやファイアウォールの設定を間違えていないか調べたり、クライアント側で MTU サイズを少しずつ減らしてみてください (これは良くない回避策です)。
もう一つの方法は、KexAlgorithms、HostKeyAlgorithms、Ciphers、MACs などの設定値を減らして最初の SSH ペイロードを減らすことです。

== 参照 ==

* [[Wikibooks:ja:OpenSSH]]
* [https://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]
* OpenSSH 鍵管理: IBM developerWorks の [https://www.ibm.com/developerworks/library/l-keyc/index.html Part 1]、funtoo.org の [[Funtoo:OpenSSH Key Management, Part 2|Part 2]]、[[Funtoo:OpenSSH Key Management, Part 3|Part 3]]
* [https://stribika.github.io/2015/01/04/secure-secure-shell.html Secure Secure Shell]

{{TranslationStatus|OpenSSH|2025-07-12|839725}}

スワップ

2025-07-07T09:45:50Z

AshMyzk: 同期

[[Category:ファイルシステム]]
[[de:Swap]]
[[en:Swap]]
[[es:Swap]]
[[fr:Swap]]
[[hu:Swap]]
[[pt:Swap]]
[[ru:Swap]]
[[zh-hans:Swap]]
{{Related articles start}}
{{Related|fstab}}
{{Related|ハイバネート}}
{{Related|zswap}}
{{Related|zram}}
{{Related|ビデオメモリにスワップ}}
{{Related|ZFS#スワップボリューム}}
{{Related|Dm-crypt/スワップの暗号化}}
{{Related articles end}}

このページでは GNU/Linux での[[Wikipedia:ja:ページング方式|スワップ領域とページング]]を紹介します。また、スワップパーティションとスワップファイルの作成と有効化について説明しています。

[https://www.linux.com/news/all-about-linux-swap-space/ All about Linux swap space] より:

:''Linux は物理 RAM (random access memory) をページと呼ばれるメモリのかたまりに分割します。スワッピングとは、メモリを解放するために、ページがスワップ領域という名の事前設定領域にコピーされることを言います。物理メモリとスワップ領域の合計が利用できる仮想メモリのサイズになります。''

スワップのサポートは Linux カーネルにより提供され、ユーザスペースのユーティリティは {{Pkg|util-linux}} パッケージに存在します。

== スワップ領域 ==

スワップ領域は普通ディスクパーティションとして作られますが、ファイルにすることもできます。Arch Linux のインストール中にユーザーはスワップ領域を作成することができ、必要であればインストール後でも作成できます。スワップ領域を作成する理由は2つあります: 仮想メモリを拡張して、搭載している物理メモリ(RAM)より多くするためと、[[電源管理/サスペンドとハイバネート|suspend-to-disk(ハイバネート)]] をするためです。

スワップを使って仮想メモリを拡張することが利益になるかどうかは搭載している物理メモリの容量により異なります。必要なプログラムをすべて実行するのに必要な量の物理メモリを搭載していないのであれば、スワップを作成することは''おそらく''利益となるでしょう。これにより、[[Wikipedia:Out of memory|out of memory(メモリ不足)]] を避けることができます。Out of memory とは、Linux カーネルの OOM killer という仕組みが自動的にプロセスを kill してメモリの空き領域を作ろうとしている状態のことを言います。仮想メモリの容量を必要な量まで増やすには、足りない分をスワップ領域として追加してください。

メモリが枯渇しているときにスワップを使用することの最大の欠点は、パフォーマンスが低下することです([[#パフォーマンス]] セクションを見てください)。それゆえ、スワップを有効化するかどうかは個人の好みの問題となります。スワップを有効化するよりメモリが枯渇したときにプロセスが kill されるほうが良いという人もいますし、メモリが枯渇したときにシステムが低速化するがスワップを有効化したほうが良いという人もいます。

スワップの状態を確認するには、次を実行:

$ swapon --show

もしくは、以下を実行して物理メモリとスワップの使用状況を表示:

$ free -h

== スワップパーティション ==

[[パーティショニング#スワップ|スワップパーティション]]は、ほとんどの GNU/Linux の[[パーティショニングツール]]で作成することができます。スワップパーティションは、GPT 上ではパーティションタイプ GUID {{ic|0657FD6D-A4AB-43C4-84E5-0933C84B4F4F}} が ([[gdisk]] では {{ic|8200}} タイプ、[[fdisk]] では {{ic|swap}} タイプ)、MBR 上ではタイプ ID {{ic|82}} が指定されています。

Linux のスワップ領域をセットアップする時には、{{man|8|mkswap}} コマンドが使われます。例えば:

# mkswap /dev/sd''xy''

{{Warning|指定したパーティションに保存されている全てのデータが消失します。}}

デバイスのページングを有効にするには:

# swapon /dev/sd''xy''

オプションについては {{man|8|swapon}} を参照してください。

=== 起動時に有効化する ===

スワップパーティションをブート時に有効化するには:

* [[systemd#GPT パーティションの自動マウント]]を使う
* あるいは、{{ic|/etc/fstab}} にエントリを追加する。例: {{bc|1=UUID=''device_UUID'' none swap defaults 0 0}}

:{{ic|''device_UUID''}} はスワップ領域の [[UUID]] です。

{{ic|fstab}} ファイルの構文については [[fstab]] を見てください。また、[[systemd#systemd.mount - マウント]] も参照してください。

=== スワップの無効化 ===

特定のスワップ領域を無効にするには:

# swapoff /dev/sda2

もしくは {{ic|-a}} スイッチを使って全てのスワップ領域を無効化することもできます。

スワップは systemd によって管理されているため、次の起動時にスワップが自動的に有効化されてしまいます。検出されたスワップ領域を自動的に有効化する機能を恒久的に無効にするには、{{ic|systemctl --type swap}} を実行して問題の ''.swap'' ユニットを確認して[[マスク]]してください。

== スワップファイル ==

パーティションを作るかわりに、臨機応変にサイズを変えたり簡単に削除できるものとしてスワップファイルが選択肢になりえます。特にディスク容量が貴重な場合 (例: 小容量の SSD) はこちらが理想的でしょう。

{| class="wikitable sortable"
! ファイルシステム
! スワップファイルのサポート
|-
| [[Bcachefs]]
| {{No|https://github.com/koverstreet/bcachefs/issues/368}}
|-
| [[Btrfs]]
| {{G|[[Btrfs#Swap file|Yes]]}}
|-
| [[F2FS]]
| {{Yes}}
|-
| [[ext4]]
| {{Yes}}
|-
| [[JFS]]
| {{Yes}}
|-
| [[Wikipedia:NILFS|NILFS2]]
| {{No}}
|-
| [[NTFS3]]
| {{Yes}}
|-
| [[Wikipedia:ReiserFS|ReiserFS]]
| {{Yes}}
|-
| [[XFS]]
| {{Yes}}
|-
| [[ZFS]]
| {{No}}
|}

=== スワップファイルの作成 ===

{{Note|[[Btrfs]] については、以下の手順ではなく [[Btrfs#スワップファイル]] で説明されている手順に従ってください。}}

{{man|8|mkswap}} を使用して、所望のサイズのスワップファイルを作成します (ヒントは [[パーティショニング#スワップ]] を参照してください)。たとえば、4 GiB のスワップファイルを作成します:

# mkswap -U clear --size 4G --file /swapfile

スワップファイルを有効化してください:

# swapon /swapfile

最後に、fstab 設定を編集してスワップファイルのエントリを追加してください:

{{hc|/etc/fstab|
/swapfile none swap defaults 0 0
}}

fstab にエントリを追加する以外に、スワップユニットを作成する方法もあります ({{man|5|systemd.swap}} を参照):

{{hc|/etc/systemd/system/swapfile.swap|2=
[Swap]
What=/swapfile

[Install]
WantedBy=swap.target
}}

作成後は [[daemon-reload]] を実行し、{{ic|swapfile.swap}} を[[有効化]]してください。

追加の情報については [[fstab#使用法]] を見てください。

{{Note|スワップファイルは、UUID やラベルではなくファイルシステム上の位置により指定されなければなりません。}}

==== スワップファイルの削除 ====

スワップファイルを削除するには、まずスワップファイルを無効にしなければなりません。その後、スワップファイルを削除できます:

# swapoff /swapfile
# rm -f /swapfile

最後に {{ic|/etc/fstab}} から該当するエントリを削除してください。

== スワップの暗号化 ==

[[dm-crypt/スワップの暗号化]]を見て下さい。

== パフォーマンス ==

通常、スワップに対する操作は RAM 上のデータに対する直接アクセスよりも断然遅くなります。しかし、パフォーマンスを向上させようとしてスワップを全体的に無効化するとパフォーマンスの劣化を招くことがあります。データを保持しておくのに十分な物理メモリが無い場合、スワップアウトできないとファイルシステムキャッシュのためのメモリが足りなくなってしまいます。その結果、ディスクへのアクセスが増加し、負荷が増加します。

スワップ値を変えることでパフォーマンスを向上できるかもしれません。

=== Swappiness ===

メモリ使用量が特定の閾値に達すると、カーネルはアクティブなメモリを調べ、何を解放できるかを確認し始めます。ファイルデータは (変更されている場合) ファイルシステムに書き出して、アンロードし、後で再ロードすることができます。他のデータは、アンロードする前にスワップに書き込まなければなりません。

''Swappiness'' [[sysctl]] パラメータは、カーネルが書き込み先としてファイルよりもスワップを優先する度合いを表します。Swappiness は 0 から 200 の間の値にすることができます (Linux < 5.8 では 100 が最大)。デフォルトの値は 60 です。小さい値にすると、カーネルは開いているファイルの解放を優先し、大きい値にすると、カーネルはスワップ領域を使おうとします。100 にすると、IO コストが等しいとみなされます。

{{Note|Swappiness がメモリの閾値に影響を与えたり、スワップ領域を使用させなくしたりするとよく誤解されます。しかし、この値は、スワップとファイルページのどちらを優先して解放するかだけに影響を与えます。より詳細な説明は[https://www.howtogeek.com/449691/what-is-swapiness-on-linux-and-how-to-change-it/ この記事]を、あるいはこの値が使われている[https://github.com/torvalds/linux/blob/v6.2/mm/vmscan.c#L3000-L3014 カーネルのソースコード]を参照してください。}}

現在の swappiness 値をチェックするには:

$ sysctl vm.swappiness

代わりに {{ic|/proc/sys/vm/swappiness}} ファイルを読むことで生の整数値を得ることができます。

swappiness 値を一時的にセットするには:

# sysctl -w vm.swappiness=35

swappiness 値を永続的にセットするには、{{man|5|sysctl.d}} 設定ファイルを作成します。例えば:

{{hc|/etc/sysctl.d/99-swappiness.conf|2=
vm.swappiness = 35
}}

[[ブートローダー]]を使ってカーネルのロード時に swappiness を設定するには、[[カーネルパラメータ]]を追加してください。例えば: {{ic|1=sysctl.vm.swappiness=35}}。

他の swappiness 値を選択する理由としては以下があります:

* デスクトップの応答性のために swappiness を下げることが[https://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that 提案されている]から。この主張の言わんとしていることは、知覚されるパフォーマンス (応答性) はプログラムがユーザーの入力にいかに速く応答するかによるため、anonymous ページ (プログラムのメモリ) は RAM 内に留めておくべきであり、''実際の''パフォーマンスを多少犠牲にしてでも開いたファイルの解放を優先させるべきというものです。
** [https://chrisdown.name/2018/01/02/in-defence-of-swap.html 妥当な swappiness の最小値]は 1 です。Swappiness を 0 にすると、anonymous ページのエビクションに対して極端なバイアスが掛かり、メモリ争奪の極端な状況を除いて anonymous ページを reclaim やスワップするためにスキャンできなくなります。全く使用されていない anonymous ページを reclaim しないことは一般に望ましくありません。
* 100 以上の高い swappiness に設定することは、スワップする IO コストがファイルからの読み出しコストと同じかより小さい場合に (定義上) 望ましいから。このような状況は[https://lists.ubuntu.com/archives/lubuntu-users/2013-October/005831.html スワップがディスクをバッキングデバイスとして使用していない]場合 (特に [[zram]] を使用している場合) に起こり得ます。また、スワップ IO が [[zswap]] などの低コストなメカニズムによってインターセプト/キャッシュされる場合にも起こり得ます。

=== VFS cache pressure ===

スワップのパフォーマンスに影響を与えるもう1つの ''sysctl'' パラメーターは {{ic|vm.vfs_cache_pressure}} です。このパラメータは、ページキャッシュとスワップと比較して、VFS キャッシュのキャッシングのために使用されているメモリをカーネルが reclaim する優先度を制御します。この値を増やすと、VFS キャッシュが reclaim される割合が上がります。このパラメータの詳細は [https://docs.kernel.org/admin-guide/sysctl/vm.html Linux カーネルのドキュメント]を参照してください。

デフォルトの値は 100 です。この場合、ファイルシステムのキャッシュは他のキャッシュと同じくらい重要ということになり、両方のキャッシュは同じ重みで reclaim されます。デスクトップでは、ファイルシステムのブラウジング時間は操作のレイテンシ (知覚される応答性) に影響を与えるから[https://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that ファイルシステムのキャッシュは他のキャッシュよりも重要である]ため、VFS cache pressure は 50 に設定するべきと主張されています。一方、VFS キャッシュに二度とアクセスされない多くの小さなファイルのメタデータが保持されている場合、より大きな値に設定することが[https://docs.gluster.org/en/main/Administrator-Guide/Linux-Kernel-Tuning/#vmvfs_cache_pressure 提案されています]。このパラメータのチューニングに関する詳細は [https://web.archive.org/web/20171004100853/http://doc.opensuse.org/documentation/leap/tuning/html/book.sle.tuning/cha.tuning.memory.html#cha.tuning.memory.vm.reclaim OpenSUSE のチューニングガイド]を参照してください (このガイドでは、キャッシュのタイプを {{ic|slaptop}} でチェックし実験することが推奨されています)。

=== 優先度 ===

複数のスワップファイルやスワップパーティションを使っている場合、priority 値 (0 から 32767) をそれぞれのスワップ領域に割り当てることを考えて下さい。システムは優先度が低いスワップ領域を使う前に高い優先度が付けられたスワップ領域を使います。例えば、もしあなたが高速なディスクと低速なディスクを持っている場合、高速なデバイス上のスワップ領域に高い優先度をあててください。priority は [[fstab]] で {{ic|pri}} パラメータを使って設定できます:

UUID=f9fe0b69-a280-415d-a03a-a32752370dee none swap defaults,pri=100 0 0
UUID=d7eb6062-01c8-4367-ac1d-3bf1167de8bb none swap defaults,pri=10 0 0

もしくは ''swapon'' の {{Ic|--priority}} パラメータを使います:

# swapon --priority 100 /dev/sda1

もし2つ以上の領域が同じ priority を持ち、それが一番高い priority の場合、その領域間ではラウンドロビン方式でページが配分されます。

=== ストライピング ===

スワップの性能を上げるために [[RAID]] を使う必要はありません。{{ic|/etc/fstab}} ファイルでスワップの優先度が同じに設定されている場合、複数のデバイスにスワップをストライプ処理するのはカーネルだけで行うことができます。詳しくは [http://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-2.html#ss2.3 The Software-RAID HOWTO] を参照してください。

=== Discard (トリム) ===

[[ソリッドステートドライブ#スワップ]] を参照。

=== RAM 内の圧縮ブロックデバイス ===

[[パフォーマンスの向上#zram や zswap でのスワップ]] を参照。

=== スワップ領域をハイバーネート専用に使う ===

スワップをハイバネートイメージストレージ領域としてしか使わない場合、[[zswap]] を使い、そのライトバックを無効化することで、通常のスワップ仕様ではディスク書き込みが起こらないようにすることができます。[[電源管理/サスペンドとハイバネート#Zswap のライトバックを無効化し、スワップ領域をハイバネートのみに使用する]] を参照してください。

== 参照 ==

* [https://chrisdown.name/2018/01/02/in-defence-of-swap.html In defence of swap: common misconceptions] (日本語訳: [https://chrisdown.name/ja/2018/01/02/in-defence-of-swap.html スワップの弁護：よくある誤解を解く])

{{TranslationStatus|Swap|2025-07-07|839579}}

パフォーマンスの向上

2025-07-07T09:44:20Z

AshMyzk: 同期

[[Category:ハードウェア]]
[[Category:システム管理]]
[[en:Improving performance]]
[[es:Improving performance]]
[[fr:Improving performance]]
[[pl:Improving performance]]
[[pt:Improving performance]]
[[ru:Improving performance]]
[[zh-hans:Improving performance]]
{{Related articles start}}
{{Related|パフォーマンスの向上/ブートプロセス}}
{{Related|Pacman ヒント#パフォーマンス}}
{{Related|OpenSSH#SSH の高速化}}
{{Related|OpenOffice#OpenOffice の高速化}}
{{Related|ノートパソコン}}
{{Related|Preload}}
{{Related articles end}}

この記事では、知覚または計測できるシステムパフォーマンスの向上を最終目的として、パフォーマンスに関連する基本的なシステム診断、及び、リソース消費量の削減やシステム最適化のための手順に関する情報を提供しています。ゲーミングおよび低レイテンシに特有のその他のアドバイスは [[ゲーム#パフォーマンスを向上させる]] も参照してください。

== 基本 ==

=== システムを知る ===

システムをチューンするには、全体のスピードを下げているボトルネックやサブシステムに狙いを定めるがベストな方法です。システムの仕様を知ることは、それらを特定することに役立ちます。

* (LibreOffice や Firefox などの) 巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の容量が十分であるか確認してください。以下のコマンドを使って、"available" 列の値を確認してください: {{bc|$ free -h}}
* 起動時間が長い場合、または、アプリケーションを初めて起動するとき (だけ) にロードに長い時間が掛かる場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには {{ic|hdparm}} コマンドを使うことができます: {{bc|# hdparm -t /dev/sd''X''}} {{Note|{{Pkg|hdparm}} で出力されるのはハードドライブの純粋な読み込み速度なので、有効なベンチマークとは言えませんが、平均的なコンピュータでは (アイドル状態のときに) 40MB/s より高い数値が出るのが妥当です。}}
* 十分な RAM が利用できる時でも CPU 負荷が一貫して高い場合、不要な[[デーモン]]やプロセスを無効化するなどして CPU 使用量を減らすことを試みてください。{{Pkg|htop}} や {{ic|pstree}} などの[[アプリケーション一覧/ユーティリティ#システム監視|システム監視ツール]]で CPU 負担をモニタすることができます: {{bc|$ htop}}
* ダイレクトレンダリングを使うアプリケーション (つまり、ビデオプレイヤ、ゲーム、[[ウィンドウマネージャ]]などの GPU を使うアプリケーション) が遅い場合、GPU パフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。{{ic|glxinfo}} コマンドを使うことで確認できます ({{Pkg|mesa-utils}} パッケージに含まれています)。次のコマンドを実行すると {{ic|direct rendering: Yes}} と表示される必要があります: {{bc|$ glxinfo {{!}} grep "direct rendering"}}
* [[デスクトップ環境]]を動かしている場合、(不要な) 視覚デスクトップ効果を無効化することで GPU 使用率を削減できる場合があります。現在使用しているものがハードウェアや個人の要件に合わない場合、より軽量な環境を使用するか、[[デスクトップ環境#カスタム環境|カスタムの環境]]を作成しましょう。
* 最適化された[[カーネル]]を使用することでパフォーマンスを向上できます。一般に {{Pkg|linux-zen}} が良い選択肢です。しかし、この記事の特定の部分で説明されているように、デフォルトのカーネルを調節することで良いパフォーマンスを得られます。

=== ベンチマーク ===

最適化の効果を判断できないことがたびたびあります。そういった場合は[[ベンチマーク]]ツールで計測することができます。

== ストレージデバイス ==

==== セクタサイズ ====

NVMe ドライブや Advanced Format ハードディスクが[[アドバンスドフォーマット|適切な論理セクタサイズ]]を使用していることを確認してください。

=== パーティショニング ===

パーティションが[[パーティショニング#パーティションアライメント|適切にアライメントされている]]ことを確認してください。

==== 複数のドライブ ====

複数のドライブを持っているのであれば、ソフトウェア [[RAID]] を組んでパフォーマンスを劇的に向上させることができます。

[[スワップ]]を別のディスク上に作成することでもパフォーマンスを多少向上させることができます。特に、スワップが頻繁に発生する場合です。

===== SSD を HDD のキャッシュとして使う =====

ハードディスクから移行することができない場合、ソリッドステートドライブをキャッシュレイヤとして使うことで読み書き速度を向上させ、ランダムアクセスによるパフォーマンスの低下を減らすことができます。方法としては、[[LVM#キャッシュ]]、[[Bcache]]、[[Bcachefs#SSD キャッシング]] があります。

==== HDD でのレイアウト ====

従来の回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター（ディスクの外周の近く）は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さく (15~20GiB、必要に応じて調節) して、できるだけドライブの最初に配置することが推奨されます。他のデータ（画像・動画など）は別のパーティションに置くべきです。通常、システム ({{ic|/}}) から home ディレクトリ ({{ic|/home}}) を分割することでこれを達成できます。

{{Note|このページのすべてのアドバイスにおいて言えることですが、得られる利益を計測してください: ハードドライブを[https://blog.stuffedcow.net/2019/09/hard-disk-geometry-microbenchmarking/#shortstroke ショートストローク]したり、合計容量の数％しか使わないようにしたりしない限り、一般的な使用においては読み書き操作が依然としてドライブ全体に及ぶため、パーティションを分割してもほんの数%しかアクセス時間は改善されません。それと比べて、SSD にアップグレードするとパフォーマンスが1桁以上向上します。}}

=== ファイルシステムの選択とチューニング ===

ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。[[ファイルシステム]]の記事に人気のあるファイルシステムの簡単な説明がされています。[[:カテゴリ:ファイルシステム]]から関連記事も見ることができます。

==== マウントオプション ====

様々な [[fstab#atime オプション|*atime]] オプションが、{{ic|strictatime}} のパフォーマンスのペナルティを軽減することができます。

他のマウントオプションはファイルシステム固有なので、ファイルシステムの関連記事を参照してください:

* [[Ext3]]
* [[Ext4#パフォーマンスの向上]]
* [[JFS#最適化]]
* [[XFS#パフォーマンス]]
* [[Btrfs#デフラグメンテーション]]、[[Btrfs#圧縮]]、{{man|5|btrfs}}
* [[ZFS#チューニング]]
* [[NTFS#パフォーマンスの向上]]

===カーネルパラメータの調整===

ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは [[sysctl#仮想メモリ]] を見て下さい。

=== I/O スケジューラの設定 ===

==== 背景情報 ====

入出力 ''(I/O)'' スケジューラはストレージデバイスにブロック I/O の操作を送信するときの順番を決めるカーネルコンポーネントです。I/O スケジューラの目的は読み込みリクエストを最適な方法で扱うことであるため、以下の2つのドライブの特徴を押さえておくことが重要です:

* HDD は回転ディスクでありヘッドが物理的に必要な場所に移動します。そのため、ランダムアクセスは 3〜12ms と非常に遅くなります (ハイエンドサーバーのドライブなのかノートパソコンのドライブなのか、あるいはディスクコントローラの書き込みバッファを迂回するかなどで速度は変わります)。逆に連続アクセスなら高いスループットを得ることが可能です。連続アクセスならヘッドはほとんど動かなくてよいためです。典型的な HDD は毎秒200回ほどの I/O リクエストを処理することができます ''(IOPS)''。

* SSD には物理的に移動する部品がありません。ランダムアクセスはシーケンシャルアクセスと同じ速度が出ます (0.1ms 未満)。SSD は複数のリクエストを一度にこなすこともできます。典型的な SSD のスループットは 10,000 IOPS を超えるため、大抵の場合は必要な仕事量を上回ります。

プロセスを大量に実行してストレージの様々な場所の I/O リクエストを発生させているとき (つまりランダムアクセスをしている状態)、数千の IOPS が生成されますが、普通の HDD では 200 IOPS までしか対応できません。ストレージにアクセスできるまで待機するリクエストの待ち行列が作られることになります。I/O スケジューラはこの待ち行列を最適化します。

==== スケジューリングアルゴリズム ====

スループットを改善する方法の一つとして、待機リクエストの順番を論理アドレスで並び替えてできるだけ一番近いリクエストを通すことで、アクセスをリニア化する方法があります。これが [[w:ja:エレベータアルゴリズム|elevator]] スケジューラと呼ばれる Linux の最初の I/O スケジューラでした。

エレベータアルゴリズムの問題点はシーケンシャルアクセスをするプロセスが上手く動かなくなることです。そのようなプロセスは、データブロックを読み取って数マイクロ秒で処理してから次のブロックを読み出します。エレベータスケジューラはプロセスが近くのブロックを呼びだそうとしていることを知らないため、他の場所のリクエストに移ってしまいます。[[w:Anticipatory_scheduling|anticipatory]] IO スケジューラはこの問題を解決します。このスケジューラは、他のリクエストを処理する前に、近くで別の読み取り操作が発生することを予測して、数ミリ秒待機します。

上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて [[w:Deadline_scheduler|deadline]] スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターアルゴリズムと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。

[[w:CFQ|Completely Fair Queuing (CFQ)]] は別のアプローチで問題に取り組みました。CFQ はプロセスの優先度に基づくキューを使ってタイムスライスと許容するリクエストの数を割り当てます。さらに [[cgroups]] のサポートを追加することで特定のプロセスグループに一定の IO を予約できるようにしました。これは共有・クラウドサーバーで特に役立ちます。ユーザーはリソースが必要なときに料金を払って IOPS を得られるのです。また、同期 I/O で近くの操作を待機するという ''anticipatory'' スケジューラの機能を改良して取り入れています。''anticipatory'' と ''elevator'' スケジューラは Linux カーネルから外され、下記のより高度な代替スケジューラに置き換えられました。

[https://docs.kernel.org/block/bfq-iosched.html Budget Fair Queuing (BFQ)] は CFQ のコードをベースにいくつか改善を加えています。各プロセスに固定長のタイムスライスを与えるかわりに、プロセスのセクタ数から計算した "budget" を割り当ててヒューリスティックを用います。BFQ は想定的に複雑なスケジューラであるため、オーバーヘッドが大きく、回転ドライブや低速 SSD に適しています。特に遅い CPU と組み合わせたときに高速なデバイスの足を引っ張ってしまうような場合に有用です。BFQ は個人用のシステムでインタラクティブな作業を行うときに、ストレージデバイスがまるで待機状態のときのように素早く反応することを目標としています。デフォルト設定ではスループットの最大化よりもレイテンシの最小化が優先されているのが特徴です。これにより、ハードドライブにおいて[https://www.phoronix.com/review/linux-50hdd-io/2 アプリケーションの起動を劇的に加速化]させられる場合があります。

[https://lwn.net/Articles/720675/ Kyber] はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。

==== カーネルの I/O スケジューラ ====

初期のアルゴリズムには既にメインラインから外されているものもあります。公式の Linux カーネルはいくつかの I/O スケジューラをサポートしています。[https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mechanism_(blk-mq) Multi-Queue Block I/O Queuing Mechanism (blk-mq)] は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。このフレームワークでは以下のスケジューラが使えます:

*''None''、キューイングアルゴリズムは適用されません。
*''mq-deadline'' は deadline スケジューラ (下記を参照) をマルチスレッドに対応させたスケジューラです。
*''Kyber''
*''BFQ''

==== I/O スケジューラの変更 ====

{{Note|スケジューラーの最適な選択は、デバイスとワークロードの正確な性質の両方によって異なります。また、MB/秒単位のスループットだけがパフォーマンスの指標ではありません。デッドラインや公平性は全体的なスループットを低下させますが、システムの応答性を向上させる可能性があります。 [[ベンチマーク]] は、各 I/O スケジューラのパフォーマンスを示すのに役立つ場合があります。}}

特定のデバイスで利用可能なスケジューラとアクティブなスケジューラを表示するには (アクティブなスケジューラは角括弧の中):

{{hc|$ cat /sys/block/'''''sda'''''/queue/scheduler|
mq-deadline kyber [bfq] none
}}

全デバイスで利用可能なスケジューラを表示するには:

{{hc|$ grep "" /sys/block/'''*'''/queue/scheduler|
/sys/block/pktcdvd0/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none
}}

デバイス ''sda'' のアクティブな I/O スケジューラを ''bfq'' に変更するには:

# echo '''''bfq''''' > /sys/block/'''''sda'''''/queue/scheduler

I/O スケジューラの変更プロセスは、ディスクが回転式か否かに応じて自動化することができ、起動毎に永続化させることができます。例えば、以下の [[udev]] ルールは、回転ドライブに対しては ''bfq'' を、[[SSD]]/eMMC ドライブに対しては ''bfq'' を、[[NVMe]] に対しては ''none'' を設定します:

{{hc|/etc/udev/rules.d/60-ioschedulers.rules|<nowiki>
# HDD
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

# SSD
ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"

# NVMe SSD
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
</nowiki>}}

再起動するか、強制的に[[udev#新しいルールをロードする|新しいルールをロード]]してください。

==== IO スケジューラの調整 ====

カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用います。
設定項目と説明は [https://docs.kernel.org/block/index.html カーネルドキュメント] で確認できます。

特定のデバイスで設定可能なパラメータを確認するには (以下の例では ''sdb'' は ''deadline'' を使用しています):

{{hc|$ ls /sys/block/'''''sdb'''''/queue/iosched|
fifo_batch front_merges read_expire write_expire writes_starved}}

レイテンシを犠牲に ''deadline'' のスループットを高めるには以下のコマンドで {{ic|fifo_batch}} を増やします:

{{bc|# echo ''32'' > /sys/block/'''''sdb'''''/queue/iosched/'''fifo_batch'''}}

=== 電源管理設定とライトキャッシュ ===

従来の回転ディスク (HDD) を使用する場合は、省電力機能を完全に無効にするか下げるかし、書き込みキャッシュが有効になっているかどうかを確認すると良いかもしれません。

[[Hdparm#電源管理の設定]] と [[Hdparm#ライトキャッシュ]] を参照してください。

後で、起動時にこれらを適用する [[Hdparm#udev ルールによる永続的な設定|udev ルール]] を作成することができます。

{{Tip|[[GNOME]] では、"ディスク" アプリケーションからこれらのパラメータのいくつかを設定でき、udev ルールは必要ありません。}}

{{Note|一部の機能はあなたのハードドライブではサポートされていないかもしれません。その場合、Hdparm が通知します。なので、この特定の機能の設定を無視してください。}}

=== ディスクの読み書きを減らす ===

遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。

{{Note|書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、'''毎日 10GB のデータ書き込みを行うと'''、'''8年間で寿命が尽きる'''とされます。この数字はもっと[https://kcall.co.uk/ssd/ 容量が大きい SSD] を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときは[https://web.archive.org/web/20161124030749/http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead この耐久実験]も参照してください。}}

==== ディスクの書き込みを表示する ====

{{Pkg|iotop}} パッケージはプログラムをディスクの書き込み数でソートして、どれくらいの頻度でどれだけディスクに書き込んでいるか表示します。詳しくは {{man|8|iotop}} を見てください。

==== ファイルを tmpfs に再配置する ====

ブラウザプロファイルなどのファイルを [[tmpfs]] ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます:

* ブラウザプロファイルを同期させる方法については [[Profile-sync-daemon]] を参照してください。特定のブラウザには注意が必要な場合があります。例えば [[Firefox Ramdisk]] を参照してください。
* 任意の指定されたフォルダを同期させる方法については [[Anything-sync-daemon]] を参照してください。
* tmpfs 内でパッケージをビルドすることでコンパイル時間を減らす方法については [[Makepkg#ビルド時間を短縮する]] を参照してください。

==== ファイルシステム ====

対応する[[ファイルシステム]]ページを参照して、パフォーマンス改善に関する指示があるか見てください。[[#ファイルシステムの選択とチューニング]] に挙げられているファイルシステムのリストも参照してください。

==== スワップ領域 ====

詳細は [[スワップ#パフォーマンス]] を見てください。

==== ライトバックの間隔とバッファサイズ ====

詳細は [[Sysctl#仮想メモリ]] を見てください。

==== コアダンプを無効化する ====

[[コアダンプ#自動的なコアダンプの無効化]] を見てください。

=== ionice によるストレージ I/O スケジューリング ===

バックアップなど多くのタスクにおいては、そのタスクを実行するために、ストレージ I/O の遅延が短かったり、ストレージ I/O の帯域が大きかったりする必要はありません。そのようなタスクはバックグラウンドタスクに分類することができます。一方、デスクトップにおいて高速な I/O は UI の応答性を高める上で必須です。ゆえに、他のタスクがストレージ I/O を必要としている間は、バックグラウンドタスクによって利用できるストレージ帯域幅を減らすことが有益です。これは、プロセスごとに異なる優先度を設定できる Linux I/O スケジューラ BFQ を使用することで実現できます。

以下のようにバックグラウンドプロセスを実行することで、プロセスの I/O 優先度 "Idle" レベルまで落とすことができます:

$ ionice -c 3 ''command''

詳細は [https://www.cyberciti.biz/tips/linux-set-io-scheduling-class-priority.html a short introduction to ionice] や {{man|1|ionice}} を参照してください。

=== トリム ===

最適なパフォーマンスを得るには、SSD の空きブロックを定期的に discard (トリム) してランダム書き込みの速度を最適化するべきです。詳細は [[ソリッドステートドライブ#TRIM]] を参照してください。

== ネットワーク ==

* カーネルネットワーキング: [[Sysctl#パフォーマンスを向上させる]] を参照
* NIC: [[ネットワーク設定#MTU とキューの長さの設定]] を参照
* DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。[[ドメイン名前解決#DNS サーバ]] を参照
* Samba: [[Samba#スループットを向上させる]] を参照

== CPU ==

=== オーバークロック ===

[[Wikipedia:ja:オーバークロック|オーバークロック]]は、CPU クロック周波数の上限を上げることにより、CPU の計算パフォーマンスを向上させます。オーバークロックできるかどうかは、CPU モデルとマザーボードモデルの組み合わせに依存します。オーバークロックは BIOS を介して行うのが最も一般的です。オーバークロックには欠点とリスクもあります。ここでは推奨も非推奨もしないでおきましょう。

Intel 製のチップの多くは acpi_cpufreq などや他のほとんどのユーティリティに正しいクロック周波数を伝えません。この結果、[[dmesg]] は極端なメッセージを表示します (これは、{{ic|acpi_cpufreq}} カーネルモジュールをアンロードしてブラックリスト化することで回避可能です)。クロック速度を読むには、{{Pkg|i7z}} パッケージの ''i7z'' を使用してください。オーバークロックされた CPU が正しく動作していることを確認する方法として、[[ストレステスト]]が推奨されます。

=== 周波数スケーリング ===

[[CPU 周波数スケーリング]]を見てください。

=== CPU スケジューラ ===

メインライン Linux カーネルのデフォルトの CPU スケジューラは [https://lwn.net/Articles/925371/ EEVDF] です。

* {{App|[[Wikipedia:Brain_Fuck_Scheduler#MuQSS|MuQSS]]|Multiple Queue Skiplist Scheduler。[[Wikipedia:Con_Kolivas|Con Kolivas]] によって開発されている {{ic|-ck}} パッチセットにより利用可能。|[[非公式ユーザーリポジトリ/Repo-ck]]|{{AUR|linux-ck}}}}
* {{App|[https://cchalpha.blogspot.com/2020/05/project-c-announcement.html Project C]|BMQ を Project C にリファクタリングするためのクロスプロジェクト。Project C コードベースに基づいて PSD を再作成します。よって、これは2つのプロジェクトのマージであり、その後 PDS が Project C として更新されます。より最近の開発として推奨されます。|https://cchalpha.blogspot.com/|{{AUR|linux-prjc}}}}
* {{App|BORE|BORE スケジューラは、対話型タスクにおいてある程度の公平性を犠牲にして低レイテンシを実現することに焦点を当てています。CFS の上に構築されており、vruntime コード更新だけに調整されています。なので、他の非公式 CPU スケジューラと比較して、全体的な変更は非常に小さいです。|https://github.com/firelzrd/bore-scheduler|{{AUR|linux-cachyos-bore}}}}
* {{App|SCX|システムをリセットせずに様々な CPU スケジューラを動的にロードできるようにします。|https://github.com/sched-ext/scx|{{Pkg|scx-scheds}}}}

=== リアルタイムカーネル ===

(TV チューナーカードをフル HD 解像度 (1080p) で実行するなど) 一部の使用用途では、[[リアルタイムカーネル]]を使うと利益を得られる場合があります。

=== プロセスの優先順位を設定 ===

{{man|1|nice}} と {{man|1|renice}} も参照してください。

==== Ananicy ====

[https://gitlab.com/ananicy-cpp/ananicy-cpp Ananicy CPP] は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、{{Pkg|ananicy-cpp}} や {{AUR|ananicy-cpp-git}} パッケージで利用可能です。nice レベルとは、CPU リソースを配分するときの実行可能ファイルの優先度を表すものです。

{{Warning|1=[[Gamemode]] と [https://gitlab.com/ananicy-cpp/ananicy-cpp Ananicy CPP] はどちらもプロセスの nice レベルを調整しようとします。これらのツールを組み合わせて使用することは推奨されていません。[https://github.com/CachyOS/ananicy-rules/blob/master/README.md#gamemode--ananicy-cpp--bad-idea]}}

==== cgroups ====

[[cgroups]] を見てください。

==== LimitCPU ====

[https://limitcpu.sourceforge.net/ LimitCPU] は特定のプロセスの CPU 使用率を制限するプログラムです。{{AUR|limitcpu}} をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:

$ limitcpu -l 50 -p 5081

=== irqbalance ===

{{Pkg|irqbalance}} はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。{{ic|irqbalance.service}} で[[systemd#ユニットを使う|操作]]することが可能です。

=== CPU の脆弱性の緩和策をオフにする ===

{{Warning|1=以下の設定を使うときは問題の脆弱性について確認してください。詳しくは [https://phoronix.com/scan.php?page=news_item&px=Linux-Improve-CPU-Spec-Switches こちら] や [https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_CPUs こちら] のページを参照。}}

CPU の脆弱性の緩和策をオフにすることで、パフォーマンスが向上する場合があります。以下の[[カーネルパラメータ]]ですべての緩和策が無効になります:

mitigations=off

このパラメータによって切り替えられるすべてのスイッチについての説明は、[https://docs.kernel.org/admin-guide/kernel-parameters.html kernel.org] で見られます。{{AUR|spectre-meltdown-checker}} や {{man|1|lscpu}} ({{Pkg|util-linux}} に同梱) を使うことで、脆弱性チェックを行うことができます。

{{Note|1=第10世代およびそれ以降の Intel CPU、または AMD Ryzen シリーズ 1000 およびそれ以降の CPU を使用している場合、緩和策を無効化することにより得られるパフォーマンスの向上は、最大でも 5% にとどまります。一方、それ以前の世代の CPU では、最大 25% まで向上します。[https://www.phoronix.com/scan.php?page=article&item=3-years-specmelt 2021 初頭における総評]、[https://www.phoronix.com/scan.php?page=article&item=spectre-rocket-lake Rocket Lake におけるテスト]、[https://www.phoronix.com/scan.php?page=article&item=alder-lake-mitigations Alder Lake におけるテスト] を参照。}}

== グラフィック ==

=== Xorg の設定 ===

グラフィックパフォーマンスは {{man|5|xorg.conf}} の設定に依存している場合があります。[[NVIDIA]]、[[AMDGPU]]、[[Intel]] の記事を参照してください。不適切な設定は Xorg が動作しなくなる原因になるため、注意しましょう。

=== Mesa の設定 ===

Mesa ドライバのパフォーマンスは [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ drirc] で設定できます。{{Pkg|adriconf}} (Advanced DRI Configurator) はオプションを設定して標準の drirc ファイルに書き込むことで MESA ドライバを設定する GUI ツールです。

=== ハードウェアビデオアクセラレーション ===

[[ハードウェアビデオアクセラレーション]]により、ビデオカードに動画のデコード/エンコードをさせることができます。

=== オーバークロック ===

CPU と同様に、(GPU の) オーバークロックは直接的にパフォーマンスを向上できますが、一般には推奨されません。いくつかのパッケージがあります: {{AUR|rovclock}} (ATI カード)、{{Pkg|rocm-smi-lib}} (最近の AMD カード)、{{AUR|nvclock}} (古い NVIDIA カード - Geforce 9 まで)、{{Pkg|nvidia-utils}} (最近の NVIDIA カード)。

[[AMDGPU#オーバークロック]] や [[NVIDIA/ヒントとテクニック#オーバークロックを有効化する]] を参照してください。

=== PCIe resizable BAR を有効化する ===

{{Note|
* 一部のシステムでは、PCIe resizable BAR を有効化するとパフォーマンスが大幅に劣化する可能性があります。システムのベンチマークを行って、PCI resizable BAR がパフォーマンスを向上させていることを確認してください。
* 効果を発揮させるには、[[Wikipedia:Unified Extensible Firmware Interface#CSM booting|Compatibility Support Module (CSM)]] を無効化しなければなりません。
}}

PCI の仕様では、PCI デバイスのメモリを PCI コントローラに公開するために、より大きい[[wikipedia:PCI_configuration_space#Standardized_registers|基底アドレスレジスタ]] (BAR) を使用できます。そうすることで、ビデオカードのパフォーマンスを向上できる可能性があります。ビデオメモリ全体にアクセスすることでパフォーマンスを向上できますし、グラフィックドライバの最適化も可能になります。Resizable BAR、above 4G decoding、そしてドライバ最適化の組み合わせを、AMD は [https://www.amd.com/en/gaming/technologies/smart-technologies.html AMD Smart Access Memory] と呼んでおり、初期は AMD Series 500 チップセットマザーボードで利用できましたが、後に UEFI アップデートを通して AMD Series 400 と Intel Series 300 以降に拡張されました。この設定はすべてのマザーボードで利用できるわけではなく、特定のボードではブート問題を引き起こすことが知られています。

BAR のサイズが 256M の場合、この機能は有効化されていないか、サポートされていません:

{{hc|1=# dmesg {{!}} grep BAR=|2=
[drm] Detected VRAM RAM=8176M, BAR=256M}}

有効化するには、マザーボード設定で "Above 4G Decode" か ">4GB MMIO" という名前の設定を有効化してください。BAR が大きくなっていることを確認するには:

{{hc|1=# dmesg {{!}} grep BAR=|2=
[drm] Detected VRAM RAM=8176M, BAR=8192M}}

== RAM、スワップ、OOM 処理 ==

=== クロック周波数とタイミング ===

RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリのメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。[[#オーバークロック]]を参照。

=== RAM オーバーレイ上に root を置く ===

{{Out of date|liveroot スクリプトはメンテナンスされていないようです。しかし、このアプローチは依然として機能するはずです。}}

書き込みが遅いメディア (USB や回転 HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。{{AUR|liveroot}} を見て下さい。

=== zram 内のスワップや zswap ===

[[zswap]] や [[zram#スワップとしての使用|zram 内のスワップ]]を使うことで、似たような利点を (同じくらいのコストで) 得られます。これら2つは一般に意図が似ていますが、動作が異なります:

* zswap は、圧縮された RAM キャッシュとして動作し、ユーザ空間の設定をあまり必要としません (と同時に許可もしていません)。スワップデバイスと組み合わせて、スワップのキャッシュとして動作します。スワップに入りそうなページは、代わりに zswap に入る可能性があります。

* zram は、RAM 内に圧縮されたブロックデバイスを作成できるカーネルモジュールです。この圧縮されたブロックデバイスはスワップデバイスとして使用でき、他のスワップデバイスと組み合わせる必要はありません。多くの設定オプションがあり、例えばコールドページを保持しておくバッキングデバイスを使用するかどうかも指定できます。

両方とも[[スワップ]]サブシステムを呼び出すため、スワップに影響を与える設定はこれらのシステムにも影響を与えます。例えば、[[スワップ#Swappiness|swappiness]] は、メモリが圧迫している状況で、カーネルがファイルキャッシュをドロップするか、ページをスワップに移動させるかのどちらを優先させるかを指定します。Zswap はページのスワップへの移動動作をインターセプトし、zram もスワップとして動作するため、このオプションはこれら2つのメカニズムがどれくらいの頻度で使用されるかにも影響を与えます。

=== グラフィックカードの RAM を使う ===

稀なケースとして、RAM 容量が非常に小さいが、ビデオ RAM に余りがある場合、後者をスワップとして使用できます。[[ビデオメモリにスワップ]] を参照してください。

=== メモリ不足の状況におけるシステムのレスポンスを改善する ===

従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の out-of-memory (OOM) killer がトリガーされるか、十分な量のメモリが開放される (システムが応答しない場合、メモリを大量消費するアプリケーションを閉じることは難しいため、これはすぐには起こり得ないでしょう) まで、システム全体のレスポンスがほぼ使用不能な状態まで低下します。挙動は特定の環境や条件に依存しており、通常のレスポンス状態に戻るまでには数秒から30分以上かかる場合があります。会議でのプレゼンテーションなどのような重要な状況においては、待つのが苦痛になるでしょう。

[https://lore.kernel.org/lkml/d9802b6a-949b-b327-c4a6-3dbca485ec20@gmx.com/T/ カーネル]と[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ Fedora] のメーリングリストで議論されている通り、メモリ不足の状況におけるカーネルとユーザ空間の挙動は将来的に改善されるかもしれませんが、ユーザは、システムのハードリセットや {{ic|vm.overcommit_*}} [[sysctl]] パラメータの調整よりも実行可能で効果的なオプションを使うことができます:

* [https://docs.kernel.org/admin-guide/sysrq.html Magic SysRq キー] ({{ic|Alt+SysRq+f}}) で手動でカーネルの OOM killer をトリガーする。
* ユーザ空間の OOM デーモンを使ってこれに自動的 (または対話的) に対処する。

{{Warning|OOM killer をトリガーして実行中のアプリケーションを kill すると、保存されていない作業が失われる場合があります。アプリケーションが最終的に通常通りメモリを開放してくれることを期待して辛抱強く待つか、あるいは応答がないシステムを可能な限り早く通常に戻したいと望むかは、あなた次第です。}}

カーネルの OOM killer では終了する (しない) プロセスに優先順位を付けられないので、SysRq よりも OOM デーモンのほうが好ましい場合もあります。いくつかの OOM デーモンをリストアップしました:

* {{App|systemd-oomd|[[systemd]] によって {{ic|systemd-oomd.service}} として提供されています。cgroups-v2 と pressure stall information (PSI) を使用してプロセスを監視し、カーネル空間で OOM が発生する前にアクションを取ります。|https://github.com/systemd/systemd, {{man|8|systemd-oomd}}|{{Pkg|systemd}}}}
* {{App|earlyoom|C で書かれた、シンプルなユーザ空間の OOM killer 実装です。|https://github.com/rfjakob/earlyoom|{{Pkg|earlyoom}}}}
* {{App|oomd|[https://lwn.net/Articles/759781/ PSI] ベースの OOM killer 実装です。Linux カーネルバージョン 4.20+ を必要とします。設定は JSON で行い、非常に複雑です。Facebook の本番環境において動作確認済み。|https://github.com/facebookincubator/oomd|{{AUR|oomd}}}}
* {{App|nohang|Python で書かれた、洗練された OOM ハンドラ。オプションで PSI サポートあり。earlyoom よりも設定可能です。|https://github.com/hakavlad/nohang|{{AUR|nohang-git}}}}
* {{App|low-memory-monitor|GNOME 開発者の取り組み。ユーザ空間のアプリケーションにメモリ不足の状態を伝えるためのより良いコミュニケーションを提供することを目的としており、さらにカーネルの OOM killer をトリガーするように設定することができます。PSI ベースで、Linux 5.2+ を必要とします。|https://gitlab.freedesktop.org/hadess/low-memory-monitor/|{{AUR|low-memory-monitor-git}}}}
* {{App|uresourced|アクティブなグラフィカルユーザセッションに対して、cgroup ベースのリソース保護を有効化する小さなデーモン。|https://gitlab.freedesktop.org/benzea/uresourced|{{AUR|uresourced}}}}

== ウォッチドッグ ==

[[Wikipedia:Watchdog timer]] ([[wikipedia:ja:ウォッチドッグタイマー|日本語版]]) より:

:ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。

よって、ウォッチドッグは例外的な状況でカーネルの回復を最適化するために使用されています。もし、'''重要なシステムサービス''' (例: ネットワーク、ファイルシステム、ACPI、systemd) が応答しなくなった場合、ウォッチドッグはそれを検知し、再起動をトリガーします。それにより、システムがロックアップし、応答しなくなったサービスのせいで長い遅延が発生してしまうことを回避できます。[[#メモリ不足の状況におけるシステムのレスポンスを改善する]] で説明されているように、この緊急メカニズムとランタイムのシステムリソース管理とを区別することは重要です。

=== systemd ウォッチドッグ ===

systemd にはウォッチドッグのリセット機構が内蔵されています。これは、適切なカーネルモジュールがロードされている場合に (以下を参照)、{{ic|/dev/watchdog}} として公開されているハードウェアウォッチドッグと対話します。システムが応答しなくなった場合、ハードウェアウォッチドッグがシステムリセットをトリガーします。

==== systemd でウォッチドッグを設定する ====

デフォルトでは、{{ic|RuntimeWatchdogSec}} は無効化されています。システムのウォッチドッグを有効化するには、以下のような {{man|5|systemd-system.conf}} [[ドロップインファイル]]を作成してください:

{{hc|/etc/systemd/system.conf.d/watchdog.conf|2=
[Manager]
RuntimeWatchdogSec=10s
RebootWatchdogSec=45s
}}

* {{ic|1=RuntimeWatchdogSec=10s}}: systemd が 10 秒より長く応答しなかった場合、システムを再起動します。
* {{ic|1=RebootWatchdogSec=45s}}: システムが再起動中にハングした場合、ウォッチドッグは 45 秒後にリセットを強制します。

以下のコマンドで適用します:

# systemctl daemon-reexec

ウォッチドッグがアクティブであることを確認してください:

{{hc|$ systemctl show {{!}} grep Watchdog|2=
RuntimeWatchdogUSec=10s
RebootWatchdogUSec=45s
}}

==== ハードウェアのウォッチドッグサポートを確認する ====

多くのシステムで、ハードウェアウォッチドッグのサポートは異なるカーネルモジュール (例: 一部の Intel チップセットでは {{ic|iTCO_wdt}}、特定の AMD プラットフォームでは {{ic|sp5100_tco}}) によって提供されている場合があります。ハードウェアウォッチドッグのモジュールを確認するには、以下を実行してください:

$ lsmod | grep wdt

関連するウォッチドッグモジュール (例: {{ic|iTCO_wdt}}、{{ic|sp5100_tco}}) を見つけたら、以下のようなファイルを作成してモジュールが[[カーネルモジュール#systemd|ブート時にロード]]されるようにしてください:

{{hc|/etc/modules-load.d/watchdog.conf|
''module_name''
}}

# modprobe ''module_name''

{{ic|''module_name''}} の部分は、あなたのハードウェアにおける実際のモジュール名に置き換えてください。

=== リファレンス ===

* {{man|5|systemd-system.conf}}
* [https://docs.kernel.org/watchdog/index.html Linux カーネルウォッチドッグのドキュメント]
* [[Systemd-boot|Arch Wiki – Systemd Boot]]
* [https://0pointer.de/blog/projects/watchdog.html Lennart Poettering による systemd ウォッチドッグに関するブログ記事]

== 参照 ==

* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Performance_Tuning_Guide/index.html Red Hat Performance Tuning Guide]
* [https://www.thomas-krenn.com/en/wiki/Linux_Performance_Measurements_using_vmstat Linux Performance Measurements using vmstat]

{{TranslationStatus|Improving performance|2025-07-07|839855}}

NVIDIA

2025-07-07T08:51:00Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[de:Nvidia]]
[[en:NVIDIA]]
[[es:NVIDIA]]
[[pt:NVIDIA]]
[[ru:NVIDIA]]
[[zh-hans:NVIDIA]]
{{Related articles start}}
{{Related|NVIDIA/ヒントとテクニック}}
{{Related|NVIDIA/トラブルシューティング}}
{{Related|Nouveau}}
{{Related|NVIDIA Optimus}}
{{Related|PRIME}}
{{Related|Bumblebee}}
{{Related|nvidia-xrun}}
{{Related|Xorg}}
{{Related|Vulkan}}
{{Related articles end}}

この記事は公式の [https://www.nvidia.com NVIDIA] グラフィックカードドライバをカバーしています。コミュニティによるオープンソースのドライバに関しては、[[Nouveau]] を見てください。ハイブリッドグラフックスを搭載しているノートパソコンを使っている場合は、[[NVIDIA Optimus]] も見て下さい。

== インストール ==

{{Warning|NVIDIA のウェブサイトで提供されているパッケージを通して NVIDIA ドライバをインストールすることは避けてください。[[pacman]] 経由でインストールすれば、システムをアップデートした際にドライバもアップデートすることができます。}}

{{Note|[[ハイブリッドグラフィックス]]のあるシステム上でデュアルブートする場合は、Windows またはサードパーティのアプリで ([https://www.asus.com/support/faq/1043747/#a14 ASUS Eco mode] のような) ''Eco mode'' を有効化すると NVIDIA のディスクリート GPU が完全に無効化され、検出されなくなります。}}

まず、[https://nouveau.freedesktop.org/CodeNames.html nouveau wiki のコードネームに関するページ]で、以下のコマンドで入手した GPU カードのモデル名/公式名に対応するファミリ名を探してください:

$ lspci -k -d ::03xx

次に、使用しているカードに適したドライバをインストールしてください:

{| class="wikitable"
|-
! GPU ファミリ
! ドライバ
! 状態
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV160 Turing (NV160/TUXXX)] 及びそれ以降
| {{Pkg|linux}} には {{Pkg|nvidia-open}} {{Pkg|linux-lts}} には {{Pkg|nvidia-open-lts}} {{Pkg|nvidia-open-dkms}} は任意のカーネルで使えます
| [https://developer.nvidia.com/blog/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules/ 上流で推奨されています]。 現行。サポートあり。1
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV110 Maxwell (NV110/GMXXX)] から [https://nouveau.freedesktop.org/CodeNames.html#NV190 Ada Lovelace (NV190/ADXXX)]
| {{Pkg|linux}} には {{Pkg|nvidia}} {{Pkg|linux-lts}} には {{Pkg|nvidia-lts}} {{Pkg|nvidia-dkms}} は任意のカーネルで使えます
| 現行。サポートあり。1
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVE0 Kepler (NVE0/GKXXX)]
| {{AUR|nvidia-470xx-dkms}}
| rowspan="4" | レガシー。サポートなし。2,3
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVC0 Fermi (NVC0/GF1XX)]
| {{AUR|nvidia-390xx-dkms}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV50 Tesla (NV50/G80-90-GT2XX)]
| {{AUR|nvidia-340xx-dkms}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV40 Curie (NV40/G70)] 及びそれ以前
| パッケージはもはや存在しません。
|}

# これらのパッケージが動作しない場合 (たいていはハードウェアが新しいことが原因です)、{{AUR|nvidia-open-beta}} が、新しいハードウェアをサポートしている新しいドライバのバージョンを提供しているかもしれません。
# [https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/007/indirect-branch-tracking/ Indirect Branch Tracking] との互換性が無いため、[https://web.archive.org/web/20250209200337/https://www.intel.com/content/www/us/en/newsroom/opinion/intel-cet-answers-call-protect-common-malware-threats.html 第11世代及びそれ以降]の Intel CPU を搭載しているシステムで Linux 5.18 (及びそれ以降) においてこれらのドライバは動作しない場合があります。Indirect Branch Tracking は、[[ブートローダー]]から {{ic|1=ibt=off}} [[カーネルパラメータ]]を設定することにより、無効化することができます。ただし、このセキュリティ機能は[https://lwn.net/Articles/889475/ エクスプロイト手法の一種を緩和する]役割があるので注意してください。
# NVIDIA はもはやこれらのカードをアクティブにサポートしておらず、これらのドライバは[https://nvidia.custhelp.com/app/answers/detail/a_id/3142/ 現在の Xorg バージョンを公式にはサポートしていない場合があります]。[[nouveau]] ドライバを使うほうが簡単かもしれません。しかし、NVIDIA のレガシーなドライバは依然として利用可能であり、3D パフォーマンスまたは安定性に関して優れているかもしれません。

:{{Note|
:* {{Pkg|dkms}} をインストールする場合は、[[Dynamic Kernel Module Support#インストール]] を読んでください。
:* [[DKMS]] 版は特定のカーネルと結びついていません。カーネルのヘッダーファイルをインストールすると、そのカーネル用の NVIDIA カーネルモジュールをコンパイルし直すためです。
}}

32ビットアプリケーションのサポートに関しては、対応する ''lib32'' パッケージも [[multilib]] リポジトリからインストールしてください (例: {{Pkg|lib32-nvidia-utils}})。

{{Pkg|nvidia-utils}} パッケージには、再起動後に {{ic|nouveau}} モジュールをブラックリスト化するファイルが含まれています。任意で、{{ic|/etc/mkinitcpio.conf}} 内の {{ic|HOOKS}} 配列から {{ic|kms}} を削除し、その後 [[Initramfs を再生成する|initramfs を再生成]]してもよいです。こうすることで、initramfs に {{ic|nouveau}} モジュールが含まれないようにして、カーネルがこのモジュールを初期ブート中に読み込めないようにします。

{{Note|[[#Wayland 設定|Wayland]] を使用している場合は、[[#DRM カーネルモード設定]] に書かれてあることをするまで再起動するべきではありません。さもないと、再起動後に黒画面になってしまうかもしれません。}}

ドライバーをインストールしたら、[[#Xorg 設定]] または [[#Wayland 設定]] へと進んでください。

=== カスタムカーネル ===

使用中のカーネルで {{ic|1=CONFIG_DRM_SIMPLEDRM=y}} となっていることを確認してください。そして、{{ic|CONFIG_DEBUG_INFO_BTF}} を使用している場合、[[PKGBUILD]] で以下が必要です (カーネル 5.16 以降):

install -Dt "$builddir/tools/bpf/resolve_btfids" tools/bpf/resolve_btfids/resolve_btfids

{{ic|CONFIG_NOVA_CORE}} を有効化してコンパイルされたカーネルでは、新しい NVIDIA GPU ドライバである [https://docs.kernel.org/gpu/nova/index.html Nova] がロードされないようにする必要があるかもしれません。{{Pkg|nvidia-utils}} はデフォルトでこのドライバをブラックリストに追加します。[[カーネルモジュール#モジュールオプションを設定する|systemd-analyze を実行する]]ことで、ロードされていないことを確認できます。別のバージョンのドライバをインストールしている場合は、{{ic|nova_core}} と {{ic|nova_drm}} を手動で[[ブラックリスト|ブラックリストに登録]]する必要があるかもしれません。

=== DRM カーネルモード設定 ===

NVIDIA は [[カーネルモード設定#KMS の遅延開始|KMS の自動遅延読み込み]]をサポートしていないため、Wayland コンポジタを正しく動作させるには DRM ([[Wikipedia:Direct Rendering Manager|Direct Rendering Manager]]) [[カーネルモード設定]]を有効化する必要があります。

{{Pkg|nvidia-utils}} 560.35.03-5 から DRM はデフォルトで有効化されています。[https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/commit/1b02daa2ccca6a69fa4355fb5a369c2115ec3e22] それより古いドライバにおいては、{{ic|nvidia_drm}} モジュールに対して {{ic|1=modeset=1}} [[カーネルモジュールパラメータ]]を設定してください。

DRM が本当に有効化されているか調べるには、以下のコマンドを実行してください:

# cat /sys/module/nvidia_drm/parameters/modeset

正しく設定されていれば、このコマンドは {{ic|N}} ではなく {{ic|Y}} と出力するはずです。

{{Note|[[カーネル#公式サポートカーネル|Arch で公式にサポートされているカーネル]]は {{ic|simpledrm}} を有効化します。しかし、NVIDIA ドライバは、{{ic|1=nvidia_drm.fbdev}} が無効化されている/利用できない場合 (バージョン 545 より前)、{{ic|efifb}} または {{ic|vesafb}} を必要とします。}}

==== 早期ロード ====

基本的な機能については先のカーネルパラメータを追加するだけで十分でしょう。可能な限り早い時にロードさせたい場合や、スタートアップ時に問題 ({{ic|nvidia}} カーネルモジュールが[[ディスプレイマネージャ]]のあとにロードされてしまうなど) が発生する場合には、{{ic|nvidia}}、{{ic|nvidia_modeset}}、{{ic|nvidia_uvm}} そして {{ic|nvidia_drm}} を initramfs に追加することができます。initramfs ジェネレータを設定する方法については [[カーネルモジュール#モジュールの早期ロード]] を見てください。[[mkinitcpio]] を使用している場合、{{Pkg|nvidia}} ドライバの更新時に毎回 [[initramfs を再生成]]する必要がある場合があります。これを自動化する方法については [[#Pacman フック]] を見てください。

===== Pacman フック =====

{{Note|カスタムの pacman フックが必要になるのは、ビルド済みのカーネルモジュールが同梱されているパッケージに対してのみです。{{ic|*-dkms}} パッケージは、更新時に ''mkinitcpio'' が自動的に実行されるので、このようなカスタムの pacman フックは必要ありません。}}

NVIDIA ドライバをアップグレードした後に [[initramfs]] をアップデートすることを忘れないように、以下のような [[pacman フック]]を利用することができます:

{{hc|/etc/pacman.d/hooks/nvidia.hook|2=
[Trigger]
Operation=Install
Operation=Upgrade
Operation=Remove
Type=Package
# 構成に存在しない Target は省略できます。例えば、nvidia-open のみを使用する場合は、nvidia-lts の Target を省略できます。
Target=nvidia
Target=nvidia-open
Target=nvidia-lts
# 他のカーネルを使う場合は以下を適宜変更してください
Target=linux

[Action]
Description=Updating NVIDIA module in initcpio
Depends=mkinitcpio
When=PostTransaction
NeedsTargets
Exec=/bin/sh -c 'while read -r trg; do case $trg in linux*) exit 0; esac; done; /usr/bin/mkinitcpio -P'
}}

{{Note|上記の {{ic|Exec}} の行が複雑なのは {{ic|nvidia}} と {{ic|linux}} の両方がアップデートされた場合に ''mkinitcpio'' が何度も実行されるのを防ぐためです。このことが気にならないのであれば、{{ic|1=Target=linux}} と {{ic|NeedsTargets}} の行を削除して、{{ic|Exec}} の行は {{ic|1=Exec=/usr/bin/mkinitcpio -P}} のように単純化させることができます。}}

=== ビデオデコードのハードウェアアクセラレーション ===

VDPAU によるビデオデコードのアクセラレーションは GeForce 8 シリーズ及びそれ以降のカードでサポートされています。NVDEC によるビデオデコードのアクセラレーションは Fermi (~400 シリーズ) 及びそれ以降のカードでサポートされています。詳しくは [[ハードウェアビデオアクセラレーション]] をご覧ください。

=== NVENC によるビデオエンコードのハードウェアアクセラレーション ===

NVENC は {{ic|nvidia_uvm}} モジュールと、関連するデバイスノードが {{ic|/dev}} 下に作成されることを要求します。

最新のドライバーパッケージは、自動的にデバイスノードを作成する [[udev ルール]]を提供するので、追加の操作は必要ありません。

古いドライバ (例えば、{{AUR|nvidia-340xx-dkms}}) を使用している場合、デバイスノードを作成する必要があります。{{ic|nvidia-modprobe}} ユーティリティを実行するとデバイスノードが自動的に作成されます。{{ic|/etc/udev/rules.d/70-nvidia.rules}} を作成して {{ic|nvidia-modprobe}} を自動的に実行させることができます:

{{hc|/etc/udev/rules.d/70-nvidia.rules|2=
ACTION=="add", DEVPATH=="/bus/pci/drivers/nvidia", RUN+="/usr/bin/nvidia-modprobe -c 0 -u"}}

== Wayland 設定 ==

Xwayland に関しては [[Wayland#Xwayland]] を見てください。

その他の設定オプションについては、それぞれの[[Wayland#コンポジタ|コンポジタ]]の wiki ページやドキュメントを見てください。

{{Note|バージョン 555.xx より前のドライバを使用している場合や、{{ic|linux-drm-syncobj-v1}} プロトコルによって Explicit Sync をサポートしていない Wayland コンポジタを使用している場合、ネイティブの Wayland アプリと Xwayland アプリの両方でちらつき、フレーム順序の狂いなどの問題が発生する可能性があります。}}

=== 基本的なサポート ===

{{ic|nvidia_drm}} モジュールの重要なカーネルパラメータは {{ic|modeset}} と {{ic|fbdev}} です。{{Pkg|nvidia-utils}} パッケージを使用している場合、これらは両方とも[https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/blob/3b439109/PKGBUILD#L60 デフォルトで有効化されています]。また、NVIDIA は[https://indico.freedesktop.org/event/6/contributions/287/attachments/210/288/NVIDIA%20Wayland%20Roadmap.pdf 将来のリリースでこれらのパラメータをデフォルトで有効化することを計画しています]。

==== modeset ====

全ての Wayland 構成において {{ic|modeset}} を有効化することは適切に機能させるために必須です。

サポートの無いドライバについては、{{ic|modeset}} を手動で有効化する必要があります。詳細は [[#DRM カーネルモード設定]] と [[Wayland#要件]] を見てください。

==== fbdev ====

{{Out of date|{{Pkg|linux}} 6.14.2 と {{Pkg|nvidia}} 570.133.07 の時点で、Wayland は fbdev が無効化されていても動作するようです。また、下記の {{ic|cat}} コマンドは {{ic|N}} を返す可能性もあります。なので、この章はそれより古いバージョンのドライバのみが対象です。}}

一部の Wayland 構成においては {{ic|fbdev}} を有効化する必要があります。

Linux 6.11 以降においてこれは厳しい要件ですが、これが仕様なのかバグなのかは現在明らかになっていません。詳細は [https://forums.developer.nvidia.com/t/drm-fbdev-wayland-presentation-support-with-linux-kernel-6-11-and-above/307920] を参照してください。

これは [[#DRM カーネルモード設定|modesetting パラメータ]]と同じようにして設定することができます。ただし、以下のコマンドの出力は modesetting と異なります:

# cat /sys/module/nvidia_drm/parameters/fbdev

{{ic|fbdev}} が設定されていない場合は、このコマンドは {{ic|N}} を出力するのではなく、ファイルが存在しないことを示すエラーが発生します。

=== サスペンドのサポート ===

Wayland でのサスペンドは X よりもデフォルトの設定の問題が発生しやすいです。詳細は [[NVIDIA/ヒントとテクニック#サスペンド後にビデオメモリを保持する]] を参照してください。

GDM を使用している場合は、[[GDM#Wayland とプロプライエタリな NVIDIA ドライバ]] も参照してください。

=== nvidia-application-profiles-rc.d ===

一部の wayland コンポジタは [https://www.nvidia.com/en-us/drivers/details/237587/ GLVidHeapReuseRatio] アプリケーションプロファイルキーが[https://github.com/NVIDIA/egl-wayland/issues/126#issuecomment-2379945259 アプリケーションのプロセス名に対して適用]されていない場合、デフォルトで大量の VRAM を消費します。例えば、以下のように設定すれば [[niri]] ではアイドル時で VRAM 消費量を約2.5GiB削減できます:

{{hc|/etc/nvidia/nvidia-application-profiles-rc.d/50-limit-free-buffer-pool-in-wayland-compositors.json|2=
{
"rules": [
{
"pattern": {
"feature": "procname",
"matches": "niri"
},
"profile": "Limit free buffer pool on Wayland compositors"
}
],
"profiles": [
{
"name": "Limit free buffer pool on Wayland compositors",
"settings": [
{
"key": "GLVidHeapReuseRatio",
"value": 1
}
]
}
]
}
}}

== Xorg 設定 ==

プロプライエタリな NVIDIA グラフィックドライバは Xorg サーバの設定ファイルを必要としません。[[Xorg#起動|X を起動]]してみて、Xorg サーバが設定ファイル無しで正しく機能するかを確認することができます。しか、様々な設定を調整するために設定ファイル ({{ic|/etc/X11/xorg.conf}} よりも {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} を優先して使用してください) を作成する必要があるかもしれません。この設定は、NVIDIA Xorg 設定ツールによって生成することができますし、手動で作成することもできます。手動で作成した場合、([[Xorg]] サーバに基本的なオプションのみを与えると言う意味で) 最小の設定にすることができますし、あるいは、Xorg の自動検出されたオプションや事前設定されたオプションをバイパスできる設定を含めることもできます。

{{Tip|その他の設定オプションは、[[NVIDIA/トラブルシューティング]] を見てください。}}

=== 自動設定 ===

NVIDIA のパッケージには、Xorg サーバの設定ファイル ({{ic|xorg.conf}}) を作成するための自動設定ツールが含まれています。次のコマンドで実行できます:

# nvidia-xconfig

このコマンドは {{ic|/etc/X11/xorg.conf}} を自動検出し、現在のハードウェアに応じてそのファイルを作成 (すでに存在する場合は編集) します。

デフォルトの深度、水平同期、垂直リフレッシュ、そして解像度が問題ないか {{ic|/etc/X11/xorg.conf}} を二重にチェックしてください。

=== nvidia-settings ===

{{Pkg|nvidia-settings}} は CLI または GUI を使って様々なオプションを設定することができるツールです。何もオプションをつけずに {{ic|nvidia-settings}} を実行すると GUI が起動します。CLI のオプションについては {{man|1|nvidia-settings}} を見てください。

{{Pkg|nvidia-settings}} の CLI/GUI は非 root なユーザとして実行でき、''nvidia-settings Configuration'' タブにある ''Save Current Configuration'' オプションで設定を {{ic|~/.nvidia-settings-rc}} に保存できます。

現在のユーザで {{ic|~/.nvidia-settings-rc}} をロードするには:

$ nvidia-settings --load-config-only

起動時に毎回このコマンドを実行させるには[[自動起動]]を見てください。

{{Note|{{ic|nvidia-settings}} から変更を加えると [[Xorg]] が起動しなくなったりクラッシュするようになったりすることがあります。生成された {{ic|~/.nvidia-settings-rc}} と [[Xorg]] のファイルの両方/片方を調整するか削除することで普通に起動できるようになるはずです。}}

=== 手動設定 ===

設定ファイルを編集することで、([[#自動設定|自動的に]]、または [[#NVIDIA settings|nvidia-settings]]によって有効化できない) いくつかの微調整をすることができます。変更を適用する前に Xorg サーバーを再起動する必要があります。

その他の詳細やオプションについては [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/ NVIDIA Accelerated Linux Graphics Driver README and Installation Guide] をご覧ください。

==== 最小設定 ====

{{ic|20-nvidia.conf}} (もしくは非推奨の {{ic|xorg.conf}}) の基本的な設定ブロックは以下のようになります:

{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|
Section "Device"
Identifier "NVIDIA Card"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce GTX 1050 Ti"
EndSection
}}

==== 起動時のロゴを無効化 ====

古いドライバ ({{AUR|nvidia-340xx-dkms}}) を使用している場合、X の起動時に表示される NVIDIA ロゴスプラッシュスクリーンを無効化しておいたほうがいいかもしれません。{{ic|Device}} セクション内に {{ic|"NoLogo"}} オプションを追加してください:

Option "NoLogo" "1"

==== モニター検出をオーバーライド ====

{{ic|Device}} セクション内の {{ic|"ConnectedMonitor"}} オプションにより、 X サーバーが起動した時にモニター検出をオーバーライドできます。これにより、起動時間を大幅に減らせるかもしれません。利用可能なオプション: アナログ接続用の {{ic|"CRT"}}、デジタルモニター用の {{ic|"DFP"}}、テレビ用の {{ic|"TV"}}。

以下の行は起動時のチェックをバイパスし、モニターを DFP として認識することを NVIDIA ドライバーに強制します:

Option "ConnectedMonitor" "DFP"

{{Note|たとえディスプレイが薄型パネルであろうと、アナログ15ピン VGA 接続に対しては "CRT" を使用してください。"DFP" は DVI や HDMI、DisplayPort のデジタル接続のみを意図しています。}}

==== 輝度調整を有効化 ====

{{Out of date|時代遅れの可能性あり[https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/GXJG7D3ALUQKOE2DT4XCL4UXQUFDDSEC/]。上流のパッケージも古いようです。}}

以下をカーネルパラメータに追加してください:

nvidia.NVreg_RegistryDwords=EnableBrightnessControl=1

あるいは、以下を {{ic|Device}} セクション内に追加してください:

Option "RegistryDwords" "EnableBrightnessControl=1"

もし、この設定で輝度調整がまだ機能しない場合は、{{AUR|nvidia-bl-dkms}} をインストールしてみてください。

{{Note|{{AUR|nvidia-bl-dkms}} をインストールすることにより、バックライト輝度調整用の {{ic|/sys/class/backlight/nvidia_backlight/}} インターフェイスが提供されます。しかし、システムが {{ic|/sys/class/backlight/acpi_video0/}} に対してバックライト制御の変更を発行し続けるかもしれません。この場合の1つの解決策は、例えば、''inotifywait'' を使用して {{ic|acpi_video0/brightness}} の変更を監視し、それを変換して {{ic|nvidia_backlight/brightness}} に対して書き込むことです。[[バックライト#sysfs を変更しても明るさが変更されない]] をご覧ください。}}

==== SLI を有効化 ====

{{Out of date|バージョン 455.23.04 から、一部の SLI モードはもはやサポートされていません。}}

{{Warning|GTX 10xx シリーズ (1080、1070、1060 など) 以降は 2-way SLI のみがサポートされます。3-way や 4-way SLI は CUDA/OpenCL アプリケーションに対しては機能するかもしれませんが、すべての OpenGL アプリケーションに対してはたいてい機能しないでしょう。}}

NVIDIA ドライバーの [https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/xconfigoptions.html#SLI README] 付録 B によると: ''このオプションは、サポートされている構成で SLI レンダリングの設定を制御します。'' "サポートされている構成"とは SLI 認定マザーボードと、2基または3基の SLI 認定 GeForce GPU を搭載しているコンピュータのことです。

{{ic|lspci}} を使って1つ目の GPU の PCI Bus ID を調べてください:

{{hc|# lspci -d ::03xx|
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
03:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
04:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M / Quadro M500M] (rev a2)
}}

調べた BusID (前述の例では 3) を {{ic|Device}} セクション内に追加してください:

BusID "PCI:3:0:0"

{{Note|フォーマットが重要です。BusID の値は {{ic|"PCI:<BusID>:0:0"}} のように指定されなければなりません。}}

希望する SLI レンダリングモードの値を {{ic|Screen}} セクション内に追加してください:

Option "SLI" "AA"

以下の表は利用可能なレンダリングモードです。

{| class="wikitable"
! 値 !! 挙動
|-
| 0, no, off, false, Single || レンダリング時にただ1つの GPU を使う。
|-
| 1, yes, on, true, Auto || SLI を有効化し、ドライバーが自動的に適切なレンダリングモードを選択することを許可する。
|-
| AFR || SLI を有効化し、Alternate Frame Rendering モードを使う。
|-
| SFR || SLI を有効化し、Split Frame Rendering モードを使う。
|-
| AA || SLI を有効化し、SLI アンチエイリアシングを使う。この値を Full-Scene アンチエイリアシングと一緒に使うと視覚品質が向上します。
|}

あるいは、''nvidia-xconfig'' ユーティリティを使って、これらの変更を {{ic|xorg.conf}} に追加できます:

# nvidia-xconfig --busid=PCI:3:0:0 --sli=AA

SLI モードが有効化されていることをシェルから確認するには:

{{hc|$ nvidia-settings -q all {{!}} grep SLIMode|
Attribute 'SLIMode' (arch:0.0): AA
'SLIMode' is a string attribute.
'SLIMode' is a read-only attribute.
'SLIMode' can use the following target types: X Screen.
}}

{{Warning|SLI を有効化した後に xorg を起動するとシステムがフリーズしたり、応答しなくなったりするかもしれません。再起動する前にディスプレイマネージャーを無効化することをおすすめします。}}

以上の設定で機能しない場合は、{{ic|nvidia-settings}} で得られる PCI Bus ID を使用する必要があるかもしれません。

{{hc|$ nvidia-settings -q all {{!}} grep -i pcibus|
Attribute 'PCIBus' (host:0[gpu:0]): 101.
'PCIBus' is an integer attribute.
'PCIBus' is a read-only attribute.
'PCIBus' can use the following target types: GPU, SDI Input Device.
Attribute 'PCIBus' (host:0[gpu:1]): 23.
'PCIBus' is an integer attribute.
'PCIBus' is a read-only attribute.
'PCIBus' can use the following target types: GPU, SDI Input Device.
}}

そして、xorg.d 内の PrimaryGPU オプションをコメントアウトしてください:

{{hc|/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf|
...

Section "OutputClass"
...
# Option "PrimaryGPU" "yes"
...
}}

この設定でグラフィカルブートの問題も解決できるかもしれません。

=== マルチモニター ===

一般的な情報は [[マルチディスプレイ]] を見て下さい。

==== NVIDIA Settings を使う ====

[[#nvidia-settings|nvidia-settings]] ツールを使ってマルチモニターを設定できます。

CLI で設定する場合、まずは以下を実行して {{ic|CurrentMetaMode}} を確認してください:

{{hc|$ nvidia-settings -q CurrentMetaMode|2=
Attribute 'CurrentMetaMode' (hostnmae:0.0): id=50, switchable=no, source=nv-control :: DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0}
}}

{{ic|::}} 以降の全て (上記の場合: {{ic|1=DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0}}}) を使って {{ic|1=nvidia-settings --assign "CurrentMetaMode=''your_meta_mode''"}} でディスプレイを再設定できます。

{{Tip|使用するモニターや解像度の設定ごとにシェルのエイリアスを作成すると便利です。}}

==== ConnectedMonitor ====

{{Out of date|{{ic|Option "TwinView"}} はバージョン 302.07 で削除され、TwinView は常に有効になっています。}}

ドライバーがセカンドモニタを正しく認識しない場合は、ConnectedMonitor を使って認識するように強制できます。

{{hc|/etc/X11/xorg.conf|

Section "Monitor"
Identifier "Monitor1"
VendorName "Panasonic"
ModelName "Panasonic MICRON 2100Ex"
HorizSync 30.0 - 121.0 # this monitor has incorrect EDID, hence Option "UseEDIDFreqs" "false"
VertRefresh 50.0 - 160.0
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor2"
VendorName "Gateway"
ModelName "GatewayVX1120"
HorizSync 30.0 - 121.0
VertRefresh 50.0 - 160.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device1"
Driver "nvidia"
Option "NoLogo"
Option "UseEDIDFreqs" "false"
Option "ConnectedMonitor" "CRT,CRT"
VendorName "NVIDIA Corporation"
BoardName "GeForce 6200 LE"
BusID "PCI:3:0:0"
Screen 0
EndSection

Section "Device"
Identifier "Device2"
Driver "nvidia"
Option "NoLogo"
Option "UseEDIDFreqs" "false"
Option "ConnectedMonitor" "CRT,CRT"
VendorName "NVIDIA Corporation"
BoardName "GeForce 6200 LE"
BusID "PCI:3:0:0"
Screen 1
EndSection

}}

{{ic|TwinView}} を使わずに1つのカードで2つのモニターを X で使うために {{ic|Screen}} でデバイスを複製しています。{{ic|nvidia-settings}} は追加した {{ic|ConnectedMonitor}} オプションを全て消してしまうので注意してください。

==== TwinView ====

{{Out of date|{{ic|Option "TwinView"}} はバージョン 302.07 で削除され、TwinView は常に有効になっています。}}

画面を2つ表示するのではなく1つの大きな画面を表示したい場合、{{ic|TwinView}} 引数を {{ic|1}} に設定してください。コンポジットを使いたい場合、このオプションを使用する必要があります。TwinView は全てのモニターが同一のカードに接続されている場合にのみ機能します。

Option "TwinView" "1"

設定例:

{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|
Section "ServerLayout"
Identifier "TwinLayout"
Screen 0 "metaScreen" 0 0
EndSection

Section "Monitor"
Identifier "Monitor0"
Option "Enable" "true"
EndSection

Section "Monitor"
Identifier "Monitor1"
Option "Enable" "true"
EndSection

Section "Device"
Identifier "Card0"
Driver "nvidia"
VendorName "NVIDIA Corporation"

#refer to the link below for more information on each of the following options.
Option "HorizSync" "DFP-0: 28-33; DFP-1 28-33"
Option "VertRefresh" "DFP-0: 43-73; DFP-1 43-73"
Option "MetaModes" "1920x1080, 1920x1080"
Option "ConnectedMonitor" "DFP-0, DFP-1"
Option "MetaModeOrientation" "DFP-1 LeftOf DFP-0"
EndSection

Section "Screen"
Identifier "metaScreen"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
Option "TwinView" "True"
SubSection "Display"
Modes "1920x1080"
EndSubSection
EndSection
}}

[https://download.nvidia.com/XFree86/Linux-x86_64/575.64/README/configtwinview.html Device オプション情報]。

SLI に対応しているカードが複数枚存在する場合、別々のカードに接続された複数のモニターを使うことができます (例: 2枚のカードが SLI で、各々のカードにモニターが1台ずつ接続)。SLI モザイクモードと "MetaModes" オプションで有効になります。以下は上記と同じように設定する例で、[[GNOME]] が完璧に動作します:

{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|
Section "Device"
Identifier "Card A"
Driver "nvidia"
BusID "PCI:1:00:0"
EndSection

Section "Device"
Identifier "Card B"
Driver "nvidia"
BusID "PCI:2:00:0"
EndSection

Section "Monitor"
Identifier "Right Monitor"
EndSection

Section "Monitor"
Identifier "Left Monitor"
EndSection

Section "Screen"
Identifier "Right Screen"
Device "Card A"
Monitor "Right Monitor"
DefaultDepth 24
Option "SLI" "Mosaic"
Option "Stereo" "0"
Option "BaseMosaic" "True"
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "Screen"
Identifier "Left Screen"
Device "Card B"
Monitor "Left Monitor"
DefaultDepth 24
Option "SLI" "Mosaic"
Option "Stereo" "0"
Option "BaseMosaic" "True"
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Default"
Screen 0 "Right Screen" 0 0
Option "Xinerama" "0"
EndSection
}}

===== TwinView を使って垂直同期 =====

TwinView と垂直同期 ({{ic|nvidia-settings}} の ''Sync to VBlank'' オプション) を使っている場合、モニターの大きさが異なっていると片方の画面だけが同期されます。{{ic|nvidia-settings}} にはどちらの画面を同期させるか設定するオプション (''Sync to this display device'' オプション) が存在しますが、必ずしも機能するとはいいがたいです。起動時に以下の環境変数を追加することで解決します (例: {{ic|/etc/profile}} に追加):

export __GL_SYNC_TO_VBLANK=1
export __GL_SYNC_DISPLAY_DEVICE=DFP-0
export VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-0

{{ic|DFP-0}} は適切な画面に置き換えてください ({{ic|DFP-0}} は DVI 端子で {{ic|CRT-0}} は VGA 端子です)。ディスプレイの識別名は {{ic|nvidia-settings}} の ''X Server XVideoSettings'' セクションで確認できます。

===== Twinview を使ってゲームを遊ぶ =====

TwinView を使ってフルスクリーンのゲームを遊ぶ場合、2つの画面が1つの大きな画面としてゲームから認識されることがあります。技術的にこれは正しいのですが (仮想的な X スクリーンの横幅は両方の画面を合わせたサイズになります)、ゲームを遊ぶときは両方の画面を使わないようにしたいときもあるでしょう。

SDL 1.2 のこの挙動を修正するには、次を試して下さい:

export SDL_VIDEO_FULLSCREEN_HEAD=1

OpenGL の場合、{{ic|xorg.conf}} の {{ic|Device}} セクションに適切な Metamodes を追加して X を再起動してください:

Option "Metamodes" "1680x1050,1680x1050; 1280x1024,1280x1024; 1680x1050,NULL; 1280x1024,NULL;"

[[ゲーム#別の X サーバーでゲームを起動する|別の X サーバーでゲームを起動する]]方法もあります。上記の方法と一緒に使うことも可能です。

==== モザイクモード ====

モザイクモードは、複数のグラフィクカードでコンポジット有りで3つ以上のモニタを使用する唯一の方法です。ウィンドウマネージャは各モニタの違いを認識するかもしれませんし、しないかもしれません。モザイクモードには、有効な SLI 設定が必要です。SLI を使わずにベースモードを使用する場合でも、GPU は依然として SLI 対応/互換でなければなりません。

===== ベースモザイク =====

ベースモザイクモードは Geforce 8000 シリーズ以上の GPU で動作します。nvidia-setting の GUI から有効にすることはできません。''nvidia-xconfig'' コマンドラインプログラムを使用するか {{ic|xorg.conf}} を手動で編集する必要があります。Metamodes を指定してください。以下は4台の DFP を 2x2 の構成で使用する例です。各々の解像度は 1920x1024 で、2枚のカードにそれぞれ2台の DFP が接続されている場合:

# nvidia-xconfig --base-mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"

{{Note|ドキュメントには 2x2 のモニター構成が記述されていますが、Base Mosaic モードで[https://forums.developer.nvidia.com/t/basemosaic-v295-vs-v310-vs-v325-only-up-to-three-screens/30583#3954733 GeForce カードは人為的にモニタ3台に制限されています]。Quadro カードは4台以上のモニタをサポートしています。2014年9月現在、Windows ドライバはこの人為的な制限を落としましたが、Linux ドライバでは未だに残っています。}}

===== SLI モザイク =====

SLI 構成を使っていて、使用する GPU が Quadro FX 5800 や Quadro Fermi 以降の場合、SLI モザイクモードが利用できます。nvidia-settings の GUI の中から有効化するか、コマンドラインで設定してください:

# nvidia-xconfig --sli=Mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"

== NVswitch ==

NVswitch のあるシステム (AWS の H100x8 など) では、以下が必要です。

* nvidia-fabricmanager をインストールする。
* Fabric manager が必要とする、対応するカーネルモジュールをインストールする。

Fabric manager を使うと、pytorch が GPU が見つからないと報告してきます。

Fabric マネージャをインストールするには:

# Nvidia から tarball をダウンロードする。[https://developer.download.nvidia.com/compute/cuda/redist/fabricmanager/linux-x86_64/ こちら]
# バージョン 555.42.02 は正しく動作します。
# インストールスクリプト sbin/fm_run_package_installer.sh を変更してしてインストール先のパスを修正してください。

対応するカーネルドライバを入手するには:

# nvidia-beta-dkms と nvidia-utils-beta の AUR リポジトリを git clone してください。
# PKGBUILD を変更してバージョン 555.42.02 を使用するようにしてください。
# ビルドし、インストールしてください。
# 再起動してください。

最後に、{{ic|systemctl enable nvidia-fabricmanager}} と {{ic|systemctl start nvidia-fabricmanager}} を実行すれば、pytorch が動くはずです。

== ヒントとテクニック ==

[[NVIDIA/ヒントとテクニック]] を参照。

== トラブルシューティング ==

[[NVIDIA/トラブルシューティング]] を参照。

== 参照 ==

* [https://forums.developer.nvidia.com/t/current-graphics-driver-releases/28500 Current graphics driver releases in official NVIDIA Forum]
* [https://forums.developer.nvidia.com/c/gpu-graphics/linux/148 NVIDIA Developers Forum - Linux Subforum]

{{TranslationStatus|NVIDIA|2025-07-07|840164}}

NILFS2

2025-07-04T15:45:45Z

AshMyzk: /* ファイルシステムをリサイズする */ style

[[Category:ファイルシステム]]
[[en:NILFS2]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related articles end}}

[https://nilfs.sourceforge.io/en/ NILFS2] (New Implementation of a Log-structured File System) はログ構造化ファイルシステムです。ファイルシステム全体のバージョニングや連続的なスナップショットをサポートしており、数秒前に間違って上書きしたり壊してしまったりしたファイルでも復元することができます。

このファイルシステムは日本電信電話 (NTT) サイバースペース研究所と世界中のコミュニティによって開発されました。NILFS は GNU General Public License (GPL) の下でライセンスされました。

NILFS2 では連続的にスナップショットが作成されるため、ファイルシステムが自動的に全ファイルの過去のバージョンを保持するバージョニングファイルシステムとみなすことができます。

{{Note|
* NILFS2 は断片化を発生させるそのログ構造化設計によりメカニカルハードディスクドライブには最適ではないかもしれません。
* 2025年4月22日現在、NILFS2 は atime (access time)、拡張属性、POSIX ACL (POSIX Access Control List) を実装していません。これらが必要である場合は、NILFS2を使用しないでください。また、適切なファイルシステムチェックが今のところ存在しないため、深刻なエラーが発生した場合に回復不能になるかもしれません。実装済みの機能と未実装の機能は [https://nilfs.sourceforge.io/en/current_status.html Current status] を参照してください。}}

{{Tip|NILFS2 ツールのほとんどはデバイスファイルの引数を省略できますが、複数の NILFS2 ファイルシステムが存在する環境では間違ったファイルシステムを変更してしまわないようにデバイスファイルの引数を常に使用することが推奨されます。}}

== NILFS2 ファイルシステムを作成する ==

この記事ではデバイスに[[パーティション]]がすでにセットアップされていると仮定しています。{{Pkg|nilfs-utils}} を[[インストール]]してください。{{ic|mkfs.nilfs2}} を使い、{{ic|''/dev/sdxY''}} のように対象のパーティションを指定してフォーマットしてください:

# mkfs.nilfs2 -L mylabel ''/dev/sdxY''

利用可能なオプションは {{man|8|mkfs.nilfs2}} を参照してください。

=== ラベルを変更する ===

nilfs-tune コマンドはマウントされていないファイルシステムにのみ使用してください。

# nilfs-tune -L newlabel ''/dev/sdxY''

== マウントする ==

その後、ファイルシステムは手動あるいは他の方法でマウントできるようになります:

# mount /dev/sdxY /mnt/foo

=== マウントオプション ===

==== エラーハンドリング ====

{{ic|1=errors=continue}} / {{ic|remount-ro}} / {{ic|panic}} は、ファイルシステムエラー時に NILFS2 が何をすべきかを指定します。{{ic|continue}} はエラーを無視し、{{ic|remount-ro}} はファイルシステムを読み取り専用でマウントし、{{ic|panic}} はシステムを停止させます。

==== Discard ====

{{ic|discard}} / {{ic|nodiscard}} はそれぞれ [[TRIM]] を有効化/無効化します。

利用可能なオプションは {{man|8|mount.nilfs2}} を参照してください。

== スナップショット ==

NILFS2 には2種類のスナップショット (チェックポイントとスナップショット) があります。これらはそれぞれ {{ic|cp}}、{{ic|ss}} と表記されます。

NILFS2 は書き込み毎にチェックポイントを自動的に作成します。チェックポイントは、ファイルシステムが満タンになった時やユーザーが手動でガベージコレクションを発動させた時に領域を空けるために NILFS2 のガベージコレクタによって自動的に削除されうるスナップショットです。

スナップショットはチェックポイントから手動で変換する必要があり、自動的に削除されません。スナップショットはマウントすることができ、データを復元することができます。

=== スナップショットを一覧表示する ===

チェックポイントとスナップショットは以下のようにして一覧表示できます:

{{hc|head=lscp /dev/sdxY|output=
CNO DATE TIME MODE FLG BLKCNT ICNT
1 2025-04-14 21:35:06 cp - 10181423 554012
2 2025-04-14 22:17:38 cp - 10181423 554012
3 2025-04-14 22:18:22 cp - 10181423 554012
4 2025-04-14 22:28:56 cp - 10181423 554012
5 2025-04-14 22:39:59 cp - 10181423 554012
...
}}

スナップショットのみを表示するには lscp に {{ic|-s}} フラグを渡してください。利用可能なオプションは {{man|1|lscp}} を参照してください。

=== チェックポイントをスナップショットに変換する ===

チェックポイントからデータを復元するには、先にチェックポイントをスナップショットに変換する必要があります。変換には {{ic|chcp}} ユーティリティを使用してください:

# chcp ss /dev/sdxY ''checkpoint-number''

{{ic|checkpoint-number}} は {{ic|lscp}} の CNO 列のチェックポイント番号です。

実行すると、{{ic|lscp}} では以下のように表示されます:

4 2025-04-14 22:28:56 ss - 10181423 554012

スナップショットをチェックポイントに戻すには:

# chcp cp /dev/sdxY ''checkpoint-number''

=== スナップショットを作成する ===

以下のようにしてチェックポイントを作成してください:

# mkcp /dev/sdxY

あるいはスナップショットを直接作成するには:

# mkcp --snapshot /dev/sdxY

=== スナップショットをマウントする ===

以下のコマンドはスナップショット {{ic|checkpoint-number}} を読み取り専用で {{ic|/mnt/snapshot}} にマウントします:

# mount -t nilfs2 -r -o cp=checkpoint-number /dev/sdxY /mnt/snapshot

=== スナップショットを削除する ===

チェックポイントを一つだけ削除するには:

# rmcp /dev/sdxY ''checkpoint-number''

ある範囲のチェックポイントを一括で削除するには:

# rmcp /dev/sdxY ''start''..''end''

{{ic|start}} は開始チェックポイント番号、{{ic|end}} は終点のチェックポイント番号です。(訳注: 削除範囲は [start, end] です。[start, end) ではありません。)

特定のチェックポイント及びそれより前のチェックポイントを全て削除するには:

# rmcp /dev/sdxY ..''checkpoint-number''

特定のチェックポイント及びそれより後のチェックポイントを全て削除するには:

# rmcp /dev/sdxY ''checkpoint-number''..

{{tip|{{ic|-i}} フラグを追加すると {{ic|rmcp}} は入力された値をインタラクティブにダブルチェックします。}}

詳細は {{man|8|rmcp}} を参照してください。

== ファイルシステムをクリーンアップする ==

マウント済みの NILFS2 ファイルシステムから古いチェックポイントをクリーンアップするには:

# nilfs-clean /dev/sdxY

ガベージコレクタに関する詳細は {{man|8|nilfs-clean}} と {{man|8|nilfs_cleanerd}} を参照してください。

== ファイルシステムをリサイズする ==

{{ic|nilfs-resize}} は NILFS2 ファイルシステムをリサイズします。

マウント済み NILFS2 ファイルシステムは以下のコマンドでリサイズできます:

# nilfs-resize /dev/sdxY ''desired-size''

{{ic|desired-size}} では単位接尾辞 {{ic|s}} (512バイトセクタ)、{{ic|K}} (キロバイト)、{{ic|M}} (メガバイト)、{{ic|G}} (ギガバイト)、{{ic|T}} (テラバイト) を使用できます。{{ic|desired-size}} が指定されなかった場合、デフォルトでパーティションのサイズが使用されます。

{{ic|nilfs-resize}} は勝手にパーティションのサイズを変更しません。ファイルシステムを縮小した場合は後でパーティションを縮小する必要があり、逆にファイルシステムを拡張したい場合はあらかじめパーティションを拡張しておく必要があります。これは [[fdisk]] などで行えます。

詳細は {{man|8|nilfs-resize}} を参照してください。

== 参照 ==

* [https://nilfs.sourceforge.io/en/faq.html NILFS2 FAQ]

{{TranslationStatus|NILFS2|2025-07-05|833898}}

NILFS2

2025-07-04T15:43:01Z

AshMyzk: カテゴリを修正

[[Category:ファイルシステム]]
[[en:NILFS2]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related articles end}}

[https://nilfs.sourceforge.io/en/ NILFS2] (New Implementation of a Log-structured File System) はログ構造化ファイルシステムです。ファイルシステム全体のバージョニングや連続的なスナップショットをサポートしており、数秒前に間違って上書きしたり壊してしまったりしたファイルでも復元することができます。

このファイルシステムは日本電信電話 (NTT) サイバースペース研究所と世界中のコミュニティによって開発されました。NILFS は GNU General Public License (GPL) の下でライセンスされました。

NILFS2 では連続的にスナップショットが作成されるため、ファイルシステムが自動的に全ファイルの過去のバージョンを保持するバージョニングファイルシステムとみなすことができます。

{{Note|
* NILFS2 は断片化を発生させるそのログ構造化設計によりメカニカルハードディスクドライブには最適ではないかもしれません。
* 2025年4月22日現在、NILFS2 は atime (access time)、拡張属性、POSIX ACL (POSIX Access Control List) を実装していません。これらが必要である場合は、NILFS2を使用しないでください。また、適切なファイルシステムチェックが今のところ存在しないため、深刻なエラーが発生した場合に回復不能になるかもしれません。実装済みの機能と未実装の機能は [https://nilfs.sourceforge.io/en/current_status.html Current status] を参照してください。}}

{{Tip|NILFS2 ツールのほとんどはデバイスファイルの引数を省略できますが、複数の NILFS2 ファイルシステムが存在する環境では間違ったファイルシステムを変更してしまわないようにデバイスファイルの引数を常に使用することが推奨されます。}}

== NILFS2 ファイルシステムを作成する ==

この記事ではデバイスに[[パーティション]]がすでにセットアップされていると仮定しています。{{Pkg|nilfs-utils}} を[[インストール]]してください。{{ic|mkfs.nilfs2}} を使い、{{ic|''/dev/sdxY''}} のように対象のパーティションを指定してフォーマットしてください:

# mkfs.nilfs2 -L mylabel ''/dev/sdxY''

利用可能なオプションは {{man|8|mkfs.nilfs2}} を参照してください。

=== ラベルを変更する ===

nilfs-tune コマンドはマウントされていないファイルシステムにのみ使用してください。

# nilfs-tune -L newlabel ''/dev/sdxY''

== マウントする ==

その後、ファイルシステムは手動あるいは他の方法でマウントできるようになります:

# mount /dev/sdxY /mnt/foo

=== マウントオプション ===

==== エラーハンドリング ====

{{ic|1=errors=continue}} / {{ic|remount-ro}} / {{ic|panic}} は、ファイルシステムエラー時に NILFS2 が何をすべきかを指定します。{{ic|continue}} はエラーを無視し、{{ic|remount-ro}} はファイルシステムを読み取り専用でマウントし、{{ic|panic}} はシステムを停止させます。

==== Discard ====

{{ic|discard}} / {{ic|nodiscard}} はそれぞれ [[TRIM]] を有効化/無効化します。

利用可能なオプションは {{man|8|mount.nilfs2}} を参照してください。

== スナップショット ==

NILFS2 には2種類のスナップショット (チェックポイントとスナップショット) があります。これらはそれぞれ {{ic|cp}}、{{ic|ss}} と表記されます。

NILFS2 は書き込み毎にチェックポイントを自動的に作成します。チェックポイントは、ファイルシステムが満タンになった時やユーザーが手動でガベージコレクションを発動させた時に領域を空けるために NILFS2 のガベージコレクタによって自動的に削除されうるスナップショットです。

スナップショットはチェックポイントから手動で変換する必要があり、自動的に削除されません。スナップショットはマウントすることができ、データを復元することができます。

=== スナップショットを一覧表示する ===

チェックポイントとスナップショットは以下のようにして一覧表示できます:

{{hc|head=lscp /dev/sdxY|output=
CNO DATE TIME MODE FLG BLKCNT ICNT
1 2025-04-14 21:35:06 cp - 10181423 554012
2 2025-04-14 22:17:38 cp - 10181423 554012
3 2025-04-14 22:18:22 cp - 10181423 554012
4 2025-04-14 22:28:56 cp - 10181423 554012
5 2025-04-14 22:39:59 cp - 10181423 554012
...
}}

スナップショットのみを表示するには lscp に {{ic|-s}} フラグを渡してください。利用可能なオプションは {{man|1|lscp}} を参照してください。

=== チェックポイントをスナップショットに変換する ===

チェックポイントからデータを復元するには、先にチェックポイントをスナップショットに変換する必要があります。変換には {{ic|chcp}} ユーティリティを使用してください:

# chcp ss /dev/sdxY ''checkpoint-number''

{{ic|checkpoint-number}} は {{ic|lscp}} の CNO 列のチェックポイント番号です。

実行すると、{{ic|lscp}} では以下のように表示されます:

4 2025-04-14 22:28:56 ss - 10181423 554012

スナップショットをチェックポイントに戻すには:

# chcp cp /dev/sdxY ''checkpoint-number''

=== スナップショットを作成する ===

以下のようにしてチェックポイントを作成してください:

# mkcp /dev/sdxY

あるいはスナップショットを直接作成するには:

# mkcp --snapshot /dev/sdxY

=== スナップショットをマウントする ===

以下のコマンドはスナップショット {{ic|checkpoint-number}} を読み取り専用で {{ic|/mnt/snapshot}} にマウントします:

# mount -t nilfs2 -r -o cp=checkpoint-number /dev/sdxY /mnt/snapshot

=== スナップショットを削除する ===

チェックポイントを一つだけ削除するには:

# rmcp /dev/sdxY ''checkpoint-number''

ある範囲のチェックポイントを一括で削除するには:

# rmcp /dev/sdxY ''start''..''end''

{{ic|start}} は開始チェックポイント番号、{{ic|end}} は終点のチェックポイント番号です。(訳注: 削除範囲は [start, end] です。[start, end) ではありません。)

特定のチェックポイント及びそれより前のチェックポイントを全て削除するには:

# rmcp /dev/sdxY ..''checkpoint-number''

特定のチェックポイント及びそれより後のチェックポイントを全て削除するには:

# rmcp /dev/sdxY ''checkpoint-number''..

{{tip|{{ic|-i}} フラグを追加すると {{ic|rmcp}} は入力された値をインタラクティブにダブルチェックします。}}

詳細は {{man|8|rmcp}} を参照してください。

== ファイルシステムをクリーンアップする ==

マウント済みの NILFS2 ファイルシステムから古いチェックポイントをクリーンアップするには:

# nilfs-clean /dev/sdxY

ガベージコレクタに関する詳細は {{man|8|nilfs-clean}} と {{man|8|nilfs_cleanerd}} を参照してください。

== ファイルシステムをリサイズする ==

{{ic|nilfs-resize}} は NILFS2 ファイルシステムをリサイズします。

マウント済み NILFS2 ファイルシステムは以下のコマンドでリサイズできます:

# nilfs-resize /dev/sdxY desired-size

{{ic|desired-size}} では単位接尾辞 {{ic|s}} (512バイトセクタ)、{{ic|K}} (キロバイト)、{{ic|M}} (メガバイト)、{{ic|G}} (ギガバイト)、{{ic|T}} (テラバイト) を使用できます。{{ic|desired-size}} が指定されなかった場合、デフォルトでパーティションのサイズが使用されます。

{{ic|nilfs-resize}} は勝手にパーティションのサイズを変更しません。ファイルシステムを縮小した場合は後でパーティションを縮小する必要があり、逆にファイルシステムを拡張したい場合はあらかじめパーティションを拡張しておく必要があります。これは [[fdisk]] などで行えます。

詳細は {{man|8|nilfs-resize}} を参照してください。

== 参照 ==

* [https://nilfs.sourceforge.io/en/faq.html NILFS2 FAQ]

{{TranslationStatus|NILFS2|2025-07-05|833898}}

NILFS2

2025-07-04T15:42:42Z

AshMyzk: ページの作成:「Category:File systems en:NILFS2 {{Related articles start}} {{Related|ファイルシステム}} {{Related articles end}} [https://nilfs.sourceforge.io/en/ NILFS2…」

[[Category:File systems]]
[[en:NILFS2]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related articles end}}

[https://nilfs.sourceforge.io/en/ NILFS2] (New Implementation of a Log-structured File System) はログ構造化ファイルシステムです。ファイルシステム全体のバージョニングや連続的なスナップショットをサポートしており、数秒前に間違って上書きしたり壊してしまったりしたファイルでも復元することができます。

このファイルシステムは日本電信電話 (NTT) サイバースペース研究所と世界中のコミュニティによって開発されました。NILFS は GNU General Public License (GPL) の下でライセンスされました。

NILFS2 では連続的にスナップショットが作成されるため、ファイルシステムが自動的に全ファイルの過去のバージョンを保持するバージョニングファイルシステムとみなすことができます。

{{Note|
* NILFS2 は断片化を発生させるそのログ構造化設計によりメカニカルハードディスクドライブには最適ではないかもしれません。
* 2025年4月22日現在、NILFS2 は atime (access time)、拡張属性、POSIX ACL (POSIX Access Control List) を実装していません。これらが必要である場合は、NILFS2を使用しないでください。また、適切なファイルシステムチェックが今のところ存在しないため、深刻なエラーが発生した場合に回復不能になるかもしれません。実装済みの機能と未実装の機能は [https://nilfs.sourceforge.io/en/current_status.html Current status] を参照してください。}}

{{Tip|NILFS2 ツールのほとんどはデバイスファイルの引数を省略できますが、複数の NILFS2 ファイルシステムが存在する環境では間違ったファイルシステムを変更してしまわないようにデバイスファイルの引数を常に使用することが推奨されます。}}

== NILFS2 ファイルシステムを作成する ==

この記事ではデバイスに[[パーティション]]がすでにセットアップされていると仮定しています。{{Pkg|nilfs-utils}} を[[インストール]]してください。{{ic|mkfs.nilfs2}} を使い、{{ic|''/dev/sdxY''}} のように対象のパーティションを指定してフォーマットしてください:

# mkfs.nilfs2 -L mylabel ''/dev/sdxY''

利用可能なオプションは {{man|8|mkfs.nilfs2}} を参照してください。

=== ラベルを変更する ===

nilfs-tune コマンドはマウントされていないファイルシステムにのみ使用してください。

# nilfs-tune -L newlabel ''/dev/sdxY''

== マウントする ==

その後、ファイルシステムは手動あるいは他の方法でマウントできるようになります:

# mount /dev/sdxY /mnt/foo

=== マウントオプション ===

==== エラーハンドリング ====

{{ic|1=errors=continue}} / {{ic|remount-ro}} / {{ic|panic}} は、ファイルシステムエラー時に NILFS2 が何をすべきかを指定します。{{ic|continue}} はエラーを無視し、{{ic|remount-ro}} はファイルシステムを読み取り専用でマウントし、{{ic|panic}} はシステムを停止させます。

==== Discard ====

{{ic|discard}} / {{ic|nodiscard}} はそれぞれ [[TRIM]] を有効化/無効化します。

利用可能なオプションは {{man|8|mount.nilfs2}} を参照してください。

== スナップショット ==

NILFS2 には2種類のスナップショット (チェックポイントとスナップショット) があります。これらはそれぞれ {{ic|cp}}、{{ic|ss}} と表記されます。

NILFS2 は書き込み毎にチェックポイントを自動的に作成します。チェックポイントは、ファイルシステムが満タンになった時やユーザーが手動でガベージコレクションを発動させた時に領域を空けるために NILFS2 のガベージコレクタによって自動的に削除されうるスナップショットです。

スナップショットはチェックポイントから手動で変換する必要があり、自動的に削除されません。スナップショットはマウントすることができ、データを復元することができます。

=== スナップショットを一覧表示する ===

チェックポイントとスナップショットは以下のようにして一覧表示できます:

{{hc|head=lscp /dev/sdxY|output=
CNO DATE TIME MODE FLG BLKCNT ICNT
1 2025-04-14 21:35:06 cp - 10181423 554012
2 2025-04-14 22:17:38 cp - 10181423 554012
3 2025-04-14 22:18:22 cp - 10181423 554012
4 2025-04-14 22:28:56 cp - 10181423 554012
5 2025-04-14 22:39:59 cp - 10181423 554012
...
}}

スナップショットのみを表示するには lscp に {{ic|-s}} フラグを渡してください。利用可能なオプションは {{man|1|lscp}} を参照してください。

=== チェックポイントをスナップショットに変換する ===

チェックポイントからデータを復元するには、先にチェックポイントをスナップショットに変換する必要があります。変換には {{ic|chcp}} ユーティリティを使用してください:

# chcp ss /dev/sdxY ''checkpoint-number''

{{ic|checkpoint-number}} は {{ic|lscp}} の CNO 列のチェックポイント番号です。

実行すると、{{ic|lscp}} では以下のように表示されます:

4 2025-04-14 22:28:56 ss - 10181423 554012

スナップショットをチェックポイントに戻すには:

# chcp cp /dev/sdxY ''checkpoint-number''

=== スナップショットを作成する ===

以下のようにしてチェックポイントを作成してください:

# mkcp /dev/sdxY

あるいはスナップショットを直接作成するには:

# mkcp --snapshot /dev/sdxY

=== スナップショットをマウントする ===

以下のコマンドはスナップショット {{ic|checkpoint-number}} を読み取り専用で {{ic|/mnt/snapshot}} にマウントします:

# mount -t nilfs2 -r -o cp=checkpoint-number /dev/sdxY /mnt/snapshot

=== スナップショットを削除する ===

チェックポイントを一つだけ削除するには:

# rmcp /dev/sdxY ''checkpoint-number''

ある範囲のチェックポイントを一括で削除するには:

# rmcp /dev/sdxY ''start''..''end''

{{ic|start}} は開始チェックポイント番号、{{ic|end}} は終点のチェックポイント番号です。(訳注: 削除範囲は [start, end] です。[start, end) ではありません。)

特定のチェックポイント及びそれより前のチェックポイントを全て削除するには:

# rmcp /dev/sdxY ..''checkpoint-number''

特定のチェックポイント及びそれより後のチェックポイントを全て削除するには:

# rmcp /dev/sdxY ''checkpoint-number''..

{{tip|{{ic|-i}} フラグを追加すると {{ic|rmcp}} は入力された値をインタラクティブにダブルチェックします。}}

詳細は {{man|8|rmcp}} を参照してください。

== ファイルシステムをクリーンアップする ==

マウント済みの NILFS2 ファイルシステムから古いチェックポイントをクリーンアップするには:

# nilfs-clean /dev/sdxY

ガベージコレクタに関する詳細は {{man|8|nilfs-clean}} と {{man|8|nilfs_cleanerd}} を参照してください。

== ファイルシステムをリサイズする ==

{{ic|nilfs-resize}} は NILFS2 ファイルシステムをリサイズします。

マウント済み NILFS2 ファイルシステムは以下のコマンドでリサイズできます:

# nilfs-resize /dev/sdxY desired-size

{{ic|desired-size}} では単位接尾辞 {{ic|s}} (512バイトセクタ)、{{ic|K}} (キロバイト)、{{ic|M}} (メガバイト)、{{ic|G}} (ギガバイト)、{{ic|T}} (テラバイト) を使用できます。{{ic|desired-size}} が指定されなかった場合、デフォルトでパーティションのサイズが使用されます。

{{ic|nilfs-resize}} は勝手にパーティションのサイズを変更しません。ファイルシステムを縮小した場合は後でパーティションを縮小する必要があり、逆にファイルシステムを拡張したい場合はあらかじめパーティションを拡張しておく必要があります。これは [[fdisk]] などで行えます。

詳細は {{man|8|nilfs-resize}} を参照してください。

== 参照 ==

* [https://nilfs.sourceforge.io/en/faq.html NILFS2 FAQ]

{{TranslationStatus|NILFS2|2025-07-05|833898}}

ファイルシステム

2025-07-04T14:50:16Z

AshMyzk: 同期

[[Category:ファイルシステム]]
[[Category:一覧]]
[[en:File systems]]
[[es:File systems]]
[[hu:File systems]]
[[it:File systems]]
[[pt:File systems]]
[[ru:File systems]]
[[uk:File systems]]
[[zh-hans:File systems]]
{{Related articles start}}
{{Related|パーティショニング}}
{{Related|デバイスファイル#lsblk}}
{{Related|ファイルのパーミッションと属性}}
{{Related|fsck}}
{{Related|fstab}}
{{Related|アプリケーション一覧/ユーティリティ#マウントツール}}
{{Related|QEMU#raw イメージからパーティションをマウントする}}
{{Related|udev}}
{{Related|udisks}}
{{Related|umask}}
{{Related|USB ストレージデバイス}}
{{Related articles end}}

[[Wikipedia:ja:ファイルシステム|Wikipedia]] より:

:ファイルシステムは、コンピュータのリソースを操作するための、オペレーティングシステム (OS) が持つ機能の一つ。ファイルとは、主に補助記憶装置に格納されたデータを指すが、デバイスやプロセス、カーネル内の情報といったものもファイルとして提供するファイルシステムもある。

:より正確に定義すれば、ファイルシステムは抽象データ型の集まりであり、ストレージ、階層構造、データの操作/アクセス/検索のために実装されたものである。ファイルシステムを特殊用途のデータベース管理システム (DBMS) と見なせるかどうかは議論があるが、ファイルシステムとデータベース管理システムには多くの共通点がある。

個々のドライブパーティションに、多くのファイルシステムのなかから1つを設定することができます。ファイルシステムはそれぞれにメリット、デメリット、特徴があります。ここではサポートされているファイルシステムの概要を記述します。より多くの情報を見るには Wikipedia へのリンクを辿って下さい。

== ファイルシステムのタイプ ==

一般的な概要については {{man|5|filesystems}} を、詳細な機能の比較については [[Wikipedia:Comparison of file systems]] を参照してください。カーネルによってすでにロードされている、あるいは組み込まれているファイルシステムは、{{ic|/proc/filesystems}} にリストアップされています。一方、インストールされているモジュールは {{ic|ls /lib/modules/$(uname -r)/kernel/fs}} ですべて見ることができます。

{| class="wikitable sortable"
|+ 組み込まれている (in-tree) ファイルシステムと FUSE ファイルシステム
! ファイルシステム
! 作成コマンド
! ユーザースペースユーティリティ
! [[Archiso]] [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64]
! カーネルのドキュメント [https://docs.kernel.org/filesystems/index.html]
! 備考
|-
| [[Bcachefs]]
| {{man|8|bcachefs}}
| {{Pkg|bcachefs-tools}}
| {{Yes}}
| [https://docs.kernel.org/filesystems/bcachefs/index.html]
| Linux 6.7 から利用可能 (実験的)。
|-
| [[Btrfs]]
| {{man|8|mkfs.btrfs}}
| {{Pkg|btrfs-progs}}
| {{Yes}}
| [https://docs.kernel.org/filesystems/btrfs.html btrfs.html]
| [https://btrfs.readthedocs.io/en/latest/Status.html 安定性に関する状況]
|-
| [[VFAT]]
| {{man|8|mkfs.fat}}
| {{Pkg|dosfstools}}
| {{Yes}}
| [https://docs.kernel.org/filesystems/vfat.html vfat.html]
| [[Wikipedia:ja:Windows 9x系|Windows 9x]] のファイルシステム。一般的に、USB フラッシュドライブや SD カードで用いられます。
|-
| rowspan="2" | [[Wikipedia:ja:exFAT|exFAT]]
| {{man|8|mkfs.exfat}}
| {{Pkg|exfatprogs}}
| {{Yes}}
|
| Linux 5.4 のネイティブのファイルシステム。[https://lwn.net/Articles/799425/] 一般的に、USB フラッシュドライブや SD カードで用いられます。
|-
| {{man|8|mkexfatfs}}
| {{Pkg|exfat-utils}}
| {{No}}
| N/A (FUSE ベース)
|
|-
| [[F2FS]]
| {{man|8|mkfs.f2fs}}
| {{Pkg|f2fs-tools}}
| {{Yes}}
| [https://docs.kernel.org/filesystems/f2fs.html f2fs.html]
| フラッシュメモリベースのデバイス。縮小することはできません。
|-
| [[ext3]]
| {{man|8|mkfs.ext3}}
| {{Pkg|e2fsprogs}}
| {{Yes}}
| [https://docs.kernel.org/filesystems/ext3.html ext3.html]
|
|-
| [[ext4]]
| {{man|8|mkfs.ext4}}
| {{Pkg|e2fsprogs}}
| {{Yes}}
| [https://docs.kernel.org/admin-guide/ext4.html ext4.html]
|
|-
| [[Wikipedia:ja:Hierarchical File System|HFS]]
| {{man|8|mkfs.hfsplus|url=https://manpages.debian.org/unstable/hfsprogs/mkfs.hfsplus.8.en.html}}
| {{AUR|hfsprogs}}
| {{No}}
| [https://docs.kernel.org/filesystems/hfs.html hfs.html]
| [[Wikipedia:ja:Classic Mac OS|Classic Mac OS]] のファイルシステム
|-
| [[Wikipedia:ja:HFS Plus|HFS+]]
| {{man|8|mkfs.hfsplus|url=https://manpages.debian.org/unstable/hfsprogs/mkfs.hfsplus.8.en.html}}
| {{AUR|hfsprogs}}
| {{No}}
| [https://docs.kernel.org/filesystems/hfsplus.html hfsplus.html]
| [[Wikipedia:ja:macOS|macOS]] (8–10.12) のファイルシステム
|-
| [[JFS]]
| {{man|8|mkfs.jfs}}
| {{Pkg|jfsutils}}
| {{Yes}}
| [https://docs.kernel.org/admin-guide/jfs.html jfs.html]
|
|-
| [[NILFS2]]
| {{man|8|mkfs.nilfs2}}
| {{Pkg|nilfs-utils}}
| {{Yes}}
| [https://docs.kernel.org/filesystems/nilfs2.html nilfs2.html]
| 基本的にフラッシュベースのデバイスで用いることを意図しています。[[拡張属性|xattrs]] と [[ACL]] はサポートされていません。
|-
| rowspan="2" | [[NTFS]]
|
|
| {{Yes}}
| [https://docs.kernel.org/filesystems/ntfs3.html ntfs3.html]
| [[Wikipedia:ja:Windows NT|Windows NT]] のファイルシステム。[https://www.paragon-software.com/home/ntfs3-driver-faq/ 新しいドライバ]。Linux 5.15 から利用可能。
|-
| {{man|8|mkfs.ntfs}}
| {{Pkg|ntfs-3g}}
| {{Yes}}
| N/A (FUSE ベース)
| 拡張機能付き FUSE ドライバ。
|-
| [[Wikipedia:ReiserFS|ReiserFS]]
| {{man|8|mkfs.reiserfs|url=https://manpages.debian.org/unstable/reiserfsprogs/mkfs.reiserfs.8.en.html}}
| {{AUR|reiserfsprogs}}
| {{No}}
|
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb103a51640ee32ab01c51e13bf8fca211f25f61 Linux 5.18 から非推奨となっており]、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb6f20ecb121cef4d7946f834a6ee867c4e21b4a Linux 6.13 で削除されました]。
|-
| [[Wikipedia:ja:Universal Disk Format|UDF]]
| {{man|8|mkfs.udf}}
| {{Pkg|udftools}}
| {{Yes}}
| [https://docs.kernel.org/filesystems/udf.html udf.html]
| ディスクイメージや DVD/ブルーレイ用の ISO/IEC 13346 ファイルシステム。
|-
| [[XFS]]
| {{man|8|mkfs.xfs}}
| {{Pkg|xfsprogs}}
| {{Yes}}
|
[https://docs.kernel.org/admin-guide/xfs.html xfs.html] 
[https://docs.kernel.org/filesystems/xfs/xfs-delayed-logging-design.html xfs-delayed-logging-design.html] 
[https://docs.kernel.org/filesystems/xfs/xfs-self-describing-metadata.html xfs-self-describing-metadata.html]
| [https://web.archive.org/web/20220902080136/https://xfs.org/index.php/XFS_FAQ#Q:_Is_there_a_way_to_make_a_XFS_filesystem_larger_or_smaller.3F 縮小不可]
|}

{| class="wikitable sortable"
|+ 外部 (out-of-tree) のファイルシステム
! ファイルシステム
! 作成コマンド
! カーネルパッチセット
! ユーザースペースユーティリティ
! 備考
|-
| [[Wikipedia:ja:Apple File System|APFS]]
| {{man|8|mkapfs|url=https://manpages.debian.org/unstable/apfsprogs/mkapfs.8.en.html}}
| {{AUR|linux-apfs-rw-dkms-git}}
| {{AUR|apfsprogs-git}}
| [[Wikipedia:ja:macOS|macOS]] (10.13 およびそれ以降) のファイルシステム。読み取り専用。書き込みサポートは試験的。Fuse バージョンの {{AUR|apfs-fuse-git}} も参照。
|-
| [[Wikipedia:ja:Reiser4|Reiser4]]
| {{man|8|mkfs.reiser4|url=https://manpages.debian.org/unstable/reiser4progs/mkfs.reiser4.8.en.html}}
|
| {{AUR|reiser4progs}}
|
|-
| [[ZFS]]
|
| {{AUR|zfs-linux}}, {{AUR|zfs-dkms}}
| {{AUR|zfs-utils}}
| [[Wikipedia:OpenZFS|OpenZFS]] 移植
|}

=== ジャーナリング ===

ext3/4、HFS+、JFS、NTFS、ReiserFS、XFS ファイルシステムは[[Wikipedia:ja:ジャーナリングファイルシステム|ジャーナリング]]を使用します。ジャーナリングは、変更をファイルシステムにコミットする前にログに記録することで、障害に対する耐性を提供します。システムクラッシュや停電が発生した場合、こうしたファイルシステムはより迅速にオンラインに戻り、データが破損する可能性が低くなります。ログ記録はファイルシステム内の専用領域で行われます。

ext3/4 はデータモードジャーナリングを提供しており、任意でメタデータに加えてデータもログに記録できます。データモードジャーナリングは書き込み操作を2回行うため (まずジャーナルに、次にディスクに)、速度面でペナルティがあります。そのため、データモードジャーナリングはデフォルトで有効化されていません。ファイルシステムの種類と機能を選ぶ際には、システム速度とデータ安全性とのトレードオフについて検討するべきでしょう。

同様に、Reiser4 は設定可能な[https://reiser4.wiki.kernel.org/index.php/Reiser4_transaction_models 「トランザクションモデル」]を提供しています。[https://reiser4.wiki.kernel.org/index.php/V4#Wandering_Logs wandering logs] と呼ばれる特殊なモデルは、ディスクへ2回書き込む必要がありません。'''write-anywhere''' モデルは、純粋なコピーオンライト方式です。'''hybrid''' と呼ばれる混合方式は、ヒューリスティックにこれら2つのモデルを切り替えます。

Reiser4、Btrfs、Bcachefs、ZFS といったコピーオンライト (別名 write-anywhere) ベースのファイルシステムは、設計上完全にアトミックに動作し、メタデータとインラインデータの両方に対してチェックサムを提供します (操作が不完全に行われることはありません。正常に動作しているハードウェア上では、不完全な操作によってデータが破損することはありません)。なので、これらのファイルシステムは、設計上、他のファイルシステムよりもデータ損失が発生しにくく、メタデータを保護するために従来のジャーナルを使用する必要がありません (メタデータが in-place に更新されることはないからです)。Btrfs は依然としてジャーナルのようなログツリーを使用していますが、fdatasync/fsync の高速化のために使用しているにすぎません。

FAT、exFAT、ext2、HFS はジャーナリングもアトミック性も提供していません。これらのファイルシステムは、一時的な使用あるいは古いシステムのためのものであり、信頼できるストレージが必要である場合に使用することは推奨されません。

=== FUSE ベースのファイルシステム ===

[[FUSE]] を見てください。

=== スタック可能なファイルシステム ===

* {{App|[[eCryptfs]]|Enterprise Cryptographic Filesystem は Linux 用のディスク暗号化ソフトウェアのパッケージです。これは POSIX 準拠のファイルシステムレベルの暗号化レイヤとして実装され、オペレーティングシステムレベルで GnuPG と同様の機能を提供することを目的としています。|https://ecryptfs.org|{{Pkg|ecryptfs-utils}}}}
* {{App|mergerfs|FUSE ベースの union ファイルシステムです。|https://github.com/trapexit/mergerfs|{{AUR|mergerfs}}}}
* {{App|mhddfs|FUSE ベースの union ファイルシステムである Multi-HDD FUSE ファイルシステム。|http://mhddfs.uvw.ru|{{AUR|mhddfs}}}}
* {{App|[[overlayfs]]|OverlayFS は Linux 用のファイルシステムサービスで、他のファイルシステムの union マウントを実装しています。|https://docs.kernel.org/filesystems/overlayfs.html|{{Pkg|linux}}}}
* {{App|unionfs-fuse|ユーザースペース Unionfs の実装。|https://github.com/rpodgorny/unionfs-fuse|{{AUR|unionfs-fuse}}}}

=== 読み取り専用のファイルシステム ===

* {{App|DwarFS|DwarFS は、Linux と Windows 用の高速で高圧縮率の読み取り専用ファイルシステムです。DwarFS は、多かれ少なかれ SquashFS と同じ機能をサポートしていますが、より圧縮に優れており、ハッシュアルゴリズムをカスタム可能です。|https://github.com/mhx/dwarfs|{{Aur|dwarfs}}}}
* {{App|[[Wikipedia:ja:EROFS|EROFS]]|Enhanced Read-Only File System は、パフォーマンスの向上とストレージ容量の圧縮を目的とした軽量の読み取り専用ファイルシステムです。|https://erofs.docs.kernel.org/|{{Pkg|erofs-utils}}}}
* {{App|[[Wikipedia:ja:SquashFS|SquashFS]]|SquashFS は、読み取り専用の圧縮ファイルシステムです。SquashFS はファイル、inodes、ディレクトリーを圧縮し、さらに大きな圧縮のために最大 1 MiB のブロック・サイズをサポートします。|https://github.com/plougher/squashfs-tools|{{Pkg|squashfs-tools}}}}

=== クラスタ化ファイルシステム ===

* {{App|[[BeeGFS]]|高パフォーマンスコンピューティングのために開発・最適化された並列ファイルシステム。|https://www.beegfs.io/c/|{{AUR|beegfs-client}}}}
* {{App|[[Ceph]]|優れたパフォーマンス、信頼性、拡張性を実現するように設計された、統合された分散ストレージシステム。|https://ceph.com/|{{AUR|ceph}}}}
* {{App|[[GlusterFS]]|数ペタバイトまで拡張可能なクラスタファイルシステム。|https://www.gluster.org/|{{Pkg|glusterfs}}}}
* {{App|[[IPFS]]|Web を高速化、安全化、およびオープン化するためのピアツーピアハイパーメディアプロトコル。IPFS は HTTP に取って代わり、私たち全員のためにより良いウェブを構築することを目指しています。ブロックを使用してファイルの一部を保存し、各ネットワーク・ノードは関心のあるコンテンツのみを保存し、重複除外、分散、拡張性の高いシステムをユーザーのみに制限 (現在はアルファ版)|https://ipfs.io/|{{Pkg|kubo}}}}
* {{App|[[MinIO]]|MinIO は高パフォーマンスな S3 互換のオブジェクトストレージを提供します。|https://min.io|{{Pkg|minio}}}}
* {{App|[[Wikipedia: MooseFS|MooseFS]]|MooseFS は、耐障害性で可用性が高い、高性能なスケールアウトネットワーク分散ファイルシステムです。|https://moosefs.com|{{Pkg|moosefs}}}}
* {{App|OpenAFS|AFS 分散ファイルシステムのオープンソース実装。|https://www.openafs.org|{{AUR|openafs}}}}
* {{App|[[Wikipedia: OrangeFS|OrangeFS]]|OrangeFS は、マルチサーバ・ベースのディスク・ストレージに透過的に並列アクセスするために設計されたスケール・アウト・ネットワーク・ファイル・システムです。並列および分散アプリケーション向けに最適化された MPI-IO のサポート。Linux クライアントだけでなく、Windows、Hadoop、WebDAV 用の並列ストレージの使用を簡素化します。POSIX 互換です。バージョン4.6以降のLinux カーネルに含まれます。|https://www.orangefs.org/}}
* {{App|Sheepdog|ボリュームおよびコンテナサービス用の分散オブジェクトストレージシステムで、ディスクとノードをインテリジェントに管理します。|https://sheepdog.github.io/sheepdog/|{{AUR|sheepdog}}}}

=== 共有ディスクファイルシステム ===

* {{App|[[Wikipedia:GFS2|GFS2]]|GFS2 では、クラスタのすべてのメンバーが同じ共有ブロック・ストレージに直接同時にアクセスできます。|https://pagure.io/gfs2-utils|{{AUR|gfs2-utils}}}}
* {{App|[[Wikipedia:OCFS2|OCFS2]]|Oracle Cluster File System (バージョン2) は、Oracle Corporation によって開発され、GNU General Public License の下でリリースされる共有ディスク・ファイル・システムです。|https://oss.oracle.com/projects/ocfs2/|{{AUR|ocfs2-tools}}}}
* {{App|[[Wikipedia:VMware_VMFS|VMware VMFS]]|VMware の VMFS (Virtual Machine File System) は、同社の主力サーバ仮想化スイートである vSphere で使用されているファイルシステムです。|https://core.vmware.com/resource/vmware-vsphere-vmfs|{{AUR|vmfs-tools}}}}

== 既存のファイルシステムを特定する ==

[[lsblk]] を使って、既存のファイルシステムを特定することができます:

{{hc|1=$ lsblk -f|2=
NAME FSTYPE LABEL UUID MOUNTPOINT
sdb
└─sdb1 vfat Transcend 4A3C-A9E9
}}

存在する場合、既存のファイルシステムが {{ic|FSTYPE}} 列に表示されます。[[mount]] されている場合は、{{ic|MOUNTPOINT}} 列に表示されます。

== ファイルシステムを作成する ==

ファイルシステムは通常、[[LVM]]、[[RAID]]、[[dm-crypt]] などの論理コンテナ内、[[パーティション]]、通常のファイル ([[Wikipedia:Loop device]] を参照) に作成されます。このセクションでは、パーティションの場合について説明します。

{{Note|1=ファイルシステムはディスクに直接書き込むことができます (そのようなディスクは ''スーパーフロッピー'' または [[パーティショニング#パーティションレスディスク|パーティションレスディスク]] と呼ばれます)。この方法を取るといくつかの制限が発生します (特に、そのようなドライブから[[Arch ブートプロセス|起動する]]場合)。例については、[[Btrfs#パーティションレス Btrfs ディスク]] を参照してください。}}

{{Warning|
* 新しいファイルシステムを作成した後、このパーティション上に以前保存されていたデータを復元できる可能性はほとんどありません。'''保持したいデータのバックアップを作成してください'''。
* 特定のパーティションの目的により、ファイルシステムの選択が制限される場合があります。たとえば、 [[EFI システムパーティション]] には [[FAT32]] ファイルシステムが含まれている必要があり、 {{ic|/boot}} ディレクトリを含むファイルシステムは [[ブートローダー]] によってサポートされている必要があります。
}}

続行する前に、ファイルシステムを作成する[[lsblk|デバイスを特定]]し、それがマウントされているかどうかを[[lsblk|確認]]してください。例えば:

{{hc|$ lsblk -f|
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 C4DA-2C4D
├─sda2 ext4 5b1564b2-2e2c-452c-bcfa-d1f572ae99f2 /mnt
└─sda3 56adc99b-a61e-46af-aab7-a6d07e504652
}}

先に進む前に、マウントされているファイルシステムを '''[[#ファイルシステムのアンマウント|アンマウント]]しなければなりません'''。上記の例では、既存のファイルシステムは {{ic|/dev/sda2}} にあり、 {{ic|/mnt}} にマウントされていますが、マウントを解除する必要があります:

# umount /dev/sda2

マウントされたばかりのファイルシステムを見つける方法は、[[#マウントしたファイルシステムの一覧表示]] を参照してください。

新しいファイルシステムを作成するには、{{man|8|mkfs}} を使用します。正確なタイプ、および特定のファイルシステムにインストールする可能性のあるユーザースペースユーティリティについては、 [[#ファイルシステムのタイプ]] を参照してください。

たとえば、 {{ic|/dev/sda1}} でタイプ [[ext4]] (Linux データパーティションで一般的に使われています) の新しいファイルシステムを作成するには、次のコマンドを実行します:

# mkfs.ext4 /dev/sda1

{{Tip|
* ''mkfs.ext4'' の {{ic|-L}} フラグを使用して、[[永続的なブロックデバイスの命名#by-label|ファイルシステムラベル]] を指定できます。''e2label'' を使用して、既存のファイルシステムのラベルを変更できます。
* ファイルシステムは、特定の制限付きで、作成後に「サイズ変更」できます。たとえば、 [[XFS]] ファイルシステムのサイズを増やすことはできますが、減らすことはできません。詳細については、 [[Wikipedia:ファイルシステムの比較#サイズ変更機能]] およびそれぞれのファイルシステムのドキュメントを参照してください。}}

これで、新しいファイルシステムを任意のディレクトリにマウントできます。

== ファイルシステムのマウント ==

デバイス(パーティションなど)上にあるファイルシステムを手動でディレクトリにマウントするには、{{man|8|mount}} を使用します。この例では {{ic|/dev/sda1}} を {{ic|/mnt}} にマウントしています。

# mount /dev/sda1 /mnt

これは {{ic|/dev/sda1}} 上のファイルシステムをディレクトリ {{ic|/mnt}} にアタッチし、ファイルシステムの内容を見えるようにするものです。この操作の前に {{ic|/mnt}} に存在していたデータは、デバイスがアンマウントされるまで不可視状態になります。

[[fstab]] には、デバイスが存在する場合に自動的にマウントされる方法に関する情報が含まれています。この動作を変更する方法の詳細については、[[fstab]] の記事を参照してください。

デバイスが {{ic|/etc/fstab}} で指定されていて、コマンドラインでデバイスかマウントポイントだけが指定された場合、その情報がマウント時に使用されます。例えば、{{ic|/etc/fstab}} に {{ic|/dev/sda1}} を {{ic|/mnt}} にマウントするという行がある場合、以下は自動的にその場所にデバイスをマウントすることになります。

# mount /dev/sda1

または、

# mount /mnt

''mount'' にはいくつかのオプションがあり、その多くは指定されたファイルシステムに依存します。
オプションは以下の方法で変更することができます:

* コマンドラインで ''mount'' と共にフラグを使用する
* [[fstab]] を編集する
* [[udev]] ルールを作成する
* [[Arch build system|カーネルを自分でコンパイルする]]
* ファイルシステム固有のマウントスクリプト ({{ic|/usr/bin/mount.*}} にあります) を使用する

より詳しい情報は、これらの関連記事と、興味のあるファイルシステムの記事をご覧下さい。

{{Tip|
* ファイルシステムは ''mount'' の代わりに ''systemd-mount'' でもマウントできます。マウントポイントが指定されていない場合、ファイルシステムは {{ic|/run/media/system/''device_identifier''/}} にマウントされます。これにより、ファイルシステムをどこにマウントするかを決めることなく、簡単にマウントすることができます。使い方や詳細は {{man|1|systemd-mount}} を参照してください。
* 一般ユーザーとしてファイルシステムをマウントする方法については、[[udisks#使用方法]] を見てください。これにより、root 権限や完全なグラフィック環境、udisks を使用するファイルマネージャを用いずにファイルシステムをマウントできるようになります。
}}

=== マウントしたファイルシステムの一覧表示 ===

マウントされている全てのファイルシステムを一覧表示するには {{man|8|findmnt}} を使ってください:

$ findmnt

''findmnt'' は様々な引数を取り、出力をフィルタリングしたり、追加情報を表示したりすることができます。例えば、デバイスやマウントポイントを引数として取り、指定されたものについての情報のみを表示させることができます:

$ findmnt /dev/sda1

''findmnt'' は {{ic|/etc/fstab}}, {{ic|/etc/mtab}}, {{ic|/proc/self/mounts}} から情報を収集します。

=== ファイルシステムのアンマウント ===

ファイルシステムをアンマウントするには {{man|8|umount}} を使ってください。ファイルシステムがあるデバイス (例:{{ic|/dev/sda1}}) かマウントポイント (例:{{ic|/mnt}}) のどちらかを指定することが可能です。

# umount /dev/sda1

または、

# umount /mnt

== トラブルシューティング ==

=== "linux Structure needs cleaning" ===

ファイルシステムを[[#ファイルシステムのアンマウント|アンマウント]]し、問題のあるボリュームで [[fsck]] を実行してください。

== 参照 ==

* {{man|5|filesystems}}
* {{man|1|systemd-mount}}
* [https://docs.kernel.org/filesystems/index.html Linux によってサポートされているファイルシステムのドキュメント]
* [[Wikipedia:File systems]]
* [[Wikipedia:Mount (Unix)]]

{{TranslationStatus|File systems|2025-07-04|839407}}

Fstab

2025-07-04T14:43:07Z

AshMyzk: 同期

{{Lowercase title}}
[[Category:ファイルシステム]]
[[Category:ブートプロセス]]
[[de:Fstab]]
[[en:Fstab]]
[[es:Fstab]]
[[fr:Fstab]]
[[hu:Fstab]]
[[it:Fstab]]
[[pt:Fstab]]
[[ru:Fstab]]
[[zh-hans:Fstab]]
{{Related articles start}}
{{Related|永続的なブロックデバイスの命名}}
{{Related|ファイルシステム}}
{{Related|tmpfs}}
{{Related|スワップ}}
{{Related|genfstab}}
{{Related articles end}}

{{man|5|fstab}} ファイルは、ディスクパーティションや様々なブロックデバイス、リモートファイルシステムをどうやってファイルシステムにマウントするかを記述します。

ファイルシステムは一行毎に記述されます。書かれている定義は、起動時やシステムマネージャの設定がリロードされたときに [[systemd]] の mount ユニットに動的に変換されます。デフォルトの設定では、マウントを必要とするサービスが起動する前にファイルシステムの [[fsck]] とマウントを自動的に実行します。例えば、[[NFS]] や [[Samba]] などのリモートファイルシステムはネットワークが立ち上がった後に systemd によって自動的にマウントされます。そのため、{{ic|/etc/fstab}} に指定するローカル・リモートファイルシステムのマウントに設定は必要ありません。詳しくは {{man|5|systemd.mount}} を見て下さい。

{{ic|mount}} コマンドはディレクトリやデバイスがひとつだけ指定された場合、他のパラメータの値を取得するために fstab を使います。このとき、fstab に記述されたマウントオプションも使われます。

== 使用法 ==

以下は、ファイルシステムの UUID を使用した {{ic|/etc/fstab}} の例です:

{{hc|/etc/fstab|2=
# <device> <dir> <type> <options> <dump> <fsck>
UUID=0a3407de-014b-458b-b5c1-848e92a327a3 / ext4 defaults 0 1
UUID=CBB6-24F2 /boot vfat defaults,nodev,nosuid,noexec,fmask=0177,dmask=0077 0 2
UUID=f9fe0b69-a280-415d-a03a-a32752370dee none swap defaults 0 0
UUID=b411dc99-f0a0-4c87-9e05-184977be8539 /home ext4 defaults 0 2
}}

* {{ic|<device>}} には、マウントされるべきブロック特殊デバイスやリモートファイルシステムを記述します。[[#ファイルシステムの識別]] を見てください。
* {{ic|<dir>}} は、ファイルシステムが[[マウント]]されるディレクトリ (つまりマウントポイント) です。このディレクトリは事前に作成しておく必要があります。
* {{ic|<type>}} は[[ファイルシステム]]の種類です。
* {{ic|<options>}} はファイルシステムのマウントオプションです。{{man|8|mount|FILESYSTEM-INDEPENDENT MOUNT OPTIONS}} と {{man|5|ext4|Mount options for ext4}} を見てください。
* {{ic|<dump>}} は {{man|8|dump|url=https://linux.die.net/man/8/dump}} ユーティリティによってチェックされます。このフィールドは通常 {{ic|0}} にセットします。{{ic|0}} はチェックを無効化します。
* {{ic|<fsck>}} は、起動時にチェックするファイルシステムの順番を設定します。{{man|8|fsck}} を見てください。ルートファイルシステムには {{ic|1}} を設定するべきです。他のパーティションには {{ic|2}} を設定するか、チェックを無効化する {{ic|0}} を設定するべきです。

{{Tip|
* タイプ {{ic|auto}} は、使用されているファイルシステムの種類をマウントコマンドに推測させます。このオプションは、[[光学ディスクドライブ|光学メディア]] (CD/DVD/Blu-ray) の場合に便利です。
* ルートファイルシステムが [[btrfs]] か [[XFS]] の場合、fsck の順番は {{ic|1}} ではなく {{ic|0}} に設定するべきです。{{man|8|fsck.btrfs}} と {{man|8|fsck.xfs}} を見てください。
}}

スタートアップ時や、{{ic|noauto}} オプションが指定されていないデバイスに対して {{man|8|mount}} コマンドを {{ic|-a}} フラグ付きで実行した時に、{{ic|/etc/fstab}} 内で指定されたすべてのデバイスは自動的にマウントされます。リストにあるが存在しないデバイスは、{{ic|nofail}} オプションが使用されている場合を除き、エラーとなります。

詳細は {{man|5|fstab|DESCRIPTION}} を見てください。

== ファイルシステムの識別 ==

{{ic|/etc/fstab}} でファイルシステムを識別する方法がいくつか存在します: カーネルの名前記述子、ファイルシステムのラベルや UUID、GPT パーティションのラベルや UUID です。カーネルの名前記述子は使用すべきではありません。ラベルよりも UUID や PARTUUID を優先して使用すべきです。詳細は [[永続的なブロックデバイスの命名]] を見てください。この記事を読み進める前に、その記事を先に読むことをおすすめします。

このセクションでは、ファイルシステムをマウントするいくつかの方法を例を通して説明します。以下の例で使用されるコマンド {{ic|lsblk -f}} と {{ic|blkid}} の出力は、[[永続的なブロックデバイスの命名]] で見られます。

=== カーネルの名前記述子 ===

{{ic|lsblk -f}} を実行してパーティションの一覧を出力し、''NAME'' 列の値の前に {{ic|/dev/}} を付け加えてください。

{{hc|/etc/fstab|2=
# <device <dir> <type> <options> <dump> <fsck>
/dev/sda2 / ext4 defaults 0 1
/dev/sda1 /boot vfat defaults,nodev,nosuid,noexec,fmask=0177,dmask=0077 0 2
/dev/sda3 /home ext4 defaults 0 2
/dev/sda4 none swap defaults 0 0
}}

{{Warning|[[デバイスファイル#ブロックデバイスの名前|ブロックデバイスのカーネル名記述子]] は [[永続的なブロックデバイスの命名|永続的]] ではなく、ブートごとに変更される可能性があるため、設定ファイル ({{ic|/etc/fstab を含む}}) で使用しないでください。}}

=== ファイルシステムラベル ===

{{ic|lsblk -f}} を実行してパーティションの一覧を出力し、[[LABEL]] 列の値の前に {{ic|1=LABEL=}} を付け加えてください。あるいは、{{ic|blkid}} を実行し、LABEL の値を引用符無しで使ってください:

{{hc|/etc/fstab|2=
# <device> <dir> <type> <options> <dump> <fsck>
LABEL=System / ext4 defaults 0 1
LABEL=ESP /boot vfat defaults,nodev,nosuid,noexec,fmask=0177,dmask=0077 0 2
LABEL=Data /home ext4 defaults 0 2
LABEL=Swap none swap defaults 0 0
}}

{{Note|任意のフィールドにスペースが含まれる場合、[[#ファイルパスのスペース]] を見てください。}}

=== ファイルシステム UUID ===

{{ic|lsblk -f}} を実行してパーティションの一覧を出力し、[[UUID]] 列の値の前に {{ic|1=UUID=}} を付け加えてください。あるいは、{{ic|blkid}} を実行し、UUID の値を引用符無しで使ってください:

{{hc|/etc/fstab|2=
# <device> <dir> <type> <options> <dump> <fsck>
UUID=0a3407de-014b-458b-b5c1-848e92a327a3 / ext4 defaults 0 1
UUID=CBB6-24F2 /boot vfat defaults,nodev,nosuid,noexec,fmask=0177,dmask=0077 0 2
UUID=b411dc99-f0a0-4c87-9e05-184977be8539 /home ext4 defaults 0 2
UUID=f9fe0b69-a280-415d-a03a-a32752370dee none swap defaults 0 0
}}

=== GPT パーティションラベル ===

{{ic|blkid}} を実行してパーティションの一覧を出力し、[[PARTLABEL]] の値を引用符無しで使ってください:

{{hc|/etc/fstab|2=
# <device> <dir> <type> <options> <dump> <fsck>
PARTLABEL=GNU/Linux / ext4 defaults 0 1
PARTLABEL=EFI\040system\040partition /boot vfat defaults,nodev,nosuid,noexec,fmask=0177,dmask=0077 0 2
PARTLABEL=Home /home ext4 defaults 0 2
PARTLABEL=Swap none swap defaults 0 0
}}

{{Note|任意のフィールドにスペースが含まれる場合、[[#ファイルパスのスペース]] を見てください。}}

=== GPT パーティション UUID ===

{{ic|blkid}} を実行してパーティションの一覧を出力し、[[PARTUUID]] の値を引用符無しで使ってください:

{{hc|/etc/fstab|2=
# <device> <dir> <type> <options> <dump> <fsck>
PARTUUID=98a81274-10f7-40db-872a-03df048df366 / ext4 defaults 0 1
PARTUUID=d0d0d110-0a71-4ed6-936a-304969ea36af /boot vfat defaults,nodev,nosuid,noexec,fmask=0177,dmask=0077 0 2
PARTUUID=7280201c-fc5d-40f2-a9b2-466611d3d49e /home ext4 defaults 0 2
PARTUUID=039b6c1c-7553-4455-9537-1befbc9fbc5b none swap defaults 0 0
}}

== ヒントとテクニック ==

=== systemd による自動マウント ===

systemd のすべてのマウントオプションは {{man|5|systemd.mount}} を見てください。

==== ローカルパーティション ====

巨大なパーティションが存在する場合、''fsck'' によってそのパーティションがチェックされている間に、そのパーティションに依存しないサービスを起動できるようにすると効率が良くなるかもしれません。パーティションの {{ic|/etc/fstab}} エントリに以下のオプションを追加することでそのように設定できます:

x-systemd.automount

そのパーティションに最初にアクセスしたときに fsck とマウントを行うようになり、パーティションの準備ができるまでカーネルがそのパーティションへのファイルアクセスを全てバッファします。
この方法は、巨大な {{ic|/home}} パーティションがある場合などに適用できます。

{{Note|この設定はファイルシステムのタイプを {{ic|autofs}} にします。これは [[locate]] によってデフォルトで無視されます。}}

==== リモートファイルシステム ====

同じ設定はリモートファイルシステムのマウントにも適用できます。アクセスしたときにだけリモートファイルシステムをマウントしたい場合、{{ic|x-systemd.automount}} パラメータを使って下さい。さらに、{{ic|1=x-systemd.mount-timeout=}} オプションを使うことで、マウントコマンドが完了するまでの制限時間を指定できます。また、{{ic|_netdev}} オプションで systemd がネットワークに依存するマウントであることを認識してネットワークがオンラインになった後に順番を入れ替えます。

x-systemd.automount,x-systemd.mount-timeout=30,_netdev

==== 暗号化ファイルシステム ====

キーファイルによって暗号化されたサブの暗号化ファイルシステムがある場合も、{{ic|/etc/crypttab}} と {{ic|/etc/fstab}} の対応するエントリに {{ic|nofail}} パラメータを追加することができます。''systemd'' はブート時に cryptsetup サービスがファイルシステムのアンロックとマウントを完了するまで待たないようになり、default.target に到達した後でマウントを完了させるようにできます。これにより、ブート直後には必要ないサブのパーティションをアンロックするためにブートが遅延することを防ぐことができます。cryptsetup の設定方法は [[dm-crypt/システム設定#Non blocking mounting]]{{Broken section link}} を参照してください。

デフォルトではマウントサービスはパーティションが利用可能になるまで90秒しか待たないため、キーファイルを利用可能にするのに遅延が発生するとマウントが失敗する可能性があります。そうならないようにするには、マウントサービスがパーティションがアンロックされるまで永遠に待つようにするために {{ic|1=x-systemd.mount-timeout=0}} オプションを fstab に追加してください:

{{hc|/etc/fstab|2=
UUID=0a3407de-014b-458b-b5c1-848e92a327a3 /data ext4 defaults,nofail,x-systemd.device-timeout=0 0 2
}}

==== 自動アンマウント ====

{{ic|x-systemd.idle-timeout}} フラグを使うことで一定時間アイドル状態のときにタイムアウトするのを指定できます。例:

x-systemd.automount,x-systemd.idle-timeout=1min

上記の設定の場合、1分間操作がないと systemd によってアンマウントされます。

=== 外部デバイス ===

{{Accuracy|nofail オプションはここで説明されているようには動きません。[[:en:Talk:Fstab#3.2 External Device options]]}}

外部デバイスが存在する時はマウントし、存在しない場合は無視したい場合、{{ic|nofail}} オプションが必要です。これにより、起動時にエラーが発生するのを防ぐことができます。例えば:

{{hc|/etc/fstab|2=
LABEL=MyExternalDrive /media/backup jfs nofail,x-systemd.device-timeout=5 0 2
}}

{{ic|nofail}} オプションは {{ic|x-systemd.device-timeout}} オプションと組み合わせて使うのが最も効果的です。デフォルトのデバイスタイムアウトは 90 秒であるのが理由で、タイムアウトを再設定しなかった場合、{{ic|nofail}} だけが指定されている切断済みの外部デバイスのせいで起動時間が 90 秒長くなってしまいます。タイムアウトを 0 にはしないでください。0 は無限に待つことになります。

=== ファイルパスのスペース ===

{{ic|fstab}} ではスペースがフィールドの区切り文字として使用されているため、フィールド (''PARTLABEL''、''LABEL''、マウントポイント) にスペースが含まれている場合、これらのスペースをエスケープ文字 {{ic|\}} と3桁の8進数 {{ic|040}} に置き換えなければなりません:

{{hc|/etc/fstab|2=
UUID=47FA-4071 /home/username/Camera\040Pictures vfat defaults 0 0
LABEL=Storage\040drive /media/100\040GB\040(Storage) ext4 defaults,user 0 2
}}

=== atime オプション ===

以下は、ドライブのパフォーマンスに影響を与える可能性のあるアクセス時間オプションです。

* {{ic|strictatime}} オプションは、ファイルがアクセスされるたびにファイルのアクセス時間を更新します。これは、Linux がサーバーで使用される場合に特に有効です。デスクトップでの使用にはあまり価値がありません。{{ic|strictatime}} オプションの欠点は、ページキャッシュからファイルを読み取る(ドライブではなくメモリから読み取る)場合でも、書き込みが発生することです。
* {{ic|noatime}} オプションは、ファイルを読み取るたびにファイルアクセス時間をドライブに書き込むことを完全に無効にします。これは、最後に変更されてからファイルが読み取られたかどうかを知る必要があるアプリケーションを除き、ほぼすべてのアプリケーションでうまく機能します。このオプションが有効になっている場合、ファイルへの書き込み時間情報は、ファイルが書き込まれるたびに引き続き更新されます。
* {{ic|nodiratime}} オプションは、ディレクトリに対してのみファイルアクセス時間の書き込みを無効にし、他のファイルは引き続きアクセス時間が書き込まれます。{{Note|{{ic|noatime}} は {{ic|nodiratime}} を含みます。[https://lwn.net/Articles/244941/ 両方を指定する必要はありません。]}}
*{{ic|relatime}} は、以前のアクセス時間が現在の変更または変更時間よりも前の場合にのみアクセス時間を更新します。さらに、Linux 2.6.30以降、以前のアクセス時間が24時間以上前の場合、アクセス時間は常に更新されます。このオプションは、{{ic|defaults}} オプション、{{ic|atime}} オプション(カーネルのデフォルトである {{ic|relatime}} を使用することを意味します。{{man|8|mount}} および [https://lwn.net/Articles/244829/ Once upon atime] を参照)またはオプションがまったく指定されていない場合に使用されます。

[[Mutt]] や、最後に変更されてからファイルが読み取られたかどうかを知る必要がある他のアプリケーションを使用する場合、{{ic|noatime}} オプションは使用しないでください。{{ic|relatime}} オプションを使用することは許容され、パフォーマンスの向上も提供します。

カーネル4.0以降、別の関連オプションがあります:

* {{ic|lazytime}} は、inode タイムスタンプ(アクセス、変更、作成時間)の変更をメモリ内でのみ保持することにより、ディスクへの書き込みを減らします。オンディスクタイムスタンプは、(1)ファイルタイムスタンプに関係のない変更のためにファイルinodeを更新する必要がある場合、(2)ディスクへの同期が発生した場合、(3)削除されていない inode がメモリから削除された場合、または(4)メモリ内コピーが最後にディスクに書き込まれてから24時間以上経過した場合にのみ更新されます。
: {{Warning|システムがクラッシュした場合、ディスク上のアクセス時間や最終変更日時は最大で24時間ずれる可能性があります。}}

{{ic|lazytime}} オプションは、前述の {{ic|*atime}} オプションと "組み合わせて" 機能し、代替として機能しないことに注意してください。つまり、デフォルトでは {{ic|relatime}} ですが、プレーンな {{ic|relatime}} オプションと同じかそれ以下のディスク書き込みコストで {{ic|strictatime}} にすることもできます。

=== ルートパーティションの再マウント ===

何らかの理由で誤ってルートパーティションを読み込み専用でマウントしてしまった場合は、次のコマンドでルートパーティションを再マウントしてください:

# mount -o remount,rw /

=== GPT パーティションの自動マウント ===

UEFI/GPT を使用している場合、[https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Discoverable Partitions Specification] に従ってパーティショニングすることで、特定のパーティションを {{ic|/etc/fstab}} から省略することができ、{{man|8|systemd-gpt-auto-generator}} を使ってそのパーティションをマウントすることができます。[[systemd#GPT パーティションの自動マウント]] を見てください。

ルートボリュームのカスタムマウントオプションを指定するには、{{ic|/dev/gpt-auto-root}} をデバイス名として使用します:

{{hc|/etc/fstab|2=
/dev/gpt-auto-root / ext4 defaults,noatime 0 1
}}

ルートボリュームに対してカスタムのマウントオプションを指定するには、デバイス名に {{ic|/dev/gpt-auto-root}} を使用してください:

{{hc|/etc/fstab|2=
/dev/gpt-auto-root / ext4 defaults,noatime 0 1
}}

=== バインドマウント ===

{{ic|bind}} オプションにより、ディレクトリをリンクさせることができます:

{{hc|/etc/fstab|2=
# <device> <dir> <type> <options> <dump> <fsck>
UUID=94649E22649E06E0 /media/user/OS/ ntfs defaults,rw,errors=remount-ro 0 0
/media/user/OS/Users/user/Music/ /home/user/Music/ none defaults,bind 0 0
/media/user/OS/Users/user/Pictures/ /home/user/Pictures/ none defaults,bind 0 0
/media/user/OS/Users/user/Videos/ /home/user/Videos/ none defaults,bind 0 0
/media/user/OS/Users/user/Downloads/ /home/user/Downloads/ none defaults,bind 0 0
/media/user/OS/Users/user/Documents/ /home/user/Documents/ none defaults,bind 0 0
/media/user/OS/Users/user/projects/ /home/user/projects/windows/ none defaults,bind 0 0
}}

詳細は {{man|8|mount|Bind mount operation}} を見てください。

=== genfstab を使用して fstab を自動的に生成する ===

''genfstab'' ツールを使用して fstab ファイルを作成できます。詳細については、[[genfstab]] を参照してください。

=== GUI ユーティリティ ===

以下は、マウントポイントを変更する際に用いることのできるプログラムのリストです。Fstab で利用できる機能のうち一部は実装されていないかもしれませんが、最も利用される機能はすべて実装されており、作業がうんと楽になるかもしれません:

* {{App|[[wikipedia:GNOME Disks|GNOME Disks]]|ストレージデバイスを管理するための GNOME ユーティリティ。{{Grp|gnome}} に含まれています。|https://apps.gnome.org/DiskUtility/|{{Pkg|gnome-disk-utility}}}}
* {{App|KDE Partition Manager|コンピュータ上のディスク、パーティション、ファイルシステムの管理を補助するユーティリティ。{{Grp|kde-system}} に含まれています。|https://apps.kde.org/partitionmanager/|{{Pkg|partitionmanager}}}}

=== ユーザーのパーミッションと所有者を変更する ===

あるドライブのマウントをすべてのユーザーに許可したい場合、以下のマウントポイントオプションを fstab エントリに追加することを検討してください。

{{Note|これは、ファイルのパーミッション機能が無いファイルシステムに対しても用いられます。この場合、ドライブ全体の所有者とパーミッションは、そのドライブをマウントしたユーザーに設定されます。}}

* {{ic|users}} - 全てのユーザーは、(たとえ他の通常ユーザーがそのドライブをマウントしていたとしても) 対象のファイルシステムをマウント/アンマウントできるようになります。このオプションは、noexec、nosuid、nodev オプションも暗黙的に設定します (ただし、後続のオプションによって上書きされない限り。例えば、users,exec,dev,suid)。これを有効化するには {{ic|users}} をマウントオプションに追加してください。
* {{ic|user}} - 任意の通常ユーザーに対象のファイルシステムのマウントを許可します。ただし、同じユーザーしかそのファイルシステムをアンマウントできません。このオプションは、noexec、nosuid、nodev オプションも暗黙的に設定します (ただし、後続のオプションによって上書きされない限り。例えば、users,exec,dev,suid)。これを有効化するには {{ic|user}} をマウントオプションに追加してください。

FAT や exFAT のようにファイルのパーミッションが実装されていないファイルシステムの場合は、ドライブ全体及び保存されているファイルに対してユーザーとグループを明示的に設定することができます。特定のユーザーの ID は {{ic|/etc/passwd}} で調べられます。UID は passwd エントリの3番目、GID は4番目です。

* {{ic|uid}} - ドライブの所有者 ID を設定します
* {{ic|gid}} - ドライブのグループ ID を設定します

Ext4 や brtfs などパーミッション機能を持つファイルシステムの場合は、(ドライブをマウントしたユーザー以外の) 他のユーザーはドライブにアクセスできないかもしれません。{{ic|/path/to/drive/}} のパーみションを確認し、必要に応じてパーミッションを変更してください。

=== 変更を検証する ===

{{ic|findmnt --verify --verbose}} コマンドを使用して、fstab ファイル内の構文エラーや無効なオプションがないかを確認します。

== 参照 ==

* [https://docs.kernel.org/admin-guide/devices.html ブロックデバイスを含むデバイスリスト]
* [https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html Filesystem Hierarchy Standard]
* [https://www.askapache.com/optimize/super-speed-secrets/ TMPFS を使ってキャッシュとサイト速度を30倍に高速化]

{{TranslationStatus|Fstab|2025-07-04|838934}}

デスクトップ通知

2025-07-03T08:41:23Z

AshMyzk: TranslationStatus の時刻形式を合わせる

[[Category:X サーバー]]
[[Category:通知]]
[[Category:ソフトウェア一覧]]
[[en:Desktop notifications]]
[[zh-hans:桌面通知程序]]
{{Related articles start}}
{{Related|GTK}}
{{Related|Libcanberra}}
{{Related articles end}}
デスクトップ通知は、非同期に特定のイベントをユーザーに通知する小さくて控えめなポップアップダイアログです。

== Libnotify ==

{{Pkg|libnotify}} は {{man|1|notify-send}} ユーティリティや [[GTK]] と [[Qt]] のアプリケーションのサポートを提供する [https://specifications.freedesktop.org/notification-spec/latest/ Desktop Notifications Specification] の実装で特定のデスクトップに依存していません。この実装はすでに [[Evolution]] や [[Pidgin]] といった多くのオープンソースアプリによって使用されています。

{{Tip|利用可能なアイコンに関する概要は[https://specifications.freedesktop.org/icon-naming-spec/latest/ 仕様]にあります。}}

== 通知サーバー ==

[[#Libnotify|libnotify]] で送られた通知を受け取るには、通知サーバーが必要です。

=== ビルトイン ===

[[Cinnamon]]、[[Deepin]]、[[Enlightenment]]、[[GNOME]]、[[GNOME Flashback]] は独自の実装を用いて通知を表示します。これらの通知サーバーはアプリケーションからの通知を DBus 経由で受け取るためにログイン時に自動的に起動されるので、他の通知サーバーに置き換えることができない場合があります。

[[KDE Plasma]] では、システムトレイの設定を開き、システムサービスの項目から Notifications の横にあるドロップダウンを Disabled に変更することで、ビルトインの通知サーバーを無効化することができます。その後システム設定メニューで System / Autostart のところに新しい自動起動アプリケーションを追加することで、所望の通知サーバーを追加することができます。変更を適用するには一旦ログアウトし、ログインし直す必要があります。

=== スタンドアロン ===

他のデスクトップ環境では、通知サーバーは手動でインストールし、[[XDG Autostart]] などを使って起動する必要があります。

あるいは、通知サーバーを [[D-Bus]] サービスにすることで、通知サーバーを初めて呼び出した時に自動的に起動させることもできます。ほとんどの通知サーバーにはすでに dbus サービスが {{ic|/usr/share/dbus-1/services}} に用意されています。{{Pkg|notification-daemon}} などの一部の実装では、ユーザー [[D-Bus]] サービスのディレクトリ ({{ic|$XDG_DATA_HOME/dbus-1/services}}) 内に手動でサービスを作る必要があります:

{{hc|org.freedesktop.Notifications.service|2=
[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/lib/notification-daemon-1.0/notification-daemon
}}

アプリケーションが通知を送ると (つまり {{ic|org.freedesktop.Notifications}} にシグナルを送ると)、{{ic|/usr/lib/notification-daemon-1.0/notification-daemon}} がまだアクティブ化されていない場合、D-Bus によってアクティブ化されます。

通知サーバーは以下から選ぶことができます:

* {{App|Deadd Notification Center|Dunst にインスパイヤされた、通知センターが付いた通知デーモン。[https://github.com/phuhl/linux_notification_center/issues/255 2025年2月から開発が滞っています。]|https://github.com/phuhl/linux_notification_center|{{AUR|deadd-notification-center}}}}
* {{App|[[Dunst]]|[[dwm]] などのミニマルなウィンドウマネージャにうってつけの Linux 用の最小通知デーモン。1.6 から Wayland サポートがあります。|https://dunst-project.org/|{{Pkg|dunst}}}}
* {{App|fnott|wlroots ベースのコンポジタのための軽量な Wayland 向けの通知デーモン。キーボードによって操作可能。|https://codeberg.org/dnkl/fnott|{{Pkg|fnott}}}}
* {{App|LXQt Notification Daemon|[[LXQt]] の通知サーバー。|https://github.com/lxde/lxqt-notificationd|{{Pkg|lxqt-notificationd}}}}
* {{App|mako|[[Wayland]] 向けの軽量な通知サーバー。現時点では [[Sway]] と {{Pkg|river}} 上で動作します。|https://github.com/emersion/mako|{{Pkg|mako}}}}
* {{App|MATE Notification Daemon|[[MATE]] の通知サーバー。|https://github.com/mate-desktop/mate-notification-daemon/|{{Pkg|mate-notification-daemon}}}}
* {{App|Notification Daemon|オリジナルの通知サーバー。|https://gitlab.gnome.org/Archive/notification-daemon|{{Pkg|notification-daemon}}}}
:{{ic|/usr/lib/notification-daemon-1.0/notification-daemon}} で手動で起動できます。
* {{App|Notify OSD|Unity の通知サーバー。|https://launchpad.net/notify-osd|{{Pkg|notify-osd}}}}
* {{App|statnot|小さくて軽量な通知デーモン。ルートウィンドウのタイトルや標準出力、FIFO パイプなどに通知を出力できるので、タイル型ウィンドウマネージャと相性がとても良いです。|https://github.com/halhen/statnot|{{AUR|statnot}}}}
* {{App|swaync|[[Sway]] のためのシンプルな GTK ベースの通知デーモン。|https://github.com/ErikReider/SwayNotificationCenter|{{Pkg|swaync}}}}
* {{App|twmn|タイル型ウィンドウマネージャ向けの通知システム。|https://github.com/sboli/twmn|{{AUR|twmn-git}}}}
* {{App|wired|レイヤーブロックのカスタマイズ性が高い軽量な通知デーモン。Rust で書かれている。|https://github.com/Toqozz/wired-notify|{{AUR|wired}}}}
* {{App|Xfce Notification Daemon|[[Xfce]] の通知サーバー。|https://docs.xfce.org/apps/notifyd/start|{{Pkg|xfce4-notifyd}}}}
:{{ic|/usr/lib/xfce4/notifyd/xfce4-notifyd}} で手動で起動できます。
:{{Tip|xfce4-notifyd を設定するには、ターミナルから次のコマンドを実行してください: {{ic|xfce4-notifyd-config}}。}}

== ヒントとテクニック ==

=== 他のユーザーに通知を送る ===

{{man|1|systemd-run}} を使うことで (例えば root として実行されたバックグラウンドのスクリプトなどから)、他のユーザーのセッションに入り、そのユーザーに通知を送ることができます:

# systemd-run --machine=''target_user''@.host --user notify-send 'Hello world!' 'This is an example notification.'

もう一つの方法は {{Pkg|systembus-notify}} です。以下のコマンドは、{{ic|systembus-notify}} をセッション内に実行しているすべてのユーザーに通知を表示します:

$ dbus-send --system / net.nuetzlich.SystemNotifications.Notify 'string:Hello world!' 'string:This is an example notification.'

{{Tip|[[systemd#サービスの失敗を通知する]] で説明されているようにして、上記のコマンドを {{ic|ExecStart}} コマンドで実行することで、失敗したサービスを通知で知らせることもできます。}}

=== 以前の通知を置き換える ===

通知 ID がわかっている場合は、その通知を置き換えることができます。新しい通知リクエストで同じ ID が指定されている場合、常に古い通知が置き換えられます。(上記の libnotify バインディングはこれを自動的に処理します。) 残念ながら、notify-send はこの ID を報告しないため、CLI でこれを行うには代替ツールが必要です。有効な CLI ツールの 1 つは、[https://github.com/phuhl/notify-send.py notify-send.py] Python スクリプトです。これは、追加の ID レポート機能と置換機能を備えた Notify-Send 構文を提供します。

ただし、''一部の'' 通知サーバー (Notify-OSD など) では、notify-send で {{ic|string:x-canonical-private-synchronous:}} ヒントを使用して同じ結果を得ることができます。

たとえば、時間を表示する通知を取得するには:
{{bc|1=
while true; do
date=$(date)
notify-send "$date" -h string:x-canonical-private-synchronous:my-notification
sleep 1
done
}}

=== ボタンを追加する、通知の閉じる/クリックをリッスンする ===

[https://github.com/phuhl/notify-send.py notify-send.py] スクリプトを使用すると、アクションを使用してボタンを表示したり通知のデフォルトアクション (通常、ユーザーが通知をクリックした時に発生します) やクローズアクションをリッスンすることができます。''action-icons'' ヒントが true に設定されており、通知デーモンがこれをサポートしている場合、ボタンにはテキストの代わりにアイコンが表示されます。スクリプトは、対応するイベントが発生したときに、コマンドラインにアクション ID または "close" を出力します。デフォルトのアクション (クリック時) をリッスンするには、アクション識別子 "default" を使用する必要があります。

ボタンにアイコンを表示する例:
{{bc|1=
notify-send.py "Buttons" "Do you like em?" --hint boolean:action-icons:true --action yes:face-cool no:face-sick
}}

=== D-Bus サービスが同梱されている通知サーバーが複数ある場合 ===

[[#スタンドアロン|スタンドアロン]]章で説明した通り、ユーザーは D-Bus サービスを作成して通知サーバーを自動的に起動させることができます。しかし、一部の通知サーバーにはすでに D-Bus サービスファイルが同梱されています。複数の通知サーバーをインストールしていて、それらのうちどれかにサービスファイルが含まれている場合、問題が発生します。例えば、{{Pkg|dunst}} と {{Pkg|mako}} の両方をインストールして、使用するサーバーを明示的に指定しなかった場合、D-Bus はどちらか一方を勝手に選びます。そうならないようにするには、{{ic|org.freedesktop.Notifications.service}} ([[#スタンドアロン]] を参照) を作成して、使用したいサービスを指定することで、使用されるサービスをオーバーライドすることができます。ファイルの作成後は、セッションを再起動してください。

== トラブルシューティング ==

=== アプリケーションがちょうど 1 分間ハングする ===

アプリケーションが通知を表示しようとした際にハングしてしまう場合、通知サービスが自身の可用性を誤って D-Bus サービス経由で広告してしまっているのかもしれません。

たとえば、ユーザーが最近、{{Pkg|plasma-workspace}} を必要とする KDE コンポーネントをインストールしたが、まだ XFCE を実行しているとします。この場合、KDE 通知機能が優先されますが、ユーザーはそれを実行していません。アプリケーションはサービスの待機中にハングし、タイムアウト後に {{Pkg|xfce4-notifyd}} にフォールバックすることになります。

最もわかりやすいハングは、通知インディケータの調整スクロールでしょう。

このような場合、2つの通知ハンドラーが存在するはずです:

{{hc|$ find /usr/share/dbus-1/services/ -name '*Notif*'|
org.kde.plasma.Notifications.service
org.xfce.xfce4-notifyd.Notifications.service
}}

[[journal]] を見ると、これら2つのうちどちら一方が定期的に1分のタイムアウトで失敗しています:

{{hc|# journalctl -g notif|2=
Jul 01 09:40:49 laptop dbus-daemon[866]: [session uid=1000 pid=866] Activating service name='org.freedesktop.Notifications' requested by ':1.193' (uid=1000 pid=5432 comm="/usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/pa")
Jul 01 09:41:49 laptop plasma_waitforname[6093]: org.kde.knotifications: WaitForName: Service was not registered within timeout
Jul 01 09:41:49 laptop dbus-daemon[866]: [session uid=1000 pid=866] Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
}}

[[#D-Bus サービスが同梱されている通知サーバーが複数ある場合]] で説明されているように、使いたいサービスを指定すれば、問題は解決します。

== 参照 ==

* [https://gnome.pages.gitlab.gnome.org/libnotify/ Libnotify リファレンスマニュアル]
* [https://web.archive.org/web/20160313162757/http://milky.manishsinha.net/2009/03/29/working-with-libnotify/ C サンプル] (アーカイブされたバージョン)
* [https://www.devdungeon.com/content/desktop-notifications-linux-python Python の通知サンプル]
* [https://hashbang.fr/tutoriel-notify.html Python の通知サンプル] (フランス語の記事)

{{TranslationStatus|Desktop notifications|2025-07-03|839792}}

デスクトップ通知

2025-07-03T08:40:34Z

AshMyzk: /* アプリケーションがちょうど 1 分間ハングする */ 修正

デスクトップ通知

2025-07-03T08:39:09Z

AshMyzk: 同期

[[Category:X サーバー]]
[[Category:通知]]
[[Category:ソフトウェア一覧]]
[[en:Desktop notifications]]
[[zh-hans:桌面通知程序]]
{{Related articles start}}
{{Related|GTK}}
{{Related|Libcanberra}}
{{Related articles end}}
デスクトップ通知は、非同期に特定のイベントをユーザーに通知する小さくて控えめなポップアップダイアログです。

== Libnotify ==

{{Pkg|libnotify}} は {{man|1|notify-send}} ユーティリティや [[GTK]] と [[Qt]] のアプリケーションのサポートを提供する [https://specifications.freedesktop.org/notification-spec/latest/ Desktop Notifications Specification] の実装で特定のデスクトップに依存していません。この実装はすでに [[Evolution]] や [[Pidgin]] といった多くのオープンソースアプリによって使用されています。

{{Tip|利用可能なアイコンに関する概要は[https://specifications.freedesktop.org/icon-naming-spec/latest/ 仕様]にあります。}}

== 通知サーバー ==

[[#Libnotify|libnotify]] で送られた通知を受け取るには、通知サーバーが必要です。

=== ビルトイン ===

[[Cinnamon]]、[[Deepin]]、[[Enlightenment]]、[[GNOME]]、[[GNOME Flashback]] は独自の実装を用いて通知を表示します。これらの通知サーバーはアプリケーションからの通知を DBus 経由で受け取るためにログイン時に自動的に起動されるので、他の通知サーバーに置き換えることができない場合があります。

[[KDE Plasma]] では、システムトレイの設定を開き、システムサービスの項目から Notifications の横にあるドロップダウンを Disabled に変更することで、ビルトインの通知サーバーを無効化することができます。その後システム設定メニューで System / Autostart のところに新しい自動起動アプリケーションを追加することで、所望の通知サーバーを追加することができます。変更を適用するには一旦ログアウトし、ログインし直す必要があります。

=== スタンドアロン ===

他のデスクトップ環境では、通知サーバーは手動でインストールし、[[XDG Autostart]] などを使って起動する必要があります。

あるいは、通知サーバーを [[D-Bus]] サービスにすることで、通知サーバーを初めて呼び出した時に自動的に起動させることもできます。ほとんどの通知サーバーにはすでに dbus サービスが {{ic|/usr/share/dbus-1/services}} に用意されています。{{Pkg|notification-daemon}} などの一部の実装では、ユーザー [[D-Bus]] サービスのディレクトリ ({{ic|$XDG_DATA_HOME/dbus-1/services}}) 内に手動でサービスを作る必要があります:

{{hc|org.freedesktop.Notifications.service|2=
[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/lib/notification-daemon-1.0/notification-daemon
}}

アプリケーションが通知を送ると (つまり {{ic|org.freedesktop.Notifications}} にシグナルを送ると)、{{ic|/usr/lib/notification-daemon-1.0/notification-daemon}} がまだアクティブ化されていない場合、D-Bus によってアクティブ化されます。

通知サーバーは以下から選ぶことができます:

* {{App|Deadd Notification Center|Dunst にインスパイヤされた、通知センターが付いた通知デーモン。[https://github.com/phuhl/linux_notification_center/issues/255 2025年2月から開発が滞っています。]|https://github.com/phuhl/linux_notification_center|{{AUR|deadd-notification-center}}}}
* {{App|[[Dunst]]|[[dwm]] などのミニマルなウィンドウマネージャにうってつけの Linux 用の最小通知デーモン。1.6 から Wayland サポートがあります。|https://dunst-project.org/|{{Pkg|dunst}}}}
* {{App|fnott|wlroots ベースのコンポジタのための軽量な Wayland 向けの通知デーモン。キーボードによって操作可能。|https://codeberg.org/dnkl/fnott|{{Pkg|fnott}}}}
* {{App|LXQt Notification Daemon|[[LXQt]] の通知サーバー。|https://github.com/lxde/lxqt-notificationd|{{Pkg|lxqt-notificationd}}}}
* {{App|mako|[[Wayland]] 向けの軽量な通知サーバー。現時点では [[Sway]] と {{Pkg|river}} 上で動作します。|https://github.com/emersion/mako|{{Pkg|mako}}}}
* {{App|MATE Notification Daemon|[[MATE]] の通知サーバー。|https://github.com/mate-desktop/mate-notification-daemon/|{{Pkg|mate-notification-daemon}}}}
* {{App|Notification Daemon|オリジナルの通知サーバー。|https://gitlab.gnome.org/Archive/notification-daemon|{{Pkg|notification-daemon}}}}
:{{ic|/usr/lib/notification-daemon-1.0/notification-daemon}} で手動で起動できます。
* {{App|Notify OSD|Unity の通知サーバー。|https://launchpad.net/notify-osd|{{Pkg|notify-osd}}}}
* {{App|statnot|小さくて軽量な通知デーモン。ルートウィンドウのタイトルや標準出力、FIFO パイプなどに通知を出力できるので、タイル型ウィンドウマネージャと相性がとても良いです。|https://github.com/halhen/statnot|{{AUR|statnot}}}}
* {{App|swaync|[[Sway]] のためのシンプルな GTK ベースの通知デーモン。|https://github.com/ErikReider/SwayNotificationCenter|{{Pkg|swaync}}}}
* {{App|twmn|タイル型ウィンドウマネージャ向けの通知システム。|https://github.com/sboli/twmn|{{AUR|twmn-git}}}}
* {{App|wired|レイヤーブロックのカスタマイズ性が高い軽量な通知デーモン。Rust で書かれている。|https://github.com/Toqozz/wired-notify|{{AUR|wired}}}}
* {{App|Xfce Notification Daemon|[[Xfce]] の通知サーバー。|https://docs.xfce.org/apps/notifyd/start|{{Pkg|xfce4-notifyd}}}}
:{{ic|/usr/lib/xfce4/notifyd/xfce4-notifyd}} で手動で起動できます。
:{{Tip|xfce4-notifyd を設定するには、ターミナルから次のコマンドを実行してください: {{ic|xfce4-notifyd-config}}。}}

== ヒントとテクニック ==

=== 他のユーザーに通知を送る ===

{{man|1|systemd-run}} を使うことで (例えば root として実行されたバックグラウンドのスクリプトなどから)、他のユーザーのセッションに入り、そのユーザーに通知を送ることができます:

# systemd-run --machine=''target_user''@.host --user notify-send 'Hello world!' 'This is an example notification.'

もう一つの方法は {{Pkg|systembus-notify}} です。以下のコマンドは、{{ic|systembus-notify}} をセッション内に実行しているすべてのユーザーに通知を表示します:

$ dbus-send --system / net.nuetzlich.SystemNotifications.Notify 'string:Hello world!' 'string:This is an example notification.'

{{Tip|[[systemd#サービスの失敗を通知する]] で説明されているようにして、上記のコマンドを {{ic|ExecStart}} コマンドで実行することで、失敗したサービスを通知で知らせることもできます。}}

=== 以前の通知を置き換える ===

通知 ID がわかっている場合は、その通知を置き換えることができます。新しい通知リクエストで同じ ID が指定されている場合、常に古い通知が置き換えられます。(上記の libnotify バインディングはこれを自動的に処理します。) 残念ながら、notify-send はこの ID を報告しないため、CLI でこれを行うには代替ツールが必要です。有効な CLI ツールの 1 つは、[https://github.com/phuhl/notify-send.py notify-send.py] Python スクリプトです。これは、追加の ID レポート機能と置換機能を備えた Notify-Send 構文を提供します。

ただし、''一部の'' 通知サーバー (Notify-OSD など) では、notify-send で {{ic|string:x-canonical-private-synchronous:}} ヒントを使用して同じ結果を得ることができます。

たとえば、時間を表示する通知を取得するには:
{{bc|1=
while true; do
date=$(date)
notify-send "$date" -h string:x-canonical-private-synchronous:my-notification
sleep 1
done
}}

=== ボタンを追加する、通知の閉じる/クリックをリッスンする ===

[https://github.com/phuhl/notify-send.py notify-send.py] スクリプトを使用すると、アクションを使用してボタンを表示したり通知のデフォルトアクション (通常、ユーザーが通知をクリックした時に発生します) やクローズアクションをリッスンすることができます。''action-icons'' ヒントが true に設定されており、通知デーモンがこれをサポートしている場合、ボタンにはテキストの代わりにアイコンが表示されます。スクリプトは、対応するイベントが発生したときに、コマンドラインにアクション ID または "close" を出力します。デフォルトのアクション (クリック時) をリッスンするには、アクション識別子 "default" を使用する必要があります。

ボタンにアイコンを表示する例:
{{bc|1=
notify-send.py "Buttons" "Do you like em?" --hint boolean:action-icons:true --action yes:face-cool no:face-sick
}}

=== D-Bus サービスが同梱されている通知サーバーが複数ある場合 ===

[[#スタンドアロン|スタンドアロン]]章で説明した通り、ユーザーは D-Bus サービスを作成して通知サーバーを自動的に起動させることができます。しかし、一部の通知サーバーにはすでに D-Bus サービスファイルが同梱されています。複数の通知サーバーをインストールしていて、それらのうちどれかにサービスファイルが含まれている場合、問題が発生します。例えば、{{Pkg|dunst}} と {{Pkg|mako}} の両方をインストールして、使用するサーバーを明示的に指定しなかった場合、D-Bus はどちらか一方を勝手に選びます。そうならないようにするには、{{ic|org.freedesktop.Notifications.service}} ([[#スタンドアロン]] を参照) を作成して、使用したいサービスを指定することで、使用されるサービスをオーバーライドすることができます。ファイルの作成後は、セッションを再起動してください。

== トラブルシューティング ==

=== アプリケーションがちょうど 1 分間ハングする ===

アプリケーションが通知を表示しようとした際にハングしてしまう場合、通知サーバーが自身の可用性を誤って D-Bus サービスに広告してしまっているのかもしれません。

たとえば、ユーザーが最近、{{Pkg|plasma-workspace}} を必要とする KDE コンポーネントをインストールしたが、まだ XFCE を実行しているとします。この場合、KDE 通知機能が優先されますが、ユーザーはそれを実行していません。アプリケーションはサービスの待機中にハングし、タイムアウト後に {{Pkg|xfce4-notifyd}} にフォールバックすることになります。

最もわかりやすいハングは、通知インディケータの調整スクロールでしょう。

このような場合、2つの通知ハンドラーが存在するはずです:

{{hc|$ find /usr/share/dbus-1/services/ -name '*Notif*'|
org.kde.plasma.Notifications.service
org.xfce.xfce4-notifyd.Notifications.service
}}

[[ジャーナル]] を見ると、これら2つのうちどちら一方が定期的に1分のタイムアウトで失敗しています:

{{hc|# journalctl -g notif|2=
Jul 01 09:40:49 laptop dbus-daemon[866]: [session uid=1000 pid=866] Activating service name='org.freedesktop.Notifications' requested by ':1.193' (uid=1000 pid=5432 comm="/usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/pa")
Jul 01 09:41:49 laptop plasma_waitforname[6093]: org.kde.knotifications: WaitForName: Service was not registered within timeout
Jul 01 09:41:49 laptop dbus-daemon[866]: [session uid=1000 pid=866] Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
}}

[[#D-Bus サービスが同梱されている通知サーバーが複数ある場合]] で説明されているように、使いたいサービスを指定すれば、問題は解決します。

== 参照 ==

* [https://gnome.pages.gitlab.gnome.org/libnotify/ Libnotify リファレンスマニュアル]
* [https://web.archive.org/web/20160313162757/http://milky.manishsinha.net/2009/03/29/working-with-libnotify/ C サンプル] (アーカイブされたバージョン)
* [https://www.devdungeon.com/content/desktop-notifications-linux-python Python の通知サンプル]
* [https://hashbang.fr/tutoriel-notify.html Python の通知サンプル] (フランス語の記事)

{{TranslationStatus|Desktop notifications|2025/07/03|839792}}

ストレステスト

2025-06-29T07:05:50Z

AshMyzk: /* rasdaemon を使う */ 修正

[[Category:CPU]]
[[en:Stress testing]]
[[pl:Stress testing]]
{{Related articles start}}
{{Related|ベンチマーク}}
{{Related articles end}}
ストレステストとは、コンピュータ上で様々なワークロードを実行することでコンピュータの安定性を評価することです。オーバークロックされたハードウェアや電圧を落としたハードウェアの安定性を確実にチェックし、システムの熱的挙動 (例: 最大温度、スロットリング、ノイズレベル) を監視するためによく行われます。システムの様々な部分 (CPU、GPU、RAM、ストレージなど) を異なるタイプのワークロードを使ってストレステストするためのプログラムがいくつか存在します。

== ストレステストのタスク ==

以下の表では、テストの種類と全体的なワークロードの大きさに基づいて、いくつかのストレステストソフトウェアをリストアップしています。多くのユースケースにおける安定性を検証するために、複数の負荷を混ぜてストレステストを行うことが重要です。

{{Warning|この先に進む前に、システムの温度を監視する何らかの手段を確保しておくことが'''強く'''推奨されます。[[センサー]] を参照してください。}}

{| class="wikitable" align="center"
|-
! ワークロード !! テストされるハードウェア1 !! タスク !! 説明
|-
| rowspan="4" {{B|軽量2}}
|-
| CPU、ストレージ || パッチのアップデート || OpenWRT プロジェクトの数百ものカーネルパッチを更新するカスタムスクリプト。[[#OpenWRT のパッチ更新]] を参照。
|-
| CPU、ストレージ || ディスクイメージを書き込む。 || [[#イメージファイルへの書き込み]] を参照。
|-
| RAM || メモリに負荷をかける || [[#MemTest86+]] を参照。
|-
| rowspan="5" {{Y|現実的3}}
|-
| CPU、RAM、ストレージ || コンパイル || 並列コンパイルは CPU のストレステストを行うのに良い方法です。[[#GCC]] を参照。
|-
| CPU、RAM || 動画エンコード || {{Pkg|ffmpeg}}、{{Pkg|x264}}、{{Pkg|handbrake-cli}} などは、動画エンコードを行うために使用できます。[[#動画エンコード]] を参照。
|-
| CPU、RAM || 暗号通貨マイニング || {{Pkg|xmrig}} - {{ic|xmrig --stress}} は (CPU のモデルに基づいて) 異なる暗号通貨マイニングアルゴリズムを使用し、可能な限り最も高い負荷を掛けます。安定性と温度をテストするのに良い方法です。
|-
| GPU || 3D レンダリング || {{AUR|unigine-heaven}} はループで実行される GPU ベンチマークです。これは、GPU をストレステストするのに良い方法です。[[ベンチマーク#グラフィックス]] を参照。
|-
| rowspan="6" {{R|人工的4}}
| CPU、RAM、ストレージ || 合成ストレステスト || {{Pkg|stress}} は、CPU、メモリ、I/O、そしてディスクのシンプルなワークロードジェネレータです。C で実装されています。[[#stress]] を参照。
|-
| CPU、RAM || 素数計算 || {{AUR|mprime}} は大きな整数を因数分解します。CPU とメモリに負荷を掛けるのに良い方法です。[[#MPrime]] を参照。
|-
| CPU || 代数計算 || {{AUR|linpack}} - Linpack は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用してベクトルと行列の基本的な演算を行います。CPU に負荷を掛けて安定性をテストするのに良い方法です。[[#Linpack]] を参照。
|-
| CPU || 円周率の計算 || {{AUR|systester}} Systester は、小数点以下 128,000,000 桁まで円周率を計算できるマルチスレッドのソフトウェアです。システムの安定性をチェックする機能が組み込まれています。[[#Systester]] を参照。
|-
| RAM || メモリに負荷をかける || {{AUR|stressapptest}} はメモリインターフェイステストです。
|-
| CPU || 様々 || {{AUR|strain}} 多機能ストレステストユーティリティ。Rust 製。
|-
|}

* 1 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。
* 2 軽量なテストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。
* 3 現実的なテストは、現実世界におけるワークロードに基づいています。
* 4 人工的なテストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。

{{Tip|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}}

=== OpenWRT のパッチ更新 ===

低負荷なワークロードの安定性テストとしては、OpenWRT プロジェクトのパッチセットをアップデートするのが良いでしょう。以下のステップに従ってください。

{{Note|git や curl など、いくつかの依存パッケージが必要になります。その他のパッケージは {{Pkg|base-devel}} メタパッケージによってほとんど提供されるはずです。念の為に {{AUR|openwrt-devel}} メタパッケージをインストールすることができます。}}

git clone --depth 1 https://github.com/openwrt/openwrt.git
cd openwrt
mkdir -p staging_dir/host/bin
cp /usr/bin/sed ./staging_dir/host/bin
curl -Os https://raw.githubusercontent.com/KanjiMonster/maintainer-tools/master/update_kernel.sh
chmod +x update_kernel.sh
./update_kernel.sh -v -u 6.6

=== stress ===

{{Pkg|stress}} は、乱数の平方根を計算するループを実行して CPU に負荷を掛けます。例えば、複数のワーカーを同時に実行して CPU の全コアに負荷を掛けることができます。また、渡されたパラメータに応じてメモリや I/O、ディスクのワークロードを生成することもできます。[https://web.archive.org/web/20190629131203/http://people.seas.harvard.edu/~apw/stress/FAQ FAQ] には例や説明があります。

4 つのワーカーを生成して平方根の計算を行うには、以下のコマンドを使ってください:

$ stress --cpu 4

=== s-tui ===

{{Pkg|s-tui}} は、ターミナルベースの CPU ストレステスト及び監視ユーティリティです。CPU の使用率と温度を監視でき、CPU に負荷をかけることもできます。ターミナルグラフィカルインターフェイスで、1つの画面で必要な情報をすべて確認できるスイスナイフのようなツールです。

=== MPrime ===

MPrime (Windows と MacOS の実装では Prime95 とも) は、システムの安定性の事実上の指標の1つとして広く認知されています。耐久テスト (Torture Test) モードでは、MPrime は CPU に非常に大きな負荷を掛ける一連の計算を行い、得られた値を既知の良い値と比較します。

Linux の実装は {{AUR|mprime}} と呼ばれています。

mprime を実行するには、シェルを開き、"mprime" とタイプしてください:

$ mprime

{{Note|[[CPU 周波数スケーリング]]を使用している場合、プロセッサが最高のクロック倍率で動作するように手動で設定する必要がある場合があります。mprime は、倍数のステップアップを発生させないような nice 値を使用するからです。}}

ソフトウェアがロードされたら、最初の質問に 'N' と答えるだけで耐久テストが始まります:

{{bc|
Main Menu

1. Test/Primenet
2. Test/Worker threads
3. Test/Status
4. Test/Continue
5. Test/Exit
6. Advanced/Test
7. Advanced/Time
8. Advanced/P-1
9. Advanced/ECM
10. Advanced/Manual Communication
11. Advanced/Unreserve Exponent
12. Advanced/Quit Gimps
13. Options/CPU
14. Options/Preferences
15. Options/Torture Test
16. Options/Benchmark
17. Help/About
18. Help/About PrimeNet Server
}}

耐久テスト (メニューオプション 15) にはいくつかのオプションが存在します。

* CPU に負担をかけるには Small FFTs (オプション 1)。
* CPU とメモリコントローラをテストするには In-place large FFTs (オプション 2)。
* Blend (オプション 3) はデフォルトであり、CPU とメモリに負担をかけるハイブリッドモードです。

エラーが発生した場合は、標準出力と {{ic|~/results.txt}} の両方に出力されます。24 時間 Large FFTs を実行できなければ、多くの人はシステムが安定しているとはみなさないでしょう。

{{ic|~/results.txt}} の例です。6月26日からの2回の実行でハードウェア障害が発生していることが分かります。このケースでは、CPU のコア電圧が不足していることが原因です:

{{bc|
[Sun Jun 26 20:10:35 2011]
FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
[Sat Aug 20 10:50:45 2011]
Self-test 480K passed!
Self-test 480K passed!
[Sat Aug 20 11:06:02 2011]
Self-test 128K passed!
Self-test 128K passed!
[Sat Aug 20 11:22:10 2011]
Self-test 560K passed!
Self-test 560K passed!
...
}}

{{Note|メモリやメモリコントローラの問題を疑っている場合、まず Blend テストを実行してみるべきです。Small FFT テストは僅かなメモリしか使用しないからです。}}

=== Linpack ===

{{AUR|linpack}} は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクトルと行列の演算を行います。CPU に負荷をかけて安定性を調べる素晴らしい方法です (Intel CPU のみをサポートしています)。インストール後、{{ic|/usr/share/linpack/linpack.conf}} を {{ic|~/.config/linpack.conf}} にコピーし、システムのメモリ容量にあわせて設定を行ってください。

=== Systester ===

{{AUR|Systester}} (Windows 版では SuperPi) は、CLI と GUI の両方のバージョンが利用できます。1億2800桁の円周率を計算してシステムの安定性をテストし、エラーの確認も行います。2つの異なる計算アルゴリズムから選択できます: Borwein の2次収束の公式と Gauss-Legendre 公式です。後者は Windows の人気な SuperPi が使っている方法と同じです。

8スレッドを使用する CLI の例は以下のようになります:

$ systester-cli -gausslg 64M -threads 8

=== MemTest86+ ===

[https://www.memtest86.com/ MemTest86] (プロプライエタリ) か [https://www.memtest.org/ Memtest86+] (GPL) を使ってメモリ (RAM) をテストします。

* GPL のバージョンは [https://archlinux.org/download/ Arch Linux のインストールイメージ]で入手できます。以下でインストールできます:
** EFI システムの場合は {{Pkg|memtest86+-efi}}
** BIOS システムの場合は {{Pkg|memtest86+}}
* プロプライエタリなバージョンは BIOS をサポートしていません。{{AUR|memtest86-efi}} でインストールできます。
* インストールしたら、[[GRUB#メイン設定ファイルの生成|GRUB を更新]]することで、GRUB はパッケージを自動で検出し、MemTest86 を直接起動できるようになります。

{{Tip|
* バージョン履歴の信頼できるソースは memtest86.com の [https://www.memtest86.com/memtest86.html History of MemTest86] セクションです。特に "2002 - 2004" とそれ以降のセクションです。プロプライエタリな MemTest86 のバージョン 5 から 7 までは BIOS と UEFI の両方をサポートしていると主張していますが、単に古いバージョンと新しいバージョンをバンドルしているだけだということに注意してください。
* 通常、テストをエラー無しで 10 サイクル以上実行できたら十分です。
}}

=== イメージファイルへの書き込み ===

低負荷ワークロードでの安定性テストとしては、{{ic|dd}} を使ってイメージをフォーマットするのが良い方法でしょう。これは、物理ディスクでもループバックマウントのイメージでも可能です。以下のスクリプトは、マウントされたイメージを使用し、ループ1回毎に各コアを1つずつ使います。あなたのシステムと合致するようにスクリプト上部の変数を調整する必要があることに注意してください。デフォルトでは、このスクリプトは1コアあたり1回だけコマンドを実行します。for ループを変更することで、0 から n までのすべてのコアをスキャンするのではなく、既知の弱いコア上で実行するように容易にカスタマイズすることができます。以下のスクリプトを root として実行してください。

{{hc|format-test.sh|<nowiki>
#!/bin/bash

# イメージを保存するパスを定義します。読み書きを回避するために tmpfs でマウントされた場所が推奨されます。
img=/scratch/image.img

# マウントポイントを定義します。
mnt=/mnt/loop

# truncate に渡すサイズ引数。システムの空きメモリよりも小さい値にしてください。
# 利用可能なオプションは truncate --help を見てください。
size=40G

# デフォルトでは仮想コアの数よりも少ない 1 になります。必要に応じて手動で再定義してください。
max=$(($(nproc) - 1))

if [[ ! -f $img ]]; then
truncate -s $size $img
mkfs.ext4 $img
[[ -d $mnt ]] || mkdir -p $mnt
if ! mountpoint -q $mnt; then
mount -o loop $img $mnt || exit 1
fi
fi

for i in $(eval echo "{0..$max}"); do
echo "using core $i of $max"
taskset -c "$i" time dd if=/dev/zero of=$mnt/zerofill status=progress
done

umount $mnt
rm $img
</nowiki>}}

=== GCC ===

GCC (または他のコンパイラ) を使った並列コンパイルは、CPU とメモリに大きな負荷をかけます。I/O のボトルネックを回避するために、SSD 上または [[tmpfs]] 内でコンパイルしてください。

カーネルをコンパイルするのが良い例でしょう (詳細な手順は [[カーネル/Arch build system]] の記事を読んでください)。この場合、[[カーネル/Arch build system#コンパイル]] 章の部分で {{ic|1=makepkg -sf MAKEFLAGS="-j$(nproc)"}} を実行してください。

=== 動画エンコード ===

ほとんどの動画エンコーダは非常に良く並列化されており、CPU の計算能力をほぼ全て使うように設計されています。以下の例では、x265 を使ってノイズをエンコードし、結果を破棄します。CPU に大きな負荷がかかります。

ffmpeg -y -f rawvideo -video_size 1920x1080 -pixel_format yuv420p -framerate 60 -i /dev/urandom -c:v libx265 -preset placebo -f matroska /dev/null

== エラーを発見する ==

[[#MPrime]] や [[#Linpack]] といった一部のストレステストアプリケーションには、結果の不一致によるエラーを発見するための一貫性チェックが組み込まれています。ハードウェアの不安定性を測定するためのより一般的でよりシンプルな方法は、カーネル自体に存在します。

=== journalctl で手動で検索する ===

以下のようにクラッシュに関する journal をフィルターしてください:

# journalctl -k --grep=mce

=== rasdaemon を使う ===

あるいは、{{AUR|rasdaemon}} をビルドして、同梱されているサービスを[[起動]]する方法もあります。Rasdaemon はエラーを sqlite データベースに保持します。同梱されている {{ic|ras-mc-ctl}} バイナリでデータベースはクエリできます。

例:

# ras-mc-ctl --errors
No Memory errors.
No PCIe AER errors.
No ARM processor errors.
No Extlog errors.
No devlink errors.
MCE events:
1 2025-06-23 08:24:48 -0400 error: Corrected error, no action required., CPU 2, bank Load Store Unit (bank=0), mcg mcgstatus=0, mci CECC, mca DC data error type 2. Ext Err Code: 13 Memory Error 'mem-tx: evict, tx: data, level: L1', mcgcap=0x00000107, status=0x9c204000000d0175, addr=0x185dd56627, misc=0xd01a000100000000, walltime=0x68594791, cpu=0x00000002, cpuid=0x00b40f40, apicid=0x00000004, microcode=0x0b404032

=== コアまでエラーをトラッキングする ===

設定を最適化する際には、BIOS のオーバークロックのセクションで用いられるような文脈でのコア単位の安定性について理解しておくことが重要になります。一つのコアには複数の CPU が含まれていることもあります。

Ryzen 9950X (物理コア16個、CPU 32個) での以下のジャーナルのエラーを考えてみてください:

[Hardware Error]: Corrected error, no action required.
[Hardware Error]: CPU:5 (1a:44:0) MC0_STATUS[-|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0x9c204000000d0175
[Hardware Error]: Error Addr: 0x000000185d960d07
[Hardware Error]: IPID: 0x000000b000000000, Syndrome: 0x0000000b1a173405
[Hardware Error]: Load Store Unit Ext. Error Code: 13
[Hardware Error]: cache level: L1, tx: DATA, mem-tx: EV

以下のスクリプトは、物理コアから CPU へのマッピングリストを生成する際に使用できます:

{{hc|~/bin/gen_mapping.sh|2=
#!/bin/bash

file=/tmp/mapping.txt
phycores=$(( $(nproc) / 2 - 1 ))

echo "Core CPU" > $file
for ((i=0; i<=phycores; i++)); do
echo "$i $(cat /sys/devices/system/cpu/cpu$i/topology/core_cpus_list)" >> $file
done

column -t $file
}}

カーネルの ID で 5 と 21 の両 CPU が物理コア 5 にマップされていることがわかります:

Core CPU
0 0,16
1 1,17
2 2,18
3 3,19
4 4,20
5 5,21
6 6,22
7 7,23
8 8,24
9 9,25
10 10,26
11 11,27
12 12,28
13 13,29
14 14,30
15 15,31

{{TranslationStatus|Stress testing|2025-06-29|838960}}

ストレステスト

2025-06-29T07:04:00Z

AshMyzk: /* ストレステストのタスク */ 修正

[[Category:CPU]]
[[en:Stress testing]]
[[pl:Stress testing]]
{{Related articles start}}
{{Related|ベンチマーク}}
{{Related articles end}}
ストレステストとは、コンピュータ上で様々なワークロードを実行することでコンピュータの安定性を評価することです。オーバークロックされたハードウェアや電圧を落としたハードウェアの安定性を確実にチェックし、システムの熱的挙動 (例: 最大温度、スロットリング、ノイズレベル) を監視するためによく行われます。システムの様々な部分 (CPU、GPU、RAM、ストレージなど) を異なるタイプのワークロードを使ってストレステストするためのプログラムがいくつか存在します。

== ストレステストのタスク ==

以下の表では、テストの種類と全体的なワークロードの大きさに基づいて、いくつかのストレステストソフトウェアをリストアップしています。多くのユースケースにおける安定性を検証するために、複数の負荷を混ぜてストレステストを行うことが重要です。

{{Warning|この先に進む前に、システムの温度を監視する何らかの手段を確保しておくことが'''強く'''推奨されます。[[センサー]] を参照してください。}}

{| class="wikitable" align="center"
|-
! ワークロード !! テストされるハードウェア1 !! タスク !! 説明
|-
| rowspan="4" {{B|軽量2}}
|-
| CPU、ストレージ || パッチのアップデート || OpenWRT プロジェクトの数百ものカーネルパッチを更新するカスタムスクリプト。[[#OpenWRT のパッチ更新]] を参照。
|-
| CPU、ストレージ || ディスクイメージを書き込む。 || [[#イメージファイルへの書き込み]] を参照。
|-
| RAM || メモリに負荷をかける || [[#MemTest86+]] を参照。
|-
| rowspan="5" {{Y|現実的3}}
|-
| CPU、RAM、ストレージ || コンパイル || 並列コンパイルは CPU のストレステストを行うのに良い方法です。[[#GCC]] を参照。
|-
| CPU、RAM || 動画エンコード || {{Pkg|ffmpeg}}、{{Pkg|x264}}、{{Pkg|handbrake-cli}} などは、動画エンコードを行うために使用できます。[[#動画エンコード]] を参照。
|-
| CPU、RAM || 暗号通貨マイニング || {{Pkg|xmrig}} - {{ic|xmrig --stress}} は (CPU のモデルに基づいて) 異なる暗号通貨マイニングアルゴリズムを使用し、可能な限り最も高い負荷を掛けます。安定性と温度をテストするのに良い方法です。
|-
| GPU || 3D レンダリング || {{AUR|unigine-heaven}} はループで実行される GPU ベンチマークです。これは、GPU をストレステストするのに良い方法です。[[ベンチマーク#グラフィックス]] を参照。
|-
| rowspan="6" {{R|人工的4}}
| CPU、RAM、ストレージ || 合成ストレステスト || {{Pkg|stress}} は、CPU、メモリ、I/O、そしてディスクのシンプルなワークロードジェネレータです。C で実装されています。[[#stress]] を参照。
|-
| CPU、RAM || 素数計算 || {{AUR|mprime}} は大きな整数を因数分解します。CPU とメモリに負荷を掛けるのに良い方法です。[[#MPrime]] を参照。
|-
| CPU || 代数計算 || {{AUR|linpack}} - Linpack は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用してベクトルと行列の基本的な演算を行います。CPU に負荷を掛けて安定性をテストするのに良い方法です。[[#Linpack]] を参照。
|-
| CPU || 円周率の計算 || {{AUR|systester}} Systester は、小数点以下 128,000,000 桁まで円周率を計算できるマルチスレッドのソフトウェアです。システムの安定性をチェックする機能が組み込まれています。[[#Systester]] を参照。
|-
| RAM || メモリに負荷をかける || {{AUR|stressapptest}} はメモリインターフェイステストです。
|-
| CPU || 様々 || {{AUR|strain}} 多機能ストレステストユーティリティ。Rust 製。
|-
|}

* 1 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。
* 2 軽量なテストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。
* 3 現実的なテストは、現実世界におけるワークロードに基づいています。
* 4 人工的なテストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。

{{Tip|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}}

=== OpenWRT のパッチ更新 ===

低負荷なワークロードの安定性テストとしては、OpenWRT プロジェクトのパッチセットをアップデートするのが良いでしょう。以下のステップに従ってください。

{{Note|git や curl など、いくつかの依存パッケージが必要になります。その他のパッケージは {{Pkg|base-devel}} メタパッケージによってほとんど提供されるはずです。念の為に {{AUR|openwrt-devel}} メタパッケージをインストールすることができます。}}

git clone --depth 1 https://github.com/openwrt/openwrt.git
cd openwrt
mkdir -p staging_dir/host/bin
cp /usr/bin/sed ./staging_dir/host/bin
curl -Os https://raw.githubusercontent.com/KanjiMonster/maintainer-tools/master/update_kernel.sh
chmod +x update_kernel.sh
./update_kernel.sh -v -u 6.6

=== stress ===

{{Pkg|stress}} は、乱数の平方根を計算するループを実行して CPU に負荷を掛けます。例えば、複数のワーカーを同時に実行して CPU の全コアに負荷を掛けることができます。また、渡されたパラメータに応じてメモリや I/O、ディスクのワークロードを生成することもできます。[https://web.archive.org/web/20190629131203/http://people.seas.harvard.edu/~apw/stress/FAQ FAQ] には例や説明があります。

4 つのワーカーを生成して平方根の計算を行うには、以下のコマンドを使ってください:

$ stress --cpu 4

=== s-tui ===

{{Pkg|s-tui}} は、ターミナルベースの CPU ストレステスト及び監視ユーティリティです。CPU の使用率と温度を監視でき、CPU に負荷をかけることもできます。ターミナルグラフィカルインターフェイスで、1つの画面で必要な情報をすべて確認できるスイスナイフのようなツールです。

=== MPrime ===

MPrime (Windows と MacOS の実装では Prime95 とも) は、システムの安定性の事実上の指標の1つとして広く認知されています。耐久テスト (Torture Test) モードでは、MPrime は CPU に非常に大きな負荷を掛ける一連の計算を行い、得られた値を既知の良い値と比較します。

Linux の実装は {{AUR|mprime}} と呼ばれています。

mprime を実行するには、シェルを開き、"mprime" とタイプしてください:

$ mprime

{{Note|[[CPU 周波数スケーリング]]を使用している場合、プロセッサが最高のクロック倍率で動作するように手動で設定する必要がある場合があります。mprime は、倍数のステップアップを発生させないような nice 値を使用するからです。}}

ソフトウェアがロードされたら、最初の質問に 'N' と答えるだけで耐久テストが始まります:

{{bc|
Main Menu

1. Test/Primenet
2. Test/Worker threads
3. Test/Status
4. Test/Continue
5. Test/Exit
6. Advanced/Test
7. Advanced/Time
8. Advanced/P-1
9. Advanced/ECM
10. Advanced/Manual Communication
11. Advanced/Unreserve Exponent
12. Advanced/Quit Gimps
13. Options/CPU
14. Options/Preferences
15. Options/Torture Test
16. Options/Benchmark
17. Help/About
18. Help/About PrimeNet Server
}}

耐久テスト (メニューオプション 15) にはいくつかのオプションが存在します。

* CPU に負担をかけるには Small FFTs (オプション 1)。
* CPU とメモリコントローラをテストするには In-place large FFTs (オプション 2)。
* Blend (オプション 3) はデフォルトであり、CPU とメモリに負担をかけるハイブリッドモードです。

エラーが発生した場合は、標準出力と {{ic|~/results.txt}} の両方に出力されます。24 時間 Large FFTs を実行できなければ、多くの人はシステムが安定しているとはみなさないでしょう。

{{ic|~/results.txt}} の例です。6月26日からの2回の実行でハードウェア障害が発生していることが分かります。このケースでは、CPU のコア電圧が不足していることが原因です:

{{bc|
[Sun Jun 26 20:10:35 2011]
FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
[Sat Aug 20 10:50:45 2011]
Self-test 480K passed!
Self-test 480K passed!
[Sat Aug 20 11:06:02 2011]
Self-test 128K passed!
Self-test 128K passed!
[Sat Aug 20 11:22:10 2011]
Self-test 560K passed!
Self-test 560K passed!
...
}}

{{Note|メモリやメモリコントローラの問題を疑っている場合、まず Blend テストを実行してみるべきです。Small FFT テストは僅かなメモリしか使用しないからです。}}

=== Linpack ===

{{AUR|linpack}} は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクトルと行列の演算を行います。CPU に負荷をかけて安定性を調べる素晴らしい方法です (Intel CPU のみをサポートしています)。インストール後、{{ic|/usr/share/linpack/linpack.conf}} を {{ic|~/.config/linpack.conf}} にコピーし、システムのメモリ容量にあわせて設定を行ってください。

=== Systester ===

{{AUR|Systester}} (Windows 版では SuperPi) は、CLI と GUI の両方のバージョンが利用できます。1億2800桁の円周率を計算してシステムの安定性をテストし、エラーの確認も行います。2つの異なる計算アルゴリズムから選択できます: Borwein の2次収束の公式と Gauss-Legendre 公式です。後者は Windows の人気な SuperPi が使っている方法と同じです。

8スレッドを使用する CLI の例は以下のようになります:

$ systester-cli -gausslg 64M -threads 8

=== MemTest86+ ===

[https://www.memtest86.com/ MemTest86] (プロプライエタリ) か [https://www.memtest.org/ Memtest86+] (GPL) を使ってメモリ (RAM) をテストします。

* GPL のバージョンは [https://archlinux.org/download/ Arch Linux のインストールイメージ]で入手できます。以下でインストールできます:
** EFI システムの場合は {{Pkg|memtest86+-efi}}
** BIOS システムの場合は {{Pkg|memtest86+}}
* プロプライエタリなバージョンは BIOS をサポートしていません。{{AUR|memtest86-efi}} でインストールできます。
* インストールしたら、[[GRUB#メイン設定ファイルの生成|GRUB を更新]]することで、GRUB はパッケージを自動で検出し、MemTest86 を直接起動できるようになります。

{{Tip|
* バージョン履歴の信頼できるソースは memtest86.com の [https://www.memtest86.com/memtest86.html History of MemTest86] セクションです。特に "2002 - 2004" とそれ以降のセクションです。プロプライエタリな MemTest86 のバージョン 5 から 7 までは BIOS と UEFI の両方をサポートしていると主張していますが、単に古いバージョンと新しいバージョンをバンドルしているだけだということに注意してください。
* 通常、テストをエラー無しで 10 サイクル以上実行できたら十分です。
}}

=== イメージファイルへの書き込み ===

低負荷ワークロードでの安定性テストとしては、{{ic|dd}} を使ってイメージをフォーマットするのが良い方法でしょう。これは、物理ディスクでもループバックマウントのイメージでも可能です。以下のスクリプトは、マウントされたイメージを使用し、ループ1回毎に各コアを1つずつ使います。あなたのシステムと合致するようにスクリプト上部の変数を調整する必要があることに注意してください。デフォルトでは、このスクリプトは1コアあたり1回だけコマンドを実行します。for ループを変更することで、0 から n までのすべてのコアをスキャンするのではなく、既知の弱いコア上で実行するように容易にカスタマイズすることができます。以下のスクリプトを root として実行してください。

{{hc|format-test.sh|<nowiki>
#!/bin/bash

# イメージを保存するパスを定義します。読み書きを回避するために tmpfs でマウントされた場所が推奨されます。
img=/scratch/image.img

# マウントポイントを定義します。
mnt=/mnt/loop

# truncate に渡すサイズ引数。システムの空きメモリよりも小さい値にしてください。
# 利用可能なオプションは truncate --help を見てください。
size=40G

# デフォルトでは仮想コアの数よりも少ない 1 になります。必要に応じて手動で再定義してください。
max=$(($(nproc) - 1))

if [[ ! -f $img ]]; then
truncate -s $size $img
mkfs.ext4 $img
[[ -d $mnt ]] || mkdir -p $mnt
if ! mountpoint -q $mnt; then
mount -o loop $img $mnt || exit 1
fi
fi

for i in $(eval echo "{0..$max}"); do
echo "using core $i of $max"
taskset -c "$i" time dd if=/dev/zero of=$mnt/zerofill status=progress
done

umount $mnt
rm $img
</nowiki>}}

=== GCC ===

GCC (または他のコンパイラ) を使った並列コンパイルは、CPU とメモリに大きな負荷をかけます。I/O のボトルネックを回避するために、SSD 上または [[tmpfs]] 内でコンパイルしてください。

カーネルをコンパイルするのが良い例でしょう (詳細な手順は [[カーネル/Arch build system]] の記事を読んでください)。この場合、[[カーネル/Arch build system#コンパイル]] 章の部分で {{ic|1=makepkg -sf MAKEFLAGS="-j$(nproc)"}} を実行してください。

=== 動画エンコード ===

ほとんどの動画エンコーダは非常に良く並列化されており、CPU の計算能力をほぼ全て使うように設計されています。以下の例では、x265 を使ってノイズをエンコードし、結果を破棄します。CPU に大きな負荷がかかります。

ffmpeg -y -f rawvideo -video_size 1920x1080 -pixel_format yuv420p -framerate 60 -i /dev/urandom -c:v libx265 -preset placebo -f matroska /dev/null

== エラーを発見する ==

[[#MPrime]] や [[#Linpack]] といった一部のストレステストアプリケーションには、結果の不一致によるエラーを発見するための一貫性チェックが組み込まれています。ハードウェアの不安定性を測定するためのより一般的でよりシンプルな方法は、カーネル自体に存在します。

=== journalctl で手動で検索する ===

以下のようにクラッシュに関する journal をフィルターしてください:

# journalctl -k --grep=mce

=== rasdaemon を使う ===

あるいは、{{AUR|rasdaemon}} をビルドして、同梱されているサービスを[[起動]]する方法もあります。Rasdaemon はエラー sqlite データベースを保持します。同梱されている {{ic|ras-mc-ctl}} バイナリでデータベースはクエリできます。

例:

# ras-mc-ctl --errors
No Memory errors.
No PCIe AER errors.
No ARM processor errors.
No Extlog errors.
No devlink errors.
MCE events:
1 2025-06-23 08:24:48 -0400 error: Corrected error, no action required., CPU 2, bank Load Store Unit (bank=0), mcg mcgstatus=0, mci CECC, mca DC data error type 2. Ext Err Code: 13 Memory Error 'mem-tx: evict, tx: data, level: L1', mcgcap=0x00000107, status=0x9c204000000d0175, addr=0x185dd56627, misc=0xd01a000100000000, walltime=0x68594791, cpu=0x00000002, cpuid=0x00b40f40, apicid=0x00000004, microcode=0x0b404032

=== コアまでエラーをトラッキングする ===

設定を最適化する際には、BIOS のオーバークロックのセクションで用いられるような文脈でのコア単位の安定性について理解しておくことが重要になります。一つのコアには複数の CPU が含まれていることもあります。

Ryzen 9950X (物理コア16個、CPU 32個) での以下のジャーナルのエラーを考えてみてください:

[Hardware Error]: Corrected error, no action required.
[Hardware Error]: CPU:5 (1a:44:0) MC0_STATUS[-|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0x9c204000000d0175
[Hardware Error]: Error Addr: 0x000000185d960d07
[Hardware Error]: IPID: 0x000000b000000000, Syndrome: 0x0000000b1a173405
[Hardware Error]: Load Store Unit Ext. Error Code: 13
[Hardware Error]: cache level: L1, tx: DATA, mem-tx: EV

以下のスクリプトは、物理コアから CPU へのマッピングリストを生成する際に使用できます:

{{hc|~/bin/gen_mapping.sh|2=
#!/bin/bash

file=/tmp/mapping.txt
phycores=$(( $(nproc) / 2 - 1 ))

echo "Core CPU" > $file
for ((i=0; i<=phycores; i++)); do
echo "$i $(cat /sys/devices/system/cpu/cpu$i/topology/core_cpus_list)" >> $file
done

column -t $file
}}

カーネルの ID で 5 と 21 の両 CPU が物理コア 5 にマップされていることがわかります:

Core CPU
0 0,16
1 1,17
2 2,18
3 3,19
4 4,20
5 5,21
6 6,22
7 7,23
8 8,24
9 9,25
10 10,26
11 11,27
12 12,28
13 13,29
14 14,30
15 15,31

{{TranslationStatus|Stress testing|2025-06-29|838960}}

ストレステスト

2025-06-29T07:00:59Z

AshMyzk: 同期

[[Category:CPU]]
[[en:Stress testing]]
[[pl:Stress testing]]
{{Related articles start}}
{{Related|ベンチマーク}}
{{Related articles end}}
ストレステストとは、コンピュータ上で様々なワークロードを実行することでコンピュータの安定性を評価することです。オーバークロックされたハードウェアや電圧を落としたハードウェアの安定性を確実にチェックし、システムの熱的挙動 (例: 最大温度、スロットリング、ノイズレベル) を監視するためによく行われます。システムの様々な部分 (CPU、GPU、RAM、ストレージなど) を異なるタイプのワークロードを使ってストレステストするためのプログラムがいくつか存在します。

== ストレステストのタスク ==

以下の表では、テストの種類と全体的なワークロードの大きさに基づいて、いくつかのストレステストソフトウェアをリストアップしています。多くのユースケースにおける安定性を検証するために、複数の負荷を混ぜてストレステストを行うことが重要です。

{{Warning|この先に進む前に、システムの温度を監視する何らかの手段を確保しておくことが'''強く'''推奨されます。[[センサー]] を参照してください。}}

{| class="wikitable" align="center"
|-
! ワークロード !! テストされるハードウェア1 !! タスク !! 説明
|-
| rowspan="4" {{B|軽量2}}
|-
| CPU、ストレージ || パッチのアップデート || OpenWRT プロジェクトの数百ものカーネルパッチを更新するカスタムスクリプト。[[#OpenWRT のパッチ更新]] を参照。
|-
| CPU、ストレージ || ディスクイメージを書き込む。 || [[#イメージファイルへの書き込み]] を参照。
|-
| RAM || メモリに負荷をかける || [[#MemTest86+]] を参照。
|-
| rowspan="5" {{Y|現実的3}}
|-
| CPU、RAM、ストレージ || コンパイル || 並列コンパイルは CPU のストレステストを行うのに良い方法です。[[#GCC]] を参照。
|-
| CPU、RAM || 動画エンコード || {{Pkg|ffmpeg}}、{{Pkg|x264}}、{{Pkg|handbrake-cli}} などは、動画エンコードを行うために使用できます。[[#動画エンコード]] を参照。
|-
| CPU、RAM || 暗号通貨マイニング || {{Pkg|xmrig}} - {{ic|xmrig --stress}} は (CPU のモデルに基づいて) 異なる暗号通貨マイニングアルゴリズムを使用し、可能な限り最も高い負荷を掛けます。安定性と温度をテストするのに良い方法です。
|-
| GPU || 3D レンダリング || {{AUR|unigine-heaven}} はループで実行される GPU ベンチマークです。これは、GPU をストレステストするのに良い方法です。[[ベンチマーク#グラフィックス]] を参照。
|-
| rowspan="6" {{R|人工的4}}
| CPU、RAM、ストレージ || 合成ストレステスト || {{Pkg|stress}} は、CPU、メモリ、I/O、そしてディスクのシンプルなワークロードジェネレータです。C で実装されています。[[#stress]] を参照。
|-
| CPU、RAM || 素数計算 || {{AUR|mprime}} は大きな整数を因数分解します。CPU とメモリに負荷を掛けるのに良い方法です。[[#MPrime]] を参照。
|-
| CPU || 代数計算 || {{AUR|linpack}} - Linpack は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用してベクトルと行列の基本的な演算を行います。CPU に負荷を掛けて安定性をテストするのに良い方法です。[[#Linpack]] を参照。
|-
| CPU || 円周率の計算 || {{AUR|systester}} Systester は、小数点以下 128,000,000 桁まで円周率を計算できるマルチスレッドのソフトウェアです。システムの安定性をチェックする機能が組み込まれています。[[#Systester]] を参照。
|-
| RAM || メモリに負荷をかける || {{AUR|stressapptest}} はメモリインターフェイステストです。
|-
| CPU || 様々 || {{AUR|strain}} 多機能ストレステストユーティリティ。Rust 製。
|-
|}

* 1 主なテスト対象。事実上、すべてのテストには CPU と RAM も含まれます。
* 2 Light テストでは、(電力/熱が制限されるという点で) コンポーネントにあまり負荷をかけません。これらのテストは、特に低電圧なシステムでの低い電力レベル (P ステート) におけるハードウェアの挙動をテストするのに役立ちます。
* 3 Realistic テストは、現実世界におけるワークロードに基づいています。
* 4 Synthetic テストは、ハードウェアに可能な限りに大きな負荷をかけるように明示的に設計されており、現実世界におけるワークロードを代表するようなものではない場合があります。

{{Tip|システムの安定性を確かなものにするために、様々な温度条件下でストレステストを長い時間 (数時間から数日) 実行することが推奨されます。例えば、室温が冬や夏で大きく異なる場合、これを考慮すべきです。}}

=== OpenWRT のパッチ更新 ===

低負荷なワークロードの安定性テストとしては、OpenWRT プロジェクトのパッチセットをアップデートするのが良いでしょう。以下のステップに従ってください。

{{Note|git や curl など、いくつかの依存パッケージが必要になります。その他のパッケージは {{Pkg|base-devel}} メタパッケージによってほとんど提供されるはずです。念の為に {{AUR|openwrt-devel}} メタパッケージをインストールすることができます。}}

git clone --depth 1 https://github.com/openwrt/openwrt.git
cd openwrt
mkdir -p staging_dir/host/bin
cp /usr/bin/sed ./staging_dir/host/bin
curl -Os https://raw.githubusercontent.com/KanjiMonster/maintainer-tools/master/update_kernel.sh
chmod +x update_kernel.sh
./update_kernel.sh -v -u 6.6

=== stress ===

{{Pkg|stress}} は、乱数の平方根を計算するループを実行して CPU に負荷を掛けます。例えば、複数のワーカーを同時に実行して CPU の全コアに負荷を掛けることができます。また、渡されたパラメータに応じてメモリや I/O、ディスクのワークロードを生成することもできます。[https://web.archive.org/web/20190629131203/http://people.seas.harvard.edu/~apw/stress/FAQ FAQ] には例や説明があります。

4 つのワーカーを生成して平方根の計算を行うには、以下のコマンドを使ってください:

$ stress --cpu 4

=== s-tui ===

{{Pkg|s-tui}} は、ターミナルベースの CPU ストレステスト及び監視ユーティリティです。CPU の使用率と温度を監視でき、CPU に負荷をかけることもできます。ターミナルグラフィカルインターフェイスで、1つの画面で必要な情報をすべて確認できるスイスナイフのようなツールです。

=== MPrime ===

MPrime (Windows と MacOS の実装では Prime95 とも) は、システムの安定性の事実上の指標の1つとして広く認知されています。耐久テスト (Torture Test) モードでは、MPrime は CPU に非常に大きな負荷を掛ける一連の計算を行い、得られた値を既知の良い値と比較します。

Linux の実装は {{AUR|mprime}} と呼ばれています。

mprime を実行するには、シェルを開き、"mprime" とタイプしてください:

$ mprime

{{Note|[[CPU 周波数スケーリング]]を使用している場合、プロセッサが最高のクロック倍率で動作するように手動で設定する必要がある場合があります。mprime は、倍数のステップアップを発生させないような nice 値を使用するからです。}}

ソフトウェアがロードされたら、最初の質問に 'N' と答えるだけで耐久テストが始まります:

{{bc|
Main Menu

1. Test/Primenet
2. Test/Worker threads
3. Test/Status
4. Test/Continue
5. Test/Exit
6. Advanced/Test
7. Advanced/Time
8. Advanced/P-1
9. Advanced/ECM
10. Advanced/Manual Communication
11. Advanced/Unreserve Exponent
12. Advanced/Quit Gimps
13. Options/CPU
14. Options/Preferences
15. Options/Torture Test
16. Options/Benchmark
17. Help/About
18. Help/About PrimeNet Server
}}

耐久テスト (メニューオプション 15) にはいくつかのオプションが存在します。

* CPU に負担をかけるには Small FFTs (オプション 1)。
* CPU とメモリコントローラをテストするには In-place large FFTs (オプション 2)。
* Blend (オプション 3) はデフォルトであり、CPU とメモリに負担をかけるハイブリッドモードです。

エラーが発生した場合は、標準出力と {{ic|~/results.txt}} の両方に出力されます。24 時間 Large FFTs を実行できなければ、多くの人はシステムが安定しているとはみなさないでしょう。

{{ic|~/results.txt}} の例です。6月26日からの2回の実行でハードウェア障害が発生していることが分かります。このケースでは、CPU のコア電圧が不足していることが原因です:

{{bc|
[Sun Jun 26 20:10:35 2011]
FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file.
[Sat Aug 20 10:50:45 2011]
Self-test 480K passed!
Self-test 480K passed!
[Sat Aug 20 11:06:02 2011]
Self-test 128K passed!
Self-test 128K passed!
[Sat Aug 20 11:22:10 2011]
Self-test 560K passed!
Self-test 560K passed!
...
}}

{{Note|メモリやメモリコントローラの問題を疑っている場合、まず Blend テストを実行してみるべきです。Small FFT テストは僅かなメモリしか使用しないからです。}}

=== Linpack ===

{{AUR|linpack}} は BLAS (Basic Linear Algebra Subprograms) ライブラリを使用して基本的なベクトルと行列の演算を行います。CPU に負荷をかけて安定性を調べる素晴らしい方法です (Intel CPU のみをサポートしています)。インストール後、{{ic|/usr/share/linpack/linpack.conf}} を {{ic|~/.config/linpack.conf}} にコピーし、システムのメモリ容量にあわせて設定を行ってください。

=== Systester ===

{{AUR|Systester}} (Windows 版では SuperPi) は、CLI と GUI の両方のバージョンが利用できます。1億2800桁の円周率を計算してシステムの安定性をテストし、エラーの確認も行います。2つの異なる計算アルゴリズムから選択できます: Borwein の2次収束の公式と Gauss-Legendre 公式です。後者は Windows の人気な SuperPi が使っている方法と同じです。

8スレッドを使用する CLI の例は以下のようになります:

$ systester-cli -gausslg 64M -threads 8

=== MemTest86+ ===

[https://www.memtest86.com/ MemTest86] (プロプライエタリ) か [https://www.memtest.org/ Memtest86+] (GPL) を使ってメモリ (RAM) をテストします。

* GPL のバージョンは [https://archlinux.org/download/ Arch Linux のインストールイメージ]で入手できます。以下でインストールできます:
** EFI システムの場合は {{Pkg|memtest86+-efi}}
** BIOS システムの場合は {{Pkg|memtest86+}}
* プロプライエタリなバージョンは BIOS をサポートしていません。{{AUR|memtest86-efi}} でインストールできます。
* インストールしたら、[[GRUB#メイン設定ファイルの生成|GRUB を更新]]することで、GRUB はパッケージを自動で検出し、MemTest86 を直接起動できるようになります。

{{Tip|
* バージョン履歴の信頼できるソースは memtest86.com の [https://www.memtest86.com/memtest86.html History of MemTest86] セクションです。特に "2002 - 2004" とそれ以降のセクションです。プロプライエタリな MemTest86 のバージョン 5 から 7 までは BIOS と UEFI の両方をサポートしていると主張していますが、単に古いバージョンと新しいバージョンをバンドルしているだけだということに注意してください。
* 通常、テストをエラー無しで 10 サイクル以上実行できたら十分です。
}}

=== イメージファイルへの書き込み ===

低負荷ワークロードでの安定性テストとしては、{{ic|dd}} を使ってイメージをフォーマットするのが良い方法でしょう。これは、物理ディスクでもループバックマウントのイメージでも可能です。以下のスクリプトは、マウントされたイメージを使用し、ループ1回毎に各コアを1つずつ使います。あなたのシステムと合致するようにスクリプト上部の変数を調整する必要があることに注意してください。デフォルトでは、このスクリプトは1コアあたり1回だけコマンドを実行します。for ループを変更することで、0 から n までのすべてのコアをスキャンするのではなく、既知の弱いコア上で実行するように容易にカスタマイズすることができます。以下のスクリプトを root として実行してください。

{{hc|format-test.sh|<nowiki>
#!/bin/bash

# イメージを保存するパスを定義します。読み書きを回避するために tmpfs でマウントされた場所が推奨されます。
img=/scratch/image.img

# マウントポイントを定義します。
mnt=/mnt/loop

# truncate に渡すサイズ引数。システムの空きメモリよりも小さい値にしてください。
# 利用可能なオプションは truncate --help を見てください。
size=40G

# デフォルトでは仮想コアの数よりも少ない 1 になります。必要に応じて手動で再定義してください。
max=$(($(nproc) - 1))

if [[ ! -f $img ]]; then
truncate -s $size $img
mkfs.ext4 $img
[[ -d $mnt ]] || mkdir -p $mnt
if ! mountpoint -q $mnt; then
mount -o loop $img $mnt || exit 1
fi
fi

for i in $(eval echo "{0..$max}"); do
echo "using core $i of $max"
taskset -c "$i" time dd if=/dev/zero of=$mnt/zerofill status=progress
done

umount $mnt
rm $img
</nowiki>}}

=== GCC ===

GCC (または他のコンパイラ) を使った並列コンパイルは、CPU とメモリに大きな負荷をかけます。I/O のボトルネックを回避するために、SSD 上または [[tmpfs]] 内でコンパイルしてください。

カーネルをコンパイルするのが良い例でしょう (詳細な手順は [[カーネル/Arch build system]] の記事を読んでください)。この場合、[[カーネル/Arch build system#コンパイル]] 章の部分で {{ic|1=makepkg -sf MAKEFLAGS="-j$(nproc)"}} を実行してください。

=== 動画エンコード ===

ほとんどの動画エンコーダは非常に良く並列化されており、CPU の計算能力をほぼ全て使うように設計されています。以下の例では、x265 を使ってノイズをエンコードし、結果を破棄します。CPU に大きな負荷がかかります。

ffmpeg -y -f rawvideo -video_size 1920x1080 -pixel_format yuv420p -framerate 60 -i /dev/urandom -c:v libx265 -preset placebo -f matroska /dev/null

== エラーを発見する ==

[[#MPrime]] や [[#Linpack]] といった一部のストレステストアプリケーションには、結果の不一致によるエラーを発見するための一貫性チェックが組み込まれています。ハードウェアの不安定性を測定するためのより一般的でよりシンプルな方法は、カーネル自体に存在します。

=== journalctl で手動で検索する ===

以下のようにクラッシュに関する journal をフィルターしてください:

# journalctl -k --grep=mce

=== rasdaemon を使う ===

あるいは、{{AUR|rasdaemon}} をビルドして、同梱されているサービスを[[起動]]する方法もあります。Rasdaemon はエラー sqlite データベースを保持します。同梱されている {{ic|ras-mc-ctl}} バイナリでデータベースはクエリできます。

例:

# ras-mc-ctl --errors
No Memory errors.
No PCIe AER errors.
No ARM processor errors.
No Extlog errors.
No devlink errors.
MCE events:
1 2025-06-23 08:24:48 -0400 error: Corrected error, no action required., CPU 2, bank Load Store Unit (bank=0), mcg mcgstatus=0, mci CECC, mca DC data error type 2. Ext Err Code: 13 Memory Error 'mem-tx: evict, tx: data, level: L1', mcgcap=0x00000107, status=0x9c204000000d0175, addr=0x185dd56627, misc=0xd01a000100000000, walltime=0x68594791, cpu=0x00000002, cpuid=0x00b40f40, apicid=0x00000004, microcode=0x0b404032

=== コアまでエラーをトラッキングする ===

設定を最適化する際には、BIOS のオーバークロックのセクションで用いられるような文脈でのコア単位の安定性について理解しておくことが重要になります。一つのコアには複数の CPU が含まれていることもあります。

Ryzen 9950X (物理コア16個、CPU 32個) での以下のジャーナルのエラーを考えてみてください:

[Hardware Error]: Corrected error, no action required.
[Hardware Error]: CPU:5 (1a:44:0) MC0_STATUS[-|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0x9c204000000d0175
[Hardware Error]: Error Addr: 0x000000185d960d07
[Hardware Error]: IPID: 0x000000b000000000, Syndrome: 0x0000000b1a173405
[Hardware Error]: Load Store Unit Ext. Error Code: 13
[Hardware Error]: cache level: L1, tx: DATA, mem-tx: EV

以下のスクリプトは、物理コアから CPU へのマッピングリストを生成する際に使用できます:

{{hc|~/bin/gen_mapping.sh|2=
#!/bin/bash

file=/tmp/mapping.txt
phycores=$(( $(nproc) / 2 - 1 ))

echo "Core CPU" > $file
for ((i=0; i<=phycores; i++)); do
echo "$i $(cat /sys/devices/system/cpu/cpu$i/topology/core_cpus_list)" >> $file
done

column -t $file
}}

カーネルの ID で 5 と 21 の両 CPU が物理コア 5 にマップされていることがわかります:

Core CPU
0 0,16
1 1,17
2 2,18
3 3,19
4 4,20
5 5,21
6 6,22
7 7,23
8 8,24
9 9,25
10 10,26
11 11,27
12 12,28
13 13,29
14 14,30
15 15,31

{{TranslationStatus|Stress testing|2025-06-29|838960}}

アドバンスドフォーマット

2025-06-29T06:19:02Z

AshMyzk: 同期

[[Category:ストレージ]]
[[en:Advanced Format]]
[[es:Advanced Format]]
[[hu:Advanced Format]]
[[ru:Advanced Format]]
[[tr:Advanced Format]]
[[zh-hans:先进格式化]]
ハードディスクドライブ (HDD) における最小の物理記憶単位は[[Wikipedia:ja:ディスクセクタ|セクタ]]です。ソリッドステートドライブ (SSD) ではページがこれと等価です。[https://www.oo-software.com/en/docs/whitepaper/whitepaper_ssd.pdf] ストレージデバイスのファームウェアは物理セクタを、ソフトウェアが操作できる論理セクタに抽象化します。論理セクタのサイズは、ディスク上のアドレッシング可能な最小単位のサイズとなります。

{{Note|ソフトウェアとドキュメントではストレージの種類に依らずに "セクタ" と "ブロック" を同じ意味で使用していることがあります。}}

; 物理セクタサイズ: これは、物理ストレージデバイスがアトミックに書き込めるとする最小単位です。HDD の場合、これはプラッタにおけるセクタの実際のサイズです。従来、HDD の物理セクタサイズは 512 バイトでした。つまり、各セクタは 512 バイトのデータを格納できることを意味します。しかし、[[Wikipedia:Advanced Format#History|アドバンスドフォーマット]] HDD の登場により、物理セクタサイズは 4096 バイト (4 KiB) に増え、誤り訂正機能が向上しました。SSD は NAND フラッシュメモリの実際のページサイズ (典型的には 4 KiB から 16 KiB ) を公開せず、報告される物理セクタサイズは論理セクタサイズと同じです。NVMe SSD の場合は、利用可能であれば、Atomic Write Unit Power Fail (AWUPF) パラメータの値が使用されます。
; 論理セクタサイズ: 論理セクタサイズ (別名、オペレーティングシステムセクタサイズ) は、オペレーティングシステムとアプリケーションに公開されるセクタサイズを表します。ソフトウェアのレベルでストレージデバイスに読み書きする際に用いられるセクタサイズです。論理セクタサイズは物理セクタサイズと異なる可能性があります。例えば、物理セクタサイズが 4096 バイトのアドバンスドフォーマット HDD は、古いシステムとアプリケーションとの互換性のために、依然として 512 バイトの論理セクタサイズを使用する場合があります。

異なる "レイヤー" (つまり、デバイス、スタックブロックデバイス、ファイルシステム) は、同じセクタサイズを使用するべきです。そうしないと、ファームウェアの変換レイヤーからのマッピングプロセス (通常は透過的ですが) で回避可能なオーバーヘッドが発生します。

現在の物理セクタサイズと論理セクタサイズは [[lsblk]] で見られます:

{{Accuracy|以下のどちらのコマンド ({{ic|lsblk}} と {{ic|cat /sys/class...}}) も NVMe ドライブ (もしかすると全 SSD) の物理セクタサイズを正確に提供せず、代わりに論理セクタサイズを報告してしまいます。}}

{{hc|$ lsblk -td|
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sda 0 4096 0 4096 4096 1 mq-deadline 64 128 0B
nvme1n1 0 4096 0 4096 4096 0 none 1023 128 0B
nvme0n1 0 4096 0 4096 4096 0 none 1023 128 0B
}}

{{ic|PHY-SEC}} は物理セクタサイズを、{{ic|LOG-SEC}} は論理セクタサイズを指します。

あるいは、以下の sysfs エントリから特定のドライブのセクタサイズを読み取ることができます:

$ cat /sys/class/block/''drive''/queue/physical_block_size
$ cat /sys/class/block/''drive''/queue/logical_block_size

セクタサイズは、[[fdisk]]、[[smartctl]]、そして [[hdparm]] の出力からも得られます。

== セクタサイズを変更する ==

{{Warning|ドライブのセクタサイズを変更すると、ドライブ上の全データが不可逆的に削除されます。}}

一部の NVMe ドライブと "エンタープライズ" SATA ハードディスクドライブでは、それぞれ標準の NVMe コマンド (NVM Command Set Specification 1.0 及びそれ以降の {{ic|Format NVM}}) か ATA コマンド (ATA Command Set - 4 及びそれ以降の {{ic|SET SECTOR CONFIGURATION EXT}}) を使って、報告されるセクタサイズを変更することができます。ハードディスクドライブの場合、最適なパフォーマンスを得るために物理セクタサイズとマッチするように論理セクタサイズを変更します。一方、NVMe ソリッドステートドライブの場合、論理セクタサイズと物理セクタサイズの両方が変更されます。

大抵、SATA ソリッドステートドライブはセクタサイズの変更をサポートしていません。例外は、報告される物理セクタサイズを変更できるが、論理セクタサイズは変更できない特定の Intel SATA SSD です。[https://superuser.com/q/982680] 報告される物理セクタサイズを変更するには [[#Intel]] に従ってください。

ドライブのセクタサイズの変更は、低レベルなフォーマットが必要になる複雑なプロセスです。代替案として、ドライブ上にファイルシステムを作成する際にセクタサイズを手動で指定して最適なパフォーマンスを得ることができます。[[#dm-crypt]] と [[#ファイルシステム]] を見てください。

=== アドバンスドフォーマットハードディスクドライブ ===

[[hdparm]] ユーティリティを使うことで、アドバンスドフォーマットハードディスクドライブのセクタサイズを変更できるかどうか調べることができます:

# hdparm -I /dev/sd''X'' {{!}} grep 'Sector size:'

{{Note|USB で接続されたドライブの場合、USB ブリッジが [[Wikipedia:SCSI / ATA Translation|SAT (SCSI/ATA Translation)]] (ANSI INCITS 431-2007) をサポートしている必要があります。}}

Sector Configuration Log に複数の論理セクタサイズが表示されるアドバンスドフォーマットドライブでは、それらのリストが表示されます:

{{bc|
Logical Sector size: 512 bytes [ Supported: 512 4096 ]
Physical Sector size: 4096 bytes
}}

複数の変更可能な論理セクタサイズをサポートしていないハードディスクドライブでは、現在のセクタサイズだけが報告されます。例えば、アドバンスドフォーマット 512e ドライブの場合:

{{bc|
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
}}

これらの種類のドライブで最適なパフォーマンスを得るには、[[#dm-crypt]] セクタサイズまたは[[#ファイルシステム]]のブロックサイズが少なくとも 4096 バイトであり、かつ 4096 バイト境界にアライメントされている必要があります。

アドバンスドフォーマット 4Kn ドライブの場合:

{{bc|
Logical Sector size: 4096 bytes
Physical Sector size: 4096 bytes
}}

4Kn ドライブでは、何も設定せずとも最適な設定になっており、パーティショニングやフォーマットの際に特別な考慮は必要ありません。そのまま使用することができます。

SATA HDD が複数の論理セクタサイズとオプションの ATA コマンド {{ic|SET SECTOR CONFIGURATION EXT}} をサポートしている場合 (基本的に「エンタープライズ」クラスと呼ばれるような HDD でのみ利用できます)、''hdparm'' を使ってサポートされているセクタサイズから選択することができます。論理セクタサイズを 4096 バイト (つまり、4Kn) に設定するには、以下を実行してください:

# hdparm --set-sector-size 4096 --please-destroy-my-drive /dev/sd''X''

その後、''hdparm'' は論理セクタサイズが 4096 バイトであると報告するはずです:

{{hc|# hdparm -I /dev/sd''X'' {{!}} grep 'Sector size:'|
Logical Sector size: 4096 bytes [ Supported: 512 4096 ]
Physical Sector size: 4096 bytes
}}

=== NVMe ソリッドステートドライブ ===

ほとんどの[[ソリッドステートドライブ]] (SSD) は、論理ブロックアドレスサイズが 512 バイトであると報告します。たとえ、それより大きなサイズ (典型的には 4 KiB、8 KiB、またはそれ以上) を物理的に使用していたとしてもです。

[[NVMe]] ドライブのフォーマットされた論理ブロックアドレスサイズ (FLBAS) を確認するには、{{Pkg|nvme-cli}} ユーティリティで ''Identify Namespace'' コマンドを使ってください:

{{hc|# nvme id-ns -H /dev/nvme0n1 {{!}} grep "Relative Performance"|
LBA Format 0 : Metadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good (in use)
LBA Format 1 : Metadata Size: 0 bytes - Data Size: 4096 bytes - Relative Performance: 0x1 Better
}}

* {{ic|Metadata Size}} は、論理ブロックアドレス (LBA) 毎の追加メタデータのバイト数です。これは Linux ではあまり良くサポートされていないため、この値が 0 であるフォーマットを選ぶのが最適です。
* {{ic|Relative Performance}} はそのフォーマットのパフォーマンスを示します: ''degraded''、''good''、''better''、''best'' のどれかです。

[[smartctl]] も、サポートされている論理ブロックアドレスサイズを表示できますが、ユーザフレンドリーな説明は提供しません。例:

{{hc|# smartctl -c /dev/nvme0n1|
...
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 2
1 - 4096 0 1
}}

{{Warning|1=4K セクタをサポートしていると報告するが、有効化すると散発的に (特に大きなランダム読み込み負荷が掛かる時に) 不安定になるような NVMe SSD もあります。[https://bbs.archlinux.org/viewtopic.php?pid=2238884#p2238884][https://halestrom.net/darksleep/blog/054_nvme/] 失ったらまずいデータを保存する前に、新しい設定を徹底的にテストしてください。この問題が発生した場合は、512 セクタの設定に戻せば大丈夫です。}}

論理ブロックアドレスサイズを変更するには、{{ic|nvme format}} を使い、{{ic|--lbaf}} パラメータで好ましい値を指定してください:

{{hc|1=# nvme format --lbaf=1 /dev/nvme0n1|2=
You are about to format nvme0n1, namespace 0x1.
WARNING: Format may irrevocably delete this device's data.
You have 10 seconds to press Ctrl-C to cancel this operation.

Use the force [--force] option to suppress this warning.
Sending format operation ...
Success formatting namespace:1
}}

この処理には数秒しかかからないはずです。

{{Note|パーティショニングの際は以下の [[#パーティションのアライメント]] に従ってください。さもないと、パフォーマンス上の利点が水の泡になります。}}

{{Accuracy|電源状態や BIOS の設定をいじる前に、ネイティブの {{ic|nvme}} コマンドを使って操作ログを確認したり、{{ic|nvme reset}} ''など''を使ってコントローラをソフトリセットしたりすることをお勧めします。}}

2020年より前のドライブは、POST の最後に "security freeze" を発行する非標準的なシステムで使用する場合、{{ic|Format NVM}} コマンドをブロックする可能性があります。[https://github.com/linux-nvme/nvme-cli/issues/816][https://forums.lenovo.com/topic/findpost/1300/5043069/5167342] {{ic|nvme format}} が失敗する場合、[[systemd#電源管理|システムをサスペンド]]してみて ([[電源管理/サスペンドとハイバネート#サスペンドの方法を変更する|S0ix ではなく S3 スリープを使用]]してください)、復帰後に {{ic|nvme format}} をもう一度実行してみてください。[https://github.com/linux-nvme/nvme-cli/issues/84][https://forums.sandisk.com/t/sn750-cannot-format-using-the-nvme-command/253702]

=== メーカー固有のプログラムを使う ===

上記の汎用ユーティリティでセクタサイズを変更できない場合、ドライブのメーカーのユーティリティを使用すれば変更できる場合があります。

==== Intel ====

Intel の場合は、[https://downloadcenter.intel.com/download/29337/Intel-Memory-and-Storage-Tool-CLI-Command-Line-Interface-?product=83425 Intel Memory and Storage (MAS) Tool] ({{AUR|intel-mas-cli-tool}}) で {{ic|1=-set PhysicalSectorSize=4096}} オプションを使用してください。報告される物理セクササイズのみが変わり、論理セクタサイズは同じままであることに注意してください。

{{Note|Intel の SSD 事業が SK Hynix に買収されて Solidigm ブランドになって以降、Intel MAS は SSD を管理するために使用できなくなりました (Optane 製品を除く)。Solidigm は、Intel MAS が提供していた機能を持つ {{AUR|solidigm-sst-storage-tool-cli}} を提供しています。[[ソリッドステートドライブ/NVMe#Intel/Solidigm]] を参照してください。}}

==== Seagate ====

Seagate の場合、{{AUR|openseachest}} を使ってください。

すべてのドライブをスキャンし、適切なものを探してください。そして、見つけたドライブの情報を表示してください:

# openSeaChest_Basics --scan
# openSeaChest_Basics -d /dev/sd''X'' -i

ドライブの情報が出力されるはずです。シリアル番号を確認してください。

そのドライブによってサポートされている論理ブロックサイズを確認してください:

# openSeaChest_Format -d /dev/sd''X'' --showSupportedFormats

4096 が一覧に載っている場合、論理セクタサイズを 4096 バイトに変更できます:

# openSeaChest_Format -d /dev/sd''X'' --setSectorSize=4096 --confirm this-will-erase-data

このコマンドは完了するまで2分かかります。その後、ドライブは 4 KiB ネイティブセクタサイズを使用するようになります。

== パーティションのアライメント ==

パーティションを正しくアライメントすることで、読み込み・変更・書き込みの過剰なサイクルを回避できます。家庭用のコンピュータでは、各パーティションの開始位置とサイズを 1 MiB (1 048 576 バイト) 境界にアライメントするのが一般的です。これは、一般的に使用されているすべてのサイズ (1 MiB、512 KiB、128 KiB、4 KiB、512 B) で割り切ることができるので、一般的なページサイズとブロックサイズのシナリオすべてをカバーします。

{{Warning|パーティションのアライメントを誤ると、dm-crypt/LUKS で 4096 バイトセクタを使用できなくなります。[https://lore.kernel.org/dm-crypt/fe8cd3b4-6d50-66d3-375c-254e278a6443@gmail.com/] を見てください。}}

* [[fdisk|fdisk、cfdisk、sfdisk]] はアライメントを自動的に管理します。
* [[GPT fdisk|gdisk と cgdisk]] はアライメントを自動的に管理します。
** ''sgdisk'' はデフォルトで、パーティションの開始位置のみをアライメントします。パーティションのサイズや終了位置のアライメントも有効化するには、{{ic|-I}}/{{ic|--align-end}} オプションを使ってください。
* [[Parted#アライメント|Parted]] はパーティションの開始位置のみをアライメントし、サイズと終了位置はアライメントしません。パーティションを作成するときは、パーティションの終了位置をメビバイトかより大きな IEC 2進接頭辞で指定するようにしてください。

[https://github.com/crysman/check-partitions-alignment checkpartitionsalignment.sh] は、[[Parted]] と awk を使ってアライメントをチェックする bash スクリプトです。

== dm-crypt ==

[[Cryptsetup]] 2.4.0 では、{{ic|luksFormat}} は自動的に LUKS2 フォーマットに最適な暗号化セクタサイズを検出します [https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.4/v2.4.0-ReleaseNotes]。

しかし、これが機能するには、デバイスが正しいデフォルトセクタサイズを報告する必要があります。[[#セクタサイズを変更する]] を見てください。

{{Tip|Cryptsetup は、暗号化パフォーマンスのためにドライブのセクササイズを 4096 バイトに変更することを強く推奨しています。[https://cdn.kernel.org/pub/linux/utils/cryptsetup/v2.8/v2.8.0-ReleaseNotes]}}

{{ic|cryptsetup luksFormat}} を使用したあとに、LUKS2 ボリュームによって使用されているセクタサイズを確認できます:

# cryptsetup luksDump ''device'' | grep sector

デフォルトのセクタサイズが正しくない場合、4 KiB のセクタサイズをそれ以外のデフォルトのオプションで LUKS2 コンテナを強制的に作成することができます:

# cryptsetup luksFormat --sector-size=4096 ''device''

このコマンドは、要求されたサイズがデバイスと一致しない場合、エラーでアボートします:

{{bc|# cryptsetup luksFormat --sector-size 4096 ''device''
(...)
Verify passphrase:
Device size is not aligned to requested sector size.
}}

{{Note|実際のドライブが 4 KiB 物理セクタを使用しているときにこのコマンドが失敗する可能性がある理由については、[https://gitlab.com/cryptsetup/cryptsetup/-/issues/585 cryptsetup issue 585] を見てください。}}

デバイスを間違ったセクタサイズで暗号化してしまった場合、以下のコマンドでそのデバイスを再暗号化できます:

{{Warning|含まれているファイルシステムが、4096 バイトおよびその倍数のブロックサイズを持っていなければなりません。さもないと、ファイルシステムが破壊されます。}}

# cryptsetup reencrypt --sector-size=4096 ''device''

== ファイルシステム ==

4Kn ディスク (物理セクタサイズが 4096 バイト、論理セクタサイズが 4096 バイト) では、全ての ''mkfs'' ユーティリティは 4096 バイトのブロックサイズを使用します。512e ディスク (物理セクタサイズが 4096、論理セクタサイズが 512 バイト) と 512n ディスク (物理セクタサイズが 512 バイト、論理セクタサイズが 512 バイト) では、''mkfs'' ユーティリティはそれぞれ異なる動作をします。

{| class="wikitable"
|+ 非 4Kn ディスクにおけるファイルシステムのブロックサイズ (バイト単位)
! ''mkfs'' ユーティリティ !! 512e ディスク !! 512n ディスク
|-
| ''mkfs.bcachefs'' || {{G|4096}} || {{O|[https://github.com/koverstreet/bcachefs/issues/765 512]}}
|-
| {{man|8|mkfs.btrfs}} || {{G|4096}} || {{G|4096}}
|-
| {{man|8|mkfs.exfat}} || {{G|4096}} || {{O|512}}
|-
| {{man|8|mkfs.ext4}} || {{G|4096}}1 || {{G|4096}}1
|-
| {{man|8|mkfs.fat}} || {{R|512}} || {{O|512}}
|-
| {{man|8|mkfs.f2fs}} || {{G|4096}} || {{G|4096}}
|-
| {{man|8|mkfs.jfs}} || {{G|4096}} || {{G|4096}}
|-
| {{man|8|mkfs.nilfs2}} || {{G|4096}} || {{G|4096}}
|-
| {{man|8|mkfs.ntfs}} || {{R|[https://github.com/tuxera/ntfs-3g/issues/133 512]}} || {{O|512}}
|-
| {{man|8|mkfs.reiserfs|url=https://manpages.debian.org/unstable/reiserfsprogs/mkfs.reiserfs.8.en.html}} || {{G|4096}} || {{G|4096}}
|-
| {{man|8|mkfs.udf}} || {{R|512}} || {{O|512}}
|-
| {{man|8|mkfs.xfs}} || {{G|4096}} || {{O|512}}
|-
| {{man|8|mkswap}} || {{G|4096}} || {{G|4096}}
|-
| {{man|8|zpool-create|url=}} || {{R|512}} || {{O|512}}
|}

# {{man|8|mkfs.ext4}} はデフォルトで、512 MiB 未満のファイルシステムに対しては 1024 バイトセクタを、512 MiB 以上のファイルシステムに対しては 4096 バイトのセクタを使用します。

ストレージデバイスが正しいセクタサイズを報告しない場合は、物理セクタサイズに応じてパーティションを明示的にフォーマットできます。

特に、ファームウェアによって管理されている ''シングル磁気記録方式'' (Singled Magnetic Recording: SMR) ドライブは、物理セクタサイズが 4096 バイトの場合に 512 バイトの論理セクタサイズを使用すると、深刻な悪影響を受けます。これらのドライブは、パフォーマンスの異なる書き込み領域が存在し、アイドル時にはリマッピングの再割当てが発生しますが、高負荷なアクティブ書き込み (例: RAID resilvering、バックアップ、小さなファイルを大量に書き込む、rsync など) 時には、ファイルシステムのセクタサイズが異なる場合に書き込み速度が1桁の MB/s まで落ちる可能性があります。これは、高パフォーマンスな書き込み領域が枯渇し、単一の領域上でセクタの変換レイヤに高負荷がかかるからです。

{{Note|x86_64 システムでは、Linux は 4 KiB より大きいブロックサイズのファイルシステムをマウントすることができません。詳細と現在の進捗状況については [https://kernelnewbies.org/KernelProjects/large-block-size Large block sizes (LBS)] を参照してください。}}

以下は、4096 バイトのセクタを明示的に設定する例です:

* [[Bcachefs]]: {{bc|1=# bcachefs format --block_size=4096 /dev/''device0'' /dev/''deviceN'' --replicas=''n''}}
* exFAT: {{bc|# mkfs.exfat -s 4096 /dev/''device''}}
* [[ext4]]: {{bc|# mkfs.ext4 -b 4096 /dev/''device''}}
* [[FAT]]: {{bc|# mkfs.fat -S 4096 /dev/''device''}}
* [[NTFS-3G]]: {{bc|# mkfs.ntfs -Q -s 4096 /dev/''device''}}
* UDF: {{bc|# mkfs.udf -b 4096 /dev/''device''}}
* [[XFS]]: {{bc|1=# mkfs.xfs -s size=4096 /dev/''device''}}
* [https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html#advanced-format-disks ZFS]: {{bc|1=# zpool create -o ashift=12 ''poolname'' raidz ''device0'' … ''deviceN''}}

== 既知の問題 ==

=== Syslinux と FAT ===

[[Syslinux]] は 512 バイト以外のセクタサイズの FAT ファイルシステムをサポートしていません。

=== systemd-homed ===

[[systemd-homed]] は、4096 バイトセクタサイズの 4Kn ドライブと LUKS 上では動作しません。Systemd のイシュー [https://github.com/systemd/systemd/issues/30393 30393] と [https://github.com/systemd/systemd/issues/30394 30394] を参照してください。

== 参照 ==

* [https://www.anandtech.com/Show/Index/2888 Western Digital’s Advanced Format: The 4K Sector Transition Begins]
* [https://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf White paper entitled "Advanced Format Technology."]
* HDD のアライメントを間違えると、読み込み/書き込みのパフォーマンスが劣化します。具体的な例は [https://linuxconfig.org/linux-wd-ears-advanced-format] を見てください。

{{TranslationStatus|Advanced Format|2025-06-29|839284}}

Uwsm

2025-06-29T06:02:08Z

AshMyzk: Universal Wayland Session Managerへの転送ページ

#REDIRECT[[Universal Wayland Session Manager]]

カテゴリ:Wayland

2025-06-29T06:00:43Z

AshMyzk: ページの作成:「Category:グラフィカルユーザーインターフェイス {{Cat main|Wayland}}」

[[Category:グラフィカルユーザーインターフェイス]]
{{Cat main|Wayland}}

Wayland

2025-06-29T06:00:03Z

AshMyzk: 同期

[[Category:Wayland]]
[[de:Wayland]]
[[en:Wayland]]
[[es:Wayland]]
[[pt:Wayland]]
[[ru:Wayland]]
[[zh-hans:Wayland]]
{{Related articles start}}
{{Related|カーネルモード設定}}
{{Related|Xorg}}
{{Related|スクリーンショットの取得#Wayland}}
{{Related articles end}}

[https://wayland.freedesktop.org/ Wayland] はディスプレイサーバープロトコルです。[[Xorg|X Window System]] の後継となることを目指しています。[[Wikipedia:Wayland_(display_server_protocol)#Differences_between_Wayland_and_X|Wikipedia に Wayland と Xorg の比較]] が掲載されています。

Wayland プロトコルを使用するディスプレイサーバは、[[Wikipedia:ja:コンポジット型ウィンドウマネージャ|コンポジット型ウィンドウマネージャ]] としても機能するため、'''コンポジタ''' と呼ばれます。以下に[[#コンポジタ|Wayland コンポジタのリスト]]を示します。

ネイティブな X11 アプリケーションをシームレスに動かすための後方互換性として、[[#Xwayland|Xwayland]] を使うことができます。これは Wayland に X サーバを提供します。

== 要件 ==

ほとんどの Wayland コンポジタは、[[カーネルモード設定]]を利用しているシステムでのみ動作します。Wayland それ自体はグラフィカルな環境を提供しません。ゆえに、Wayland に加えてコンポジタ (以下のセクションを参照)、あるいは、コンポジタを含むデスクトップ環境 (例: [[GNOME]]、[[Plasma]]) が必要となります。

GPU ドライバと Wayland コンポジタは、同一のバッファ API に対応している場合に互換性があります。主要な API は2つ存在します: [[Wikipedia:Generic Buffer Management|GBM]] と [https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API EGLStreams] です。

{| class="wikitable"
! バッファ API !! GPU ドライバーのサポート !! Wayland コンポジタのサポート
|-
| GBM || [[NVIDIA]] < 495* 以外の全てのドライバー || 全て
|-
| EGLStreams || [[NVIDIA]] || [[GNOME]]
|}

: * Nvidia ≥ 495 は EGLStreams と GBM の両方をサポートします。[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-495.44-Linux-Driver]

NVIDIA が GBM のサポートを導入して以来、NVIDIA ≥ 495 で多くのコンポジタ (Mutter と KWin を含む) がデフォルトで GBM を使用し始めました。GBM は一般的にベターでより幅広いサポートがあると考えられています。EGLStreams がサポートされていた理由は、NVIDIA GPU をプロプライエタリドライバで Wayland 下で使用する代替の方法を NVIDIA が提供しなかったからだけです。さらに、GBM が NVIDIA に導入された後、KWin は [https://invent.kde.org/plasma/kwin/-/merge_requests/1638 EGLStreams のサポートを打ち切りました]。

人気なデスクトップ環境/コンポジタと、NVIDIA によってまだサポートされている GPU を使用している場合、おそらくすでに GBM バックエンドを使用しています。確認するには、次を実行してください: {{ic|journalctl -b 0 --grep "renderer for"}}。GBM をバックエンドとして強制的に使用させるには、次の[[環境変数]]を設定してください:

GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia

== コンポジタ ==

'''スタック型'''、'''タイル型'''、'''ダイナミック型''' の違いについては、[[ウィンドウマネージャ#種類]] を参照してください。

=== スタック型 ===

* {{App|[[Enlightenment]]|[[Enlightenment#手動]] を参照してください。詳細: [https://git.enlightenment.org/enlightenment/enlightenment/src/branch/master/README.md] [https://www.enlightenment.org/about-wayland]|https://www.enlightenment.org/|{{Pkg|enlightenment}}}}
* {{App|hikari|FreeBSD で活発に開発されている [[cwm]] にインスパイアされた wlroots ベースのコンポジタ。Linux もサポートしています。|https://web.archive.org/web/20241220075628/https://hikari.acmelabs.space/|{{AUR|hikari}}}}
* {{App|KDE [[w:KWin|KWin]]|[[KDE#Plasma の起動]] を参照。|https://userbase.kde.org/KWin|{{Pkg|kwin}}}}
* {{App|Liri Shell|[[Liri]] の一部、しかし、QtQuick と QtCompositor を使って Wayland 用のコンポジタとして作られています。|https://github.com/lirios/shell|{{AUR|liri-shell}}{{Broken package link|package not found}}}}
* {{App|[[labwc]]|Openbox にインスパイアされた wlroots ベースのコンポジタ。|https://github.com/labwc/labwc|{{Pkg|labwc}}}}
* {{App|[[w:Mutter (software)|Mutter]]|[[GNOME#GNOME の起動]] を参照。|https://gitlab.gnome.org/GNOME/mutter|{{Pkg|mutter}}}}
* {{App|wayfire|[[Compiz]] にインスパイアされた、wlroots ベースの 3D コンポジタ。|https://wayfire.org/|{{AUR|wayfire}}}}
* {{App|[[Weston]]|正しさ、信頼性、予測可能性、性能のために設計された Wayland コンポジタ。|https://gitlab.freedesktop.org/wayland/weston|{{Pkg|weston}}}}
* {{App|wio|Plan 9 のリオデスクトップのルックアンドフィールを複製することを目的とする wlroots ベースのコンポジタ。|https://gitlab.com/Rubo/wio|{{AUR|wio-wl}}}}

=== タイル型 ===

* {{App|[[Cagebreak]]|cage をベースに、[[ratpoison]] にインスパイアされています。|https://github.com/project-repo/cagebreak|{{AUR|cagebreak}}}}
* {{App|miracle-wm|Mir ベースの Wayland コンポジた。i3 や sway のスタイルですが、swayfs のように、これらよりも派手で機能に富んでいます。|https://github.com/miracle-wm-org/miracle-wm|{{AUR|miracle-wm}}}}
* {{App|[[niri]]|スクロール可能なタイル型 Wayland コンポジタ。|https://github.com/YaLTeR/niri/|{{Pkg|niri}}}}
* {{App|[[Qtile]]|Python で記述および設定されたフル機能のハッキング可能なタイリングウィンドウマネージャーと Wayland コンポジタ。|https://github.com/qtile/qtile|{{Pkg|qtile}}}}
* {{App|[[Sway]]|wlroots ベースの [[i3]] 互換 Wayland コンポジタ。|https://github.com/swaywm/sway|{{Pkg|sway}}}}
* {{App|SwayFx|魅力的な視覚効果機能を追加した [[Sway]]。|https://github.com/WillPower3309/swayfx|{{AUR|swayfx}}}}
* {{App|Velox|swc ベースのシンプルなウィンドウマネージャです。dwm と [[xmonad]] の影響を受けています。|https://github.com/michaelforney/velox|{{AUR|velox-git}}}}

=== ダイナミック型 ===

* {{App|[[cwc]]|wlroots ベースの [[awesome]] ライクな Wayland コンポジタ。|https://cudiph.github.io/cwc/apidoc/| {{AUR|cwc}}}}
* {{App|[[dwl]]|wlroots ベースの [[dwm]] ライクな Wayland コンポジタ。|https://codeberg.org/dwl/dwl|{{AUR|dwl}}}}
* {{App|[[Hyprland]]|見た目を犠牲にしないダイナミックなタイリング Wayland コンポジタ。|https://hyprland.org|{{Pkg|hyprland}}}}
* {{App|japokwm|wlroots ベースの、レイアウト作成を中心とした動的な Wayland タイリングコンポジタ。|https://github.com/werererer/japokwm|{{AUR|japokwm-git}}}}
* {{App|[[river]]|dwm と [[bspwm]] にインスパイアされた動的なタイル型 Wayland コンポジタ。|https://codeberg.org/river/river|{{Pkg|river}}}}
* {{App|Vivarium|wlroots を使用するダイナミックタイル型 Wayland コンポジタ。[[xmonad]] にインスパイアされたデスクトップセマンティクスを持ちます。|https://github.com/inclement/vivarium|{{AUR|vivarium-git}}}}

=== その他 ===

* {{App|Cage|キオスクのような単一のフルスクリーンアプリケーションを表示します。|https://www.hjdskes.nl/projects/cage/|{{Pkg|cage}}}}
* {{App|phoc|モバイル端末のための wlroots ベースの小さなコンポジタ。|https://gitlab.gnome.org/World/Phosh/phoc|{{Pkg|phoc}}}}

上記のいくつかは [[ディスプレイマネージャ]] をサポートする場合があります。
それらがどのように開始されるかを {{ic|/usr/share/wayland-sessions/''compositor''.desktop}} を見て確認してください。

== ディスプレイマネージャ ==

Wayland コンポジタの実行をサポートしている[[ディスプレイマネージャ]]は以下の表の通りです。

{| class="wikitable sortable"
! 名前
! 何で動作するか
! 説明
|-
| {{Pkg|emptty}}
| TTY
| TTY で動作するシンプルな CLI ディスプレイマネージャ。
|-
| [[GDM]]
| Wayland/Xorg
| [[GNOME]] ディスプレイマネージャ。
|-
| [[greetd]]
| Wayland/Xorg/TTY
[[Greetd#Greeter]] を参照。
| 最小でありながら柔軟なログインデーモン。
|-
| {{Pkg|lemurs}}
| TTY
| Rust で書かれた TUI ディスプレイマネージャ。
|-
| {{AUR|lidm}}
| TTY
| C で書かれた、完全にカラフルでカスタマイズ可能な TUI ディスプレイマネージャ。
|-
| [[LightDM]]
| Xorg[https://github.com/canonical/lightdm/issues/267]
| 様々なデスクトップに対応したディスプレイマネージャ。
|-
| {{Pkg|ly}}
| TTY
| C で書かれた TUI ディスプレイマネージャ。
|-
| [[SDDM]]
| Wayland/Xorg
| QML ベースのディスプレイマネージャ。
|-
| {{AUR|tbsm}}
| TTY
| bash のみに依存するシンプルな CLI セッションランチャー。
|-
| [[uwsm]]
| TTY
| スタンドアローンなコンポジタのための、セッションと XDG autostart のマネージャ。
TUI メニューを提供しますが、他のディスプレイマネージャと共に使用することもできます。
|}

== Xwayland ==

{{man|1|Xwayland}} は、Wayland の下で実行される X サーバーで、Wayland サポートをまだ提供していないネイティブな [[X11]] アプリケーションに互換性を提供します。これを使用するには、{{Pkg|xorg-xwayland}} パッケージを[[インストール]]します。

Xwayland はコンポジタを介して開始されるため、あなたの使用しているコンポジタのドキュメントを読み、Xwayland との互換性についてや、Xwayland の起動方法に関する指示を確認しておく必要があります。

{{Note|
* セキュリティ: Xwayland は X サーバーであるため、 Wayland のセキュリティ機能はありません。
* パフォーマンス: Xwayland は X11 と[https://openbenchmarking.org/result/2202053-NE-NVIDIARTX35 ほぼ同等のパフォーマンス]を発揮します。しかし、一部のケースで (特に NVIDIA カード上で) パフォーマンスの低下を感じるかもしれません。
* 互換性: Xwayland は X11 と完全な後方互換性があるわけではありません。一部のアプリケーションは Xwayland 下では正しく動作しない場合があります。}}

=== NVIDIA ドライバ ===

{{Note|バージョン 470 より前の Nvidia ドライバ(例: {{aur|nvidia-390xx-dkms}}) はハードウェア支援のある Xwayland をサポートしておらず、非 Wayland ネイティブなアプリケーションは Wayland セッションでのパフォーマンスが低下します。}}

なお、[[NVIDIA#DRM カーネルモード設定|DRM KMS]] を有効にする必要があります。また、お使いのディスプレイマネージャ(例: [[GDM#Wayland と独自の NVIDIA ドライバ|GDM]])の[https://download.nvidia.com/XFree86/Linux-x86_64/515.48.07/README/xwayland.html 公式ドキュメント]に記載されている情報も見てください。

=== Kwin Wayland デバッグコンソール ===

{{pkg|kwin}} を使用している場合、以下を実行すると、どのウィンドウが Xwayland とネイティブ Wayland を使用しているか、表面、入力イベント、クリップボードの内容などを確認することができます。

$ qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole

=== Xwayland アプリケーションを検出する ===

アプリケーションが Xwayland 経由で実行されているかどうかを判断するには、{{AUR|extramaus}} を使用します。
アプリケーションのウィンドウ上にマウスポインタを移動して、マウスポインタが赤くなる場合は、アプリケーションが Xwayland 経由で実行されています。

または、{{pkg|xorg-xeyes}} を使用して、アプリケーションウィンドウ上でマウスポインタを移動するときに、目が動いているかどうかで確認することもできます。

他の方法として、({{Pkg|xorg-xwininfo}} の) ''xwininfo'' をターミナルウィンドウで実行するというものがあります。Xwayland ウィンドウ上にマウスポインタをホバーすると、マウスポインタが + マークに変わります。ウィンドウをクリックすると、xwininfo は情報を表示して終了しますが、ネイティブな Wayland ウィンドウでは何も起こりません。{{ic|Ctrl+C}} を押すことで xwininfo を終了できます。

あるいは、''xlsclients'' ({{Pkg|xorg-xlsclients}} パッケージ) を使用することもできます。Xwayland で動作中のアプリケーションを全てリストアップするには、{{ic|xlsclients -l}} を実行してください。

== GUI ライブラリ ==

=== GTK ===

{{Pkg|gtk3}} と {{Pkg|gtk4}} パッケージは Wayland バックエンドが有効になっています。GTK ではデフォルトで Wayland バックエンドを使いますが、[[環境変数]]を設定することで Xwayland を使うように上書きできます: {{ic|1=GDK_BACKEND=x11}}。

テーマの問題は [[GTK#Wayland バックエンド]] を見てください。

=== Qt ===

[[Qt]] 5 または 6 で Wayland のサポートを有効化するには、Qt 5 と 6 に対してそれぞれ {{Pkg|qt5-wayland}} または {{Pkg|qt6-wayland}} パッケージをインストールしてください。これで、Qt アプリケーションは Wayland セッション上では Wayland で動作するようになります。

必須ではないはずですが、明示的に Wayland プラグインを使って Qt 5 アプリケーションを動作させるには、[https://wiki.qt.io/QtWayland#How_do_I_use_QtWayland.3F] にあるように、{{ic|1=-platform wayland}} を使用するか、[[環境変数]] {{ic|1=QT_QPA_PLATFORM=wayland}} をセットして下さい。

一方、Wayland セッション上で [[X11]] を使用させるには、{{ic|1=QT_QPA_PLATFORM=xcb}} と設定してください。これは、システムの Qt の実装を使用しない一部のプロプライエタリアプリケーションで必要になる場合があります。
また、{{ic|1=QT_QPA_PLATFORM="wayland;xcb"}} を使用すると、Qt が Wayland を利用できない場合に、代わりに xcb (X11)プラグインを使用させることができます。[https://www.qt.io/blog/2018/05/29/whats-new-in-qt-5-11-for-the-wayland-platform-plugin]

[[sway]] などの一部のコンポジターでは、ネイティブに実行されている Qt アプリケーションの機能が不足している場合があります。たとえば、[https://keepassxc.org KeepassXC] はトレイに最小化できません。これは、アプリケーションを実行する前に {{Pkg|qt5ct}} をインストールし、{{ic|1=QT_QPA_PLATFORMTHEME=qt5ct}} を設定することで解決できます。

Qt WebEngine のバグ ([https://bugreports.qt.io/browse/QTBUG-113574 Incorrect sizing and bad text rendering with WebEngine using fractional scaling on Wayland]) のため、Qt WebEgine を使用するアプリケーション (例: [https://bugs.launchpad.net/calibre/+bug/2018658 Calibre]) では荒いフォントが表示される場合があります。
回避策は、{{ic|1=QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor}} [[環境変数]]を設定してアプリケーションを起動することです。
これにより、アプリケーションのウィンドウが分数スケーリングされなくなります。

=== Clutter ===

Clutter ツールキットには Wayland バックエンドがあり、Clutter を Wayland のクライアントとして動作させることが可能です。このバックエンドは {{Pkg|clutter}} パッケージで有効になっています。

Clutter アプリを Wayland 上で動作させるには、環境変数 {{ic|1=CLUTTER_BACKEND=wayland}} を設定する必要があります。

=== SDL ===

[[SDL|SDL3]] では、デスクトップコンポジタとの通信に Wayland がデフォルトで使用されます。

SDL2 アプリケーションを Wayland 上で動作させるには、{{ic|1=SDL_VIDEODRIVER=wayland}} を設定してください。

{{ic|1=SDL_VIDEODRIVER="wayland,x11"}} とすることにより、Wayland が利用できない場合に代わりに X11 ビデオドライバを使用するように SDL2 を設定できます [https://wiki.libsdl.org/SDL2/FAQUsingSDL]。ウィンドウ装飾を有効化するために {{Pkg|libdecor}} をインストールすると良いかもしれません (例えば、GNOME で)。

詳細は[https://wiki.libsdl.org/SDL3/README/wayland 公式のドキュメント]を参照してください。

=== GLFW ===

{{Pkg|glfw}} パッケージには Wayland に対するサポートがあります。{{ic|1=XDG_SESSION_TYPE}} が {{ic|1=wayland}} に設定されていて、かつアプリケーションの開発者が特定のバックエンドを使用するようにしていなければ、Wayland バックエンドが使用されます。

詳細は GLFW の[https://github.com/glfw/glfw/blob/3.4/src/platform.c#L87-L99 ソースコード]を参照してください。

=== GLEW ===

{{AUR|glew-wayland-git}} パッケージが GLEW ベースのアプリケーションで動かない場合、唯一の選択肢は Xwayland で {{Pkg|glew}} を使うことです。{{Bug|62713}} を参照してください。

=== EFL ===

Enlightenment には[https://www.enlightenment.org/about-wayland 完全な Wayland サポート]があります.

=== winit ===

Winit は [[Rust]] で書かれたウィンドウ管理ライブラリです。デフォルトでは Wayland が X11 より優先される仕様ですが、環境変数を設定することで Xwayland を使うように上書きすることができます:

* バージョン 0.29.2 より前の場合、{{ic|1=WINIT_UNIX_BACKEND=x11}} を設定してください。
* バージョン 0.29.2 以降の場合、{{ic|1=WAYLAND_DISPLAY}} を unset してください。そうすることで、強制的に {{ic|1=DISPLAY}} 変数を使用して X にフォールバックされます。[https://github.com/rust-windowing/winit/blob/baf10de95843f156b0fbad6b10c3137f1ebd4f1e/src/changelog/v0.29.md?plain=1#L134]

=== Electron ===

Wayland サポートを有効化する方法は次の2つです: アプリケーションごとのコマンドラインフラグを使って有効化するか、設定ファイルを使ってグローバルに有効化するかです。詳細は [[#設定ファイル]] を参照してください。

アプリケーションがどの electron バージョンを使用しているか確認する方法については [https://stackoverflow.com/q/50345957] を見てください。

{{Note|Plasma では、一部の Electron アプリケーションで間違ったアイコン (デフォルトの Wayland アイコン) がウィンドウに表示され、一方タスクバーには正しいアイコンが表示されることがあります。この問題は、デスクトップファイルの名前を強制する特殊なアプリケーション/ウィンドウルールを作成することで解決できます。}}

==== 環境変数 ====

Electron 28 及びそれ以降を使用するアプリケーションは、[[環境変数]] [https://www.electronjs.org/docs/latest/api/environment-variables#electron_ozone_platform_hint-linux ELECTRON_OZONE_PLATFORM_HINT] を {{ic|auto}} または {{ic|wayland}} に設定することで、Wayland モードを使用することができます。

コマンドラインフラグは、この環境変数より優先されます。

==== コマンドラインフラグ ====

Electron がベースとしている Chromium とは異なり、Electron アプリケーションはデフォルトで PipeWire による WebRTC 画面共有を有効化しません。なので、Wayland 上で画面共有の問題を防ぐために {{ic|1=--enable-features=WebRTCPipeWireCapturer}} を使用することが推奨されます。画面共有は {{Pkg|xdg-desktop-portal}} をベースとしています。

環境変数を使うことが望ましくない、または不可能である場合に、{{Pkg|electron}} ベースのアプリケーションを Wayland でネイティブに使用するには、Electron 20 以降では {{ic|1=--ozone-platform-hint=auto}} フラグを使用することで可能です。

トップバーが消失してしまう場合、{{ic|1=--enable-features=WaylandWindowDecorations}} フラグを使用することで解決します。これは、典型的には [[GNOME]] で必須です ([https://github.com/electron/electron/pull/29618 electron17] からsパオートされています)。

これらのフラグを永続的に設定する方法は2つあります。1つ目は、アプリケーションの [[デスクトップエントリ#desktop ファイルの変更|.desktop ファイルを変更]]して {{ic|1=Exec=}} 行の末尾にフラグを追加する方法。もう一つは、以下で説明している設定ファイルを使用する方法で、こちらはよりきれいに設定できます。

{{Note|一部のアプリケーションは、Electron に対してフラグを渡さないため、そのアプリケーションの開発者が解決策を実装する必要があります。}}

==== 設定ファイル ====

Electron 系のパッケージは {{ic|1=~/.config/electron''XX''-flags.conf}} を読み込みます。ここで、''XX'' は Electron のバージョンです。該当するバージョンのファイルが存在しない場合、{{ic|1=~/.config/electron-flags.conf}} を代わりに読み込みます。

前述のフラグを一行ずつ書き込んでください:

{{hc|~/.config/electron-flags.conf|2=
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto
}}

{{Note|このような設定ファイルは、公式リポジトリ内の Electron のパッケージと、それらの設定ファイルを使用するパッケージでのみ機能します。{{AUR|slack-desktop}} などのような Electron の独自のビルドをバンドルしているパッケージでは機能しません。{{AUR|slack-electron}} のように代替のパッケージが存在する場合があります。}}

==== 古い Electron バージョン ====

{{ic|electron25-flags.conf}} は Electron バージョン 25 に対してだけ適用されます。それより古い Electron のバージョンは {{ic|electron<バージョン>-flags.conf}} ファイルで設定できます。

古いバージョンでは、対応する Chromium バージョンによって異なるフラグが必要になる場合があります。例えば、以下のフラグは Electron 13 で機能します:

{{hc|~/.config/electron13-flags.conf|2=
--enable-features=UseOzonePlatform
--ozone-platform=wayland
}}

=== Java ===

[[Java]] プラットフォームのオープンソース実装である OpenJDK は、まだ Wayland のネイティブサポートを備えていません。
OpenJDK に Wayland を実装することを目的としたプロジェクトである [https://openjdk.java.net/projects/wakefield/ Wakefield] が実用できるようになるまでは、Xwayland を代わりに使用できます。

[[Debian:Wayland#Java Programs (supported since OpenJDK 16?)]] を参照してください:

:OpenJDK 16から、JRE は (Wayland をサポートしている) GTK3 を動的にロードできるようになりました。この[https://stackoverflow.com/questions/39197208/java-gui-support-on-wayland 議論]によると、これがサポートされているかもしれません。
:{{ic|_JAVA_AWT_WM_NONREPARENTING}} [[環境変数]]を "1" に設定することで、アプリケーションが空白の画面で起動する不具合を修正することができます。

XWayland は機能的に Wayland と同等ではないので、Wakefield が実用的になるまでは、[https://wiki.openjdk.org/display/wakefield/Pure+Wayland+toolkit+prototype WLToolkit] で機能の差を埋めることができます。これは {{ic|1=-Dawt.toolkit.name=WLToolkit}} でアクティブ化できます。[https://blog.jetbrains.com/platform/2024/07/wayland-support-preview-in-2024-2/ JetBrains IDE] といった一部のプログラムはこれをサポートしています。

== ヒントとテクニック ==

=== 自動化 ===

* [https://github.com/ReimuNotMoe/ydotool ydotool] ({{Pkg|ydotool}}) - 汎用のコマンドラインツール (wayland 以外でも利用可能)。{{ic|ydotool.service}} [[ユーザーユニット]]を[[起動/有効化]]してください。{{man|8|ydotoold}}、{{man|1|ydotool}} を参照。
* [https://github.com/atx/wtype wtype] ({{Pkg|wtype}}) - Wayland 用 xdotool type。{{man|1|wtype}} を参照。
* [https://github.com/boppreh/keyboard keyboard] - Windows と Linux で動作する Python ライブラリ。実験的な OS X サポートあり。[https://github.com/boppreh/mouse mouse] ライブラリも参照。
* [https://git.sr.ht/~brocellous/wlrctl wlrctl] ({{AUR|wlrctl}}) - 雑多な wlroots 拡張のためのコマンドラインユーティリティ (foreign-toplevel-management、virtual-keyboard、virtual-pointer をサポート)。

=== キーボードやマウスキーのリマップ ===

[[入力リマップユーティリティ]] を見てください。

=== スクリーンキャスト ===

[[スクリーンキャプチャ#スクリーンキャスト]] と [[スクリーンキャプチャ#X11 アプリケーションで Wayland ウィンドウをスクリーンキャストする]] を見てください。

=== Chromium で完全に最大化出来ない ===

''chrome://settings/appearance'' メニューから ''Use system title bar and borders'' を有効化する必要があります。

=== アプリが閉じた後もクリップボードの内容を保持する ===

Wayland の設計思想上、クリップボードのデータはソースクライアントのメモリ内に保存されます。クライアントが閉じると、クリップボードのデータは失われます。{{Pkg|wl-clip-persist}} を使うことで、この問題を解決できます。これはバックグラウンドで動き、クリップボードのデータを読んで、ソースクライアントからは独立した自身のメモリに保存します。

=== Wayland コンポジタを systemd サービスとして自動的に起動する ===

{{Note|この設定はdbusセッションを破壊し,[[PipeWire#WebRTC 画面共有]]を破壊するかも知れません.}}

ディスプレイマネージャーやシェルを使いたくなければ、Waylandコンポジタを[[systemd]] サービスを使って自動的に起動できます。{{ic|ExecStart}} 行を使いたいコンポジタに変えて下さい:

{{hc|/etc/systemd/system/wayland-compositor.service|2=
[Unit]
After=graphical.target systemd-user-sessions.service modprobe@drm.service
Conflicts=getty@tty1.service #使用できない tty1 を無効にするオプション

[Service]
User=''username''
WorkingDirectory=~

PAMName=login
TTYPath=/dev/tty1
UnsetEnvironment=TERM

StandardOutput=journal
ExecStart=/bin/labwc -s gtklock

[Install]
WantedBy=graphical.target
}}

{{Note|[[セキュリティ#物理セキュリティ]]の為に、{{Pkg|swaylock}} や {{Pkg|gtklock}} 等のスクリーンロッカーを、コンポジタの設定を通して自動的に起動する必要があるかも知れません。}}

=== wlroots ベースのコンポジタで他のレンダラーを使用する ===

wlroots ベースのコンポジタに対して {{ic|WLR_RENDERER}} [[環境変数]]を設定することで vulkan などといった他の [https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master/render wlroots レンダラー]を使用することができます。利用可能なレンダラーのリストは [https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/docs/env_vars.md wlroots のドキュメント]にあります。

==トラブルシューティング==

=== 色補正 ===

[[バックライト#色補正]]を参照。

=== 動作が遅い、表示がおかしい、クラッシュする ===

Gnome-shell で X から Wayland に切り替えるとグラフィック表示に問題が発生することがあります。原因として Xorg ベースの gnome-shell 用に {{ic|1=CLUTTER_PAINT=disable-clipped-redraws:disable-culling}} が設定されている可能性があります。{{ic|/etc/environment}} や rc ファイルから該当箇所を削除してみてください。

=== リモートディスプレイ ===

* ([[sway]] で使用されている) {{pkg|wlroots}}{{Broken package link|replaced by {{Pkg|wlroots0.18}}}} は、バージョン 0.10 より、{{Pkg|wayvnc}} を使って VNC バックエンドを提供しています。RDP バックエンドは削除されました [https://github.com/swaywm/wlroots/releases/tag/0.10.0]。
* {{pkg|mutter}} はコンパイル時にリモートデスクトップが有効化されています。詳細は [https://wiki.gnome.org/Projects/Mutter/RemoteDesktop] と {{Pkg|gnome-remote-desktop}} を見てください。
* {{pkg|krfb}} は {{pkg|kwin}} に VNC サーバを提供します。{{ic|krfb-virtualmonitor}} を使えば、他のデバイスを外部モニタとしてセットアップすることが可能です。
* 2013年に FreeRDP が Weston にマージされました。コンパイルフラグで有効化されています。{{Pkg|weston}} パッケージは、バージョン 6.0.0 より、FreeRDP が有効化されています。
* {{Pkg|waypipe}} は Wayland アプリケーションの透過プロキシです。[[SSH]] 上で動作するラッパーコマンドあり。
** 以下は、Plasma デスクトップでリモートの KDE kcalc を起動する例です:
::{{bc|1=$ waypipe ssh example.local env QT_QPA_PLATFORM=wayland QT_QPA_PLATFORMTHEME=KDE dbus-launch kcalc}}

=== ゲームやリモートデスクトップ、仮想マシンウィンドウでの入力捕捉 ===

Xorg と異なり、Wayland では入力デバイスを独占 (グラブ) することができません (例: [https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html キーボード]、[https://tronche.com/gui/x/xlib/input/XGrabPointer.html マウス])。キーボードショートカットやポインタデバイスをアプリケーションウィンドウに渡すのは Wayland コンポジタの役目となっています。

入力グラブが変わったことで以下のように既存のアプリケーションで問題が発生します:

* ホットキーや修飾キーがコンポジタによって認識されてしまい、リモートデスクトップや仮想マシンのウィンドウに送信されなくなります。
* マウスポインタがアプリケーションウィンドウに制限されなくなるため、仮想マシンやリモートデスクトップのウィンドウ内のマウスポインタの位置がホスト環境のマウスポインタとずれるようになります。

Wayland と Xwayland にプロトコル拡張を追加することで解決を図っていますが、Wayland コンポジタが拡張をサポートしている必要があり、ネイティブの Wayland クライアントの場合、ウィジェットツールキット (例: GTK, Qt) やアプリケーション自身が拡張に対応していなければなりません。Xorg アプリケーションの場合、Xwayland のサポートで十分であるため、アプリケーションやウィジェット・ツールキットに変更を加える必要はありません。

これらの拡張はすでに {{pkg|wayland-protocols}} に含まれており、{{pkg|xorg-xwayland}} によってサポートされています。

関連する拡張:

* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml Xwayland keyboard grabbing protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml Compositor shortcuts inhibit protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/relative-pointer/relative-pointer-unstable-v1.xml Relative pointer protocol]
* [https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml Pointer constraints protocol]

サポートしている Wayland コンポジタ:

* Mutter, [[GNOME]] のコンポジタ ([https://bugzilla.gnome.org/show_bug.cgi?id=783342 リリース 3.28] 以降)。
* wlroots (Relative pointer protocols と Pointer constraints protocol に対応)
* Kwin
** [[KDE#Wayland で X11 のショートカットが衝突する]]
** [https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/keyboard_shortcuts_inhibit_v1_interface.cpp Keyboard shortcuts inhibit]

サポートしているウィジェットツールキット:

* GTK (リリース 3.22.18 以降)

=== GTK テーマが動かない ===

https://github.com/swaywm/sway/wiki/GTK-3-settings-on-Wayland を参照してください。

=== NVIDIA モジュールを読み込まないようにする ===

[[sway]] などの Wayland コンポジターを起動する前に {{ic|1=__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json}} を [[環境変数]] として追加します。

=== 拡大/サーフェススケーリング ===

スクリーンの拡大は、まだ解決していません。[https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/145 wp-surface-scale プロトコルを提供する]プルリクエストが2022年半ばにマージされました。

=== カーネル 6.11.2 以降、Wayland にラグ/スタッタリングが発生する (AMD) ===

将来のカーネルリリースでこの問題が修正されるまで、回避策は、カーネルのコマンドラインに {{ic|1=amdgpu.dcdebugmask=0x400}} を追加することです。

こちらを参照: https://community.frame.work/t/wayland-lag-stuttering-since-kernel-6-11-2/59422

== 参照 ==

* [https://wayland.freedesktop.org/docs/html/ Wayland オンラインドキュメント]
* [https://gitlab.freedesktop.org/wayland 公式リポジトリ]
* [[Fedora:How to debug Wayland problems]]
* [https://wearewaylandnow.com/ We are Wayland now!] - "Are we Wayland yet?" の更新されたバージョン
* [https://awesomeopensource.com/projects/wayland Awesome Wayland projects]
* [[カーソルテーマ]]
* [https://bbs.archlinux.org/viewtopic.php?id=107499 Arch Linux forum discussion]
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide#common-x11-apps-used-on-i3-with-wayland-alternatives i3 Migration Guide - Common X11 apps used on i3 with Wayland alternatives]
* [https://wayland.app/protocols/ Wayland Explorer - A better way to read Wayland documentation]
* [https://askubuntu.com/questions/1393618/how-can-i-tell-if-an-application-is-using-xwayland How can I tell if an application is using XWayland]

{{TranslationStatus|Wayland|2025-06-29|839014}}

永続的なブロックデバイスの命名

2025-06-29T05:13:28Z

AshMyzk: 同期

[[Category:ブートプロセス]]
[[Category:ファイルシステム]]
[[Category:ハードウェア検出とトラブルシューティング]]
[[en:Persistent block device naming]]
[[es:Persistent block device naming]]
[[fr:Persistent block device naming]]
[[hu:Persistent block device naming]]
[[pt:Persistent block device naming]]
[[ru:Persistent block device naming]]
[[zh-hans:Persistent block device naming]]
{{Related articles start}}
{{Related|fstab}}
{{Related|udev}}
{{Related|LVM}}
{{Related articles end}}
この記事では[[ブロックデバイス]]に永続的な名前を使う方法を説明します。永続的な命名は [[udev]] の導入によって可能になったものであり、バスによる命名と比べて複数の利点があります。同じ命名スキームを持つドライブがマシン上に複数存在する場合、それらに対応するデバイスノードが追加される順序は任意です。そのため、起動するたびにデバイス名 (例: {{ic|/dev/sd'''a'''}} と {{ic|/dev/sd'''b'''}}、{{ic|/dev/nvme'''0'''n1}} と {{ic|/dev/nvme'''1'''n1}}、{{ic|/dev/mmcblk'''0'''}} と {{ic|/dev/mmcblk'''1'''}}) が入れ替わる可能性があり、下手をすると、システムが起動できなくなったり、カーネルパニックが発生したり、ブロックデバイスが表示されなくなってしまいます。永続的な命名によってこれらの問題は解決します。

{{Note|
* 永続的な命名には制約が存在しますが、それはこの記事では扱っていません。例えば、[[mkinitcpio]] が命名方法をサポートしていても、[[systemd]] が起動時に処理できる命名法には制約が存在することがあります (例: {{Bug|42884}})。
* この記事では [[LVM]] の論理ボリュームに言及しません。{{ic|/dev/''VolumeGroupName''/''LogicalVolumeName''}} デバイスパスは永続的であるためです。
}}

== 永続的な命名の方法 ==

[[udev]] によって管理されている永続的な命名を提供しているスキームは複数あります:

* {{ic|60-persistent-storage.rules}} はデフォルトで4つのスキームを提供しています: [[#by-label|by-label]]、[[#by-uuid|by-uuid]]、[[#by-id と by-path|by-id と by-path]]。[[GUID Partition Table|GUID Partition Table (GPT)]] のディスクにおいては、先の4つに加えて [[#by-partlabel|by-partlabel]] と [[#by-partuuid|by-partuuid]] のスキームも利用可能です。
* {{ic|99-systemd.rules}} は、[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]]に対応している環境では [[#gpt-auto|gpt-auto]] を提供しています。

{{ic|/dev/disk/}} 内のディレクトリは、デバイスがあるかどうかに応じて動的に作成・破棄されます。

{{Note|[[ディスクのクローン]]は同じ名前の異なるディスクを作成することに注意してください。}}

以下のセクションではこれらの異なる命名規則がどのようなものであるか、またどうやって使うのかを説明しています。

[[lsblk]] コマンドを使うことで1つ目の永続的な名前をグラフィカルに表示することができます:

{{hc|$ lsblk -f|
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat CBB6-24F2 /boot
├─sda2 ext4 Arch Linux 0a3407de-014b-458b-b5c1-848e92a327a3 /
├─sda3 ext4 Data b411dc99-f0a0-4c87-9e05-184977be8539 /home
└─sda4 swap f9fe0b69-a280-415d-a03a-a32752370dee [SWAP]
mmcblk0
└─mmcblk0p1 vfat F4CA-5D75
}}

[[GPT]] を使っている場合、代わりに {{ic|blkid}} コマンドを使います。{{ic|blkid}} コマンドはスクリプトでは使いやすいですが、人間にとっては読みづらいです。

{{hc|# blkid|2=
/dev/sda1: UUID="CBB6-24F2" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="d0d0d110-0a71-4ed6-936a-304969ea36af"
/dev/sda2: LABEL="Arch Linux" UUID="0a3407de-014b-458b-b5c1-848e92a327a3" TYPE="ext4" PARTLABEL="GNU/Linux" PARTUUID="98a81274-10f7-40db-872a-03df048df366"
/dev/sda3: LABEL="Data" UUID="b411dc99-f0a0-4c87-9e05-184977be8539" TYPE="ext4" PARTLABEL="Home" PARTUUID="7280201c-fc5d-40f2-a9b2-466611d3d49e"
/dev/sda4: UUID="f9fe0b69-a280-415d-a03a-a32752370dee" TYPE="swap" PARTLABEL="Swap" PARTUUID="039b6c1c-7553-4455-9537-1befbc9fbc5b"
/dev/mmcblk0: PTUUID="0003e1e5" PTTYPE="dos"
/dev/mmcblk0p1: UUID="F4CA-5D75" TYPE="vfat" PARTUUID="0003e1e5-01"
}}

=== by-label ===

ほぼすべての[[ファイルシステム#ファイルシステムのタイプ|ファイルシステムタイプ]]が、ラベルを持つことができます。ラベルを持つボリュームはすべて {{ic|/dev/disk/by-label}} ディレクトリ内に出現します。

{{hc|$ ls -l /dev/disk/by-label/|
total 0
lrwxrwxrwx 1 root root 10 May 27 23:31 Data -> ../../sda3
lrwxrwxrwx 1 root root 10 May 27 23:31 Arch\x20Linux -> ../../sda2
}}

ほとんどのファイルシステムは、ファイルシステム作成時におけるラベルの設定をサポートしています (関連する {{ic|mkfs.*}} ユーティリティの [[man ページ]]を参照してください)。一部のファイルシステムにおいてはラベルを変更することもできます。以下は、一般的なファイルシステムにおけるラベルの変更方法です:

; btrfs : {{pkg|btrfs-progs}} で {{ic|btrfs filesystem label /dev/''XXX'' "''new label''"}} (デバイスをすでにマウントしている場合は、そのマウントポイントを使用してください)
; crypto_LUKS (LUKS2 のみ) : {{Pkg|cryptsetup}} で {{ic|1=cryptsetup config --label="''new label''" /dev/''XXX''}}
; exfat : {{Pkg|exfatprogs}} で {{ic|tune.exfat -L "''new label''" /dev/''XXX''}}
: {{Pkg|exfatprogs}} または {{Pkg|exfat-utils}} で {{ic|exfatlabel /dev/''XXX'' "''new label''"}}
; ext2/3/4 : {{pkg|e2fsprogs}} で {{ic|e2label /dev/''XXX'' "''new label''"}}
; fat/vfat : {{pkg|dosfstools}} で {{ic|fatlabel /dev/''XXX'' "''new label''"}}
: {{pkg|mtools}} で {{ic|mlabel -i /dev/''XXX'' ::"''new label''"}}
; jfs : {{pkg|jfsutils}} で {{ic|jfs_tune -L "''new label''" /dev/''XXX''}}
; ntfs : {{pkg|ntfs-3g}} で {{ic|ntfslabel /dev/''XXX'' "''new label''"}}
; reiserfs : {{AUR|reiserfsprogs}} で {{ic|reiserfstune -l "''new label''" /dev/''XXX''}}
; swap : {{pkg|util-linux}} で {{ic|swaplabel -L "''new label''" /dev/''XXX''}}
; udf : {{Pkg|udftools}} で {{ic|udflabel /dev/''XXX'' "''new label''"}}
; xfs : {{pkg|xfsprogs}} で {{ic|xfs_admin -L "''new label''" /dev/''XXX''}} (デバイスをすでにマウントしている場合は、そのマウントポイントを使用してください)

デバイスのラベルは ''lsblk'' を使って得ることができます:

{{hc|$ lsblk -dno LABEL /dev/sda2|
Arch Linux
}}

あるいは ''blkid'' を使って:

{{hc|# blkid -s LABEL -o value /dev/sda2|
Arch Linux
}}

{{Note|
* 衝突を避けるために、ラベルは曖昧であってはいけません。
* ラベルに設定できるのは16文字までです。
* ラベルはファイルシステムのプロパティであるため、単一の RAID デバイスをアドレス指定するのには適していません。
* [[dm-crypt]] で暗号化済みコンテナを使用する場合、コンテナがロック/暗号化されている間はコンテナ内のファイルシステムのラベルは利用できなくなります。
}}

=== by-uuid ===

[[wikipedia:ja:UUID|UUID]] は、各[[ファイルシステム]]にユニークな識別子を与えるための仕組みです。UUID 識別子は、パーティションをフォーマットするときにファイルシステムユーティリティ (例: {{ic|mkfs.*}}) によって生成されます。UUID 識別子は衝突が起こりにくいように作られています。(スワップや生の暗号化デバイスの LUKS ヘッダを含む) 全ての GNU/Linux ファイルシステムが UUID をサポートします。FAT、exFAT、NTFS ファイルシステムは UUID をサポートしていませんが、それでも、より短い UID (unique identifier) で {{ic|/dev/disk/by-uuid/}} 内に現れます:

{{hc|$ ls -l /dev/disk/by-uuid/|
total 0
lrwxrwxrwx 1 root root 10 May 27 23:31 0a3407de-014b-458b-b5c1-848e92a327a3 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 27 23:31 b411dc99-f0a0-4c87-9e05-184977be8539 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 27 23:31 CBB6-24F2 -> ../../sda1
lrwxrwxrwx 1 root root 10 May 27 23:31 f9fe0b69-a280-415d-a03a-a32752370dee -> ../../sda4
lrwxrwxrwx 1 root root 10 May 27 23:31 F4CA-5D75 -> ../../mmcblk0p1
}}

デバイスの UUID は ''lsblk'' を使って得ることができます:

{{hc|$ lsblk -dno UUID /dev/sda1|
CBB6-24F2
}}

あるいは ''blkid'' を使って:

{{hc|# blkid -s UUID -o value /dev/sda1|
CBB6-24F2
}}

UUID を使用する利点として、名前の衝突が発生する可能性がラベルよりもずっと少ないことが挙げられます。さらに、UUID はファイルシステムの作成時に自動的に生成されます。他のシステムにデバイスを接続したときでも、一意性を保つことができます。ラベルの場合、他のシステムに接続したとき名前がカブってしまう可能性が否定できません。

逆に UUID の欠点としては、生成されるコードが長いために、設定ファイル (例: [[fstab]] や [[crypttab]]) が読みづらくなったり整形が崩れてしまうことがあります。また、パーティションのサイズを変更したり、再フォーマットをするたびに新しい UUID が生成されるので、設定を手動で変更する必要が生じます。

{{Tip|スワップパーティションに UUID が割り当てられていない場合、[[スワップ#スワップパーティション|mkswap]] ユーティリティを使ってスワップパーティションをリセットする必要があります。}}

=== by-id と by-path ===

{{ic|by-id}} はハードウェアのシリアル番号に基づいて一意な名前を作成します。{{ic|by-path}} は (sysfs による) 一番短い物理パスを使います。どちらも、属するサブシステムを示す文字列を含んでいるため ({{ic|by-path}} の場合 {{ic|-ide-}}、{{ic|by-id}} の場合 {{ic|-ata-}})、デバイスを制御するハードウェアと繋がりがあります。このため永続性のレベルが異なってきます: {{ic|by-path}} はデバイスをコントローラの他のポートに接続したときに値が変わり、{{ic|by-id}} はデバイスを他のサブシステムが使っているハードウェアコントローラのポートに接続したときに値が変わります。[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html] 従って、ハードウェアが変わっても値が変わらないような永続的な命名としてはどちらも不適切です。

しかし、巨大なハードウェア基盤で特定のデバイスを見つけたいときに、どちらも有益な情報を提供します。例えば、永続的なラベル ({{ic|by-label}} や {{ic|by-partlabel}}) を手動で割り当てず、ハードウェアポートの使用を表すディレクトリが変わらない場合、{{ic|by-id}} と {{ic|by-path}} を使うことで特定のデバイスを探すことが可能です。[https://linuxshellaccount.blogspot.in/2008/09/how-to-easily-find-wwns-of-qlogic-hba.html] [https://www.linuxquestions.org/questions/linux-server-73/how-to-find-wwn-for-dev-sdc-917269/]

{{Note|
* {{ic|by-id}} と {{ic|by-path}} のリンクは、(パーティションではなく) ディスクの場合のみ永続的であるとみなせます。パーティションは、パーティションテーブル内における番号で参照され、パーティションの順番が変更された場合にリンクが変更される可能性があります。
* NVMe デバイスにおける {{ic|/dev/disk/by-path/pci-*}} のパスは、PCIe デバイスがシステムに追加または除去された場合や、ファームウェアが[https://github.com/systemd/systemd/issues/22692 デバイスを決定的に列挙しない]場合に変化してしまう場合があります。
* NVMe デバイスの、名前空間識別子 (NSID) を用いない {{ic|by-id}} (シンボリック) リンクは古い方法です。代わりに、ハードウェアのシリアルナンバーの後に名前空間識別子を付けた名前のリンクを使用してください (例: 最初の名前空間の場合は {{ic|_1}}、最初の名前空間上の最初のパーティションの場合は {{ic|'''_1'''-part1}} となります)。
}}

{{hc|$ ls -l /dev/disk/by-id/|
total 0
lrwxrwxrwx 1 root root 10 May 27 23:31 ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470 -> ../../sda
lrwxrwxrwx 1 root root 10 May 27 23:31 ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 May 27 23:31 ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 27 23:31 ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 27 23:31 ata-WDC_WD2500BEVT-22ZCT0_WD-WXE908VF0470-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 May 27 23:31 mmc-SD32G_0x0040006d -> ../../mmcblk0
lrwxrwxrwx 1 root root 10 May 27 23:31 mmc-SD32G_0x0040006d-part1 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 13 May 27 23:31 nvme-Samsung_SSD_970_EVO_Plus_2TB_S4J4NJ0N704064T -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-Samsung_SSD_970_EVO_Plus_2TB_S4J4NJ0N704064T-part1 -> ../../nvme1n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-Samsung_SSD_970_EVO_Plus_2TB_S4J4NJ0N704064T-part2 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 13 May 27 23:31 nvme-Samsung_SSD_970_EVO_Plus_2TB_S4J4NJ0N704064T_1 -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-Samsung_SSD_970_EVO_Plus_2TB_S4J4NJ0N704064T_1-part1 -> ../../nvme1n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-Samsung_SSD_970_EVO_Plus_2TB_S4J4NJ0N704064T_1-part2 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 13 May 27 23:31 nvme-WDS100T1X0E-00AFY0_21455A801268 -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-WDS100T1X0E-00AFY0_21455A801268-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-WDS100T1X0E-00AFY0_21455A801268-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 13 May 27 23:31 nvme-WDS100T1X0E-00AFY0_21455A801268_1 -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-WDS100T1X0E-00AFY0_21455A801268_1-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-WDS100T1X0E-00AFY0_21455A801268_2-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 13 May 27 23:31 nvme-eui.002538570142d716 -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-eui.002538570142d716-part1 -> ../../nvme1n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-eui.002538570142d716-part2 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 13 May 27 23:31 nvme-eui.e8238fa6bf530001001b448b4566aa1a -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-eui.e8238fa6bf530001001b448b4566aa1a-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-eui.e8238fa6bf530001001b448b4566aa1a-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f -> ../../sda
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f-part4 -> ../../sda4
}}

{{hc|$ ls -l /dev/disk/by-path/|
total 0
lrwxrwxrwx 1 root root 10 May 27 23:31 pci-0000:00:1f.2-ata-1 -> ../../sda
lrwxrwxrwx 1 root root 10 May 27 23:31 pci-0000:00:1f.2-ata-1-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 May 27 23:31 pci-0000:00:1f.2-ata-1-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 27 23:31 pci-0000:00:1f.2-ata-1-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 27 23:31 pci-0000:00:1f.2-ata-1-part4 -> ../../sda4
lrwxrwxrwx 1 root root 13 May 27 23:31 pci-0000:01:00.0-nvme-1 -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 May 27 23:31 pci-0000:01:00.0-nvme-1-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 pci-0000:01:00.0-nvme-1-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 13 May 27 23:31 pci-0000:04:00.0-nvme-1 -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 May 27 23:31 pci-0000:04:00.0-nvme-1-part1 -> ../../nvme1n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 pci-0000:04:00.0-nvme-1-part2 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 10 May 27 23:31 pci-0000:07:00.0-platform-rtsx_pci_sdmmc.0 -> ../../mmcblk0
lrwxrwxrwx 1 root root 10 May 27 23:31 pci-0000:07:00.0-platform-rtsx_pci_sdmmc.0-part1 -> ../../mmcblk0p1
}}

==== World Wide Name ====

{{ic|by-id}} はストレージデバイスの [[Wikipedia:ja:World Wide Name|World Wide Name (WWN)]] のリンクも作成します (そのデバイスが WWN をサポートしている場合)。他の {{ic|by-id}} リンクとは異なり、WWN は完全に永続的であり、使用されているサブシステムに依らず変化しません。

SATA と SAS のデバイスには {{ic|wwn-}} プレフィックスが付きますが、NVMe デバイスでは[[Wikipedia:World Wide Name#Formats|別の WWN 形式]]が使用され {{ic|nvme-eui.}} というプレフィックスが付きます。[https://github.com/systemd/systemd/pull/3136]

{{Tip|大抵、ストレージデバイスの WWN はそのデバイスのラベルに印刷されています (ここでのラベルは、デバイス自体に貼られているステッカーのことです)。}}

{{hc|$ ls -l /dev/disk/by-id/{wwn-,nvme-eui.}*|
lrwxrwxrwx 1 root root 13 May 27 23:31 nvme-eui.002538570142d716 -> ../../nvme1n1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-eui.002538570142d716-part1 -> ../../nvme1n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-eui.002538570142d716-part2 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 13 May 27 23:31 nvme-eui.e8238fa6bf530001001b448b4566aa1a -> ../../nvme0n1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-eui.e8238fa6bf530001001b448b4566aa1a-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 May 27 23:31 nvme-eui.e8238fa6bf530001001b448b4566aa1a-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f -> ../../sda
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 27 23:31 wwn-0x60015ee0000b237f-part4 -> ../../sda4
}}

=== by-partlabel ===

{{Note|この方法が関係するのは [[GUID Partition Table|GUID Partition Table (GPT)]] のディスクだけです。}}

パーティションラベルは、GPT ディスクの[[Wikipedia:ja:GUIDパーティションテーブル#パーティションエントリ (LBA 2〜33)|パーティションエントリ]]のヘッダで定義することができます。

この方法は[[#by-label|ファイルシステムラベル]]と非常に似ています。しかし、パーティションラベルは、パーティション上のファイルシステムが変更された場合でも、影響を受けません。

パーティションラベルを持つ全パーティションは {{ic|/dev/disk/by-partlabel}} ディレクトリ内に出現します。

{{hc|$ ls -l /dev/disk/by-partlabel/|
total 0
lrwxrwxrwx 1 root root 10 May 27 23:31 EFI\x20system\x20partition -> ../../sda1
lrwxrwxrwx 1 root root 10 May 27 23:31 GNU\x2fLinux -> ../../sda2
lrwxrwxrwx 1 root root 10 May 27 23:31 Home -> ../../sda3
lrwxrwxrwx 1 root root 10 May 27 23:31 Swap -> ../../sda4
}}

デバイスのパーティションラベルは ''lsblk'' を使って得ることができます:

{{hc|$ lsblk -dno PARTLABEL /dev/sda1|
EFI system partition
}}

あるいは ''blkid'' を使って:

{{hc|# blkid -s PARTLABEL -o value /dev/sda1|
EFI system partition
}}

{{Note|
* GPT パーティションラベルも名前が衝突しないように付ける必要があります。パーティションラベルを変更したいときは、[[gdisk]] か ncurse ベースの [[cgdisk]] を使うことができます。どちらのプログラムも {{Pkg|gptfdisk}} パッケージに入っています。[[パーティショニング#パーティショニングツール]]を見て下さい。
* 仕様によると、GPT パーティションラベルの長さは72文字までです。
}}

=== by-partuuid ===

[[#by-partlabel|GPT パーティションラベル]]のように、GPT パーティション UUID も GPT ディスク上の[[Wikipedia:ja:GUIDパーティションテーブル#パーティションエントリ (LBA 2〜33)|パーティションエントリ]]で定義されます。

MBR はパーティション UUID をサポートしていません。しかし、Linux[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d33b98fc82b0908e91fb05ae081acaed7323f9d2] と、libblkid[https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d67cc2889a0527b26d7bb8c76f2acac46751d673] を使用するソフトウェア (例: udev[https://github.com/systemd/systemd/pull/3293]) は、MBR パーティションに対して擬似的な PARTUUID を生成することができます。この時、形式は {{ic|''SSSSSSSS''-''PP''}} となります。{{ic|''SSSSSSSS''}} の部分はゼロで埋められた32ビットの [[Wikipedia:Master boot record#Disk identity|MBR ディスクシグネチャ]]で、{{ic|''PP''}} はゼロで埋められた16進形式のパーティション番号です。GPT パーティションの通常の PARTUUID と違って、MBR の疑似 PARTUUID は、パーティション番号が変更された場合に変わる可能性があります。

動的ディレクトリは他の方法のものと似ており、[[#by-uuid|ファイルシステム UUID]] と同じく、UUID はラベルよりも推奨されます。

{{hc|$ ls -l /dev/disk/by-partuuid/|
total 0
lrwxrwxrwx 1 root root 10 May 27 23:31 0003e1e5-01 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 10 May 27 23:31 039b6c1c-7553-4455-9537-1befbc9fbc5b -> ../../sda4
lrwxrwxrwx 1 root root 10 May 27 23:31 7280201c-fc5d-40f2-a9b2-466611d3d49e -> ../../sda3
lrwxrwxrwx 1 root root 10 May 27 23:31 98a81274-10f7-40db-872a-03df048df366 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 27 23:31 d0d0d110-0a71-4ed6-936a-304969ea36af -> ../../sda1
}}

デバイスのパーティション UUID は ''lsblk'' を使って得ることができます:

{{hc|$ lsblk -dno PARTUUID /dev/sda1|
d0d0d110-0a71-4ed6-936a-304969ea36af
}}

あるいは ''blkid'' を使って:

{{hc|# blkid -s PARTUUID -o value /dev/sda1|
d0d0d110-0a71-4ed6-936a-304969ea36af
}}

=== gpt-auto ===

[[systemd#GPT パーティションの自動マウント|systemd-gpt-auto-generator]] の前提要件を全て満たしている場合、udev は、ルートボリュームのブロックデバイスを指す {{ic|/dev/gpt-auto-root}} シンボリックリンクを作成します。ルートパーティションが LUKS によって暗号化されている場合、{{ic|/dev/gpt-auto-root}} はロック解除された/マッピングされたボリュームを指し、{{ic|/dev/gpt-auto-root-luks}} は暗号化されているパーティションを指します。

{{hc|$ ls -l /dev/gpt-auto-*|
lrwxrwxrwx 1 root root 10 May 27 23:31 /dev/gpt-auto-root -> dm-0
lrwxrwxrwx 1 root root 10 May 27 23:31 /dev/gpt-auto-root-luks -> nvme1n1p2
}}

== 永続的な命名の使用 ==

様々なアプリケーションで、永続的な命名を使うように設定を行うことができます。以下はアプリケーションの設定例です。

=== fstab ===

メインの記事を参照してください: [[fstab#ファイルシステムの識別]]。

=== カーネルパラメータ ===

永続的な名前を[[カーネルパラメータ]]で使用するには、以下の前提条件を満たさなければなりません。[[インストールガイド]]に従った標準的なインストールでは、以下の両方の前提条件を満たしています:

* [[udev]] が含まれている [[initramfs]] イメージを使用していること
* [[mkinitcpio]] の場合、{{ic|udev}} か {{ic|systemd}} のどちらか一方の[[Mkinitcpio#HOOKS|フック]]を {{ic|/etc/mkinitcpio.conf}} で有効化していること

ルートファイルシステムの場所はカーネルコマンドラインで {{ic|root}} パラメータを使って渡します。カーネルコマンドラインは[[ブートローダー]]から設定します。[[カーネルパラメータ#ブートローダーの設定]] を参照してください。永続的なデバイスの命名に変更するには、ブロックデバイスを指定するパラメータ (例: {{ic|root}} と {{ic|resume}}) のみを変更して、他のパラメータはそのままにしてください。様々な命名規則がサポートされています:

[[#by-label|ラベルを用いた]]デバイスの永続的な命名と {{ic|1=LABEL=}} 形式。以下の例では、{{ic|Arch Linux}} がルートファイルシステムの LABEL になっています:

root="LABEL=Arch Linux"

[[#by-uuid|UUID を用いた]]デバイスの永続的な命名と {{ic|1=UUID=}} 形式。以下の例では、{{ic|0a3407de-014b-458b-b5c1-848e92a327a3}} がルートファイルシステムの UUID になっています:

root=UUID=0a3407de-014b-458b-b5c1-848e92a327a3

[[#by-id と by-path|ディスク id を用いた]]デバイスの永続的な命名と {{ic|/dev}} パス形式。以下の例では、{{ic|wwn-0x60015ee0000b237f-part2}} がルートパーティションの id になっています。

root=/dev/disk/by-id/wwn-0x60015ee0000b237f-part2

[[#by-partuuid|GPT パーティション UUID を用いた]]デバイスの永続的な命名と {{ic|1=PARTUUID=}} 形式。以下の例では、{{ic|98a81274-10f7-40db-872a-03df048df366}} がルートパーティションの PARTUUID になっています。

root=PARTUUID=98a81274-10f7-40db-872a-03df048df366

[[#by-partlabel|GPT パーティションラベルを用いた]]デバイスの永続的な命名と {{ic|1=PARTLABEL=}} 形式。以下の例では、{{ic|GNU/Linux}} がルートパーティションの PARTLABEL になっています。

root="PARTLABEL=GNU/Linux"

[[#gpt-auto|GPT パーティションの自動マウント]]を使用している場合、{{ic|1=root=}} パラメータは省略できます。明示的に設定したい場合は、以下を使用してください:

root=gpt-auto

{{TranslationStatus|Persistent block device naming|2025-06-29|838910}}

ハードウェアビデオアクセラレーション

2025-06-29T04:55:33Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[en:Hardware video acceleration]]
[[ru:Hardware video acceleration]]
[[zh-hans:Hardware video acceleration]]
[[Wikipedia:Graphics processing unit#GPU accelerated video decoding and encoding|ハードウェアビデオアクセラレーション]]により、ビデオカードで動画をデコード/エンコードすることができ、CPU の負担を下げて電力を節約することができます。

Linux でこれを実現する方法は複数存在します:

* [[Wikipedia:Video Acceleration API|Video Acceleration API]] (VA-API) はハードウェア支援による動画エンコード・デコードの両方を実現する仕様とオープンソースライブラリです。Intel によって開発されました。
* [[Wikipedia:VDPAU|Video Decode and Presentation API for Unix]] (VDPAU) は GPU ビデオハードウェアに動画のデコードやポストプロセス処理をオフロードするオープンソースのライブラリです。NVIDIA によって開発されました。
* [https://gpuopen.com/advanced-media-framework/ Advanced Media Framework SDK] (AMF) は、[[AMDGPU PRO]] を使用してマルチメディア処理のために AMD GPU に「部分的に」アクセスできるようにするオープンソースのフレームワークです。AMD によって開発されました。
* [[Wikipedia:Nvidia NVDEC|NVDEC]]/[[Wikipedia:Nvidia NVENC|NVENC]] - Fermi 以降の NVIDIA GPU によって使われている、ハードウェアビデオアクセラレーションのためのプロプライエタリ API。
* [https://www.khronos.org/blog/an-introduction-to-vulkan-video Vulkan Video] は、ハードウェアアクセラレートされたビデオエンコードとデコードをサポートするために開発された [[Vulkan]] グラフィックス API の拡張です。

ドライバとアプリケーションのサポートの包括的な概要については、[[#比較一覧]] を参照してください。

== インストール ==

=== Intel ===

==== VA-API ====

[[Intel Graphics]] オープンソースドライバーは VA-API に対応しています:

* [https://github.com/intel/media-driver/#supported-platforms Broadwell] [[wikipedia:Template:Intel_processor_roadmap|(2014)]] 及びそれ以降の HD Graphics シリーズ (例: Intel Arc) は {{Pkg|intel-media-driver}} によってサポートされています。
* [[wikipedia:Coffee_Lake|Coffee Lake]] (2017) までの GMA 4500 (2008) は {{Pkg|libva-intel-driver}} によってサポートされています。
* [[Wikipedia:Haswell (microarchitecture)#Haswell Refresh|Haswell Refresh]] から Skylake までの VP9 デコードと、Broadwell から Skylake までのハイブリッド VP8 エンコードは {{AUR|intel-hybrid-codec-driver-git}} によってサポートされています。

{{Note|Skylake 及びそれ以降は {{Pkg|linux-firmware}} も必要です。}}

[https://www.intel.com/content/www/us/en/developer/articles/technical/linuxmedia-vaapi.html VAAPI がサポートするハードウェアと機能] もご覧ください。

==== Vulkan ====

ANV オープンソース [[vulkan]] ドライバは、{{Pkg|vulkan-intel}} 経由で Vulkan Video のサポートを提供しています。

{{Note|Vulkan Video を有効化するには、追加の設定が必要です。[[#Vulkan Video の設定]] を参照してください。}}

==== Intel Video Processing Library (Intel VPL) ====

[https://github.com/intel/libvpl Intel VPL] を使用するには、ベースライブラリである {{Pkg|libvpl}} に加えて、以下のランタイム実装のうち少なくとも一つを[[インストール]]してください:

* {{Pkg|vpl-gpu-rt}}: Tiger Lake 及びそれ以降の GPU に対するサポートを提供します
* {{Pkg|intel-media-sdk}} (開発中止): それより古い Intel GPU に対するサポートを提供します

=== NVIDIA ===

[[Nouveau]] オープンソースドライバーは VA-API と VDPAU に対応しています:

* GeForce GTX 750 までの GeForce 8 シリーズ及びそれ以降の GPU は {{Pkg|mesa}} によってサポートされています。
* (現在 NVIDIA のバイナリドライバーから抽出される) {{AUR|nouveau-fw}} ファームウェアパッケージが [https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware 必要] です。

[[NVIDIA]] プロプライエタリドライバは {{Pkg|nvidia-utils}} によってサポートされています:

* [[Wikipedia:GeForce 8 series|GeForce 8 シリーズ]]及びそれ以降の GPU における VDPAU
* [[Wikipedia:Fermi_(microarchitecture)|Fermi]] 及びそれ以降の GPU における NVDEC [https://developer.download.nvidia.com/assets/cuda/files/NVIDIA_Video_Decoder.pdf]
* [[Wikipedia:Kepler_(microarchitecture)|Kepler]] 及びそれ以降の GPU における NVENC
* [[Wikipedia:Pascal_(microarchitecture)|Pascal]] 及びそれ以降の GPU における Vulkan Video [https://developer.nvidia.com/vulkan/video/get-started]

=== AMD/ATI ===

[[AMD]] と [[ATI]] オープンソースドライバーは {{Pkg|mesa}} によって VA-API と VDPAU をサポートしています:

* VA-API は Radeon HD 2000 及びそれ以降の GPU。
* VDPAU は Radeon R600 及びそれ以降の GPU。

RADV オープンソース [[vulkan]] ドライバは、{{Pkg|vulkan-radeon}} 経由で Vulkan Video サポートを提供しています。

[[AMDGPU PRO]] プロプライエタリドライバーは AMDGPU ドライバー上で動作し、AMF に加えて VA-API と VDPAU に対応しています。

* [[Wikipedia:Radeon Rx 300 series|Fiji]] 及びそれ以降の GPU における AMF は {{AUR|amf-amdgpu-pro}} によってサポートされています。

{{Note|
* 場合によっては、あなたのアプリケーションが [[AMDGPU PRO]] [[Vulkan]] ドライバを使用するように強制する必要があります。
* [[Wikipedia:High Efficiency Video Coding|HEVC]] エンコードは [[Wikipedia:Radeon RX 5000 series|Navi]] より古い GPU では利用できない場合があります。
}}

=== 変換レイヤー ===

* {{App|libvdpau-va-gl|OpenGL/VAAPI バックエンドを用いた VDPAU ドライバ。H.264 のみ。|https://github.com/i-rinat/libvdpau-va-gl|{{Pkg|libvdpau-va-gl}}}}
* {{App|nvidia-vaapi-driver|VA-API を提供する [[CUDA]] NVDEC ベースのバックエンド。|https://github.com/elFarto/nvidia-vaapi-driver/|{{Pkg|libva-nvidia-driver}}}}

{{Note|{{Pkg|libva-nvidia-driver}} 実装によってハードウェアビデオデコードを使えるようにはなりますが、NVIDIA の電源管理に対する現状の制限により、[https://github.com/elFarto/nvidia-vaapi-driver/issues/74 CPU によるビデオデコードよりも多くの電力を消費します]。}}

== 確認 ==

設定せずともシステムが完璧に動作する場合があります。なので、このセクションから読み始めて、システムの確認をすると良いでしょう。

{{Tip|
* コマンドラインサポートのある [[mpv#ハードウェアデコード|mpv]] は、ハードウェアアクセラレーションをテストするのにぴったりです。{{ic|1=mpv --hwdec=auto ''video_filename''}} のログを見てください。詳細は [https://mpv.io/manual/stable/#options-hwdec hwdec] を参照。
* AMD、Intel、そして NVIDIA の場合、動画を再生しながら {{Pkg|nvtop}} を使うことで "DEC" (デコーダ) の使用率を確認できます。
* Intel GPU の場合、{{pkg|intel-gpu-tools}} を使って、{{ic|intel_gpu_top}} を root として実行することで、ビデオプレイバック中に GPU 使用率をモニタできます。ビデオバーが 0% よりも上にあれば、GPU のビデオデコーダ/エンコーダが使用されていることを示します。([[インテルグラフィックス#試験的な新しい Xe ドライバをテストする|新しい Xe ドライバ]]を使用している場合、{{ic|intel_gpu_top}} が[https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/174 エラーを出します]。確認するには {{ic|gputop}} を実行してみてください。[https://dri.freedesktop.org/docs/drm/gpu/i915.html#intel-gpu-basics vcs (Video Command Streamer) の値]が 0% より大きければ、GPU 動画デコード/エンコードが使用されていることを意味します。)
* AMD GPU の場合、{{Pkg|radeontop}} を使用して GPU 使用率をモニタできます。{{pkg|intel-gpu-tools}} とは違い、現在 {{Pkg|radeontop}} でデコード/エンコードの仕様状況を確認する方法はありません [https://github.com/clbr/radeontop/issues/29]。
* 任意の GPU において、{{Pkg|htop}} のようなツールで CPU 使用率を比較できます。特に、高解像度なビデオ (4k 以上) において、VA-API が有効化されていて動作しているときの CPU 使用率は、ノート PC や他の比較的低電力なデバイスにおいて劇的に低いはずです。
}}

=== VA-API の確認 ===

VA-API の設定は {{Pkg|libva-utils}} パッケージに含まれている {{ic|vainfo}} を実行することで確認できます:

{{hc|$ vainfo|<nowiki>
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.7.3
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
</nowiki>}}

あなたのカードを使ってデコードできるフォーマットが {{ic|VAEntrypointVLD}} で、エンコードできるフォーマットが {{ic|VAEntrypointEncSlice}} で示されます。

上の例では、以下の行があることから {{ic|i965}} ドライバーが使われていることが確認できます:

vainfo: Driver version: Intel '''i965''' driver for Intel(R) Skylake - 1.7.3

{{ic|vainfo}} を実行したときに以下のようなエラーが表示される場合:

libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

適切なドライバーを設定する必要があります。[[#VA-API の設定]] を見てください。

=== VDPAU の確認 ===

{{pkg|vdpauinfo}} をインストールしてから、以下のコマンドを実行してください。VDPAU ドライバーがロードされていることや、現在の設定が確認できます:

{{hc|$ vdpauinfo|<nowiki>
display: :0 screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name width height types
-------------------------------------------
420 16384 16384 NV12 YV12
422 16384 16384 UYVY YUYV
444 16384 16384 Y8U8V8A8 V8U8Y8A8

Decoder capabilities:

name level macbs width height
----------------------------------------------------
MPEG1 --- not supported ---
MPEG2_SIMPLE 3 9216 2048 1152
MPEG2_MAIN 3 9216 2048 1152
H264_BASELINE 41 9216 2048 1152
H264_MAIN 41 9216 2048 1152
H264_HIGH 41 9216 2048 1152
VC1_SIMPLE 1 9216 2048 1152
VC1_MAIN 2 9216 2048 1152
VC1_ADVANCED 4 9216 2048 1152
...
</nowiki>}}

=== Vulkan Video の確認 ===

{{pkg|vulkan-tools}} をインストールし、''vulkaninfo'' を使ってビデオ処理拡張が利用可能であるかを確認してください:

{{hc|$ vulkaninfo {{!}} grep VK_KHR_video_|<nowiki>
VK_KHR_video_decode_av1 : extension revision 1
VK_KHR_video_decode_h264 : extension revision 9
VK_KHR_video_decode_h265 : extension revision 8
VK_KHR_video_decode_queue : extension revision 8
VK_KHR_video_encode_h264 : extension revision 14
VK_KHR_video_encode_h265 : extension revision 14
VK_KHR_video_encode_queue : extension revision 12
VK_KHR_video_maintenance1 : extension revision 1
VK_KHR_video_queue : extension revision 8
</nowiki>}}

== 設定 ==

ビデオドライバは VA-API と VDPAU の両方に対してハードウェアビデオアクセラレーションのサポートを自動的に有効化するはずですが、場合によっては手動で VA-API/VDPAU を手動で設定する必要があります。[[#確認]] セクションを見た場合にのみ、このセクションを読み進めてください。

(他に設定が存在しない場合に使用される) デフォルトのドライバ名はシステムによって推測されます。しかし、それらはしばしばトリッキーで、機能しないこともあります。推測された値は [[Xorg]] のログファイルに出力されます。ログファイルは、Xorg が rootless の場合は {{ic|~/.local/share/xorg/Xorg.0.log}}、Xorg が root として実行されている場合は {{ic|/var/log/Xorg.0.log}} です。ログファイルからある値を検索するには:

{{hc|$ grep -iE 'vdpau {{!}} dri driver' ''xorg_のログファイル''|
(II) RADEON(0): [DRI2] DRI driver: radeonsi
(II) RADEON(0): [DRI2] VDPAU driver: radeonsi
}}

この出力の場合、{{ic|radeonsi}} が VA-API と VDPAU のデフォルトです。

{{Note|[[GDM]] を使用している場合、代わりに {{ic|1=journalctl -b --grep='vdpau {{!}} dri driver'}} を root として実行してください。}}

しかし、これは ''設定'' を表すものではありません。上記の値は、オーバーライドしたとしても変更されません。

=== VA-API の設定 ===

{{ic|LIBVA_DRIVER_NAME}} [[環境変数]] を使うことで、VA-API 用に使用するドライバをオーバーライドできます:

* [[Intel Graphics]]:
** {{Pkg|libva-intel-driver}} の場合は {{ic|i965}} を使ってください。
** {{Pkg|intel-media-driver}} の場合は {{ic|iHD}} を使ってください。
* NVIDIA:
** [[Nouveau]] の場合は {{ic|nouveau}} を使ってください。
** [[NVIDIA]] NVDEC の場合は {{ic|nvidia}} を使ってください。
* AMD:
** [[AMDGPU]] ドライバの場合は {{ic|radeonsi}} を使ってください。

{{Note|
* インストールされているドライバーは {{ic|/usr/lib/dri/}} ディレクトリを見ることで確認できます。{{ic|/usr/lib/dri/'''${LIBVA_DRIVER_NAME}'''_drv_video.so}} として使われます。
* 一部のドライバーは互換性を保つために異なる名前を使っていることがあります。{{ic|sha1sum /usr/lib/dri/* {{!}} sort}} を実行することで確認できます。
* {{ic|LIBVA_DRIVERS_PATH}} を使うことで VA-API ドライバーのパスを上書きできます。
* バージョン 12.0.1 から Mesa は {{ic|gallium}} の代わりとして {{ic|radeonsi}} を提供しています。
}}

=== VDPAU の設定 ===

{{ic|VDPAU_DRIVER}} [[環境変数]]を使うことで、VDPAU 用に使用するドライバをオーバーライドできます。

適切なドライバ名は、あなたのセットアップに依存します:

* Intel graphics の場合、{{ic|va_gl}} に設定する[[#Failed to open VDPAU backend|必要があります]]。
* オープンソースの AMD ドライバの場合、{{ic|radeonsi}} に設定してください。
* オープンソースの Nouveau ドライバの場合、{{ic|nouveau}} に設定してください。
* NVIDIA のプロプライエタリなバージョンの場合、{{ic|nvidia}} に設定してください。

{{Note|
* インストールされているドライバーは {{ic|/usr/lib/vdpau/}} ディレクトリを見ることで確認できます。{{ic|/usr/lib/vdpau/libvdpau_'''${VDPAU_DRIVER}'''.so}} として使われます。
* 一部のドライバーは互換性を保つために異なる名前を使っていることがあります。{{ic|sha1sum /usr/lib/vdpau/*}} を実行することで確認できます。
* ハイブリッド構成 (NVIDIA と AMD の両方のカードが搭載されている) 場合、{{ic|DRI_PRIME}} [[環境変数]]を設定する必要があるかもしれません。詳しくは [[PRIME]] を参照。
}}

=== Vulkan Video の設定 ===

* [[インテルグラフィックス]]: {{Pkg|vulkan-intel}} の Vulkan Video サポートは {{ic|1=ANV_DEBUG=video-decode,video-encode}} [[環境変数]]で有効化できます。
* [[AMD]]: {{Pkg|vulkan-radeon}} の Vulkan Video サポートは、Mesa 25 以降、VCN 2、3、4+ ではデフォルトで有効化されています。それより古いカードでサポートを強制的に有効化するには、{{ic|RADV_PERFTEST}} [[環境変数]]に {{ic|video_decode,video_encode}} を設定してください。

=== アプリケーションの設定 ===

マルチメディアフレームワーク:

* [[FFmpeg#ハードウェアビデオアクセラレーション]]
* [[GStreamer#ハードウェアアクセラレーション]]

ビデオプレイヤ:

* [[Kodi#ヒントとテクニック]]
* [[MPlayer#ハードウェアアクセラレーション]]
* [[mpv#ハードウェアデコード]]
* [[VLC media player#ハードウェアアクセラレーションのサポート]]

ウェブブラウザ:

* [[Chromium#ハードウェアビデオアクセラレーション]]
* [[Firefox#ハードウェアビデオアクセラレーション]]
* [[GNOME Web#ハードウェアアクセラレーション]]

マルチメディア録画/ストリーミング:

* [[Open Broadcaster Software#ハードウェアアクセラレーション]]

== トラブルシューティング ==

=== Failed to open VDPAU backend ===

適切なドライバを指すように {{ic|VDPAU_DRIVER}} 変数を設定する必要があります。[[#VDPAU の設定]] を参照。

=== VAAPI init failed ===

エラーは {{ic|libva: /usr/lib/dri/i965_drv_video.so init failed}} という行で確認できます。[[Wayland]] が正しく認識されていないことが原因で発生します。{{ic|$DISPLAY}} の設定を解除することで mpv, MPlayer, VLC などは X11 であると誤認しないようになります。mpv の場合は {{ic|1=--gpu-context=wayland}} パラメータを追加することでも解決できます。

このエラーは、あなたのハードウェアに合わない VA-API ドライバをインストールした場合にも起こりえます。

=== AMDGPU ドライバーを使用したビデオデコード時の破損や歪み ===

[[AMDGPU]] ドライバーでビデオデコードの破損または歪みが発生する場合は、{{ic|1=allow_rgb10_configs=false}} [[環境変数]]を設定してください。[https://bugs.freedesktop.org/show_bug.cgi?id=106490]

== 比較一覧 ==

=== VA-API ドライバ ===

{| class="wikitable" style="text-align:center;"
! コーデック
! {{pkg|libva-intel-driver}} [https://github.com/01org/intel-vaapi-driver/blob/master/README]
! {{pkg|intel-media-driver}} [https://github.com/intel/media-driver/blob/master/README.md]
! {{pkg|mesa}} [https://www.x.org/wiki/RadeonFeature/] [https://nouveau.freedesktop.org/wiki/VideoAcceleration/]
! {{Pkg|libva-nvidia-driver}} (NVDEC アダプタ)
|-
! colspan=5 | デコード
|-
! MPEG-2
| {{G|GMA 4500 以降}}
| {{G|Broadwell 以降}}
| {{G|Radeon HD 6000 以降 GeForce 8 以降1}}
| rowspan=10 | [[#NVIDIA ドライバのみ]] を参照
|-
! H.263/MPEG-4 Visual3
| {{No}}
| {{No}}
| {{G|Radeon HD 6000 以降}}
|-
! VC-1
| {{G|Sandy Bridge 以降}}
| rowspan=2 {{G|Broadwell 以降}}
| {{G|Radeon HD 2000 以降 GeForce 9300 以降1}}
|-
! H.264/MPEG-4 AVC
| {{G|Ironlake 以降}}
| {{G|Radeon HD 2000 以降 GeForce 8 以降1}}
|-
! H.265/HEVC 8bit
| {{G|Cherryview/Braswell 以降}}
| {{G|Skylake 以降}}
| {{G|Radeon R9 Fury 以降}}
|-
! H.265/HEVC 10bit
| {{G|Broxton 以降}}
| {{G|Broxton/Apollo Lake 以降}}
| {{G|Radeon 400 以降}}
|-
! VP8
| {{G|Broadwell 以降}}
| {{G|Broadwell 以降}}
| {{No}}
|-
! VP9 8bit
| {{G|Broxton 以降 Hybrid: Haswell refresh から Skylake2}}
| {{G|Broxton/Apollo Lake 以降}}
| rowspan=2 {{G|Raven Ridge + Radeon RX 5000 以降}}
|-
! VP9 10bit & 12bit
| {{G|Kaby Lake 以降}}
| {{G|Kaby Lake 以降}}
|-
! AV1 8bit & 10bit
| {{No}}
| {{G|Tiger Lake 以降}}
| {{G|Radeon RX 6600 以上/以降}}
|-
! colspan=5 | エンコード
|-
! MPEG-2
| {{G|Ivy Bridge 以降}}
| {{G|Broadwell 以降 Broxton/Apollo Lake を除く}}
| {{No}}
| rowspan=8 {{No}}4
|-
! H.264/MPEG-4 AVC
| {{G|Sandy Bridge 以降}}
| {{G|Broadwell 以降}}
| {{G|Radeon HD 7000 以降}}
|-
! H.265/HEVC 8bit
| {{G|Skylake 以降}}
| {{G|Skylake 以降}}
| {{G|Radeon 400 以降}}
|-
! H.265/HEVC 10bit
| {{G|Kaby Lake 以降}}
| rowspan=2 {{G|Kaby Lake 以降}}
| {{G|Raven Ridge + Radeon RX 5000 以降}}
|-
! VP8
| {{G|Cherryview/Braswell 以降 Hybrid: Haswell から Skylake2}}
| rowspan=3 {{No}}
|-
! VP9 8bit
| {{G|Kaby Lake 以降}}
| rowspan=2 {{G|Ice Lake 以降}}
|-
! VP9 10bit & 12bit
| rowspan=2 {{No}}
|-
! AV1 8bit & 10bit
| {{G|Alchemist 以降}}
| {{G|Radeon RX 7900 以上/以降}}
|}

# GeForce GTX 750 まで。
# Hybrid VP8 エンコーダと VP9 デコーダは {{AUR|intel-hybrid-codec-driver-git}} によってサポートされています。
# MPEG-4 Part 2 は VAAPI の制限のためデフォルトで無効化されています。使用してみるには、{{ic|1=VAAPI_MPEG4_ENABLED=true}} [[環境変数]]を設定してください。
# NVIDIA CUDA アダプタコーデックのサポートは活発に開発中であり、これは変更される可能性があります [https://github.com/elFarto/nvidia-vaapi-driver/issues/116]。

=== VDPAU ドライバ ===

{| class="wikitable" style="text-align:center;"
! コーデック
! 色深度
! {{pkg|mesa}} [https://www.x.org/wiki/RadeonFeature/] [https://nouveau.freedesktop.org/wiki/VideoAcceleration/]
! {{pkg|nvidia-utils}}
! {{pkg|libvdpau-va-gl}} (VA-API アダプタ)
|-
! colspan=5 | デコード
|-
! MPEG-2
! 8bit
| {{G|Radeon R600 以降 GeForce 8 以降1}}
| {{G|GeForce 8 以降}}
| rowspan=3 {{No}}
|-
! H.263/MPEG-4 Visual
! 8bit
| {{G|Radeon HD 6000 以降 GeForce 200 以降1}}
| {{G|GeForce 200 以降}}
|-
! VC-1
! 8bit
| {{G|Radeon HD 2000 以降 GeForce 9300 以降1}}
| {{G|GeForce 8 以降2}}
|-
! H.264/MPEG-4 AVC
! 8bit
| {{G|Radeon HD 2000 以降 GeForce 8 以降1}}
| {{G|GeForce 8 以降}}
| [[#VA-API ドライバ]] を参照
|-
! rowspan=2 | H.265/HEVC
! 8bit
| {{G|Radeon R9 Fury 以降}}
| {{G|GeForce 900 以降3}}
| rowspan=6 {{No}}
|-
! 10bit
| {{G|Radeon 400 以降}}
| {{No}}4
|-
! rowspan=2 | VP9
! 8bit
| rowspan=2 {{G|Raven Ridge + Radeon RX 5000 以降}}
| {{G|GeForce 900 以降3}}
|-
! 10bit/12bit
| {{No}}4
|-
! rowspan=2 | AV1
! 8bit
| rowspan=2 {{G|Radeon RX 6600 以上/以降}}
| {{G|GeForce 30 以降}}5
|-
! 10bit
| {{No}}4
|}

# GeForce GTX 750 まで。
# GeForce 8800 Ultra、8800 GTX、8800 GTS (320/640 MB) は[[Wikipedia:Nvidia PureVideo|除く]]。
# GeForce GTX 970 と GTX 980 は除く。
# NVIDIA の実装は8ビットストリームまでに制限されています [https://forums.developer.nvidia.com/t/vdpau-expose-hevc-main10-support-where-available-on-die/43163] [https://us.download.nvidia.com/XFree86/Linux-x86_64/410.57/README/vdpausupport.html#vdpau-implementation-limits]。
# ドライババージョン 510 から [https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-510-Linux-Beta]

=== NVIDIA ドライバのみ ===

{| class="wikitable" style="text-align:center;"
! rowspan=2 | コーデック
! colspan=2 | {{Pkg|nvidia-utils}} [https://developer.nvidia.com/nvidia-video-codec-sdk]
|-
! NVDEC
! NVENC
|-
! MPEG-2
| rowspan=3 {{G|Fermi 以降1}}
| rowspan=2 {{No}}
|-
! VC-1
|-
! H.264/MPEG-4 AVC
| {{G|Kepler 以降2}}
|-
! H.265/HEVC 8bit
| rowspan=2 {{G|Maxwell (GM206) 以降}}
| {{G|Maxwell (2nd Gen) 以降}}
|-
! H.265/HEVC 10bit
| {{G|Pascal 以降}}
|-
! VP8
| {{G|Maxwell (2nd Gen) 以降}}
| rowspan=3 {{No}}
|-
! VP9 8bit
| {{G|Maxwell (GM206) 以降}}
|-
! VP9 10bit & 12bit
| {{G|Pascal 以降}}
|-
! AV1 8bit & 10bit
| {{G|Ampere 以降3}}
| {{G|Ada Lovelace 以降}}
|}

# GM108 は除く (未サポート)
# GM108 と GP108 は除く (未サポート)
# A100 は除く (未サポート)

=== アプリケーションサポート ===

{| class="wikitable"
! rowspan=2 | アプリケーション
! colspan=4 | デコード
! colspan=3 | エンコード
! rowspan=2 | ドキュメント
|-
! VA-API
! VDPAU
! NVDEC
! Vulkan
! VA-API
! NVENC
! Vulkan
|-
! [[FFmpeg]]
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| [[FFmpeg#ハードウェアビデオアクセラレーション]]
|-
! [[GStreamer]]
| {{Yes}}
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{No|1=https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7197}}
| [[GStreamer#ハードウェアアクセラレーション]]
|-
! [[Kodi]]
| {{Yes}}
| {{Yes}}
| {{No}}
| {{No}}
| {{-}}
| {{-}}
| {{-}}
| [[Kodi#ヒントとテクニック]]
|-
! [[mpv]]
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{-}}
| {{-}}
| {{-}}
| [[mpv#ハードウェアデコード]]
|-
! [[VLC media player]]
| {{Yes}}
| {{Yes}}
| {{No}}
| {{No|1=https://code.videolan.org/videolan/vlc/-/issues/28362}}
| {{-}}
| {{-}}
| {{-}}
| [[VLC media player#ハードウェアアクセラレーションのサポート]]
|-
! [[MPlayer]]
| {{No}}
| {{Yes}}
| {{No}}
| {{No}}
| {{-}}
| {{-}}
| {{-}}
| [[MPlayer#ハードウェアアクセラレーション]]
|-
! [[Flash]]
| {{No}}1
| {{Yes}}1
| {{No}}
| {{No}}
| {{-}}
| {{-}}
| {{-}}
| [[ブラウザプラグイン#Adobe Flash Player]]
|-
! [[Chromium]]
| {{Yes}}
| {{No}}
| {{No}}
| {{No}}
| {{Yes}}
| {{No}}
| {{No}}
| [[Chromium#ハードウェアビデオアクセラレーション]]
|-
! [[Firefox]]
| {{Yes}}
| {{No}}
| {{No}}
| {{No|1=https://bugzilla.mozilla.org/show_bug.cgi?id=1753129}}
| {{No|1=https://bugzilla.mozilla.org/show_bug.cgi?id=1658900}}
| {{No}}
| {{No}}
| [[Firefox#ハードウェアビデオアクセラレーション]]
|-
! [[GNOME/Web]]
| colspan=4 {{C|GStreamer}}
| {{C|?}}
| {{C|?}}
| {{C|?}}
| [[GNOME Web#ビデオ]]
|}

# VDPAU は NPAPI プラグインによってのみサポートされています。部分的な VA-API と VDPAU アクセラレーションを提供する、PPAPI プラグインから NPAPI ブラウザへの実験的なアダプタが利用できます。

{{TranslationStatus|Hardware video acceleration|2025-06-29|838872}}

CPU 周波数スケーリング

2025-06-28T11:08:12Z

AshMyzk: 同期

[[Category:電源管理]]
[[Category:CPU]]
[[de:Cpufrequtils]]
[[en:CPU frequency scaling]]
[[fr:CPU frequency scaling]]
[[pt:CPU frequency scaling]]
[[zh-hans:CPU frequency scaling]]
{{Related articles start}}
{{Related|省電力設定}}
{{Related|Laptop Mode Tools}}
{{Related|CPU の低電圧化}}
{{Related articles end}}

[https://docs.kernel.org/admin-guide/pm/cpufreq.html CPU パフォーマンススケーリング]により、オペレーティングシステムは消費電力の削減やパフォーマンスの向上のために CPU の周波数を上げ下げすることができるようになります。スケーリングは、システムの負荷に応じて自動的に行ったり、ACPI イベントに応じて調整したり、ユーザスペースのプログラムで手動で変更したりできます。

Linux カーネルは ''CPUFreq'' サブシステムを通して CPU パフォーマンススケーリングを提供します。このサブシステムには2つの抽象化レイヤが定義されています:

* [[#スケーリングガバナー|スケーリングガバナー]]は、望ましい CPU 周波数を計算するアルゴリズムを実装します。システムのニーズに基づいている可能性があります。
* [[#スケーリングドライバ|スケーリングドライバ]]は、直接 CPU と対話し、現在のガバナーの要求する望ましい周波数に変更します。

デフォルトのスケーリングドライバとスケーリングガバナーは自動的に選択されますが、[[#cpupower|cpupower]] や [[acpid]]、[[Laptop Mode Tools]]、デスクトップ環境によって提供されている GUI ツールなどのユーザスペースのツールでも高度な設定をすることができます。

== ユーザースペースツール ==

=== i7z ===

{{Pkg|i7z}} は Linux 向けの i7 (現在は、i3、i5、i7、i9) CPU レポートツールです。{{ic|i7z}} コマンドでターミナルから実行することができ、GUI は {{ic|i7z-gui}} で起動できます。

=== turbostat ===

{{Pkg|turbostat}} は最近の Intel と AMD の CPU の周波数、消費電力、アイドル状態、その他の統計情報を表示することができます。

=== cpupower ===

{{Pkg|cpupower}} は CPU 周波数スケーリングを補助するように作られたユーザースペースのユーティリティの集まりです。このパッケージがなくてもスケーリングを使うことはできますが、便利なコマンドラインユーティリティや起動時にガバナーを変えるための [[systemd]] のサービスが入っているためインストールすることが推奨されています。

''cpupower'' の設定ファイルは {{ic|/etc/default/cpupower}} です。この設定ファイルは {{ic|/usr/lib/systemd/scripts/cpupower}} 内の bash スクリプトによって読み込まれます。bash スクリプトは {{ic|cpupower.service}} と ''systemd'' によって有効にされます。ブート時に起動するには {{ic|cpupower.service}} を[[有効化]]してください。

=== thermald ===

{{Pkg|thermald}} は、Intel CPU のオーバーヒートを防止するために使用される [https://github.com/intel/thermal_daemon Linux デーモン]です。このデーモンは P-state、T-state、および Intel power clamp ドライバを使用してサーマルパラメータを積極的に制御します。最新のドライバが利用できない場合、デーモンはシステムの冷却を制御するために x86 モデル固有のレジスタと Linux の "cpufreq サブシステム" に戻り、システムの冷却を制御します。

デフォルトでは、このデーモンは利用可能な CPU デジタル温度センサーを使って CPU 温度を監視し、ハードウェアが積極的な補正動作を行う前に CPU 温度を制御下に維持します。thermal sysfs に皮膚温度センサーがある場合、皮膚温度を 45C 以下に保とうと試みます (訳注: ここでの皮膚温度 (skin temperature) とは、ユーザがデバイスを持ったときに感じる温度のことです)。

Tiger Lake ラップトップ (例: [https://wiki.archlinux.org/title/Dell_Latitude_3420 Dell Latitude 3420]) では、このデーモンは、他の方法で利用できるものよりも [https://www.phoronix.com/review/intel-thermald-tgl 多くのパフォーマンスを解放する] と報告されています。

関連する systemd ユニットは {{ic|thermald.service}} です。このサービスは[[起動]]され、かつ[[有効化]]されている必要があります。詳細については、{{man|8|thermald}} を参照してください。

=== power-profiles-daemon ===

{{Pkg|power-profiles-daemon}} の ''powerprofilesctl'' コマンドラインツールは {{ic|power-profiles-daemon}} サービスを通して電源プロファイル (省電力、バランス、パフォーマンスなど) を扱います。GNOME と KDE もプロファイル切り替えのための [https://gitlab.freedesktop.org/upower/power-profiles-daemon#how-to-use グラフィカルインターフェイス] を提供しています。以下を参照してください:

* [[GNOME#電源モード]]
* [[KDE#電源管理]]

使い方や使用例、類似プロジェクトとの比較などについては、[https://gitlab.freedesktop.org/upower/power-profiles-daemon#power-profiles-daemon プロジェクトの README] を参照してください。

{{ic|power-profiles-daemon}} サービスを [[起動/有効化]] してください。''powerprofilesctl'' が起動されると、サービスも起動しようとすることに注意してください ({{ic|dbus.service}} の [[ユニットステータス]] を見てください。)

{{Note|
* ''power-profiles-daemon'' は、[[TLP]] や {{Pkg|tuned}}、{{AUR|system76-power}} といった他の電源管理サービスと[https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/blob/main/data/power-profiles-daemon.service.in#L3 衝突]します。(潜在的に依存関係にあるため) ''power-profiles-daemon'' を [[アンインストール]] せずに前述のサービスのどれかを代わりに使用するには、{{ic|power-profiles-daemon}} サービスを [[マスク]] して無効化してください ([https://github.com/linrunner/TLP/issues/564]、[https://linrunner.de/tlp/installation/arch.html#service-units] も参照。)
* [[#tuned|tuned]] は、バージョン 2.23.0 以降、''power-profiles-daemon'' 用の ''tuned-ppd'' サービス互換性レイヤーを提供するようになりました。
}}

=== tuned ===

{{Pkg|tuned}} は、システムデバイスの監視と適応チューニングのためのデーモンです。GPU 電力モード、PCIe 電力管理、sysctl 設定の設定、カーネルスケジューリングの調整などを行うことができます。システム内の電源管理の設定も行います。

[https://github.com/redhat-performance/tuned/releases/tag/v2.23.0#tuned release 2.23.0] の時点で、プロジェクトには {{Pkg|power-profiles-daemon}} 用に書かれたプログラムのための互換性レイヤーである {{Pkg|tuned-ppd}} が同梱されています。そのようなプログラムとしては以下があります:

* [[GNOME#電源モード]]
* [[KDE#電源管理]]

power-profiles-daemon の代わりにtuned を使用する必要がある理由については、Fedora の [https://fedoraproject.org/wiki/Changes/TunedAsTheDefaultPowerProfileManagementDaemon#Make_Tuned_the_Default_Power_Profile_Management_Daemon#see 提案] を参照して、tuned に置き換えてください。反対の議論については、[https://discussion.fedoraproject.org/t/f41-change-proposal-make-tuned-the-default-power-profile-management-daemon-system-wide/118554/29]を参照してください。

{{ic|tuned}} デーモンサービスを[[起動/有効化]]します。 power-profiles-daemon の互換性のために、{{ic|tuned-ppd}} サービスも[[起動/有効化]]します。コマンドラインから tuned を制御するには、{{ic|tuned-adm}} を使用してプロファイルを表示、設定します。

{{Note|''tuned-ppd'' は {{ic|/etc/tuned/ppd.conf}} で設定されています。プログラムが ''power-profiles-daemon'' のプロファイルを選択する際に使用される ''tuned'' プロファイルを設定するには、このファイルを編集してください。このファイルには、すべての power-profiles-daemon モードおよびバッテリー検出が含まれています。}}

=== cpupower-gui ===

{{AUR|cpupower-gui-git}} は CPU 周波数のスケーリングを支援するために設計されたグラフィカルなユーティリティです。GUI は [[GTK]] をベースにしており、''cpupower'' と同じオプションを提供することを意図しています。 ''cpupower-gui'' は、コアの有効化/無効化、及び、各コアの最大/最小の CPU 周波数とガバナーを変更することができます。このアプリケーションは [[polkit]] を通して特権付与を行い、{{ic|wheel}} [[ユーザグループ]]のログイン済みユーザであれば誰でも周波数とガバナーを変更することができます。{{ic|cpupower-gui.service}} と {{ic|cpupower-gui-user.service}} に関する詳細は [https://github.com/vagnum08/cpupower-gui?tab=readme-ov-file#systemd-units cpupower-gui systemd ユニット]を参照してください。

=== gnome-shell-extension-cpupower ===

{{AUR|gnome-shell-extension-cpupower-git}} は、CPU 周波数の最大値と最小値を変更し、周波数ブーストを有効化/無効化することのできる [[GNOME]] シェル拡張です。

=== auto-cpufreq ===

{{AUR|auto-cpufreq}} は、Linux 用の CPU 速度と電源の自動オプティマイザです。ノート PC のバッテリー状態、CPU 使用率、CPU 温度、そしてシステムの負荷をアクティブに監視します。

=== nvidia-powerd ===

''nvidia-powerd'' デーモンは、サポートされているノート PC プラットフォームにおいて [[NVIDIA]] の Dynamic Boost テクノロジのサポートを提供します。このデーモンは、システム全体の電力制御ソフトウェアとして動作し、ワークロードの要求に応じて GPU と CPU の間で電力を動的に配分しつつ、システム全体の熱予算を維持します。[https://download.nvidia.com/XFree86/Linux-x86_64/570.144/README/dynamicboost.html]

{{ic|nvidia-powerd}} サービスを[[開始/有効化]]してください。これは {{Pkg|nvidia-utils}} パッケージにあります。

{{Note|''nvidia-powerd'' の前提要件は次のとおりです: NVIDIA Ampere (及びそれより新しい) GPU あるいは Intel Comet Lake (及びそれより新しい) あるいは AMD Renoir (及びそれより新しい) チップセットのどれかを搭載しており、かつ、ファームウェアレベルの Dynamic Boost サポートが存在すること ({{ic|nvidia-settings -q DynamicBoostSupport}} で確認できます)。}}

== スケーリングドライバ ==

スケーリングドライバは、ガバナーによって指定された周波数を設定する CPU 固有の詳細を実装します。厳密に言えば、ACPI 標準は、P0 で始まって徐々に低パフォーマンスになる [[wikipedia:Advanced Configuration and Power Interface#Performance state|power-performance states (P-states)]] を要求しています。この機能は、Intel では SpeedStep と、AMD では PowerNow! と呼ばれています。

とはいえ実際には、プロセッサは固定の P-state に制限するどころか、特定の周波数を指定する方法を提供しています。スケーリングドライバは周波数の指定を処理します。

{{Note|ネイティブな CPU モジュールは自動的にロードされます。}}

''cpupower'' は、ネイティブな CPU の制限を調べるためにドライバを必要とします:

{| class="wikitable"
! ドライバ !! 説明
|-
| {{ic|acpi_cpufreq}} || ACPI Processor Performance States を使用する CPUFreq ドライバ。このドライバは Intel Enhanced SpeedStep もサポートしています (以前は、非推奨となっている {{ic|speedstep_centrino}} モジュールによってサポートされていました)。AMD Ryzen においては 3つの周波数ステートのみを提供します。
|-
| {{ic|amd_pstate}} || このドライバには3つのモード (active、passive、guided) があり、それぞれ CPU ハードウェアからの自律性の度合いに対応しています。カーネル 6.5 以降、{{ic|amd_pstate}} CPU パワースケーリングドライバは、サポートされている CPU (Zen 2 及びそれより新しい CPU) において "active mode" の場合に自動的に使用されます。詳細は [[#amd_pstate]] を参照してください。
|-
| {{ic|amd_pstate_epp}} || このドライバは、AMD Ryzen プロセッサ (Zen 2 及びそれより新しい CPU の一部) 向けの {{ic|1=amd_pstate=active}} によって選択された、内部ガバナーのあるスケーリングドライバを実装します。
|-
| {{ic|cppc_cpufreq}} || ACPI CPPC システムベースの CPUFreq ドライバ ([[#Collaborative processor performance control]] を参照)。AArch64 システムにおいて一般的なデフォルトです。最近の x86 CPU でも動作しますが、{{ic|intel_pstate}} や {{ic|amd_pstate}} ドライバのほうが優れています。
|-
| {{ic|intel_cpufreq}} || カーネル 5.7 から、intel_pstate スケーリングドライバは、ハードウェアによって管理された P-state (HWP) をサポートしていない CPU において、"passive mode" (別名 {{ic|intel_cpufreq}}) を選択します。つまり、Intel Core i シリーズの第5世代及びそれより古い CPU においてです。この "passive" ドライバは Intel CPU において ACPI ドライバと似たように動作します。ただし、ACPI の 16-pstate 制限はありません。
|-
| {{ic|intel_pstate}} || このドライバは、Intel Core プロセッサ (Sandy Bridge 及びそれより新しい CPU) 向けの内部ガバナーのあるスケーリングドライバを実装します。対象のプロセッサにおいては下記の古いドライバの代わりにこれが自動的に使用されます。このドライバは他のドライバよりも優先度が高く、モジュールではなくビルトインとなっています。{{ic|intel_pstate}} は、古い CPU において {{ic|intel_cpufreq}} 経由で "passive mode" で実行される場合があります。このドライバを使用していて問題が発生する場合は、{{ic|1=intel_pstate=disable}} をカーネルラインに追加して {{ic|acpi_cpufreq}} ドライバに戻してください。
|-
| {{ic|p4_clockmod}} || Intel Pentium 4/Xeon/Celeron プロセッサ向けの CPUFreq ドライバ。クロックをスキップすることで CPU 温度を下げます。(このドライバではなく {{ic|speedstep_lib}} を代わりに使用したほうが良いかもしれません。)
|-
| {{ic|pcc_cpufreq}} || このドライバは Hewlett-Packard と Microsoft Corporation の Processor Clocking Control インターフェイスをサポートしています。これは一部の ProLiant サーバーにおいて有用です。
|-
| {{ic|powernow_k8}} || K8/K10 Athlon 64/Opteron/Phenom プロセッサ向けの CPUFreq ドライバ。Linux 3.7 以降、より最近の AMD CPu においては 'acpi_cpufreq' が自動的に使用されます。
|-
| {{ic|speedstep_lib}} || Intel SpeedStep のあるプロセッサ (主に Atom と古い Pentium) 向けの CPUFreq ドライバ。
|}

{{Accuracy|1=以下のコマンドはモジュールとして組み込まれているドライバしか出力せず、ビルトインのもの (例えば [https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/blob/main/config?ref_type=heads#L711 intel_pstate と amd_pstate]) は出力されません。}}

利用可能なモジュールの完全なリストを表示するには、次を実行してください:

$ ls /usr/lib/modules/$(uname -r)/kernel/drivers/cpufreq/

適切なモジュールをロードしてください (詳しくは[[カーネルモジュール]]を見て下さい)。適切な cpufreq ドライバーがロードされていれば、次のコマンドで CPU の詳細が表示されます:

$ cpupower frequency-info

=== 最大・最小周波数を設定する ===

一部のケースで、最大・最小周波数を手動で設定する必要があることがあります。

最大クロック周波数を設定するには ({{ic|''clock_freq''}} は単位付きのクロック周波数です: GHz、MHz):

# cpupower frequency-set -u ''clock_freq''

最小クロック周波数を設定するには:

# cpupower frequency-set -d ''clock_freq''

特定の周波数で動作するように CPU を設定するには:

# cpupower frequency-set -f ''clock_freq''

{{Note|
* 単一の CPU コアだけを調整するには、{{ic|-c ''core_number''}} をコマンドに加えてください。
* ガバナーの最大周波数と最小周波数は {{ic|/etc/default/cpupower}} で設定できます。
}}

あるいは、手動で周波数を設定することもできます:

# echo ''value'' | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq

利用可能な値は {{ic|/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies}} などで調べられます。[https://web.archive.org/web/20201029114421/https://software.intel.com/sites/default/files/comment/1716807/how-to-change-frequency-on-linux-pub.txt]

=== 周波数ブーストを設定する ===

一部のプロセッサでは、適切な温度条件下で短時間、周波数を通常の最大値以上に上げることができます。これは、Intel プロセッサでは [[Wikipedia:ja:インテルターボ・ブースト・テクノロジー|Turbo Boost]] と、AMD プロセッサでは [[Wikipedia:AMD Turbo Core|Turbo-Core]] と呼ばれています。

==== sysfs から設定する (intel_pstate) ====

intel_pstate には、プロセッサがターボ P-State に入ることを禁止するための、ドライバ固有のインターフェイスが存在します:

# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo

==== sysfs から設定する (古いスケーリングドライバ) ====

{{ic|intel_pstate}} より古いスケーリングドライバにおいては、ドライバがブーストをサポートしている場合、{{ic|/sys/devices/system/cpu/cpufreq/boost}} 属性が存在し、これを使ってブーストを無効化/有効化することができます。

ブーストを無効化するには:

# echo 0 > /sys/devices/system/cpu/cpufreq/boost

ブーストを有効化するには:

# echo 1 > /sys/devices/system/cpu/cpufreq/boost

==== x86_energy_perf_policy から設定する ====

Intel プロセッサにおいては、{{Pkg|x86_energy_perf_policy}} を使ってターボブーストを設定することもできます:

# x86_energy_perf_policy --turbo-enable 0

=== amd_pstate ===

{{ic|amd_pstate}} には 3 つのオペレーションモードが存在します: CPPC autonomous (active) モード、CPPC non-autonomous (passive) モード、CPPC guided autonomous (guided) モード。[[カーネル#公式サポートカーネル|公式サポートカーネル]]は {{ic|1=CONFIG_X86_AMD_PSTATE_DEFAULT_MODE=3}} でビルドされており、つまりデフォルトは active モードです。これは[[カーネルパラメータ]]を使って {{ic|1=amd_pstate=active}}、{{ic|1=amd_pstate=passive}}、{{ic|1=amd_pstate=guided}} のように変更できます。{{ic|acpi_cpufreq}} ドライバに戻すには {{ic|1=amd_pstate=disable}} と設定してください。

; Active モード
: {{ic|active}} モードは {{ic|amd_pstate_epp}} (Energy Performance Preference) ドライバによって実装されています。このモードでは、ソフトウェアが CPPC ファームウェアにパフォーマンス (0x0) または電力効率 (0xff) にバイアスをかけることを要求した場合、{{ic|amd_pstate_epp}} ドライバはハードウェアにヒントを提供します。
; Passive モード
: {{ic|passive}} モードは {{ic|amd_pstate}} ドライバによって実装されています。このモードでは、ドライバは現在の負荷に基づいて望ましいパフォーマンス (特に、ユーザエクスペリエンスに影響を与えずにどれだけパフォーマンスの低下を許容できるか) を定義します。
; Guided モード
: {{ic|guided}} モードは {{ic|amd_pstate}} ドライバによって実装されています。このモードでは、{{ic|amd_pstate}} ドライバはパフォーマンスレベルの最大と最小をリクエストし、プラットフォームは、現在の負荷において適切なパフォーマンスレベルをその範囲内で自動的に選択します。

{{Note|一部のマザーボードは必要な設定をファームウェア内で有効にしていないかもしれません。この場合、{{ic|the _CPC object is not present in SBIOS or ACPI disabled}} エラーが発生します。''Enable CPPC'' (たいてい ''AMD CBS > NBIO > SMU > CPPC'' にあります) を ''Auto'' から ''Enabled'' に変更してください (あるいは UEFI 内の似たような設定を変更してください)。これらのオプションが存在しない場合は、ベンダーのウェブサイトを見て更新がないかを調べるか、高度な UEFI オプションを表示させる隠れた方法がマザーボードにないか確認してください。}}

== スケーリングガバナー ==

スケーリングガバナーとは、望ましい CPU 周波数を決定するパワースキームです。固定の周波数をリクエストするガバナーもありますし、システムの負荷に応じて動的に調節するアルゴリズムを実装しているものもあります。カーネルに含まれているガバナーは以下のとおりです:

{{Note|1=各ガバナーは任意のスケーリングドライバと互換性があります。ただし、active モードでの {{ic|intel_pstate}} と {{ic|amd_pstate}} は例外です。これらは、{{ic|powersave}} と {{ic|performance}} という形で疑似ガバナーを提供します。下の [[#自律的な周波数スケーリング]] を参照してください。}}

{| class="wikitable"
! ガバナー !! 説明
|-
| performance || 最大周波数で CPU を動作させます。最大周波数は {{ic|/sys/devices/system/cpu/cpu''X''/cpufreq/scaling_max_freq}} で得ることができます。
|-
| powersave || 最小周波数で CPU を動作させます。最小周波数は {{ic|/sys/devices/system/cpu/cpu''X''/cpufreq/scaling_min_freq}} で得ることができます。
|-
| userspace || ユーザーが指定した周波数で CPU を動作させます。{{ic|/sys/devices/system/cpu/cpu''X''/cpufreq/scaling_setspeed}} で設定可能です。
|-
| ondemand || 現在の負荷にあわせて周波数を動的に切り替えます。最大周波数に一気に切り替えたあと、アイドル時間が増えるにつれて周波数がもとに戻る可能性があります。
|-
| conservative || 現在の負荷にあわせて周波数を動的に切り替えます。ondemand よりも段階的に周波数を切り替えます。
|-
| schedutil || スケジューラによって CPU の周波数が選択されます [https://lwn.net/Articles/682391/]、[https://lore.kernel.org/lkml/1614814.usHvZ58O6A@vostro.rjw.lan/]。
|}

スケーリングドライバによっては、以下のガバナーのうちどれかがデフォルトでロードされます:

* [https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commit/83345a2f829af62ce6fd4b4fa3a875b8f6560f43 Linux 4.9.5] 以降では {{ic|schedutil}}
* Intel CPU で {{ic|intel_pstate}} ドライバを、あるいは AMD CPU で {{ic|amd_pstate}} を使用する場合、内部の {{ic|powersave}} ガバナー (上記のノートを参照、{{ic|schedutil}} と等価です)。

{{Warning|デフォルトのガバナーを変更する場合は、CPU 監視ツールを使用してください (温度や電圧など)。}}

特定のガバナーをアクティブ化するには、以下のコマンドを実行してください:

# cpupower frequency-set -g ''governor''

{{Note|
* 単一の CPU コアだけを調整するには、上のコマンドに {{ic|-c ''core_number''}} を加えて下さい。
* ガバナーを有効にするには、特定の[[カーネルモジュール]] ({{ic|cpufreq_''governor''}}) がロードされている必要があります。カーネル 3.4 現在、これらのモジュールは自動的にロードされます。
}}

もしくは、CPU ごとにガバナーを手動で有効にすることもできます:

# echo ''governor'' | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

{{Tip|CPU の速度をリアルタイムで表示するには、次を実行してください:
$ watch cat /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_cur_freq
}}

=== ondemand ガバナーを調整する ===

詳細は[https://docs.kernel.org/admin-guide/pm/cpufreq.html#ondemand カーネルドキュメント]を見てください。

==== 閾値を切り替える ====

周波数を上げるときの閾値を設定するには:

# echo -n ''percent'' > /sys/devices/system/cpu/cpufreq/''governor''/up_threshold

周波数を下げるときの閾値を設定するには:

# echo -n ''percent'' > /sys/devices/system/cpu/cpufreq/''governor''/down_threshold

==== サンプリングレート ====

サンプリングレートは、CPU の周波数を変化させるのにガバナーが確認する頻度を決めます。1 より大きく {{ic|sampling_down_factor}} を設定すると負担評価のオーバーヘッドが減って、負担が高い時に CPU がずっと最高周波数で動作しパフォーマンスが向上します。{{ic|sampling_down_factor}} に設定できる値は 1 から 100000 です。CPU 周波数や負担が低いときの挙動には影響がありません。

値を読み取るには (デフォルト = 1)、次を実行:

$ cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

値を設定するには、次を実行:

# echo -n ''value'' > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

==== 変更を永続化させる ====

Linux 5.9 から、{{ic|cpufreq.default_governor}} カーネルオプションを設定することが可能になりました。[https://kernelnewbies.org/Linux_5.9#CPU_Frequency_scaling] スケーリングパラメータをブート時に設定するには、[[#cpupower|cpupower]] ユーティリティを設定して、cpupower の systemd サービスを有効化してください。あるいは、[[systemd-tmpfiles]] や [[udev]] ルールを使用することもできます。

== 自律的な周波数スケーリング ==

Intel と AMD は両方とも、(1) システムのパフォーマンスの範囲と、(2) プリファレンスを指定するパフォーマンス/電力のヒントに基づいて CPU に自身の速度を決定させる方法を定義しています。以下の場合に完全自律モードがアクティブ化されます:

* {{ic|amd_pstate}} が "active" に設定された場合。CPU と BIOS の''両方''に CPPC サポートが必要です。
* {{ic|intel_pstate}} が "active" に設定され、''かつ''、ハードウェア P-state (HWP) が利用可能である (つまり、Sandy Bridge 以降) 場合。設定無しで動作します。

能動的な governing の最も重要な特徴は、2つのガバナー ({{ic|powersave}} と {{ic|performance}}) のみが利用可能であるように見えることです。これらは通常のガバナーのようには動作しません。これらのレベルは、CPU の内部ガバナーの ''Energy Performance Preference'' ヒントに変換されます。結果として、これらは両方、動的スケーリングを提供します。{{ic|schedutil}} や {{ic|ondemand}} に似ていますが、主にレイテンシが異なります。{{ic|performance}} アルゴリズムは、Intel HWP に[https://www.phoronix.com/scan.php?page=news_item&px=MTM3NDQ 古い ondemand ガバナーよりも優れた省電力機能を提供するはずです]。

=== Intel active、非 HWP ===

紛らわしいことに、intel-pstate ドライバには、CPU の能動的な決定を必要としない "active" モードがあります。カーネルコマンドラインによって "active" モードが強制されたが、HWP が利用できないか無効化されている場合に、このモードはオンになります。{{ic|powersave}} と {{ic|performance}} しか提供しませんが、ドライバ自体は {{ic|schedutil}} や {{ic|performance}} に似た方法で governing を行います (つまり、最大の P-state のままになります)。能動的な intel-pstate に比べて、このモードに実際の利点はありません。

=== EPP を設定する ===

sysfs インターフェイスが利用可能である場合、中間的なヒントを選択することができます。インターフェイスは AMD と Intel で同じです。{{ic|/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference}} ファイルは現在のプリファレンスを記述し、{{ic|/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_available_preferences}} は利用可能なプリファレンスのリストを提供します。また、0 (パフォーマンス優先) から 255 (省電力優先) までの間の数値を渡すことができます。EPP がない Intel CPU にはフォールバック実装が提供されています。文字列を EPB レベル (次のセクションで説明) に変換しますが、数値では失敗します。

{{Pkg|x86_energy_perf_policy}} は、Intel CPU に対して''のみ''、{{ic|--hwp-epp}} スイッチによる EPP ヒントの設定をサポートしています。これは、Intel と AMD で異なるマシン固有のレジスタ (MSR) への直接アクセスにより機能します。このプログラムは、周波数乗数の範囲を使って HWP 周波数の範囲を制限することもできます。

{{man|8|x86_energy_perf_policy}} でハードウェア P-State を有効にするには:

# x86_energy_perf_policy -H 1
# x86_energy_perf_policy -U 1

== Collaborative processor performance control ==

最近の CPU の電力消費量は、もはや単純に周波数や電圧設定に依存していません。必要に応じて切り替え可能なモジュールが存在しているからです。Collaborative Processor Performance Control (CPPC) は、ACPI 5.0 で提供されている P-state の置き換えです。静的な周波数レベルのテーブルを定義する代わりに、プロセッサは多くの抽象的な''パフォーマンスレベル''を提供し、オペレーティングシステムはこれらのレベルの中から選択します。これには2つの長所があります:

* 16個の P-state エントリという制限がない。典型的な CPU では数百ものレベルの中から選ぶことができます。
* CPU は、特定の部品 (例えば、ベクトル FPU) が使用されていない時に、より高い周波数を提供できます。

一方、柔軟な周波数は、{{ic|schedutil}} による高速な周波数変更において重要な周波数不変の使用率追跡を破壊します。CPPC において周波数を静的にするために多くのベンダ固有の方法が取られてきましたが、ほとんどの成功例は arm64 におけるものです。

{{ic|cppc_cpufreq}} は汎用の CPPC スケーリングドライバです。{{ic|amd_pstate}} も、Zen 3 MSR が利用できない場合に、ACPI CPPC を使用して CPU の周波数を管理します。この方法 ("共有メモリ" とも呼ばれる) は、MSR よりも高レイテンシです。

== Intel performance and energy bias hint ==

[https://docs.kernel.org/admin-guide/pm/intel_epb.html Intel performance and energy bias hint (EPB)] は、ユーザスペースが電力とパフォーマンスのトレードオフを自由に指定できるようにするための Intel CPU によって提供されているインターフェイスです。0 (最高のパフォーマンス) から 15 (最高の省電力) のスケールで指定できます。FPB レジスタは、周波数スケーリングとは独立して機能する、パフォーマンス管理のもう一つのレイヤーです。P-state と C-state の選択がどの程度積極的に行われるかに関与し、エネルギー消費量に影響を与える内部のモデル固有の決定に影響を与えます。

以下は一般的な値とそれぞれのエイリアスです (sysfs と {{man|8|x86_energy_perf_policy}} によって認識されます):

{| class="wikitable"
! EPB 値
! 文字列
|-
| 0
| performance
|-
| 4
| balance-performance
|-
| 6
| normal, default
|-
| 8
| balance-power
|-
| 15
| power
|}

=== sysfs から設定する ===

EPB は sysfs 属性を用いて設定できます:

# echo ''epb'' | tee /sys/devices/system/cpu/cpu*/power/energy_perf_bias

=== x86_energy_perf_policy から設定する ===

{{Pkg|x86_energy_perf_policy}} を使って:

# x86_energy_perf_policy --epb ''epb''

=== cpupower から設定する ===

{{Pkg|cpupower}} を使って:

# cpupower set -b ''epb_value''

{{Warning|cpupower は文字列エイリアスをサポートしていません。文字列が与えられた場合、何も言わずに EPB を 0 (最高パフォーマンス) に設定してしまいます。}}

== ACPI イベントとの対話 ==

AC アダプタを接続したときやノートパソコンのフタを閉じたときなど様々な ACPI イベントによってガバナーを自動的に切り替えるように設定することができます。簡単なサンプルは下にありますが、[[acpid]] の記事は全部読む価値があります。

イベントは {{ic|/etc/acpi/handler.sh}} で定義します。{{Pkg|acpid}} パッケージがインストールされていれば、ファイルは既に存在し実行可能になっているはずです。例えば、AC アダプタが切断されたときにスケーリング governor を {{ic|performance}} から {{ic|conservative}} に変更して、またアダプタが接続されたときは戻したい場合:

{{hc|/etc/acpi/handler.sh|<nowiki>
[...]

ac_adapter)
case "$2" in
AC*)
case "$4" in
00000000)
echo "conservative" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo -n $minspeed >$setspeed
#/etc/laptop-mode/laptop-mode start
;;
00000001)
echo "performance" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo -n $maxspeed >$setspeed
#/etc/laptop-mode/laptop-mode stop
;;
esac
;;
*) logger "ACPI action undefined: $2" ;;
esac
;;

[...]
</nowiki>}}

== トラブルシューティング ==

=== BIOS の周波数制限 ===

CPU/BIOS 設定によっては最大周波数までスケールすることができなかったり周波数を上げることが全くできなかったりすることがあります。これは大抵 BIOS イベントが OS に周波数を制限するよう通知しているのが原因であり、結果的に {{ic|/sys/devices/system/cpu/cpu0/cpufreq/bios_limit}} が低い値に設定されます。

BIOS のセットアップユーティリティで特定の設定 (Frequency、Thermal Management など) をしたのに変更できない場合、BIOS にバグが存在したり、BIOS 自体のバージョンが古いのかもしれません。または BIOS に何か理由があって CPU の周波数を制限しているということもあります。

そのような理由として、バッテリーが取り除かれた (またはほとんど死んでいる) ことで AC 電源しか使えないようになっているのが原因だということがあります (使用しているマシンがノートパソコンの場合)。この場合、電力が弱い AC 電源だけではピーク性能を発揮するのに十分な電力が供給されておらず、バッテリーの補助がないとデータを喪失したり、破損したり、または最悪の場合ハードウェアに深刻なダメージを与える可能性があります。

全ての BIOS が CPU 周波数を制限するわけではありませんが、例えば IBM/Lenovo のほとんどの Thinkpad は制限を加えます。詳しくは thinkwiki の[https://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling トピック]を参照して下さい。

変な BIOS の設定がないことを確認して、何をするのかちゃんと理解できているのなら、BIOS の制限を無視するようにカーネルを設定することができます。

{{Warning|
* このセクションをよく読んで理解してください。CPU 周波数の制限は BIOS のセーフティ機能であり、それを回避する必要は絶対ではありません。
* この方法は'''推奨されておらず'''、ハードウェアに深刻なダメージを負わせる可能性があります。自己責任で行ってください。[https://github.com/syscl/CPUTune]
}}

{{ic|1=processor.ignore_ppc=1}} [[カーネルパラメータ]]を設定してください。一時的に変更してみたいときは {{ic|/sys/module/processor/parameters/ignore_ppc}} の値を {{ic|0}} から {{ic|1}} に変更してください。

一部のシステムは CPU 周波数の制限に他のメカニズムを使用します (例えば、バッテリー無しで動作している場合や公式でない電源アダプタを使用している場合)。Intel CPU で BD PROCHOT ビットを操作する方法は [[Lenovo ThinkPad T480#CPU stuck at minimum frequency]]{{Broken section link}} を、他の修正方法は [[Dell XPS 15 (9560)#General slowness & stuttering]] {{Broken section link}}を参照してください。これは Lenovo ThinkPad T480 に限らず、XPS15 9550 や XPS15 9560 といった Dell XPS モデルにも共通の問題です。このビットは、一部の Intel ベースの MacBook でも、バッテリーが接続されていない場合に CPU 周波数を最小にします。

== 参照 ==

* [https://docs.kernel.org/cpu-freq/index.html Linux CPUFreq - カーネルドキュメント]
* [https://www.reddit.com/r/linux/comments/1hdogn/acpi_cpufreq_or_intel_pstates/ pstate に関する Reddit の投稿]
* [https://docs.kernel.org/admin-guide/pm/cpufreq.html#frequency-boost-support プロセッサのブースト制御]
* [https://docs.kernel.org/admin-guide/pm/intel_pstate.html intel_pstate カーネルドキュメント]
* [https://docs.kernel.org/admin-guide/pm/amd-pstate.html amd_pstate カーネルドキュメント]
* [https://linrunner.de/tlp/settings/processor.html intel_pstate/intel_cpufreq ドキュメント kernel 5.7+]

{{TranslationStatus|CPU frequency scaling|2025-06-28|836952}}

NVIDIA/ヒントとテクニック

2025-06-28T08:07:21Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[en:NVIDIA/Tips and tricks]]
[[ru:NVIDIA/Tips and tricks]]
[[zh-hans:NVIDIA/提示和技巧]]
メインの記事は [[NVIDIA]] です。

== ターミナルの解像度を修正する ==

[[NVIDIA#fbdev]] がデフォルトで有効であるため、[[Linux コンソール]]は追加の設定無しでモニタのネイティブな解像度を使用するはずです。

{{ic|fbdev}} を無効化していたり、古いドライバを使用していたりする場合は、解像度が予想より小さい場合があります。回避策として、[[ブートローダー]]の設定で解像度を設定することができます。

GRUB を使用している場合、[[GRUB/ヒントとテクニック#フレームバッファの解像度を設定する]]を見てください。

[[systemd-boot]] を使用している場合、{{ic|''esp''/loader/loader.conf}} 内で {{ic|console-mode}} を設定してください。詳しくは [[systemd-boot#ローダー設定]] をご覧ください。[https://forums.fedoraforum.org/showthread.php?t=306271] [https://web.archive.org/web/20170405115954/https://www.reddit.com/r/archlinux/comments/4gwukx/nvidia_drivers_and_high_resolution_tty_possible/]

[[rEFInd]] を使用している場合、{{ic|''esp''/EFI/refind/refind.conf}} で {{ic|use_graphics_for +,linux}} を設定してください。ちょっとした注意事項としては、これによりブート中にカーネルパラメータが表示されなくなります。

{{Tip|上記の方法でターミナルの解像度を修正できない場合、UEFI の設定で Legacy BIOS モード (しばしば、Compatibility Support Module、CSM、Legacy Boot と呼ばれます) を完全に無効化する必要があるかもしれません。無効化する前に、すべてのデバイスが UEFI ブートを使用するように設定されていることを確認してください。}}

== TV 出力を使う ==

[[Wikibooks:NVIDIA/TV-OUT]] を見てください。

== X で TV (DFP) を唯一のディスプレイとして使う ==

モニターが自動的に検出されない場合、X サーバーは何かしらのデフォルトの解像度 (通常であれば 640x480) にフォールバックします。これは、DVI/HDMI/DisplayPort 接続の TV をメインディスプレイとして使用していて TV がオフまたは切断されているときに X が起動すると問題になります。

NVIDIA に正しい解像度を強制するには、EDID のコピーをファイルシステムのどこかに保存して、X がディスプレイから EDID を読み込まずにそのファイルをパースできるようにします。

EDID を取得するには、{{ic|nvidia-settings}} を起動します。ツリー形式で情報が表示されますが、今は設定は無視して GPU を選択し (対応するエントリは ''GPU-0'' などのような名前であるはずです)、''DFP'' セクションをクリックして (''DFP-0'' などのような名前です)、''Acquire Edid...'' ボタンをクリックしてファイルをどこかに保存してください (例: {{ic|/etc/X11/dfp0.edid}})。

フロントエンドにマウスやキーボードが接続されていない場合、コマンドラインを使って EDID を取得することもできます。EDID ブロックも出力するように引数を指定して X サーバーを起動します:

$ startx -- -logverbose 6

X サーバーが初期化を完了したら、サーバーを閉じ、''nvidia-xconfig'' を使って [[Xorg#一般|Xorg のログファイル]]から EDID ブロックを抽出してください:

$ nvidia-xconfig --extract-edids-from-file ~/.local/share/xorg/Xorg.0.log --extract-edids-output-file ./dfp0.bin

Xorg の設定で以下を {{ic|Device}} セクションに追加してください:

{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|
Option "ConnectedMonitor" "DFP"
Option "CustomEDID" "DFP-0:/etc/X11/dfp0.bin"
}}

{{ic|ConnectedMonitor}} オプションはドライバーに強制的に DFP を認識させます。{{ic|CustomEDID}} にはデバイスの EDID データを指定してください。TV/DFP が接続されているかのように X が起動するようになります。

ブート時に自動的にディスプレイマネージャを起動して適切な X ディスプレイが設定されてから TV の電源を入れることができます。

== ヘッドレス (モニターなし) 解像度 ==

ヘッドレスモードでは解像度は VNC や Steam Link で利用される 640x480 に落ちます。より高い解像度(例えば、1920x1080)で開始するには、{{ic|xorg.conf}} 内の {{ic|Screen}} サブセクションの下にある {{ic|Virtual}} エントリで指定します:

Section "Screen"
[...]
SubSection "Display"
Depth 24
Virtual 1920 1080
EndSubSection
EndSection

{{Tip|ヘッドレスモードは扱いづらく、エラーが発生しがちかもしれません。例えば、ヘッドレスモードではデスクトップ環境や {{Pkg|nvidia-utils}} は解像度を変更するためのグラフィカルな手段を提供しません。解像度の設定を容易にするためには、ポートにモニターが接続されているように見せかける、ダミーの DP や HDMI アダプターを使うことができます。そうすれば、VNC や Steam Link のようなリモートセッションを使って、解像度を普通に変更できます。}}

== 電源を確認 ==

NVIDIA の X.org ドライバーを使って GPU の現在の電源を検出することもできます。現在の電源を表示するには、読み取り専用パラメータの 'GPUPowerSource' をチェックしてください (0 - AC, 1 - バッテリー):

{{hc|$ nvidia-settings -q GPUPowerSource -t|1}}

== ACPI イベントを Listen する ==

NVIDIA ドライバーは自動的に [[acpid]] デーモンに接続して、バッテリー電源やドッキング、ホットキーなどの ACPI イベントを listen します。接続が失敗した場合、X.org は以下のような警告を出力します:

{{hc|~/.local/share/xorg/Xorg.0.log|
NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
NVIDIA(0): may not be running or the "AcpidSocketPath" X
NVIDIA(0): configuration option may not be set correctly. When the
NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will
NVIDIA(0): try to use it to receive ACPI event notifications. For
NVIDIA(0): details, please see the "ConnectToAcpid" and
NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X
NVIDIA(0): Config Options in the README.
}}

上記の警告は完全に無害ですが、{{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} で {{ic|ConnectToAcpid}} オプションを無効にすることでメッセージを消すことができます:

Section "Device"
...
Driver "nvidia"
Option "ConnectToAcpid" "0"
...
EndSection

ノートパソコンを使っている場合、代わりに [[acpid]] デーモンをインストールして有効化すると良いかもしれません。

== GPU の温度をシェルに表示する ==

GPU の温度を確認する方法は3つあります。''nvidia-settings'' は X を使用する必要があります。X を使っていない場合は ''nvidia-smi'' や ''nvclock'' による方法を使って下さい。また、''nvclock'' は GeForce 200 シリーズのカードや Zotac IONITX の 8800GS などの内蔵 GPU など新しい NVIDIA カードでは機能しません。

=== nvidia-settings ===

GPU の温度をシェルに表示するには、以下のように ''nvidia-settings'' を使って下さい:

{{hc|$ nvidia-settings -q gpucoretemp|
Attribute 'GPUCoreTemp' (hostname:0[gpu:0]): 49.
'GPUCoreTemp' is an integer attribute.
'GPUCoreTemp' is a read-only attribute.
'GPUCoreTemp' can use the following target types: GPU.
}}

上記の場合、ボードの GPU 温度は 49 °C になります。

''rrdtool'' や ''conky'' などのユーティリティで使うために温度だけを表示したいときは:

{{hc|$ nvidia-settings -q gpucoretemp -t|49}}

=== nvidia-smi ===

X を全く使わず (例: Wayland を実行している場合やヘッドレスサーバの場合) GPU から直接温度を読み込むことができる ''nvidia-smi'' を使います。

GPU の温度をシェルに表示するには、''nvidia-smi'' を使って下さい:

{{hc|$ nvidia-smi|<nowiki>
Wed Feb 28 14:27:35 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14 Driver Version: 550.54.14 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce GTX 1660 Ti Off | 00000000:01:00.0 On | N/A |
| 0% 49C P8 9W / 120W | 138MiB / 6144MiB | 2% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 223179 G weston 120MiB |
+-----------------------------------------------------------------------------------------+
</nowiki>}}

温度だけ見るには:

{{hc|$ nvidia-smi -q -d TEMPERATURE|2=
==============NVSMI LOG==============

Timestamp : Wed Feb 28 14:27:35 2024
Driver Version : 550.54.14
CUDA Version : 12.4

Attached GPUs : 1
GPU 00000000:01:00.0
Temperature
GPU Current Temp : 49 C
GPU T.Limit Temp : N/A
GPU Shutdown Temp : 95 C
GPU Slowdown Temp : 92 C
GPU Max Operating Temp : 90 C
GPU Target Temperature : 83 C
Memory Current Temp : N/A
Memory Max Operating Temp : N/A
}}

''rrdtool'' や ''conky'' などのユーティリティで使うために温度だけを取得したいときは:

{{hc|1=$ nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader,nounits|2=49}}

=== nvclock ===

{{AUR|nvclock}} パッケージを[[インストール]]してください。

{{Note|''nvclock'' は Geforce 200 シリーズなどの新しい NVIDIA カードの温度センサーにはアクセスできません。}}

たまに ''nvclock'' と ''nvidia-settings''/''nv-control'' が報告する温度が食い違うことがあります。''nvclock'' の作者 (thunderbird) による [https://sourceforge.net/projects/nvclock/forums/forum/67426/topic/1906899 この投稿] によると、''nvclock'' の値のほうが正確なようです。

== オーバークロックと冷却 ==

{{Warning| オーバークロックによってハードウェアに永久的な損傷が発生するかもしれません。警告しましたよ。}}

=== nvidia-settings からオーバークロックを有効化する ===

{{Note|
* rootless モードで Xorg サーバを実行している場合、一部のオーバークロックの設定は適用できません。[[Xorg#root として Xorg を実行|Xorg を root として実行]]することを検討してください。
* ''nvidia-settings'' は root として実行する必要があるかもしれません。
* DRM カーネルモードセッティングを有効にすると Coolbits の値に関わらずオーバークロックができなくなる場合があります。
}}

ドライバのバージョンによっては、一部のオーバークロック機能がデフォルトで有効になっています。一部のサポートされていないオーバークロック機能は {{ic|Device}} セクションで ''Coolbits'' オプションで有効化する必要があります:

Option "Coolbits" "''値''"

{{Tip| ''Coolbits'' オプションは、Xorg の設定ファイルを操作する ''nvidia-xconfig'' を使って簡単に設定できます: {{bc|1=# nvidia-xconfig --cool-bits=''value''}}}}

''Coolbits'' の値は2進数の構成ビットを足し合わせたものです。構成ビットは以下のとおりです:

* {{ic|8}} (ビット3) - ''nvidia-settings'' の ''PowerMizer'' ページの追加のオーバークロック機能を有効化します。Fermi や Fermi より新しいアーキテクチャでバージョン 337.12 から利用可能です。[https://www.phoronix.com/scan.php?px=MTY1OTM&page=news_item]
* {{ic|16}} (ビット4) - ''nvidia-settings'' の CLI のオプションを使ってオーバーボルテージできるようにします。Fermi や Fermi より新しいアーキテクチャでバージョン 346.16 から利用可能です。[https://www.phoronix.com/scan.php?page=news_item&px=MTg0MDI]

サポートされていないバージョンのドライバを使用している場合は、以下のビットも使用する必要があるかもしれません:

* {{ic|1}} (ビット0) - ''nvidia-settings'' の ''Clock Frequencies'' ページで古い(Fermi以前)コアをオーバークロックできるようにします。バージョン 343.13 で削除されました。
* {{ic|2}} (ビット1) - このビットがセットされると、ドライバは「ビデオメモリの容量が異なる複数の GPU を使用するときに SLI の初期化を試みます。」バージョン 470.42.01 で削除されました。
* {{ic|4}} (ビット2) - ''nvidia-settings'' の ''Thermal Monitor'' ページで GPU ファンの速度を手動設定できるようにします。バージョン 470.42.01 で削除されました。

複数の機能を有効化するには ''Coolbits'' の値に上記の値を足し合わせてください。例えば、Fermi コアのオーバークロックとオーバーボルテージを有効化する場合は {{ic|Option "Coolbits" "24"}} をセットします。

''Coolbits'' に関するドキュメントは {{ic|/usr/share/doc/nvidia/html/xconfigoptions.html}} と[https://download.nvidia.com/XFree86/Linux-x86_64/565.77/README/xconfigoptions.html#Coolbits ここ]にあります。

{{Note| 別の手段としては DOS(推奨) 内から、あるいは [https://www.techpowerup.com/download/nvidia-nvflash/ nvflash] と [https://www.guru3d.com/files-details/nvidia-bios-editor-download-nibitor.html NiBiTor 6.0] を Win32 環境内で使って、GPU BIOS を編集しリフラッシュするというものがあります。BIOS をフラッシュする利点は電圧制限を上げられることだけでなく、一般に Coolbit のようなソフトウェアオーバークロッキングの方法で安定性が向上することです。[https://ivanvojtko.blogspot.sk/2014/03/how-to-overclock-geforce-460gtx-fermi.html Fermi BIOS modification tutorial]}}

=== 静的な 2D/3D クロックを設定する ===

[[カーネルモジュールパラメータ]]を使用して PowerMizer を最大パフォーマンスレベルで有効化してください (この設定がないと VSync が機能しません):

{{hc|/etc/modprobe.d/nvidia.conf|2=
options nvidia NVreg_RegistryDwords="PerfLevelSrc=0x2222"
}}

=== GPU のブーストクロックを下げる ===

[https://nouveau.freedesktop.org/CodeNames.html#NV140 Volta (NV140/GVXXX)] GPU 及びそれ以降では、クロックブーストが異なる方法で動作します。最大クロックはブート時に、サポートされている最も高い制限値に設定されます。これが望ましい動作である場合は、設定は必要ありません。

これの欠点は、電力効率が低いことです。クロックが上がると、安定性のために電圧を上げる必要があります。その結果として、電力消費量、発熱、ファンの音量が非線形的に増加します。なので、ブーストクロックの制限を下げることで、電力効率を上げることができます。

ブーストクロックの制限は nvidia-smi を使用して変更できます:

* サポートされているクロックレートを表示: {{bc|$ nvidia-smi -q -d SUPPORTED_CLOCKS}}
* GPU のブーストクロックの制限を 1695 MHz に設定: {{bc|1=# nvidia-smi --lock-gpu-clocks=0,1695 --mode=1}}
* メモリのブーストクロックの制限を 5001 MHz に設定: {{bc|1=# nvidia-smi --lock-memory-clocks=0,5001}}

電力効率の最適化をするには、ゲームをプレイしながら nvidia-smi で GPU 使用率を確認してください。VSync はオンにしておく必要があります。ブーストクロックの制限を下げると、GPU 使用率が増加します。遅い GPU では、各フレームを描画するのにより長い時間がかかるからです。GPU 使用率が 100% になり、かつ、カクつきが発生しない程度にまでクロックを下げれば、効率は最大になります。このとき、各フレームはリフレッシュレートを維持するのにちょうど十分なほど高速に描画できていることになります。

例として、RTX 3090 Ti でデフォルトから上記の設定に変更した場合、Hitman 3 を 4K 60 FPS でプレイしたところ、電力消費量が 30% 減少し、温度は 75 度から 63 度に、ファンの速度は 73% から 57% に低下しました。

=== オーバークロックの設定を保存する ===

通常、''nvidia-settings'' インターフェイスで設定したクロックと電圧のオフセットは保存されず、再起動すると消えてしまいます。幸い、プロプライエタリドライバにおいてオーバークロック用のインターフェイスを提供し、ユーザのオーバークロック設定を保存することが可能で、起動時に自動的に設定を適用するツールがあります。以下にその一部を挙げます:

* {{AUR|gwe}} - グラフィカル。デスクトップセッションの開始時に設定を適用します。
* {{AUR|nvclock}} と {{AUR|systemd-nvclock-unit}} - グラフィカル。システムの起動時に設定を適用します。
* {{AUR|nvoc}} - テキストベース。プロファイルは {{ic|/etc/nvoc.d/}} 下の設定ファイルです。デスクトップセッション開始時に設定を適用します。

あるいは、{{ic|GPUGraphicsClockOffset}} 属性と {{ic|GPUMemoryTransferRateOffset}} 属性を[[自動起動|起動時に]] ''nvidia-settings'' のコマンドラインインターフェイスでセットすることができます。例えば:

$ nvidia-settings -a "GPUGraphicsClockOffset[''performance_level'']=''offset''"
$ nvidia-settings -a "GPUMemoryTransferRateOffset[''performance_level'']=''offset''"

{{ic|''performance_level''}} は最も高いパフォーマンスレベルとなります。マシンに複数の GPU が存在する場合、GPU ID を指定する必要があります: {{ic|1=[gpu:''gpu_id'']GPUGraphicsClockOffset[''performance_level'']=''offset''}}。

=== カスタムの TDP 制限 ===

最近の NVIDIA グラフィックカードは TDP と温度が制限内に収まるように周波数を調整します。パフォーマンスを上げるために TDP 制限を変更できます。これにより温度が上昇し、電力消費量が増加するでしょう。

例えば、電力制限を 160.30W に設定するには:

# nvidia-smi -pl 160.30

(ドライバの永続化なしで)電力制限を起動時に設定するには:

{{hc|/etc/systemd/system/nvidia-tdp.timer|2=
[Unit]
Description=Set NVIDIA power limit on boot

[Timer]
OnBootSec=5

[Install]
WantedBy=timers.target
}}

{{hc|/etc/systemd/system/nvidia-tdp.service|2=
[Unit]
Description=Set NVIDIA power limit

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -pl 160.30
}}

そして、{{ic|nvidia-tdp.timer}} を[[有効化]]してください。

=== ログイン時にファンの速度を設定する ===

{{Accuracy|GPU のファン速度を手動設定するには (たとえ Xorg が root として実行されていたとしても) ''nvidia-settings'' を root として実行する必要があるため、以下の方法はうまく行きません。}}

''nvidia-settings'' のコンソールインターフェイスを使ってグラフィックカードのファンの速度を調整することができます。まず、Xorg 設定の [[#nvidia-settings からオーバークロックを有効化する|Coolbits]] オプションでビット2を有効化していることを確認してください。

{{Note| 現在 GeForce 400/500 シリーズのカードではこの方法を使ってログイン時にファンの速度を設定することはできません。この方法では ''nvidia-settings'' を使って現在の X セッション内でファンのスピードを変更することしかできません。}}

Xorg が起動した時にファンを調整するには以下の行を [[xinitrc]] ファイルに記述します。{{ic|''n''}} は設定したいファンの速度のパーセンテージに置き換えて下さい。

nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUTargetFanSpeed=''n''"

GPU とファンの番号を増やすことで二番目の GPU を設定することもできます。

nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''" \
-a "[gpu:1]/GPUFanControlState=1" -a [fan:1]/GPUCurrentFanSpeed=''n''" &

[[GDM]] や [[KDM]] などのログインマネージャを使用している場合、デスクトップエントリファイルを作成して設定をさせることもできます。{{ic|~/.config/autostart/nvidia-fan-speed.desktop}} を作成してその中に以下のテキストを入力してください。{{ic|''n''}} は速度のパーセンテージに置き換えて下さい。

[Desktop Entry]
Type=Application
Exec=nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''"
X-GNOME-Autostart-enabled=true
Name=nvidia-fan-speed

{{Note|ドライバーのバージョン 349.16 から、{{ic|GPUCurrentFanSpeed}} は {{ic|GPUTargetFanSpeed}} に置き換わっています [https://devtalk.nvidia.com/default/topic/821563/linux/can-t-control-fan-speed-with-beta-driver-349-12/post/4526208/#4526208]。}}

複数のグラフィックカードのファン速度を調整できるようにしたい場合、以下のコマンドを実行:

$ nvidia-xconfig --enable-all-gpus
$ nvidia-xconfig --cool-bits=4

{{Note|一部のラップトップ(ThinkPad [https://devtalk.nvidia.com/default/topic/1052110/linux/can-t-control-gtx-1050-ti-max-q-fan-on-thinkpad-x1-extreme-laptop/post/5340658/#5340658 X1 Extreme] や [https://devtalk.nvidia.com/default/topic/1048624/linux/how-to-set-gpu-fan-speed/post/5321818/#5321818 P51/P52] を含む)においては、2つのファンがあるものの、どちらも nvidia によって制御されません。}}

=== NVML によるシンプルなオーバークロックスクリプト ===

Nvidia Management Library (NVML) は、GPU のコアとメモリのクロックオフセットと電力制限値を管理できる API を提供しています。これを使うには、{{AUR|python-nvidia-ml-py}} をインストールし、以下の Python スクリプトを所望の設定で使用してください。このスクリプトは、起動のたびに root として実行してオーバークロック/低電圧の設定を適用し直す必要があります。

{{bc|1=
#!/usr/bin/env python

from pynvml import *

nvmlInit()

# 調節対象の GPU を指定する。以下でエラーが発生する場合や、複数の GPU が存在する場合、1 に設定するか、他の値を試してください
myGPU = nvmlDeviceGetHandleByIndex(0)

# 以下の行の "000" の部分を所望の GPU クロックオフセット値に置き換えてください。
nvmlDeviceSetGpcClkVfOffset(myGPU,000)

# 以下の行の "000" の部分を、所望のメモリクロックオフセット値の「2倍」に置き換えてください。
# 例えば、オフセットが 500 である場合、以下の行には 1000 と記述してください。
nvmlDeviceSetMemClkVfOffset(myGPU,000)

# 以下に電力制限値を mW で設定してください。例えば、216W は 216000 (mW) になります。電力制限値を調整したくない場合は以下の行を削除してください。
nvmlDeviceSetPowerManagementLimit(myGPU, 000000)
}}

== カーネルモジュールパラメータ ==

一部のオプションはカーネルモジュールパラメータから設定できます。パラメータの完全なリストは {{ic|modinfo nvidia}} を実行するか {{ic|nv-reg.h}} を見てください。[[Gentoo:NVidia/nvidia-drivers/ja#カーネルモジュールのパラメーター]] も見てください。

例えば、以下を有効化すると PAT 機能 [https://docs.kernel.org/arch/x86/pat.html] が有効になります。PAT 機能はメモリの割り当て方に影響を及ぼします。PAT は Pentium III に初めて導入され [https://www.kernel.org/doc/ols/2008/ols2008v2-pages-135-144.pdf]、それよりも新しい CPU の殆どでサポートされています([[wikipedia:Page attribute table#Processors]] を参照)。あなたのシステムでこの機能がサポートされている場合、パフォーマンスが向上するはずです。

{{hc|/etc/modprobe.d/nvidia.conf|2=
options nvidia NVreg_UsePageAttributeTable=1
}}

一部のノートパソコンでは NVIDIA の設定を有効化するために以下のオプションを含めなければなりません。さもないと "Setting applications clocks is not supported" などと表示されます。

{{hc|/etc/modprobe.d/nvidia.conf|2=
options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1"
}}

{{Note|[[カーネルモジュール#/etc/modprobe.d/ 内のファイルを使う]] にある通り、[[NVIDIA#DRM カーネルモード設定|early KMS]] を使用している場合は [[Initramfs を再生成する]]必要があります。}}

== サスペンド後にビデオメモリを保持する ==

デフォルトでは、システムのサスペンドと復帰時に NVIDIA の Linux ドライバーは必須のビデオメモリの割り当てのみを保存し復元します。NVIDIA 曰く:
:結果として生じるビデオメモリの内容の消失は、ユーザスペースの NVIDIA ドライバーや一部のアプリケーションによって部分的に補われます。しかし、電源管理サイクルの終了時にレンダリングの破損やアプリケーションのクラッシュなどの機能不全が発生する可能性があります。

"まだ実験段階の" インターフェイスを使用すれば、(ディスクまたは RAM に十分な領域があれば) ビデオメモリ全てを保存できるようになります。

ビデオメモリの内容を全て保存し復元するようにするには、{{ic|nvidia}} カーネルモジュールに対して {{ic|1=NVreg_PreserveVideoMemoryAllocations=1}} [[カーネルモジュールパラメータ]]を設定する必要があります。NVIDIA はこのパラメータをデフォルトで設定していませんが、一方 Arch Linux では、サポートされているドライバにおいてこのパラメータがデフォルトで設定されており、ビデオメモリはデフォルトで保持されます。

{{ic|NVreg_PreserveVideoMemoryAllocations}} が有効であるかを調べるには、以下を実行してください:

# cat /proc/driver/nvidia/params | sort

{{ic|PreserveVideoMemoryAllocations: 1}} という行と、{{ic|TemporaryFilePath: "/var/tmp"}} という行があるはずです (これらのパラメータについては以下で説明されています)。

サポートされているドライバにおいては、上流の要件通り、必須のサービスである {{ic|nvidia-suspend.service}}、{{ic|nvidia-hibernate.service}}、{{ic|nvidia-resume.service}} はデフォルトで[[有効化]]されています。

詳細は [https://download.nvidia.com/XFree86/Linux-x86_64/565.77/README/powermanagement.html NVIDIA のドキュメント]を参照してください。

{{Accuracy|[[NVIDIA#早期ロード|KMS を早期開始]]する場合 (つまり、initramfs の段階で {{ic|nvidia}} モジュールがロードされる場合)、initramfs の時点では、以前のビデオメモリの内容が保存されている {{ic|NVreg_TemporaryFilePath}} にアクセスできません。つまり、ハイバーネートを使用する場合は、KMS の早期開始を使用するべきではありません。}}

{{Note|
* [[カーネルモジュール#/etc/modprobe.d/ 内のファイルを使う]] にある通り、[[NVIDIA#DRM カーネルモード設定|early KMS]] を使用している場合は [[initramfs を再生成する]]必要があります。
* 上流のデフォルトでは、ビデオメモリの内容は ([[tmpfs]] である) {{ic|/tmp}} に保存されます。NVIDIA は、最高のパフォーマンスを得るために[https://download.nvidia.com/XFree86/Linux-x86_64/565.77/README/powermanagement.html#PreserveAllVide719f0 他のファイルシステムを使うことを推奨]しています。また、{{ic|/tmp}} のサイズがメモリの容量に対して不十分である場合も、他のファイルシステムを使う必要があります。このような理由から、Arch Linux では、サポートされているドライバにおいて {{ic|1=nvidia.NVreg_TemporaryFilePath=/var/tmp}} パラメータがデフォルトで設定されています。
* ビデオメモリの内容を保存するファイルシステムは、無名一時ファイルをサポートし (例えば、ext4 や XFS)、かつビデオメモリの割り当てを保存するのに十分な容量がある必要があります (つまり、すべての NVIDIA GPU のメモリ容量合計の 1.05 倍以上)。コマンド {{ic|1=nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits}} を使えば、システム上のすべての GPU ビデオメモリの容量を一覧表示できます。
* NVIDIA は {{ic|nvidia-resume.service}} を有効化するのは必須であるとしていますが、これを有効化するのは任意です。このサービスの機能は {{man|8|systemd-sleep}} フック ({{ic|/usr/lib/systemd/system-sleep/nvidia}}) によって提供され、このフックは自動的に実行されるからです。ただし、[https://gitlab.gnome.org/GNOME/gdm/-/issues/784 GDM を Wayland で使用している場合]は、{{ic|nvidia-resume.service}} を明示的に有効化する必要があります。
}}

== Dynamic Boost ==

Dynamic Boost は、システムのワークロードに応じて GPU 及び CPU の電力消費を管理する、システム全体で動作する電力制御ソフトウェアです。[https://download.nvidia.com/XFree86/Linux-x86_64/535.54.03/README/dynamicboost.html] 適宜、電力制限を上げることによって、特に GPU を使用するアプリケーションでパフォーマンスを向上させることができます。

主なシステム要件は、Ampere (及びそれより新しい) GPU が搭載されているラップトップであることです。

詳細は [[CPU 周波数スケーリング#nvidia-powerd]] を参照してください。

{{Tip|電力制限を手動で設定できない人にとっては特に役立つでしょう。[[NVIDIA Optimus#消費電力 (TDP) が低いままになる]] を参照してください。}}

== ドライバーの持続 ==

NVIDIA はブート時に任意で実行できるデーモンを用意しています。標準的な単一 GPU の X デスクトップ環境では持続デーモンは必要ではなく、むしろ問題を引き起こします [https://devtalk.nvidia.com/default/topic/1044421/linux/nvidia-persistenced-causing-60-second-reboot-delays]。詳細については NVIDIA ドキュメントの [https://docs.nvidia.com/deploy/driver-persistence/index.html#persistence-daemon Driver Persistence] 章をご覧ください。

ブート時に持続デーモンを開始するには {{ic|nvidia-persistenced.service}} を[[有効化]]してください。手動での使用については[https://docs.nvidia.com/deploy/driver-persistence/index.html#usage 上流のドキュメント]をご覧ください。

== YCbCr 4:2:0 サブサンプリングを強制する ==

[[Wikipedia:HDMI#Refresh frequency limits for standard video|古い出力規格の制限]]に悩まされているが、YUV 4:2:0 を使用することで問題を緩和できるような場合は、NVIDIA ドライバに YUV420 を強制するためのドキュメント化されていない X11 オプションがあります:

Option "ForceYUV420" "True"

これで、より高い解像度とリフレッシュレートを利用できますが、画質に悪影響を及ぼします。

== GPU を使ってレンダリングするようにアプリケーションを設定する ==

[[PRIME#GPU を使ってレンダリングするようにアプリケーションを設定する]] を参照してください。

{{TranslationStatus|NVIDIA/Tips and tricks|2025-06-28|839461}}

NVIDIA Optimus

2025-06-28T08:04:45Z

AshMyzk: /* 消費電力が低いままになる (TDP) */ 章の名前を変更

[[Category:グラフィックス]]
[[en:NVIDIA Optimus]]
[[es:NVIDIA Optimus]]
[[fr:NVIDIA Optimus]]
[[ru:NVIDIA Optimus]]
[[zh-hans:NVIDIA Optimus]]
{{Related articles start}}
{{Related|PRIME}}
{{Related|Bumblebee}}
{{Related|Nouveau}}
{{Related|NVIDIA}}
{{Related|nvidia-xrun}}
{{Related|外付け GPU}}
{{Related articles end}}

[[Wikipedia:NVIDIA Optimus|NVIDIA Optimus]] は、内蔵 GPU とディスクリート NVIDIA GPU をノート PC に組み込み、さらにノート PC からアクセスできるようにする技術です。

== 利用可能な方法 ==

複数の方法が利用できます:

* [[#内蔵グラフィックスのみを使う]] - NVIDIA GPU は完全に電源オフになるので、消費電力を削減できます。
* [[#NVIDIA グラフィックスのみを使う]] - 内蔵グラフィックスよりも優れたパフォーマンスを発揮します。ただし、より多くの電力を消費します (これはモバイル端末においては喜ばしいことではありません)。この方法は、[[#optimus-manager を使う|optimus-manager]] と [[#nvidia-xrun を使う|nvidia-xrun]] と同じ基本プロセスを利用しており、より自動化されたアプローチを取る前にトラブルシューティングや一般的な機能検証のためにこの方法を利用するべきです。
* 両方を使う (必要なときに NVIDIA GPU を使用し、それ以外のときは電源を落として電力を節約する):
** [[#PRIME レンダーオフロードを使う]] - NVIDIA が公式にサポートしている方法です。
** [[#optimus-manager を使う]] - 1つのコマンドでグラフィックスを切り替えます (適用させるにはログインし直さなければなりません)。また、PRIME レンダーオフロードとのハイブリッドモードもサポートしています。NVIDIA GPU の性能を最大限に引き出し、使用していない場合はオフにします。1.4 リリース以降では、AMD と NVIDIA の組み合わせもサポートされています。
** [[#nvidia-xrun を使う]] - NVIDIA グラフィックスを使用して別の TTY で別の X セッションを実行します。NVIDIA GPU の性能を最大限に引き出し、使用していない場合はオフにします。
** [[#Bumblebee を使う]] - 指定したアプリケーションに対しては NVIDIA グラフィックスを使用し、その他のアプリケーションに対しては Intel グラフィックスを使えるようにすることで、Windows ライクな機能を提供します。しかし、重大なパフォーマンスの問題を抱えています。
** [[#switcheroo-control を使う]] - Bumblebee と似ていますが、特に [[GNOME]] ユーザ向けです。[[デスクトップエントリ]]内で専用 GPU を優先するかどうかを指定できるようになり、さらに右クリックメニューから手動で NVIDIA GPU でアプリケーションを実行できるようになります。
** [[#nouveau を使う]] - (プロプライエタリな NVIDIA ドライバと比較して) パフォーマンスが劣っており、スリープやハイバネートの問題が発生することがあります。最新の NVIDIA GPU では動作しません。
** [[#EnvyControl を使う]] - optimus-manager と似ていますが、多くの設定を必要とせず、バックグラウンドでデーモンを実行する必要もありませんし、GNOME を使用している場合でもパッチ適用済みの GDM バージョンをインストールする必要はありません。
** [[#NVidia-eXec を使う]] - Bumblebee と似ていますが、パフォーマンスが低下することはありません。Xorg と Wayland の両方で動作します。このパッケージは実験的であり、現在、GNOME/GDM においてテストされています。
** [[#nvidia-switch を使う]] - nvidia-xrun と似ていますが、TTY を変更する必要はありません。切り替えは、ディスプレイマネージャでログインとログアウトをすることにより、行われます。このパッケージは、Debian ベースのシステムでテストされていますが、nvidia-xrun のように、全ての Linux システムで動作するはずです。

{{Note|これらのオプションはすべて相互に排他的です。1つの方法をテストして別の方法を選択する場合は、別の方法を試行する前に、1つの方法に従って行われた構成変更を必ず元に戻す必要があります。そうしないと、ファイルの競合や未定義の動作が発生する可能性があります。}}

== 内蔵グラフィックスのみを使う ==

GPU を切り替えることに興味はなく、特定の GPU のみを使いたい場合は、システムの BIOS で関連するオプションを確認してください。いずれかのカードを無効にするオプションがあるはずです。ラップトップによっては、ディスクリートカードを有効化したり無効化したりしかできないことがあります。とはいえ、どれかのカードだけを使用する予定であるかを確認することは、損ではありません。

BIOS で Nvidia グラフィックスを無効にできない場合は、Linux カーネル自体から無効にできます。[[ハイブリッドグラフィック#ディスクリート GPU の完全な電源オフ]] を参照してください。

=== レンダリングプロバイダを切り替えずに CUDA を使う ===

CUDA は、NVIDIA グラフィックスにレンダリングを切り替えることなく使用できます。CUDA アプリケーションを起動する前に、NVIDIA カードの電源が入っていることを確認するだけです。詳細については、[[ハイブリッドグラフィック#ディスクリート GPU の完全な電源オフ]] を参照してください。

これで、CUDA アプリケーションを起動すると、必要なすべてのカーネルモジュールが自動的にロードされます。CUDA の使用後に NVIDIA カードの電源を切る前に、まず {{ic|nvidia}} カーネルモジュールをアンロードする必要があります:

# rmmod nvidia_uvm
# rmmod nvidia

== NVIDIA グラフィックスのみを使う ==

プロプライエタリな NVIDIA ドライバは、プライマリレンダリングプロバイダとして設定することができます。[[NVIDIA#DRM カーネルモード設定]] を有効化することによって prime sync を有効化しない限り、顕著なスクリーンティアリングの問題が発生します (詳細は [https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/] を参照)。ディスクリート GPU を使用することができ ([https://www.phoronix.com/scan.php?page=article&item=nouveau-410-blob&num=1 2017年1月]現在)、パフォーマンスにおいて nouveau ドライバよりも顕著な優位性を持っています。

まず、[[NVIDIA]] ドライバと {{Pkg|xorg-xrandr}} を[[インストール]]してください。そして、{{ic|/etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf}} を設定してください。この設定ファイルのオプションは、このセットアップとの互換性を提供するために、パッケージによって提供されている {{ic|/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf}} と組み合わされます。

{{Note|セットアップによっては EDID ファイルによる nvidia ドライバーのディスプレイの値の自動検出がされなくなることがあります。回避策は [[#解像度や画面スキャンが正しく認識されず Xorg.log に EDID のエラーが表示される]] を見て下さい。}}

{{hc|/etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf|
Section "OutputClass"
Identifier "intel"
MatchDriver "i915"
Driver "modesetting"
EndSection

Section "OutputClass"
Identifier "nvidia"
MatchDriver "nvidia-drm"
Driver "nvidia"
Option "AllowEmptyInitialConfiguration"
Option "PrimaryGPU" "yes"
ModulePath "/usr/lib/nvidia/xorg"
ModulePath "/usr/lib/xorg/modules"
EndSection
}}

次に、{{ic|~/.xinitrc}} の先頭に以下の2行を追加してください:

{{hc|~/.xinitrc|
xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
}}

そしてドライバをロードするために再起動し、X を起動させます。

ディスプレイの dpi が正しくない場合は以下の行を追加してください:

xrandr --dpi 96

X の起動時に黒画面が表示される場合、{{ic|~/.xinitrc}} に記述した 2 つの {{ic|xrandr}} コマンドの後にアンパサンド (アンド記号) がないことを確認してください。アンパサンドがある場合、{{ic|xrandr}} コマンドが実行し終える前にウィンドウマネージャが起動してしまうことがあり、そうなると黒画面になってしまいます。

=== ディスプレイマネージャ ===

[[ディスプレイマネージャ]]を使用する場合、{{ic|~/.xinitrc}} を使うのではなく、使用しているディスプレイマネージャのディスプレイセットアップスクリプトを作成あるいは編集する必要があります。

==== LightDM ====

[[LightDM]] ディスプレイマネージャの場合:

{{hc|/etc/lightdm/display_setup.sh|
#!/bin/sh
xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
}}

スクリプトに[[実行可能属性]]を付与してください。

次に、そのスクリプトを実行するように lightdm を設定します。{{ic|/etc/lightdm/lightdm.conf}} 内の {{ic|[Seat:*]}} セクションを編集してください:

{{hc|/etc/lightdm/lightdm.conf|output=
[Seat:*]
display-setup-script=/etc/lightdm/display_setup.sh
}}

そして、再起動し、ディスプレイマネージャを起動させてください。

==== SDDM ====

[[SDDM]] ディスプレイマネージャの場合 (SDDM は [[KDE]] のデフォルトのディスプレイマネージャです):

{{hc|/usr/share/sddm/scripts/Xsetup|
xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto
}}

==== GDM ====

[[GDM]] ディスプレイマネージャの場合、2つの .desktop ファイルを新規作成してください:

{{hc|/usr/share/gdm/greeter/autostart/optimus.desktop
/etc/xdg/autostart/optimus.desktop|
<nowiki>[Desktop Entry]
Type=Application
Name=Optimus
Exec=sh -c "xrandr --setprovideroutputsource modesetting NVIDIA-0; xrandr --auto"
NoDisplay=true
X-GNOME-Autostart-Phase=DisplayServer</nowiki>
}}

GDM が [[GDM#Xorg バックエンドを使う|X をデフォルトバックエンドとして使う]]ように設定してください。

=== 3D を確認する ===

NVIDIA グラフィックスが使用されているかどうかは、{{Pkg|mesa-utils}} をインストールして次のコマンドを実行することで確認できます:

$ glxinfo | grep NVIDIA

=== 詳細情報 ===

詳細情報は、このトピックに関する NVIDIA の公式ページ [http://us.download.nvidia.com/XFree86/Linux-x86/370.28/README/randr14.html] を見てください。

== 切り替え可能なグラフィックスを使う ==

=== PRIME レンダーオフロードを使う ===

これは、切替可能なグラフィックスをサポートする NVIDIA 公式の方法です。

詳細は [[PRIME#PRIME レンダーオフロード]] を参照してください。

=== nouveau を使う ===

グラフィックスの切り替えについては [[PRIME]] を、オープンソースな NVIDIA ドライバについては [[nouveau]] を参照してください。

=== Bumblebee を使う ===

[[Bumblebee]] を参照してください。

=== switcheroo-control を使う ===

[[PRIME#Gnome 統合]] を参照してください。

=== nvidia-xrun を使う ===

[[nvidia-xrun]] を参照してください。

=== optimus-manager を使う ===

上流のドキュメント [https://github.com/Askannz/optimus-manager Optimus-manager] を参照してください。Arch Linux システムにおけるインストールと設定方法の両方がカバーされています。

=== EnvyControl を使う ===

上流のドキュメント [https://github.com/geminis3/envycontrol EnvyControl] を参照してください。インストール方法と使用方法の両方がカバーされています。

=== NVidia-eXec を使う ===

上流のドキュメント [https://github.com/pedro00dk/nvidia-exec NVidia-eXec] を参照してください。インストール方法と使用方法の両方がカバーされています。

=== nvidia-switch を使う ===

上流のドキュメント [https://github.com/nvidiaswitch/nvidia-switch nvidia-switch] を参照してください。インストール方法と使用方法の両方がカバーされています。

== トラブルシューティング ==

=== ティアリング/垂直同期が機能しない ===

[[NVIDIA#DRM カーネルモード設定|DRM カーネルモード設定]]を有効化してください。これにより、PRIME 同期が有効化され、ティアリングが修正されます。

詳細は公式の[https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/ フォーラムスレッド]で確認できます。

=== Failed to initialize the NVIDIA GPU at PCI:1:0:0 (GPU fallen off the bus / RmInitAdapter failed!) ===

カーネルパラメータに {{ic|1=rcutree.rcu_idle_gp_delay=1}} を追加してください。オリジナルのトピックは [https://github.com/Bumblebee-Project/Bumblebee/issues/455#issuecomment-22497464] と [https://bbs.archlinux.org/viewtopic.php?id=169742] で確認できます。

=== 解像度や画面スキャンが正しく認識されず Xorg.log に EDID のエラーが表示される ===

NVIDIA ドライバがディスプレイの EDID を検出できていないことが原因です。手動で EDID ファイルへのパスを指定するか、同じような方法で同一の情報を提供する必要があります。

EDID ファイルへのパスを指定するには {{ic|Xorg.conf}} の NVIDIA カードの Device セクションを編集して、以下の記述を追加して適当にパスを置き換えてください:

{{hc|/etc/X11/xorg.conf|
Section "Device"
Option "ConnectedMonitor" "CRT-0"
Option "CustomEDID" "CRT-0:/sys/class/drm/card0-LVDS-1/edid"
Option "IgnoreEDID" "false"
Option "UseEDID" "true"
EndSection
}}

Xorg が起動しない場合は、CRT という文字列を全て DFB に置き換えてみて下さい。
{{ic|card0}} は、LVDS でディスプレイに接続されている Intel カードの識別子です。edid バイナリはこのディレクトリに存在します。ハードウェアの構成が異なっている場合、CustomEDID の値も変わってくるので確認するようにしてください。どのような場合でも、パスは {{ic|/sys/class/drm}} で始まります。

または、{{Pkg|read-edid}} などのツールを使って edid を自分で作成して、作成したファイルを使うようにドライバーを設定することもできます。modelines も使えますが、{{ic|UseEDID}} と {{ic|IgnoreEDID}} は変更するようにしてください。

=== 解像度が間違っているが、EDID エラー無し ===

''nvidia-xconfig'' を使っていると、不適切な情報 (特に、利用可能な解像度を制限するモニタのリフレッシュレート) が {{ic|xorg.conf}} 内に生成されてしまうことがあります。{{ic|HorizSync}}/{{ic|VertRefresh}} の行をコメントアウトしてみてください。これで解決するならば、この記事で言及していないその他すべての項目も削除できるでしょう。

=== ロックアップ問題 (lspci がフリーズ) ===

症状: lspci がハングする。システムのサスペンドが失敗する。シャットダウン時にハングする。optirun がハングする。

対象: GTX 965M やそれと似たようなカードを搭載した新しいノート PC で、bbswitch (例: Bumblebee 経由) や nouveau を使用している時。

dGPU 電源リソースがオンになっている場合、ACPI コードで失敗してフリーズが起こることがあります ([https://bugzilla.kernel.org/show_bug.cgi?id=156341 カーネルバグ 156341])。

nouveau を使用している際に、ランタイムの電源管理を無効化すると、nouveau が電源状態を変更しなくなるため、この問題を回避できます。
ランタイムの電源管理を無効化するには、カーネルパラメータに {{ic|1=nouveau.runpm=0}} を追加してください。

モデル固有の既知の解決策については、[https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-234494238 この issue] を見てください。
その他の場合、{{ic|1=acpi_osi="!Windows 2015"}} や {{ic|1=acpi_osi=! acpi_osi="Windows 2009"}} を[[カーネルパラメータ]]に追加して起動することで解決することもあります。(あなたのノート PC を先の issue で報告することを検討してください)

=== ノート PC/NVIDIA Optimus で画面が見つからない ===

以下のような出力がないか調べてください:

{{hc|$ lspci {{!}} grep VGA|
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation Device 0df4 (rev a1)
}}

NVIDIA ドライバ 319.12 Beta [https://www.nvidia.com/object/linux-display-amd64-319.12-driver.html] と Linux カーネル 3.9 以降では、NVIDIA ドライバは Optimus のサポートを提供します。

他の解決策は、[[Intel]] ドライバをインストールして、Intel ドライバにスクリーンを処理させることです。3D ソフトウェアを使用したい場合は、[[Bumblebee]] を使ってそのソフトウェアを実行し、NVIDIA カードを使うようにソフトウェアに指示する必要があります。

=== ランダムなフリーズ "(EE) NVIDIA(GPU-0): WAIT" ===

内蔵 AMD カードを搭載していて、専用 NVIDIA カードのみを使用するように設定している環境でプロプライエタリな (NVIDIA) ドライバを使用していると、最大 10 秒フリーズし、Xorg のログに以下のエラーが出力されると報告されています:

[ 219.796] (EE) NVIDIA(GPU-0): WAIT (2, 8, 0x8000, 0x0002e1c4, 0x0002e1cc)
[ 226.796] (EE) NVIDIA(GPU-0): WAIT (1, 8, 0x8000, 0x0002e1c4, 0x0002e1cc)

これはまだ根本的な原因ではありませんが、内蔵カードと専用カードが Xorg とやり取りする過程で競合が発生することと関連があるようです。

回避策は、切り替え可能なグラフィックスを使うことです。詳細は [[PRIME#PRIME レンダーオフロード]] を参照してください。

=== optimus-manager で "No Devices detected" ===

'lspci' が PCI ドメインを最初の出力列に出力してしまい、''optimus-manager'' が {{ic|BusID}} を複数のノート PC モデルにマッピングしようとして、{{ic|optimus-manager}} によって生成されたファイルが壊れてしまうことがあります。

GUI のロードが終わらない黒画面が発生する場合や、GUI が部分的にロードされたがコンソールにアーティファクトが発生する場合、Xorg が {{ic|(EE) - No Devices detected}} でクラッシュする場合には、[https://github.com/Askannz/optimus-manager/issues/471#issuecomment-1315628537 上流の GitHub ページ]に回避策とバグレポートがあります.

=== Xorg: マウスを動かしたときにだけ外部モニタが更新される ===

この問題に対する回避策は、iGPU の Xorg ドライバをアンインストールすることです (例: {{Pkg|xf86-video-amdgpu}} や {{Pkg|xf86-video-intel}}) [https://bbs.archlinux.org/viewtopic.php?id=284651]。この方法は、外部モニタのポート (HDMI/DP/USB-C) が NVIDIA dGPU に直接接続されている限り、うまく行くはずです。

{{Tip|デスクトップの挙動が奇妙になる場合があります (例: 仮想デスクトップを切り替えたり、Alt-Tab を使用したときに外部モニタの画像がフリーズするなど)。これは、ノート PC のモニタを無効化することで回避できます。}}

=== 消費電力 (TDP) が低いままになる ===

ドライバのバージョン 530.41 から、カードの消費電力が低く制限された状態に固定されてしまうというケースが発生し始めました ([https://github.com/NVIDIA/open-gpu-kernel-modules/issues/483 GitHub issue 483] を参照)。NVIDIA ドライバは、{{ic|nvidia-smi}} を使用して電力制限を手動で設定する機能を無効化していますが、多くのノート PC で低消費電力状態に固定されてしまい、パフォーマンスが悪化してしまいます。

(Ampere 世代及びそれ以降で) この問題を回避するには、[https://download.nvidia.com/XFree86/Linux-x86_64/535.54.03/README/dynamicboost.html DynamicBoost] を有効化する {{ic|nvidia-powerd.service}} を[[起動/有効化]]してください。

{{TranslationStatus|NVIDIA Optimus|2023-08-20|785744}}

NVIDIA

2025-06-28T07:26:51Z

AshMyzk: 同期

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[de:Nvidia]]
[[en:NVIDIA]]
[[es:NVIDIA]]
[[pt:NVIDIA]]
[[ru:NVIDIA]]
[[zh-hans:NVIDIA]]
{{Related articles start}}
{{Related|NVIDIA/ヒントとテクニック}}
{{Related|NVIDIA/トラブルシューティング}}
{{Related|Nouveau}}
{{Related|NVIDIA Optimus}}
{{Related|PRIME}}
{{Related|Bumblebee}}
{{Related|nvidia-xrun}}
{{Related|Xorg}}
{{Related|Vulkan}}
{{Related articles end}}

この記事は公式の [https://www.nvidia.com NVIDIA] グラフィックカードドライバをカバーしています。コミュニティによるオープンソースのドライバに関しては、[[Nouveau]] を見てください。ハイブリッドグラフックスを搭載しているノートパソコンを使っている場合は、[[NVIDIA Optimus]] も見て下さい。

== インストール ==

{{Warning|NVIDIA のウェブサイトで提供されているパッケージを通して NVIDIA ドライバをインストールすることは避けてください。[[pacman]] 経由でインストールすれば、システムをアップデートした際にドライバもアップデートすることができます。}}

{{Note|[[ハイブリッドグラフィックス]]のあるシステム上でデュアルブートする場合は、Windows またはサードパーティのアプリで ([https://www.asus.com/support/faq/1043747/#a14 ASUS Eco mode] のような) ''Eco mode'' を有効化すると NVIDIA のディスクリート GPU が完全に無効化され、検出されなくなります。}}

まず、[https://nouveau.freedesktop.org/wiki/CodeNames/ nouveau wiki のコードネームに関するページ]で、以下のコマンドで入手した GPU カードのモデル名/公式名に対応するファミリ名を探してください:

$ lspci -k -d ::03xx

次に、使用しているカードに適したドライバをインストールしてください:

{| class="wikitable"
|-
! GPU ファミリ
! ドライバ
! 状態
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV160 Turing (NV160/TUXXX)] 及びそれ以降
| {{Pkg|linux}} には {{Pkg|nvidia-open}} {{Pkg|linux-lts}} には {{Pkg|nvidia-open-lts}} {{Pkg|nvidia-open-dkms}} は任意のカーネルで使えます
| [https://developer.nvidia.com/blog/nvidia-transitions-fully-towards-open-source-gpu-kernel-modules/ 上流で推奨されています]。 現行。サポートあり。1
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV110 Maxwell (NV110/GMXXX)] から [https://nouveau.freedesktop.org/CodeNames.html#NV190 Ada Lovelace (NV190/ADXXX)]
| {{Pkg|linux}} には {{Pkg|nvidia}} {{Pkg|linux-lts}} には {{Pkg|nvidia-lts}} {{Pkg|nvidia-dkms}} は任意のカーネルで使えます
| 現行。サポートあり。1
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVE0 Kepler (NVE0/GKXXX)]
| {{AUR|nvidia-470xx-dkms}}
| rowspan="4" | レガシー。サポートなし。2,3
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NVC0 Fermi (NVC0/GF1XX)]
| {{AUR|nvidia-390xx-dkms}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV50 Tesla (NV50/G80-90-GT2XX)]
| {{AUR|nvidia-340xx-dkms}}
|-
| [https://nouveau.freedesktop.org/CodeNames.html#NV40 Curie (NV40/G70)] 及びそれ以前
| パッケージはもはや存在しません。
|}

# これらのパッケージが動作しない場合 (たいていはハードウェアが新しいことが原因です)、{{AUR|nvidia-open-beta}} が、新しいハードウェアをサポートしている新しいドライバのバージョンを提供しているかもしれません。
# [https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/007/indirect-branch-tracking/ Indirect Branch Tracking] との互換性が無いため、[https://www.intel.com/content/www/us/en/newsroom/opinion/intel-cet-answers-call-protect-common-malware-threats.html 第11世代及びそれ以降]の Intel CPU を搭載しているシステムで Linux 5.18 (及びそれ以降) においてこれらのドライバは動作しない場合があります。Indirect Branch Tracking は、[[ブートローダー]]から {{ic|1=ibt=off}} [[カーネルパラメータ]]を設定することにより、無効化することができます。ただし、このセキュリティ機能は[https://lwn.net/Articles/889475/ エクスプロイト手法の一種を緩和する]役割があるので注意してください。
# NVIDIA はもはやこれらのカードをアクティブにサポートしておらず、これらのドライバは[https://nvidia.custhelp.com/app/answers/detail/a_id/3142/ 現在の Xorg バージョンを公式にはサポートしていない場合があります]。[[nouveau]] ドライバを使うほうが簡単かもしれません。しかし、NVIDIA のレガシーなドライバは依然として利用可能であり、3D パフォーマンスまたは安定性に関して優れているかもしれません。

:{{Note|
:* {{Pkg|dkms}} をインストールする場合は、[[Dynamic Kernel Module Support#インストール]] を読んでください。
:* [[DKMS]] 版は特定のカーネルと結びついていません。カーネルのヘッダーファイルをインストールすると、そのカーネル用の NVIDIA カーネルモジュールをコンパイルし直すためです。
}}

32ビットアプリケーションのサポートに関しては、対応する ''lib32'' パッケージも [[multilib]] リポジトリからインストールしてください (例: {{Pkg|lib32-nvidia-utils}})。

{{Pkg|nvidia-utils}} パッケージには、再起動後に {{ic|nouveau}} モジュールをブラックリスト化するファイルが含まれています。任意で、{{ic|/etc/mkinitcpio.conf}} 内の {{ic|HOOKS}} 配列から {{ic|kms}} を削除し、その後 [[Initramfs を再生成する|initramfs を再生成]]してもよいです。こうすることで、initramfs に {{ic|nouveau}} モジュールが含まれないようにして、カーネルがこのモジュールを初期ブート中に読み込めないようにします。

{{Note|[[#Wayland 設定|Wayland]] を使用している場合は、[[#DRM カーネルモード設定]] に書かれてあることをするまで再起動するべきではありません。さもないと、再起動後に黒画面になってしまうかもしれません。}}

ドライバーをインストールしたら、[[#Xorg 設定]] または [[#Wayland 設定]] へと進んでください。

=== カスタムカーネル ===

使用中のカーネルで {{ic|1=CONFIG_DRM_SIMPLEDRM=y}} となっていることを確認してください。そして、{{ic|CONFIG_DEBUG_INFO_BTF}} を使用している場合、[[PKGBUILD]] で以下が必要です (カーネル 5.16 以降):

install -Dt "$builddir/tools/bpf/resolve_btfids" tools/bpf/resolve_btfids/resolve_btfids

{{ic|CONFIG_NOVA_CORE}} を有効化してコンパイルされたカーネルでは、新しい NVIDIA GPU ドライバである [https://docs.kernel.org/gpu/nova/index.html Nova] がロードされないようにする必要があるかもしれません。{{Pkg|nvidia-utils}} はデフォルトでこのドライバをブラックリストに追加します。[[カーネルモジュール#モジュールオプションを設定する|systemd-analyze を実行する]]ことで、ロードされていないことを確認できます。別のバージョンのドライバをインストールしている場合は、{{ic|nova_core}} と {{ic|nova_drm}} を手動で[[ブラックリスト|ブラックリストに登録]]する必要があるかもしれません。

=== DRM カーネルモード設定 ===

NVIDIA は [[カーネルモード設定#KMS の遅延開始|KMS の自動遅延読み込み]]をサポートしていないため、Wayland コンポジタを正しく動作させるには DRM ([[Wikipedia:Direct Rendering Manager|Direct Rendering Manager]]) [[カーネルモード設定]]を有効化する必要があります。

{{Pkg|nvidia-utils}} 560.35.03-5 から DRM はデフォルトで有効化されています。[https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/commit/1b02daa2ccca6a69fa4355fb5a369c2115ec3e22] それより古いドライバにおいては、{{ic|nvidia_drm}} モジュールに対して {{ic|1=modeset=1}} [[カーネルモジュールパラメータ]]を設定してください。

DRM が本当に有効化されているか調べるには、以下のコマンドを実行してください:

# cat /sys/module/nvidia_drm/parameters/modeset

正しく設定されていれば、このコマンドは {{ic|N}} ではなく {{ic|Y}} と出力するはずです。

{{Note|[[カーネル#公式サポートカーネル|Arch で公式にサポートされているカーネル]]は {{ic|simpledrm}} を有効化します。しかし、NVIDIA ドライバは、{{ic|1=nvidia_drm.fbdev}} が無効化されている/利用できない場合 (バージョン 545 より前)、{{ic|efifb}} または {{ic|vesafb}} を必要とします。}}

==== 早期ロード ====

基本的な機能については先のカーネルパラメータを追加するだけで十分でしょう。可能な限り早い時にロードさせたい場合や、スタートアップ時に問題 ({{ic|nvidia}} カーネルモジュールが[[ディスプレイマネージャ]]のあとにロードされてしまうなど) が発生する場合には、{{ic|nvidia}}、{{ic|nvidia_modeset}}、{{ic|nvidia_uvm}} そして {{ic|nvidia_drm}} を initramfs に追加することができます。initramfs ジェネレータを設定する方法については [[カーネルモジュール#モジュールの早期ロード]] を見てください。[[mkinitcpio]] を使用している場合、{{Pkg|nvidia}} ドライバの更新時に毎回 [[initramfs を再生成]]する必要がある場合があります。これを自動化する方法については [[#Pacman フック]] を見てください。

===== Pacman フック =====

{{Note|カスタムの pacman フックが必要になるのは、ビルド済みのカーネルモジュールが同梱されているパッケージに対してのみです。{{ic|*-dkms}} パッケージは、更新時に ''mkinitcpio'' が自動的に実行されるので、このようなカスタムの pacman フックは必要ありません。}}

NVIDIA ドライバをアップグレードした後に [[initramfs]] をアップデートすることを忘れないように、以下のような [[pacman フック]]を利用することができます:

{{hc|/etc/pacman.d/hooks/nvidia.hook|2=
[Trigger]
Operation=Install
Operation=Upgrade
Operation=Remove
Type=Package
# 構成に存在しない Target は省略できます。例えば、nvidia-open のみを使用する場合は、nvidia-lts の Target を省略できます。
Target=nvidia
Target=nvidia-open
Target=nvidia-lts
# 他のカーネルを使う場合は以下を適宜変更してください
Target=linux

[Action]
Description=Updating NVIDIA module in initcpio
Depends=mkinitcpio
When=PostTransaction
NeedsTargets
Exec=/bin/sh -c 'while read -r trg; do case $trg in linux*) exit 0; esac; done; /usr/bin/mkinitcpio -P'
}}

{{Note|上記の {{ic|Exec}} の行が複雑なのは {{ic|nvidia}} と {{ic|linux}} の両方がアップデートされた場合に ''mkinitcpio'' が何度も実行されるのを防ぐためです。このことが気にならないのであれば、{{ic|1=Target=linux}} と {{ic|NeedsTargets}} の行を削除して、{{ic|Exec}} の行は {{ic|1=Exec=/usr/bin/mkinitcpio -P}} のように単純化させることができます。}}

=== ビデオデコードのハードウェアアクセラレーション ===

VDPAU によるビデオデコードのアクセラレーションは GeForce 8 シリーズ及びそれ以降のカードでサポートされています。NVDEC によるビデオデコードのアクセラレーションは Fermi (~400 シリーズ) 及びそれ以降のカードでサポートされています。詳しくは [[ハードウェアビデオアクセラレーション]] をご覧ください。

=== NVENC によるビデオエンコードのハードウェアアクセラレーション ===

NVENC は {{ic|nvidia_uvm}} モジュールと、関連するデバイスノードが {{ic|/dev}} 下に作成されることを要求します。

最新のドライバーパッケージは、自動的にデバイスノードを作成する [[udev ルール]]を提供するので、追加の操作は必要ありません。

古いドライバ (例えば、{{AUR|nvidia-340xx-dkms}}) を使用している場合、デバイスノードを作成する必要があります。{{ic|nvidia-modprobe}} ユーティリティを実行するとデバイスノードが自動的に作成されます。{{ic|/etc/udev/rules.d/70-nvidia.rules}} を作成して {{ic|nvidia-modprobe}} を自動的に実行させることができます:

{{hc|/etc/udev/rules.d/70-nvidia.rules|2=
ACTION=="add", DEVPATH=="/bus/pci/drivers/nvidia", RUN+="/usr/bin/nvidia-modprobe -c 0 -u"}}

== Wayland 設定 ==

Xwayland に関しては [[Wayland#Xwayland]] を見てください。

その他の設定オプションについては、それぞれの[[Wayland#コンポジタ|コンポジタ]]の wiki ページやドキュメントを見てください。

{{Note|バージョン 555.xx より前のドライバを使用している場合や、{{ic|linux-drm-syncobj-v1}} プロトコルによって Explicit Sync をサポートしていない Wayland コンポジタを使用している場合、ネイティブの Wayland アプリと Xwayland アプリの両方でちらつき、フレーム順序の狂いなどの問題が発生する可能性があります。}}

=== 基本的なサポート ===

{{ic|nvidia_drm}} モジュールの重要なカーネルパラメータは {{ic|modeset}} と {{ic|fbdev}} です。{{Pkg|nvidia-utils}} パッケージを使用している場合、これらは両方とも[https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/blob/3b439109/PKGBUILD#L60 デフォルトで有効化されています]。また、NVIDIA は[https://indico.freedesktop.org/event/6/contributions/287/attachments/210/288/NVIDIA%20Wayland%20Roadmap.pdf 将来のリリースでこれらのパラメータをデフォルトで有効化することを計画しています]。

==== modeset ====

全ての Wayland 構成において {{ic|modeset}} を有効化することは適切に機能させるために必須です。

サポートの無いドライバについては、{{ic|modeset}} を手動で有効化する必要があります。詳細は [[#DRM カーネルモード設定]] と [[Wayland#要件]] を見てください。

==== fbdev ====

{{Out of date|{{Pkg|linux}} 6.14.2 と {{Pkg|nvidia}} 570.133.07 の時点で、Wayland は fbdev が無効化されていても動作するようです。また、下記の {{ic|cat}} コマンドは {{ic|N}} を返す可能性もあります。なので、この章はそれより古いバージョンのドライバのみが対象です。}}

一部の Wayland 構成においては {{ic|fbdev}} を有効化する必要があります。

Linux 6.11 以降においてこれは厳しい要件ですが、これが仕様なのかバグなのかは現在明らかになっていません。詳細は [https://forums.developer.nvidia.com/t/drm-fbdev-wayland-presentation-support-with-linux-kernel-6-11-and-above/307920] を参照してください。

これは [[#DRM カーネルモード設定|modesetting パラメータ]]と同じようにして設定することができます。ただし、以下のコマンドの出力は modesetting と異なります:

# cat /sys/module/nvidia_drm/parameters/fbdev

{{ic|fbdev}} が設定されていない場合は、このコマンドは {{ic|N}} を出力するのではなく、ファイルが存在しないことを示すエラーが発生します。

=== サスペンドのサポート ===

Wayland でのサスペンドは X よりもデフォルトの設定の問題が発生しやすいです。詳細は [[NVIDIA/ヒントとテクニック#サスペンド後にビデオメモリを保持する]] を参照してください。

GDM を使用している場合は、[[GDM#Wayland とプロプライエタリな NVIDIA ドライバ]] も参照してください。

== Xorg 設定 ==

プロプライエタリな NVIDIA グラフィックドライバは Xorg サーバの設定ファイルを必要としません。[[Xorg#起動|X を起動]]してみて、Xorg サーバが設定ファイル無しで正しく機能するかを確認することができます。しか、様々な設定を調整するために設定ファイル ({{ic|/etc/X11/xorg.conf}} よりも {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} を優先して使用してください) を作成する必要があるかもしれません。この設定は、NVIDIA Xorg 設定ツールによって生成することができますし、手動で作成することもできます。手動で作成した場合、([[Xorg]] サーバに基本的なオプションのみを与えると言う意味で) 最小の設定にすることができますし、あるいは、Xorg の自動検出されたオプションや事前設定されたオプションをバイパスできる設定を含めることもできます。

{{Tip|その他の設定オプションは、[[NVIDIA/トラブルシューティング]] を見てください。}}

=== 自動設定 ===

NVIDIA のパッケージには、Xorg サーバの設定ファイル ({{ic|xorg.conf}}) を作成するための自動設定ツールが含まれています。次のコマンドで実行できます:

# nvidia-xconfig

このコマンドは {{ic|/etc/X11/xorg.conf}} を自動検出し、現在のハードウェアに応じてそのファイルを作成 (すでに存在する場合は編集) します。

デフォルトの深度、水平同期、垂直リフレッシュ、そして解像度が問題ないか {{ic|/etc/X11/xorg.conf}} を二重にチェックしてください。

=== nvidia-settings ===

{{Pkg|nvidia-settings}} は CLI または GUI を使って様々なオプションを設定することができるツールです。何もオプションをつけずに {{ic|nvidia-settings}} を実行すると GUI が起動します。CLI のオプションについては {{man|1|nvidia-settings}} を見てください。

{{Pkg|nvidia-settings}} の CLI/GUI は非 root なユーザとして実行でき、''nvidia-settings Configuration'' タブにある ''Save Current Configuration'' オプションで設定を {{ic|~/.nvidia-settings-rc}} に保存できます。

現在のユーザで {{ic|~/.nvidia-settings-rc}} をロードするには:

$ nvidia-settings --load-config-only

起動時に毎回このコマンドを実行させるには[[自動起動]]を見てください。

{{Note|{{ic|nvidia-settings}} から変更を加えると [[Xorg]] が起動しなくなったりクラッシュするようになったりすることがあります。生成された {{ic|~/.nvidia-settings-rc}} と [[Xorg]] のファイルの両方/片方を調整するか削除することで普通に起動できるようになるはずです。}}

=== 手動設定 ===

設定ファイルを編集することで、([[#自動設定|自動的に]]、または [[#NVIDIA settings|nvidia-settings]]によって有効化できない) いくつかの微調整をすることができます。変更を適用する前に Xorg サーバーを再起動する必要があります。

その他の詳細やオプションについては [https://download.nvidia.com/XFree86/Linux-x86_64/560.35.03/README/ NVIDIA Accelerated Linux Graphics Driver README and Installation Guide] をご覧ください。

==== 最小設定 ====

{{ic|20-nvidia.conf}} (もしくは非推奨の {{ic|xorg.conf}}) の基本的な設定ブロックは以下のようになります:

{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|
Section "Device"
Identifier "NVIDIA Card"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce GTX 1050 Ti"
EndSection
}}

==== 起動時のロゴを無効化 ====

古いドライバ ({{AUR|nvidia-340xx-dkms}}) を使用している場合、X の起動時に表示される NVIDIA ロゴスプラッシュスクリーンを無効化しておいたほうがいいかもしれません。{{ic|Device}} セクション内に {{ic|"NoLogo"}} オプションを追加してください:

Option "NoLogo" "1"

==== モニター検出をオーバーライド ====

{{ic|Device}} セクション内の {{ic|"ConnectedMonitor"}} オプションにより、 X サーバーが起動した時にモニター検出をオーバーライドできます。これにより、起動時間を大幅に減らせるかもしれません。利用可能なオプション: アナログ接続用の {{ic|"CRT"}}、デジタルモニター用の {{ic|"DFP"}}、テレビ用の {{ic|"TV"}}。

以下の行は起動時のチェックをバイパスし、モニターを DFP として認識することを NVIDIA ドライバーに強制します:

Option "ConnectedMonitor" "DFP"

{{Note|たとえディスプレイが薄型パネルであろうと、アナログ15ピン VGA 接続に対しては "CRT" を使用してください。"DFP" は DVI や HDMI、DisplayPort のデジタル接続のみを意図しています。}}

==== 輝度調整を有効化 ====

{{Out of date|時代遅れの可能性あり[https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/GXJG7D3ALUQKOE2DT4XCL4UXQUFDDSEC/]。上流のパッケージも古いようです。}}

以下をカーネルパラメータに追加してください:

nvidia.NVreg_RegistryDwords=EnableBrightnessControl=1

あるいは、以下を {{ic|Device}} セクション内に追加してください:

Option "RegistryDwords" "EnableBrightnessControl=1"

もし、この設定で輝度調整がまだ機能しない場合は、{{AUR|nvidia-bl-dkms}} をインストールしてみてください。

{{Note|{{AUR|nvidia-bl-dkms}} をインストールすることにより、バックライト輝度調整用の {{ic|/sys/class/backlight/nvidia_backlight/}} インターフェイスが提供されます。しかし、システムが {{ic|/sys/class/backlight/acpi_video0/}} に対してバックライト制御の変更を発行し続けるかもしれません。この場合の1つの解決策は、例えば、''inotifywait'' を使用して {{ic|acpi_video0/brightness}} の変更を監視し、それを変換して {{ic|nvidia_backlight/brightness}} に対して書き込むことです。[[バックライト#sysfs を変更しても明るさが変更されない]] をご覧ください。}}

==== SLI を有効化 ====

{{Out of date|バージョン 455.23.04 から、一部の SLI モードはもはやサポートされていません。}}

{{Warning|GTX 10xx シリーズ (1080、1070、1060 など) 以降は 2-way SLI のみがサポートされます。3-way や 4-way SLI は CUDA/OpenCL アプリケーションに対しては機能するかもしれませんが、すべての OpenGL アプリケーションに対してはたいてい機能しないでしょう。}}

NVIDIA ドライバーの [https://download.nvidia.com/XFree86/Linux-x86_64/560.35.03/README/xconfigoptions.html README] 付録 B によると: ''このオプションは、サポートされている構成で SLI レンダリングの設定を制御します。'' "サポートされている構成"とは SLI 認定マザーボードと、2基または3基の SLI 認定 GeForce GPU を搭載しているコンピュータのことです。

{{ic|lspci}} を使って1つ目の GPU の PCI Bus ID を調べてください:

{{hc|# lspci -d ::03xx|
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
03:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
04:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
08:00.0 3D controller: NVIDIA Corporation GM108GLM [Quadro K620M / Quadro M500M] (rev a2)
}}

調べた BusID (前述の例では 3) を {{ic|Device}} セクション内に追加してください:

BusID "PCI:3:0:0"

{{Note|フォーマットが重要です。BusID の値は {{ic|"PCI:<BusID>:0:0"}} のように指定されなければなりません。}}

希望する SLI レンダリングモードの値を {{ic|Screen}} セクション内に追加してください:

Option "SLI" "AA"

以下の表は利用可能なレンダリングモードです。

{| class="wikitable"
! 値 !! 挙動
|-
| 0, no, off, false, Single || レンダリング時にただ1つの GPU を使う。
|-
| 1, yes, on, true, Auto || SLI を有効化し、ドライバーが自動的に適切なレンダリングモードを選択することを許可する。
|-
| AFR || SLI を有効化し、Alternate Frame Rendering モードを使う。
|-
| SFR || SLI を有効化し、Split Frame Rendering モードを使う。
|-
| AA || SLI を有効化し、SLI アンチエイリアシングを使う。この値を Full-Scene アンチエイリアシングと一緒に使うと視覚品質が向上します。
|}

あるいは、''nvidia-xconfig'' ユーティリティを使って、これらの変更を {{ic|xorg.conf}} に追加できます:

# nvidia-xconfig --busid=PCI:3:0:0 --sli=AA

SLI モードが有効化されていることをシェルから確認するには:

{{hc|$ nvidia-settings -q all {{!}} grep SLIMode|
Attribute 'SLIMode' (arch:0.0): AA
'SLIMode' is a string attribute.
'SLIMode' is a read-only attribute.
'SLIMode' can use the following target types: X Screen.
}}

{{Warning|SLI を有効化した後に xorg を起動するとシステムがフリーズしたり、応答しなくなったりするかもしれません。再起動する前にディスプレイマネージャーを無効化することをおすすめします。}}

以上の設定で機能しない場合は、{{ic|nvidia-settings}} で得られる PCI Bus ID を使用する必要があるかもしれません。

{{hc|$ nvidia-settings -q all {{!}} grep -i pcibus|
Attribute 'PCIBus' (host:0[gpu:0]): 101.
'PCIBus' is an integer attribute.
'PCIBus' is a read-only attribute.
'PCIBus' can use the following target types: GPU, SDI Input Device.
Attribute 'PCIBus' (host:0[gpu:1]): 23.
'PCIBus' is an integer attribute.
'PCIBus' is a read-only attribute.
'PCIBus' can use the following target types: GPU, SDI Input Device.
}}

そして、xorg.d 内の PrimaryGPU オプションをコメントアウトしてください:

{{hc|/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf|
...

Section "OutputClass"
...
# Option "PrimaryGPU" "yes"
...
}}

この設定でグラフィカルブートの問題も解決できるかもしれません。

=== マルチモニター ===

一般的な情報は [[マルチディスプレイ]] を見て下さい。

==== NVIDIA Settings を使う ====

[[#nvidia-settings|nvidia-settings]] ツールを使ってマルチモニターを設定できます。

CLI で設定する場合、まずは以下を実行して {{ic|CurrentMetaMode}} を確認してください:

{{hc|$ nvidia-settings -q CurrentMetaMode|2=
Attribute 'CurrentMetaMode' (hostnmae:0.0): id=50, switchable=no, source=nv-control :: DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0}
}}

{{ic|::}} 以降の全て (上記の場合: {{ic|1=DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0}}}) を使って {{ic|1=nvidia-settings --assign "CurrentMetaMode=''your_meta_mode''"}} でディスプレイを再設定できます。

{{Tip|使用するモニターや解像度の設定ごとにシェルのエイリアスを作成すると便利です。}}

==== ConnectedMonitor ====

{{Out of date|{{ic|Option "TwinView"}} はバージョン 302.07 で削除され、TwinView は常に有効になっています。}}

ドライバーがセカンドモニタを正しく認識しない場合は、ConnectedMonitor を使って認識するように強制できます。

{{hc|/etc/X11/xorg.conf|

Section "Monitor"
Identifier "Monitor1"
VendorName "Panasonic"
ModelName "Panasonic MICRON 2100Ex"
HorizSync 30.0 - 121.0 # this monitor has incorrect EDID, hence Option "UseEDIDFreqs" "false"
VertRefresh 50.0 - 160.0
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor2"
VendorName "Gateway"
ModelName "GatewayVX1120"
HorizSync 30.0 - 121.0
VertRefresh 50.0 - 160.0
Option "DPMS"
EndSection

Section "Device"
Identifier "Device1"
Driver "nvidia"
Option "NoLogo"
Option "UseEDIDFreqs" "false"
Option "ConnectedMonitor" "CRT,CRT"
VendorName "NVIDIA Corporation"
BoardName "GeForce 6200 LE"
BusID "PCI:3:0:0"
Screen 0
EndSection

Section "Device"
Identifier "Device2"
Driver "nvidia"
Option "NoLogo"
Option "UseEDIDFreqs" "false"
Option "ConnectedMonitor" "CRT,CRT"
VendorName "NVIDIA Corporation"
BoardName "GeForce 6200 LE"
BusID "PCI:3:0:0"
Screen 1
EndSection

}}

{{ic|TwinView}} を使わずに1つのカードで2つのモニターを X で使うために {{ic|Screen}} でデバイスを複製しています。{{ic|nvidia-settings}} は追加した {{ic|ConnectedMonitor}} オプションを全て消してしまうので注意してください。

==== TwinView ====

{{Out of date|{{ic|Option "TwinView"}} はバージョン 302.07 で削除され、TwinView は常に有効になっています。}}

画面を2つ表示するのではなく1つの大きな画面を表示したい場合、{{ic|TwinView}} 引数を {{ic|1}} に設定してください。コンポジットを使いたい場合、このオプションを使用する必要があります。TwinView は全てのモニターが同一のカードに接続されている場合にのみ機能します。

Option "TwinView" "1"

設定例:

{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|
Section "ServerLayout"
Identifier "TwinLayout"
Screen 0 "metaScreen" 0 0
EndSection

Section "Monitor"
Identifier "Monitor0"
Option "Enable" "true"
EndSection

Section "Monitor"
Identifier "Monitor1"
Option "Enable" "true"
EndSection

Section "Device"
Identifier "Card0"
Driver "nvidia"
VendorName "NVIDIA Corporation"

#refer to the link below for more information on each of the following options.
Option "HorizSync" "DFP-0: 28-33; DFP-1 28-33"
Option "VertRefresh" "DFP-0: 43-73; DFP-1 43-73"
Option "MetaModes" "1920x1080, 1920x1080"
Option "ConnectedMonitor" "DFP-0, DFP-1"
Option "MetaModeOrientation" "DFP-1 LeftOf DFP-0"
EndSection

Section "Screen"
Identifier "metaScreen"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
Option "TwinView" "True"
SubSection "Display"
Modes "1920x1080"
EndSubSection
EndSection
}}

[https://download.nvidia.com/XFree86/Linux-x86_64/560.35.03/README/configtwinview.html Device オプション情報]。

SLI に対応しているカードが複数枚存在する場合、別々のカードに接続された複数のモニターを使うことができます (例: 2枚のカードが SLI で、各々のカードにモニターが1台ずつ接続)。SLI モザイクモードと "MetaModes" オプションで有効になります。以下は上記と同じように設定する例で、[[GNOME]] が完璧に動作します:

{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|
Section "Device"
Identifier "Card A"
Driver "nvidia"
BusID "PCI:1:00:0"
EndSection

Section "Device"
Identifier "Card B"
Driver "nvidia"
BusID "PCI:2:00:0"
EndSection

Section "Monitor"
Identifier "Right Monitor"
EndSection

Section "Monitor"
Identifier "Left Monitor"
EndSection

Section "Screen"
Identifier "Right Screen"
Device "Card A"
Monitor "Right Monitor"
DefaultDepth 24
Option "SLI" "Mosaic"
Option "Stereo" "0"
Option "BaseMosaic" "True"
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "Screen"
Identifier "Left Screen"
Device "Card B"
Monitor "Left Monitor"
DefaultDepth 24
Option "SLI" "Mosaic"
Option "Stereo" "0"
Option "BaseMosaic" "True"
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Default"
Screen 0 "Right Screen" 0 0
Option "Xinerama" "0"
EndSection
}}

===== TwinView を使って垂直同期 =====

TwinView と垂直同期 ('''nvidia-settings''' の "Sync to VBlank" オプション) を使っている場合、モニターの大きさが異なっていると片方の画面だけが同期されます。'''nvidia-settings''' にはどちらの画面を同期させるか設定するオプション ("Sync to this display device" オプション) が存在しますが、必ずしも機能するとはいいがたいです。起動時に以下の環境変数を追加することで解決します (例: {{ic|/etc/profile}} に追加):

export __GL_SYNC_TO_VBLANK=1
export __GL_SYNC_DISPLAY_DEVICE=DFP-0
export VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-0

{{ic|DFP-0}} は適切な画面に置き換えてください ({{ic|DFP-0}} は DVI 端子で {{ic|CRT-0}} は VGA 端子です)。ディスプレイの識別名は '''nvidia-settings''' の "X Server XVideoSettings" セクションで確認できます。

===== Twinview を使ってゲームを遊ぶ =====

TwinView を使ってフルスクリーンのゲームを遊ぶ場合、2つの画面が1つの大きな画面としてゲームから認識されることがあります。技術的にこれは正しいのですが (仮想的な X スクリーンの横幅は両方の画面を合わせたサイズになります)、ゲームを遊ぶときは両方の画面を使わないようにしたいときもあるでしょう。

SDL のこの挙動を修正するには、次を試して下さい:

export SDL_VIDEO_FULLSCREEN_HEAD=1

OpenGL の場合、{{ic|xorg.conf}} の {{ic|Device}} セクションに適切な Metamodes を追加して X を再起動してください:

Option "Metamodes" "1680x1050,1680x1050; 1280x1024,1280x1024; 1680x1050,NULL; 1280x1024,NULL;"

[[ゲーム#別の X サーバーでゲームを起動する|別の X サーバーでゲームを起動する]]方法もあります。上記の方法と一緒に使うことも可能です。

==== モザイクモード ====

モザイクモードは、複数のグラフィクカードでコンポジット有りで3つ以上のモニタを使用する唯一の方法です。ウィンドウマネージャは各モニタの違いを認識するかもしれませんし、しないかもしれません。モザイクモードには、有効な SLI 設定が必要です。SLI を使わずにベースモードを使用する場合でも、GPU は依然として SLI 対応/互換でなければなりません。

===== ベースモザイク =====

ベースモザイクモードは Geforce 8000 シリーズ以上の GPU で動作します。nvidia-setting の GUI から有効にすることはできません。''nvidia-xconfig'' コマンドラインプログラムを使用するか {{ic|xorg.conf}} を手動で編集する必要があります。Metamodes を指定してください。以下は4台の DFP を 2x2 の構成で使用する例です。各々の解像度は 1920x1024 で、2枚のカードにそれぞれ2台の DFP が接続されている場合:

# nvidia-xconfig --base-mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"

{{Note|ドキュメントには 2x2 のモニター構成が記述されていますが、Base Mosaic モードで[https://forums.developer.nvidia.com/t/basemosaic-v295-vs-v310-vs-v325-only-up-to-three-screens/30583#3954733 GeForce カードは人為的にモニタ3台に制限されています]。Quadro カードは4台以上のモニタをサポートしています。2014年9月現在、Windows ドライバはこの人為的な制限を落としましたが、Linux ドライバでは未だに残っています。}}

===== SLI モザイク =====

SLI 構成を使っていて、使用する GPU が Quadro FX 5800 や Quadro Fermi 以降の場合、SLI モザイクモードが利用できます。nvidia-settings の GUI の中から有効化するか、コマンドラインで設定してください:

# nvidia-xconfig --sli=Mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"

== NVswitch ==

NVswitch のあるシステム (AWS の H100x8 など) では、以下が必要です。

* nvidia-fabricmanager をインストールする。
* Fabric manager が必要とする、対応するカーネルモジュールをインストールする。

Fabric manager を使うと、pytorch が GPU が見つからないと報告してきます。

Fabric マネージャをインストールするには:

# Nvidia から tarball をダウンロードする。[https://developer.download.nvidia.com/compute/cuda/redist/fabricmanager/linux-x86_64/ こちら]
# バージョン 555.42.02 は正しく動作します。
# インストールスクリプト sbin/fm_run_package_installer.sh を変更してしてインストール先のパスを修正してください。

対応するカーネルドライバを入手するには:

# nvidia-beta-dkms と nvidia-utils-beta の AUR リポジトリを git clone してください。
# PKGBUILD を変更してバージョン 555.42.02 を使用するようにしてください。
# ビルドし、インストールしてください。
# 再起動してください。

最後に、{{ic|systemctl enable nvidia-fabricmanager}} と {{ic|systemctl start nvidia-fabricmanager}} を実行すれば、pytorch が動くはずです。

== ヒントとテクニック ==

[[NVIDIA/ヒントとテクニック]] を参照。

== トラブルシューティング ==

[[NVIDIA/トラブルシューティング]] を参照。

== 参照 ==

* [https://forums.developer.nvidia.com/t/current-graphics-driver-releases/28500 Current graphics driver releases in official NVIDIA Forum]
* [https://forums.developer.nvidia.com/c/gpu-graphics/linux/148 NVIDIA Developers Forum - Linux Subforum]

{{TranslationStatus|NVIDIA|2025-06-28|839409}}

パフォーマンスの向上

2025-06-28T06:32:40Z

AshMyzk: 同期

[[Category:ハードウェア]]
[[Category:システム管理]]
[[en:Improving performance]]
[[es:Improving performance]]
[[fr:Improving performance]]
[[pl:Improving performance]]
[[pt:Improving performance]]
[[ru:Improving performance]]
[[zh-hans:Improving performance]]
{{Related articles start}}
{{Related|パフォーマンスの向上/ブートプロセス}}
{{Related|Pacman ヒント#パフォーマンス}}
{{Related|OpenSSH#SSH の高速化}}
{{Related|OpenOffice#OpenOffice の高速化}}
{{Related|ノートパソコン}}
{{Related|Preload}}
{{Related articles end}}

この記事では、知覚または計測できるシステムパフォーマンスの向上を最終目的として、パフォーマンスに関連する基本的なシステム診断、及び、リソース消費量の削減やシステム最適化のための手順に関する情報を提供しています。ゲーミングおよび低レイテンシに特有のその他のアドバイスは [[ゲーム#パフォーマンスを向上させる]] も参照してください。

== 基本 ==

=== システムを知る ===

システムをチューンするには、全体のスピードを下げているボトルネックやサブシステムに狙いを定めるがベストな方法です。システムの仕様を知ることは、それらを特定することに役立ちます。

* (LibreOffice や Firefox などの) 巨大なアプリケーションを同時に動作させたときにコンピュータが遅くなる場合、RAM の容量が十分であるか確認してください。以下のコマンドを使って、"available" 列の値を確認してください: {{bc|$ free -h}}
* 起動時間が長い場合、または、アプリケーションを初めて起動するとき (だけ) にロードに長い時間が掛かる場合、おそらくハードドライブが遅過ぎます。ハードドライブの速度を計測するには {{ic|hdparm}} コマンドを使うことができます: {{bc|# hdparm -t /dev/sd''X''}} {{Note|{{Pkg|hdparm}} で出力されるのはハードドライブの純粋な読み込み速度なので、有効なベンチマークとは言えませんが、平均的なコンピュータでは (アイドル状態のときに) 40MB/s より高い数値が出るのが妥当です。}}
* 十分な RAM が利用できる時でも CPU 負荷が一貫して高い場合、不要な[[デーモン]]やプロセスを無効化するなどして CPU 使用量を減らすことを試みてください。{{Pkg|htop}} や {{ic|pstree}} などの[[アプリケーション一覧/ユーティリティ#システム監視|システム監視ツール]]で CPU 負担をモニタすることができます: {{bc|$ htop}}
* ダイレクトレンダリングを使うアプリケーション (つまり、ビデオプレイヤ、ゲーム、[[ウィンドウマネージャ]]などの GPU を使うアプリケーション) が遅い場合、GPU パフォーマンスを向上させることで解決するはずです。まず初めにダイレクトレンダリングが有効になっているかどうか確認しましょう。{{ic|glxinfo}} コマンドを使うことで確認できます ({{Pkg|mesa-utils}} パッケージに含まれています)。次のコマンドを実行すると {{ic|direct rendering: Yes}} と表示される必要があります: {{bc|$ glxinfo {{!}} grep "direct rendering"}}
* [[デスクトップ環境]]を動かしている場合、(不要な) 視覚デスクトップ効果を無効化することで GPU 使用率を削減できる場合があります。現在使用しているものがハードウェアや個人の要件に合わない場合、より軽量な環境を使用するか、[[デスクトップ環境#カスタム環境|カスタムの環境]]を作成しましょう。
* 最適化された[[カーネル]]を使用することでパフォーマンスを向上できます。一般に {{Pkg|linux-zen}} が良い選択肢です。しかし、この記事の特定の部分で説明されているように、デフォルトのカーネルを調節することで良いパフォーマンスを得られます。

=== ベンチマーク ===

最適化の効果を判断できないことがたびたびあります。そういった場合は[[ベンチマーク]]ツールで計測することができます。

== ストレージデバイス ==

==== セクタサイズ ====

NVMe ドライブや Advanced Format ハードディスクが[[アドバンスドフォーマット|適切な論理セクタサイズ]]を使用していることを確認してください。

=== パーティショニング ===

パーティションが[[パーティショニング#パーティションアライメント|適切にアライメントされている]]ことを確認してください。

==== 複数のドライブ ====

複数のドライブを持っているのであれば、ソフトウェア [[RAID]] を組んでパフォーマンスを劇的に向上させることができます。

[[スワップ]]を別のディスク上に作成することでもパフォーマンスを多少向上させることができます。特に、スワップが頻繁に発生する場合です。

===== SSD を HDD のキャッシュとして使う =====

ハードディスクから移行することができない場合、ソリッドステートドライブをキャッシュレイヤとして使うことで読み書き速度を向上させ、ランダムアクセスによるパフォーマンスの低下を減らすことができます。方法としては、[[LVM#キャッシュ]]、[[Bcache]]、[[Bcachefs#SSD キャッシング]] があります。

==== HDD でのレイアウト ====

従来の回転式 HDD を使用している場合、パーティションのレイアウトがシステムのパフォーマンスに影響を与える可能性があります。ドライブの最初のセクター（ディスクの外周の近く）は最後のセクターよりも高速です。また、パーティションを小さくすれば必要なドライブヘッドの移動が少なくなり、ディスク操作をスピードアップできます。従って、システムのために作るパーティションは小さく (15~20GiB、必要に応じて調節) して、できるだけドライブの最初に配置することが推奨されます。他のデータ（画像・動画など）は別のパーティションに置くべきです。通常、システム ({{ic|/}}) から home ディレクトリ ({{ic|/home}}) を分割することでこれを達成できます。

{{Note|このページのすべてのアドバイスにおいて言えることですが、得られる利益を計測してください: ハードドライブを[https://blog.stuffedcow.net/2019/09/hard-disk-geometry-microbenchmarking/#shortstroke ショートストローク]したり、合計容量の数％しか使わないようにしたりしない限り、一般的な使用においては読み書き操作が依然としてドライブ全体に及ぶため、パーティションを分割してもほんの数%しかアクセス時間は改善されません。それと比べて、SSD にアップグレードするとパフォーマンスが1桁以上向上します。}}

=== ファイルシステムの選択とチューニング ===

ファイルシステムごとに強みが異なるのでシステムごとにファイルシステムを選ぶことはとても重要です。[[ファイルシステム]]の記事に人気のあるファイルシステムの簡単な説明がされています。[[:カテゴリ:ファイルシステム]]から関連記事も見ることができます。

==== マウントオプション ====

様々な [[fstab#atime オプション|*atime]] オプションが、{{ic|strictatime}} のパフォーマンスのペナルティを軽減することができます。

他のマウントオプションはファイルシステム固有なので、ファイルシステムの関連記事を参照してください:

* [[Ext3]]
* [[Ext4#パフォーマンスの向上]]
* [[JFS#最適化]]
* [[XFS#パフォーマンス]]
* [[Btrfs#デフラグメンテーション]]、[[Btrfs#圧縮]]、{{man|5|btrfs}}
* [[ZFS#チューニング]]
* [[NTFS#パフォーマンスの向上]]

===カーネルパラメータの調整===

ブロックデバイスのパフォーマンスに影響するキーが複数存在します、詳しくは [[sysctl#仮想メモリ]] を見て下さい。

=== I/O スケジューラの設定 ===

==== 背景情報 ====

入出力 ''(I/O)'' スケジューラはストレージデバイスにブロック I/O の操作を送信するときの順番を決めるカーネルコンポーネントです。I/O スケジューラの目的は読み込みリクエストを最適な方法で扱うことであるため、以下の2つのドライブの特徴を押さえておくことが重要です:

* HDD は回転ディスクでありヘッドが物理的に必要な場所に移動します。そのため、ランダムアクセスは 3〜12ms と非常に遅くなります (ハイエンドサーバーのドライブなのかノートパソコンのドライブなのか、あるいはディスクコントローラの書き込みバッファを迂回するかなどで速度は変わります)。逆に連続アクセスなら高いスループットを得ることが可能です。連続アクセスならヘッドはほとんど動かなくてよいためです。典型的な HDD は毎秒200回ほどの I/O リクエストを処理することができます ''(IOPS)''。

* SSD には物理的に移動する部品がありません。ランダムアクセスはシーケンシャルアクセスと同じ速度が出ます (0.1ms 未満)。SSD は複数のリクエストを一度にこなすこともできます。典型的な SSD のスループットは 10,000 IOPS を超えるため、大抵の場合は必要な仕事量を上回ります。

プロセスを大量に実行してストレージの様々な場所の I/O リクエストを発生させているとき (つまりランダムアクセスをしている状態)、数千の IOPS が生成されますが、普通の HDD では 200 IOPS までしか対応できません。ストレージにアクセスできるまで待機するリクエストの待ち行列が作られることになります。I/O スケジューラはこの待ち行列を最適化します。

==== スケジューリングアルゴリズム ====

スループットを改善する方法の一つとして、待機リクエストの順番を論理アドレスで並び替えてできるだけ一番近いリクエストを通すことで、アクセスをリニア化する方法があります。これが [[w:ja:エレベータアルゴリズム|elevator]] スケジューラと呼ばれる Linux の最初の I/O スケジューラでした。

エレベータアルゴリズムの問題点はシーケンシャルアクセスをするプロセスが上手く動かなくなることです。そのようなプロセスは、データブロックを読み取って数マイクロ秒で処理してから次のブロックを読み出します。エレベータスケジューラはプロセスが近くのブロックを呼びだそうとしていることを知らないため、他の場所のリクエストに移ってしまいます。[[w:Anticipatory_scheduling|anticipatory]] IO スケジューラはこの問題を解決します。このスケジューラは、他のリクエストを処理する前に、近くで別の読み取り操作が発生することを予測して、数ミリ秒待機します。

上述のスケジューラはどちらも全体のスループットを改善することを目指していましたが、それによって不幸にも長い間待たされてしまうリクエストも発生していました。例えば、プロセスの多くがストレージ領域の最初の部分をリクエストしていて、不幸なプロセスはストレージの末端付近をリクエストしているような状況を考えて下さい。そのため、開発者は公平なアルゴリズムを作成することを決めて [[w:Deadline_scheduler|deadline]] スケジューラが追加されました。deadline スケジューラはアドレスによってキューの順番を決めますが (エレベーターアルゴリズムと同じ)、一定期間、リクエストがキューの中で待機した場合、リクエストを (経過時間によって順番が付けられる) "expired" キューに移動します。スケジューラは先に expired キューをチェックして、リクエストを処理してからエレベーターキューに移動します。このアルゴリズムは公平性のために全体のスループットを犠牲にしているわけです。

[[w:CFQ|Completely Fair Queuing (CFQ)]] は別のアプローチで問題に取り組みました。CFQ はプロセスの優先度に基づくキューを使ってタイムスライスと許容するリクエストの数を割り当てます。さらに [[cgroups]] のサポートを追加することで特定のプロセスグループに一定の IO を予約できるようにしました。これは共有・クラウドサーバーで特に役立ちます。ユーザーはリソースが必要なときに料金を払って IOPS を得られるのです。また、同期 I/O で近くの操作を待機するという ''anticipatory'' スケジューラの機能を改良して取り入れています。''anticipatory'' と ''elevator'' スケジューラは Linux カーネルから外され、下記のより高度な代替スケジューラに置き換えられました。

[https://docs.kernel.org/block/bfq-iosched.html Budget Fair Queuing (BFQ)] は CFQ のコードをベースにいくつか改善を加えています。各プロセスに固定長のタイムスライスを与えるかわりに、プロセスのセクタ数から計算した "budget" を割り当ててヒューリスティックを用います。BFQ は想定的に複雑なスケジューラであるため、オーバーヘッドが大きく、回転ドライブや低速 SSD に適しています。特に遅い CPU と組み合わせたときに高速なデバイスの足を引っ張ってしまうような場合に有用です。BFQ は個人用のシステムでインタラクティブな作業を行うときに、ストレージデバイスがまるで待機状態のときのように素早く反応することを目標としています。デフォルト設定ではスループットの最大化よりもレイテンシの最小化が優先されているのが特徴です。これにより、ハードドライブにおいて[https://www.phoronix.com/review/linux-50hdd-io/2 アプリケーションの起動を劇的に加速化]させられる場合があります。

[https://lwn.net/Articles/720675/ Kyber] はネットワークルーティングで用いられている積極的なキュー管理テクニックから生まれた新しいスケジューラです。リクエストを制限するメカニズムとして「トークン」を基に実装されています。リクエストの割当を受けるにはキューイングトークンを必要とすることで、リクエストのスタベーションを防ぎます。ディスパッチトークンによってデバイスの特定の優先度の操作に制限されます。さらに、ターゲットの読み込みレイテンシを定義して、レイテンシ目標を達成するためにスケジューラ自身がチューニングを行います。アルゴリズムの実装は比較的シンプルなので高速なデバイスでも効率的に機能します。

==== カーネルの I/O スケジューラ ====

初期のアルゴリズムには既にメインラインから外されているものもあります。公式の Linux カーネルはいくつかの I/O スケジューラをサポートしています。[https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mechanism_(blk-mq) Multi-Queue Block I/O Queuing Mechanism (blk-mq)] は I/O クエリを複数のキューに割り当てて、複数のスレッドおよび CPU コアにタスクを分散させます。このフレームワークでは以下のスケジューラが使えます:

*''None''、キューイングアルゴリズムは適用されません。
*''mq-deadline'' は deadline スケジューラ (下記を参照) をマルチスレッドに対応させたスケジューラです。
*''Kyber''
*''BFQ''

==== I/O スケジューラの変更 ====

{{Note|スケジューラーの最適な選択は、デバイスとワークロードの正確な性質の両方によって異なります。また、MB/秒単位のスループットだけがパフォーマンスの指標ではありません。デッドラインや公平性は全体的なスループットを低下させますが、システムの応答性を向上させる可能性があります。 [[ベンチマーク]] は、各 I/O スケジューラのパフォーマンスを示すのに役立つ場合があります。}}

特定のデバイスで利用可能なスケジューラとアクティブなスケジューラを表示するには (アクティブなスケジューラは角括弧の中):

{{hc|$ cat /sys/block/'''''sda'''''/queue/scheduler|
mq-deadline kyber [bfq] none
}}

全デバイスで利用可能なスケジューラを表示するには:

{{hc|$ grep "" /sys/block/'''*'''/queue/scheduler|
/sys/block/pktcdvd0/queue/scheduler:none
/sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none
/sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none
}}

デバイス ''sda'' のアクティブな I/O スケジューラを ''bfq'' に変更するには:

# echo '''''bfq''''' > /sys/block/'''''sda'''''/queue/scheduler

I/O スケジューラの変更プロセスは、ディスクが回転式か否かに応じて自動化することができ、起動毎に永続化させることができます。例えば、以下の [[udev]] ルールは、回転ドライブに対しては ''bfq'' を、[[SSD]]/eMMC ドライブに対しては ''bfq'' を、[[NVMe]] に対しては ''none'' を設定します:

{{hc|/etc/udev/rules.d/60-ioschedulers.rules|<nowiki>
# HDD
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

# SSD
ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"

# NVMe SSD
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
</nowiki>}}

再起動するか、強制的に[[udev#新しいルールをロードする|新しいルールをロード]]してください。

==== IO スケジューラの調整 ====

カーネルの I/O スケジューラには遅延・期限時間や FIFO パラメータなどそれぞれ設定項目が存在します。特定のデバイスとワークロードの組み合わせにあわせてアルゴリズムを調整することが可能です。スループットを高めたり遅延を少なくしたりするときに用います。
設定項目と説明は [https://docs.kernel.org/block/index.html カーネルドキュメント] で確認できます。

特定のデバイスで設定可能なパラメータを確認するには (以下の例では ''sdb'' は ''deadline'' を使用しています):

{{hc|$ ls /sys/block/'''''sdb'''''/queue/iosched|
fifo_batch front_merges read_expire write_expire writes_starved}}

レイテンシを犠牲に ''deadline'' のスループットを高めるには以下のコマンドで {{ic|fifo_batch}} を増やします:

{{bc|# echo ''32'' > /sys/block/'''''sdb'''''/queue/iosched/'''fifo_batch'''}}

=== 電源管理設定とライトキャッシュ ===

従来の回転ディスク (HDD) を使用する場合は、省電力機能を完全に無効にするか下げるかし、書き込みキャッシュが有効になっているかどうかを確認すると良いかもしれません。

[[Hdparm#電源管理の設定]] と [[Hdparm#ライトキャッシュ]] を参照してください。

後で、起動時にこれらを適用する [[Hdparm#udev ルールによる永続的な設定|udev ルール]] を作成することができます。

{{Tip|[[GNOME]] では、"ディスク" アプリケーションからこれらのパラメータのいくつかを設定でき、udev ルールは必要ありません。}}

{{Note|一部の機能はあなたのハードドライブではサポートされていないかもしれません。その場合、Hdparm が通知します。なので、この特定の機能の設定を無視してください。}}

=== ディスクの読み書きを減らす ===

遅いストレージデバイスへの不必要なアクセスを避けることはパフォーマンスを向上にとって良いことであり、デバイスの寿命を伸ばすことにも繋がります。ただし最近のハードウェアでは寿命への影響はわずかです。

{{Note|書き込み増幅率が平凡な 10x で、書き込み/消去サイクルが標準的な 10000 である、32GB の SSD の場合、'''毎日 10GB のデータ書き込みを行うと'''、'''8年間で寿命が尽きる'''とされます。この数字はもっと[https://kcall.co.uk/ssd/ 容量が大きい SSD] を使ったり書き込み増幅が少ない最新のコントローラを使うことで改善されます。また、ディスクの書き込みを制限するのにどの方法が必要なのか考えるときは[https://web.archive.org/web/20161124030749/http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead この耐久実験]も参照してください。}}

==== ディスクの書き込みを表示する ====

{{Pkg|iotop}} パッケージはプログラムをディスクの書き込み数でソートして、どれくらいの頻度でどれだけディスクに書き込んでいるか表示します。詳しくは {{man|8|iotop}} を見てください。

==== ファイルを tmpfs に再配置する ====

ブラウザプロファイルなどのファイルを [[tmpfs]] ファイルシステムに再配置してメモリ内に保存することで、アプリケーションのレスポンスを向上させることができます:

* ブラウザプロファイルを同期させる方法については [[Profile-sync-daemon]] を参照してください。特定のブラウザには注意が必要な場合があります。例えば [[Firefox Ramdisk]] を参照してください。
* 任意の指定されたフォルダを同期させる方法については [[Anything-sync-daemon]] を参照してください。
* tmpfs 内でパッケージをビルドすることでコンパイル時間を減らす方法については [[Makepkg#ビルド時間を短縮する]] を参照してください。

==== ファイルシステム ====

対応する[[ファイルシステム]]ページを参照して、パフォーマンス改善に関する指示があるか見てください。[[#ファイルシステムの選択とチューニング]] に挙げられているファイルシステムのリストも参照してください。

==== スワップ領域 ====

詳細は [[スワップ#パフォーマンス]] を見てください。

==== ライトバックの間隔とバッファサイズ ====

詳細は [[Sysctl#仮想メモリ]] を見てください。

==== コアダンプを無効化する ====

[[コアダンプ#自動的なコアダンプの無効化]] を見てください。

=== ionice によるストレージ I/O スケジューリング ===

バックアップなど多くのタスクにおいては、そのタスクを実行するために、ストレージ I/O の遅延が短かったり、ストレージ I/O の帯域が大きかったりする必要はありません。そのようなタスクはバックグラウンドタスクに分類することができます。一方、デスクトップにおいて高速な I/O は UI の応答性を高める上で必須です。ゆえに、他のタスクがストレージ I/O を必要としている間は、バックグラウンドタスクによって利用できるストレージ帯域幅を減らすことが有益です。これは、プロセスごとに異なる優先度を設定できる Linux I/O スケジューラ BFQ を使用することで実現できます。

以下のようにバックグラウンドプロセスを実行することで、プロセスの I/O 優先度 "Idle" レベルまで落とすことができます:

$ ionice -c 3 ''command''

詳細は [https://www.cyberciti.biz/tips/linux-set-io-scheduling-class-priority.html a short introduction to ionice] や {{man|1|ionice}} を参照してください。

=== トリム ===

最適なパフォーマンスを得るには、SSD の空きブロックを定期的に discard (トリム) してランダム書き込みの速度を最適化するべきです。詳細は [[ソリッドステートドライブ#TRIM]] を参照してください。

== ネットワーク ==

* カーネルネットワーキング: [[Sysctl#パフォーマンスを向上させる]] を参照
* NIC: [[ネットワーク設定#MTU とキューの長さの設定]] を参照
* DNS: キャッシュ付きの DNS リゾルバの使用を検討してください。[[ドメイン名前解決#DNS サーバ]] を参照
* Samba: [[Samba#スループットを向上させる]] を参照

== CPU ==

=== オーバークロック ===

[[Wikipedia:ja:オーバークロック|オーバークロック]]は、CPU クロック周波数の上限を上げることにより、CPU の計算パフォーマンスを向上させます。オーバークロックできるかどうかは、CPU モデルとマザーボードモデルの組み合わせに依存します。オーバークロックは BIOS を介して行うのが最も一般的です。オーバークロックには欠点とリスクもあります。ここでは推奨も非推奨もしないでおきましょう。

Intel 製のチップの多くは acpi_cpufreq などや他のほとんどのユーティリティに正しいクロック周波数を伝えません。この結果、[[dmesg]] は極端なメッセージを表示します (これは、{{ic|acpi_cpufreq}} カーネルモジュールをアンロードしてブラックリスト化することで回避可能です)。クロック速度を読むには、{{Pkg|i7z}} パッケージの ''i7z'' を使用してください。オーバークロックされた CPU が正しく動作していることを確認する方法として、[[ストレステスト]]が推奨されます。

=== 周波数スケーリング ===

[[CPU 周波数スケーリング]]を見てください。

=== CPU スケジューラ ===

メインライン Linux カーネルのデフォルトの CPU スケジューラは [https://lwn.net/Articles/925371/ EEVDF] です。

* {{App|[[Wikipedia:Brain_Fuck_Scheduler#MuQSS|MuQSS]]|Multiple Queue Skiplist Scheduler。[[Wikipedia:Con_Kolivas|Con Kolivas]] によって開発されている {{ic|-ck}} パッチセットにより利用可能。|[[非公式ユーザーリポジトリ/Repo-ck]]|{{AUR|linux-ck}}}}
* {{App|[https://cchalpha.blogspot.com/2020/05/project-c-announcement.html Project C]|BMQ を Project C にリファクタリングするためのクロスプロジェクト。Project C コードベースに基づいて PSD を再作成します。よって、これは2つのプロジェクトのマージであり、その後 PDS が Project C として更新されます。より最近の開発として推奨されます。|https://cchalpha.blogspot.com/|{{AUR|linux-prjc}}}}
* {{App|BORE|BORE スケジューラは、対話型タスクにおいてある程度の公平性を犠牲にして低レイテンシを実現することに焦点を当てています。CFS の上に構築されており、vruntime コード更新だけに調整されています。なので、他の非公式 CPU スケジューラと比較して、全体的な変更は非常に小さいです。|https://github.com/firelzrd/bore-scheduler|{{AUR|linux-cachyos-bore}}}}
* {{App|SCX|システムをリセットせずに様々な CPU スケジューラを動的にロードできるようにします。|https://github.com/sched-ext/scx|{{Pkg|scx-scheds}}}}

=== リアルタイムカーネル ===

(TV チューナーカードをフル HD 解像度 (1080p) で実行するなど) 一部の使用用途では、[[リアルタイムカーネル]]を使うと利益を得られる場合があります。

=== プロセスの優先順位を設定 ===

{{man|1|nice}} と {{man|1|renice}} も参照してください。

==== Ananicy ====

[https://gitlab.com/ananicy-cpp/ananicy-cpp Ananicy CPP] は動的に実行可能ファイルの nice レベルを調整するためのデーモンで、{{Pkg|ananicy-cpp}} や {{AUR|ananicy-cpp-git}} パッケージで利用可能です。nice レベルとは、CPU リソースを配分するときの実行可能ファイルの優先度を表すものです。

{{Warning|1=[[Gamemode]] と [https://gitlab.com/ananicy-cpp/ananicy-cpp Ananicy CPP] はどちらもプロセスの nice レベルを調整しようとします。これらのツールを組み合わせて使用することは推奨されていません。[https://github.com/CachyOS/ananicy-rules/blob/master/README.md#gamemode--ananicy-cpp--bad-idea]}}

==== cgroups ====

[[cgroups]] を見てください。

==== LimitCPU ====

[https://limitcpu.sourceforge.net/ LimitCPU] は特定のプロセスの CPU 使用率を制限するプログラムです。{{AUR|limitcpu}} をインストールすれば、プロセスの PID で CPU 使用率を 0 から 100 までの値にコンピュータに搭載されている CPU コア数をかけた数字の範囲で制限することができます。例えば、CPU コアが8個であれば利用可能な値は 0 から 800 です。使用例:

$ limitcpu -l 50 -p 5081

=== irqbalance ===

{{Pkg|irqbalance}} はマルチプロセッサシステムでパフォーマンスを向上させるためにプロセッサ間でハードウェア割り込みを分散させます。{{ic|irqbalance.service}} で[[systemd#ユニットを使う|操作]]することが可能です。

=== CPU の脆弱性の緩和策をオフにする ===

{{Warning|1=以下の設定を使うときは問題の脆弱性について確認してください。詳しくは [https://phoronix.com/scan.php?page=news_item&px=Linux-Improve-CPU-Spec-Switches こちら] や [https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_CPUs こちら] のページを参照。}}

CPU の脆弱性の緩和策をオフにすることで、パフォーマンスが向上する場合があります。以下の[[カーネルパラメータ]]ですべての緩和策が無効になります:

mitigations=off

このパラメータによって切り替えられるすべてのスイッチについての説明は、[https://docs.kernel.org/admin-guide/kernel-parameters.html kernel.org] で見られます。{{AUR|spectre-meltdown-checker}} や {{man|1|lscpu}} ({{Pkg|util-linux}} に同梱) を使うことで、脆弱性チェックを行うことができます。

{{Note|1=第10世代およびそれ以降の Intel CPU、または AMD Ryzen シリーズ 1000 およびそれ以降の CPU を使用している場合、緩和策を無効化することにより得られるパフォーマンスの向上は、最大でも 5% にとどまります。一方、それ以前の世代の CPU では、最大 25% まで向上します。[https://www.phoronix.com/scan.php?page=article&item=3-years-specmelt 2021 初頭における総評]、[https://www.phoronix.com/scan.php?page=article&item=spectre-rocket-lake Rocket Lake におけるテスト]、[https://www.phoronix.com/scan.php?page=article&item=alder-lake-mitigations Alder Lake におけるテスト] を参照。}}

== グラフィック ==

=== Xorg の設定 ===

グラフィックパフォーマンスは {{man|5|xorg.conf}} の設定に依存している場合があります。[[NVIDIA]]、[[AMDGPU]]、[[Intel]] の記事を参照してください。不適切な設定は Xorg が動作しなくなる原因になるため、注意しましょう。

=== Mesa の設定 ===

Mesa ドライバのパフォーマンスは [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ drirc] で設定できます。{{Pkg|adriconf}} (Advanced DRI Configurator) はオプションを設定して標準の drirc ファイルに書き込むことで MESA ドライバを設定する GUI ツールです。

=== ハードウェアビデオアクセラレーション ===

[[ハードウェアビデオアクセラレーション]]により、ビデオカードに動画のデコード/エンコードをさせることができます。

=== オーバークロック ===

CPU と同様に、(GPU の) オーバークロックは直接的にパフォーマンスを向上できますが、一般には推奨されません。いくつかのパッケージがあります: {{AUR|rovclock}} (ATI カード)、{{Pkg|rocm-smi-lib}} (最近の AMD カード)、{{AUR|nvclock}} (古い NVIDIA カード - Geforce 9 まで)、{{Pkg|nvidia-utils}} (最近の NVIDIA カード)。

[[AMDGPU#オーバークロック]] や [[NVIDIA/ヒントとテクニック#オーバークロックを有効化する]] を参照してください。

=== PCIe resizable BAR を有効化する ===

{{Note|
* 一部のシステムでは、PCIe resizable BAR を有効化するとパフォーマンスが大幅に劣化する可能性があります。システムのベンチマークを行って、PCI resizable BAR がパフォーマンスを向上させていることを確認してください。
* 効果を発揮させるには、[[Wikipedia:Unified Extensible Firmware Interface#CSM booting|Compatibility Support Module (CSM)]] を無効化しなければなりません。
}}

PCI の仕様では、PCI デバイスのメモリを PCI コントローラに公開するために、より大きい[[wikipedia:PCI_configuration_space#Standardized_registers|基底アドレスレジスタ]] (BAR) を使用できます。そうすることで、ビデオカードのパフォーマンスを向上できる可能性があります。ビデオメモリ全体にアクセスすることでパフォーマンスを向上できますし、グラフィックドライバの最適化も可能になります。Resizable BAR、above 4G decoding、そしてドライバ最適化の組み合わせを、AMD は [https://www.amd.com/en/gaming/technologies/smart-technologies.html AMD Smart Access Memory] と呼んでおり、初期は AMD Series 500 チップセットマザーボードで利用できましたが、後に UEFI アップデートを通して AMD Series 400 と Intel Series 300 以降に拡張されました。この設定はすべてのマザーボードで利用できるわけではなく、特定のボードではブート問題を引き起こすことが知られています。

BAR のサイズが 256M の場合、この機能は有効化されていないか、サポートされていません:

{{hc|1=# dmesg {{!}} grep BAR=|2=
[drm] Detected VRAM RAM=8176M, BAR=256M}}

有効化するには、マザーボード設定で "Above 4G Decode" か ">4GB MMIO" という名前の設定を有効化してください。BAR が大きくなっていることを確認するには:

{{hc|1=# dmesg {{!}} grep BAR=|2=
[drm] Detected VRAM RAM=8176M, BAR=8192M}}

== RAM、スワップ、OOM 処理 ==

=== クロック周波数とタイミング ===

RAM は BIOS で設定することで、クロック周波数とタイミングを別々にすることができます。メモリのパフォーマンスは両方の値によって変わります。BIOS に用意されている最高速のプリセットを選択することでデフォルト設定よりも性能を上げることができます。マザーボードやメモリのメーカーがサポートしていない周波数まで値を高めると、CPU のオーバークロックと同じようなリスクがあるので注意してください。[[#オーバークロック]]を参照。

=== RAM オーバーレイ上に root を置く ===

{{Out of date|liveroot スクリプトはメンテナンスされていないようです。しかし、このアプローチは依然として機能するはずです。}}

書き込みが遅いメディア (USB や回転 HDD) を使う場合、(ディスク上の) 読み取り専用の root の上で RAM オーバーレイを作って root を動作させることができます。root に書き込みできる領域が制限されるかわりにパフォーマンスが劇的に改善します。{{AUR|liveroot}} を見て下さい。

=== Zram または zswap ===

[[zswap]] や [[zram]] を使うことで、似たような利点を (同じくらいのコストで) 得られます。これら2つは一般に意図が似ていますが、動作が異なります:

* Zswap は、圧縮された RAM キャッシュとして動作し、ユーザ空間の設定をあまり必要としません (と同時に許可もしていません)。スワップデバイスと組み合わせて、スワップのキャッシュとして動作します。スワップに入りそうなページは、代わりに zswap に入る可能性があります。
* Zram は、RAM 内に圧縮されたブロックデバイスを作成できるカーネルモジュールです。この圧縮されたブロックデバイスはそれ単体でスワップデバイスとして使用でき、他のスワップデバイスと組み合わせてる必要はありません。多くの設定オプションがあり、例えばコールドページを保持しておくバッキングデバイスを使用するかどうかも指定できます。

両方とも[[スワップ]]サブシステムを呼び出すため、スワップに影響を与える設定はこれらのシステムにも影響を与えます。例えば、[[スワップ#swappiness|{{ic|vm.swappiness}}]] は、メモリが圧迫している状況で、カーネルがファイルキャッシュをドロップするか、ページをスワップに移動させるかのどちらを優先させるかを指定します。Zswap はページのスワップへの移動動作をインターセプトし、zram もスワップとして動作するため、このオプションはこれら2つのメカニズムがどれくらいの頻度で使用されるかにも影響を与えます。

=== グラフィックカードの RAM を使う ===

稀なケースとして、RAM 容量が非常に小さいが、ビデオ RAM に余りがある場合、後者をスワップとして使用できます。[[ビデオメモリにスワップ]] を参照してください。

=== メモリ不足の状況におけるシステムのレスポンスを改善する ===

従来の GNU/Linux システム (特にグラフィカルワークステーション) では、割り当てられたメモリがオーバーコミットすると、カーネル内の out-of-memory (OOM) killer がトリガーされるか、十分な量のメモリが開放される (システムが応答しない場合、メモリを大量消費するアプリケーションを閉じることは難しいため、これはすぐには起こり得ないでしょう) まで、システム全体のレスポンスがほぼ使用不能な状態まで低下します。挙動は特定の環境や条件に依存しており、通常のレスポンス状態に戻るまでには数秒から30分以上かかる場合があります。会議でのプレゼンテーションなどのような重要な状況においては、待つのが苦痛になるでしょう。

[https://lore.kernel.org/lkml/d9802b6a-949b-b327-c4a6-3dbca485ec20@gmx.com/T/ カーネル]と[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ Fedora] のメーリングリストで議論されている通り、メモリ不足の状況におけるカーネルとユーザ空間の挙動は将来的に改善されるかもしれませんが、ユーザは、システムのハードリセットや {{ic|vm.overcommit_*}} [[sysctl]] パラメータの調整よりも実行可能で効果的なオプションを使うことができます:

* [https://docs.kernel.org/admin-guide/sysrq.html Magic SysRq キー] ({{ic|Alt+SysRq+f}}) で手動でカーネルの OOM killer をトリガーする。
* ユーザ空間の OOM デーモンを使ってこれに自動的 (または対話的) に対処する。

{{Warning|OOM killer をトリガーして実行中のアプリケーションを kill すると、保存されていない作業が失われる場合があります。アプリケーションが最終的に通常通りメモリを開放してくれることを期待して辛抱強く待つか、あるいは応答がないシステムを可能な限り早く通常に戻したいと望むかは、あなた次第です。}}

カーネルの OOM killer では終了する (しない) プロセスに優先順位を付けられないので、SysRq よりも OOM デーモンのほうが好ましい場合もあります。いくつかの OOM デーモンをリストアップしました:

* {{App|systemd-oomd|[[systemd]] によって {{ic|systemd-oomd.service}} として提供されています。cgroups-v2 と pressure stall information (PSI) を使用してプロセスを監視し、カーネル空間で OOM が発生する前にアクションを取ります。|https://github.com/systemd/systemd, {{man|8|systemd-oomd}}|{{Pkg|systemd}}}}
* {{App|earlyoom|C で書かれた、シンプルなユーザ空間の OOM killer 実装です。|https://github.com/rfjakob/earlyoom|{{Pkg|earlyoom}}}}
* {{App|oomd|[https://lwn.net/Articles/759781/ PSI] ベースの OOM killer 実装です。Linux カーネルバージョン 4.20+ を必要とします。設定は JSON で行い、非常に複雑です。Facebook の本番環境において動作確認済み。|https://github.com/facebookincubator/oomd|{{AUR|oomd}}}}
* {{App|nohang|Python で書かれた、洗練された OOM ハンドラ。オプションで PSI サポートあり。earlyoom よりも設定可能です。|https://github.com/hakavlad/nohang|{{AUR|nohang-git}}}}
* {{App|low-memory-monitor|GNOME 開発者の取り組み。ユーザ空間のアプリケーションにメモリ不足の状態を伝えるためのより良いコミュニケーションを提供することを目的としており、さらにカーネルの OOM killer をトリガーするように設定することができます。PSI ベースで、Linux 5.2+ を必要とします。|https://gitlab.freedesktop.org/hadess/low-memory-monitor/|{{AUR|low-memory-monitor-git}}}}
* {{App|uresourced|アクティブなグラフィカルユーザセッションに対して、cgroup ベースのリソース保護を有効化する小さなデーモン。|https://gitlab.freedesktop.org/benzea/uresourced|{{AUR|uresourced}}}}

== ウォッチドッグ ==

[[Wikipedia:Watchdog timer]] ([[wikipedia:ja:ウォッチドッグタイマー|日本語版]]) より:

:ウォッチドッグタイマーはコンピュータの動作に支障が生じていないか確認して復旧するために使われる電子的なタイマーである。通常、コンピュータは定期的にウォッチドッグタイマーをリセットする。何らかの理由でウォッチドッグをリセットできなかった場合、タイマーによってタイムアウト信号が生成され、コンピュータを安定状態に移行して通常のシステムオペレーティングを復旧させるなどの対応が行われる。

よって、ウォッチドッグは例外的な状況でカーネルの回復を最適化するために使用されています。もし、'''重要なシステムサービス''' (例: ネットワーク、ファイルシステム、ACPI、systemd) が応答しなくなった場合、ウォッチドッグはそれを検知し、再起動をトリガーします。それにより、システムがロックアップし、応答しなくなったサービスのせいで長い遅延が発生してしまうことを回避できます。[[#メモリ不足の状況におけるシステムのレスポンスを改善する]] で説明されているように、この緊急メカニズムとランタイムのシステムリソース管理とを区別することは重要です。

=== systemd ウォッチドッグ ===

systemd にはウォッチドッグのリセット機構が内蔵されています。これは、適切なカーネルモジュールがロードされている場合に (以下を参照)、{{ic|/dev/watchdog}} として公開されているハードウェアウォッチドッグと対話します。システムが応答しなくなった場合、ハードウェアウォッチドッグがシステムリセットをトリガーします。

==== systemd でウォッチドッグを設定する ====

デフォルトでは、{{ic|RuntimeWatchdogSec}} は無効化されています。システムのウォッチドッグを有効化するには、以下のような {{man|5|systemd-system.conf}} [[ドロップインファイル]]を作成してください:

{{hc|/etc/systemd/system.conf.d/watchdog.conf|2=
[Manager]
RuntimeWatchdogSec=10s
RebootWatchdogSec=45s
}}

* {{ic|1=RuntimeWatchdogSec=10s}}: systemd が 10 秒より長く応答しなかった場合、システムを再起動します。
* {{ic|1=RebootWatchdogSec=45s}}: システムが再起動中にハングした場合、ウォッチドッグは 45 秒後にリセットを強制します。

以下のコマンドで適用します:

# systemctl daemon-reexec

ウォッチドッグがアクティブであることを確認してください:

{{hc|$ systemctl show {{!}} grep Watchdog|2=
RuntimeWatchdogUSec=10s
RebootWatchdogUSec=45s
}}

==== ハードウェアのウォッチドッグサポートを確認する ====

多くのシステムで、ハードウェアウォッチドッグのサポートは異なるカーネルモジュール (例: 一部の Intel チップセットでは {{ic|iTCO_wdt}}、特定の AMD プラットフォームでは {{ic|sp5100_tco}}) によって提供されている場合があります。ハードウェアウォッチドッグのモジュールを確認するには、以下を実行してください:

$ lsmod | grep wdt

関連するウォッチドッグモジュール (例: {{ic|iTCO_wdt}}、{{ic|sp5100_tco}}) を見つけたら、以下のようなファイルを作成してモジュールが[[カーネルモジュール#systemd|ブート時にロード]]されるようにしてください:

{{hc|/etc/modules-load.d/watchdog.conf|
''module_name''
}}

# modprobe ''module_name''

{{ic|''module_name''}} の部分は、あなたのハードウェアにおける実際のモジュール名に置き換えてください。

=== リファレンス ===

* {{man|5|systemd-system.conf}}
* [https://docs.kernel.org/watchdog/index.html Linux カーネルウォッチドッグのドキュメント]
* [[Systemd-boot|Arch Wiki – Systemd Boot]]
* [https://0pointer.de/blog/projects/watchdog.html Lennart Poettering による systemd ウォッチドッグに関するブログ記事]

== 参照 ==

* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Performance_Tuning_Guide/index.html Red Hat Performance Tuning Guide]
* [https://www.thomas-krenn.com/en/wiki/Linux_Performance_Measurements_using_vmstat Linux Performance Measurements using vmstat]

{{TranslationStatus|Improving performance|2025-06-28|837833}}