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

Дык скачут имена?

В общем, если ничего не менять, то мы должны забыть все эти sd*.

У меня два ссдешника и я никогда не знаю какой из них после перезагрузки sda или sdb.

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

Нет, раньше оно могло работать только с PARTUUID, если без initramfs.

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

что там у тебя не работает?

и ты же понимаешь, что PARTUUID и UUID это разные UUID, т.е. разные значения?

Лейблы

да? предположим у разных ситем одинаковый лейбл root что из-за этого такая путаница? мало вероятно, у меня есть флеха с установленым arch лйбл root - в одной машине она определяется как sda, в другой как sdb, а после перезагрузки наоборот определиться может, хотя на других винтах нет систем с таким лейблом.

хз. было поломато ??

разные значения?

как определить текущий PARTUIDD?

потому и ввели UUID в состав фс (оно есть не у всех фс). у него очень малая вероятность совпадения.

sudo blkid

Begining with kernel 5.3 the order in which SCSI devices are probed and named has become non-deterministic.

Охренеть.

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.

А можно не надо? Или, всё же, есть опция для отключения этого?.. Придётся читать.

хз. было поломато ??

Проверил на виртуалке. Сейчас тоже не работает.

А можно не надо? Или, всё же, есть опция для отключения этого?..

выше ссылку на опцию ядра я кидал

Если клонируешь диски — то да, придётся по-другому, а если просто даёшь одинаковые лейблы, то ссзб.

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

Это касается почти всех в этом треде.

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

/boot/grub/grub.cfg 
<------>linux<->/vmlinuz-5.15.0-75-generic root=UUID=58c04197-097a-4265-add4-73a0780f787a ro  mitigations=off
<------>initrd<>/initrd.img-5.15.0-75-generic

Вроде есть возможность, но нафига бороться, проще заглянуть в /dev/disk и выбрать вариант по душе.

выше ссылку на опцию ядра я кидал

Да, увидел уже, спасибо.

Спасибо, нет 😁

initrd<>/initrd.img-5.15.0-75-generic

Ну так у тебя есть initramfs, а у меня – нет. С initramfs будут и LABEL работать, а без него – не будут.

К твоему удаленному комментарию, а то я уже ответ написал:

Ну я точно знаю, что без initramfs ядро успешно найдет корень по PARTUUID, а вот по LABEL и UUID оно не найдет. Почему так – я не знаю, возможно опрос и формирование списка устройств по UUID идет сильно позже в коде ядра, чем монтирование корня, возможно они завязаны на то, чтобы корень уже был, типа туда смонтирует proc sys и будет туда писать таблицу устройств с UUID, а раз этого нет, то и нет… хз.

погуглил - признаю.
без инитрамфс говорят есть только PATUUID и PARTLABEL для gpt.
имхо странно, но ладно. это не баг, а фитча.

Ну выглядит логично: вначале ядро обнаруживает разделы на дисках, начинает всякие процессы, а потом уже смотрит что там на этих разделах есть, и для этого ему уже корень хочется иметь подмонтированным, т.к. там логи, /proc, /sys и пр.

у меня вопрос лишь в том, почему наличие инитрамфс добавляет возможность UUID корневого раздела ??
предположу в инитрамфс впихнута udev служба инициализирующая UUID фс. а без udev UUID фс не инициализируется.
причем почему такая вариабельность именно с параметром корня ядра… он очень рано используется. до «всех этих ваших» удевов или нет…

сколь помню внутрянку инитрамфс, чтото из системных рамдисков, типа /proc /dev не помню кто именно, скриптом в инитрамфс и монтируются. причем именно скриптом :)

Потому что initramfs это фактически полноценная загрузка linux, оно монтирует свой рут, потом стартует ряд сервисов, запускает процессы, а потом переключается на твой рут. Я делал когда-то для своего ноута свой initramfs, чтобы ноут был полностью зашифрован.

Моя система два диска: ssd, hdd.
На ssd три раздела: корень debian, корень для экспериментов (опробования новых дистрибутивов), swap.
hdd отдан под общий /home
При установке форматируется swap и UUID его каждый раз меняется, после каждого эксперимента меня заколебало ползать в fstab, прописал /dev/sdb3 и в ус не дую.
Компьютер - ноут перетыканий изменений не предвидится.
Знаю в ubuntu подсмотрел можно swap-файл сделать, но пока по старой схеме всё работает.

да. на инитрамфс полноценно и собираются все лайв-образы - вполне удобно, малогабаритно и ненапряжно.
на то он и «инит».

mkswap --help
 -U, --uuid UUID           specify the uuid to use

мож лучше так ?? uuid и должон быть каждый раз уникальный.

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

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

привяжись лучше к by-id или by-path они более стабильны.

кстати интересен вариант, когда каждый раз разные носители будут выигрывать доли микросекунд и sdXX будет каждый раз разные :)

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

