Мелкие чудеса linux и железа

Вы бы дистр озвучили.

А это существенно зависит от дистра? Debian 10. Ядро 5.4

А это существенно зависит от дистра?
enp3s0

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

Look for “GRUB_CMDLINE_LINUX” and add the following”net.ifnames=0 biosdevname=0“.

https://www.itzgeek.com/how-tos/mini-howtos/change-default-network-name-ens33-to-old-eth0-on-ubuntu-16-04.html

сетевые интерфейсы вместо enp3s0 и enp4s0 стали enp4s0 и enp5s0

Естественно, нумерация занятых слотов поменялась.

А это существенно зависит от дистра?

Эту фичу добавили в udev/systemd не помню уже с какой версии. Вернуть старое именование интерфейсов можно так

touch /etc/udev/rules.d/80-net-name-slot.rules

или указав параметр ядра, как выше посоветовали. Со звуковухой есть несколько вариантов, самый простой - указать параметры для модуля ядра:

/etc/modprobe.d/alsa.conf

options snd cards_limit=2
options snd-hda-intel index=0 vid=<vid твоей DP/HDMI карточки> pid=<pid твоей DP/HDMI карточки>
options snd-hda-intel index=1 vid=<vid твоей S/PDIF карточки> pid=<pid твоей S/PDIF карточки>

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

не надо так

Эту фичу добавили в udev/systemd не помню уже с какой версии.

Самое смешное, что пропагандировалось это как «persistent naming». Персистент аж ппц, ога.

Пажжи пажжи, щас окажется что ноут стартует в 2-3 раза медленнее с systemd… хотя пажжи… oh shiiiieeeee

А в биосе, или что там, есть какие-то настройки по поводу нумерации на шине?

Ничего не поделаешь, это системД.

Самое смешное, что пропагандировалось это как «persistent naming». Персистент аж ппц, ога.

Не persistent, а predictable. И оно таки предсказуемое.

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

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

поскольку она зависит от случайной последовательности их инициализации.

Вот не надо глупости писать, вас послушать так до божественного системГ после каждого ребута имена интерфейсов менялись.

Вот не надо глупости писать, вас послушать так до божественного системГ после каждого ребута имена интерфейсов менялись.

Сначала разберитесь в матчасти, а потом пытайтесь спорить.

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

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

А до удев менялись стало быть?

А до удев менялись стало быть?

Да, причём могли делать это при каждой загрузке. Разумеется, в реальности это случалось нечасто, однако именно из-за этого то самое persistent naming через udev и ввели.

Бред. Как собственно и с монтированием корня по UUID.

Не знаю ни одной программы, кроме говённого systemГ, которой недостаточно классического наименования интерфейса, подключенного по ЛЮБОЙ шине, хоть PCI хоть ISA хоть USB хоть SPI.

Ну хочется привязываться к номеру шины - назови устройство eth№шины. Но нет же ж, тренируем навыки телепатии.

Кстати про телепатию.

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

Так вот, ПРИВЕРЖЕНЦЫ SYSTEMD, вам вопрос: по какому сраному алгоритму, не запуская Linux, определить чем будет сетевая карта ?

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

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

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

Самое смешное, что пропагандировалось это как «persistent naming». Персистент аж ппц, ога.

во-во)

сетевые интерфейсы вместо enp3s0 и enp4s0 стали enp4s0 и enp5s0

Терпеть не могу такую херню. Рукожопы сраные, не могли маппинг сделать статичным.

Да он всей новой хернёй восхищается в независимости от её работоспособности – фанбой бтрфс, вяленого, системдэ.

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

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

сейчас во FreeBSD до сих пор осталась эта схема: именование внутри класса драйвера по порядку pci devices. хочешь привязку к мак - делаешь вручную. но хотя бы не слетает, если ssd диск добавил:) плюс /boot/device.hints для изменения порядка привязки к pci.

hint.igb.0.at="pci0:6:0:3"
hint.igb.1.at="pci0:6:0:2"
hint.igb.2.at="pci0:6:0:1"
hint.igb.3.at="pci0:6:0:0"
hint.igb.4.at="pci0:9:0:0"
hint.igb.5.at="pci0:9:0:1"
hint.igb.6.at="pci0:9:0:2"
hint.igb.7.at="pci0:9:0:3"

Не persistent, а predictable. И оно таки предсказуемое.

ахаха, как в сабжевом топике))

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

Не знаю зачем меня кастанули, но поясню, это в udev запилили. Как по мне, не очень полезная и иногда глючная вешь. Получается цепочка, сначала ведро назначает имена, потом удев переименовывает интерфейсы, причем переименовывает используя временное имя, например надо eth0 и eth1 поменять местами, он переименовывает eth0 в ethчто-то-там, потом eth1->eth0, ethчто-то-там->eth1 вот в процессе переименований в зависимости от погоды на сатурне, что-то может пойти не так и система загрузится с интерфейсами ethчто-то-там и eth0. Такая же ситуация с заменой сетевки. У вас был eth0, заменили сетевку, ядро назвало её eth0 потом удев переименует её в eth1 потому что про eth0 у него уже есть правило.

