Зависание при загрузке

Добрый день!
Mageia 4 зависает при загрузке после сообщения о проверке новых устройств. Система была недавно обновлена с Mageia 3 однако первое время после обновления загружалась нормально (за исключнием появления сообщений "Already instlled on this kernel" для nvidia-current и virtualbox).
Сходная проблема возникала при обновлении ранее этой же системы с Mageia 2 до 3, тогда всё в итоге решилось переустановкой драйвера nvidia. Однако сейчас ситуация несколько иная - не только не запускаются иксы, но и не удаётся войти на runlevel 3, работает только однопользовательский режим без поддержки сети (виснет после init 3).
Вероятно это как-то связано с тем, что после обновления до Mageia 4 настраивал nfs - менял имя компьютера, редактировал hosts и т.п.
Что делать? Куда копать? Как заставить, по крайней мере, выйти в runlevel 3?

"skier" написал:

"Already instlled on this kernel" для nvidia-current и virtualbox

потому что ваша система КАЖДЫЙ РАЗ по новому пыталась ставить это ПО. И дело не в системе, а в ваших руках(которыми вы ЭТО в систему добавили)

"skier" написал:

Что делать? Куда копать? Как заставить, по крайней мере, выйти в runlevel 3?

drBatty , прежде всего мне удивительна ваша агрессивность в мой адрес. Вы что, всех так встречаете?
Тем более, что единственное моё действие "руками" заключалось в даче команды на обновление дистрибутива, а баг с обновлением драйвера nvidia официально зарегистрирован, например, здесь: https://bugs.mageia.org/show_bug.cgi?id=12893
Меня интересует, однако, невозможность перейти на runlevel 3 в моём случае. При обновлении с Магеи 2 на 3 я "лечился" переустановкой nvidia, но тогда система загружалась на 3-ий уровень.

Относительно вашей рекомендации "читать логи" - boot.log заканчивается строчками:

nvidia-current (331.79-1.mga4.nonfree): Already installed on this kernel.
virtualbox (4.3.16-1.mga4): Already installed on this kernel.
Проверяется наличие новых устройств

dmesg - сообщением о регистрации драйвера uvcvideo

Что смотреть дальше?
Если есть какие-то конструктивные предложения - прошу высказываться.
Если нет, то лучше не тратить своё и моё время.

"skier" написал:

При обновлении с Магеи 2 на 3 я "лечился" переустановкой nvidia

С VBox'ом был аналогичный баг https://bugs.mageia.org/show_bug.cgi?id=13547 его лучше тоже переустанавливать / удалять в таких ситуациях

"skier" написал:

Относительно вашей рекомендации "читать логи"

Что в
[console]journalctl[/console]
?
Чтобы все не читать, можно задать с какой даты вывести, с того дня как не загружается или с предыдущего
[console]journalctl --since=год-месяц-день
# например
journalctl --since=2014-10-15 # выведет лог с 15 октября 2014[/console]

skier,
Загружаетесь в новое ядро? (которое установилось после обновления - в окне GRUB должны остаться несколько строк с ядрами)

Загрузиться в него.
Попробуйте зайти в рутовый шелл так: передайте в загрузку grub

init=/bin/bash

Далее переустановите пакеты virtualbox и nvidia
Найти их можно так:
[console]rpm -qa | grep virtualbox nvidia[/console]
Удалить и сразу поставить тактак:
[console]urpme пакеты && urpmi пакеты[/console]
После того как пакеты установятся перезагрузиться.

"skier" написал:

Вы что, всех так встречаете?

да.

"skier" написал:

Если нет, то лучше не тратить своё и моё время.

Извиняюсь. Проблема в том, что у вас systemd, а у systemd проблема с логами. Я(и ещё множество людей) очень давно говорил о том, что введение systemd приведёт именно к таким проблемам. Но всем ведь всё равно…

ОК, магие systemd, я об этом не знал. Знал-бы, промолчал.

"drBatty" написал:

