Пожалуйста, включите 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