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

Ядро монтирует? С какого перепугу?

разупорина прими

Параметр ядра root=/dev/sda1, например. Кто по-твоему монтирует?

initrd

А смысл в этих патчах, если ядро умеет монтировать по идентификатору раздела?

ядро умеет монтировать по идентификатору раздела?

Как?

 $ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.14.13-m root=UUID=78dc0113-65fa-4957-8424-702e2a080265 ro quiet ....

ядро собрано без патчей

Если я правильно понимаю, то параметр root=UUID=78dc0113-65fa-4957-8424-702e2a080265 обрабатывается скриптом в initramfs, а не ядром.

Нет, можно собрать ядро без поддержки initrd, но с поддержкой встроенной командной строки.

с поддержкой встроенной командной строки

Опять же, если я не ошибаюсь, то эта «встроенная командная строка» — это как раз строка для параметров ядра. Командовать там особо не чем. Я не прав?

Как это нечем? Вот, например, у меня ядро грузится в режиме UEFI через EFI-stub, без бутлодера. Как оно поймёт, на каком разделе корень системы? Через встроенную командную строку. Там же можно, скажем, заодно задавать параметры монтирования (если тебе нужно data=writeback на корне с ext4, например) и параметры модулей ядра.

Как оно поймёт, на каком разделе корень системы? Через встроенную командную строку.

И каким образом ты указываешь root? По UUID? По label?

Лично я указываю root=/dev/sdaX, но можно и по UUID, как выше сказали. Про метку врать не буду, не пробовал.

Это разные вещи

Попробуй сейчас загрузиться по UUID. И если получится, скажи версию ядра.

Вот только ядро самостоятельно может справиться только с вариантом /dev/sdX, а UUID/LABEL обрабатываются через initrd. Есть ли у кого патчи, чтобы это поправить - и спрашивал ТС.

А еще можно попробовать удалить пакет libuuid1 :)

если gpt разметка, то можно без initrd монтировать как root=PARTUUID=

Ты уверен, что это ядро обрабатывает этот параметр?

у меня просто нет initrd, так что либо ядро, либо магия

Прочитал комментарий в init/do_mounts.c:

/*
* Convert a name into device number. We accept the following variants:
*
* 1) device number in hexadecimal represents itself
* 2) /dev/nfs represents Root_NFS (0xff)
* 3) /dev/<disk_name> represents the device number of disk
* 4) /dev/<disk_name><decimal> represents the device number
* of partition - device number of disk plus the partition number
* 5) /dev/<disk_name>p<decimal> - same as the above, that form is
* used when disk name of partitioned disk ends on a digit.
* 6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
* unique id of a partition if the partition table provides it.
* The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
* partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
* filled hex representation of the 32-bit "NT disk signature", and PP
* is a zero-filled hex representation of the 1-based partition number.
* 7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
* a partition with a known unique id.
* 8) <major>:<minor> major and minor number of the device separated by
* a colon.
*
* If name doesn't have fall into the categories above, we return (0,0).
* block_class is used to check if something is a disk name. If the disk
* name contains slashes, the device name has them replaced with
* bangs.
*/

Ну вот вы сами и нашли правильную документацию :-)

У меня вообще таблицы разделов нет

С этого и надо было начинать. Патч, поддерживающий UUID/LABEL, должен быть не сложным, можно выдернуть кусок кода из команды mount. Команда mount, когда ей дают UUID=xxx, сама читает/парсит суперблоки доступных блочных устройств, поэтому патч получится не завязаным на код драйверов ФС, но в ванильное ядро его врядли включат.

Хотя создать таблицу разделов будет попроще, чем писать патч.

Хотя создать таблицу разделов будет попроще, чем писать патч.

Да патч-то почти готов, я знаю, где взять код, знаю куда его засунуть, могу даже комментарий дополнить. Патч проще.

Это как? На /dev/sda файловая система?

Да, именно так. Но иногда этот /dev/sda вдруг внезапно превращается в /dev/sdb или даже /dev/sdc, потому хочу смонтировать по UUID.

Как оно поймёт, на каком разделе корень системы? Через встроенную командную строку.

