Очень интересно!

Вот жеж. Скачайте лайв и проверьте, делов-то.

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

У «живых юзеров» тоже возможно

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

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

Запусти в виртуалке намонтируй 100500 дисков, проверь.

ЩИТО? Нет, я конешно не мониторю это, но это было бы очень странное поведение, не? Названия дисков меняются только если использовать другой sata/m2-порт, если я не ошибаюсь. Никогда такого не слышал.

Где ж взять виртуалку-то?

Опа, ещё один из криокамеры выскочил.

Я не собираюсь 100 раз перезагружать ПЭКА, чтобы проверить, что они не меняются.

Ладно-ладно, не суетись, я просвещу. Начиная с ядра, ЕМНИП, 5.3, теперь ядро рандомно присваивает названия, ради ускорения инициализации дисков, делает это по мере обнаружения и как бы одновременно.

Очередной виток.

Но кто-же читает…

Повторим?

они не меняются

Begining with kernel 5.3 the order in which SCSI devices are probed and named has become non-deterministic. This is a result of a change that was submitted to add asynchronous device probing.The probing happens asynchronously on a per-device basis, so even devices on a single bus can appear in "random" order. The logic behind the change is that if you will have dozens of disks, one wants them to start as early as possible, instead of probing/failing/waiting in a synchonous way; in an environment where there are hundreds of disks, and even more partitions, this change is even more important.    

https://www.suse.com/support/kb/doc/?id=000018449

Ты имеешь в виду, что оба загрузочных?

Лет 10 назад на домашнем компе прописал что-то в fstab чтоб HDD XFS c файлами монтировалась в ~/Data. Система на SSD. Ни разу не вспоминал об этом, т.к. проблем нет, соотвественно, нужды проверять что там творится, не было.

На ноуте, что под рукой, только один SSD.

Ты имеешь в виду, что оба загрузочных?

Не.

У меня два ссд – на одном система, а другой для «мусора», так вот они постоянно меняются названиями между собой при перезагрузке.

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

У тебя мусорный прописан в fstab?

Конечно, по uuid, как положено.

systemd тут ни при чём, это идиотизм в ядре. У меня кстати давно не менялись, хотя одно время каждая третья загрузка фейлилась т.к. системный диск оказывался на sdb.

Тоже пофиксили?

Fedora 38, 2 hdd, 1 ssd загрузочный. Замены имён дисков не видел, но не могу утверждать, что замен не было - в fstab настроено монтирование по LABEL.

Обрати внимание, когда будешь перегружать, интересно!

меняются ли рандомно названия /dev/sd* у дисков

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

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

Видимо ядро было старше 5.3

Как «федораст» со стажем, я развею твои сомнения: нет, не меняются.
Товарищ utanho таки прав.

После загрузки посмотрите lsblk, он покажет кого как смонтировали.

Я специально гонял пт кругу лайв федоры. Много раз. Ни единого разрыва.

У дебиана 11 и 12, у сюси 15.4 - рандом. В тумблевиде всё нормально.

не Fedora, Gentoo

на USB висят 3 диска, иногда бывает что меняются местами, в зависимости от скорости раскрутки-определения параметров,
поэтому использую /dev/disk/by-label/ (можно и другие варианты использовать)

возможно у вас похожий случай

А я оч. долго сидел на Федоре.

У тебя и у меня штатная ситуация, так и должно быть.

Интересно послушать тех, у кого не меняется, а ещё интереснее услышать как так получается.

Я допускаю, что в новых версиях udev что-то допилили, но что и зачем пока никто не сказал.

Я вот даю ссылку почему дела обстоят так и интернет полон ответов на этот вопрос в таком же духе, но не получил ссылок объясняющих, почему и как это где-то починили. Тем более, когда ничего и не поломали 😁

Мне под подобными названиями (очень интересно/весьма любопытно…) приходит на почту спам с предложениями присоединиться к различным инвест-проектам…

да. use uuid|labels, luke

А я на генте. Там такого безобразия не было.

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

Сосбственно поэтому я и тычу пальцем в системду

Сейчас стоит сюся тумблевид. Монтируется по /dev/sdX. Никаких проблем

Такой shit happens sometimes независимо от дистров. Потому юзайте UUID или scsi path и ваши волосы будут мягкими и шелковистыми.

Устройства /dev/sd* мне нужны для скриптов 1-2 раза в месяц, и я не сталкивался с ситуцией, что они неправильные...

Дык монтируются по LABEL, всё всегда правильно. Ну, если сам не накосячу при редких переделках партишенов на дисках 😁

я к тому что иногда может возникать болтанка внутри /dev/sd(a|b|c|...) между одними и теми же дисками при перезагрузке.
как я понял ТС об этом тред завел.
я бы ещё к своему ответу добавил бы serial|wwn

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

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

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

Да вообще убрать эти /dev/sda, зачем они нужны.

sd* зло в духе виндовых букв диска, при наличии /dev/disk/

Дык убрали уже, но нет, кто-то ещё монтирует таким макаром.

Если бы убрали, то не монтировали. Или я что-то не так понял? По-мне если кому-то надо /dev/sda, пускай эти девайсы юзерспейс создаёт в конце init-а, когда уже всё точно успело проинициализироваться и с порядком вопросов нет. udev там какой-нибудь. А в inittab оно просто не должно работать, тем более раз оно и так по факту надёжно не работает из-за случайного порядка, ну и пусть не работает уже надёжно и стопроцентно.

Наверняка ведь есть юзеры, которые перезагружают компьютер пока он не заработает, т.к. прописали /dev/sda по какому-нибудь тупому гайду 20-летней давности. Зачем им страдать? Пристрелить и всё.

Нет. И вообще:

Вы все еще имейте в системе название дисков /dev/sd*, тогда NVMe идет к Вам!

2023-07-31 РАПОРТУЮ: была перезагрузка, буквы сохранились.

Глянул на домашнем диск в fstab прописан по имени /dev/sdb1 а не по uuid. За 10 лет не замечал проблем, значит не меняется.

А точнее какой расклад? И что в fstab?

Интересно. Что за диски? Куда воткнуты?

/dev/mapper/fedora-swap: UUID="-cut-" TYPE="swap"
/dev/sdb1: LABEL="data" UUID="-cut-" BLOCK_SIZE="512" TYPE="xfs" PARTUUID="-cut-"
/dev/mapper/fedora-home: UUID="-cut-" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/fedora-root: UUID="-cut-" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sda2: UUID="-cut-" TYPE="LVM2_member" PARTUUID="-cut-"
/dev/sda3: LABEL_FATBOOT="kolibrios" LABEL="kolibrios" UUID="-cut-" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="-cut-"
/dev/sda1: UUID="-cut-" BLOCK_SIZE="1024" TYPE="ext4" PARTUUID="-cut-"

fstab:

dev/mapper/fedora-root /                       ext4    defaults        1 1
UUID=-cut- /boot                   ext4    defaults        1 2
/dev/mapper/fedora-home /home                   ext4    defaults        1 2
/dev/mapper/fedora-swap swap                    swap    defaults        0 0

# Mount Toshiba 250Gb drive
/dev/sdb1 /home/user/Data    xfs  rw,users,defaults    0 2