Попрощаемся с eth*

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

если для этого одного демона критичен этот десятый интерфейс, то демон его должен ждать. Очевидно же!

В общем я не вижу смысла пытаться тебе что-то объяснить: ты либо не понимаешь о чём я говорю

именно так. По твоему выходит, что надо сначала демон подымать, а потом интерфейс, с которым работает этот демон. По моему, это попытка запрячь лошадь позади телеги. Оригинально конечно, но не слишком эффективно. Да и не нужно.

либо просто упёрся на своём ЛЕННАРТ НИНУЖЕН ОЛОЛОЛО.

вот как раз наоборот, это ты упёрся - дали зелёный кактус - будем жрать зелёный кактус, и пофигу, что оно колется. Завтра дадут говно - будешь жрать говно.

А мне это не совсем понятно - у меня были eth, и проблемы не было. Ввели новый udev, проблема появилась. Очевидно, что просто кривой udev, и eth тут совсем не при чём.

когда наступает после?

в правиле удава ясно написано, что eth7 == MAC666. Как только подымется eth7 на MAC666, то и наступит «после». Старый удав НЕ переименовывал MAC123 на eth7, потому-что в его же правилах было ясно написано, что eth7 занят(на MAC666). Потому-то и конфликтов не было.

и ты надеюсь заметил, что у тебя в системе та же версия удава, про которую идёт разговор в баге, а не мифическая, где всё работает.

у меня тестинг, а не продакшен.

ну да я заранее знал что если я не привяжу макадресы то порядок моих сетевух целиком лежит на совести кода ядра который с каждым обновлением может их поменять..

может поменять и без обновления, они действительно СРАЗУ ВСЕ ядром включаются. Порядок получается непредсказуемый. Уже давно такое. Но я о случае, когда всё прописано и привязано.

во вторых был добавлен новый функционал, в третьих неосиляторы-консерваторы(ключевое слово неосиляторы) ССЗБ

я так и не понял, можно ли мне использовать eth, как мне нравится? Если да - проблемы нет, и новый функционал - это хорошо.

это придумано ребятами из редхата которые работают по поддержке дохреналиона серверов по всему миру и решает проблему которая стоила некоторым компаниям внезапных простоев в работе.

я в курсе кем это придумано, и для чего. Вопрос лишь в том, сохранится-ли старая схема нумерации интерфейсов? Да/нет? Если «да», то проблема надумана, и автор первого поста просто соврал. Новая схема вполне годна для _автоматического_ поднятия интерфейсов. А к схеме с MACами надо ведь и ручки приложить.

для ноутбуков и десктопов это всё вообще нафиг не надо там всёравно нетворкманагер балом правит.

мне больше нравится, когда это руками настроено. Даже в десктопе.

в правиле удава ясно написано, что eth7 == MAC666. Как только подымется eth7 на MAC666, то и наступит «после».

почему eth7? т.е. ты хочешь сказать, что при появлении новой железки нужно проверять все ли сетевые карточки описанные в правилах удева подключены, и если все - то начинать переименовывание? Что делать если eth7 добавляется только по вторникам? Может быть нам при каждом втыкании нового устройства строкить граф зависимостей, искать безопасный путь и выполнять его если он возможен?

Старый удав НЕ переименовывал MAC123 на eth7, потому-что в его же правилах было ясно написано, что eth7 занят(на MAC666).

4.2

я ловил это на своём ноутбуке когда менял броадкомовский драйвер с открытого на закрытый и мне интерфейс переименовывало, и вайфай переменовывался, а теперь представь что я убунтоид и не делал привязку к макам потому что ни в зуб ногой про то что у меня какието етц есть вайфай был настроен я зашёл в жокея ткнул в другой драйвер перезагрузился, вайфай не настроен, оп. я поймал проблему хотя не должен был с ней вообще столкнуться, в твоём варианте какието костыли поверх старой системы должны ьбыли всё разрулить либо я должен был разрулить всё вручную( что мне и пришлось делать года 3 назад)

твоя не уметь в читать, обратитесь к администратору для устранения проблемы.

о да. Мы в школе разные языки изучали.

а разве у нас не запрещена пропаганда веществ?

на аватарке изображена лошадь, пускающая дым из трубочки. Лошадь не существует IRL, как и анаша. Это антипропаганда.

