Именование дисков (sda, sdb, sdc...). Как поменять порядок?

На /dev/disk/by-path заменили бы, немного его именование сократив, а то там слишком многа букаф.

sd? и nvme?n? ты переименовать не можешь, в отличие от сетевых интерфейсов, только создавать ссылки.

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

давайте призовём Поттеринга

Понадобится - призовём.

На армах по UUID не загружается, надо PARTUUID.

Как уже сказали, имена /dev/sdX не являются чем-то надежным, их порядок не определен. У меня тоже от этого был моральный дискомфорт, я всю жизнь думал, что это что-то постоянное, а это не так. Можно назначить файлам устройств постоянные имена, но вот здесь пишут, что лучше не надо. Лучше дать им еще псевдонимы, которые не будут пересекаться с их изначальными именами. Плюс в том, что их можно сделать короткими и осмысленными.

Создать файл /etc/udev/rules.d/10-local.rules

KERNEL=="sd*", ATTRS{model}=="<model>" SYMLINK+="rootdrive%n"
KERNEL=="sd*", ATTRS{model}=="<model>" SYMLINK+="anotherdrive%n"
...

udevadm info --attribute-walk --name=/dev/sdX | grep -i 'model'

Подробности.

Еще лет 10 тому линух не страдал херней. Все эти sda adb были каждый на своем месте, а теперь ведет себя совершенно рандомно, меняя а на b время от времени.

Так выглядит начало апокалипсиса.

я так понимаю, ты борешься с race condition пихая всё в один поток

Начитался этой темы, сделал себе:

# cat /etc/udev/rules.d/sda-alias.rules
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="319cfe49-3eb9-49a9-b0e5-4d8d5236e2e0", SYMLINK+="Zarch"
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="0559f56c-21f8-4bc9-aa2b-83a434592f12", SYMLINK+="Zubuntu"
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="b3bc74a0-4f14-46b7-bdb2-f67274c661b0", SYMLINK+="Zvoid"
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="f202e161-153b-4b16-8079-b97ec10bee68", SYMLINK+="Zhome"

# ls -l /dev/Z*
lrwxrwxrwx 1 root root 4 ноя 18 00:41 /dev/Zarch -> sda3
lrwxrwxrwx 1 root root 4 ноя 18 00:41 /dev/Zhome -> sda5
lrwxrwxrwx 1 root root 4 ноя 18 00:41 /dev/Zubuntu -> sda4
lrwxrwxrwx 1 root root 4 ноя 18 00:41 /dev/Zvoid -> sda6

В прошлой теме про RNDIS было интереснее, в плане человечьего именования, вместо страшных букв. Но там и устройства были «net», которым таки можно менять сам NAME, в отличие от «block».

# cat /etc/udev/rules.d/rndis.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="rndis_host", NAME="Zrndis%n"

UPD: Кстати, поменял и rndis по аналогии тогда уж. Венгерская нотация, так венгерская нотация.

Класс! ;) Примеры возьму на вооружение

Их не надо запоминать. Один раз в удаве наконфижить и всё.

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

Но там и устройства были «net», которым таки можно менять сам NAME, в отличие от «block».

Дискам тоже можно задать сам NAME, а не только SYMLINK, если верить доке. Я это не проверял, но думаю, что если имена дать не sd?, то ничего плохого не случится.

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

Это и есть изменение топологии. Если ты про то, что онлайн перетыкание приводит к смене буквы, то это более безопасное поведение, чем использование освободившейся — вдруг это не тот же самый диск? :)

Может, что-то поменялось, но раньше такие правила просто не работали.

с херали ??
UUID это параметр файловой системы (не всех). к аппаратной части процессора оно имеет отношение как собака к луне.

Тем не менее по UUID грузится не желает, ждёт этот UUID, но его нет...

хех, даж интересно стало, UUID читалка в ядре отвалилась?? :-\
а чего говорит blkid, ls -l /dev/disk/by-uuid ??

ls -l /dev/disk/by-uuid

Вот этого пути не знал, благодарю.

хех, там цельна пачка папок с by-**** генерит и удаляет емнип udev или udisk. я в них путаюсь.

это не в ядре, а в udev

в ядре PARTUUID

Ну да, но ведьэ то неправильно. Ведь так красиво: sda, sdb, sdc , 1,2,3, все понятно, коротко, удобно. Нет, теперь все толсто, жирно, неудобно, нерационально.

