На сколько я понимаю, создание persistent-net.rules - основная задача пакета ? 206-alt1 и 201-alt1.M70P.1 этого не делают почему-то.
Пожалуйста, включите debug в udev, и пришлите логи.
В дополнение к http://bugzilla.altlinux.org/28955#c28 Может, сделать настраиваемый вариант шаблона имён ? Скажем, чтобы не ethX можно было задать, а etherX С логами сейчас сложно, эту систему уже в работу поставил. На днях попробую ещё раз на стенде поставить и посмотреть.
Алексей подсказал набор команд: udevadm trigger udevadm trigger --action=add После этого persistent-net.rules создаётся. Видимо, надо перевешивать на сам udev и разбираться, почему action add не выполняется.
70-persistent-net.rules обнаружился в /run/udev: tmp-rules--70-persistent-net.rules. Получается, просто не скопировался в нужное место ?
udevadm trigger udevadm trigger --action=add Спасибо. Это помогло.
закрываю багу?
(В ответ на комментарий №3) > почему action add не выполняется. Совершенно на всякий: если в kvm -- то может иметь значение то, что make-initrd этот случай понимает как тестирование и добавляет сетевые модули, т.е. они грузятся ещё из initrd и дальше уже никаких add, разумеется: http://lists.altlinux.org/pipermail/devel/2014-August/198968.html
Не знаю пока, как в Сизифе, но с udev-rule-generator-net-201-alt1.M70P.4 проблема воспроизводится в p7. И что с комментарием N2 ? Оформить в виде отдельного бага с enhancement ? udev_log="debug" в udev.conf ничего интересного не дал увидеть: всё, что в логе появилось, связано только с vgchange. Или не только в messages смотреть надо ?
тогда надо перевесить на p7, что бы понимать о какой версии идет речь.
Не создаётся при загрузке, но потом если вызвать udevad trigger -c add - всё создаётся. Какую отладку предоставить ?
Судя по коду, когда udev получает ADD на сетевые устройства - /etc/udev/rules.d ещё не перемонтирован на запись, и это действительно так, по крайней мере в случае с rc.sysinit - udev стартует задолго (несколько миллисекунд) до перемонтирования корня в RW и за это время он успевает отработать ADD на сетевые устройства. Файл с рулезами в итоге образуется в /run/udev/ и его кто-то должен в конце загрузки скопировать в /etc/ По идее там ещё могут быть косяки с тем, что во время загрузки корень станет RW и часть данных будет записана в /etc/udev/rules.d, а часть в /run/udev Но я с таким не сталкивался.
в других дистрибутивах упоминается некий udev-finish, который как раз и копирует всё что надо и куда надо. У нас такого нет.
Повесил напоминалку к p8.
*** Bug 30779 has been marked as a duplicate of this bug. ***
2 rider: часом не смотрел про udev-finish с тех пор? На своих сборках такого будто не наблюдал, как бы воспроизвести...
Нет, не смотрел. Посмотри.
(In reply to comment #15) > На своих сборках такого будто не наблюдал, как бы воспроизвести... Просто поставить udev-rule-generator-net и посмотреть, что получается. :-) У меня, на текущем Сизифе, картина такая. В /etc/udev/rules.d лежит давно созданный 70-persistent-net.rules с описанным eth0, а в /run/udev лежит недавно созданный tmp-rules--70-persistent-net.rules c eth1. tmp-rules-... в 70-persistent-net.rules не скопирован. Кстати, получается, что в /run/udev/tmp-rules--70-persistent-net.rules есть только то, чего не хватает.
(In reply to comment #12) > в других дистрибутивах упоминается некий udev-finish, который как раз и > копирует всё что надо и куда надо. > > У нас такого нет. А было: # rpm -qf /etc/init.d/udevd-final udev-168-alt2.M60P.2 Только вот там использовалась такая конструкция: udev_root=$(udevadm info --run 2>/dev/null) Сейчас "udevadm info --run" не работает.
День добрый. В тестовом задании [#159059] systemd.git=229-alt1 я вернул сервис udevd-final, который занимается копированием /run/udev/tmp-rules--70-persistent-net.rules в /etc/udev/rules.d/70-persistent-net.rules. Прошу тестировать. Пока наблюдаю следующую проблему - при обновлении получаю выключенный udevd-final. Как его лучше включать по-умолчанию? И возможно, лучше если его будут включать пакеты udev-rule-generator-net и udev-rule-generator-cdrom. может кто подскажет конкретный %triggerin ?
и еще в догонку, делать ли такое же копирование для systemd? сейчас вернул только под sysv.
По триггерам документация в /usr/share/doc/rpm-4.0.4/manual/triggers -- сам её оттуда и перечитываю, но очень редко (сейчас голова не настолько ясная, чтоб триггеры писать). Также на всякий напоминаю просьбу по возможности не выкатывать существенные изменения под вторник-среду (регулярки), а вместо того пинать меня проверить сборочное задание; с #159059 исошку собираю, посмотрю.
64-битная regular-lxde.iso с task#159059 собралась и загрузилась нормально (установилась и перезагрузилась тоже без происшествий). Могу выложить.
Конечно и для systemd делать, если его планируем на сервера.
В #159059 новая сборка - можно с ней провериться. Особо обратить внимание на следующее: при установке udev сервис udevd-final не обязан быть включенным. А вот при установке его "клиентов", пакетов udev-rule-generator-cdrom или udev-rule-generator-net сервис udevd-final должен включаться. И финальный тест - если установлены udev-rule-generator-*, то после перезагрузки должны появиться файлики /etc/udev/rules.d/70-persistent-* тест интересует как при новой инсталяции, так и при обновлении. Я обновление у себя проверил - вроде все работает. Если претензий не будет, отправлю в таком виде в сизиф.
Проверил; regular-icewm.iso: - sysvinit (соответственно проверял chkconfig); - сервис udevd-final оказывается включенным; regular-lxde.iso: - systemd (проверял systemctl); - сервис udevd-final оказывается disabled/disabled/inactive. В обоих случаях установлен udev-rule-generator-net, был создан /etc/udev/rules.d/70-persistent-net.rules
<shaba> а порядок установки пакетов можешь посмотреть? сначала udev установился, а потом udev-rule-generator-net. Или наоборот? В обоих случаях картинка одинакова -- сперва u-r-g-n, затем сам udev: $ egrep '\<udev-(rule-|1:).*installed$' build.log <13>Mar 11 09:05:02 rpmi: udev-rule-generator-net-1:229-alt1 1457672311 installed <13>Mar 11 09:05:20 rpmi: udev-1:229-alt1 1457672311 installed <13>Mar 11 09:07:33 rpmi: udev-rule-generator-net-1:229-alt1 1457672311 installed <13>Mar 11 09:07:33 rpmi: udev-1:229-alt1 1457672311 installed
udev-229-alt1 успешно добрался до сизифа.
(In reply to comment #27) > udev-229-alt1 успешно добрался до сизифа. Да, работает. Сейчас уже udev-229-alt5 udev-rule-generator-net-229-alt5
(In reply to comment #2) > В дополнение к http://bugzilla.altlinux.org/28955#c28 > > Может, сделать настраиваемый вариант шаблона имён ? Скажем, чтобы не ethX можно > было задать, а etherX http://bugzilla.altlinux.org/32167
(In reply to Alexey Shabalin from comment #27) > udev-229-alt1 успешно добрался до сизифа. В p9 опять сломалось. Причём я что-то не очень понял, когда и как. Это должно было работать, когда я возился с переименованием eth -> ether в udev-rule-generator, это конец августа прошлого года. Но откат p9 на этот момент ситуацию не исправляет, что странно. Глубже пока не копал. Есть одно отличие от прошлой ситуации: в /run/udev сейчас нет tmp-rules--70-persistent-net.rules. Вообще, помогает добавить udevadm trigger и udevadm trigger --action=add в udevd-final имеющийся теперь в udev-rule-generator. Может так и поступить?
(In reply to Sergey Y. Afonin from comment #30) > В p9 опять сломалось. Причём я что-то не очень понял, когда и как. Это > должно было работать, когда я возился с переименованием eth -> ether в > udev-rule-generator, это конец августа прошлого года. Всё сошлось. Я c udev-rule-generator в p8 возился, а p9 на этом компьютере появился 27-ого феврала, и был взят готовый persistent-net.rules, полученный ещё в p8.
не может ли быть такого, что на момент попытки генерации правил tmpfs в /run ещё не смонтирован ? Добавлять повторный запуск по устройствам - идея выглядит так себе если честно.
(In reply to Anton Farygin from comment #32) > не может ли быть такого, что на момент попытки генерации правил tmpfs в /run > ещё не смонтирован ? Добавил touch /run/qwery в начало init.d/udevd, файл присутствует. > Добавлять повторный запуск по устройствам - идея выглядит так себе если > честно. Обнаружился ещё такой момент. Есть bug 32166. Если в udevd-final добавить перезагрузку модулей, то правила в persistent-net.rules тоже дописываются. Только как-то странно: если добавить rmmmod && modprobe после udevadm trigger (который там сейчас есть; про что я в комментарии 30 писал я пока убрал), то они попарно дописываются, по две строки с разными именами на один MAC-адрес. Правильно получается, если rmmod до udevadm trigger сделать, а modprobe после.
(In reply to Sergey Y. Afonin from comment #33) > то они попарно дописываются, по две строки с разными именами на один > MAC-адрес. Правильно получается, если rmmod до udevadm trigger сделать, > а modprobe после. Нет, не так. И "udevadm trigger --action=add" я не убрал в тот раз видимо. Получается так, что udevadm trigger --action=add эквивалентно for MODULE in $MODULES; do action "loading $MODULE module" modprobe $MODULE done Триггер срабатывает в момент modprobe. То есть, если вдруг чинить это в udevd-final, то вот эти два варианта эквивалентны получаются: udevadm trigger --action=add sleep 10 for MODULE in $MODULES; do action "loading $MODULE module" modprobe $MODULE done либо for MODULE in $MODULES; do action "loading $MODULE module" modprobe $MODULE done udevadm control --reload-rules for MODULE in $MODULES; do action "loading $MODULE module" modprobe $MODULE done sleep в первом случае потому, что trigger --action=add что-то прямо долго работает (слишком много всего перебирает?): udevd-final завершиться успевает, а он ещё правила дописывает. Во втором случае control --reload-rules нужно потому, что udevd не успевает перечитать правила сам до второго цикла. Ну или так же sleep помогает. Хотя, может быть, sleep на 1-2 секунды и перед control --reload-rules не повредит на всякий случай.
(In reply to Sergey Y. Afonin from comment #34) > for MODULE in $MODULES; do > action "loading $MODULE module" modprobe $MODULE > done Не тот кусок. Везде читать, как for MODULE in $MODULES; do action "reloading $MODULE module" rmmod $MODULE && modprobe $MODULE done
Вариант починки (отключаемый) через udevd-final я сделал, патч пока в bug 32166 приложил. А тут что-то вообще ничего не понимаю. p8, persistent-net.rules создаётся: libsystemd-239-alt5 libudev1-239-alt5 systemd-utils-239-alt5 udev-239-alt5 udev-extras-239-alt5 udev-hwdb-239-alt5 udev-rules-239-alt5 udev-rule-generator-net-1.1-alt1 udev-rule-generator-1.1-alt1 Sisyphus 2019/01/01, persistent-net.rules не создаётся: libsystemd-239-alt3.x86_64 libudev1-239-alt3.x86_64 systemd-utils-239-alt3.x86_64 udev-239-alt3.x86_64 udev-extras-239-alt3.x86_64 udev-hwdb-239-alt3.noarch udev-rules-239-alt3.noarch udev-rule-generator-net-1-alt2.noarch udev-rule-generator-1-alt2.noarch Где тут-то разница?.. Откат до Sisyphus с зимнего стартера JeOS/p9 (после обновления до текущего p9). Дальше уже надо дебажить udev видимо. /run для записи уже доступен до старта udev, это я в Comment 33 написал.
Ещё одно наблюдение нашлось: persistent-net.rules создаётся в p9 с systemd. Но тут речь про десктоп с KDE5, так что может просто что-то ещё такое стоит кроме systemd.
(In reply to Michael Shigorin from comment #7) > > почему action add не выполняется. > Совершенно на всякий: если в kvm -- то может иметь значение то, что > make-initrd этот случай понимает как тестирование и добавляет сетевые > модули, т.е. они грузятся ещё из initrd и дальше уже никаких add, > разумеется: http://lists.altlinux.org/pipermail/devel/2014-August/198968.html А не оно ли? Теперь уже и не в kvm. lsmod в S01bla-bla (udev - S02) показывает наличие загруженных модулей. Интерфейсы уже есть (и даже один оставленный в persistent-net.rules уже переименован). rmmod в этом месте не помогает: модули удаляются, но после S02udevd самостоятельно не появляются. В p8 то же самое (модули загружены), но это не мешает (до)создать persistent-net.rules. Какой-то патч в Сизифе убрали, или не то место нашёл?
udev-rule-generator-2:1.4-alt1 -> sisyphus: Sun Apr 26 2020 Sergey Y. Afonin <asy@altlinux> 2:1.4-alt1 - renamed sysconfig/write_net_rules to sysconfig/udev-rule-generator - renaming interfaces if 70-persistent-net.rules recently changed (ALT #32166) - added the ability to update persistent-net.rules (ALT #29282)
(In reply to Repository Robot from comment #39) > udev-rule-generator-2:1.4-alt1 -> sisyphus: > - added the ability to update persistent-net.rules (ALT #29282) В udev-rule-generator теперь это можно включить послредством UPDATE_NET_RULES=yes в /etc/sysconfig/udev-rule-generator, но наверное это, всё же, задача самого udev.
багу можно закрывать?
(In reply to Alexey Shabalin from comment #41) > багу можно закрывать? Так она не исправлена же. В стороннем пакете сделаны действия для обхода проблемы.
rule-generator сторонний пакет, в нем можно делать что нужно.
#100 udev-rule-generator 1.6-alt1 -> 2:1.6-alt2 Fri Sep 15 2023 Sergey Y. Afonin <asy@altlinux> 2:1.6-alt2 - used UPDATE_NET_RULES=yes by default
