udev
関連記事
- "udev とは、Linuxカーネル 用のデバイス管理ツールである。主に
/devディレクトリ以下のデバイスノードを管理するために利用する。以前/devディレクトリの管理を担っていた devfs と、ホットスワップやファームウェアのロードなどユーザー空間におけるデバイスのアクション全てを担っていた hotplug の後継ツールである。"
udev は hotplug と hwdetect 両方の機能を置き換えます。
Udev は並列処理を利用してカーネルモジュールをロードするため順番にモジュールをロードするのと比べ良いパフォーマンスが得られます。従ってモジュールは非同期に読み込まれます。この方法の欠点として、起動した時 udev はいつも同じ順番ではモジュールをロードしません。マシンに複数のブロックデバイスがある場合、デバイスノードの名称がランダムに変化する可能性があります。例えば、マシンに2つハードドライブが接続されている場合、ランダムで /dev/sda が /dev/sdb になるかもしれません。これについては下で詳しく説明しています。
目次
- 1 インストール
- 2 udev ルールについて
- 3 Udisks
- 4 ヒントとテクニック
- 5 トラブルシューティング
- 6 参照
インストール
現在 Udev は systemd に含まれているため Arch Linux ではデフォルトでインストールされています。詳しくは systemd-udevd.service(8) の man ページを見て下さい。
AUR には独立したフォークが存在します: eudev。
udev ルールについて
管理者が書いた udev ルールは /etc/udev/rules.d/ にあり、そのファイル名は .rules で終わらなければなりません。様々なパッケージに同梱されている udev ルールは /usr/lib/udev/rules.d/ に格納されています。もし /usr/lib と /etc に同じ名前のファイルがあった場合、 /etc にあるファイルが優先されます。
udev のルールについて学ぶには、udev(7) マニュアルを参照してください。また、Writing udev rules も参照してください。また、いくつかの実用的な例がガイドの中で提供されています。udev ルールの書き方 - 例 も見てください。
udev ルールの例
- udev ルールの書き方を学ぶには udev ルールの書き方 (日本語訳) を見て下さい。
- udev ルールのサンプルを見るには Improved Udev Rule For Arch Linux を見て下さい。
以下はウェブカメラが接続されたときにシンボリックリンク /dev/video-cam1 を作るルールの例です。まず、カメラが接続されたときデバイス /dev/video2 にロードされていることを見つけたとします。このルールを書く理由は次のブート時にデバイスが /dev/video0 など他の名前で表示される可能性があるからです。
# udevadm info -a -p $(udevadm info -q path -n /dev/video2)
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0/video4linux/video2':
KERNEL=="video2"
SUBSYSTEM=="video4linux"
...
looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2/3-2:1.0':
KERNELS=="3-2:1.0"
SUBSYSTEMS=="usb"
...
looking at parent device '/devices/pci0000:00/0000:00:04.1/usb3/3-2':
KERNELS=="3-2"
SUBSYSTEMS=="usb"
...
ATTRS{idVendor}=="05a9"
...
ATTRS{manufacturer}=="OmniVision Technologies, Inc."
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="4519"
ATTRS{bDeviceClass}=="00"
ATTRS{product}=="USB Camera"
...
video4linux デバイスから KERNEL=="video2" と SUBSYSTEM=="video4linux" を使います、そして usb parent SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519" から製造者・製品 ID を使ってウェブカメラをマッチさせます。
/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", \
ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"
上の例では SYMLINK+="video-cam1" を使ってシンボリックリンクを作成していますが OWNER="john" や GROUP="video" を使ってユーザーやグループを設定したり MODE="0660" を使ってパーミッションを設定することも簡単にできます。
ただし、デバイスが取り除かれた時に何かを実行するルールを書く時は、デバイスの属性にアクセス出来ないことに注意してください。この場合、プリセットのデバイス環境変数を使う必要があります。これらの環境変数を監視するには、デバイスを抜いた時に次のコマンドを実行してください:
# udevadm monitor --environment --udev
このコマンドの出力の中に、ID_VENDOR_ID や ID_MODEL_ID などの、前に使っていた属性 "idVendor" と "idProduct" に一致する値があるはずです。デバイスの環境変数を使うルールは以下のようになります:
/etc/udev/rules.d/83-webcam-removed.rules
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="05a9", ENV{ID_MODEL_ID}=="4519", RUN+="/path/to/your/script"
デバイスの属性を一覧する
ルールを書くために使用できるデバイスのすべての属性のリストを取得するには、次のコマンドを実行します。
$ udevadm info --attribute-walk --name=device_name
device_name を /dev/sda や /dev/ttyUSB0 など、システムに存在するデバイスに置き換えてください。
デバイス名が分からない場合は、特定のシステムパスの全属性をリストアップすることもできます。
$ udevadm info --attribute-walk --path=/sys/class/backlight/acpi_video0
デバイスを絞り込むには、クラスを把握し、実行する。
$ ls /dev/class/by-id
シンボリックリンクをそのまま、あるいはそれが指し示すものを --name の入力として使用することができます。例えば
$ udevadm info --attribute-walk --name=/dev/input/by-id/usb-foostan_Corne-event-kbd
下位デバイスを持たない裸のUSBデバイスのパスを取得するには、 USB デバイスのフルパスを使用する必要があります。モニターモードを起動し、 USB デバイスを接続することで取得できます。
$ udevadm monitor
... KERNEL[26652.638931] add /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3 (usb) KERNEL[26652.639153] add /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:05.0/0000:05:00.0/usb1/1-3/1-3:1.0 (usb) ...
一番深いパスを選択すれば、 --attribute-walk はとにかく親の属性を全て表示します。
ロードする前にルールをテストする
# udevadm test $(udevadm info -q path -n [device name]) 2>&1
このコマンドは新しいルールの全てのアクションを実行はしませんが、既存のデバイスのシンボリックリンクのルールは処理します。ロードできないときに役に立つかもしれません。また、テストしたい udev ルールのデバイスのパスを直接指定することも可能です:
# udevadm test /sys/class/backlight/acpi_video0/
新しいルールをロードする
udev はルールファイルの変更を自動的に検出するので、udev を再起動することなく、変更は直ちに有効になります。しかし、既に存在するデバイスに対しては、ルールは自動的に再トリガされません。USB デバイスのようなホットプラグ可能なデバイスは、おそらく新しい規則を有効にするために再接続するか、少なくとも ohci-hcd と ehci-hcd カーネルモジュールをアンロードして再ロードし、それによってすべての USB ドライバを再ロードしなければならないでしょう。
ルールが自動的にリロードされない場合。
# udevadm control --reload
手動で udev にルールを強制的に起動させるには。
# udevadm trigger
Udisks
Udisks を見て下さい。
ヒントとテクニック
ルールの中でのドライブのマウント
リムーバブルドライブをマウントするには、udev ルールから mount を呼び出さないようにしてください。これは2つの理由でお勧めできません。(1) systemd はデフォルトで systemd-udevd.service を個別の マウント名前空間 (namespaces(7) を参照) で実行します、これはマウントがシステムの残りの部分から見えないことを意味します。(2) これを解決するためにサービスパラメータを変更しても (PrivateMounts と MountFlags 行をコメントアウトする)、Udev から起動したプロセスが数秒後に終了してしまうという別の問題があります。NTFS-3G のような FUSE ファイルシステムの場合、mount はファイルシステム内部を処理するためにユーザースペースプロセスを起動します。これが殺されると、ファイルシステムにアクセスしようとすると Transport endpoint not connected エラーが発生することになります。
機能するオプションもあります。
- systemd サービスは、(FUSE のような) 長時間実行するプロセスをいくつでも開始できるスクリプトを呼び出すことができます。systemd サービスは、(FUSE のような) 長時間稼働するプロセスをいくつでも起動できるスクリプトを起動できます。
/mediaの下で USB ディスクを自動的にマウントする簡潔な例は udev-media-automount です。これは高速で信頼できることが確認されています。同じアイデアのバリエーションが このブログの記事 で説明されています。 - Udev のルールで
mountの代わりにsystemd-mountを使ってください。これは systemd の開発者が推奨しています。 例えば、この Udev ルールは USB ディスクを "/media" 以下にマウントするものです。
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --collect $devnode /media"- ただし、この記事を書いている時点では、信頼性が低いことが判明しています。
- udisks や udiskie のようなパッケージを使用してください。これらは非常に強力ですが、セットアップが困難です。また、これらは単一ユーザセッションでの使用を意図しており、現在セッションがアクティブな非特権ユーザの所有下でいくつかのファイルシステムを利用できるようにするからです。
通常ユーザーにデバイスの使用を許可する
カーネルドライバがデバイスを初期化する際に、デフォルト状態ではデバイスノードは root:root によって所有され、パーミッションは 600 に設定されます。[1] よって、ドライバがこのデフォルトを変更するか、ユーザー空間の udev ルールがパーミッションを変更しない限り、通常ユーザーはデバイスにアクセスできません。
Udev 値 OWNER、GROUP、MODE を使って、アクセス権を付与することができます。しかし、全てのユーザーがデバイスを利用できるようにし、なおかつデバイスファイルのモードを過度に寛容にしないようにするのは困難です。Ubuntu では、plugdev というグループを作成して、このグループにデバイスが追加されます。しかし、このアプローチは systemd の開発者達によって推奨されていない [2] だけでなく、Arch の udev ルールに追加されたときにはバグとみなされました (FS#35602)。歴史的に採用されていたもう一つのアプローチは、デバイスのカテゴリ毎に対応する別々のグループを使用するというものです (ユーザーとグループ#systemd 以前のグループ で説明されています)。
Systemd システムにおける最近の推奨されるアプローチは、MODE を 660 に設定してグループがデバイスを使用できるようにし、uaccess という TAG を付けることです [3]。この特殊なタグにより、udev は動的なユーザー ACL をデバイスノードに適用するようになり、systemd-logind(8) と連携してログイン中のユーザーがデバイスにアクセスできるようにします。以下は、このアプローチを実装する udev ルールの例です:
/etc/udev/rules.d/71-device-name.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="vendor_id", ATTRS{idProduct}=="product_id", MODE="0660", TAG+="uaccess"
ファームウェアプログラマや USB 仮想 comm デバイスにアクセス
以下のルールは users グループのユーザーが AVR マイクロコントローラの USBtinyISP USB プログラマにアクセスできるように設定します:
/etc/udev/rules.d/50-usbtinyisp.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0660"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0660"
他のデバイスを使う場合は lsusb を使ってベンダー・プロダクト ID を確認してください。
HDMI ケーブルの抜き差し時に実行
以下の内容でルール /etc/udev/rules.d/95-hdmi-plug.rules を作成します。
ACTION=="change", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/path/to/script.sh"
VGA ケーブル接続時に実行
VGA モニターケーブルが接続されたときに arandr を起動するには以下の内容の /etc/udev/rules.d/95-monitor-hotplug.rules ルールを作成します:
KERNEL=="card0", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/arandr"
ディスプレイマネージャによっては .Xauthority がユーザーのホームディレクトリに保存されないことがあります。その場合 ENV{XAUTHORITY} を修正する必要があります。例えば GDM なら以下のようになります:
$ printenv XAUTHORITY
/run/user/1000/gdm/Xauthority
新しい eSATA ドライブの検知
eSATA ドライブを挿入しても検知されない場合、いくつか試せることがあります。eSATA を挿入したまま再起動してください。もしくは次を実行してください:
# echo 0 0 0 | tee /sys/class/scsi_host/host*/scan
または (AUR から) scsiaddAUR をインストールして次を実行してください:
# scsiadd -s
うまくいけば、あなたのドライブが /dev にあります。ドライブがない場合、次を実行しながら上のコマンドを試して何が起こっているのか確認してください:
# udevadm monitor
内部 SATA ポートを eSATA とする
eSATA ベイや他の eSATA アダブタを接続するとシステムはディスクを内部 SATA ドライブとして認識します。GNOME や KDE はその度に root パスワードを尋ねることになります。以下の udev ルールは指定した SATA ポートを外部 eSATA ポートとして表示させます。これで、USB ドライブと同じように通常の GNOME ユーザーで eSATA ドライブを root パスワードなしでポートに接続することができるようになります。
/etc/udev/rules.d/10-esata.rules
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM}="0"
固定デバイス名の設定
udev は全てのモジュールを非同期にロードするので、初期化される順番は異なってしまいます。この結果デバイスの名前がランダムで変わる可能性があります。udev ルールを追加すれば固定デバイス名を使えます:
- ブロックデバイスは永続的なブロックデバイスの命名を見て下さい。
- ネットワークデバイスはネットワーク設定#デバイス名を見て下さい。
ビデオドライバー
ウェブカメラをセットアップするなら、まずウェブカメラ設定を参照してください。
複数のウェブカメラを使うと、例えば motion (video4linux デバイスやウェブカメラから画像を取得するソフトウェアモーション検知プログラム) を使う場合、起動時にビデオデバイスはランダムで /dev/video0..n と割り当てられます。推奨される方法は udev ルールを使って (udev ルールの記述にある例のようにして) シンボリックリンクを作成する方法です。
/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam1"
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="08f6", SYMLINK+="video-cam2"
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0840", SYMLINK+="video-cam3"
プリンター
複数のプリンターを使っている場合、起動時にランダムで /dev/lp[0-9] のデバイスが割り当てられ、CUPS の設定などを破壊してしまいます。
永続的なブロックデバイスの命名と同じように /dev/lp/by-id と /dev/lp/by-path の下にシンボリックリンクを作成する、以下のルールを作成することが可能です:
/etc/udev/rules.d/60-persistent-printer.rules
ACTION=="remove", GOTO="persistent_printer_end"
# This should not be necessary
#KERNEL!="lp*", GOTO="persistent_printer_end"
SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
ENV{ID_TYPE}!="printer", GOTO="persistent_printer_end"
ENV{ID_SERIAL}=="?*", SYMLINK+="lp/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
IMPORT{builtin}="path_id"
ENV{ID_PATH}=="?*", SYMLINK+="lp/by-path/$env{ID_PATH}"
LABEL="persistent_printer_end"
ディスクをシリアルで識別する
特定のディスクデバイス /dev/sdX に対して何らかのアクションを実行するには、 udevadm info /dev/sdX で表示される固有のシリアル ID_SERIAL_SHORT で永久に特定されます。これは、もし見つかったデバイス名があれば、それをパラメータとして渡して説明します。
/etc/udev/rules.d/69-disk.rules
ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_SERIAL_SHORT}=="X5ER1ALX", RUN+="/path/to/script /dev/%k"
USB デバイスでサスペンドから復帰
udev ルールは、マウスやキーボードなどの USB デバイスのウェイクアップ機能を有効にし、マシンをスリープから復帰させるために使用するのに便利です。
まず、USB デバイスのベンダー識別子と製品識別子を特定します。これらは、udev ルールでそれを認識するために使用されます。例えば
$ lsusb | grep Logitech
Bus 007 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
デバイスが接続されている USB コントローラを検索するには:
# grep c52b /sys/bus/usb/devices/*/idProduct
/sys/bus/usb/devices/1-1.1.1.4/idProduct:c52b
デバイスと接続している USB コントローラの power/wakeup 属性を変更してください:
/etc/udev/rules.d/50-wake-on-device.rules
ACTION=="add", SUBSYSTEM=="usb", DRIVER=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="enabled", ATTR{driver/1-1.1.1.4/power/wakeup}="enabled"
イベントでトリガー実行
様々な udev イベントをトリガーすると便利なことがあります。例えば、リモートマシンで USB デバイスの切断をシミュレートしたいかもしれません。そのような場合は udevadm trigger を使ってください。
# udevadm trigger --verbose --type=subsystems --action=remove --subsystem-match=usb --attr-match="idVendor=abcd"
このコマンドは、ベンダー ID abcd を持つすべての USB デバイスに対して USB remove イベントを発生させます。
udev ルールからデスクトップ通知を行う
udev を介して notify-send の呼び出しを含む外部スクリプトを呼び出します。デスクトップに通知が表示されない時があります 以下は、udev ルールから notify-send が正常に実行されるために、どのファイルにどんなコマンドと環境変数が含まれている必要があるかの例です。
1) 以下の udev ルールは、ノートパソコンの電源状態に応じて画面の明るさを変更した際に、通知音を鳴らし、デスクトップ通知を送信するスクリプトを実行するものです。ファイルを作成します。
/etc/udev/rules.d/99-backlight_notification.rules
# Rule for when switching to battery
ACTION=="change", SUBSYSTEM=="power_supply", ATTR{type}=="Mains", ATTR{online}=="0", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/USERNAME/.Xauthority" RUN+="/usr/bin/su USERNAME_TO_RUN_SCRIPT_AS -c /usr/local/bin/brightness_notification.sh"
# Rule for when switching to AC
ACTION=="change", SUBSYSTEM=="power_supply", ATTR{type}=="Mains", ATTR{online}=="1", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/USERNAME/.Xauthority" RUN+="/usr/bin/su USERNAME_TO_RUN_SCRIPT_AS -c /usr/local/bin/brightness_notification.sh"
USERNAME_TO_RUN_SCRIPT_ASとUSERNAMEは、通知が表示されるグラフィックセッションのユーザーのショートネームに変更する必要があります。- スクリプトは
/usr/bin/suで実行する必要があり、これは通知が表示されるグラフィカルセッションのユーザー（root/system ではなく）の下にその所有権を配置します。
2) udev ルールの発動時に実行される実行スクリプトの内容。
/usr/local/bin/brightness_notification.sh
#!/usr/bin/env bash export XAUTHORITY=/home/USERNAME_TO_RUN_SCRIPT_AS/.Xauthority export DISPLAY=:0 export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/UID_OF_USER_TO_RUN_SCRIPT_AS/bus" /usr/bin/sudo -u USERNAME_TO_RUN_SCRIPT_AS /usr/bin/paplay --server=/run/user/UID_OF_USER_TO_RUN_SCRIPT_AS/pulse/native /home/USERNAME/.i3/sounds/Click1.wav > /dev/null 2>&1 /usr/bin/notify-send --icon=/usr/share/icons/gnome/256x256/status/battery-full-charging.png 'Changing Power States' --expire-time=4000
USERNAME_TO_RUN_SCRIPT_AS,UID_OF_USER_TO_RUN_SCRIPT_AS,USERNAMEはユーザーのショートネームと通知を表示するグラフィックセッションのユーザーのUIDに変更する必要があります。- pulseaudio 経由でオーディオを再生する場合、
/usr/bin/sudoが必要です。 - 通知が表示されるグラフィカルセッションのユーザーのための3つの環境変数 (すなわち、
XAUTHORITY,DISPLAYandDBUS_SESSION_BUS_ADDRESS) を定義してエクスポートすることが必要です。
3) 新しい udev ルール (上記参照) をロード/リロードして、ノートパソコンの電源を抜いてテストします。
長時間稼働するプロセスの生成
udev によって起動されたプログラムは、そのデバイスからのさらなるイベントをブロックし、udev のルールから生成されたタスクは、イベント処理が完了した後に強制終了されます。udev で長時間稼働するプロセスを起動する必要がある場合、at を使うことができます。(例: your_command | at now, batch) もしくは systemd ユニット から直接 udev ルールからトリガー を作成することも可能です。
トラブルシューティング
モジュールのブラックリスト
稀に、udev が間違って誤ったモジュールをロードすることがあります。これを止めさせるために、モジュールをブラックリストに入れることができます。ブラックリスト化すれば、udev は二度とそのモジュールをロードしません。カーネルモジュール#ブラックリストを見て下さい。起動時と hotplug のイベント時 (例: USB フラッシュドライブを入れた時) 両方です。
デバッグ出力
ハードウェアのデバッグ情報を取得したいときは、udev.log-priority=debug カーネルパラメータを使ってください。もしくは、以下を設定:
/etc/udev/udev.conf
udev_log="debug"
上記の設定ファイルを FILES 行に追加することで initramfs に組み込むこともできます:
/etc/mkinitcpio.conf
FILES="... /etc/udev/udev.conf"
設定後は initramfs を再生成してください:
# mkinitcpio -p linux
起動時に udevd が止まる
LDAP に移行したり LDAP を使っているシステムを更新した後 udevd が起動時 "Starting UDev Daemon" というメッセージを出したときに止まることがあります。これは通常 udevd が LDAP にある名前を検索しようとして、ネットワークがまだ立ち上がっておらず、失敗していることが原因です。解決方法は全てのシステムグループの名前をローカルで存在させることです。
udev ルールで記述されているグループ名とシステム上にあるグループ名を抽出してください:
# fgrep -r GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups # cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups
違いを確認するために、side-by-side の diff を実行してください:
# diff -y present_groups udev_groups ... network < nobody < ntp < optical optical power | pcscd rfkill < root root scanner scanner smmsp < storage storage ...
この場合、何らかの理由で pcscd グループがシステム上に存在しません。欠けているグループを追加してください:
# groupadd pcscd
また、LDAP に頼る前にローカルリソースが検索されるようにしてください。/etc/nsswitch.conf に次の行を含める必要があります:
group: files ldap
リムーバブルデバイスとして扱われなくてはならないデバイスがそう扱われない
問題のデバイスのカスタム udev ルールを作成する必要があります。デバイスの定義情報を取得するために ID_SERIAL または ID_SERIAL_SHORT を使います (/dev/sdb は必要に応じて変更してください):
$ udevadm info /dev/sdb | grep ID_SERIAL
それから /etc/udev/rules.d/ にルールを作成して udisks または udisks2 の変数を設定します。
udisks の場合、UDISKS_SYSTEM_INTERNAL="0" を設定することでデバイスがリムーバブルとして扱われるようになり、自動マウントできるようになります (詳しくは udisks(7) を参照):
/etc/udev/rules.d/50-external-myhomedisk.rules
ENV{ID_SERIAL_SHORT}=="serial_number", ENV{UDISKS_SYSTEM_INTERNAL}="0"
udisks2 の場合、UDISKS_AUTO="1" を設定することでデバイスが自動マウントされ、UDISKS_SYSTEM="0" を設定することでデバイスがリムーバブルとして認識されます。詳しくは udisks(8) を参照。
/etc/udev/rules.d/99-removable.rules
ENV{ID_SERIAL_SHORT}=="serial_number", ENV{UDISKS_AUTO}="1", ENV{UDISKS_SYSTEM}="0"
udevadm control --reload で udev ルールをリロードしてください。デバイスを接続すると外付けドライブとして認識されるはずです。
モジュールが自動でロードされないサウンドの問題
/etc/modprobe.d/sound.conf 内の古いエントリによって問題が起こる場合があります。このファイルを手入れして、それから再度試して下さい。
IDE CD/DVD ドライブサポート
バージョン 170 から、udev は CD-ROM/DVD-ROM ドライブをサポートしておらず、伝統的な IDE ドライブとして ide_cd_mod モジュールを使ってロードされ /dev/hd* として表示します。cdparanoia など、ハードウェアに直接アクセスするツールでは問題なくドライブを使えますが、KDE などのより高い次元のユーザースペースのプログラムにはドライブが見えなくなります。
sr_mod など他のモジュールよりも先に ide_cd_mod モジュールがロードされる理由は、何らかの理由で initramfs で piix モジュールをロードしているなどが考えられます。その場合、/etc/mkinitcpio.conf で piix を ata_piix に置き換えることができます。
オプティカルドライブのグループ ID が "disk" に設定される
オプティカルドライブのグループ ID が disk に設定されていて、それを optical に設定したい場合、カスタム udev ルールを作成する必要があります:
/etc/udev/rules.d
# permissions for IDE CD devices
SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", ATTRS{media}=="cdrom*", GROUP="optical"
# permissions for SCSI CD devices
SUBSYSTEMS=="scsi", KERNEL=="s[rg][0-9]*", ATTRS{type}=="5", GROUP="optical"
X サーバーが存在しない場合、RUN ルールの X プログラムがハングする
xrandr または別の X ベースのプログラムが X サーバーに接続しようとすると TCP 接続にフォールバックします。これは、systemd-udev サービス設定 の IPAddressDeny が原因でハングします。最終的にプログラムは強制終了され、イベント処理が再開されます。
ルールが DRM デバイス用であり、ハングによって X サーバーの起動後にイベント処理が完了する場合、これにより 3D アクセラレーションが failed toauthenticate magic エラーで動作しなくなる可能性があります。