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

в нормальных операционках такого нет.

Нормальные операционок нет

как я понимаю может во-первых смениться DRIVERS. Хотя тут wildcard впрочем, как и у меня + KERNEL может начать выдавать не eth, а ath и т.п. такое часто с wifi бывает.

у тебя 10 wifi'ев? а у кого 10? Не, я понимаю 10 ethernet карт, которые RJ45, но 10 вайфаев - мне не ясен смысл такого юзкейса.

но это особенности того, что у меня простое оборудование.

вот ради кого это делают-то?

вот очень красивые логи и обсуждение https://bugzilla.redhat.com/show_bug.cgi?id=782145 drBatty тоже загляни.

заглянул, блжад.

Привет, меня зовут Вася, у меня 6 интерфейсов и удав запутался. Почините, что-бы было eth{0..5}

Хай Вася! Давайте мы сделаем systemd udev, и назовём все интерфейсы у всех по новой! Зачем чинить этот быдлокод, нас самих он задолбал! Лучше написать новый.

Это не первый тред на эту тему, и, боюсь, не последний. Кровавый баттхёрт арчеводов уже отбушевал.

а что с арчеводами, и почему мой никнейм упоминается в одном контексте с арчем?

у тебя 10 wifi'ев?

нет. достаточно одного был wlan0 стал ath0 привет всем конфигам, подобная беда и с eth0 -> eth1 может быть. В общем я привел ссылку на баг с логами, они красноречивее меня..

ради тырпрайз пользователей и серверов.

== работает неправильно. Ведь нам нужно, чтобы именно этот интерфейс (по MAC-адресу) назывался eth1.

нет. потом в eth1 переименовывается, как оно и должно.

Он не должен ни при каких обстоятельствах становиться eth2, eth15 или каким-то другим ethN, так как это может поломать некую логику дальше по цепочке. Например dhcp-сервер может запустится не на том интерфейсе (пример высосан из пальца, но думаю смысл ясен).

ну просто надо сделать запуск сетевых сервисов зависимым от ethX. Как оно и было в старых init-скриптах. Похоже в systemd просто ВСЁ СРАЗУ, вот проблема и вылезла. А раньше dhcp запускался после ethX. И всё было нормально.

нет. достаточно одного был wlan0 стал ath0 привет всем конфигам, подобная беда и с eth0 -> eth1 может быть.

при чём тут eth?

В общем я привел ссылку на баг с логами, они красноречивее меня..

ну кто хотел БЫСТРО и СРАЗУ? За 910 миллисекунд? Получите, распишитесь. Я говорил, что ничего хорошего из этого НЕ получится?

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

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

Имхо добавление возможности делать predictable-names это хорошо, как вариант по умолчанию, я думаю - плохо.

эта проблема ортогональна systemd и скорости загрузки, если чо.

а что с арчеводами

То же самое, только раньше.

быть того не может, у вас такой же удав.

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

чинить надо, а не костыли вставлять. Не?

эта проблема ортогональна systemd и скорости загрузки, если чо.

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

ну просто надо сделать запуск сетевых сервисов зависимым от ethX. Как оно и было в старых init-скриптах. Похоже в systemd просто ВСЁ СРАЗУ, вот проблема и вылезла. А раньше dhcp запускался после ethX. И всё было нормально.

Ты не понимаешь суть проблемы. При каждом изменении состояния интерфейса, будь то добавление IP-адреса, появление линка на сетевухе или изменение имени, ядро шлёт по протоколу netlink мультикастом уведомление всем подписчикам. В случае переименования eth0 -> eth2 -> eth1 подписчик не сможет определить какое из переименований «окончательное».

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

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

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

А если интерфейс должен появиться через пол часа после после загрузки системы, когда раздуплится какая-нибудь Ънтерпрайзная махина, стоящая по соседству? Считаешь, что в этом случае система должна тормознуть на эти пол часа?

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

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

А ещё ты похоже забываешь, что проблемы лучше решать превентивно, а не после того, как песец потоптался 8).

Ты не понимаешь суть проблемы. При каждом изменении состояния интерфейса, будь то добавление IP-адреса, появление линка на сетевухе или изменение имени, ядро шлёт по протоколу netlink мультикастом уведомление всем подписчикам. В случае переименования eth0 -> eth2 -> eth1 подписчик не сможет определить какое из переименований «окончательное».

дык - есть время поднятия сетевых интерфейсов, а ПОСЛЕ него время поднятия сетевых демонов. Когда подымаются демоны, интерфейсы УЖЕ подняты.

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

ИМХО они ВСЕ должны подыматься ПОСЛЕ.

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

ну и пусть появляются. По твоему, демон должен интерфейсы отслеживать? А по моему у него в конфиге должно быть жёстко прописано eth5, и подыматься этот демон должен ПОСЛЕ того, как eth5 определился. Иначе ерунда получится.