Данный комментарий гораздо лучше, поскольку уже несёт хотя бы какую-то информацию, а не только ругань, тот комментаний, на который ты отвечал тоже нес информацию (про eudev), плюс формально не нарушает правила, т.к. Леннарт не является участником дискусии.

если для этого одного демона критичен этот десятый интерфейс, то демон его должен ждать. Очевидно же!

у демона нет возможности это узнать пока libastral не допилят.

А мне это не совсем понятно - у меня были eth, и проблемы не было. Ввели новый udev, проблема появилась. Очевидно, что просто кривой udev, и eth тут совсем не при чём.

Ты перевираешь, надо так: «Где-то в 2005 проблема была у всех. но сделали поддержку inplace переименовани и у меня проблема исчезла, а у других нет. У меня были eth, и у меня проблемы не было, а у других была. Ввели новый udev, и у меня проблемы нет, а у других оставалась. Очевидно, что просто кривой udev.»

Так да, и пока решения нет, ну или оно есть только у диванных теоретиков/занятых людей, которые не могут пропатчить алгоритм. Я вот думаю, что при повторной попыткой переименования устройств проблему можно вылечить. Но у меня нету желания доказывать свой алгоритм и тем более пытаться сделать реализацию.

я так и не понял, можно ли мне использовать eth, как мне нравится? Если да - проблемы нет, и новый функционал - это хорошо.

если я правильно понял, то полноценно нет, использовать переименования в eth* можно, но алгоритм, который отвечает за конфликтующие переименования (eth0 <-> eth1, через eth2) будет выпилен.

у демона нет возможности это узнать пока libastral не допилят.

вот давай ты мне расскажешь ситуацию, в которой возможны проблемы?

Как я вижу, проблема возникает в том, и только в том случае, когда ты демоны запускаешь раньше, чем интерфейсы _переименовываются_. При этом ты подтасовываешь факты: интерфейс может _подыматься_ любое время (хоть вечность), но вот когда он поднялся, _переименование_ не слишком долгое. В любом случае быстрее 100 миллисекунд. Потому конфликт возможен тогда, и ТОЛЬКО тогда, когда автор системы инициализации озабочен экономией этих сраных миллисекунд.

Ты перевираешь, надо так: «Где-то в 2005 проблема была у всех. но сделали поддержку inplace переименовани и у меня проблема исчезла, а у других нет. У меня были eth, и у меня проблемы не было, а у других была.

