Как найти причины, по которым правило udev не применяется?

Я добавил правило udev для создания отдельной ссылки на специальное устройство tty. Я взял поставщика и идентификатор продукта из lsusb:

Bus 001 Device 016: ID abcd:1234 Foo Device

Выход dmesg для устройства:

[  369.384850] usb 1-1.1: new full-speed USB device number 4 using xhci_hcd
[  369.470492] usb 1-1.1: New USB device found, idVendor=09d8, idProduct=0420
[  369.470506] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  369.470515] usb 1-1.1: Product: TWN4/B1.06/CCL3.12/PRS1.04
[  369.470522] usb 1-1.1: Manufacturer: OEM
[  369.475188] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device

Обычно система Debian генерирует tty ACM* для этого устройства:

$ ls /dev/ttyACM*
/dev/ttyACM0

Итак, я создал /ect/udev/rules.d/99-bizrfid.rules:

ACTION=="add", ATTRS{idVendor}=="09d8", ATTRS{idProduct}=="0420", SYMLINK+="ttyMyDevice"

Но ls /dev/tty* не показывает ttyMyDevice.

Что я пробовал до сих пор без успеха:

  1. Бег udevadm trigger. Это должно применить новое правило udev.
  2. Я сделал перезагрузку.
  3. Я посмотрел на udevadm test /dev/ttyACM0. Мой udevrule показан в конце. Так что я уверен, что это не было отменено. Но меня интересует подсказка «невозможно открыть». Тем не менее, эта подсказка присутствует и для других tty, таких как tty0 или ttyS0.
...    
Reading rules file: /lib/udev/rules.d/98-systemd.rules
Reading rules file: /etc/udev/rules.d/99-bizrfid.rules
rules contain 49152 bytes tokens (4096 * 12 bytes), 12883 bytes strings
4240 strings (40079 bytes), 3515 de-duplicated (27922 bytes), 726 trie nodes used
unable to open device '/sys/dev/ttyACM0'
Unload module index
Unloaded link configuration context.
  1. Я снова подключил USB-устройство.
  2. Я попробовал другое правило udev. Это правило верно на 100%, потому что я уже использую это правило для других устройств. Но это не работает для ttyACM0:
ACTION=="add", KERNEL=="ttyACM*", MODE="0666"

Интересно, почему это не работает. Как найти причины, по которым правило udev не применяется?


linux linux-kernel usb tty udev
person eDeviser    schedule 16.04.2021    source источник
comment
Не могли бы вы поделиться с нами действительной частью вывода dmesg? Это = помогло бы нам также узнать, что это за USB-устройство и фактические значения.   -  person tukan    schedule 19.04.2021
comment
@tukan: Хорошая идея! Я добавил вывод dmesg.   -  person eDeviser    schedule 19.04.2021
comment
Спасибо. Теперь, какой драйвер вы используете? У вас есть общий или у вас есть скомпилированный? Причина, по которой я спрашиваю, заключается в том, что если вы проверите - usb.ids я не не вижу вашего idVendor=09d8, idProduct=0420 поддерживаемого.   -  person tukan    schedule 19.04.2021
comment
dmesg говорит, что я использую драйвер cdc_acm. Я НЕ скомпилирован по индивидуальному заказу.   -  person eDeviser    schedule 19.04.2021
comment
В порядке. Если вы сделаете udevadm test -a add $(udevadm info -q path -n /dev/ttyACM0), что будет возвращено?   -  person tukan    schedule 19.04.2021
comment
Еще одна вещь пришла мне в голову. Вы (имя пользователя) состоите в группе dialup и tty?   -  person tukan    schedule 20.04.2021
comment
Вам нужно добавить SUBSYSTEM="usb"?   -  person stark    schedule 20.04.2021
comment
@stark: SUBSYSTEM="usb" не сработало.   -  person eDeviser    schedule 21.04.2021
comment
@tukan Я добавил вывод в качестве примера в ответ, но не вижу никаких проблем. Я не понимаю важности члена/группы. Я вошел в систему как root, а udevadm запускается как root. Должен ли root быть членом dialup?   -  person eDeviser    schedule 21.04.2021
comment
Вы должны добавить информацию к своему вопросу, а не как ответ на ваш вопрос. Ах, вы работаете как root, тогда все должно быть в порядке. Причина Invalid rule /etc/udev/rules.d/99-bizrfid.rules:1: invalid ACTION operation. Пожалуйста, покажите нам фактическое правило 99-bizrfid.rules, а не заглушку, как вы сделали в своем вопросе.   -  person tukan    schedule 21.04.2021
comment
Вопрос в том, как найти причины.... Поэтому я собрал решения для поиска проблем. Я думаю, что это соответствует вопросу.   -  person eDeviser    schedule 21.04.2021
comment
@tukan Большое спасибо за вашу помощь. Добавлено теперь cat из 99.bizrfid.rules. Это почти то же самое. Ошибка Invalid rule... возникла из-за того, что сегодня утром я попробовал что-то еще и забыл =. Правило теперь действительно такое же, как указано, и я обновил вывод файла udevadm test.... Извините за эту путаницу.   -  person eDeviser    schedule 21.04.2021
comment
Пожалуйста. Ответы зарезервированы для ответа на вопрос. Поскольку вы добавляете информацию, ее следует рассматривать не как ответ, а как добавление дополнительной информации, чтобы мы могли ответить на ваш вопрос.   -  person tukan    schedule 21.04.2021
comment
@старк это SUBSYSTEM=="tty".   -  person 0andriy    schedule 21.04.2021

