Bug 24339 - Логика назначения сетевых интерфейсов при установке и в установленной системе различается
: Логика назначения сетевых интерфейсов при установке и в установленной системе...
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/udev-rule-generator)
: unstable
: x86 Linux
: P3 normal
Assigned To:
:
:
:
:
: 27685
  Show dependency tree
 
Reported: 2010-10-17 12:04 by
Modified: 2013-01-08 18:43 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-10-17 12:04:07
При установке
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 From 2010-10-17 13:12:57 -------
Что значит «назначалось»? Привязка к MAC-адресам осуществляется в файле
/etc/udev/rules.d/70-persistent-net.rules, который создаётся автоматически при
первом запуске системы.
------- Comment #2 From 2010-10-17 13:29:47 -------
(В ответ на комментарий №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 From 2010-10-18 14:49:04 -------
видимо устновщик не копирует /etc/udev/rules.d/70-persistent-net.rules в
устанавливаемую систему (если он там вообще создается). а без
70-persistent-net.rules интерфейсы имеют полное право меняться местами
------- Comment #4 From 2010-10-18 16:09:42 -------
(В ответ на комментарий №3)
> видимо устновщик не копирует /etc/udev/rules.d/70-persistent-net.rules в
Да. В следующе бете будет исправлено.
------- Comment #5 From 2012-03-10 17:26:27 -------
Это не альтератор, а или модуль настройки, или инсталер.

В 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 From 2012-08-09 12:37:29 -------
в последнем altlinux-6.0.2_RC2-20120731-kdesktop-x86_64-ru-install-dvd5.iso -
файл 70-persistent-net.rules во время инсталяции не создаётся и соответсвенно
не переносится в систему.
------- Comment #7 From 2012-08-09 15:00:09 -------
Недавно заметил при установке чего-то свежесобранного из t6/sisyphus (точнее
сейчас не помню, надо проверять), что 70-persistent-net.rules не создаётся
вообще.

Сходу проблему не отловил, по крайней мере /lib/udev/write_net_rules был на
месте.
------- Comment #8 From 2012-08-09 15:12:11 -------
(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 From 2012-08-09 15:19:52 -------
Спасибо; его предполагается чинить?  Как понимаю, это p7 blocker.
------- Comment #10 From 2012-08-09 18:47:28 -------
(В ответ на комментарий №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 From 2012-08-09 21:24:38 -------
(In reply to comment #10)
>         UDEV_VERSION="$(udevd --version)"
Как вариант -- фиксировать при сборке и соответственно
Requires: udev >= %{get_version udev}

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

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

/lib/udev/write_net_rules работает, если его запустить руками с правильными
параметрами, но сам не запускается, ни в среде установщика, ни в установленной
системе.
------- Comment #19 From 2012-11-19 15:28:17 -------
(В ответ на комментарий №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 From 2012-11-19 16:24:07 -------
> Только что проверил - удалил /etc/udev/rules.d/70-persistent-net.rules,
> перегрузился, /etc/udev/rules.d/70-persistent-net.rules создался заново.
> Так что вижу что в установленной системе работает.
Хмм.. У меня, как оказалось, на рабочей машине тоже работает.

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

Прошу прощения за ложный вызов.
------- Comment #22 From 2012-11-19 17:52:19 -------
Сегодняшний Сизиф. Удалил /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 From 2012-11-19 17:54:42 -------
> А вот правила игнорирования со времен p6 изменились, теперь игнорируется ещё и 
> ?[2367abef]:* , что объясняет все известные мне случаи неработы.
Изменение mac адреса на неигнорируемый привело к следующему:
команда 
udevadm --debug test --action=add /sys/class/net/eth0
фай
------- Comment #24 From 2012-11-19 17:58:26 -------
> А вот правила игнорирования со времен p6 изменились, теперь игнорируется ещё и 
> ?[2367abef]:* , что объясняет все известные мне случаи неработы.
Изменение mac адреса на неигнорируемый привело к следующему:
команда 
udevadm --debug test --action=add /sys/class/net/eth0
файл заводит, если удалить и перезагрузиться -- файл не появляется.
Аналогично тому, как у Гоши на железе.

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

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

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

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

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