Bug 24339

Summary: Логика назначения сетевых интерфейсов при установке и в установленной системе различается
Product: Sisyphus Reporter: Valentin Lutt <lutt>
Component: udev-rule-generatorAssignee: Sergey Y. Afonin <asy>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: normal    
Priority: P3 CC: ab, aen, amike, asy, boyarsh, cas, evg, george, inger, kharpost, ldv, mike, rider, shaba, vitty, vsu, zerg
Version: unstable   
Hardware: x86   
OS: Linux   
Bug Depends on:    
Bug Blocks: 27685    

Description Valentin Lutt 2010-10-17 12:04:07 MSD
При установке desktop-kde4/altlinux-6.0.0_beta-20101015-kdesktop-i586-ru-install-dvd5.iso встроенной сетевой карте nVidia Corporation MCP77 Ethernet назначается eth0, а дополнительной Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ - eth1. После установки и перезапуска интерфейсы меняются местами, т.е. встроенная становится eth1, а дополнительная eth0, но назначенные IP адреса остаются за логическими интерфейсами, а не картами. Сетевая подсистема выбиралась NetworkManager.
Comment 1 Andrey Cherepanov 2010-10-17 13:12:57 MSD
Что значит «назначалось»? Привязка к MAC-адресам осуществляется в файле /etc/udev/rules.d/70-persistent-net.rules, который создаётся автоматически при первом запуске системы.
Comment 2 Valentin Lutt 2010-10-17 13:29:47 MSD
(В ответ на комментарий №1)
> Что значит «назначалось»?
Это значит что при установке системы я вижу
Интерфейс eth0 Сетевая карта: nVidia Corporation MCP77 Ethernet,
прописываю туда свой внутренний IP, перехожу на eth1, вижу там Сетевая карта: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+, соответственно прописываю внешний, завершаю установку, перезагружаю систему, инета нету. Иду в альтератор и вижу там eth0, сетевая карта Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ и мой внутренний IP, ну а на набортной соответственно внешний IP висит.
Исправляю это безобразие и после этого оно уже ничего не меняет, во всяком случае пока, после где-то 5-ти перезапусков.
Comment 3 Valery Inozemtsev 2010-10-18 14:49:04 MSD
видимо устновщик не копирует /etc/udev/rules.d/70-persistent-net.rules в устанавливаемую систему (если он там вообще создается). а без 70-persistent-net.rules интерфейсы имеют полное право меняться местами
Comment 4 Sergey V Turchin 2010-10-18 16:09:42 MSD
(В ответ на комментарий №3)
> видимо устновщик не копирует /etc/udev/rules.d/70-persistent-net.rules в
Да. В следующе бете будет исправлено.
Comment 5 Michael Shigorin 2012-03-10 17:26:27 MSK
Это не альтератор, а или модуль настройки, или инсталер.

В installer-feature-ltsp сделал так (не помню уже -- не уверен, что /etc/udev/rules.d/70-persistent-net.rules был на месте к моменту запуска скрипта, чтоб просто его скопировать... надо бы перепроверить):
http://git.altlinux.org/people/mike/packages/?p=installer-feature-ltsp.git;a=blob;f=installer-feature-ltsp/preinstall.d/98-eth;h=ac2d42bf058a931ceb497979947b277a398e7f4e;hb=bae2e50af906ef01c0afacd8fd5af6003e88a425#l30
Comment 6 Mike 2012-08-09 12:37:29 MSK
в последнем altlinux-6.0.2_RC2-20120731-kdesktop-x86_64-ru-install-dvd5.iso - файл 70-persistent-net.rules во время инсталяции не создаётся и соответсвенно не переносится в систему.
Comment 7 Michael Shigorin 2012-08-09 15:00:09 MSK
Недавно заметил при установке чего-то свежесобранного из t6/sisyphus (точнее сейчас не помню, надо проверять), что 70-persistent-net.rules не создаётся вообще.