ну давай, рассказывай, у кого она была, ДО появления systemd? Не надо мне ссылки появления проблемы ПОСЛЕ (типа того, что была выше, https://bugzilla.redhat.com/show_bug.cgi?id=782145 для федоры 18)

Так да, и пока решения нет, ну или оно есть только у диванных теоретиков/занятых людей, которые не могут пропатчить алгоритм. Я вот думаю, что при повторной попыткой переименования устройств проблему можно вылечить. Но у меня нету желания доказывать свой алгоритм и тем более пытаться сделать реализацию.

просто не нужно бежать впереди паровоза. Секунда ничего не решает(в любом случае), и можно и подождать. Секунды БОЛЕЕ ЧЕМ ДОСТАТОЧНО, дабы удав всё _переименовал_. За это время можно сделать что-то полезное, например загрузить библиотеки (которых ещё нет в кеше), и/или ещё что-то. Или просто тупо подождать. За это время все критичные интерфейсы либо подымуться и переименуются, либо не подымутся(и соответственно не будут мешать).

если я правильно понял, то полноценно нет, использовать переименования в eth* можно, но алгоритм, который отвечает за конфликтующие переименования (eth0 <-> eth1, через eth2) будет выпилен.

можешь объяснить - зачем? Вполне можно просто сменить дефолт, и пусть система, которая ставится с нуля, именует интерфейсы так, как оно ей хочется, хоть 33c8c462d6037ad4d94b.

проблема возникает тогда, когда процесс переименования устройств и появление новых идёт одновременно.

ну давай, рассказывай, у кого она была, ДО появления systemd? Не надо мне ссылки появления проблемы ПОСЛЕ (типа того, что была выше, https://bugzilla.redhat.com/show_bug.cgi?id=782145 для федоры 18)

Запосченная проблема начиналась в fc16, не знаю, было ли там systemd, оно к проблеме не относится: udev-173-3.fc16.x86_64

просто не нужно бежать впереди паровоза. Секунда ничего не решает(в любом случае), и можно и подождать. Секунды БОЛЕЕ ЧЕМ ДОСТАТОЧНО, дабы удав всё _переименовал_.

я не думаю, что дальшейший разговор осмыленен. Ты в упор отказываешься видеть наличие проблемы, и почему-то пытаешься её связать с дальшейшей загрузкой системы. Я как-то не сильно заинтересован в дальшейшем обсуждении и скидывании линков на проблемы людей, т.к. все равно ты читаешь по диагонали.

можешь объяснить - зачем?

что зачем? Если зачем выпилят - то т.к. не осилили реализовать нормально и предпочти убрать полурабочий вариант.

Вполне можно просто сменить дефолт, и пусть система, которая ставится с нуля, именует интерфейсы так, как оно ей хочется, хоть 33c8c462d6037ad4d94b.

его сменили, теперь система по дефолту обзывает устройства в wsp02d23 и т.п.

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

проблема возникает тогда, когда процесс переименования устройств и появление новых идёт одновременно.

я так и не понял, КАК это проявляется? удав прекрастно знает, что ему надо получить скажем eth0, eth1 и eth2, маки их он тоже знает. Даже если скажем eth1 и тормозит, он НЕ будет переименовывать eth0, который eth2 в eth1. Потому-что знает, что eth1 занят. А вот если eth2 _очень_ _быстро_ подымется, и если ядро его по ошибке поименует в eth1, то удав его _сразу_ переименует как надо.

Процесс идёт одновременно, однако промежуточные имена не берутся из пространства окончательных. Потому конфликта и не возникает.

Ещё конфликт может быть в таком случае: админ прописал eth0 и eth1 по MAC. Но у него есть ещё eth2, который прописывать ему лень. В этом случае, возможно, что _непрописанный_ eth2 будет иногда eth2, а иногда eth3. Но это проблема в кривых руках админа, который этот eth2 не прописал. ССЗБ.

Ты в упор отказываешься видеть наличие проблемы

я не отказываюсь, а просто не понимаю. Объясни. Аргументы «редхат большой, ему видней» не катят.

извини, но я буду разговаривать на своём языке не зависимо от того понимают меня или нет, увы но обещал.

можно конечно, в документации всё расписано для Ъ

не изучал языки в школе, украл алгоритмы человеческой речи вместе с телом-носителем.

что зачем? Если зачем выпилят - то т.к. не осилили реализовать нормально и предпочти убрать полурабочий вариант.

хорошо. Я домой попадаю через дверь. А если у тебя дверь заклинило, и тебе удобнее через окно? Ну заходи в окно, при чём тут я, и все остальные?

Если _тебе_ более удобна такая схема - сделай такую, кто против? Зачем у всех выпиливать то, что уже много лет отлично работает?

его сменили, теперь система по дефолту обзывает устройства в wsp02d23 и т.п.

дык я не против. Я против того, что я прихожу домой, а у меня на двери табличка: «теперь модно лазать в окно, дверь замурована».

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

можно конечно, в документации всё расписано для Ъ

мне нужна старая схема переименования eth. Мне пофиг, как оно работает, но сетевая карточка с MAC666 должна у меня стать eth7. Я согласен прописать для этого одну строчку в конфиге. (хотя ИМХО это должна сделать сама обновлялка, на основе старого конфига, где всё прописано, ну ладно).

не изучал языки в школе, украл алгоритмы человеческой речи вместе с телом-носителем.

в следующий раз отнесись более внимательно к выбору носителя. Они на этой планете разные бывают, и 95% совершенно негодные.

код алгоритма стал unmainteined затем deprecated, затем removed. зачем и почему лучше спроси у сиверса.

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

почему-же так получилось, что сетевые демоны стали запускаться ДО подъёма интерфейсов?

и секунды не достаточно

для чего? Для переименования? Не ври.

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

при чём тут демоны? мы говорим про работу одного конкретного удева и его реакцию на поднимаемые ядром интерфейсы.

код алгоритма стал unmainteined затем deprecated, затем removed. зачем и почему лучше спроси у сиверса.

ясно всё с вами…

хм за время этого обсуждения мы написали больше текста чем в документации достаточной чтобы ответить на все твои вопросы, считаю лоркуссию успешной.

маловероятно что будут исправлять, это фишка by-design. Ну так же как и изменение поведения в том случае если производитель устройства одумается и реализует драйвер как надо :). Я бы был не против если бы текущий алгоритм дочинили, но поскольку я сходу могу предположить как это сделать, я подозреваю, что я не понимаю проблемы до конца, да и возможно тогда логика обработки правил перестанет быть stateless.

ради интереса поставь в правило для переименования одного интерфейса скрипт получающий его имя с другого вэбсервера по другому интерфейсу, что должен делать удев чтобы такое работало? написать костыль скрипт для разруливания или сказать ты ССЗБ не делай так или ССЗБ... и это аналогично тому ССЗБ случаю код для разруливания которого силами удева был удалён, по причине официального признания такой ситуации ССЗБ.

сетевушка с маком который ты обязал быть етц 0 может раздуплиться последней

ну и пусть. Предположим, раздуплилась eth1 и стала eth0, вот пусть её удав и быстренько переименует в eth1 (как надо). Не вижу проблемы. Если за секунду ничего нужного не раздуплилось - пусть переименовывает неправильные eth0 и eth1 в неправильные (свободные) eth2 и eth3. Потом пусть демон подымает, а через три часа, подымутся eth0 и eth1, которые СРАЗУ и будут переименованы удавом как надо. Да, в такой ситуации возможен конфликт, только я не понимаю смысл такой конфигурации, в которой _критичные_ интерфейсы подымаются по 3 часа. Т.е. может это кому-то и надо, но таких людей очень мало, таких, которым необходима загрузка боевого сервера за 1 секунду, И ОДНОВРЕМЕННО у них критичный eth подымается 3 часа.

так вот теперь удев считает что переименовывать интерфейсы в етц будет только админ который знает что делает

дык так всегда было. Просто во время _установки_ это по дефолту прописывалось.

при чём тут демоны? мы говорим про работу одного конкретного удева и его реакцию на поднимаемые ядром интерфейсы.

при том, что как назовёт удав(ядро) интерфейсы, волнует только демонов. И то, не всех.

ради интереса поставь в правило для переименования одного интерфейса скрипт получающий его имя с другого вэбсервера по другому интерфейсу, что должен делать удев чтобы такое работало?

а зачем такое надо-то? лично мне необходимо и достаточно, что-бы определённая карточка с определённым MAC переименовывалась на определённый eth. ВСЁ. Когда-то это всё было решаемо без привязок, просто по номеру слота. Но сделали получше, теперь ядро СРАЗУ ВСЁ определяет, и потому eth назначаются рандомно. Ну и ладно, это быстрее, есть профит. Тогда-же запилили костыль, который переименовывает как надо. Если уж исправлять конфликт, то пусть ядро именует интерфейсы например hte0, hte1 и т.д. Или ещё как-то.

Но сделали получше, теперь ядро СРАЗУ ВСЁ определяет, и потому eth назначаются рандомно.

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

P.S. пиши уже алгоритм.

P.P.S.

sed s/eth/net/g /etc/udev/rules.d/80-persistent-net.rules
grep eth /etc
....

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

в том-то и дело, что гонки возникают, потому-что ядро СРАЗУ всё определяет. Т.е. СРАЗУ начинает инициализацию всех eth, что найдёт. Но вот _определяются_ они ессно не одновременно. И если девайсы одинаковые, то порядок их определения случайный.

P.S. пиши уже алгоритм.

он УЖЕ написан.

1. читаем правила, и запоминаем все прописанные eth
2. ждём, пока какой-то интерфейс определится
3. когда определится, проверяем, есть-ли он среди прописанных? Если нет такого, ничего не делаем.
4. если есть, и MAC правильный, ничего не делаем
5. если MAC неправильный, переименовываем как надо
6. если переименовать как надо нельзя, ибо конфликт, переименовываем конфликтный интерфейс как надо, и переименовываем текущий
7. если это невозможно (например eth0 ←→ eth1), то переименовываем конфликтный в свободный, потом текущий как надо, и потом конфликтный как надо
8. если в момент переименования ядро определило опять какой-нить eth66 как eth0, и eth1 → eth0 опять невозможно, рекурсивно выполняем предыдущий пункт

Очевидно, что глубина рекурсии будет не более числа интерфейсов. Алгоритм будет выполнен за линейное время, которое зависит только от числа интерфейсов, при этом неправильный интерфейс будет существовать только очень недолго.

Алгоритм годен, если интерфейсов <100 (тогда можно считать их число константой).

А я просто пожелаю Поцтерингу смерти. Чем скорее тем лучше

Кстати, вчера смотрел на гите так оно почти не шевелится. И сами форкеры говорили, что eudev just for fun. То есть можно ставить его без опасений?

если для этого одного демона критичен этот десятый интерфейс, то демон его должен ждать. Очевидно же!

А чё, грамотное техническое решение! Не то что эти наши поттерингоподелия! А пользователи остальных девяти интерфейсов пусть сосут лапу в ожидании сервиса 8).

