Bug 28955 - Нестабильность в наименовании сетевых интерфейсов.
: Нестабильность в наименовании сетевых интерфейсов.
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/udev)
: unstable
: all Linux
: P3 normal
Assigned To:
:
: https://bugs.freedesktop.org/show_bug...
:
: 28484
: 29280
  Show dependency tree
 
Reported: 2013-05-11 17:23 by
Modified: 2014-11-20 12:40 (History)


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


Note

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


Description From 2013-05-11 17:23:15
После установки starterkit altlinux-p7-kde4-20130428-x86_64.iso и получения
всех обновлений на ноутбуке имеющем два сетевых интерфейса - проводной и
безпроводной, при перезагрузках ОС наблюдается нестабильность именования
интерфейсов. Иногда проводной получает именование eth0 а беспроводной eth1,
иногда - наоборот.

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

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

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

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

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

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

нет, ни r8168.ko ни wl.ko в initrd нет.
------- Comment #7 From 2013-05-15 21:23:13 -------
Замеченная разница между 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 From 2013-05-15 22:01:00 -------
А, получилось искуственным образом (поменяв местами 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 From 2013-05-15 22:45:21 -------
Проблема в том, что правила из 70-persistent-net.rules, создаваемые
текуще75-persistent-net-generator.rules, которые используются для генерации
------- Comment #10 From 2013-05-15 23:01:36 -------
Проблема в том, что правила из 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 From 2013-05-16 13:58:09 -------
(В ответ на комментарий №10)
А можно скомбинировать новую систему именования интерфейсов при загрузке и
инициализации модулей с последующим переименованием в 70-persistent-net.rules
или аналогичном месте?
------- Comment #12 From 2013-05-16 21:59:44 -------
(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 From 2013-05-17 01:32:34 -------
Created an attachment (id=5826) [details]
dmesg с systemd 204 alt1.1

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

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

Апстрим заявляет, что возвращать "заведомо кривое" поведение не будет ни в коем
разе, по крайней мере без ядерных исправлений вроде резервирования eth0..N для
подобных переименований.  Некоторая логика есть, но спешку с выкидыванием
вместо объявления неподдерживаемым она никак не оправдывает.
------- Comment #15 From 2013-05-17 20:21:06 -------
(В ответ на комментарий №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 From 2013-05-17 20:47:14 -------
(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 From 2013-05-17 23:28:30 -------
Проверять можно, например, в системе с двумя одинаковыми сетевыми картами,
выставив в 70-persistent-net.rules порядок ethN, обратный получающемуся при
назначении ядром. Хотя, возможно, и тут не удастся надёжно поймать race, если
драйвер при инициализации устройства делает какие-то достаточно длительные
операции.
------- Comment #18 From 2013-05-17 23:34:39 -------
(В ответ на комментарий №13)
> Created an attachment (id=5826) [details] [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 From 2013-05-20 13:53:51 -------
Насколько понимаю по
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 From 2013-05-21 02:19:03 -------
> Вадим, я попробую на днях найти два одинаковых 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 From 2013-08-13 17:00:40 -------
А кто, в итоге, должен создавать 70-persistent-net.rules сейчас ? Что-то у меня
не создаётся. Ни в p7 (201-alt1.M70P.1), ни с точечным обновлением из Сизифа до
206-alt1.
------- Comment #22 From 2013-08-13 20:43:28 -------
udev-rule-generator-net
------- Comment #23 From 2013-08-14 10:14:51 -------
Значит, что-то не работает... У меня dist-upgrade до p7, правда, с
приключениями прошёл в виде ресета не к месту, но, вроде бы, я все пакеты
пострадавшие восстановил, глядя на rpm -Va. Существующий persistent-net.rules,
если руками создать, вроде как работает, по крайней мере, с 206-alt1.
------- Comment #24 From 2013-08-14 10:16:53 -------
(В ответ на комментарий №21)
> А кто, в итоге, должен создавать 70-persistent-net.rules сейчас ? Что-то у меня
> не создаётся. Ни в p7 (201-alt1.M70P.1), ни с точечным обновлением из Сизифа до
> 206-alt1.
Никто не должен создавать. Интерфейсы теперь именуются по новой схеме,
исключающей их перепрыгивание.
------- Comment #25 From 2013-08-14 11:08:39 -------
Про новую схему я в курсе (и яростно негодую - меня _очень_ устраивают имена
вида ethX, когда их может быть десяток и более, а с 802.1q и несколько сотен
вида ethX.N). Но udev-rule-generator-net, на сколько я понимаю, должен
обеспечивать работу старой схемы. Получается, что старую схему сломали совсем,
и в p7 тоже ?
------- Comment #26 From 2013-08-14 13:38:37 -------
(В ответ на комментарий №25)
> Но udev-rule-generator-net, на сколько я понимаю, должен
> обеспечивать работу старой схемы. Получается, что старую схему сломали совсем,
> и в p7 тоже ?
Тогда вешайте новый баг на udev-rule-generator-net
------- Comment #27 From 2013-08-14 13:49:34 -------
(В ответ на комментарий №26)
> (В ответ на комментарий №25)
> > Но udev-rule-generator-net, на сколько я понимаю, должен
> > обеспечивать работу старой схемы. Получается, что старую схему сломали совсем,
> > и в p7 тоже ?
> Тогда вешайте новый баг на udev-rule-generator-net

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

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

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

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

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

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

Ставлю Кентавра 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 From 2013-10-16 15:04:20 -------
(В ответ на комментарий №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 From 2013-10-16 15:18:03 -------
(In reply to comment #33)

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

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

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

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

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

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

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

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