Как зафиксировать имена жёстких дисков?

А какая у тебя модель блока питания и материнки?

Дай вывод sensors и smartctl -x проблемный диск.

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

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

Почему в какой-то момент имена /dev/sd* стали скакать?

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

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

Оказывается не так давно это всё случилось.

Before kernel 5.3, devices would always be probed in the order in which they exist on the bus, resulting in the first device being named 'sda', the second device 'sdb', and so on. Controllers could be probed in parallel but the devices would still appear in the same order on a per-controller basis. If there was only one controller, they'd be predictable as long as new devices weren't added in the middle.

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.

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

Диски скачут, потому что ядро назначает имена как под руку зайдёт, а потом udev подключается, так что никакой проблемы и нет. Видимо ты напутал.

Диски скачут, потому что ядро назначает имена как под руку зайдёт

Ядро инициализирует устройства. Имена дискам раздает удев. Удев - часть системды. Так понятнее?

Когда я сидел на генте с ядрами 5.х, я о проблеме и не подозревал. Веселье началось с лайвами опенсюсе 15.4 и дебиан 11. Когда я попытался пересесть с генты на что-нибудь бинарное, первым делом словил незагружающуюся систему, потому что имена дисков стали рандомными. Начал раскопки и докопался. Причем лайв федоры грузился как надо и имена не путал. Про всякую маргинальщину ничего не могу сказать, нет столько свободного времени.

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

П.С. сейчас в /etc/fstab разделы монтируются по /dev/sdX, никаких проблем

У тебя несколько сата и в fstab было /dev/sd* бла-бла?

выстрел мимо. udev и задолго до системд нумеровал диски в порядке поступления данных с осмотра системы :)
в генту не думаю чтоб сильно другой алгоритм.
для точной привязки устройств аккурат и не надо использовать эту систему автоматической нумерации :)
система /dev/disk/by-* для этого и внедрена.

Именно

выстрел мимо. udev и задолго до системд нумеровал диски в порядке поступления данных с осмотра системы :)

Вы вообще читаете комментарии, на которые отвечаете? Или просто встретили знакомое слово «udev»?

«удев - часть ситемд» вот про это :)
ну и про это «разделы монтируются по /dev/sdX».
никто и никогда не обещал, что нумерация sdX останется неизменной при изменении параметров системы. (и даже, о ужас, до системды).
sdX, сколь помню, линейно увеличивается по мере выявления носителей - меняешь их порядок, включаешь еще один носитель чуть «раньше» текущего и номера сдвигаются, что естествено.

номера сдвигаются, что естествено

Как выяснилось, естественно с появлением ядра 5.3

интересно, а какой есть иной алгоритм выбора sd(a,b,c,d…)(1,2,3,4…) ?? мне вот просто интересно.

Ссылку выше дал. Раньше по расположению на контроллере (я хз, как правильно называется), детерминированно, а теперь нет, вот они и скачут. А привязывать точки монтирования теперь через всякое в /dev/disk.

Так я понял.

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

удев - часть системд

Не вырывайте из контекста.

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

Параметры системы не меняются никаких динамических массивов и всего такого. Монтирование /dev/sdX работало годами, имена дисков не прыгали. Проблемы начались совсем недавно, когда в недрах системды что-то поменяли.

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

на самом деле тупо отключение новой фичи

Нет, не это. К тому же врядли это можно отключить

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

Ссылка была из твоей зюзи.

Глянь по ссылке со слов

In case the behaviour is not desired for a given reason, use the option ...

Я на буржуйских форумах натыкался на описание. Но проблема была именно в системде.

Можно ссылку?

Можно ссылку?

Увы. Если бы можно было, я бы давно скинул. Теперь надо заново искать. В свое время я этой проблеме посвятил много времени.

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

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

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

что бы где бы не поменяли UUID прописанный в разделе неизменен.
«меня утомляет» рассказывать давно известные постулаты :)

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

Вот это в ядре отключить надо: CONFIG_SCSI_SCAN_ASYNC

Можно ссылку?

Вот:

https://lore.kernel.org/lkml/59eedd28-25d4-7899-7c3c-89fe7fdd4b43@acm.org/t/

но проблема не в systemd.

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

что бы где бы не поменяли UUID прописанный в разделе неизменен

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

В случае с /dev/sdX, как правило, всегда известно, где какой диск находится. UUID хорошо подходит для съемных носителей, куда бы его не воткнули, он смонтируется как надо. А для статичного использования все плюсы исчезают. К тому же, покажите мне хоть одного человека, который сможет этот UUID или PARTUUID запомнить и по памяти воспроизвести. А с /dev/sdX трудностей не возникает.

исчо раз никто не обещал стабильность в нумерации sdXX.

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

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

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

Конечно никто не обещал, оно просто работало.

Это как полагаться на UB - плохая идея.

если уж очень сильно хочется привязаться именно к железякам, то используй систему привязки к идентификаторам носителей /dev/disk/by-id
или более хардкорно пути расположения железяк на материнке /dev/disk/by-path
они заявленно стабильно привязаны к параметрам именно железяк.

но нет :)
мы будет писать за углом подъезда - в детстве же работало и никто не косился.

п.с.: на протяжении много лет i686 прекрасно работало, а тут херакс и слили цельный пласт оборудования в реку стикс.
вот ведь 321сы….

Вот это в ядре отключить надо: CONFIG_SCSI_SCAN_ASYNC

а можно это как то в grub в параметры ядра ядра прописать?