если для этого одного демона критичен этот десятый интерфейс, то демон его должен ждать. Очевидно же!

А чё, грамотное техническое решение! Не то что эти наши поттерингоподелия! А пользователи остальных девяти интерфейсов пусть сосут лапу в ожидании сервиса 8).

при чём тут пользователи остальных интерфейсов? Кто их заставляет ждать? Или ты один из тех, кто считает Леннарта первооткрывателем параллельной загрузки? Тогда я тебя расстрою: она реализована например в слаке, причём задолго до твоего Леннарта, и без всяких новых систем загрузки.

Тогда я тебя расстрою: она реализована например в слаке, причём задолго до твоего Леннарта, и без всяких новых систем загрузки.

Она и в gentoo была реализвана. И тоже с кучей костылей на bash-скриптах. Но ты же всё равно не веришь в существование случаев, когда все эти костыли разваливаются. И в багрепорты ты тоже не веришь, ведь их специально Поттеринг (лично!) отправил, чтобы, так сказать, расшатать устои unix-вея =).

Исправят проблему полностью, это я называю custom names.

Скажите, милейший, а почему с дисками никаких custom names не надо и никакого вручнуюнаименования не надо? И есть одновременно несколько способов именования устройств.

А вот там где сраный потеринг с его даунами-фанати так так обязательно надо внезапно переименовать ethX в новую инновационную NIH-синдром схему?

