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

Сферический? Да, есть такое.

Так sata или флэшку? Если sata, то да, вполне возможно такое.

да, sata.

Сферический? Да, есть такое.

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

Ну изолента, на то и изолента, я без неё обхожусь и нормально себя чувствую. Выше писал про наименования интерфейсов и то что я отказался от этой хипстерсой поделки.
ЗЫ До переезда на фряху пока не дозрел :)

До переезда на фряху пока не дозрел :)

ну эт лично мои приколы все-таки)

Ну у меня для этого хоть и косвенные, но предпосылки есть :) Не водил бы дружбу со слакой, в принципе мог бы давно уже свалить. :) Хотя вот знаю людей которые лет 10 назад наоборот с фряхи на линукс переехали.

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

Скорее костыль для героического решения созданных проблем.

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

ЕМНИП, во времена мандрейка и аспа, master\slave primary\secondary всегда были hda и hdb, независимо от того, кто после кого был вставлен.

Что есть вполне логично: для системы считать устройства нужно по мере их подключения к физическому порту, т.е. если у тебя на компе винт подключен к порту SATA3, он никак не должен быть sdb, даже если он второй в системе. А пользователи вообще не должны знать об этих телодвижениях, для них придуманы label, существующие с незапамятных времен.

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

Нет, допустим три диска /dev/sda /dev/sdb на sata и /dev/sdc на usb внешний.

Перезагрузился и стало /dev/sda - внешний на USB, остальные как-то перемешались заранее неизвестно как. Потом перезагрузился ещё раз и снова порядок другой. Естественно, если вынул внешний - тоже меняется.

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

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

На самом деле ещё хуже: перестановка не каждый раз, но может произойти и без подключения. И без изменения порядка в BIOS тоже. хз почему, вероятно что-то инициализируется с разной скоростью в зависимости от фаз Луны.

Но это как правило, если при перезагрузке есть внешний диск или флешка, воткнутая в usb. Если всё только через sata, оно сильно стабильнее, но тоже может уехать иногда.

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

ЕМНИП, во времена мандрейка и аспа, master\slave primary\secondary всегда были hda и hdb, независимо от того, кто после кого был вставлен.

Что есть вполне логично: для системы считать устройства нужно по мере их подключения к физическому порту, т.е. если у тебя на компе винт подключен к порту SATA3, он никак не должен быть sdb, даже если он второй в системе. А пользователи вообще не должны знать об этих телодвижениях, для них придуманы label, существующие с незапамятных времен.

Логично, но с некоторых пор логика нарушилась. Может когда много sata портов стало.

я не особо люблю uuid, мне больше нравятся lvm метки, либо во freebsd тоже есть метки. аж два вида, к сожалению.

crypt@witch ~ $ ls /dev/label/
blender  cache  home  ssd_swap
crypt@witch ~ $ grep ssd_swap /etc/fstab 
/dev/label/ssd_swap	none		swap	sw		0	0

Это на каком дистре так было/бывает? И если «было», то когда приблизительно по временам такое замечено было?
Я почему спрашиваю, у меня совершенно точно бывали варианты с подключенным usb хардом, последний был на поддиванном, отключил меньше года назад, на подобные грабельки не приходилось наступать.

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

Ключевое здесь — «скорее всего». 😉 О том-то и речь, что порядок будет случайным (хоть и не равномерно распределённым). А если вообще без привязки имён интерфейсов к чему-либо, то отвечать на этот вопрос будете после каждой загрузки системы.

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

Решает, но аналогично текущей схеме в Linux — так в чём проблема тогда?

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

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

прошивка умудрилась поменять нумерацию слотов при подключении нового PCI-устройства

как прошивка может поменять нумерацию слотов? это не прошивкой определяется, а bios.

Решает, но аналогично текущей схеме в Linux — так в чём проблема тогда?

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

как прошивка может поменять нумерацию слотов? это не прошивкой определяется, а bios.

О нём и речь.

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

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

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

И да: в FreeBSD с хинтами всё точно так же сломалось бы при таких «прыжках» сетевых интерфейсов по слотам.

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

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

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

Потрясающе, как можно со слепой уверенностью продолжать утверждать, что проблемы не существует, аргументируя лишь «УМВР». И пофиг, что время инициализации оборудования имеет случайные отклонения, которых может быть достаточно для изменения порядка; и наплевать, что с этой проблемой боролись ещё кучу лет назад, внедрив привязку к MAC — разработчики ведь просто глупые и ничего не понимают, а им всего-то надо было спросить anc, УМВР ли у него…

О нём и речь.

эээ... так с чего вдруг bios-то будет менять нумерацию слотов? никогда он ее не меняет. поменялась нумерация девайсов в системе, чисто косяк линукса.