Я еще помню времена, когда, например, работали скайп-касты на 2g рамы, и 2 ядрах, одновременно качалось и куча чего делалось и даже ноут не издавал звука взлетающего самолета. А потом появился революционный прогрессивный зум. А мы тут со своими sdX носимся, эх…

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

кстати глянул в бутявку - ядру указание на рут-раздел передается аккурат через uuid т.е. он сии циферки знает.

Тут, похоже, у людей каша в голове не хуже, чем у меня.

Насколько я понимаю на текущий момент:
/dev заполняет udev в пространстве пользователя. Все эти плюшки с /dev/block /dev/disk/ /dev/disk/by-uuid - его рук дело. Самому ядру они нафиг не нужны.

У меня тут тренировочный Alpine загружается по UUID на root. И без udev (как в Alpine по умолчанию) - никаких зацепок в /dev не смог найти. Только в /sys упоминается.

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

после инициализации ядра на эту структуру натравливается udev (хотя он наверное может дополнительно перечитывать аппаратные шины) но да херъ с ним.
так что uuid может лежать в структуре описания набортного железа и до запуска udevd/udiskd (кстати чем они отличаются ??) не светиться более нигде.

нужон тот кто знает, что делается в ядре,а не наши кухонные разговоры… :)

Alpine загружается по UUID на root

С initramfs загружается, или голое ядро?

Раньше ядро понимало только устройство в ″root=/dev/zzz″. Потом, году в 2005 стало понимать ″root=PARTUUID=fff". Поддержку поиска root-устройства по uuid файловой системы, вроде, в ядро не добавляли.

Все эти плюшки с /dev/block /dev/disk/ /dev/disk/by-uuid - его рук дело.

Да, причём udev запускает внешний код для определения метки и пр., типа ata_id, scsi_id. Хотя эти программы и идут в составе пакета udev и разрабатываются вместе.

Никаких готовых таблиц/структур ядро не хранит. libblkid, используемый в udevd, сам анализирует суперблоки, драйвер ФС в ядре не участвует в определении метки (label) файловой системы и т.д.

С initramfs загружается, или голое ядро?

Вот так запускается из gummiboot:

root@alpine2:/boot/loader/entries$ cat alpine.conf 
title    Alpine
version  default
linux    /vmlinuz-lts
initrd   /initramfs-lts
options  root=UUID=cf27a8e7-729b-49c6-8c50-22b9c4234ca8 ro modules=ext4 rootfstype=ext4

И еще одно исправление: но cat /proc/cmdline у них немного разные: Это ELILO:

BOOT_IMAGE=scsi0:/vmlinuz-lts  root=UUID=cf27a8e7-729b-49c6-8c50-22b9c4234ca8 modules=ext4 rootfstype=ext4 ro

initrd=\initramfs-lts root=UUID=cf27a8e7-729b-49c6-8c50-22b9c4234ca8 ro modules=ext4 rootfstype=ext4

libblkid, используемый в udevd, сам анализирует суперблоки

Исходник настоящего blkid из util-linux я не осмыслил. Но из busybox blkid более/менее понял. Он тупо все в (пардон, ошибся, поправляю) /proc/partitions перебирает и считывает UUID непосредственно из внутренностей.

С initramfs загружается, или голое ядро?

Потренировался ещё немного - похоже ключевое слово для UUID в cmdline «modules=ext4».

Т.е. если бы ядро было собрано с CONFIG_EXT4_FS=y (а не m), то и этого бы не надо было для запуска с root=UUID.

А так - да. В самом ядре, насколько я понял, в init/do_mounts.c перечислены 9 возможных вариантов, независимых от ФС, в т.ч. PARTUUID.

Просто в документации к ELILO было написано, что не может почему-то.

Не знаю, касательно ELILO, в обычно LILO в документации было написано, что в конфиге нельзя писать:

root=UUID=Bla-bla

append="root=UUID=Bla-bla"

ключевое слово для UUID в cmdline «modules=ext4»

Это от используемого initramfs (initrd) зависит. Некоторые безусловно грузят модули extfs, некоторые при генерации создают такой образ initramfs, что там будет безусловная загрузка модуля текущей корневой ФС. Хорошо, что хоть «UUID=» у всех одинаково задаётся.