Прими разупорин! В случае UEFI встроенная командная строка нужна вовсе не для того чтобы „ядро понимало на каком разделе корень системы“. А как ты сам сказал „отсутствие загрузчика“ на UEFI приводит к тому что нет того через что можно передавать параметры загрузки и в этом случае встроенная командная строка единственный выход.

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

Это одно и то же. Только в моём случае я пишу эту строку в конфиг загрузчика, а в случае UEFI, эту строку нужно захардкодить в ядро.

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

Читать до полного просвещения.

Initramfs и конкретно Initramfs --> UUID/LABEL Root Mounting

Early Userspace Mounting

Custom Initramfs и Custom Initramfs --> Mount by UUID or LABEL

Initramfs/HOWTO

И да к сведению - Initramfs можно встроить в само ядро так что на вид это будет один файл. См Embedding into the Kernel --> CONFIG_INITRAMFS_SOURCE

Это я всё знаю. Мне не важно, что на вид это будет один файл, мне важно отсутствие initramfs.
И почему ты считаешь, что «монтирование по UUID это вообще не задача ядра»?

Мне не важно, что на вид это будет один файл, мне важно отсутствие initramfs.

USE CONFIG_INITRAMFS_SOURCE Luke CYB3R!

И почему ты считаешь, что «монтирование по UUID это вообще не задача ядра»?

Наверное потому что я в своё время перечитал все ссылки из предпоследнего сообщения или просто потому что 42 ответ выбери сам.

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

Ну понятно, с тобой бесполезно спорить.

Ок. Ещё раз для особо одаренных и понятливых. То чего ты желаешь а именно --> монтирование корневого раздела по UUID или метке файловой системы делает не ядро. Всё. Большая и жирная точка. Эту задачу у людей решает что угодно inird/initramfs да хоть чёрт с ушами но не ядро потому что ядро к этому не имеет вообще никакого отношения. Далее если люди не хотят видеть отдельный файл inird/initramfs они включают его при помощи CONFIG_INITRAMFS_SOURCE в состав самого ядра и таким образом добиваются того что отдельного inird/initramfs попросту не существует.

Если всё вышесказанное к тому же подкреплённое вполне конкретными примерами до тебя не доходит я раскланиваюсь и удаляюсь из этого треда. И за одно желаю всяческих успехов.

Я не понимаю, почему ты так категоричен. Почему ядро не должно читать метки FS?
Ведь иксы в ядро засунули? Засунули. А веб-сервер засунули? Засунули. Так что мешает сделать монтирование корня по метке файловой системы?
У меня CONFIG_BLK_DEV_INITRD=n и менять это значение я не собираюсь, потому CONFIG_INITRAMFS_SOURCE я включить не могу. Я прекрасно знаю, как эта опция работает, много раз её использовал, но в данном случае мне это не нужно.
В данном случае задача называется «смонтировать раздел по UUID, не используя initramfs», потому использовать initramfs для этого не получится. А если initramfs будет вкомпилена в ядро, она никуда не пропадёт.

Ну хорошо, допустим, командная строка нужна вовсе не для этого. Ладно. Но как тогда в условиях отсутствия бутлодера указать ядру на корень? Или всё-таки «root=${ROOT_DEVICE}» — это тоже один из параметров ядра, как считаешь?

„отсутствие загрузчика“ на UEFI приводит к тому что нет того через что можно передавать параметры загрузки

Есть.

/root # efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000
Boot0000* Debian (EFI stub)	HD(1,800,40000,9d851a0d-0e6e-426e-90d1-dbc2f6243604)File(\EFI\debian\vmlinuz)r.o.o.t.=.U.U.I.D.=.b.8.1.2.b.3.9.d.-.5.f.9.0.-.4.2.2.d.-.9.e.4.e.-.9.3.2.4.e.2.1.1.2.c.f.1. .r.o. .q.u.i.e.t. .a.d.d._.e.f.i._.m.e.m.m.a.p. .i.n.i.t.r.d.=.E.F.I.\.d.e.b.i.a.n.\.i.n.i.t.r.d...i.m.g...

Ну хорошо, допустим, командная строка нужна вовсе не для этого.