И да: в FreeBSD с хинтами всё точно так же сломалось бы при таких «прыжках» сетевых интерфейсов по слотам.

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

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

Нет, дорогой друг, «закономерный», это когда ты вставляешь носитель с линуксом в комп, и еще до его загрузки знаешь, как будет называться сетевой интерфейс. Тогда например на компе «А» я могу написать скрипт для компа «Б»:

1. Копирую образ ОС на SD-шку;

2. Пишу там в автозагрузке шото типа ifconfig eth0 inet 192.168.бла.бла netmask 255.255.255.0;

3. Вставляю эту SD-шку в условную Малину, или любой другой headless девайс, ребутаю, и коннекчусь по SSH в 192.168.бла.бла

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

А когда я НЕ ЗНАЮ как будет называться мой сетевой интерфейс - это и есть «случайный порядок».

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

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

bios этого не может делать потому что не может делать никогда.

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

Какие ещё случайные отклонения? Совсем пургу гнать начали.

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

Привязка к мак решает другую «проблему», при добавлении ещё одной карточки или при удалении(не всегда по собственной воле, сгорела) старая «останется» с тем же именем.

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

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

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

Сам не знаю, почему у автора это произошло.

эээ... так с чего вдруг bios-то будет менять нумерацию слотов? никогда он ее не меняет.

С появления новых слотов. Ты ж не забывай, что не PCI единым. Стоит тебе воткнуть USB-хаб, и твоя нумерация пойдет по одному месту: был у тебя Bus 001 Device 001: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c), воткнул ты хабчик с донглом клаво-мыши, и вот у тебя уже Bus 002 Device 002: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c), Bus 001 Device 001: Linux Foundation 3.0 root hub, Bus 002 Device 001: A4Tech Co., Ltd. 2.4G Device

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

так что нет, твой пример с хабчиком не канает.

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

Какие ещё случайные отклонения? Совсем пургу гнать начали.

Ясно. Как подучите матчасть¹²³ хоть немного, возвращайтесь.

¹ https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

² https://wiki.debian.org/NetworkInterfaceNames

³ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/consistent-network-interface-device-naming_configuring-and-managing-networking

так это та система, за которую топит Rootlexx

Не нужно выдумывать. Я за неё не топлю, я пытаюсь объяснить, зачем она нужна.

Наверное, если бы существовали /dev-файлы интерфейсов, то было бы что-то типа текущей схемы с носителями данных: есть интерфейс и несколько символьных ссылок на него, зависящих от пути к устройству, MAC, ещё каких-нибудь характеристик…

Кроме голословного «not predictable for modern technology» по первой ссылке (а чего ещё можно ждать по этой ссылке?), ничего интересного.

Вы описываете вариант когда в наличии разное железо в котором больше одной сетевой карты. В этих условиях ни старый вариант, ни вариант с привязкой к мак, ни ненужнод никаким образом не сделает «зашибись». Но в случае старой схемы, вам достаточно потыкать по сетевкам, что бы найти ту которая вам нужна. В случаях с привязкой к мак(если не озаботились удалением информации о старой сетевке) или ненужнод, вам придется тащить моник и клаву. Разницу видим?
Кстати, вот прям в тему вспомнилось, была у меня одна система, проработала с осени 2002 до мая 2021 в кол-ве 34 штук точно. Робило это под слакой разных версий (от времени зависило). Сетевки горели только в путь, собстно как и всё остальное железо, разнообразия по железу за эти годы было мама не горюй, но вот как-то стабильно имя интерфейса было eth0. В случае если бы там был ненужнод, пришлось бы прикручивать ещё какой-то костыль, что не добавило бы удобства. А так в случае замены сетевки, «руки» приехали, поменяли сетевую, проверили что работает (без всяких логинов и других пингов, в системе была заложена проверка работоспособности вызываемая по хитрой комбинации кнопочек) и уехали. Вот это действительно удобно.

Не нужно выдумывать. Я за неё не топлю, я пытаюсь объяснить, зачем она нужна.

Это тебе не нужно выдумывать. Когда ты пытаешься объяснить, зачем нужна нерабочая вещь, то это равносильно «топишь». Пруф с твоих слов:

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

«Не рабочая, а как бы рабочая». (с)

Теперь далее.

Наверное, если бы существовали /dev-файлы интерфейсов

А они и есть:

