Странности работы udev с CD/DVD устройствами

Раньше, когда IDE-диски ещё нормально работали со старый драйвером (и именовались /dev/hd*), команда mount /mnt/cdrom всегда срабатывала успешно, независимо от времени распознавания диска приводом и состояния привода перед командой (открыт/только что закрыт/диск распознан/остановлен). Конечно, если диск был и распознавался приводом.

После вынужденного перехода на новый драйвер (винчестеры /dev/sd*, CD/DVD /dev/sr*), успех монтирования начал зависеть от состояния привода в момент подачи команды. Пришлось писать скрипт, повторяющий процедуру “до победного конца”.

И вот теперь, после перехода на udev-1.6.5 и ядро 2.6.37, к проблемам с монтированием добавилась ещё одна, уже совсем дикая – только что смонтированный диск иногда снова сам собой отмонтируется сразу после монтирования!

Сообщения во всех логах идут только о монтировании. Куда копать – непонятно. Единственное, что удалось сделать – скрипт, учитывающий новую “странность” монтирования, с паузой не только между попытками, но и между монтированием и проверкой.
#!/bin/sh
for ((i=2; i<=20; i++)) ; do
 mount /mnt/cdrom &>/dev/null
 sleep 0.5
 A=`grep /mnt/cdrom /etc/mtab`
 if [ -n "$A" ] ; then exit 0; fi
 # echo $i
 sleep 0.5
done
mount /mnt/cdrom
Похоже, udev с каждой новой версией становится всё более глючным и непредсказуемым. К предыдущим “странностям”, описанным в посте выше, а также тут и тут добавилась ещё более редкая и трудновоспроизводимая – иногда извлечение смонтированного диска сопровождается его повторным “проглатыванием”.
P.S.
Поймал причину :)
Оказывается, такое происходит, если смонтированный (и заблокированный) диск пытались извлечь кнопкой на приводе. Кнопкой он при этом не извлекается, но событие запоминается и обрабатывается в самый неподходящий момент… Осталось выяснить, кто виноват.
Приехали.
После очередного обновления udev команда eject больше не работает от пользователя, если вставлен диск!
eject: unable to eject, last error: Inappropriate ioctl for device
Если диска нет – работает. eject -t работает всегда.
Забавно. Оказывается, лоток привода блокируется, если вставлен диск.
sdparm -C unlock /dev/sr0
помогает.
Мало того, оказывается, это не баг, а фича:
Udev now enables kernel media-presence polling if available. Part
of udisks optical drive tray-handling moved to cdrom_id: The tray
is locked as soon as a media is detected to enable the receiving
of media-eject-request events. Media-eject-request events will
eject the media.
http://www.spinics.net/lists/hotplug/msg05030.html
Или я чего-то не понял, или с этого udev надо срочно куда-то мигрировать.
У меня дня 4 назад лоток блокировался. Сейчас все прошло: нажал на кнопку - получил диск :)
И вроде ничего не ковырял, только обновлялся
xxTTxx, я не о кнопке, а о программном запросе на извлечение диска.
Разработчики udev, как выяснилось, с версии 172 добавили в /lib/udev/rules.d/ файлик 60-cdrom_id.rules следующего содержания:
# do not edit this file, it will be overwritten on update
ACTION=="remove", GOTO="cdrom_end"
SUBSYSTEM!="block", GOTO="cdrom_end"
KERNEL!="sr[0-9]*|xvd*", GOTO="cdrom_end"
ENV{DEVTYPE}!="disk", GOTO="cdrom_end"
# unconditionally tag device as CDROM
KERNEL=="sr[0-9]*", ENV{ID_CDROM}="1"
# media eject button pressed
ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $tempnode", GOTO="cdrom_end"
# import device and media properties and lock tray to
# enable the receiving of media eject button events
IMPORT{program}="cdrom_id --lock-media $tempnode"
LABEL="cdrom_end"
Это значит, что сразу когда вы вставляете диск, лоток привода автоматически блокируется командой
/lib/udev/cdrom_id --lock-media /dev/sr0
а когда нажимаете на кнопку, заблокированный привод посылает сигнал, который обрабатывает udev, и сама выкидывает диск командой
/lib/udev/cdrom_id --eject-media /dev/sr0
А вот если вы попытаетесь извлечь диск программно, например командой eject в консоли, ничего у вас не выйдет! Лоток заблокирован, программа получит невразумительную ошибку ввода/вывода, а udev же никакого события не получит, поскольку не умеет отслеживать системные вызовы.

Другими словами, товарищи разработчики udev ради удобства отслеживания кнопки на дисководе изменили поведение системы – теперь любые программы, которые не знают, что привод по-умолчанию нынче заблокирован, не смогут его открыть.
Natrio
Это значит, что сразу когда вы вставляете диск, лоток привода автоматически блокируется командой
/lib/udev/cdrom_id --lock-media /dev/sr0
а когда нажимаете на кнопку, заблокированный привод посылает сигнал, который обрабатывает udev, и сама выкидывает диск командой
/lib/udev/cdrom_id --eject-media /dev/sr0
А вот если вы попытаетесь извлечь диск программно, например командой eject в консоли, ничего у вас не выйдет! Лоток заблокирован, программа получит невразумительную ошибку ввода/вывода, а udev же никакого события не получит, поскольку не умеет отслеживать системные вызовы.

Наверное, это локальный глюк udev на вашей системе. Я сейчас с приводом поигрался - у меня автоматической блокировки лотка не происходит.

То есть, вставляю диск - он автоматически монтируется в третьегноме.
Нажимаю на кнопку - диск извлекается (событие не отслеживается udev - размонтирования в гноме не происходит)
Вставляю заново. Монтируется. Запускаю “$ eject /dev/sr0” - диск извлекается, размонтирование происходит (от рута - то же самое)
Вставляю заново. Монтируется. Отсоединяю том в Наутилусе - диск извлекается, размонтирование происходит

А вот если вручную запустить
/lib/udev/cdrom_id --lock-media /dev/sr0
- то происходит следующее:
НАжимаю кнопку на приводе - никакой реакции
Команда “$ eject /dev/sr0” завершается с сообщением
eject: unable to eject, last error: Неприменимый к данному устройству ioctl
но при этом лоток все равно открывается, диск извлекается.
В наутилусе диск размонтируется и извлекается по щелчку мышки.

У себя автоматическую блокировку лотка наблюдал однократно несколько дней назад. Я тогда болванку записывал. Только не помню - это иди до записи было, или после.
Привод - Optiarc DVD RW AD-7260S, 1.02
Система - x86_64
AHCi в биосе включено
xxTTxx, я уже разговаривал с одним из мейнтейнеров по этому поводу. Он успешно воспроизвёл проблему с eject на своей машине. Это не локальный глюк udev, просто у меня не стоит “третьегнум”, который всё делает за вас.

Если интересно, загрузитесь изначально в консоль (чтобы не запустился console-kit, а из него udisks), войдите под пользователя, вставьте диск, подождите секунд 10-15, и попробуйте команду eject -v.
А ещё лучше
strace -e ioctl eject
Вот если тогда он у вас сработает, можно будет разбираться дальше.
В результате пришлось самому делать патч на eject.
https://bugs.archlinux.org/task/25405
Что делать с udev, пока думаю…
Natrio, так может в AUR, eject с патчиком? Я бы воспользовался, да и не только я, думаю. Ожидая развития событий=)
 
Зарегистрироваться или войдите чтобы оставить сообщение.