LINUX.ORG.RU
ФорумTalks

predictable interface names: по-моему это fail

 , ,


0

1

В связи с настройкой нового сервера я испытал грабли с этими predictable names: до первой загрузки с systemd мне имя интерфейса не известно вообще (с чем я и столкнулся при настройке нового сервера из livecd в котором systemd не было). И вот тут меня осенило - а нафига это вообще нужно?

На сервере с одним интерфейсом я хочу чтобы имя было всегда eth0. Зачем мне его менять?

На сервере с несколькими сетевухами мне не нужны ни eth0, eth1, ни enp0s3, enp0s4 итп. Мне нужны int, ext, dmz итп. Т.е. осмысленные имена.

В общем, я считаю что Поттеринг зря потратил на эту фичу время. А persistent names в udev уже давно реализованы.

★★★★★
Ответ на: комментарий от Axon

А ваще, будь поцтеринг вменяемее, он бы решил проблему нормальным способом:

Взял бы свои predictable interface names, отсортировал по алфавиту, и в соответствии с получившимся порядком назначил бы обычные имена eth0, eth1...

geekless ★★
()
Ответ на: комментарий от geekless

А ваще, будь поцтеринг вменяемее, он бы решил проблему нормальным способом:

Взял бы свои predictable interface names, отсортировал по алфавиту, и в соответствии с получившимся порядком назначил бы обычные имена eth0, eth1...

А потом появляется новый вендор сетевого оборудования, и мы имеем всякие eth9+3/4...

Axon ★★★★★
()
Ответ на: комментарий от geekless

это решение переусложнённое и не решает задачи при изменении кол-ва сетевух, т.е. решение практически настолько же unpredictable как и сейчас.

А при чем тут systemd? это чисто udev фича.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

т.е. решение практически настолько же unpredictable как и сейчас.

Не совсем. Как было с udev persistent names?

Вставили адаптер -> он стал eth0. Вытащили его, вставили другой в тот же слот - он тал уже eth1.

Теперь

Вставили адаптер -> он стал p3p1. Вытащили его, вставили другой - он остался p3p1. Имена как раз предсказуемые, вот только... Дурацкие.

no-dashi ★★★★★
()
Ответ на: комментарий от qnikst

unpredictable как и сейчас.

А разве сейчас не persistent naming rules? Т.е. привязка названия к MAC. Это во многих дистрах так.

А при чем тут systemd? это чисто udev фича.

udev часть systemd и заведует им тот же товарищ, не?

true_admin ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

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

Для udev раньше было решение с persistent names, которое работало не всегда, т.е. там присутствуют race conditions (решается или использованием другого пространства имен, или в случае фейла переименования попытаться переименовать ещё раз через небольшой таймаут). Насчет сейчас тоже как-то неясно, они предсказуемые после 1 запуска, если мы втыкаем сетевуху в голый комп - мы понятия не имеем, какое у неё будет имя, хотя у меня нету опыта работы с серверами, чтобы судить насколько это там важно.

qnikst ★★★★★
()
Ответ на: комментарий от true_admin

А разве сейчас не persistent naming rules? Т.е. привязка названия к MAC. Это во многих дистрах так

да, только с гонками.

udev часть systemd и заведует им тот же товарищ, не?

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Возможно ситуация меняется, напр. судя по тому, что они стали брать некоторые патчи из eudev, и возможно будет новый тур по проталкиванию патчей на standalone build.

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от qnikst

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

Это совершенно не нужно.

