LINUX.ORG.RU
ФорумTalks

eudev обновился

 , ,


0

1
[ebuild     U  ] sys-fs/eudev-1_beta1-r2 [1_beta1-r1]

Прилетело с утра.

Changelog:

eudev-1_beta1-r2 (04 Jan 2013)

04 Jan 2013; Ian Stakenvicius <axs@gentoo.org> -eudev-1_beta1-r1.ebuild, +eudev-1_beta1-r2.ebuild, +files/eudev-1_beta1-fix-modprobe-call.patch: fixed module loading when USE=-kmod but kmod is installed; put keymap files back in lib/udev

★★★★★

Последнее исправление: leg0las (всего исправлений: 1)

Ответ на: комментарий от Kindly_Cat

а в будущем удеве красота, меняют правила именовая persisent-net девайсов, возвращая проблемы решенные в 2007.

qnikst ★★★★★
()
Ответ на: комментарий от AX

насколько я понял:

возвоможные race condition в случае одновременного переименования и появляения устройства с таким же именем. Насколько я понял системы с systemd не затронет, т.к. изменения придут вместе с решением со стороны системд.

Ну и как обычно утверждения, что это даёт гарантии действительно неизменяемых имён, хотя это и так есть.

qnikst ★★★★★
()
Ответ на: комментарий от Kindly_Cat

Я как заинтересованый в разработке eudev пользователь написал.

leg0las ★★★★★
() автор топика
Ответ на: комментарий от Thero

репозиторий udev? Я знаком по обсуждению на #gentoo-dev, моя информация может быть не до конца верной, ибо я плохо разбираюсь в udev.

qnikst ★★★★★
()

Где же они раньше то были? Я уже везде смержил / и /usr, благо lvm.
Или у сабжа есть еще какие-то фичи, кроме поддержки /usr отдельным разделом?

Lavos ★★★★★
()
Последнее исправление: Lavos (всего исправлений: 1)
Ответ на: комментарий от AX

Арчепроблемы:-)

В генте он хардмаскед.

leg0las ★★★★★
() автор топика

Ну теперь Пёттерингу точно капец.

buddhist ★★★★★
()
Ответ на: комментарий от Thero

это более того в irc было, а логируется ли канал, чтобы дать ссылку я не знаю.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

а в будущем удеве красота, меняют правила именовая persisent-net девайсов, возвращая проблемы решенные в 2007.