у systemd проблема с логами

Что есть то есть =(

Благодарю всех отозвавшихся!
Позавчера и вчера не было времени заниматься поиском проблем, сделал только копию системного раздела из-под live cd.
Сегодня загрузился в failsafe mode (с последним ядром), по подсказке xxblx принялся изучать лог journalctl, и готовить сообщение на форум. Потом решил снова попробовать дать init 3, дождаться зависания, а потом посмотреть что будет в свежем логе после такой попытки. Ввёл команду - и, о чудо! - система загрузилась в multiuser mode, причём на 2-ом терминале стартовали иксы с приглашением kdm.
Попробовал перезагрузиться уже сразу в нормальном режиме, минуя failsafe - получилось. Тем не менее, при загрузке как и раньше были сообщения

nvidia-current (331.79-1.mga4.nonfree): Already installed on this kernel.
virtualbox (4.3.16-1.mga4): Already installed on this kernel.

Не уверен - стоит ли пытаться что-то мутить с переустановкой virtualbox и nvidia. Вероятно, причина всё же не в них.
Во всех логах загрузок (успешных и зависаний) присутствуют сообщения об ошибках вида:

[console]окт 19 12:39:25 ALDAN systemd-udevd[512]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/60_iscan.rules:8
окт 19 12:39:25 ALDAN systemd-udevd[512]: invalid rule '/etc/udev/rules.d/60_iscan.rules:8'
окт 19 12:39:25 ALDAN systemd-udevd[512]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/60_iscan.rules:9
окт 19 12:39:25 ALDAN systemd-udevd[512]: invalid rule '/etc/udev/rules.d/60_iscan.rules:9'
окт 19 12:39:25 ALDAN systemd-udevd[512]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/60_iscan.rules:10
окт 19 12:39:25 ALDAN systemd-udevd[512]: invalid rule '/etc/udev/rules.d/60_iscan.rules:10'
окт 19 12:39:25 ALDAN systemd-udevd[512]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/60_iscan.rules:11
окт 19 12:39:25 ALDAN systemd-udevd[512]: invalid rule '/etc/udev/rules.d/60_iscan.rules:11'
[/console]

И далее вплоть до rules:76
В случаях, когда система зависала ниже встречается такое:

[console]окт 19 12:39:57 ALDAN systemd-udevd[512]: worker [519] /devices/pci0000:00/0000:00:02.0/usb1 timeout; kill it
окт 19 12:39:57 ALDAN systemd-udevd[512]: seq 1322 '/devices/pci0000:00/0000:00:02.0/usb1' killed
окт 19 12:40:27 ALDAN systemd-udevd[512]: worker [518] /devices/pci0000:00/0000:00:02.0/usb1/1-1 timeout; kill it
окт 19 12:40:27 ALDAN systemd-udevd[512]: seq 1324 '/devices/pci0000:00/0000:00:02.0/usb1/1-1' killed
окт 19 12:40:27 ALDAN systemd-udevd[512]: worker [520] /devices/pci0000:00/0000:00:02.0/usb1/1-3 timeout; kill it
окт 19 12:40:27 ALDAN systemd-udevd[512]: seq 1328 '/devices/pci0000:00/0000:00:02.0/usb1/1-3' killed
[/console]

-тот же номер процесса: 512

И потом вот такое:

[console]окт 19 12:43:13 ALDAN kernel: INFO: task systemd-udevd:518 blocked for more than 120 seconds.
окт 19 12:43:13 ALDAN kernel: Tainted: P O 3.14.18-server-3.mga4 #1
окт 19 12:43:13 ALDAN kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
окт 19 12:43:13 ALDAN kernel: systemd-udevd D c02cdec9 0 518 512 0x00000004[/console]

- тот же номер процесса: 518, 512
Аналогично для процесса 520:
[console]окт 19 12:43:13 ALDAN kernel: INFO: task systemd-udevd:520 blocked for more than 120 seconds.
окт 19 12:43:13 ALDAN kernel: Tainted: P O 3.14.18-server-3.mga4 #1
окт 19 12:43:13 ALDAN kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
окт 19 12:43:13 ALDAN kernel: systemd-udevd D c02cdec9 0 520 512 0x00000004
[/console]

И, наконец:
[console]окт 19 12:43:13 ALDAN kernel: INFO: task service_harddra:14669 blocked for more than 120 seconds.
окт 19 12:43:13 ALDAN kernel: Tainted: P O 3.14.18-server-3.mga4 #1
окт 19 12:43:13 ALDAN kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
окт 19 12:43:13 ALDAN kernel: service_harddra D 00000005 0 14669 641 0x00000000[/console]

То есть, похоже, система ждёт ответа от какого-то устройства, и не дожидается.
От чего-то на USB? И что за нарушенные правила от 8 по 76?

UPDATE:
Ага, понял, речь о правилах пакета "Image Scan", эти же ошибки были и на старом ядре, до обновления до Mageia 4, однако ранее сканер, который всегда выключен (если это он?), никогда не вешал систему...

UPDATE2:
Немного поразмыслив, склонен предполагать что накрывается USB хаб.

Да, похоже что вешает систему правило для usb-устройства.

"skier" написал:

Ага, понял, речь о правилах пакета "Image Scan", эти же ошибки были и на старом ядре, до обновления до Mageia 4, однако ранее сканер, который всегда выключен (если это он?), никогда не вешал систему...

Вот это и странно, конечно. А если отключить сканер, загрузить систему, потом подключить в usb-разъем и включить сам сканер, соответственно, система повиснет наглухо? Что будет в журнале?

И покажите содержимое правила
[console]cat /etc/udev/rules.d/60_iscan.rules[/console]

Возможно, как вариант стоит попробовать сделать резервную копию файла правила, а затем закомментировать проблемные строки 8 - 10 или попробовать удалить правило вообще.

"skier" написал:

окт 19 12:39:25 ALDAN systemd-udevd[512]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/60_iscan.rules:8
окт 19 12:39:25 ALDAN systemd-udevd[512]: invalid rule '/etc/udev/rules.d/60_iscan.rules:8'
окт 19 12:39:25 ALDAN systemd-udevd[512]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/60_iscan.rules:9
окт 19 12:39:25 ALDAN systemd-udevd[512]: invalid rule '/etc/udev/rules.d/60_iscan.rules:9'
окт 19 12:39:25 ALDAN systemd-udevd[512]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/60_iscan.rules:10
окт 19 12:39:25 ALDAN systemd-udevd[512]: invalid rule '/etc/udev/rules.d/60_iscan.rules:10'
окт 19 12:39:25 ALDAN systemd-udevd[512]: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/60_iscan.rules:11
окт 19 12:39:25 ALDAN systemd-udevd[512]: invalid rule '/etc/udev/rules.d/60_iscan.rules:11'

В случае чего, восстановить из резервной копии.

xxblx написал:

Да, похоже что вешает систему правило для usb-устройства.

Сначала тоже так думал, но на самом деле не похоже, что это оно. Правило присутствует в системе, по крайней мере, с 21.02.2013, и с ним были связаны такие же ошибки до апгрейда на Магея 4 (судя по журналу от 10.10.2014), и это не влияло на работоспособность.
Вот само правило:

# This file is part of the "Image Scan! for Linux" binary package (or
# generated automatically as part of its installation).  Any changes
# will be overwritten with each upgrade of the package.
ACTION!="add", GOTO="iscan_rules_end"
SUBSYSTEM!="usb_device", GOTO="iscan_rules_end"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0101", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0103", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0104", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0106", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0107", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0109", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010a", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010b", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010c", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010e", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="010f", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0110", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0112", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0116", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0118", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0119", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="011b", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="011c", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="011d", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="011e", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0121", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0122", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0126", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0128", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0129", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="012a", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="012b", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="012c", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="012d", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="012e", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="012f", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0801", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0802", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0805", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0806", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0807", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="080d", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="080e", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="080f", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0810", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0811", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0813", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0814", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0815", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0817", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0818", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0819", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="081a", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="081c", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="081d", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="081f", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0820", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0827", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0828", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0829", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="082a", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="082b", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="082e", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="082f", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0830", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0833", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0835", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0836", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0837", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0838", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="0839", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="083a", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="083c", MODE="0666"
SYSFS{idVendor}=="04b8", SYSFS{idProduct}=="083f", MODE="0666"
LABEL="iscan_rules_end"

В нём "проблемные" все строки, начиная с 8 по 76 (я просто не стал перегружать предыдущий постинг), содержащие id сканеров Epson.
"Проблемные" они, очевидно, потому что сканер в момент загрузки системы физически выключен.
Если его включить, зависания не происходит, и сканер корректно определяется:

[console][vova@ALDAN ~]$ lsusb
Bus 002 Device 005: ID 18e3:9101 Fitipower Integrated Technology Inc All-in-1 Card Reader
Bus 002 Device 007: ID 04b8:0122 Seiko Epson Corp. GT-F520/GT-F570 [Perfection 3590 PHOTO]
Bus 002 Device 003: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 03f0:6004 Hewlett-Packard DeskJet 5550
Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub[/console]

Думаю, проблема с самой шиной USB, поскольку тут:

[console]окт 19 12:39:57 ALDAN systemd-udevd[512]: worker [519] /devices/pci0000:00/0000:00:02.0/usb1 timeout; kill it
окт 19 12:39:57 ALDAN systemd-udevd[512]: seq 1322 '/devices/pci0000:00/0000:00:02.0/usb1' killed
окт 19 12:40:27 ALDAN systemd-udevd[512]: worker [518] /devices/pci0000:00/0000:00:02.0/usb1/1-1 timeout; kill it
окт 19 12:40:27 ALDAN systemd-udevd[512]: seq 1324 '/devices/pci0000:00/0000:00:02.0/usb1/1-1' killed
окт 19 12:40:27 ALDAN systemd-udevd[512]: worker [520] /devices/pci0000:00/0000:00:02.0/usb1/1-3 timeout; kill it
окт 19 12:40:27 ALDAN systemd-udevd[512]: seq 1328 '/devices/pci0000:00/0000:00:02.0/usb1/1-3' killed
[/console]

таймаут идёт по шине 1, а сканер висит на 2-ой, как видно выше.
В другом эпизоде неудачной загрузки есть аналогичные таймауты по шине 2, без упоминания сканера.
Возможно, глючит USB контроллер?

skier, возможно.
Другой ОС установленной нет, чтобы проверить? Может с железом проблема?

*ROFL* Ребят, правда, без обид, иногда, всё же, действительно стоит просто-напросто переустановить систему, скопировав /home в свой аварийный контейнер (я так называю внешние диски и т.п.), чем вот так днями сидеть и ковыряться в возможных багах мейнтейнера, проверяя десятки тысяч кода *ROFL* *CRAZY* Извините за оффтоп, наболело.

P.S. Вот поэтому не люблю я менять конфиги...потому что забудешь, что менял, а потом при обновлении вспоминай, чего ты раньше там изменял, и почему это не работает сейчас, после обновления.

"chelovekot" написал:

просто-напросто переустановить систему

И остаться с нерешенным багом. Правило это, похоже, таки кривое. ТС, а что выдается по команде

# udevadm monitor --property

при подключении сканера?
И да, в моей системе я не увидел в man udev ключа SYSFS{}. Версия udev - 182.

"yars" написал:

И остаться с нерешенным багом.

А ещё неизвестно, баг ли это или специфическая настройка конфигов пользователем, которая конфликтует с обновлением... багом будет точно, если проявится на "голой", только что установленной, системе.

xxblx написал:

Другой ОС установленной нет, чтобы проверить? Может с железом проблема?

Нет. Была винда, но давно умерла "естественной смертью". Воскрешать не стал.
Да и как проверить? Вот сегодня комп опять без проблем загрузился (тьфу-тьфу три раза).

chelovekot, это "не наш метод". :) Я последний раз так делал, когда с Мандривы на Магею пересаживался. И тоже, кстати, не без косяков получается, когда в старой системе куча пакетов стоит, которые уже и не помнишь когда и по какому поводу ставил. Всё равно приходится потом ковыряться.