grep ^1 /sys/class/net/*/type -l | cut -f 5 -d /
vasily_pupkin ★★★★★
()
Ответ на: комментарий от geekless

Взял бы свои predictable interface names, отсортировал по алфавиту, и в соответствии с получившимся порядком назначил бы обычные имена eth0, eth1...

што

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Если ты пишешь конфиги до того как знаешь название своей сетевухи (даже без udev), ты, вероятно, пишешь в общем случае. В таком случае тебе логичнее было бы полагаться на интроспекцию ОС. Если ты пишешь конфиги после того как знаешь название своей сетевухи, то.. то проблемы нет. Если ты пишешь конфиги для конкретной тачки и ситуации, но не знаешь название сетевухи, то не понятно что тебе мешает запустить ip и его узнать.

vasily_pupkin ★★★★★
()
Ответ на: комментарий от qnikst

А разве сейчас не persistent naming rules? Т.е. привязка названия к MAC. Это во многих дистрах так

да, только с гонками.

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

drBatty ★★
()
Ответ на: комментарий от vasily_pupkin

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

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

true_admin ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Как мне интроспекция поможет узнать имя которое назначит udev?

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

http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id...

vasily_pupkin ★★★★★
()
Ответ на: комментарий от drBatty

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

Ну здрасте. Создание правил для переименования сетевых интерфейсов в ethX строго не рекомендуется, так как именно это и вызывает race condition. RTFM.

Axon ★★★★★
()
Ответ на: комментарий от Axon

Ну здрасте. Создание правил для переименования сетевых интерфейсов в ethX строго не рекомендуется, так как именно это и вызывает race condition. RTFM.

до свидания. Я с Патрегом создаю, УМВР, ЧЯДНТ?

drBatty ★★
()
Ответ на: комментарий от drBatty

сказать то что хотел?

в генте тоже есть удав, при этом можно поставить как 171 (как в слаке, если не ошибаюсь), так 197 или live версию, и там есть eth0, eth1 и т.д.

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

тебе уже сказали, что systemd отношения к этому не имеет. Race же есть, но далеко не всегда, хочешь посмотреть на race - поменяй маки eth0 и eth1 в persistent конфиге местами.

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

может я просто не юзаю systemd?

Это не имеет никакого значения.

Axon ★★★★★
()
Ответ на: комментарий от Axon

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

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

ну я тебе показал, что ты не прав.

Дополню, в генте можно иметь udev-197 и там будет predictable имена, если захочешь (установишь use-flag или руками добавишь файл).

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

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

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

Axon ★★★★★
()
Ответ на: комментарий от Axon

Просто гонку по какой-нибудь причине выиграет ядро, и привет.

чо?

У меня такое было, например.

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

qnikst ★★★★★
()
Ответ на: комментарий от no-dashi

Если я ничего не путаю, то в FreeBSD такая схема реализована, только более красиво.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Axon

Рассчитываете на это. Когда сломается, вспомните, что я предупреждал.

и долго мне ждать, пока оно «сломается»? Вангую, что твой systemds в твоём арчике сломается куда как раньше.

drBatty ★★
()
Ответ на: комментарий от qnikst

тебе уже сказали, что systemd отношения к этому не имеет. Race же есть, но далеко не всегда, хочешь посмотреть на race - поменяй маки eth0 и eth1 в persistent конфиге местами.

менял. И что? Всё равно eth0 остаётся eth0, как его не меняй. В чём проблема-то? Что eth1 опознаётся раньше eth0? Ну дык удав их и переименовывает как надо. Зачем нужны какие-то новые имена?

drBatty ★★
()
Ответ на: комментарий от qnikst

ну я тебе показал, что ты не прав.

нет. Не показал. Если обозвать eth0 как eth0, то он будет eth0, в чём проблема-то? В наличие второго eth(третьего и т.д)? Ну есть такое, что дальше?

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

drBatty ★★
()
Ответ на: комментарий от drBatty

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

vurdalak ★★★★★
()
Ответ на: комментарий от drBatty

менял.

лог загрузки.

Зачем нужны какие-то новые имена?

прочитай на wiki fdo-шной, там понятно написано, заодно в обсуждении там можешь поутверждать, что у раз у тебя проблемы нет, то ни у кого нет, а у кого есть так-то руки кривые. Проблемы объективно есть, их можно решить разными способами без predictable naming rules, можно и с ним, это один из вариантов со своими плюсами и минусами, не являющийся ни панацеей ни злом во плоти.

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

нет. Не показал.

нет, показал, ты сказал, что проблема из-за системд, я тебе возразил, что это чисто udev-во решение введенное в 197 и никаким боком к systemd не относящееся. По этому вопросу возражения есть?

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

Если обозвать eth0 как eth0, то он будет eth0, в чём проблема-то?

я попросил тебя сделать так, чтобы eth0 стало eth1, а eth1 стало eth0 при следующей загрузке. Что ты там решаешь - я не понимаю..

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

у меня на моих use-case в генте проблем с сетевыми интерфейсами нет. Ну и мне кажется, что ты даже не понял о чем разговор.

qnikst ★★★★★
()
Ответ на: комментарий от vurdalak

немного не так, для сетевухи они будут обозваны ядром в ethX в порядке загрузки модулей + порядке инициализации шины. В случае pci это pci-bus order, в случае usb это как попало, в зависимости от оборудования, причем для монолита все проще т.к. модули уже загружены, в отличии от отдельных модулей. Параллельно с этим при появлении ethX устройства в дело вступает udev, который переименовывает их в том же namespace в ethY в зависимости от правил; соответсвенно если udev хочет переименовать eth0 -> eth1, но в ~этот же момент ядро создало eth1, то процесс переименования обламывается, и когда udev хочет переименовать eth1 в eth0 он опять обламывается. Решений много, решения не сложные, а использовать уникальную инфу для сетевухи (predictable-network-naming) это одно из решений, со своими плюсами и минусами.

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

Ну дык удав их и переименовывает как надо

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

true_admin ★★★★★
() автор топика
Ответ на: комментарий от vurdalak

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

udev их переименовывает в нужном порядке в момент загрузки ориентируясь по их MAC. В слаке так сделано. Ну а если ты на своём сервере провода перетыкаешь по горячему - ССЗБ.

drBatty ★★
()
Ответ на: комментарий от drBatty

udev их переименовывает в нужном порядке в момент загрузки ориентируясь по их MAC.

Не может быть так что перименование произойдёт после того как будут прописаны айпишники и роуты?

true_admin ★★★★★
() автор топика
Ответ на: комментарий от qnikst

лог загрузки.

будет под рукой - кину. Сейчас у мну десктоп с одной сетевой.

прочитай на wiki fdo-шной, там понятно написано, заодно в обсуждении там можешь поутверждать, что у раз у тебя проблемы нет, то ни у кого нет, а у кого есть так-то руки кривые. Проблемы объективно есть, их можно решить разными способами без predictable naming rules, можно и с ним, это один из вариантов со своими плюсами и минусами, не являющийся ни панацеей ни злом во плоти.

ты слышал про бритву Оккама? Вот и объясни мне, нафейхуя?

drBatty ★★
()
Ответ на: комментарий от drBatty

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

Ну а если ты на своём сервере провода перетыкаешь по горячему - ССЗБ.

Ну конечно. Если ты свет выключаешь — ссзб, бэкапы для слабаков. Если железо перевтыкаешь без перезагрузки — ссзб. А еще есть такой ССЗБ-пакет для обновления ядра без перезагрузки.

vurdalak ★★★★★
()
Ответ на: комментарий от qnikst

нет, показал, ты сказал, что проблема из-за системд, я тебе возразил, что это чисто udev-во решение введенное в 197 и никаким боком к systemd не относящееся. По этому вопросу возражения есть?

нет.

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

ну значит у тебя неправильный удав, раз он даже eth не умеет.

я попросил тебя сделать так, чтобы eth0 стало eth1, а eth1 стало eth0 при следующей загрузке.

ну для этого надо правила переписывать. Я переписывал как-то, в чём проблема? Мне как раз и надо было, что-бы eth0 стало eth1, ибо конфиги переписывать меня ломало, а я их с другого сервера скопипастил.

у меня на моих use-case в генте проблем с сетевыми интерфейсами нет. Ну и мне кажется, что ты даже не понял о чем разговор.

ну дык поясни, нафейхуя какие-то новые имена интерфейсам дают?

drBatty ★★
()
Ответ на: комментарий от qnikst

В случае pci это pci-bus order

на одном моём локалхосте pci карточки определяются рандомно, иной раз первая первой, а иной раз наоборот. От чего зависит - я не знаю.

соответсвенно если udev хочет переименовать eth0 -> eth1, но в ~этот же момент ядро создало eth1, то процесс переименования обламывается

не обламывается, а переименовывает в eth2, а потом в eth1(после переименования eth1 → eth0). Я потом тебе лог с этой ерундой покажу, если ты мне не веришь.

drBatty ★★
()
Ответ на: комментарий от true_admin

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

меня просили не поливать говном systemd, потому ответ - нет. У меня такого быть не может. У тебя - без понятия, man systemd.

drBatty ★★
()
Ответ на: комментарий от true_admin

Не может быть так что перименование произойдёт после того как будут прописаны айпишники и роуты?

именно потому мой локалхост грузится 7 секунд, а не 3. Что-бы такой ерунды не было.

drBatty ★★
()
Ответ на: комментарий от vasily_pupkin

Разве удев умеет прерывать контекст правил и продолжать его после каких то новых событий?

нет. Судя по логу, сначала определяются интерфейсы ВСЕ ВМЕСТЕ, а затем удав их переименовывает. Или даже переименовывает ОДНОВРЕМЕННО, потому-что иногда в логах видно, что переименование было ДО определения.

Но - какая разница? Главное, что одна сетевуха eth0, вторая eth1 и так далее, как их не втыкай. Не вижу проблемы.

drBatty ★★
()
Ответ на: комментарий от drBatty

вот тебе объяснение сути проблемы: predictable interface names: по-моему это fail (комментарий)

сжато: проблем нет в том случае если гарантируется, что ядро не создает устройства в том же namespace, куда переименовывает udev. На самом деле условие можно ослабить, но мне строго не сформулировать это. Для решения этой проблемы есть 2 пути: 1). использовать разные пространства имен (так сделали в predict-n-n, так делают руками как ТС -давая логические имена), 2). делать повтор операции в случае фейла, при этом переименовывать через временное имя (мне этот вариант нравится больше) но из-коробки его нигде нет.

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

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

Не, то что оно их может перименовать в какое то новое нечто - это понятно. А как оно переименовывает обратно?

vasily_pupkin ★★★★★
()
Ответ на: комментарий от qnikst

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

4.2

в слаке именно так и сделано. Т.ч. это всё-же гентопроблема. Пинай своих маинтейнеров, Патрег осилил.

drBatty ★★
()
Ответ на: комментарий от drBatty

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

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

ну дык поясни, нафейхуя какие-то новые имена интерфейсам дают?

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

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

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

qnikst ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Не, то что оно их может перименовать в какое то новое нечто - это понятно. А как оно переименовывает обратно?

ну так и переименовывает

eth1 → eth2
eth0 → eth1
eth2 → eth0
в чём проблема-то? Я сам удивился, когда увидел в логе eth2, которого отродясь на том компе не было, и быть не могло.

drBatty ★★
()
Ответ на: комментарий от drBatty

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от drBatty

/me пнул себя, а Вильяма позже пну.

в persistent-names.rules что-то принципиально отличное от:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:21:cc:4a:a9:d0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

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

УМВР без всяких слипов. И я-бы не назвал это «гонкой», просто интерфейсы определяются одновременно, и ядро даёт им имена от балды. А удав их переименовывает как надо. Мне кажется, что это не в слаке фича, а в вашей генте баг.

тебя попросили поливать говном удев

а зачем, если УМВР?

drBatty ★★
()
Ответ на: комментарий от qnikst

в persistent-names.rules что-то принципиально отличное от:

нет, оно и есть. Только две строки - eth0 и eth1. Они сами на установке появились, их утилита netconfig вписала, если я не ошибаюсь. И эта утилита входит в стандартный setup из Slackware Linux. Я, во всяком случае, ничего туда не вписывал.

drBatty ★★
()
Ответ на: комментарий от drBatty

УМВР без всяких слипов.

слип, это чтобы было не одновременно и чтобы ты смогу увидеть проблему если есть.

Мне кажется, что это не в слаке фича, а в вашей генте баг.

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

И я-бы не назвал это «гонкой», просто интерфейсы определяются одновременно, и ядро даёт им имена от балды.

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

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

чо?

https://wiki.archlinux.org/index.php/Udev#Network_device

When choosing the static names it should be avoided to use names in the format of «ethX» and «wlanX», because this may lead to race conditions between the kernel and udev during boot.

ты сможешь объяснить процесс, который там происходил?

Нет. А вы?

Axon ★★★★★
()
Ответ на: комментарий от vasily_pupkin

было бы прикольно в интерактивном режиме отлавливать запросы на подключение оборудования и вписывать названия ДО подключения. Чтобы ведро маячило каким-нибудь Кедам, а они выдавали диалоговое окно «Вставлена сетевая карта производства Вротмненоги Inc. Как желаете назвать ее?». И только чтобы после подтверждения она добавлялась.

Это вообще очень бы помогло. Например, админ попивает чай дома, а тут в офисе неустановленный Вася пихает в сервер свою сетевуху (чтобы порево смотреть по выделенному каналу). В таком случае админ мог бы посмотреть на сообщение «вставлено новое оборудование» и просто отклонить его.

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

С анакондой шото типа такого и есть, если правильно помню. Правда я видел её последний раз в районе RH 7.x :D

Впрочем, неустановленные Васи - совсем другой юзкейс

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Axon

и просто от фразы «гонку может выиграть ядро» мне захотелось плакать.. выше в треде описано.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

слип, это чтобы было не одновременно и чтобы ты смогу увидеть проблему если есть.

пусть будет одновременно, в чём проблемы? А увидеть - не будет сети - увижу.

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

ну слака вообще-то не для серверов нужна, а для десктопов. А на десктопах обычно один интерфейс и такой проблемы нет. Я, кстати, сам на сервера никогда слаку не ставил - я тут про свой локалхост рассказал. Да, не совсем обычный.

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

_появляются_ они одновременно, а вот _определяются_ таки нет. По очереди. Причём рандомно. Т.ч. проблема мне вполне знакома. Но меня удивляет, что её решение(udev) опять поломали. Чините…

drBatty ★★
()
Ответ на: комментарий от qnikst

просто такое правило не решит проблему в общем случае.

это почему?

вот правило с десктопа с одним eth

$ cat /etc/udev/rules.d/70-persistent-net.rules 

# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:60:6e:d7:5e:45", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
с двумя вроде тоже самое, только строчек две. Будет доступно - гляну(хотя там сейчас тоже один интерфейс, второй просто не нужен, но правитло должно остаться).

drBatty ★★
()
Ответ на: комментарий от drBatty

А на десктопах обычно один интерфейс

погрепал technocity.ru, на большинстве матерей за > 5 тыс. руб, или 2 GLAN, или GLAN+Wifi+Bluetooth

stevejobs ★★★★☆
()
Ответ на: комментарий от drBatty

пусть будет одновременно, в чём проблемы?

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

_появляются_ они одновременно, а вот _определяются_ таки нет.

каким чудом это делается?

qnikst ★★★★★
()
Ответ на: комментарий от drBatty

это почему?

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

qnikst ★★★★★
()
Ответ на: комментарий от stevejobs

погрепал technocity.ru, на большинстве матерей за > 5 тыс. руб, или 2 GLAN, или GLAN+Wifi+Bluetooth

нафейхуя? У меня один, но есть два PCIE и один PCI, т.ч. ещё 3 могу воткнуть. Смысл? Есть же роутер с четырьмя дырками.

drBatty ★★
()
Ответ на: комментарий от qnikst

каким чудом это делается?

слушай, я не знаю. В логе так написано. Или у тебя в одной строчке лога два события? У меня вот по одному событию в каждой строке. А кроме лога - яхз.

drBatty ★★
()
Ответ на: комментарий от drBatty

вангую модули вкомпиленные в ядро и pci сетевухи.

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

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от qnikst

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

если в правиле написано «eth0», но переименование в eth0 невозможно, т.к. такой интерфейс уже существует, то что делать-то по твоему? По моему(и по мнению моего удава) надо переименовать в eth2, а уже потом в eth0, когда eth0 освободится. Видать в твоём удаве это поломали… Уже говорил - чините.

drBatty ★★
()
Ответ на: комментарий от qnikst

вангую модули вкомпиленные в ядро и pci сетевухи.

ЕМНИП одна карта pci(8139) с модулем вкомпилленым, а вторая attansic встроенная в карту (тоже считается pci), но там модуль невкомпиллен, а так болтается в lsmod (идёт в комплекте с ядром начиная ЕМНИПП с 2.6.15, ваниль)

drBatty ★★
()
Ответ на: комментарий от drBatty

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

ну... не про то история же, так все умеют.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

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

я тоже что-то не нашёл, хотя да, проблемы были, но они уже давно решены. Вот - вернулись, вместе с этим вашим systemd. Который тут «не при чём». Хотя в других темах вы все фапаете на «быструю» и «параллельную» загрузку. Может в этом-то и причина? В том что загрузка настолько быстрая, что даже нормально интерфейсы именоваться не успевают? Не?

drBatty ★★
()
Ответ на: комментарий от drBatty

Вот - вернулись, вместе с этим вашим systemd.

системд не мой, я им не пользуюсь, и не собираюсь

Который тут «не при чём».

если ты способен объяснить при чем он тут, то пожалуйста.

Хотя в других темах вы все фапаете на «быструю» и «параллельную» загрузку.

правда?

Может в этом-то и причина?

нет

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

нет, больше всего плакались о race-о проблеме пользователи debian (мне немного лень искать в общем в теме про анонс этих измений в udev-197 было)

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

если ты способен объяснить при чем он тут, то пожалуйста.

если я правильно понял, то удав теперь часть systemd. Не?

нет, больше всего плакались о race-о проблеме пользователи debian (мне немного лень искать в общем в теме про анонс этих измений в udev-197 было)

ну в слаке эта проблема уже давно и успешно решена. Значит - в дебе поломали. Я не прав?

drBatty ★★
()
Ответ на: комментарий от drBatty

если я правильно понял, то удав теперь часть systemd. Не?

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

ну в слаке эта проблема уже давно и успешно решена. Значит - в дебе поломали. Я не прав?

я утверждаю, что везде недочинили.

qnikst ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.