Bug 29282 - Не создаёт persistent-net.rules
Summary: Не создаёт persistent-net.rules
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: udev (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL:
Keywords:
: 30779 (view as bug list)
Depends on:
Blocks: 30940
  Show dependency tree
 
Reported: 2013-08-14 14:43 MSK by Sergey Y. Afonin
Modified: 2023-09-15 15:10 MSK (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Y. Afonin 2013-08-14 14:43:04 MSK
На сколько я понимаю, создание persistent-net.rules - основная задача пакета ?
206-alt1 и 201-alt1.M70P.1 этого не делают почему-то.
Comment 1 Alexey Shabalin 2013-08-14 14:46:17 MSK
Пожалуйста, включите debug в udev, и пришлите логи.
Comment 2 Sergey Y. Afonin 2013-08-14 14:54:36 MSK
В дополнение к http://bugzilla.altlinux.org/28955#c28

Может, сделать настраиваемый вариант шаблона имён ? Скажем, чтобы не ethX можно было задать, а etherX

С логами сейчас сложно, эту систему уже в работу поставил. На днях попробую ещё раз на стенде поставить и посмотреть.
Comment 3 Sergey Y. Afonin 2013-09-20 00:45:19 MSK
Алексей подсказал набор команд:

udevadm trigger
udevadm trigger --action=add

После этого persistent-net.rules создаётся. Видимо, надо перевешивать на сам udev и разбираться, почему action add не выполняется.
Comment 4 Sergey Y. Afonin 2013-10-21 10:51:22 MSK
70-persistent-net.rules обнаружился в /run/udev: tmp-rules--70-persistent-net.rules. Получается, просто не скопировался в нужное место ?
Comment 5 Cool_Lamer 2014-03-11 20:59:51 MSK
udevadm trigger
udevadm trigger --action=add

Спасибо. Это помогло.
Comment 6 Alexey Shabalin 2014-09-02 20:27:57 MSK
закрываю багу?
Comment 7 Michael Shigorin 2014-09-02 22:09:33 MSK
(В ответ на комментарий №3)
> почему action add не выполняется.
Совершенно на всякий: если в kvm -- то может иметь значение то, что make-initrd этот случай понимает как тестирование и добавляет сетевые модули, т.е. они грузятся ещё из initrd и дальше уже никаких add, разумеется: http://lists.altlinux.org/pipermail/devel/2014-August/198968.html
Comment 8 Sergey Y. Afonin 2014-09-03 01:32:55 MSK
Не знаю пока, как в Сизифе, но с udev-rule-generator-net-201-alt1.M70P.4 проблема воспроизводится в p7. И что с комментарием N2 ? Оформить в виде отдельного бага с enhancement ? udev_log="debug" в udev.conf ничего интересного не дал увидеть: всё, что в логе появилось, связано только с vgchange. Или не только в messages смотреть надо ?
Comment 9 Alexey Shabalin 2014-09-03 06:51:49 MSK
тогда надо перевесить на p7, что бы понимать о какой версии идет речь.
Comment 10 Anton Farygin 2015-02-28 11:31:28 MSK
Не создаётся при загрузке, но потом если вызвать udevad trigger -c add - всё создаётся.

Какую отладку предоставить ?
Comment 11 Anton Farygin 2015-02-28 12:10:19 MSK
Судя по коду, когда udev получает ADD на сетевые устройства - /etc/udev/rules.d ещё не перемонтирован на запись, и это действительно так, по крайней мере в случае с rc.sysinit - udev стартует задолго (несколько миллисекунд) до перемонтирования корня в RW и за это время он успевает отработать ADD на сетевые устройства.

Файл с рулезами в итоге образуется в /run/udev/ и его кто-то должен в конце загрузки скопировать в /etc/

По идее там ещё могут быть косяки с тем, что во время загрузки корень станет RW и часть данных будет записана в /etc/udev/rules.d, а часть в /run/udev
Но я с таким не сталкивался.
Comment 12 Anton Farygin 2015-02-28 12:19:04 MSK
в других дистрибутивах упоминается некий udev-finish, который как раз и копирует всё что надо и куда надо.

У нас такого нет.
Comment 13 Michael Shigorin 2015-06-09 10:52:26 MSK
Повесил напоминалку к p8.
Comment 14 Anton Farygin 2015-06-16 18:21:22 MSK
*** Bug 30779 has been marked as a duplicate of this bug. ***
Comment 15 Michael Shigorin 2015-11-17 13:54:06 MSK
2 rider: часом не смотрел про udev-finish с тех пор?
На своих сборках такого будто не наблюдал, как бы воспроизвести...
Comment 16 Anton Farygin 2015-11-17 14:23:01 MSK
Нет, не смотрел.

Посмотри.
Comment 17 Sergey Y. Afonin 2015-11-17 15:17:22 MSK
(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 есть только то, чего не хватает.
Comment 18 Sergey Y. Afonin 2015-11-27 10:00:41 MSK
(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" не работает.
Comment 19 Alexey Shabalin 2016-02-20 14:52:26 MSK
День добрый.
В тестовом задании [#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 ?
Comment 20 Alexey Shabalin 2016-02-20 14:57:06 MSK
и еще в догонку, делать ли такое же копирование для systemd? сейчас вернул только под sysv.
Comment 21 Michael Shigorin 2016-02-20 19:47:46 MSK
По триггерам документация в /usr/share/doc/rpm-4.0.4/manual/triggers -- сам её оттуда и перечитываю, но очень редко (сейчас голова не настолько ясная, чтоб триггеры писать).

Также на всякий напоминаю просьбу по возможности не выкатывать существенные изменения под вторник-среду (регулярки), а вместо того пинать меня проверить сборочное задание; с #159059 исошку собираю, посмотрю.
Comment 22 Michael Shigorin 2016-02-20 20:34:09 MSK
64-битная regular-lxde.iso с task#159059 собралась и загрузилась нормально
(установилась и перезагрузилась тоже без происшествий).  Могу выложить.
Comment 23 Anton Farygin 2016-02-20 20:39:03 MSK
Конечно и для systemd делать, если его планируем на сервера.
Comment 24 Alexey Shabalin 2016-03-11 10:12:32 MSK
В #159059 новая сборка - можно с ней провериться.  Особо обратить внимание на следующее: при установке udev сервис udevd-final  не обязан быть включенным. А вот при установке его "клиентов", пакетов udev-rule-generator-cdrom или udev-rule-generator-net сервис udevd-final должен включаться. И финальный тест - если установлены udev-rule-generator-*, то после перезагрузки должны появиться файлики /etc/udev/rules.d/70-persistent-*
тест интересует как при новой инсталяции, так и при обновлении. Я обновление у себя проверил - вроде все работает.
Если претензий не будет, отправлю в таком виде в сизиф.
Comment 25 Michael Shigorin 2016-03-11 11:46:46 MSK
Проверил;
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
Comment 26 Michael Shigorin 2016-03-11 12:35:03 MSK
<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
Comment 27 Alexey Shabalin 2016-03-15 10:02:36 MSK
udev-229-alt1 успешно добрался до сизифа.
Comment 28 Sergey Y. Afonin 2016-05-05 14:25:29 MSK
(In reply to comment #27)

> udev-229-alt1 успешно добрался до сизифа.

Да, работает. Сейчас уже

udev-229-alt5
udev-rule-generator-net-229-alt5
Comment 29 Sergey Y. Afonin 2016-06-02 13:39:03 MSK
(In reply to comment #2)

> В дополнение к http://bugzilla.altlinux.org/28955#c28
> 
> Может, сделать настраиваемый вариант шаблона имён ? Скажем, чтобы не ethX можно
> было задать, а etherX

http://bugzilla.altlinux.org/32167
Comment 30 Sergey Y. Afonin 2020-04-19 13:26:00 MSK
(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. Может так и поступить?
Comment 31 Sergey Y. Afonin 2020-04-19 15:13:45 MSK
(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.
Comment 32 Anton Farygin 2020-04-19 18:36:42 MSK
не может ли быть такого, что на момент попытки генерации правил tmpfs в /run ещё не смонтирован ?

Добавлять повторный запуск по устройствам - идея выглядит так себе если честно.
Comment 33 Sergey Y. Afonin 2020-04-20 09:54:52 MSK
(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 после.
Comment 34 Sergey Y. Afonin 2020-04-20 13:31:08 MSK
(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 не повредит на всякий случай.
Comment 35 Sergey Y. Afonin 2020-04-20 13:32:55 MSK
(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
Comment 36 Sergey Y. Afonin 2020-04-20 21:11:59 MSK
Вариант починки (отключаемый) через 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 написал.
Comment 37 Sergey Y. Afonin 2020-04-21 16:29:31 MSK
Ещё одно наблюдение нашлось: persistent-net.rules создаётся в p9 с systemd. Но тут речь про десктоп с KDE5, так что может просто что-то ещё такое стоит кроме systemd.
Comment 38 Sergey Y. Afonin 2020-04-22 01:00:05 MSK
(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. Какой-то патч в Сизифе убрали, или не то место нашёл?
Comment 39 Repository Robot 2020-04-30 10:26:32 MSK
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)
Comment 40 Sergey Y. Afonin 2020-05-01 01:27:08 MSK
(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.
Comment 41 Alexey Shabalin 2021-08-18 14:46:09 MSK
багу можно закрывать?
Comment 42 Sergey Y. Afonin 2021-08-18 15:21:55 MSK
(In reply to Alexey Shabalin from comment #41)

> багу можно закрывать?

Так она не исправлена же. В стороннем пакете сделаны действия для обхода проблемы.
Comment 43 Alexey Shabalin 2021-08-18 16:57:10 MSK
rule-generator сторонний пакет, в нем можно делать что нужно.
Comment 44 Sergey Y. Afonin 2023-09-15 15:10:43 MSK
#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