Comments 15
Адреса устройств USB могут меняться при включении даже в тот же самый порт. Как Вы решаете эту проблему?
Замечу также, что команда
предпочтительнее, чем
Замечу также, что команда
getent group lp
предпочтительнее, чем
cat /etc/group | egrep lp
Но стоит помнить, что getent входит в libc-bin, которая может быть не всюду установлена. В том же контейнере её может не быть
Адреса устройств меняются только в том случае, если вы пытаетесь переключить устройство в другой порт, или переподключить в тот же порт с малым промежутком времени. При переподключении в тот же порт с малым промежутком времени, можно написать правило в udev, закрепив принтер по серийному номеру.
При перезагрузке ни разу не наблюдал, чтобы устройство, которое подключено к одному и тому же порту меняло адрес. (Эксплуатирую данное решение не долго, но до этого, как и описывал, эксплуатировал решение на Ubuntu 14.04 и LXC 1.0, проблем не замечено)
При перезагрузке ни разу не наблюдал, чтобы устройство, которое подключено к одному и тому же порту меняло адрес. (Эксплуатирую данное решение не долго, но до этого, как и описывал, эксплуатировал решение на Ubuntu 14.04 и LXC 1.0, проблем не замечено)
адреса назначаются по порядку, и если устройство задумается с ответом, у него может быть другой адрес :)
Попробуйте, например
lsusb -d 9710:7830 | tr ':' ' ' | cut -d ' ' -f 2,4
Попробуйте, например
lsusb -d 9710:7830 | tr ':' ' ' | cut -d ' ' -f 2,4
Ну я в принципе тоже и написал. При быстром переподключении может смениться адрес, но это можно решить при помощи udev.
А я говорю про первую загрузку. Я бы не стал полагаться на то, что устройство всегда получит адрес A на шине B.
И да, правило в udev поможет.
И да, правило в udev поможет.
Не совсем понял, про первую загрузку.
Если про первую загрузку контейнера, то в любом случае устройство пробрасывается из хоста, а значит перед тем, как пробросить устройство, оно должно уже быть подключено к хосту, иначе это будет не проброс конкретного устройства, а проброс шины в целом, т.к. адрес конкретного устройства определить попросту не получится.
Если про первую загрузку контейнера, то в любом случае устройство пробрасывается из хоста, а значит перед тем, как пробросить устройство, оно должно уже быть подключено к хосту, иначе это будет не проброс конкретного устройства, а проброс шины в целом, т.к. адрес конкретного устройства определить попросту не получится.
А может кто разбирался почему в контейнерах не работают kernel логи?
У меня модем как-то так проброшен
lxc.cgroup.devices.allow = c 188:0 rwm
lxc.autodev: 1
lxc.hook.autodev: sh -c «mknod -m 0666 ${LXC_ROOTFS_MOUNT}/dev/ttyUSB0 c 188 0»
А какая версия lxc при этом используется? У меня в старой версии до 2.0 тоже так работало, ну или похожим образом.
2.0.7
Ну и как? Работает такое в LXD?
Кстати, еще полезно бывает «передернуть» USB на хосте чем-то вроде
Рецепт «передергивания» для USB2.0 и 3.0
Кстати, еще полезно бывает «передернуть» USB на хосте чем-то вроде
echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/unbind && echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/bindРецепт «передергивания» для USB2.0 и 3.0
Sign up to leave a comment.
Проброс USB-принтера в контейнер LXD