udev
関連記事
udev は、オペレーティングシステムの管理者がユーザー空間のイベントハンドラを登録できるようにする、ユーザー空間のシステムです。udev のデーモンによって捕捉されたイベントは主に、周辺機器関連の物理イベントに応答して (Linux) カーネルによって生成されたものです。そのため、udev の主な使用目的は、(カーネルモジュールやデバイスファームウェアのロードなど) カーネルに制御が戻るようなアクションを含む、周辺機器の検出やホットプラグです。また、周辺機器の検出においては、デバイス (ファイル) のパーミッションを調整して非 root ユーザーや非 root グループからアクセス可能にするなども行われます。
udev は、devfsd と hotplug の後継として、/dev ディレクトリ内のデバイスノードの追加、シンボリックリンクの作成、名称変更などの管理も行います。udev は hotplug と hwdetect の両方の機能を置き換えます。
udev は、別々のイベントを同時に (並列に) 処理します。それにより、古いシステムよりも高いパフォーマンスが得られる可能性があります。しかし、カーネルモジュールのロード順がブート毎に同じであることが保証されないなどの理由により、この機構はシステムの管理を複雑化させてしまう可能性もはらんでいます。マシンに複数のブロックデバイスが搭載されている場合、再起動するとデバイスノードの名称が変化してしまう場合があります。例えば、マシンに 2 つのハードドライブが存在する場合、/dev/sda は次回の起動時に /dev/sdb となってしまうかもしれません。これに関する詳細は、下記を見てください。
目次
- 1 インストール
- 2 udev ルールについて
- 3 Udisks
- 4 ヒントとテクニック
- 5 トラブルシューティング
- 6 参照
インストール
udev は systemd の一部なので、デフォルトでインストールされます。詳細は systemd-udevd.service(8) を見てください。
udev ルールについて
管理者が書いた udev ルールは /etc/udev/rules.d/ 内に配置することになっており、そのファイル名は .rules で終わらなければなりません。様々なパッケージに同梱されている udev ルールは /usr/lib/udev/rules.d/ に格納されています。もし /usr/lib と /etc に同じ名前のファイルがあった場合、/etc にあるファイルが優先されます。
udev ルールについて学ぶには、udev(7) マニュアルを参照してください。また、Writing udev rules も参照してください。このガイドには、実践的な例 (Writing udev rules - Examples) がいくつか挙げられています。
udev ルールの例
以下は、ウェブカメラが接続された時に /dev/video-cam シンボリックリンクを作成するルールの例です。
ここで、カメラは既に接続されていて、/dev/video2 というデバイス名でロードされているとします。そして、以下の udev ルールを書く理由は、次回のブート時にデバイスファイルが別の名前 (例えば /dev/video0 など) になってしまうかもしれないからです (なので、/dev/video-cam という固定のファイル名で参照できるようにしようというのが目的です)。
$ udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/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" という条件式が使用されています。それより 2 階層上を見ると、USB 親デバイス SUBSYSTEMS=="usb" からはベンダー ID ATTRS{idVendor}=="05a9" とプロダクト ID ATTRS{idProduct}=="4519" を使ってウェブカメラをマッチさせています。
以上から、以下のようにこのデバイスにマッチするルールを作成することができます:
/etc/udev/rules.d/83-webcam.rules
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", SYMLINK+="video-cam"
ここで、SYMLINK+="video-cam" を使ってシンボリックリンクを作成していますが、OWNER="john" でデバイスの所有者を、GROUP="video" でデバイスの所有グループを設定することもできますし、MODE="0660" でパーミッションも設定できます。
デバイスが取り除かれた時に何かを行うルールを記述したい場合は、デバイスの属性にはアクセスできないことに注意してください (とっくにデバイスは取り除かれているからです)。この場合、事前に定義されたデバイスの環境変数を使う必要があります。そのような環境変数を監視するには、デバイスが取り除かれた状態で以下のコマンドを実行してください:
$ udevadm monitor --property --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 デバイスのフルパスを使用する必要があります。udevadm のモニターモードを開始し、対象の 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 info --attribute-walk --path=/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
ロードする前にルールをテストする
# udevadm test $(udevadm info --query=path --name=device_name) 2>&1
このコマンドは、ルールの全てのアクションを実行しませんが、既存のデバイスに対するシンボリックリンクのルールは処理します。ルールをロードできない場合に役立つかもしれません。また、テストしたい udev ルールのデバイスへのパスを直接指定することも可能です:
# udevadm test /sys/class/backlight/acpi_video0/
新しいルールをロードする
udev はルールファイルの変更を自動的に検出するので、udev を再起動せずとも変更は即座に有効になります。しかし、既に存在するデバイスに対しては、ルールが自動的に再トリガーされません。USB デバイスなどのホットプラグ可能なデバイスは、新しいルールを有効にするために再接続するか、少なくともカーネルモジュール ohci-hcd と ehci-hcd を再ロードして全ての USB ドライバを再読み込みする必要があります。
ルールが自動的に再読み込みされない場合は、以下を実行してください:
# udevadm control --reload
手動でルールを強制的にトリガーするには:
# udevadm trigger
Udisks
Udisks を見て下さい。
ヒントとテクニック
ルールの中でドライブをマウントする
リムーバブルディスクをマウントする際に udev ルールから mount コマンドを実行しないでください。これは以下の 2 つの理由により賢明ではありません:
- デフォルトで systemd は、分離された "mount 名前空間" 内で
systemd-udevd.serviceを実行します (namespaces(7) を参照)。つまり、この名前空間外からはデバイスが不可視になります。 - この問題を解決するために (
PrivateMountsとMountFlagsの行をコメントアウトして) サービスのパラメータを変更したとしても、udev から起動されたプロセスは数秒後に終了させられてしまうという問題があります。NTFS-3G などの FUSE ファイルシステムにおいては、mount はファイルシステムを管理するためにユーザー空間のプロセスを起動します。このプロセスが終了されると、そのファイルシステムにアクセスしようとした時にTransport endpoint not connected(通信端点が接続されていません) というエラーが発生します。
うまく行く方法もいくつかあります:
- Udev ルールからカスタムの systemd サービスを起動する。カスタムの systemd サービスでは、長時間動作させるプロセス (FUSE など) を開始するスクリプトを開始するなどができます。USB ディスクを自動的に
/media内にマウントする簡単な例は 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"
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} の値は適宜変更する必要があります。例として、GNOME Display Manager の場合は以下のようになります:
$ printenv XAUTHORITY
/run/user/1000/gdm/Xauthority
新しい eSATA を検知する
eSATA ドライブが挿入された時に検出されない場合、問題を解決できるかもしれない方法がいくつかあります。1つ目は、eSATA が挿入されている状態で再起動することです。あるいは、以下のコマンドを試してみることもできます:
# echo 0 0 0 > /sys/class/scsi_host/host*/scan
あるいは、scsiaddAUR をインストールし、以下を実行してみることもできます:
# scsiadd -s
うまく行けば、ドライブが /dev 内に出現します。出現しない場合は、以下のコマンドを実行し、出力されるログを見ながら上記のコマンドをもう一度試してください:
# udevadm monitor
内部 SATA ポートを eSATA として認識させる
eSATA ベイや他の eSATA アダプタを接続すると、システムはこのディスクを内部 SATA ドライブとして認識します。GNOME や KDE では毎回 root のパスワードが要求されます。以下のルールは、指定した SATA ポートを外部 eSATA ポートとしてマークします。これにより、GNOME の通常ユーザーでも root のパスワード無しで eSATA ドライブを USB ドライブのようにポートに接続できるようになります。
/etc/udev/rules.d/10-esata.rules
DEVPATH=="/devices/pci0000:00/0000:00:1f.2/host4/*", ENV{UDISKS_SYSTEM}="0"
固定デバイス名を設定する
udev は全てのモジュールを非同期でロードするので、モジュールは毎回異なる順番で初期化される可能性があります。これにより、デバイス名がランダムに変わってしまいます。udev ルールを用いることで、固定デバイス名を使用することができます。 ブロックデバイスに関しては 永続的なブロックデバイスの命名 も、ネットワークデバイスに関しては ネットワーク設定#インターフェイス名の変更 も参照してください。
ビデオデバイス
ウェブカメラのセットアップに関しては ウェブカメラ設定 を参照してください。
複数のウェブカメラを使用すると、それぞれのビデオデバイスはブート時に /dev/video* としてランダムに割り当てられます。推奨される解決策は、#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"
プリンタ
複数のプリンタを使用すると、それぞれのプリンタはブート時に /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"
# これは必須では無いはずです
#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}=="serial_number", RUN+="/path/to/script /dev/%k"
USB デバイスでサスペンドから復帰させる
udev ルールを用いることで、マウスやキーボードといった USB デバイスの復帰トリガーを有効化して、そのデバイスを使ってシステムをスリープから復帰させることができます。
まず、対象の USB デバイスのベンダー ID とプロダクト ID を調べてください。これらの ID は udev ルール内でデバイスを識別するために使用します。例えば:
$ lsusb | grep Logitech
Bus 007 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
次に、以下のコマンドを使ってデバイスの接続先を調べてください:
$ grep c52b /sys/bus/usb/devices/*/idProduct
/sys/bus/usb/devices/1-1.1.1.4/idProduct:c52b
最後に、USB デバイス自体と、USB デバイスの接続先である USB コントローラの power/wakeup 属性をデバイスの接続時に変更するルールを作成してください:
/etc/udev/rules.d/50-wake-on-device.rules
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="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 リモートイベントをトリガーします。
Udev ルールからデスクトップ通知をトリガーする
notify-send を呼び出す外部スクリプトを udev から実行してデスクトップに通知を表示させるのは、場合によっては困難です。以下の例では、notify-send を udev ルールから正しく実行するために、どのファイルにどのコマンドや環境変数を記述すべきかを説明しています。
1) 以下の udev は、ノート PC の電源状態によって画面の輝度が変更された際に通知音を再生しデスクトップ通知を送信するスクリプトを実行します。以下のファイルを作成してください:
/etc/udev/rules.d/99-backlight_notification.rules
# バッテリー駆動に切り替わったときのルール
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"
# 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 としてではなく) 通知が表示されるグラフィカルセッションのユーザーとしてプロセスを実行します。
2) udev のトリガー時に実行する実行可能スクリプトの内容:
/usr/local/bin/brightness_notification.sh
#!/bin/sh 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 に置き換える必要があります。/usr/bin/sudoは、pulseaudio で音声を再生するために必要です。- 通知が表示されるグラフィカルセッションのユーザーに対して、3つの環境変数 (
XAUTHORITY、DISPLAY、DBUS_SESSION_BUS_ADDRESS) を定義し export する必要があります。
3) 作成した udev ルールを (再) ロードし、ノート PC から電源アダプタを抜いてテストしてください。
長時間稼働するプロセスを生成する
udev からプログラムを開始するとそのデバイス以降のイベントがブロックされ、また、udev ルール内で生成されたタスクはイベント処理の完了後に終了されます。長時間稼働するプロセスを udev から生成する必要がある場合は、at を使うか (使用例: your_command | at now または batch)、udev ルールから直接トリガーできる systemd ユニットを作成してください。
トラブルシューティング
モジュールをブラックリストに追加する
稀なケースですが、udev が間違って、誤ったモジュールをロードしてしまうことがあります。間違ったモジュールをロードしないようにするには、モジュールをブラックリストに追加することができます。ブラックリストに追加すると、起動時にも、ホットプラグイベントが発生したとき (USB フラッシュドライブを挿入したときなど) にも、udev はそのモジュールをロードしなくなります。
デバッグ出力
ハードウェアのデバッグ情報を表示するには、udev.log-priority=debug カーネルパラメータを使ってください。あるいは、以下の設定を行うこともできます:
/etc/udev/udev.conf
udev_log="debug"
このオプションは、mkinitcpio の FILES 配列にこの設定ファイルを追加することで、initramfs 内に組み込むことも可能です:
/etc/mkinitcpio.conf
FILES="... /etc/udev/udev.conf"
mkinitcpio.conf を変更した後は、initramfs を再生成してください。
起動時に udevd が止まる
LDAP に移行したり LDAP を使っているシステムを更新した後 udevd が起動時 "Starting UDev Daemon" というメッセージを出したときに止まることがあります。これは通常 udevd が LDAP にある名前を検索しようとして、ネットワークがまだ立ち上がっておらず、失敗していることが原因です。解決方法は全てのシステムグループの名前をローカルで存在させることです。
udev ルールで参照されているグループ名とシステム上に実際に存在しているグループ名を抽出してください:
# grep -Fr GROUP /etc/udev/rules.d/ /usr/lib/udev/rules.d/ | sed 's:.*GROUP="\([-a-z_]\{1,\}\)".*:\1:' | sort -u >udev_groups
# cut -d: -f1 /etc/gshadow /etc/group | sort -u >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 グループがシステム上に存在していないことがわかります。欠けているグループを追加してください。また、LDAP よりも前にローカルのリソースを参照するように設定してください。/etc/nsswitch.conf には以下の行が含まれている必要があります:
group: files ldap
リムーバブルデバイスとして扱われなくてはならないデバイスがそう扱われない
問題のリムーバブルデバイスに対してカスタムの udev ルールを作成する必要があります。デバイスの不変な情報 (そのデバイスを識別するために利用できる情報) としては、ID_SERIAL や ID_SERIAL_SHORT が使えます (以下の /dev/sdb の部分は必要に応じて変更してください):
$ udevadm info /dev/sdb | grep ID_SERIAL
次に、デバイスが自動マウントされるようにするために 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 ドライブのサポート
udev はバージョン 170 から、ide_cd_mod モジュールによって従来の IDE ドライブとしてロードされデバイスファイルが /dev/hd* となる CD-ROM/DVD-ROM をサポートしなくなりました。このようなドライブはハードウェアに直接アクセスするツール (cdparanoia など) によって依然として利用可能ですが、より高いレイヤーのユーザー空間のプログラム (KDE など) からは不可視です。
ide_cd_mod モジュールが他のモジュール (sr_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 が設定されているため、ハングしてしまいます。最終的には、プログラムは kill され、イベントの処理が再開されます。
対象のルールが drm デバイスに対するものであり、X サーバが開始されるとハングによってイベントの処理が終わってしまう場合、failed to authenticate magic エラーで 3D アクセラレーションが機能しなくなってしまう可能性があります。