добавить в /etc/default/grub

GRUB_DISABLE_LINUX_UUID=true
GRUB_DISABLE_LINUX_PARTUUID=false

выполнить реконфигурацию и теперь корень будет прибит к /dev/sda проверено 5-ю выключениями\включениями и 5-ю перезагрузками

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

# cat /proc/cmdline 
initrd=\opensuse-tumbleweed\6.3.9-1-default\initrd root=/dev/sda1 rootfstype=ext4 rw mitigations=off

как-то так

добавить в /etc/default/grub

А если нет груба?

А как в systemd-boot? У меня гробов нет.

А как это автоматизировать?

А как это автоматизировать?

Что именно?

как обычно man systemd-boot :)

У меня гробов нет

а у меня systemd-boot нет, я воспользовался подсказкой root=PARTUUID=xxxxxxxx, посмотрел его командой # blkid, вовремя загрузки системы пока висел grub нажал E и подменил UUID на PARTUUID, загрузился в такой конфигурации и увидел что корень находится в /dev/sda1, повторил эту операцию многократно и с перезагрузкой и с выключить\включить, убедившись что имя диска не меняется - начитался мануалов как так сгенерить grub.cfg что бы вместо UUID был PARTUUID… всё, а тебе очевидно надо начитаться мануалов как в systemd-boot вся эта хрень делается.

Экий ты затейник!

Смену ядра.

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

А точно GRUB_DISABLE_LINUX_PARTUUID=false, а не true?

#погугилзатебя :)
надо какнить поковырять сию систему.
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

/boot/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf
title      Fedora 19 (Rawhide)
version    3.8.0-2.fc19.x86_64
machine-id 6a9857a393724b7a981ebb5b8495b9ea
options    root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2
linux      /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux
initrd     /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd

так понимаю параметр options root=PARTUUID=**** спасет отца русской демократии :)

надо конечно еще глядеть генератор конфигов загрузки systemd-boot для автоматического подхвата ядер.

Смену ядра

Я потерял нить повествования. Зачем менять ядро?

Оно автоматически прописывается куда надо при обновлении?

Оно автоматически прописывается куда надо при обновлении?

Я вас совсем не понимаю. Что куда прописывается и зачем и причем здесь ядро?

Если вас интересует /dev/sdX то ядро тут нипричем.

наверно, иногда старые способы в экзотических случаях, применение находят. )

качнул пакет - хуки на обновление ядра есть.
systemd-boot_251.4-1ubuntu7.1_amd64.deb/deb://CONTENTS/etc/kernel/postinst.d/systemd-boot

#!/bin/sh

set -e

test -x /usr/bin/bootctl || exit 0

bootctl is-installed --quiet || exit 0

echo "Installing kernel version $1 in systemd-boot..."

kernel-install add "$1" "$2"

погугилзатебя

Что? Зачем?

cat /boot/efi/loader/entries/opensuse-tumbleweed-6.3.9-1-default.conf 
# Boot Loader Specification type#1 entry
# File created by /usr/lib/kernel/install.d/90-loaderentry.install (systemd 253.5+suse.29.g07bb12a282)
title      openSUSE Tumbleweed
version    6.3.9-1-default
sort-key   opensuse-tumbleweed
options    root=/dev/sda1 rootfstype=ext4 quiet rw mitigations=off
linux      /opensuse-tumbleweed/6.3.9-1-default/linux
initrd     /opensuse-tumbleweed/6.3.9-1-default/initrd

так понимаю параметр options root=PARTUUID=**** спасет отца русской демократии :)

PARTUUID

лишняя сущность

непривычно видеть корень на sdb1, на этом вроде всё

а мне это нужно по другим причинам, температура винтов в коньках и tlp, температура как бы то же не критично, ну поменяются значения местами - ерунда, главное что бы эти значения не были критическими, а вот с tlp затык, в настройках DISK_DEVICES=sdb, а оно систему в sdb пихает и винт начинает постоянно останавливаться для экономии и тут же стартовать для чтения\записи, всвязи с чем возникают неприятные звуки, а sda который теперь фактически не нужен - наоборот постоянно крутится и грется.

GRUB_DISABLE_LINUX_PARTUUID=false

выключить выключение PARTUUID, а выключение UUID наоборот включить, одно не пойму - почему оно по дефолту включено, может выключить и c UUID нормально заработает - надо пробовать… попробовал - порожняк, все лекарство получается в одной строке GRUB_DISABLE_LINUX_PARTUUID=false

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

В смысле не в этом вопрос, а это видимо работает так же.

Я видать не допёр, что у тебя тоже systemd-boot.

Тогда ясно, да, прописать чего надо в /etc/kernel/cmdline и всё.

А вместо sdb не можешь прописать что-то из /dev/disk?