Bug 28955 - Нестабильность в наименовании сетевых интерфейсов.
Summary: Нестабильность в наименовании сетевых интерфейсов.
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: udev (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL: https://bugs.freedesktop.org/show_bug...
Keywords:
Depends on: 28484
Blocks: 29280
  Show dependency tree
 
Reported: 2013-05-11 17:23 MSK by Vadim Zelenin
Modified: 2014-11-20 12:40 MSK (History)
12 users (show)

See Also:


Attachments
dmesg при ожидаемом назначении имён интерфейсов (52.67 KB, text/plain)
2013-05-13 02:35 MSK, Vadim Zelenin
no flags Details
dmesg при неправильном назначении имён интерфейсов (52.67 KB, text/plain)
2013-05-13 02:43 MSK, Vadim Zelenin
no flags Details
Вариант журнала с явным переименованием интерфейсов (52.81 KB, text/plain)
2013-05-13 02:54 MSK, Vadim Zelenin
no flags Details
dmesg с systemd 204 alt1.1 (52.00 KB, text/plain)
2013-05-17 01:32 MSK, Vadim Zelenin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vadim Zelenin 2013-05-11 17:23:15 MSK
После установки starterkit altlinux-p7-kde4-20130428-x86_64.iso и получения всех обновлений на ноутбуке имеющем два сетевых интерфейса - проводной и безпроводной, при перезагрузках ОС наблюдается нестабильность именования интерфейсов. Иногда проводной получает именование eth0 а беспроводной eth1, иногда - наоборот.

Обсуждение в форуме: http://forum.altlinux.org/index.php/topic,29155.0.html
Comment 1 Vadim Zelenin 2013-05-13 02:35:24 MSK
Created attachment 5821 [details]
dmesg при ожидаемом назначении имён интерфейсов

dmesg при ожидаемом назначении имён интерфейсов.
eth0 - проводной,
eth1 - безпроводной.
Точно так, как описано в автоматически сгенерированном 70-persistent-net.rules
Comment 2 Vadim Zelenin 2013-05-13 02:43:40 MSK
Created attachment 5822 [details]
dmesg при неправильном назначении имён интерфейсов

Теперь
eth0 - безпроводной интерфейс,
eth1 - проводной.
Возможно-ли, что интерфейсы перепутываются в результате выполнения make-initrd?
Comment 3 Vadim Zelenin 2013-05-13 02:54:04 MSK
Created attachment 5823 [details]
Вариант журнала с явным переименованием интерфейсов

В 70-persistent-net.rules назначил именем безпроводного интерфейса wlan0.
Теперь systemd-udevd рапортует о переименовании инерфейсов.
Comment 4 Michael Shigorin 2013-05-13 13:26:24 MSK
Проверьте на всякий, нет ли в initrd модулей для этих интерфейсов (распаковывается в пустом каталоге: zcat /boot/initrd.img | cpio -id).

Просьба текстовым приложениям назначать тип text/plain :)
Comment 5 Michael Shigorin 2013-05-13 13:30:01 MSK
А, это broadcom до сих пор по умолчанию eth* заводит вместо wlan*...

Спасибо, постараюсь воспроизвести на двух просто ethernet.
Comment 6 Vadim Zelenin 2013-05-14 01:37:42 MSK
(В ответ на комментарий №4)
> Проверьте на всякий, нет ли в initrd модулей для этих интерфейсов
> (распаковывается в пустом каталоге: zcat /boot/initrd.img | cpio -id).

нет, ни r8168.ko ни wl.ko в initrd нет.
Comment 7 Michael Shigorin 2013-05-15 21:23:13 MSK
Замеченная разница между 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.

