После установки starterkit altlinux-p7-kde4-20130428-x86_64.iso и получения всех обновлений на ноутбуке имеющем два сетевых интерфейса - проводной и безпроводной, при перезагрузках ОС наблюдается нестабильность именования интерфейсов. Иногда проводной получает именование eth0 а беспроводной eth1, иногда - наоборот. Обсуждение в форуме: http://forum.altlinux.org/index.php/topic,29155.0.html
Created attachment 5821 [details] dmesg при ожидаемом назначении имён интерфейсов dmesg при ожидаемом назначении имён интерфейсов. eth0 - проводной, eth1 - безпроводной. Точно так, как описано в автоматически сгенерированном 70-persistent-net.rules
Created attachment 5822 [details] dmesg при неправильном назначении имён интерфейсов Теперь eth0 - безпроводной интерфейс, eth1 - проводной. Возможно-ли, что интерфейсы перепутываются в результате выполнения make-initrd?
Created attachment 5823 [details] Вариант журнала с явным переименованием интерфейсов В 70-persistent-net.rules назначил именем безпроводного интерфейса wlan0. Теперь systemd-udevd рапортует о переименовании инерфейсов.
Проверьте на всякий, нет ли в initrd модулей для этих интерфейсов (распаковывается в пустом каталоге: zcat /boot/initrd.img | cpio -id). Просьба текстовым приложениям назначать тип text/plain :)
А, это broadcom до сих пор по умолчанию eth* заводит вместо wlan*... Спасибо, постараюсь воспроизвести на двух просто ethernet.
(В ответ на комментарий №4) > Проверьте на всякий, нет ли в initrd модулей для этих интерфейсов > (распаковывается в пустом каталоге: zcat /boot/initrd.img | cpio -id). нет, ни r8168.ko ни wl.ko в initrd нет.
Замеченная разница между dmesg-with-{success,failure} -- в порядке загрузки модулей wl и r8168 (не завершения инициализации интерфейсов, а именно загрузки): [ 7.636033] eth%d: RTL8168D/8111D at 0xffffc9000065e000, f0:4d:a2:4b:8a:31, IRQ 47 [ 7.750142] wl: module license 'unspecified' taints kernel. vs [ 7.836606] wl: module license 'unspecified' taints kernel. [ 7.837755] eth%d: RTL8168D/8111D at 0xffffc90000660000, f0:4d:a2:4b:8a:31, IRQ 47 Переименование происходит только в dmesg-with-wlan0, действительно: [ 8.116133] systemd-udevd[688]: renamed network interface eth0 to wlan0 А вот такие строчки можно игнорировать, это отзвук удаления пакетов livecd-* в конце работы livecd-install: systemd[1]: Cannot add dependency job for unit livecd-net-eth.service, ... У меня пока не получается воспроизвести проблему на EeePC 901 с добавленным к набортным eth/wlan-интерфейсам (atl1e и rt2800pci) ещё и USB Ethernet (asix), загруженном в режиме сохранения сессии с флэшки с altlinux-p7-mate-20130426-i586.iso -- именование устойчиво воспроизводится и при разном порядке следования интерфейсов. Сделал rmmod atl1e rt2800pci asix и затем modprobe asix -- получил eth1 и запись о переименовании интерфейса в dmesg. Попробуйте и Вы выполнить вручную выгрузку обоих модулей и загрузку одного или другого.
А, получилось искуственным образом (поменяв местами eth0 и eth1 в /etc/udev/rules.d/70-persistent-net.rules) -- при этом после загрузки получаем интерфейсы, пронумерованные в порядке загрузки модулей, и отсутствие "renamed" в `dmesg`. Возможно, "при чём" /lib/udev/write_net_rules, попадающий в initrd благодаря вот этому моему коммиту: http://git.altlinux.org/people/mike/packages/?p=make-initrd-propagator.git;a=commitdiff;h=7f78167fb68e08972af39e7fc1c12f7ca8984323 Вадим, если удобно -- попробуйте сбэкапить и пересобрать у себя initrd, убрав или переименовав в нём этот скрипт.
Проблема в том, что правила из 70-persistent-net.rules, создаваемые текуще75-persistent-net-generator.rules, которые используются для генерации
Проблема в том, что правила из 70-persistent-net.rules, создаваемые текущей версией 75-persistent-net-generator.rules, не работают с systemd после удаления оттуда поддержки переименования сетевых интерфейсов поверх уже существующих имён: http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=commitdiff;h=97595710b77aa162ca5e20da57d0a1ed7355eaad Т.е., теперь нельзя назначать интерфейсам имена вида eth*, wlan* и любые другие имена, которые могут совпасть с именами, автоматически назначаемыми ядром, поскольку в случае, если в процессе загрузки эти имена окажутся назначенными не в нужном порядке, systemd-udevd не сможет поменять их местами. О совместимости с уже существующими конфигурациями, где создан файл 70-persistent-net.rules с такими именами интерфейсов, как обычно, никто не думал, а для новых установок предлагается использовать новый формат имён интерфейсов: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Апстрим о проблеме давно знает и ничего делать не собирается: https://bugs.freedesktop.org/show_bug.cgi?id=53837 > In short: Devices can no longer be renamed to ethX. В Fedora откатили проблемное изменение в пакете для F18, чтобы не ломать обновление: https://bugzilla.redhat.com/show_bug.cgi?id=896135 При этом в F19 патч с откатом опять убран - предполагается, что при обновлении придётся переходить на новую схему именования интерфейсов.
(В ответ на комментарий №10) А можно скомбинировать новую систему именования интерфейсов при загрузке и инициализации модулей с последующим переименованием в 70-persistent-net.rules или аналогичном месте?
(In reply to comment #10) > Апстрим о проблеме давно знает и ничего делать не собирается: > https://bugs.freedesktop.org/show_bug.cgi?id=53837 Сделал reopen, подписал тяжёлую артиллерию; благодарю. > В Fedora откатили проблемное изменение в пакете для F18, чтобы не ломать > обновление: > https://bugzilla.redhat.com/show_bug.cgi?id=896135 Вот для удобства соответствующий патч: http://pkgs.fedoraproject.org/cgit/systemd.git/plain/0013-F18-Revert-udev-network-device-renaming-immediately-.patch?h=f18&id=54dbdc6c2a513fed37fdec82d70fbba1f9cc37e6 Сборка с ним (204-alt1.1) доступна у меня в git.alt и как http://git.altlinux.org/tasks/97426/ -- Вадим, попробуйте с ней, у меня заработало.
Created attachment 5826 [details] dmesg с systemd 204 alt1.1 Я перезагрузил ноутбук несколько раз, с разными вариациями в 70-persistent-net.rules. Мне не удалось добиться неправильного срабатывания udev. Похоже, что Вам удалось побороть эту ошибку!
Тогда идём к shaba@ с предложением поместить её в сизиф и, видимо, скопировать в p7 либо сделать бэкпорт с этим патчем. Апстрим заявляет, что возвращать "заведомо кривое" поведение не будет ни в коем разе, по крайней мере без ядерных исправлений вроде резервирования eth0..N для подобных переименований. Некоторая логика есть, но спешку с выкидыванием вместо объявления неподдерживаемым она никак не оправдывает.
(В ответ на комментарий №12) > (In reply to comment #10) > > Апстрим о проблеме давно знает и ничего делать не собирается: > > https://bugs.freedesktop.org/show_bug.cgi?id=53837 > Сделал reopen, подписал тяжёлую артиллерию; благодарю. > > > В Fedora откатили проблемное изменение в пакете для F18, чтобы не ломать > > обновление: > > https://bugzilla.redhat.com/show_bug.cgi?id=896135 > Вот для удобства соответствующий патч: > http://pkgs.fedoraproject.org/cgit/systemd.git/plain/0013-F18-Revert-udev-network-device-renaming-immediately-.patch?h=f18&id=54dbdc6c2a513fed37fdec82d70fbba1f9cc37e6 > > Сборка с ним (204-alt1.1) доступна у меня в git.alt и как > http://git.altlinux.org/tasks/97426/ -- Вадим, попробуйте с ней, у меня > заработало. Миша, на самом деле в этой сборке твой патч не прикладывается - ты забыл "gear-update-tag -ac" запустить. А если приложить патч, то сборка обламывается: src/udev/udev-event.c: In function 'rename_netif': src/udev/udev-event.c:802:9: warning: implicit declaration of function 'util_strscpy' [-Wimplicit-function-declaration] ...... ./.libs/libudev-core.a(libudev_core_la-udev-event.o): In function `rename_netif': /usr/src/RPM/BUILD/systemd-204/src/udev/udev-event.c:802: undefined reference to `util_strscpy' /usr/src/RPM/BUILD/systemd-204/src/udev/udev-event.c:803: undefined reference to `util_strscpy' Что вы там напроверяли, и как у вас получилось что вы ожидали - я не знаю. Проверяйте task #97504
(In reply to comment #15) > Миша, на самом деле в этой сборке твой патч не прикладывается - > ты забыл "gear-update-tag -ac" запустить. Великолепно. > Что вы там напроверяли, и как у вас получилось что вы ожидали - я не знаю. Самому интересно, а проверял указанием другого ethN в 70-persistent-net.rules. Видимо, тест действительно вышел нечестным в силу того, что на железе, где возможно было проверить установленную систему (liveflash не годится, там сетевые модули в initrd) -- не получалось воткнуть eth1 к eth0. Более качественным тестом при сложно ловящемся race condition является обмен местами имён интерфейсов в этом конфигурационном файле и проверка, что полученные имена соответствуют заданным, о чём в dmesg есть записи ("renamed"). > Проверяйте task #97504 Спасибо :)
Проверять можно, например, в системе с двумя одинаковыми сетевыми картами, выставив в 70-persistent-net.rules порядок ethN, обратный получающемуся при назначении ядром. Хотя, возможно, и тут не удастся надёжно поймать race, если драйвер при инициализации устройства делает какие-то достаточно длительные операции.
(В ответ на комментарий №13) > Created an attachment (id=5826) [details] > dmesg с systemd 204 alt1.1 В этом случае случайно получилась последовательная загрузка драйверов: [ 8.268916] eth0: Broadcom BCM4315 802.11 Hybrid Wireless Controller 5.100.82.112 [ 8.380782] systemd-udevd[691]: renamed network interface eth0 to eth1 [ 8.438415] r8168 Gigabit Ethernet driver 8.035.00-NAPI loaded [ 8.514024] eth0: Identified chip type is 'RTL8168D/8111D'. Такой вариант может правильно обработаться и без патчей; проблема возникнет только в случае, если два сетевых устройства успеют появиться в системе быстрее, чем udevd начнёт обработку событий, требующую переименования этих устройств в те же имена в другом порядке. В случае, если эти устройства используют разные драйверы, воспроизвести такую ситуацию может быть довольно сложно.
Насколько понимаю по http://git.altlinux.org/tasks/archive/done/_95/97504/logs/events.2.1.log -- это всё вместе с http://git.altlinux.org/people/shaba/packages/?p=systemd.git;a=commitdiff;h=da61480b0af0295b7edf90bfa341e51908416cc9 -- уже в сизифе, спасибо. Вадим, я попробую на днях найти два одинаковых ethernet (сейчас их под рукой в пригодном для эксперимента виде нет) -- если у Вас найдутся, тоже проверьте и по результатам CLOSED или REOPENED.
> Вадим, я попробую на днях найти два одинаковых ethernet (сейчас их под рукой в > пригодном для эксперимента виде нет) -- если у Вас найдутся, тоже проверьте и > по результатам CLOSED или REOPENED. У меня физических карт тоже нет, но я установил p7 в VirtualBox-e и настроил два адаптера одного типа. В 70-persistent-net.rules переименовал интерфейсы в обратном порядке. Поведение при 201 и 204-alt1.1 при этом оказалось сходным: интерфейсы именовались вопреки 70-persistent-net.rules. В случае использования 204-alt2 интерфейсы переименовались согласно 70-persistent-net.rules: [ 7.392401] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 10:11:11:11:11:00 [ 7.392423] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection [ 9.143024] e1000 0000:00:08.0 eth1: (PCI:33MHz:32-bit) 10:11:11:11:11:11 [ 9.143065] e1000 0000:00:08.0 eth1: Intel(R) PRO/1000 Network Connection [ 9.193644] systemd-udevd[563]: Tried to rename network interface eth1, but the target name eth0 already exists! The names that udev rules assign to network interfaces must be changed. Avoid names that collide with kernel created ones. A workaround will be attempted now, but this WILL BREAK in a future release! See https://bugs.freedesktop.org/show_bug.cgi?id=56929#c3 [ 9.263484] systemd-udevd[563]: renamed network interface eth1 to rename3 [ 9.273433] systemd-udevd[565]: renamed network interface eth0 to eth1 [ 9.314811] systemd-udevd[563]: renamed network interface rename3 to eth0 на мой взгляд, очень убедительно.
А кто, в итоге, должен создавать 70-persistent-net.rules сейчас ? Что-то у меня не создаётся. Ни в p7 (201-alt1.M70P.1), ни с точечным обновлением из Сизифа до 206-alt1.
udev-rule-generator-net
Значит, что-то не работает... У меня dist-upgrade до p7, правда, с приключениями прошёл в виде ресета не к месту, но, вроде бы, я все пакеты пострадавшие восстановил, глядя на rpm -Va. Существующий persistent-net.rules, если руками создать, вроде как работает, по крайней мере, с 206-alt1.
(В ответ на комментарий №21) > А кто, в итоге, должен создавать 70-persistent-net.rules сейчас ? Что-то у меня > не создаётся. Ни в p7 (201-alt1.M70P.1), ни с точечным обновлением из Сизифа до > 206-alt1. Никто не должен создавать. Интерфейсы теперь именуются по новой схеме, исключающей их перепрыгивание.
Про новую схему я в курсе (и яростно негодую - меня _очень_ устраивают имена вида ethX, когда их может быть десяток и более, а с 802.1q и несколько сотен вида ethX.N). Но udev-rule-generator-net, на сколько я понимаю, должен обеспечивать работу старой схемы. Получается, что старую схему сломали совсем, и в p7 тоже ?
(В ответ на комментарий №25) > Но udev-rule-generator-net, на сколько я понимаю, должен > обеспечивать работу старой схемы. Получается, что старую схему сломали совсем, > и в p7 тоже ? Тогда вешайте новый баг на udev-rule-generator-net
(В ответ на комментарий №26) > (В ответ на комментарий №25) > > Но udev-rule-generator-net, на сколько я понимаю, должен > > обеспечивать работу старой схемы. Получается, что старую схему сломали совсем, > > и в p7 тоже ? > Тогда вешайте новый баг на udev-rule-generator-net См. в sisyphus@ тред "О технологической нейтральности и съемных носителях". Старая схема, увы, костыльная. Ее не сломали, а пытались сохранить. Не факт, что это возможно, тем более длительное время.
> См. в sisyphus@ тред "О технологической нейтральности и съемных носителях". Там же про десктоп и пользователя, который, возможно, этого никогда не увидит. > Старая схема, увы, костыльная. Костыльная она, или нет, но с однотипными именами интерфейсов удобнее работать в скриптах, особенно, когда интерфейсов много. А systemd предлагает использовать достаточно плохо предсказуемое имя. Да и плохо произносимое.
(In reply to comment #26) > Тогда вешайте новый баг на udev-rule-generator-net bug 29282
(In reply to comment #25) > Но udev-rule-generator-net, на сколько я понимаю, должен обеспечивать работу > старой схемы. Получается, что старую схему сломали совсем, и в p7 тоже ? УМВР... и на железе, и в виртуалках, и в установленном виде, и с livecd.
Немного причешу межбаговые зависимости... Этот баг не FIXED для p7. Зато, для p7 есть Bug 29280.
Ну что же, с приездом... :-( Ставлю Кентавра 7.0.1 (Сервер, SysV init), получаю: 2: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 3: enp2s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 4: enp2s0f2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 5: enp2s0f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 Казалось бы, замечательно... Но, update-kernel вытягивает kernel-image-std-def-3.10.16-alt1, и всё это превращается... В 2: ens2f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 3: ens2f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 4: ens2f2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 5: ens2f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 Хорошо, что сервер всё ещё гоняю на соседнем столе... Intel S2600GZ.
(В ответ на комментарий №32) > Ставлю Кентавра 7.0.1 (Сервер, SysV init), получаю: > > 2: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen > 1000 > 3: enp2s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 > 4: enp2s0f2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 > 5: enp2s0f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 Этот вариант именования интерфейсов используется для PCI-устройств общего вида и создаётся из номеров [domain:]bus:dev.fn, видимых, например, в выводе lspci. > Казалось бы, замечательно... Но, update-kernel вытягивает > kernel-image-std-def-3.10.16-alt1, и всё это превращается... В > > 2: ens2f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 > 3: ens2f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 > 4: ens2f2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 > 5: ens2f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 А в данном случае, вероятно, с новым ядром заработала поддержка PCI hotplug через ACPI, в результате стало устанавливаться свойство ID_NET_NAME_SLOT: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c?id=a4bbef099209d4e3bccd913cd30da536f8971064#n167 При этом для назначения имени интерфейса используется первое из установленных свойств ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, ID_NET_NAME_PATH: http://cgit.freedesktop.org/systemd/systemd/tree/rules/80-net-name-slot.rules?id=40ca29a1370379d43e44c0ed425eecc7218dcbca Какой-либо механизм для сохранения ранее использовавшихся имён интерфейсов, имевшийся ранее в 75-persistent-net-generator.rules, теперь отсутствует, в результате при каждой загрузке имена интерфейсов формируются заново без учёта предыдущей конфигурации системы. Можно предложить, например, такой вариант решения этой проблемы, не привязанный к конкретной системе конфигурации сети: - Создать изначально пустой файл, в котором будут сохраняться используемые имена интерфейсов. - При назначении имени интерфейса, если в файле встречается имя, указанное в свойстве ID_NET_NAME_SLOT или ID_NET_NAME_PATH, использовать именно это имя, даже если установлено свойство с более высоким приоритетом. - После назначения имени интерфейса сохранить это имя в файле, если оно там ранее отсутствовало. Возможно, вместо одного файла будет проще использовать каталог, в котором будут создаваться файлы с именами интерфейсов.
(In reply to comment #33) > Какой-либо механизм для сохранения ранее использовавшихся имён интерфейсов, > имевшийся ранее в 75-persistent-net-generator.rules, теперь отсутствует, в > результате при каждой загрузке имена интерфейсов формируются заново без учёта > предыдущей конфигурации системы. Может, всё же, его вернуть ? И придумать какое-то стандартное название для ethernet-интерфейсов, чтобы в скриптах не заниматься вычислением имени каждый раз ? etherX, например, как я в http://bugzilla.altlinux.org/show_bug.cgi?id=29282#c2 предложил.
(В ответ на комментарий №32) > 5: enp2s0f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 > > Казалось бы, замечательно... Но, update-kernel вытягивает > kernel-image-std-def-3.10.16-alt1, и всё это превращается... В > > 5: ens2f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 Есть предложение эту багу всё-таки закрыть (она _решена_), а обсуждение комплектности дистрибутивов перенести в bug #29994, что давно стоило сделать.
(In reply to comment #35) > Есть предложение эту багу всё-таки закрыть (она _решена_), а обсуждение Она была решена, но, судя по всему, временно: http://lists.altlinux.org/pipermail/sisyphus/2014-February/362067.html "старый патч для переименования интерфейсов отвалился" Или патч вернулся ?
(В ответ на комментарий №36) > http://lists.altlinux.org/pipermail/sisyphus/2014-February/362067.html Проверил тогда на регулярках (в них входит udev-rule-generator-net) -- порядок.
(In reply to comment #27) > См. в sisyphus@ тред "О технологической нейтральности и съемных носителях". > Старая схема, увы, костыльная. Ее не сломали, а пытались сохранить. Не факт, > что это возможно, тем более длительное время. Я тут завёл Bug 30491 про то, что ломается без поддержки этой схемы.
