29282 2013-08-14 14:43:04 +0400 Не создаёт persistent-net.rules 2023-09-15 15:10:43 +0300 1 1 4 Development Sisyphus udev unstable all Linux CLOSED FIXED P3 normal --- 30940 1 asy shaba arseny evg mike month.of.death real.altlinux.org rider shaba qa-sisyphus oldest_to_newest 142085 0 asy 2013-08-14 14:43:04 +0400 На сколько я понимаю, создание persistent-net.rules - основная задача пакета ? 206-alt1 и 201-alt1.M70P.1 этого не делают почему-то. 142086 1 shaba 2013-08-14 14:46:17 +0400 Пожалуйста, включите debug в udev, и пришлите логи. 142088 2 asy 2013-08-14 14:54:36 +0400 В дополнение к http://bugzilla.altlinux.org/28955#c28 Может, сделать настраиваемый вариант шаблона имён ? Скажем, чтобы не ethX можно было задать, а etherX С логами сейчас сложно, эту систему уже в работу поставил. На днях попробую ещё раз на стенде поставить и посмотреть. 142738 3 asy 2013-09-20 00:45:19 +0400 Алексей подсказал набор команд: udevadm trigger udevadm trigger --action=add После этого persistent-net.rules создаётся. Видимо, надо перевешивать на сам udev и разбираться, почему action add не выполняется. 143326 4 asy 2013-10-21 10:51:22 +0400 70-persistent-net.rules обнаружился в /run/udev: tmp-rules--70-persistent-net.rules. Получается, просто не скопировался в нужное место ? 145668 5 month.of.death 2014-03-11 20:59:51 +0400 udevadm trigger udevadm trigger --action=add Спасибо. Это помогло. 147521 6 shaba 2014-09-02 20:27:57 +0400 закрываю багу? 147527 7 mike 2014-09-02 22:09:33 +0400 (В ответ на комментарий №3) > почему action add не выполняется. Совершенно на всякий: если в kvm -- то может иметь значение то, что make-initrd этот случай понимает как тестирование и добавляет сетевые модули, т.е. они грузятся ещё из initrd и дальше уже никаких add, разумеется: http://lists.altlinux.org/pipermail/devel/2014-August/198968.html 147532 8 asy 2014-09-03 01:32:55 +0400 Не знаю пока, как в Сизифе, но с udev-rule-generator-net-201-alt1.M70P.4 проблема воспроизводится в p7. И что с комментарием N2 ? Оформить в виде отдельного бага с enhancement ? udev_log="debug" в udev.conf ничего интересного не дал увидеть: всё, что в логе появилось, связано только с vgchange. Или не только в messages смотреть надо ? 147534 9 shaba 2014-09-03 06:51:49 +0400 тогда надо перевесить на p7, что бы понимать о какой версии идет речь. 150492 10 rider 2015-02-28 11:31:28 +0300 Не создаётся при загрузке, но потом если вызвать udevad trigger -c add - всё создаётся. Какую отладку предоставить ? 150493 11 rider 2015-02-28 12:10:19 +0300 Судя по коду, когда udev получает ADD на сетевые устройства - /etc/udev/rules.d ещё не перемонтирован на запись, и это действительно так, по крайней мере в случае с rc.sysinit - udev стартует задолго (несколько миллисекунд) до перемонтирования корня в RW и за это время он успевает отработать ADD на сетевые устройства. Файл с рулезами в итоге образуется в /run/udev/ и его кто-то должен в конце загрузки скопировать в /etc/ По идее там ещё могут быть косяки с тем, что во время загрузки корень станет RW и часть данных будет записана в /etc/udev/rules.d, а часть в /run/udev Но я с таким не сталкивался. 150494 12 rider 2015-02-28 12:19:04 +0300 в других дистрибутивах упоминается некий udev-finish, который как раз и копирует всё что надо и куда надо. У нас такого нет. 151710 13 mike 2015-06-09 10:52:26 +0300 Повесил напоминалку к p8. 151800 14 rider 2015-06-16 18:21:22 +0300 *** Bug 30779 has been marked as a duplicate of this bug. *** 153783 15 mike 2015-11-17 13:54:06 +0300 2 rider: часом не смотрел про udev-finish с тех пор? На своих сборках такого будто не наблюдал, как бы воспроизвести... 153786 16 rider 2015-11-17 14:23:01 +0300 Нет, не смотрел. Посмотри. 153792 17 asy 2015-11-17 15:17:22 +0300 (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 есть только то, чего не хватает. 153952 18 asy 2015-11-27 10:00:41 +0300 (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" не работает. 155189 19 shaba 2016-02-20 14:52:26 +0300 День добрый. В тестовом задании [#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 ? 155190 20 shaba 2016-02-20 14:57:06 +0300 и еще в догонку, делать ли такое же копирование для systemd? сейчас вернул только под sysv. 155193 21 mike 2016-02-20 19:47:46 +0300 По триггерам документация в /usr/share/doc/rpm-4.0.4/manual/triggers -- сам её оттуда и перечитываю, но очень редко (сейчас голова не настолько ясная, чтоб триггеры писать). Также на всякий напоминаю просьбу по возможности не выкатывать существенные изменения под вторник-среду (регулярки), а вместо того пинать меня проверить сборочное задание; с #159059 исошку собираю, посмотрю. 155195 22 mike 2016-02-20 20:34:09 +0300 64-битная regular-lxde.iso с task#159059 собралась и загрузилась нормально (установилась и перезагрузилась тоже без происшествий). Могу выложить. 155196 23 rider 2016-02-20 20:39:03 +0300 Конечно и для systemd делать, если его планируем на сервера. 155613 24 shaba 2016-03-11 10:12:32 +0300 В #159059 новая сборка - можно с ней провериться. Особо обратить внимание на следующее: при установке udev сервис udevd-final не обязан быть включенным. А вот при установке его "клиентов", пакетов udev-rule-generator-cdrom или udev-rule-generator-net сервис udevd-final должен включаться. И финальный тест - если установлены udev-rule-generator-*, то после перезагрузки должны появиться файлики /etc/udev/rules.d/70-persistent-* тест интересует как при новой инсталяции, так и при обновлении. Я обновление у себя проверил - вроде все работает. Если претензий не будет, отправлю в таком виде в сизиф. 155619 25 mike 2016-03-11 11:46:46 +0300 Проверил; 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 155627 26 mike 2016-03-11 12:35:03 +0300 <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 155723 27 shaba 2016-03-15 10:02:36 +0300 udev-229-alt1 успешно добрался до сизифа. 156531 28 asy 2016-05-05 14:25:29 +0300 (In reply to comment #27) > udev-229-alt1 успешно добрался до сизифа. Да, работает. Сейчас уже udev-229-alt5 udev-rule-generator-net-229-alt5 157179 29 asy 2016-06-02 13:39:03 +0300 (In reply to comment #2) > В дополнение к http://bugzilla.altlinux.org/28955#c28 > > Может, сделать настраиваемый вариант шаблона имён ? Скажем, чтобы не ethX можно > было задать, а etherX http://bugzilla.altlinux.org/32167 189326 30 asy 2020-04-19 13:26:00 +0300 (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. Может так и поступить? 189327 31 asy 2020-04-19 15:13:45 +0300 (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. 189329 32 rider 2020-04-19 18:36:42 +0300 не может ли быть такого, что на момент попытки генерации правил tmpfs в /run ещё не смонтирован ? Добавлять повторный запуск по устройствам - идея выглядит так себе если честно. 189334 33 asy 2020-04-20 09:54:52 +0300 (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 после. 189352 34 asy 2020-04-20 13:31:08 +0300 (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 не повредит на всякий случай. 189354 35 asy 2020-04-20 13:32:55 +0300 (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 189368 36 asy 2020-04-20 21:11:59 +0300 Вариант починки (отключаемый) через 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 написал. 189386 37 asy 2020-04-21 16:29:31 +0300 Ещё одно наблюдение нашлось: persistent-net.rules создаётся в p9 с systemd. Но тут речь про десктоп с KDE5, так что может просто что-то ещё такое стоит кроме systemd. 189399 38 asy 2020-04-22 01:00:05 +0300 (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. Какой-то патч в Сизифе убрали, или не то место нашёл? 189582 39 repository-robot 2020-04-30 10:26:32 +0300 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) 189609 40 asy 2020-05-01 01:27:08 +0300 (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. 201805 41 shaba 2021-08-18 14:46:09 +0300 багу можно закрывать? 201807 42 asy 2021-08-18 15:21:55 +0300 (In reply to Alexey Shabalin from comment #41) > багу можно закрывать? Так она не исправлена же. В стороннем пакете сделаны действия для обхода проблемы. 201816 43 shaba 2021-08-18 16:57:10 +0300 rule-generator сторонний пакет, в нем можно делать что нужно. 233285 44 asy 2023-09-15 15:10:43 +0300 #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