А если интерфейс должен появиться через пол часа после после загрузки системы, когда раздуплится какая-нибудь Ънтерпрайзная махина, стоящая по соседству? Считаешь, что в этом случае система должна тормознуть на эти пол часа?

система должна работать, а вот демон должен ждать, и надеяться.

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

я только федоропроблемы вижу. И арчепроблемы. И теперь гентопроблемы. Короче - везде, куда приходит systemd начинаются леннартопроблемы. Может проблема не в eth?

А ещё ты похоже забываешь, что проблемы лучше решать превентивно, а не после того, как песец потоптался 8).

т.е. писец по имени Леннарт уже пришёл? Выхода нет? Из-за него надо даже eth менять?

Predictable interface names появились в одной из прошлых версий, и именно тогда пошли все эти разговоры.

А если ты материнку не поменял?

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

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

Ты бы ещё спросил, как тебе помогут новые правила, если ты себе яйца отрежешь.

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

Ты не пугай так.

ИМХО они ВСЕ должны подыматься ПОСЛЕ.

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

В общем я не вижу смысла пытаться тебе что-то объяснить: ты либо не понимаешь о чём я говорю, либо просто упёрся на своём ЛЕННАРТ НИНУЖЕН ОЛОЛОЛО.

ИМХО они ВСЕ должны подыматься ПОСЛЕ.

Или ввести имена интерфейсов, не конфликтующие с ядерными и не заморачиваться.

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

А у нас правилом для udev и тоже по умолчанию поведение не менялось. Но когда такие мелочи истеричек останавливали?

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

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

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

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

угумс, вот тут и раскрыта суть новости ту штуку которая при «пытается переименовать eth0 в eth1 и обламывается» делает «переименовывает eth1 в ethN; переименовывает eth0 в eth1» отправили в костылево, такие конфликты более не будут решаться в автоматическом режиме.

мой врач сказал что это нормально в период юниксового созревания.

оно отключаемо и в тот момент когда ты их воткнёшь в один и тот же слот думаю станет возможным всё...

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

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

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

блин что-то я сразу не глянул на твой аватарка...

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

как вариант по умолчанию необходимо, и чем раньше тем лучше.

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

ну так и починили ещё в удеве 187, а теперь выкинули костыль. ждать загрузки всех сетевых интерфейсов неприемлемо, так что придумывай новый костыль с таким тех заданием, удачи.

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

и да при чём тут леннарт вообще? неужели кеннеди убил?

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

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

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

Камикадзе моде?

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

Если ты считаешь, что usb девайс втыкаемый в разные слоты должен переименовываться по разному, если ты считаешь, что изменение драйвера/версии ядра может приводить к изменению имени девайса, и при этом считаешь, что custom names в не eth пространстве имен хуже, то я даже не знаю, что и сказать.. наверное ты лишь чуть меньше предвзят, чем drBatty.

Может лучше спать идти.. а то, какой-то полет сознания, а не текст.

Если, что я старался использовать 3 термина:

• persistent names - автопереименование основанное на маках в ядерном пространстве имен;
• predictable names - автопереименование основанное на информации о железе: слоте/маке/как-повезет^W;
• custom names - автопереименование основанное на маках в не ядерном пространстве имен.

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

Так по вариантам:

• первый вариант работает только в случае когда имена не перекрываются, например, когда устройств мало (но тогда переименование вообще не нужно). Плюсы: он прост, существует огромное количество документации и скриптов испольующих eth/wlan пространство имен. Минусы: начиная с определенного количества, вида устройств перестает работать, эта проблема не имеет успешного решения, имена могут зависеть от модуля ядра
• второй вариант дает предсказуемые имена. Плюсы: при некоторых условиях, вы можете понять имя будет дано устройсву, по выводу информации о нем. Минусы: имена не постоянны, см. usb девайсы, имена могут зависеть от модуля ядра, его версии и положения устройства, имена не удобны.
• Третий вариант работает всегда. Плюсы: имена предсказуемы, имена не случайны. минусы: нужно придумывать политику именования самому.

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

Табличка:

              | persistent  | predictable | widely     |  automatic |
              |             |             | documented |            |
--------------+-------------+-------------+------------+------------+
persistent    |  -          |  -          |  +         |   +        |
predictable   |  -          |  ~          |  -         |   --       |
custom        |  +          |  +          |  ~         |   -        |
--------------+-------------+-------------+------------+------------+

Камикадзе моде?

да нет, это он пытается что-то стоящее изобразить просто.

Поеттеринг и Сиверс всё правильно сделали!

А если ты материнку не поменял?

если сетевая осталось той же, то и MAC тот же. Не вижу проблемы.

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

на другом кластере по волшебству слоты пронумерованы точно так же?

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

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