Попробуйте и Вы выполнить вручную выгрузку обоих модулей и загрузку одного или другого.
Comment 8 Michael Shigorin 2013-05-15 22:01:00 MSK
А, получилось искуственным образом (поменяв местами 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, убрав или переименовав в нём этот скрипт.
Comment 9 Sergey Vlasov 2013-05-15 22:45:21 MSK
Проблема в том, что правила из 70-persistent-net.rules, создаваемые текуще75-persistent-net-generator.rules, которые используются для генерации
Comment 10 Sergey Vlasov 2013-05-15 23:01:36 MSK
Проблема в том, что правила из 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 патч с откатом опять убран - предполагается, что при обновлении придётся переходить на новую схему именования интерфейсов.
Comment 11 Vadim Zelenin 2013-05-16 13:58:09 MSK
(В ответ на комментарий №10)
А можно скомбинировать новую систему именования интерфейсов при загрузке и инициализации модулей с последующим переименованием в 70-persistent-net.rules или аналогичном месте?
Comment 12 Michael Shigorin 2013-05-16 21:59:44 MSK
(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/ -- Вадим, попробуйте с ней, у меня заработало.
Comment 13 Vadim Zelenin 2013-05-17 01:32:34 MSK
Created attachment 5826 [details]
dmesg с systemd 204 alt1.1

Я перезагрузил ноутбук несколько раз, с разными вариациями в 70-persistent-net.rules. Мне не удалось добиться неправильного срабатывания udev.

Похоже, что Вам удалось побороть эту ошибку!
Comment 14 Michael Shigorin 2013-05-17 01:48:31 MSK
Тогда идём к shaba@ с предложением поместить её в сизиф и, видимо, скопировать в p7 либо сделать бэкпорт с этим патчем.

Апстрим заявляет, что возвращать "заведомо кривое" поведение не будет ни в коем разе, по крайней мере без ядерных исправлений вроде резервирования eth0..N для подобных переименований.  Некоторая логика есть, но спешку с выкидыванием вместо объявления неподдерживаемым она никак не оправдывает.
Comment 15 Alexey Shabalin 2013-05-17 20:21:06 MSK
(В ответ на комментарий №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
Comment 16 Michael Shigorin 2013-05-17 20:47:14 MSK
(In reply to comment #15)
> Миша, на самом деле в этой сборке твой патч не прикладывается -
> ты забыл "gear-update-tag -ac" запустить.
Великолепно.

> Что вы там напроверяли, и как у вас получилось что вы ожидали - я не знаю.
Самому интересно, а проверял указанием другого ethN в 70-persistent-net.rules.  Видимо, тест действительно вышел нечестным в силу того, что на железе, где возможно было проверить установленную систему (liveflash не годится, там сетевые модули в initrd) -- не получалось воткнуть eth1 к eth0.

Более качественным тестом при сложно ловящемся race condition является обмен местами имён интерфейсов в этом конфигурационном файле и проверка, что полученные имена соответствуют заданным, о чём в dmesg есть записи ("renamed").

> Проверяйте task #97504
Спасибо :)
Comment 17 Sergey Vlasov 2013-05-17 23:28:30 MSK
Проверять можно, например, в системе с двумя одинаковыми сетевыми картами, выставив в 70-persistent-net.rules порядок ethN, обратный получающемуся при назначении ядром. Хотя, возможно, и тут не удастся надёжно поймать race, если драйвер при инициализации устройства делает какие-то достаточно длительные операции.
Comment 18 Sergey Vlasov 2013-05-17 23:34:39 MSK
(В ответ на комментарий №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 начнёт обработку событий, требующую переименования этих устройств в те же имена в другом порядке. В случае, если эти устройства используют разные драйверы, воспроизвести такую ситуацию может быть довольно сложно.
Comment 19 Michael Shigorin 2013-05-20 13:53:51 MSK
Насколько понимаю по 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.
Comment 20 Vadim Zelenin 2013-05-21 02:19:03 MSK
> Вадим, я попробую на днях найти два одинаковых 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

на мой взгляд, очень убедительно.
Comment 21 Sergey Y. Afonin 2013-08-13 17:00:40 MSK
А кто, в итоге, должен создавать 70-persistent-net.rules сейчас ? Что-то у меня не создаётся. Ни в p7 (201-alt1.M70P.1), ни с точечным обновлением из Сизифа до 206-alt1.
Comment 22 Michael Shigorin 2013-08-13 20:43:28 MSK
udev-rule-generator-net
Comment 23 Sergey Y. Afonin 2013-08-14 10:14:51 MSK
Значит, что-то не работает... У меня dist-upgrade до p7, правда, с приключениями прошёл в виде ресета не к месту, но, вроде бы, я все пакеты пострадавшие восстановил, глядя на rpm -Va. Существующий persistent-net.rules, если руками создать, вроде как работает, по крайней мере, с 206-alt1.
Comment 24 Anton V. Boyarshinov 2013-08-14 10:16:53 MSK
(В ответ на комментарий №21)
> А кто, в итоге, должен создавать 70-persistent-net.rules сейчас ? Что-то у меня
> не создаётся. Ни в p7 (201-alt1.M70P.1), ни с точечным обновлением из Сизифа до
> 206-alt1.
Никто не должен создавать. Интерфейсы теперь именуются по новой схеме, исключающей их перепрыгивание.
Comment 25 Sergey Y. Afonin 2013-08-14 11:08:39 MSK
Про новую схему я в курсе (и яростно негодую - меня _очень_ устраивают имена вида ethX, когда их может быть десяток и более, а с 802.1q и несколько сотен вида ethX.N). Но udev-rule-generator-net, на сколько я понимаю, должен обеспечивать работу старой схемы. Получается, что старую схему сломали совсем, и в p7 тоже ?
Comment 26 Anton V. Boyarshinov 2013-08-14 13:38:37 MSK
(В ответ на комментарий №25)
> Но udev-rule-generator-net, на сколько я понимаю, должен
> обеспечивать работу старой схемы. Получается, что старую схему сломали совсем,
> и в p7 тоже ?
Тогда вешайте новый баг на udev-rule-generator-net
Comment 27 AEN 2013-08-14 13:49:34 MSK
(В ответ на комментарий №26)
> (В ответ на комментарий №25)
> > Но udev-rule-generator-net, на сколько я понимаю, должен
> > обеспечивать работу старой схемы. Получается, что старую схему сломали совсем,
> > и в p7 тоже ?
> Тогда вешайте новый баг на udev-rule-generator-net

См. в sisyphus@ тред "О технологической нейтральности и съемных носителях". Старая схема, увы, костыльная. Ее не сломали, а пытались сохранить. Не факт, что это возможно, тем более длительное время.
Comment 28 Sergey Y. Afonin 2013-08-14 14:49:45 MSK
> См. в sisyphus@ тред "О технологической нейтральности и съемных носителях".

Там же про десктоп и пользователя, который, возможно, этого никогда не увидит.

> Старая схема, увы, костыльная.

Костыльная она, или нет, но с однотипными именами интерфейсов удобнее работать в скриптах, особенно, когда интерфейсов много. А systemd предлагает использовать достаточно плохо предсказуемое имя. Да и плохо произносимое.
Comment 29 Sergey Y. Afonin 2013-08-14 14:55:22 MSK
(In reply to comment #26)

> Тогда вешайте новый баг на udev-rule-generator-net

bug 29282
Comment 30 Michael Shigorin 2013-08-14 18:47:15 MSK
(In reply to comment #25)
> Но udev-rule-generator-net, на сколько я понимаю, должен обеспечивать работу
> старой схемы. Получается, что старую схему сломали совсем, и в p7 тоже ?
УМВР... и на железе, и в виртуалках, и в установленном виде, и с livecd.
Comment 31 Sergey Y. Afonin 2013-09-20 14:49:52 MSK
Немного причешу межбаговые зависимости... Этот баг не FIXED для p7. Зато, для p7 есть Bug 29280.
Comment 32 Sergey Y. Afonin 2013-10-16 11:20:20 MSK
Ну что же, с приездом... :-(

Ставлю Кентавра 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.
Comment 33 Sergey Vlasov 2013-10-16 15:04:20 MSK
(В ответ на комментарий №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, использовать именно это имя, даже если установлено свойство с более высоким приоритетом.

 - После назначения имени интерфейса сохранить это имя в файле, если оно там ранее отсутствовало.

Возможно, вместо одного файла будет проще использовать каталог, в котором будут создаваться файлы с именами интерфейсов.
Comment 34 Sergey Y. Afonin 2013-10-16 15:18:03 MSK
(In reply to comment #33)

> Какой-либо механизм для сохранения ранее использовавшихся имён интерфейсов,
> имевшийся ранее в 75-persistent-net-generator.rules, теперь отсутствует, в
> результате при каждой загрузке имена интерфейсов формируются заново без учёта
> предыдущей конфигурации системы.

Может, всё же, его вернуть ? И придумать какое-то стандартное название для ethernet-интерфейсов, чтобы в скриптах не заниматься вычислением имени каждый раз ? etherX, например, как я в http://bugzilla.altlinux.org/show_bug.cgi?id=29282#c2 предложил.
Comment 35 Michael Shigorin 2014-04-13 13:03:45 MSK
(В ответ на комментарий №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, что давно стоило сделать.
Comment 36 Sergey Y. Afonin 2014-04-13 14:50:45 MSK
(In reply to comment #35)

> Есть предложение эту багу всё-таки закрыть (она _решена_), а обсуждение

Она была решена, но, судя по всему, временно:
http://lists.altlinux.org/pipermail/sisyphus/2014-February/362067.html

"старый патч для переименования интерфейсов отвалился"

Или патч вернулся ?
Comment 37 Michael Shigorin 2014-04-13 17:13:25 MSK
(В ответ на комментарий №36)
> http://lists.altlinux.org/pipermail/sisyphus/2014-February/362067.html
Проверил тогда на регулярках (в них входит udev-rule-generator-net) -- порядок.
Comment 38 Sergey Y. Afonin 2014-11-20 11:55:13 MSK
(In reply to comment #27)

> См. в sisyphus@ тред "О технологической нейтральности и съемных носителях".
> Старая схема, увы, костыльная. Ее не сломали, а пытались сохранить. Не факт,
> что это возможно, тем более длительное время.

Я тут завёл Bug 30491 про то, что ломается без поддержки этой схемы.