Не знаю зачем меня кастанули

я тебя поддержать хотел

А. Спасибо! :) Тогда докину, как было до udev, говоришь подавану «возьми сетевку, вали туда-то, поменяй такую-то сетевку» с появлением udev, «возьми сетевку, монитор, клавиатуру, будешь на месте отзвонись скажу что надо сделать» емнип мне одного раза хватило что бы выпилить эту фигню :)

=)) я пропустил релизы RHEL7, RHEL8 в надежде, что за 10 лет к RHEL9-10 они доведут все до ума. а дома на фряху свалил, чтобы еще все по-старому было.

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

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

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

https://en.wikipedia.org/wiki/Anecdotal_evidence

Подождите, но году так в 2012 (или когда там эти enp100s500 пошли) оно рекламировалось как решение сабжевой проблемы.

Это что получается, обманули? 😱

Не проще было бы UUID тогда лепить?

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

ахаха, как в сабжевом топике))

Ну конечно — если не обладать знаниями, то всё в мире такое непредсказуемое!

Вот вам задачка: одна сетевая расположена на шине 0, слоте 1, а другая на шине 2, слоте 3 — предскажите, какие имена получат эти сетевые в классической схеме с именованием устройств ядром.

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

Удачи!

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

Когда до вас не дошло, какое отношение информация по ссылке имеет к вашему «аргументу» «УМВР».

Ну а что я могу сделать если у меня действительно всё работает начиная ещё с исовых сетевок.

Ну а что я могу сделать если у меня действительно всё работает начиная ещё с исовых сетевок.

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

Вот вам задачка: одна сетевая расположена на шине 0, слоте 1, а другая на шине 2, слоте 3 — предскажите, какие имена получат эти сетевые в классической схеме с именованием устройств ядром.

Летели два напильника, один зеленый, другой на север. Сколько мне лет?

Вопрос сродни «почему перешли на ненужнод».

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

Бред. Как собственно и с монтированием корня по UUID.

UUID - вынужденная мера. С некоторых пор после загрузки может поменяться /dev/sda на /dev/sdb например. Внешние диски, через USB которые подключены, так это вообще постоянно прыгают по именам, внутренние гораздо реже, но иногда фазы Луны так складываются, что и они меняются.

Вот вам задачка: одна сетевая расположена на шине 0, слоте 1, а другая на шине 2, слоте 3 — предскажите, какие имена получат эти сетевые в классической схеме с именованием устройств ядром.

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

Скорее всего eth0 и eth1 соответственно.

Не угадали. Вопрос не имеет однозначного ответа.

я сейчас дома перешел на фряху и мне любопытно, как они решают эти проблемы. у них до сих пор действует принцип, как в старом Linux: OS uses the driver name followed by the order in which one the card is detected at the kernel boot.

Я так понимаю, этот порядок произвольный. Так вот во FreeBSD есть device.hints и ты можешь назначить свой порядок:

hint.igb.0.at="pci0:6:0:1"
hint.igb.1.at="pci0:6:2:3"

А потом раскатите образ с этой конфигурацией на полторы сотни идентичных машин

как видишь, это вполне решает твою задачу.

в любом случае я не понимаю, при чем тут nvme disk. линукс на мой взгляд обмотан со всех сторон изолентой из серии «хотели, как лучше».

p.s.

anonymous_incognito anc

UUID - вынужденная мера. С некоторых пор после загрузки может поменяться /dev/sda на /dev/sdb например.

Это что ещё за ужасы? Типа загрузились с sda, а после загрузки он стал sdb?

Внешние диски, через USB которые подключены, так это вообще постоянно прыгают по именам

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

у них до сих пор действует принцип, как в старом Linux: OS uses the driver name followed by the order in which one the card is detected at the kernel boot.

Ну именно в linux тоже ничего не поменялось :) Говорю как пользователь слаки с многолетним стажем :)

в любом случае я не понимаю, при чем тут nvme disk

Вот здесь ответили Мелкие чудеса linux и железа (комментарий)

линукс на мой взгляд

только проблема топика именно к linux как ядру не имеет отношения.

Это что ещё за ужасы? Типа загрузились с sda, а после загрузки он стал sdb?

подключил новое устройство по той же шине для копирования и он стал sdb.

подключил новое устройство (флешку) и он стал sdb.

Понял ещё меньше. «Он» это кто?

Ну именно в linux тоже ничего не поменялось :) Говорю как пользователь слаки с многолетним стажем :)

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

Понял ещё меньше. «Он» это кто?

подключаешь другое блочное устройство по SATA к порту, который предшествует sdb, например. получаешь sdb -> sdc.