Bug 24339

Что значит «назначалось»? Привязка к MAC-адресам осуществляется в файле /etc/udev/rules.d/70-persistent-net.rules, который создаётся автоматически при первом запуске системы.

(В ответ на комментарий №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-ти перезапусков.

видимо устновщик не копирует /etc/udev/rules.d/70-persistent-net.rules в устанавливаемую систему (если он там вообще создается). а без 70-persistent-net.rules интерфейсы имеют полное право меняться местами

(В ответ на комментарий №3)
> видимо устновщик не копирует /etc/udev/rules.d/70-persistent-net.rules в
Да. В следующе бете будет исправлено.

Это не альтератор, а или модуль настройки, или инсталер.

В 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

в последнем altlinux-6.0.2_RC2-20120731-kdesktop-x86_64-ru-install-dvd5.iso - файл 70-persistent-net.rules во время инсталяции не создаётся и соответсвенно не переносится в систему.

Недавно заметил при установке чего-то свежесобранного из t6/sisyphus (точнее сейчас не помню, надо проверять), что 70-persistent-net.rules не создаётся вообще.

Сходу проблему не отловил, по крайней мере /lib/udev/write_net_rules был на месте.

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

Это sisyphus-only, после переезда udev в systemd перестал функционировать udev-rule-generator.

Спасибо; его предполагается чинить?  Как понимаю, это p7 blocker.

(В ответ на комментарий №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'

(In reply to comment #10)
>         UDEV_VERSION="$(udevd --version)"
Как вариант -- фиксировать при сборке и соответственно
Requires: udev >= %{get_version udev}

> --run больше нет такой опции.
Апстриму очередная антимедаль за причинение неудобств всем, кто не в ногу.

в сизифе исправлено с версии 188-alt1

К сожалению, не подтверждаю (опять сломалось?)
Вчерашний Сизиф, пакет udev-rule-generator стоит.
Впрочем..
Есть мнение, что в среде установщика создание 70-persistent-rules не происходит потому, что события из ядра приходят ещё во время работы initrd, где, разумеется, отсутствует udev-rule-generator
Можно, конечно, попробовать класть его тоже в initrd и потом вытаскивать получившиеся правила в систему, но как-то это всё криво, нельзя ли как-то сделать "как было"?

не уверен, но может это как-то связано:
у нас initrd после окончания работы удаляет за собой базу udev.
правильно ли потом запускается udev?
должно запускаться
bindir@/udevadm trigger --type=subsystems ; @bindir@/udevadm trigger --type=devices
без --action=add

(В ответ на комментарий №14)
> не уверен, но может это как-то связано:
> у нас initrd после окончания работы удаляет за собой базу udev.
> правильно ли потом запускается udev?
> должно запускаться
> bindir@/udevadm trigger --type=subsystems ; @bindir@/udevadm trigger
> --type=devices
> без --action=add
Ну, он запускается через service udev start
В инитскрипте я с ходу такого не обнаружил (используется только 
udevadm trigger без дополнительных параметров)

2shaba@: ping

(В ответ на комментарий №16)
> 2shaba@: ping

?
/lib/udev/write_net_rules работает, 70-persistent-net.rules создаётся.

> /lib/udev/write_net_rules работает, 70-persistent-net.rules создаётся.

/lib/udev/write_net_rules работает, если его запустить руками с правильными параметрами, но сам не запускается, ни в среде установщика, ни в установленной системе.

(В ответ на комментарий №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 создался заново.
Так что вижу что в установленной системе работает.

> Только что проверил - удалил /etc/udev/rules.d/70-persistent-net.rules,
> перегрузился, /etc/udev/rules.d/70-persistent-net.rules создался заново.
> Так что вижу что в установленной системе работает.
Хмм.. У меня, как оказалось, на рабочей машине тоже работает.

А вот на свежеустановленных (в основном в виртуалках, но mac адреса у них стоят такие, что НЕ игнорируются правилом создания правил, но и на железе тоже, хотя вот прямо сейчас на железе не проверял) почему-то не работает..
Пошёл искать 10 отличий :( Найду -- напишу..

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

Прошу прощения за ложный вызов.

Сегодняшний Сизиф. Удалил /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

> А вот правила игнорирования со времен p6 изменились, теперь игнорируется ещё и 
> ?[2367abef]:* , что объясняет все известные мне случаи неработы.
Изменение mac адреса на неигнорируемый привело к следующему:
команда 
udevadm --debug test --action=add /sys/class/net/eth0
фай

> А вот правила игнорирования со времен p6 изменились, теперь игнорируется ещё и 
> ?[2367abef]:* , что объясняет все известные мне случаи неработы.
Изменение mac адреса на неигнорируемый привело к следующему:
команда 
udevadm --debug test --action=add /sys/class/net/eth0
файл заводит, если удалить и перезагрузиться -- файл не появляется.
Аналогично тому, как у Гоши на железе.

Я выложил свежий кентавр в people/boyarsh (появится через пару часов) - в нём воспроизводится как из пушки :(

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

> Прошу прощения за ложный вызов.

 
> А где находится этот фильтр?
в /lib/udev/rules.d/75-persistent-net-generator.rules

Но даже с mac адресами, не попадающими под этот фильтр, на свежеустановленных системах при перезагрузке файл с правилами не порождается.

Вообще ничего не понимаю -- поставил сегодня в ту же виртуальную машину, что и вчера, свежую систему -- файл создался..

(В ответ на комментарий №27)
> Вообще ничего не понимаю -- поставил сегодня в ту же виртуальную машину, что и
> вчера, свежую систему -- файл создался..

А сегодня как?

(В ответ на комментарий №28)
> (В ответ на комментарий №27)
> > Вообще ничего не понимаю -- поставил сегодня в ту же виртуальную машину, что и
> > вчера, свежую систему -- файл создался..
> 
> А сегодня как?

Как-то оно через раз. Вот сегодня файл создался, но, похоже, только при первой загрузке и, соответственно, интерфейсы переставились по сравнению с установщиком..

похоже, что исправлено в installer 1.7.11-alt1

С приходом udev >= 197 у этой задачи появится новое решение, см.
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

(In reply to comment #31)
> С приходом udev >= 197 у этой задачи появится новое решение
Оооох.  А работающее старое эти гигантские дятлы расклевали?