Сходу проблему не отловил, по крайней мере /lib/udev/write_net_rules был на месте.
Comment 8 Dmitry V. Levin 2012-08-09 15:12:11 MSK
(In reply to comment #7)
> Недавно заметил при установке чего-то свежесобранного из t6/sisyphus (точнее
> сейчас не помню, надо проверять), что 70-persistent-net.rules не создаётся
> вообще.
> 
> Сходу проблему не отловил, по крайней мере /lib/udev/write_net_rules был на
> месте.

Это sisyphus-only, после переезда udev в systemd перестал функционировать udev-rule-generator.
Comment 9 Michael Shigorin 2012-08-09 15:19:52 MSK
Спасибо; его предполагается чинить?  Как понимаю, это p7 blocker.
Comment 10 Alexey Shabalin 2012-08-09 18:47:28 MSK
(В ответ на комментарий №9)
> Спасибо; его предполагается чинить?  Как понимаю, это p7 blocker.

Я нашёл ошибку.
в rule_generator.functions использовалось
        RUNDIR=$(udevadm info --run)
--run больше нет такой опции.
Хотел сделать проверку версии, типа 

        RUNDIR='/run/udev'
        UDEV_VERSION="$(udevd --version)"
        [ "${UDEV_VERSION:-0}" -gt 185 ] || RUNDIR=$(udevadm info --run)

но почему-то не работает, может udevd не может вызвать udevd --version?
так что оставлю только 
        RUNDIR='/run/udev'
Comment 11 Michael Shigorin 2012-08-09 21:24:38 MSK
(In reply to comment #10)
>         UDEV_VERSION="$(udevd --version)"
Как вариант -- фиксировать при сборке и соответственно
Requires: udev >= %{get_version udev}

> --run больше нет такой опции.
Апстриму очередная антимедаль за причинение неудобств всем, кто не в ногу.
Comment 12 Alexey Shabalin 2012-10-17 13:48:47 MSK
в сизифе исправлено с версии 188-alt1
Comment 13 Anton V. Boyarshinov 2012-10-17 14:21:43 MSK
К сожалению, не подтверждаю (опять сломалось?)
Вчерашний Сизиф, пакет udev-rule-generator стоит.
Впрочем..
Есть мнение, что в среде установщика создание 70-persistent-rules не происходит потому, что события из ядра приходят ещё во время работы initrd, где, разумеется, отсутствует udev-rule-generator
Можно, конечно, попробовать класть его тоже в initrd и потом вытаскивать получившиеся правила в систему, но как-то это всё криво, нельзя ли как-то сделать "как было"?
Comment 14 Alexey Shabalin 2012-10-17 15:49:18 MSK
не уверен, но может это как-то связано:
у нас initrd после окончания работы удаляет за собой базу udev.
правильно ли потом запускается udev?
должно запускаться
bindir@/udevadm trigger --type=subsystems ; @bindir@/udevadm trigger --type=devices
без --action=add
Comment 15 Anton V. Boyarshinov 2012-10-23 15:11:50 MSK
(В ответ на комментарий №14)
> не уверен, но может это как-то связано:
> у нас initrd после окончания работы удаляет за собой базу udev.
> правильно ли потом запускается udev?
> должно запускаться
> bindir@/udevadm trigger --type=subsystems ; @bindir@/udevadm trigger
> --type=devices
> без --action=add
Ну, он запускается через service udev start
В инитскрипте я с ходу такого не обнаружил (используется только 
udevadm trigger без дополнительных параметров)
Comment 16 AEN 2012-11-18 07:33:03 MSK
2shaba@: ping
Comment 17 Alexey Shabalin 2012-11-19 13:34:28 MSK
(В ответ на комментарий №16)
> 2shaba@: ping

?
/lib/udev/write_net_rules работает, 70-persistent-net.rules создаётся.
Comment 18 Anton V. Boyarshinov 2012-11-19 15:09:38 MSK
> /lib/udev/write_net_rules работает, 70-persistent-net.rules создаётся.

/lib/udev/write_net_rules работает, если его запустить руками с правильными параметрами, но сам не запускается, ни в среде установщика, ни в установленной системе.
Comment 19 Alexey Shabalin 2012-11-19 15:28:17 MSK
(В ответ на комментарий №18)
> > /lib/udev/write_net_rules работает, 70-persistent-net.rules создаётся.
> 
> /lib/udev/write_net_rules работает, если его запустить руками с правильными
> параметрами, но сам не запускается, ни в среде установщика, ни в установленной
> системе.

Только что проверил - удалил /etc/udev/rules.d/70-persistent-net.rules, перегрузился, /etc/udev/rules.d/70-persistent-net.rules создался заново.
Так что вижу что в установленной системе работает.
Comment 20 Anton V. Boyarshinov 2012-11-19 16:24:07 MSK
> Только что проверил - удалил /etc/udev/rules.d/70-persistent-net.rules,
> перегрузился, /etc/udev/rules.d/70-persistent-net.rules создался заново.
> Так что вижу что в установленной системе работает.
Хмм.. У меня, как оказалось, на рабочей машине тоже работает.

А вот на свежеустановленных (в основном в виртуалках, но mac адреса у них стоят такие, что НЕ игнорируются правилом создания правил, но и на железе тоже, хотя вот прямо сейчас на железе не проверял) почему-то не работает..
Пошёл искать 10 отличий :( Найду -- напишу..
Comment 21 Anton V. Boyarshinov 2012-11-19 17:41:12 MSK
> такие, что НЕ игнорируются правилом создания правил, но и на железе тоже, хотя
> вот прямо сейчас на железе не проверял) почему-то не работает..
> Пошёл искать 10 отличий :( Найду -- напишу..
А вот правила игнорирования со времен p6 изменились, теперь игнорируется ещё и 
?[2367abef]:* , что объясняет все известные мне случаи неработы.

Прошу прощения за ложный вызов.
Comment 22 Fr. Br. George 2012-11-19 17:52:19 MSK
Сегодняшний Сизиф. Удалил /etc/udev/rules.d/70-persistent-net.rules,
перезагрузился. Файл не создаётся. rpmverify udev-rule-generator молчит.

Командой udevadm --debug test --action=add /sys/class/net/eth0 файл заводится

Карточки самые обычные
root@grail:/home/george> ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 1000
    link/ether 00:e0:4c:06:03:2b brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 00:17:31:70:a9:09 brd ff:ff:ff:ff:ff:ff
Comment 23 Anton V. Boyarshinov 2012-11-19 17:54:42 MSK
> А вот правила игнорирования со времен p6 изменились, теперь игнорируется ещё и 
> ?[2367abef]:* , что объясняет все известные мне случаи неработы.
Изменение mac адреса на неигнорируемый привело к следующему:
команда 
udevadm --debug test --action=add /sys/class/net/eth0
фай
Comment 24 Anton V. Boyarshinov 2012-11-19 17:58:26 MSK
> А вот правила игнорирования со времен p6 изменились, теперь игнорируется ещё и 
> ?[2367abef]:* , что объясняет все известные мне случаи неработы.
Изменение mac адреса на неигнорируемый привело к следующему:
команда 
udevadm --debug test --action=add /sys/class/net/eth0
файл заводит, если удалить и перезагрузиться -- файл не появляется.
Аналогично тому, как у Гоши на железе.

Я выложил свежий кентавр в people/boyarsh (появится через пару часов) - в нём воспроизводится как из пушки :(
Comment 25 Alexey Shabalin 2012-11-19 21:35:00 MSK
(В ответ на комментарий №21)
> > такие, что НЕ игнорируются правилом создания правил, но и на железе тоже, хотя
> > вот прямо сейчас на железе не проверял) почему-то не работает..
> > Пошёл искать 10 отличий :( Найду -- напишу..
> А вот правила игнорирования со времен p6 изменились, теперь игнорируется ещё и 
> ?[2367abef]:* , что объясняет все известные мне случаи неработы.
> 
А где находится этот фильтр?

> Прошу прощения за ложный вызов.
Comment 26 Anton V. Boyarshinov 2012-11-20 13:33:41 MSK
 
> А где находится этот фильтр?
в /lib/udev/rules.d/75-persistent-net-generator.rules

Но даже с mac адресами, не попадающими под этот фильтр, на свежеустановленных системах при перезагрузке файл с правилами не порождается.
Comment 27 Anton V. Boyarshinov 2012-11-20 15:12:03 MSK
Вообще ничего не понимаю -- поставил сегодня в ту же виртуальную машину, что и вчера, свежую систему -- файл создался..
Comment 28 AEN 2012-11-28 02:24:48 MSK
(В ответ на комментарий №27)
> Вообще ничего не понимаю -- поставил сегодня в ту же виртуальную машину, что и
> вчера, свежую систему -- файл создался..

А сегодня как?
Comment 29 Anton V. Boyarshinov 2012-11-29 15:46:51 MSK
(В ответ на комментарий №28)
> (В ответ на комментарий №27)
> > Вообще ничего не понимаю -- поставил сегодня в ту же виртуальную машину, что и
> > вчера, свежую систему -- файл создался..
> 
> А сегодня как?

Как-то оно через раз. Вот сегодня файл создался, но, похоже, только при первой загрузке и, соответственно, интерфейсы переставились по сравнению с установщиком..
Comment 30 Anton V. Boyarshinov 2012-12-07 13:55:31 MSK
похоже, что исправлено в installer 1.7.11-alt1
Comment 31 Dmitry V. Levin 2013-01-08 16:35:41 MSK
С приходом udev >= 197 у этой задачи появится новое решение, см.
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Comment 32 Michael Shigorin 2013-01-08 18:43:25 MSK
(In reply to comment #31)
> С приходом udev >= 197 у этой задачи появится новое решение
Оооох.  А работающее старое эти гигантские дятлы расклевали?