Абсолютно аналогичная ситуация с именованием была в области дисков. Где пришли уроды с devfs и решили отменить sda1,2,3,4. И решили ИДИОТЫ, сделать что бы все имена именовались как раз по положению на шине.

Ну и чем это все закончилось? Что, малолетние дебилы тогда еще под стол пешком ходили, держа соску в зубах как сигу? Вот и не помнят нифига? Приползли из люльки заменив соску на сигу, молоко на пиво и сразу в бой? Весь мир до основания мы разрушим, в чаде алкогольного угара кутежа?

Закончилось это тем что devfs послали нафиг. А для дисков запилили НЕСКОЛЬКО схем именования, в том числе персистентные. Действующие ОДНОВРЕМЕННО, и действующие во всех дистрибутивах. И sdaX остались. И UUID добавились, при чем на уровне «внутри диска» в том числе. И шинное наименование есть... только оно практически НИКЕМ не используются IRL и действует параллельно с остальной кучей схем.

В результате админ/инженер-интегратор может настраивать-скриптописать *логично*.
С точки зрения админского уровня абстракции - админ манипулирует сущностными лежащими гораздо выше системной шины. Даже привязка к mac не так удобна - админа интересует в основном не карта а сам линк.

И да, человек который считает что «640 кб достаточно»^W именования по шине достаточно - сказочный, абсолютно мразотный, упырь-дебилоид.

PS
Потеринг - гондон. Его фанаты - мерзотные, тупые как доски, дебилоиды с синдромом дауна. И блин как эти школоадмины надоели уже, с безумными выпучеными глазами. Что характерно в хостинги уже набежили, в провайдеры. «Вот уроды»(С)

Скажите, милейший, а почему с дисками никаких custom names не надо и никакого вручнуюнаименования не надо? И есть одновременно несколько способов именования устройств.