yars:

[root@ALDAN vova]# udevadm monitor --property
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[575.274949] add      /devices/pci0000:00/0000:00:02.1/usb2/2-4 (usb)
ACTION=add
BUSNUM=002
DEVNAME=/dev/bus/usb/002/007
DEVNUM=007
DEVPATH=/devices/pci0000:00/0000:00:02.1/usb2/2-4
DEVTYPE=usb_device
MAJOR=189
MINOR=134
PRODUCT=4b8/122/110
SEQNUM=2306
SUBSYSTEM=usb
TYPE=255/255/255
KERNEL[575.275373] add      /devices/pci0000:00/0000:00:02.1/usb2/2-4/2-4:1.0 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:02.1/usb2/2-4/2-4:1.0
DEVTYPE=usb_interface
INTERFACE=255/255/255
MODALIAS=usb:v04B8p0122d0110dcFFdscFFdpFFicFFiscFFipFFin00
PRODUCT=4b8/122/110
SEQNUM=2307
SUBSYSTEM=usb
TYPE=255/255/255
UDEV  [575.300947] add      /devices/pci0000:00/0000:00:02.1/usb2/2-4 (usb)
ACTION=add
BUSNUM=002
DEVNAME=/dev/bus/usb/002/007
DEVNUM=007
DEVPATH=/devices/pci0000:00/0000:00:02.1/usb2/2-4
DEVTYPE=usb_device
ID_BUS=usb
ID_FOR_SEAT=usb-pci-0000_00_02_1-usb-0_4
ID_MODEL=EPSON_Scanner
ID_MODEL_ENC=EPSON\x20Scanner
ID_MODEL_FROM_DATABASE=GT-F520/GT-F570 [Perfection 3590 PHOTO]
ID_MODEL_ID=0122
ID_PATH=pci-0000:00:02.1-usb-0:4
ID_PATH_TAG=pci-0000_00_02_1-usb-0_4
ID_REVISION=0110
ID_SERIAL=EPSON_EPSON_Scanner
ID_USB_INTERFACES=:ffffff:
ID_VENDOR=EPSON
ID_VENDOR_ENC=EPSON
ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
ID_VENDOR_ID=04b8
MAJOR=189
MINOR=134
PRODUCT=4b8/122/110
SEQNUM=2306
SUBSYSTEM=usb
TAGS=:seat:uaccess:
TYPE=255/255/255
USEC_INITIALIZED=5274610
libsane_matched=yes
UDEV  [576.337309] add      /devices/pci0000:00/0000:00:02.1/usb2/2-4/2-4:1.0 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:02.1/usb2/2-4/2-4:1.0
DEVTYPE=usb_interface
ID_MODEL_FROM_DATABASE=GT-F520/GT-F570 [Perfection 3590 PHOTO]
ID_USB_CLASS_FROM_DATABASE=Vendor Specific Class
ID_USB_PROTOCOL_FROM_DATABASE=Vendor Specific Protocol
ID_USB_SUBCLASS_FROM_DATABASE=Vendor Specific Subclass
ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
INTERFACE=255/255/255
MODALIAS=usb:v04B8p0122d0110dcFFdscFFdpFFicFFiscFFipFFin00
PRODUCT=4b8/122/110
SEQNUM=2307
SUBSYSTEM=usb
TYPE=255/255/255
USEC_INITIALIZED=75563

А правило таки да, кривое - ошибки идут даже когда с включённым сканером загружаешься. Чего-то ребята из Эпсон недомудрили...
Версия udev - 208.