При установке 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.
Что значит «назначалось»? Привязка к 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 у этой задачи появится новое решение Оооох. А работающее старое эти гигантские дятлы расклевали?