/dev/disk/by-uuid/2af76541-f1f3-4d5a-8dcb-28941a9ec2a6
/dev/disk/by-id/ata-VBOX_HARDDISK_VBd86c7148-47b5cc1e-part1
/dev/disk/by-id/ata-VBOX_HARDDISK_VBd86c7148-47b5cc1e
/dev/disk/by-id/ata-VBOX_CD-ROM_VB2-01700376
/dev/input/by-id/usb-VirtualBox_USB_Tablet-mouse
/dev/input/by-id/usb-VirtualBox_USB_Tablet-event-mouse
/dev/input/by-path/pci-0000:00:1f.4-usb-0:1:1.0-mouse
/dev/input/by-path/pci-0000:00:1f.4-usb-0:1:1.0-event-mouse
/dev/input/by-path/pci-0000:00:04.0-mouse
/dev/input/by-path/pci-0000:00:04.0-event-mouse
/dev/input/by-path/platform-i8042-serio-0-event-kbd
/dev/input/by-path/platform-i8042-serio-1-event-mouse
/dev/input/by-path/platform-i8042-serio-1-mouse

Наверное, если бы существовали /dev-файлы интерфейсов

А они и есть:

Он про сетевые интерфейсы.

Когда ты пытаешься объяснить, зачем нужна нерабочая вещь, то это равносильно «топишь»

Шта? — ну и бред…

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

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

«Топить» — это яро выступать, болеть за что-то. Перечитайте моё первое сообщение в этой теме и прекратите развешивать ярлыки направо и налево.

А они и есть:

Показывает устройства ввода и носителей данных…

Вы точно всё ещё помните, о чём идёт разговор?

Вы точно всё ещё помните, о чём идёт разговор?

Наверное, если бы существовали /dev-файлы интерфейсов

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

С появления новых слотов. Ты ж не забывай, что не PCI единым. Стоит тебе воткнуть USB-хаб

а ты? сам посмотри, на что отвечал.

«Топить» — это яро выступать, болеть за что-то.

именно это ты и делаешь во всех systemd и anti-systemd ветках. и сюда пришел именно за этим же.

Во-первых, она работает:

во-первых, в топике она НЕ работает. запроси тогда информацию у anon incog и докажи, что она работает.

Он про сетевые интерфейсы.

про сетевые интерфейсы я выше кидал пример с device.hints, но его больше волнует доказать, что он «не топит»

Ну да, а если рекурсивно пройти к самому первому сообщению, то…

Я отвечал ровно на то, что процитировал. И если вас упоминание MAC не навело на нужные мысли, то это не моя проблема.

в топике она НЕ работает

Не работает в одном случае («в топике») ≠ не работает вообще.

именно это ты и делаешь во всех systemd и anti-systemd ветках. и сюда пришел именно за этим же.

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

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

А теперь перечитываем о чем написано в теме «Я воткнул носитель информации и у меня отвалилась сетка». Мне одному кажется, что это больше похоже на создание проблем, а не решение их?
ЗЫ Не знаю почему, но мне вспомнилось «если бы программисты строили дома».

Не работает в одном случае («в топике») ≠ не работает вообще.

Ну да, тема через несколько лет «У меня скончался nvme, я его выдернул и у меня сменились названия сетевых интерфейсов и пропал звук». А nvme гарантированно сдохнет, это не hdd.

Ну да, тема через несколько лет «У меня скончался nvme, я его выдернул и у меня сменились названия сетевых интерфейсов и пропал звук». А nvme гарантированно сдохнет, это не hdd.

Что «ну да»? До вас не дошло, что вы снова написали об этом же самом случае?

Прошу заметить это будет уже другая тема.

PS Из личного опыта. В прошлом году на поддиванный ( с тремя сетевками ) забубенил новый камешек, из-за того что новый куллер малька побольше, не все старые сетевки влезали, пришлось одну заменить на мелкий pci-e, а другие на слот переместились. Если бы был ненужнод, вот бы мне неожиданная радость подвалила по всему /etc, а может и не только, грепать с целью замены имён интерфейсов. Что-то в духе «ваша радость не будет полной, если вы помимо железа ещё и софтверную часть не поломаете». А так, собрали железку, включили, работает. Для моей пользы (с) однозначно профит.
Вообще вдумайтесь в формулировку «из-за того, что я добавил носитель информации и проапгрэйдил камень, мне пришлось перенастраивать систему». Это по вашему нормально звучит?

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

И да, переименовывает интерфейсы не systemd, а udev, который у вас, полагаю, также в наличии. Возможно, у вас просто старая версия, или же в нём это отключено.

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

Нет, описанное в топике это ненужнод. udev переименовывает в привязке к маку

Таки нет, это делает udev. Просто в последнем поменяли политику по умолчанию.

Пользую udev с тех пор как его Патрик завез, а было это очень давно, имена интерфейсов вида ethX.

Я ж написал:

Возможно, у вас просто старая версия, или же в нём это отключено.

Ну или у вас eudev — не знаю, что там в Slackware.

Интересно каким образом параметр ведра может влиять на поведение udev? Я не оспариваю то что вы пишите, но мне кажется что вы ошибаетесь.