Ответы (2)


arrow_upward
2
arrow_downward

Для udev правила /ect/udev/rules.d/99-bizrfid.rules я бы добавил SUBSYSTEM:

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="09d8", ATTRS{idProduct}=="0420", SYMLINK+="ttyMyDevice"

Вы также можете добавить ATTRS{manufacturer}==, но idVendor и idProduct достаточно.

В противном случае это выглядит правильно, и тестовый запуск создает символическую ссылку:

creating link '/dev/ttyMyDevice' to '/dev/ttyACM0'

person tukan    schedule 21.04.2021
comment
Здорово! Это работает! Но запуска udevadm trigger было недостаточно. Мне нужно было запустить udevadm trigger и udevadm test -a add .... Или полная перезагрузка. Как вы нашли причину, по которой правило udev не применялось? - person eDeviser; 21.04.2021
comment
@eDeviser Отлично;). да, udevadm trigger недостаточно. Вам нужно добавить правило, или большинство людей после этого перезагружают. Как я узнал об этом? Я бы сказал опыт и исключение всех других возможностей. Для таких вопросов, связанных с linux/unix, лучше подходит unix stackexchange. Пожалуйста, не забудьте принять его - Принятие ответов. - person tukan; 21.04.2021
comment
Если udevadm trigger не работает, это не решение. Что-то еще не так… - person 0andriy; 21.04.2021
comment
@0andriy Он неправильно написал правило. Работает ли после перезагрузки? Почему это должно быть неправильно? - person tukan; 21.04.2021
comment
Потому что нужна перезагрузка. Это против Unix. - person 0andriy; 21.04.2021
comment
@0andriy Хорошо, я понимаю, что на сервере, но на ноутбуке? Не совсем. В любом случае, вы можете использовать udevadm ... add, и он работает без перезагрузки. Вы жалуетесь безосновательно, пожалуйста, предложите лучшее решение или просто решите какую-нибудь другую проблему. - person tukan; 21.04.2021
comment
Возможно, udevadm control --reload следует выполнить перед выполнением udevadm trigger, я обычно запускаю эти две команды при изменении правил udev. Но это просто мысль. Кроме того, возможно, попробуйте повторно подключить свои USB-устройства после внесения этих изменений в правила, во всяком случае, это было бы моим первым побуждением. И, конечно же, @0andriy прав, в Linux вы не должны перезагружаться, чтобы внести такие небольшие изменения, некоторые команды перезапуска обычно подходят. - person Sam Protsenko; 22.04.2021
comment
@SamProtsenko ОП сказал, что у него это работает. Его правило udev было неверным, и в этом была суть проблемы. Что касается перезагрузки, я говорил об однократной перезагрузке, необходимой, чтобы убедиться, что все работает (если нужно), конечно, я не говорю о перезагрузке каждый раз, когда вы подключаете USB. Всегда лучше иметь его без перезагрузки, но если он находится на ноутбуке разработчика (опять же говоря об однократной перезагрузке), мне все равно, так как я перезагружаюсь около 5-10 секунд. На рабочем сервере это совершенно другая проблема, но вы не должны экспериментировать с udev правилами на такой машине. - person tukan; 22.04.2021

arrow_upward
1
arrow_downward

Согласно комментариям, я могу попробовать отладить проблему:

Проверьте драйвер

Используйте dmesg для проверки используемого драйвера и убедитесь, что он является универсальным. Если это пользовательская компиляция, проблема может быть внутри вашей пользовательской реализации. Если это общий, перейдите ко второму шагу. Я нашел имя драйвера в последней строке: cdc_acm

[  369.384850] usb 1-1.1: new full-speed USB device number 4 using xhci_hcd
[  369.470492] usb 1-1.1: New USB device found, idVendor=09d8, idProduct=0420
[  369.470506] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  369.470515] usb 1-1.1: Product: TWN4/B1.06/CCL3.12/PRS1.04
[  369.470522] usb 1-1.1: Manufacturer: OEM
[  369.475188] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device