не потому-ли, что сетевые устройства не поддерживают одновременно несколько наименований, в чем виновато, неожиданно, но ядро?

А вот там где сраный потеринг с его даунами-фанати так так обязательно надо внезапно переименовать ethX в новую инновационную NIH-синдром схему?

ну раз умный такой, то напиши нормальный алгоритм INPLACE переименования устройств, сраный поттериг и сиверс не осилили. Вот тут 2-мя сообщениями выше drBatty тебе даже алгоритм написал.

не потому-ли, что сетевые устройства не поддерживают одновременно несколько наименований, в чем виновато, неожиданно, но ядро?

Ну вот пусть сначала правят в ведре, а потом все ломают. Проблему надо решать там где она возникает, а не ломать всем всё, с гордым дауническим визгом.

ну раз умный такой, то напиши нормальный алгоритм INPLACE переименования устройств, сраный поттериг и сиверс не осилили. Вот тут 2-мя сообщениями выше drBatty тебе даже алгоритм написал.

А теперь объясните мне почему udev использует устройства sdaX в качестве базовых (остальные схемы это симлинки), и почему там все в порядке?

Но я догадываюсь почему. Потеринг сраный с фанатами не добрался еще. Доберется и там сломает все, урод.

И да, если ты мамку поменял на аналогичную, и воткнул всё как было, то у тебя всё работает (в контексте сабжа).

проблема в том, что слоты расширения постоянно меняются, ISA, PCI, сейчас вот Express, который с PCI не имеет ничего общего, кроме названия. Завтра ещё что-нить будет. А вот MAC был всегда, и останется навсегда.

Малолетние дебилы просто никогда не переносили решение с железа на железо же.

Ну вот пусть сначала правят в ведре, а потом все ломают. Проблему надо решать там где она возникает, а не ломать всем всё, с гордым дауническим визгом.

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

А теперь объясните мне почему udev использует устройства sdaX в качестве базовых (остальные схемы это симлинки), и почему там все в порядке?

покажи скрипты переименования sda1 <-> sda2, дальше поговорим.

несмотря на то, что я очень не люблю творчество поттеринга, нехилая часть лоровской аудитории выглядит более сраной и некомпетентной.

Она и в gentoo была реализвана. И тоже с кучей костылей на bash-скриптах.

в слаке всего два таких скрипта: /etc/rc.d/rc.inet1 и /etc/rc.d/rc.inet2. К первому ещё есть конфиг /etc/rc.d/rc.inet1.conf. Это ты называешь «кучей»?

Но ты же всё равно не веришь в существование случаев, когда все эти костыли разваливаются.

Да. Не верю. Хочу доказательств. Сложно что-ли?

И в багрепорты ты тоже не веришь

там английским по белому написано, что проблема в федоре 18. Давай другие багрепорты, если они у тебя конечно есть. Как ваш systemd+udev путается - мне уже доказали. Спасибо.

И sdaX остались.

а вот ещё раньше никаких sda не было. Были hda. Потом их заменили на sda, ВНЕЗАПНО всё обморозилось, что теперь известно, как «12309». Совпадение конечно…

С точки зрения админского уровня абстракции - админ манипулирует сущностными лежащими гораздо выше системной шины. Даже привязка к mac не так удобна - админа интересует в основном не карта а сам линк.

оно так, но не существует способа привязать к линку. А вот к карте - существует. Причём стандартный и общепринятый.

ну раз умный такой, то напиши нормальный алгоритм INPLACE переименования устройств, сраный поттериг и сиверс не осилили. Вот тут 2-мя сообщениями выше drBatty тебе даже алгоритм написал.

дык он УЖЕ был давно написан. Уже лет 5 в продакшене как минимум. Зачем ломать рабочее? Потому-что какой-то сраный новый init не осилил? Может проблема не в удаве?

Но я догадываюсь почему. Потеринг сраный с фанатами не добрался еще. Доберется и там сломает все, урод.

ну отдельный /usr/ он уже поломал, с тем понтом дела, что «у меня он всё равно не работает, потому работать не будет у всех!». Теперь вот с eth такая фигня - у кого-то systemd не смог инициализировать eth, и вместо того, что-бы править systemd (раз udev это его часть), Леннарт просто взял, и поломал рабочий механизм переименований. Как «не нужный».