質問: udev:usbスティック挿入時に暗号化されたボリュームをマウントします キーを含むusbスティックを挿入したときに自動的にマウントしたい暗号化されたパーティションがあり、スティックが取り外されたときにそれをアンマウント(およびマッパーを閉じる)したいと思います。 ubuntukarmicを使用しています。truecryptでこれを試みるプロジェクトがいくつかあるようです(たとえば、 http://sourceforge.net/projects/tc-wrapper/ )が、dmcrypt/luksに基づくものはありません。だから私はudevルールを書いて運試しをしようと思いました。多くの苛立たしい時間の後、私はこれを思いついた:action=="add", subsystem=="block", attrs{model}=="flash disk", attrs{vendor}=="usb2.0", run+="/home/michael/trigger-mount.sh encrypted" action=="remove", subsystem=="block", env{id_vendor_id}=="0204", env{id_model_id}=="6025", run+="/home/michael/trigger-mount.sh encrypted" それは機能しますが、いいことではありません。ここでの問題は、最初のルールが削除時に一致せず、2番目のルールが追加時に一致しないことです。udevadm monitor --propertyはこれを示しています(そして「追加」でもほとんど同じです)。udev [1264556064.762870] remove /devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/host47/target47:0:0/47:0:0:0/block/sde (block) udev_log=3 action=remove devpath=/devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/host47/target47:0:0/47:0:0:0/block/sde subsystem=block devname=/dev/sde devtype=disk seqnum=3512 id_vendor=usb2.0 id_vendor_enc=usb2.0\x20\x20 id_vendor_id=0204 id_model=flash_disk id_model_enc=flash\x20disk\x20\x20\x20\x20\x20\x20 id_model_id=6025 id_revision=2.00 id_serial=usb2.0_flash_disk-0:0 id_type=disk id_instance=0:0 id_bus=usb id_usb_interfaces=:080650: id_usb_interface_num=00 id_usb_driver=usb-storage id_path=pci-0000:00:02.0-usb-0:4:1.0-scsi-0:0:0:0 dkd_media_available=1 dkd_presentation_nopolicy=0 major=8 minor=64 devlinks=/dev/block/8:64 /dev/disk/by-id/usb-usb2.0_flash_disk-0:0 /dev/disk/by-path/pci-0000:00:02.0-usb-0:4:1.0-scsi-0:0:0:0 これには、両方の場合(追加、削除)の両方のルールに一致するために必要なすべてのデータが含まれているようです。完全を期すために、ここにudevadm info -a -p /sys/block/sde/の出力があります。 looking at device '/devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/host48/target48:0:0/48:0:0:0/block/sde': kernel=="sde" subsystem=="block" driver=="" attr{range}=="16" attr{ext_range}=="256" attr{removable}=="1" attr{ro}=="0" attr{size}=="512000" attr{alignment_offset}=="0" attr{capability}=="53" attr{stat}==" 16 47 504 510 0 0 0 0 0 380 510" looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2/2-4/2-4:1.0/host48/target48:0:0/48:0:0:0': kernels=="48:0:0:0" subsystems=="scsi" drivers=="sd" attrs{device_blocked}=="0" attrs{type}=="0" attrs{scsi_level}=="3" attrs{vendor}=="usb2.0 " attrs{model}=="flash disk " attrs{rev}=="2.00" attrs{state}=="running" attrs{timeout}=="30" attrs{iocounterbits}=="32" attrs{iorequest_cnt}=="0x41" attrs{iodone_cnt}=="0x41" attrs{ioerr_cnt}=="0x0" attrs{modalias}=="scsi:t-0x00" attrs{evt_media_change}=="0" attrs{queue_depth}=="1" attrs{queue_type}=="none" attrs{max_sectors}=="240" .... 誰かがこれに光を当てることができますか?
回答: 以前の回答 ;でudevをオートマウンターとして使用する方法についていくつかの情報を書きました。それ(またはそれがリンクしているリソース)はあなたにいくらかの光を当てるかもしれません。あなたの質問が正確に何であるかは私にはわかりません 個別の追加と削除のルールについて: [〜#〜] action [〜#〜] 一致を削除すると、それらを統合できる可能性がありますが、これにより、ルールが頻繁に実行される可能性があります。各ルールを明示的に一致させる方が良いと思います。または、さらに良いことに(以下のnmountセクションで説明されている理由により)、"remove"ルールを完全に削除します。 devルールの [〜#〜] run [〜#〜] アクションについて: [〜#〜] run [ 〜#〜] udevルールのアクションを完了する必要がありますすばやく。リンクした例を見てください。 twoスクリプトがあることがわかります--udevは一方を呼び出し、もう一方をスピンオフして実際のマウントを実行し、最初のスクリプトが処理制御をudevにタイムリーに戻すことを可能にします。すでにこれを行っている場合は、すばらしいです。そうでない場合は、同様の方法でスクリプトを微調整することを検討してください。 アンマウントについて:デバイスの取り外し時に自動的にアンマウントするのに多くの問題が発生し、最終的にnot "remove"ルールを使用することにしました。すべて。代わりに、"remove"ルールを置き換える別のアンマウンタースクリプトを作成しました。 これは、デバイスを物理的に取り外す前に、デバイスを閉じるのに必要なだけの時間をosに与える必要があるためです。ファイルシステムを読み取り専用でマウントした場合、ドライブをヤンクすることは1つのことですが、完全な読み取り/書き込みファイルシステムは、可能な限りクリーンにマウント解除する必要があります。 (これは、windowsの[ドライブを安全に削除する]オプションが行うことです。これは、ドライブをアンマウントするためのメカニズムですbeforeデバイスがシステムから物理的に削除されます。) 通常のファイルシステムでは、マウント時にsyncオプションを使用し、アンマウント時にumount -l(レイジーアンマウント)を使用することで、いくつかのアンマウントを「適切に」機能させることができました。レイジーアンマウントは、ファイルシステムをすぐにデタッチするようにカーネルに指示しますが、ファイルシステムへの参照を後でビジー状態でなくなったときにクリーンアップします。この種の機能はありますが、完全なアンマウントを実行するほどデータの安全性は高くありませんbeforeデバイスを削除します。 同じ理由で、暗号化されたファイルシステムでレイジーアンマウントを機能させるのに問題があるかもしれません。デバイスマッパーは、標準のファイルシステムの問題に加えて、さらに複雑なレイヤーを追加します。これにより、暗号化されたファイルシステムが汚れたマウント解除に対してさらに敏感になるように思われます。 (ただし、暗号化されたfsの経験はあまりないので、許容できる可能性があります。) うまくいけば、それはあなたにいくつかの指針を与えるでしょう。率直に言って、自動マウントの目的では、udevは機能しますが、理想的ではありません。 halevtデーモン または新しいdevicekitの方がおそらく適切でしょう。