Проверьте разрешения пользователя

Убедитесь, что разрешение вашего правила udev правильное:

chmod 644 99-myrule.rules
chown root:root 99-myrule.rules

Выполните тестовый запуск действия добавления

Проверьте вывод udevadm test -a add $(udevadm info -q path -n /dev/ttyACM0). Мой вывод выглядит так:

Звоню: тест

version 232
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

=== trie on-disk ===
tool version:          232
file size:         8447696 bytes
header size             80 bytes
strings            1849040 bytes
nodes              6598576 bytes
Load module index
Found container virtualization none
timestamp of '/etc/systemd/network' changed
timestamp of '/usr/lib/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
timestamp of '/etc/udev/rules.d' changed
Skipping overridden file: /lib/udev/rules.d/99-bizrfid.rules.
Reading rules file: /lib/udev/rules.d/50-firmware.rules

...

Reading rules file: /lib/udev/rules.d/98-systemd.rules
Reading rules file: /etc/udev/rules.d/99-bizrfid.rules
rules contain 49152 bytes tokens (4096 * 12 bytes), 12900 bytes strings
4244 strings (40114 bytes), 3517 de-duplicated (27942 bytes), 728 trie nodes used
GROUP 20 /lib/udev/rules.d/50-udev-default.rules:26
IMPORT builtin 'hwdb' /lib/udev/rules.d/60-serial.rules:7
IMPORT builtin 'usb_id' /lib/udev/rules.d/60-serial.rules:8
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0: if_class 2 protocol 0
IMPORT builtin 'hwdb' /lib/udev/rules.d/60-serial.rules:8
IMPORT builtin 'path_id' /lib/udev/rules.d/60-serial.rules:15
LINK 'serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' /lib/udev/rules.d/60-serial.rules:16
IMPORT builtin skip 'usb_id' /lib/udev/rules.d/60-serial.rules:19
LINK 'serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' /lib/udev/rules.d/60-serial.rules:23
LINK 'ttyMyDevice' /etc/udev/rules.d/99-bizrfid.rules:1
handling device node '/dev/ttyACM0', devnum=c166:0, mode=0660, uid=0, gid=20
preserve permissions /dev/ttyACM0, 020660, uid=0, gid=20
preserve already existing symlink '/dev/char/166:0' to '../ttyACM0'
found 'c166:0' claiming '/run/udev/links/\x2fserial\x2fby-id\x2fusb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00'
creating link '/dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' to '/dev/ttyACM0'
preserve already existing symlink '/dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00' to '../../ttyACM0'
found 'c166:0' claiming '/run/udev/links/\x2fserial\x2fby-path\x2fpci-0000:00:14.0-usb-0:1.1:1.0'
creating link '/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' to '/dev/ttyACM0'
preserve already existing symlink '/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0' to '../../ttyACM0'
creating link '/dev/ttyMyDevice' to '/dev/ttyACM0'
creating symlink '/dev/ttyMyDevice' to 'ttyACM0'
created db file '/run/udev/data/c166:0' for '/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/tty/ttyACM0'
ACTION=add
DEVLINKS=/dev/serial/by-path/pci-0000:00:14.0-usb-0:1.1:1.0 /dev/serial/by-id/usb-OEM_TWN4_B1.06_CCF3.00_PRS1.04-if00 /dev/ttyMyDevice
DEVNAME=/dev/ttyACM0
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/tty/ttyACM0
ID_BUS=usb
ID_MODEL=TWN4_B1.06_CCF3.00_PRS1.04
ID_MODEL_ENC=TWN4\x2fB1.06\x2fCCF3.00\x2fPRS1.04
ID_MODEL_FROM_DATABASE=Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI
ID_MODEL_ID=0420
ID_PATH=pci-0000:00:14.0-usb-0:1.1:1.0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_1_1_1_0
ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
ID_PCI_INTERFACE_FROM_DATABASE=XHCI
ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
ID_REVISION=0200
ID_SERIAL=OEM_TWN4_B1.06_CCF3.00_PRS1.04
ID_TYPE=generic
ID_USB_CLASS_FROM_DATABASE=Communications
ID_USB_DRIVER=cdc_acm
ID_USB_INTERFACES=:020201:0a0000:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=OEM
ID_VENDOR_ENC=OEM
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_VENDOR_ID=09d8
MAJOR=166
MINOR=0
SUBSYSTEM=tty
TAGS=:systemd:
USEC_INITIALIZED=71480300178
Unload module index
Unloaded link configuration context.
person eDeviser    schedule 21.04.2021