Не решенные. Из-за ненадежности старой схемы привязки имен интерфейсов к MAC-адресам у меня на работе только чуть-чуть не дошло до суда с хостером (который мы бы все равно проиграли, т.к. баг был в udev'е).

Сути такая. Заказали у американского хостера выделенный сервер Dell, попросили поставить Debian Stable. В сервере две набортные сетевые карты broadcom (на момент заказа это было невозможно знать), требуют firmware, которого в debian installer'е нет. Сотрудник хостера временно поставил туда сетевую карту от Intel, поставил Debian через нее по сети, в результате eth0 = intel, eth1 = broadcom, eth2 = broadcom. Все три карты подключены к одному свитчу. Udev благополучно записал свой файлик с персистентными правилами привязки имен к MAC'ам. Сотрудник хостера поменял в /etc/network/interfaces, чтобы система ходила в интернет через eth1, а не через eth0, выключил сервер, убрал intel'овскую карту, включил сервер обратно. Итог: eth0 не существует, eth1 = broadcom (с интернетом), eth2 = broadcom (с доступом во внутреннюю сеть хостера - т.е. по сути не используется), все работает, можно пользоваться сервером. На свитче хостер прописал соответствие нашего IP и MAC от eth1 (мы об этом не знали).

После этого сервер несколько раз перезагружали, и все работало как надо. Только один раз дело дошло до незапланированной перезагрузки. После нее сервер перестал пинговаться. Письмо хостеру, они рапортуют «все исправлено». Ну да, пингуется и работает, более детально проверять не стал, т.к. не было повода. До следующей перезагрузки. После чего начали на них собирать материалы для судебного иска за нарушение SLA.

А хостер спрашивает: «а что это у вас там за система резервирования каналов? почему ваш IP прыгает по MAC'ам, а я ничего не знаю?». Я тоже ничего не знаю. Подняли логи хостера - выяснилось, что IP прыгал с первой broadcom'овской сетевой карты на вторую. Т.е. персистентное правило существовало, но не применялось!

Потом на IRC мне объяснили, что избежать такого рода проблем при переименовании ethX -> ethY при условии, что целевое имя может быть занято (а у нас это так, в наиболее распространенном случае надо переименовать eth0 -> eth1, eth1 -> eth2), практически невозможно, и что я ССЗБ, так как использовал Debian, а не RHEL, где biosdevname есть по умолчанию и такого глюка просто не может быть. Приятно видеть, что и остальной мир отвяжут от этой ненадежной старой схемы.

P.S. хостера все равно сменили по другим причинам.

AEP ★★★★★
()

Я вот думаю - хотелось бы обновить вино (1.4.1), но новое вино хочет новый удав, а новый удав ставить не хочется, поставить eudev?

leg0las ★★★★★
() автор топика
Ответ на: комментарий от AEP

Сотрудник хостера временно поставил туда сетевую карту от Intel, поставил Debian через нее по сети, в результате eth0 = intel, eth1 = broadcom, eth2 = broadcom. Все три карты подключены к одному свитчу. Udev благополучно записал свой файлик с персистентными правилами привязки имен к MAC'ам. Сотрудник хостера поменял в /etc/network/interfaces, чтобы система ходила в интернет через eth1, а не через eth0, выключил сервер, убрал intel'овскую карту, включил сервер обратно.

если я всё правильно понимаю, то он должен был потереть файлик persistent-net. ну или втыкать карточку последней. Т.к. имена интерфейсов выдаются в PCI-bus-order, то они бы выдавались правильно даже без персистентных правил.

Остаются некоторые проблемы, которые этот патч решает лучше, чем другие, но при этом он ломает настроенные системы, таким образом это является хорошим решением, но плохим умолчанием.

qnikst ★★★★★
()
Ответ на: комментарий от gatsu

тебе ведь приходилось рыться в редхато-коде не относящемся к ядру, особенно тому поддержка, которого в последний год стала неактивной?

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

имена интерфейсов выдаются в PCI-bus-order

Это неверно. Собственно, именно из-за неверности этого весь сыр-бор.

Имена на самом деле даются ядром интерфейсам в порядке привязки драйверов к PCI-устройствам. Драйвера привязываются к PCI-устройствам приблизительно в том порядке, в котором udev загружает их модули. А модули загружаются параллельно и, следовательно, в _случайном_ порядке, который даже не является неизменным между перезагрузками системы.

AEP ★★★★★
()
Ответ на: комментарий от AEP

понял, тогда согласен.

в общем-то решения можно сделать и с существующим udev, напр. если бы ядро и удев переименовывали девайсы в разных пространствах имён, или делать тоже самое хаком, автоматом переименовывая девайс в _renaming и потом применяя персистент правила.

В любом случае принятое решение решает проблемы достаточно эффективно, но при этом ломая часть систем. В целом мне лично пофиг, поскольку в gentoo будет use flag на это дело.

qnikst ★★★★★
()
Ответ на: комментарий от Lavos

Вчера-сегодня ставил с нуля генту на работе, система матюгалась что нету /sbin/udevd. Потребовалось поставить eudev, иначе большая и мохнатая.

dismal_faun ★★
()
Ответ на: комментарий от iBliss

cat /etc/network/interfaces

К сожалению, уже не могу. Контракт расторгнут. А с того сервера, который на замену у другого хостера - ничего интересного, статика с алиасами на одном интерфейсе eth0.

AEP ★★★★★
()
Последнее исправление: AEP (всего исправлений: 1)
Ответ на: комментарий от AEP

Навскидку не вспомнишь? ethX подымался через auto-правила или allow-hotplug? (сильно думаю, что проблема в автоподъёме).

iBliss
()
Ответ на: комментарий от iBliss

По умолчанию в Debian используется allow-hotplug, но на большинстве серверов, которые настраиваю сам, я переделываю на auto. Думаю, что там тоже переделал, но на 100% уже не уверен.

Впрочем, не понимаю, как это может привести к имевшему место багу. Ведь в случае использования auto попытка поднять интерфейс получается ровно одна, из init-скриптов, никак не привязанная к обработчикам uevent'ов (в отличие от allow-hotplug), и заведомо после udevadm settle.

AEP ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.