Бессмысленно повторять… Ещё раз перечитай внимательно. И да есть такая хрень как «командная строка» но к изначальному вопросу «монтирования корневого раздела по UUID или метке файловой системы» она, так же как и ядро, не имеет вообще никакого отношения. «Командная строка» != «командной строке в командной оболочке sh/bash/tsh/zsh/…»!!! «Командная строка» ядра в случае UEFI или embedded системы лишь способ передачи параметров в систему {минуя/заменяя собой} передачу параметров через загрузчик.

И да я не спорю с root=${ROOT_DEVICE}… Тем не менее не глядя на то, что дистрибутивы на базе gnu/linux можно грузить с mdadm, cryptsetup, lvm2, NFS, ftp и т.д. для чистого ядра без initrd/initramf эти всё перечисленные способы загрузки невозможны по причине отсутствия в нем всего необходимого функционала. Но даже без всей этой экзотики кроме этого есть немалое количество случаев когда чистое ядро linux без initrd/initramf даже загрузится с заданного ROOT_DEVICE не сможет потому что модули этого устройства по той или иной причине не в составе ядра.

А вот равно как для всех этих способов mdadm, cryptsetup, lvm2, NFS, ftp и прочих устройств у которых нет модулей в составе самого ядра так и для загрузки с корневого раздела с определенным UUID или меткой файловой системы используется initrd/initramf.

Всё еще мало? Читайте ramfs, rootfs and initramfs

А веб-сервер засунули? Засунули.

Ты так то не пугай. Это называется не засунули а кто-то, давным давно дурью маялся. Бегло глянул, нашел только патч на 2.6.18. Отдельный. Т.е. в ядре этой бяки никогда небыло. Ну выдь правда? А если кто там в сторонке тюненгует ядро повсякому, так это того кто личное дело.

А по теме ls -l /dev/disk/by-uuid/. Вроде удева это хозяйство. Нет удева - нет хозяйства.

Есть.

Через него передаются параметры в систему? Т.е. «командная строка» ядра либо «командная строка» любого другого загрузчика попросту не нужна? И система их корректно читает?

Через него передаются параметры в систему? Т.е. «командная строка» ядра либо «командная строка» любого другого загрузчика попросту не нужна? И система их корректно читает?

Да. Да. Да.

Поскольку это требует наличия в ядре EFI Stub, то логично предположить, что он с этим и разбирается.

А вообще интересно. Тут, говорят читать до просветления это. И если не вдумываясь смотреть, то ядро умеет в твою хотелку.

Патчи на ядро для монтирования корневого раздела по UUID

А зачем патчи? Меняешь в fstab /dev/XdaY на UUID и всё. Или для этого нужен initramfs? А то в убунте оно по дефолту, я как-то даже не заморачивался.

Да. Да. Да.

Поскольку это требует наличия в ядре EFI Stub, то логично предположить, что он с этим и разбирается.

Значит уже исправлено. Раньше всё это не работало что и требовало костыли в виде «командной строки». А вообще «командная строка» это больше именно к embedded системам там где либо вообще никаких загрузчиков нет либо ограничения такие что…

А зачем патчи? Меняешь в fstab /dev/XdaY на UUID и всё. Или для этого нужен initramfs? А то в убунте оно по дефолту, я как-то даже не заморачивался.

fstab находится на ROOT_DEVICE и не может быть прочитан до тех пор пока ROOT_DEVICE не будет примонтирован… Типичная проблема курицы и яйца.

Ясно, значит initramfs...

дело не в fstab, by-uuid симлинки создаёт udev

В fstab «UUID» и «LABEL» дополнительно обрабатывает mount. Если ты запишешь «/dev/disk/by-label/ROOT», то это будет не совсем то же, что «LABEL=ROOT». Хотя на конечный результат не повлияет. Это насколько я понимаю.

корень монтируется ядром а не mount

использовать initramfs для этого не получится

а почему именно, если не секрет?

дело не в fstab, by-uuid симлинки создаёт udev

Не важно. udev так же юзерспэйсная штука и живет всяко где-то около ROOT_DEVICE. И udev так же как и fstab… Да та же курица и яйцо.

Ясно, значит initramfs...

Я не спорю с naszar

Тут, говорят читать до просветления это

Потому что в последнее время в ядре много чего делали возможно и это тоже уже сделали… Однако даже если это не так я точно знаю что с initrd/initramf это вообще не проблема.