От версии ядра зависит.

Есть, например, такой параметр:

driver_async_probe= 
  List of driver names to be probed asynchronously. *
  matches with all driver names. If * is specified, the
  rest of the listed driver names are those that will NOT
  match the *.
  Format: <driver_name1>,<driver_name2>...

Читай доки (для своей версии ядра):

https://www.kernel.org/doc/html/v6.4/admin-guide/kernel-parameters.html

да кстати, вспомнил еще вариант
можно еще сделать свое правило udev, которым по необходимым аппаратным идентификаторам будет создавать файл устройства с заранее указанным именем.
оно будет неизменно.
в принципе, это будет тот же by-path/ by-id/ только с желаемыми sdXX именами.

если уж очень сильно хочется привязаться именно к железякам, то используй систему привязки к идентификаторам носителей /dev/disk/by-id

или более хардкорно /dev/disk/by-path

попробуйте это без ошибок вписать в fstab. Скажу по секрету: /dev/sdX - это тоже «пути расположения железяк на материнке». Причем гораздо более простые в понимании.

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

когда нет аргументов, начинается кривляние и демагогия.

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

оно будет неизменно.

Больше костылей богу костылей?

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

Да, походу решение лежит здесь.

Ты чего в танк-то засел? Ядро так работает же, ну.

вписать в fstab вместо /dev/sda1 строчку /dev/disk/by-id/ata-WDC_WD2500AAKS-00VSA0_WD-WMART1918109-part1 или /dev/disk/by-path/pci-0000:00:08.0-ata-1-part1 один фиг это симлинки на /dev/sda1. смотри что у тебя прописано

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

а вот /dev/disk/by-path привязывается именно к «пути» дерева подключенных устройств, что и отображается в имени. и при переподключении носителя на другой аппаратный канал имя естественно изменится.
в отличии от /dev/disk/id который привязывается к аппаратным именам устройства, чуть выше это к примеру «название фирмы производителя и название винчестер». и он не зависит от того к какому каналу носитель подключен.
и т.д.

Больше костылей богу костылей?

аккурат наоборот. если не нравятся дефолтные настройки системы, делаешь свои.
производитель не особо заинтересован учитывать все хотелки всех пользователей, афигеешь от них :)
делаешь правило udev и своему носителю уникальное имя, оторванное от системы дефолтной системы перечисления. к примеру /dev/sd_moy_nositel и получаешь свою хотелку с неизменным именем устройства.
можно остаться и с /dev/sda просто номер в имени файла своего правила поменьше чем дефолтные.

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

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

решение лежит здесь

вот как это выглядит у меня, на машине два винта, на винтах разные системы - при запуске систем винты могут определяться каждый раз по разному - sda или sdb, на работу систем это не влияет - так как они привязаны к uuid, сами системы нигеде и никак не пересекаются, даже в grub не видят друг друга… делаю следущее - запускаю систему на первом носителе, в grub затираю uuid и прописываю sda1, жму F10 и у меня стартует система со второго носителя - потому что оказыватся это он sda, я когда впервый раз такое увидел - не поверил своим глазам и даже переповторил этот трюк, что бы убедиться в реальности происходящего… жесть какая то - корень должен быть прибит к определенному разделу, а кому это нинужно это просто идиот с одним винтом.

Сделай себе такой grub.cfg и не парься:

cat /boot/grub/grub.cfg 

### BEGIN ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="default"
fi



### MENU ###
set timeout=2


menuentry 'Gentoo Linux 6.2.0' {
    linux   /vmlinuz-6.2.0-gentoo root=PARTUUID=0E92B818-EF52-42E1-8C30-D56145032E71 clocksource="tsc" nomodeset
}


menuentry 'Gentoo Linux 6.2.1' --id default {
    linux   /vmlinuz-6.2.1-gentoo root=PARTUUID=0E92B818-EF52-42E1-8C30-D56145032E71 clocksource="tsc" nomodeset
}

вписать в fstab вместо /dev/sda1 строчку /dev/disk/by-id/ata-WDC_WD2500AAKS-00VSA0_WD-WMART1918109-part1 или /dev/disk/by-path/pci-0000:00:08.0-ata-1-part1 один фиг это симлинки на /dev/sda1

нет, в корне неправильно

ничего не понимаю - думал это решение проблемы, но это «в корне не правильно» или я чего то не правильно понял?

Сделай себе такой grub.cfg

а чем это отличается от моего?

linux   /boot/vmlinuz-linux root=UUID=4c22e04f-b907-4bbb-a3c1-54c8cec1d674 rw  quiet

UUID – более сложная штука, это инфа о фс, а PARTUUID – более простая, это инфа о разделе, поэтому она работает без initramfs…

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

UUID

PARTUUID

так вот где собака зарыта? сейчас попробую.

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

в инитрамфс вообще много чего делается по формированию системы.

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

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

Ну что не понятно-то? Времена, когда юзеры юзали для своих нужд имена sda, sdb и тд ушли, теперь /dev/disk.

Потому что ядро рандомно их присваивает, а уже потом по всяким другим «именам» мы монтируем диски, куда надо. Именно поэтому нельзя тупо монтировать /dev/sd* через fstab, если у тебя больше одного диска.

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

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

UUID – более сложная штука, это инфа о фс, а PARTUUID – более простая

не работает это шняга

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

Первый список получен скриптом из initrd, или команда руками вводилась? Во втором случае секунд задержки от ручного ввода могло уже хватить.