Bug 54071

(In reply to Антон Мидюков from comment #0)
> Сейчас при конвертации iso образа
Интересно, чем выполняется конвертация и во что вообще конвертируется ISO-образ?

> требуется заменить uid файловой системы
Сразу уточним: здесь речь идёт о пропагаторном параметре fuid, передаваемом через аргумент automatic=... Важно, что он не является каким-либо UUID файловой системы, поэтому не может использоваться для поиска. Он является одноимённым пустым файлом в корне CDROM и служит подтверждением на самом последнем этапе, что смонтированный раздел именно тот, с которого мы хотим загрузиться.

> Сейчас при конвертации iso образа требуется заменить uid файловой системы
> на актуальный в /boot/grub/grub.cfg
Таким образом, получается, что при конвертированни ISO-образа неупомянутый конвертор теряет файл, не используемый для других методов загрузки, или используемый в других целях. Правильный конвертор должен: либо игнорировать automatic=... целиком и заменять его нужными значениями, либо убирать fuid:... и заменять на uuid:<актуальный UUID> или на label:<актуальная LABEL>.

> Из-за этого iso образы нельзя писать тем же rufus (не в режиме iso).
Про rufus ничего не скажу, но если я верно понял, конвертирование по задаче не является простым копированием, что-то должно быть изменено в загрузочном меню в любом случае.

> Если будет искаться file uid, как то делает grub, как в efi, так и в legacy
> режиме, то проблема решится.
Я бы предложил изначально (в m-p) не использовать fuid, а использовать uuid. Данный UUID всё равно придётся менять при конвертировании на актуальный, но это как раз то, что требуется по задаче, работает быстро и надёжно, поддерживается методами disk и cdrom. Именно uuid содержит UUID файловой системы, fuid -- просто название файла и только для метода cdrom. В методе disk эта fuid уже используется внутренне для совсем других целей.

> У grub это получается делать очень быстро, почему это нельзя сделать в linux?
Grub действительно использует поиск по файлу на монтируемых дисках. Это не быстро, не надёжно, это вообще плохая практика. Лучше использовать UUID файловой системы. Разница в том, что если кто-то имеет раздел на пути сканирования с "живым" суперблоком но с испорченной файловой системой, он попытается его смонтировать для проверки наличия файла и может что-то пойти не так -- всё зависит от кода в ядре и userspace. При использовании настоящего UUID достаточно мгновенно обработать событие от make-initrd, по сути нужный раздел уже найден.

Так что, данный баг лучше рассматривать как предложение уйти от fuid в дистрибутивах на uuid, предлагаю перевесить на m-p. ISO-образ можно создавать с заданным UUID, его можно читать через тот же blkid. Я понимаю, что "с fuid как в grub" удобно, но дистрибвно это небезопасно, такой вариант лучше оставить пользователю на его страх и риск.

Если по задаче предпочтительно сделать так, чтобы при смене типа носителя не нужно было что-либо менять, тогда начиня с m-p лучше использовать label:...

При этом нужно учитывать, что в некоторых файловых системах LABEL может иметь существенные ограничения и ввиду его использования в параметрах загрузки нежелательно использовать пробелы (altboot может заменять "\040" на пробел).

Тогда строка automatic=method:cdrom,label:ALT\040Rescue\040x86_64 будет иметь одинаковый смысл как на исходном, так и на сконвертированном носителе. К слову, конвертор iso2stick перебивает automatic полностью, добавляя в него uuid=...

(Ответ для Leonid Krivoshein на комментарий #1)
> (In reply to Антон Мидюков from comment #0)
> > Сейчас при конвертации iso образа
> Интересно, чем выполняется конвертация и во что вообще конвертируется
> ISO-образ?
> 

Руками. Файловые системы fat32, exfat, ntfs, ext4, f2fs.

> > требуется заменить uid файловой системы
> Сразу уточним: здесь речь идёт о пропагаторном параметре fuid, передаваемом
> через аргумент automatic=... Важно, что он не является каким-либо UUID
> файловой системы, поэтому не может использоваться для поиска. Он является
> одноимённым пустым файлом в корне CDROM и служит подтверждением на самом
> последнем этапе, что смонтированный раздел именно тот, с которого мы хотим
> загрузиться.
> 

Да. Но в то же время grub по этому же самому файлу находит нужную файловую систему.

> > Сейчас при конвертации iso образа требуется заменить uid файловой системы
> > на актуальный в /boot/grub/grub.cfg
> Таким образом, получается, что при конвертированни ISO-образа неупомянутый
> конвертор теряет файл, не используемый для других методов загрузки, или
> используемый в других целях. Правильный конвертор должен: либо игнорировать
> automatic=... целиком и заменять его нужными значениями, либо убирать
> fuid:... и заменять на uuid:<актуальный UUID> или на label:<актуальная
> LABEL>.

Сейчас нет никакого fuid. Нужно руками заменять uuid:<неактуальный UUID> на uuid:<актуальный UUID>.

> 
> > Из-за этого iso образы нельзя писать тем же rufus (не в режиме iso).
> Про rufus ничего не скажу, но если я верно понял, конвертирование по задаче
> не является простым копированием, что-то должно быть изменено в загрузочном
> меню в любом случае.

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

> 
> > Если будет искаться file uid, как то делает grub, как в efi, так и в legacy
> > режиме, то проблема решится.
> Я бы предложил изначально (в m-p) не использовать fuid, а использовать uuid.

Так уже давно. И используется disk, чтобы менять только uuid.

> Данный UUID всё равно придётся менять при конвертировании на актуальный, но
> это как раз то, что требуется по задаче, работает быстро и надёжно,
> поддерживается методами disk и cdrom. Именно uuid содержит UUID файловой
> системы, fuid -- просто название файла и только для метода cdrom. В методе
> disk эта fuid уже используется внутренне для совсем других целей.

А хотелось бы, чтобы метод disk по аналогии с grub грузил по наличию файла в файловой системе.

> 
> > У grub это получается делать очень быстро, почему это нельзя сделать в linux?
> Grub действительно использует поиск по файлу на монтируемых дисках. Это не
> быстро, не надёжно, это вообще плохая практика. 

Все дистрибутивы linux, использующие grub, так делают.

> Лучше использовать UUID
> файловой системы. Разница в том, что если кто-то имеет раздел на пути
> сканирования с "живым" суперблоком но с испорченной файловой системой, он
> попытается его смонтировать для проверки наличия файла и может что-то пойти
> не так -- всё зависит от кода в ядре и userspace. При использовании
> настоящего UUID достаточно мгновенно обработать событие от make-initrd, по
> сути нужный раздел уже найден.
> 
> Так что, данный баг лучше рассматривать как предложение уйти от fuid в
> дистрибутивах на uuid, предлагаю перевесить на m-p. ISO-образ можно
> создавать с заданным UUID, его можно читать через тот же blkid. Я понимаю,
> что "с fuid как в grub" удобно, но дистрибвно это небезопасно, такой вариант
> лучше оставить пользователю на его страх и риск.

На m-p перевешивать не надо, так как уже всё сделано несколько лет как.
Есть запрос на такую фичу у make-initrd-bootchain-altboot.

Обратил внимание, что в bootchain-localdev/data/lib/bootchain/localdev "fuid" используется единообразно, независимо от метода и наличия компонента directory. То есть, уже и сейчас можно проверить его с методом disk. Но внутри altboot есть места, где он используется для передачи имени файла второй стадии. Можно будет попробовать это разделить, введя ещё оду внутреннюю переменную.

Важно понимать, что fuid в altboot не используется для поиска носителя никак, это нельзя переделать. Но если указать fuid, он должен быть именно такой на найденном и смонтированном носителе, иначе будет выдана ошибка и найденный носитель не будет считаться подходящим.

Отличие make-initrd от загрузчиков в том, что загрузчик может себе позволить монтировать по очереди все найденные разделы. Такой код пишется обычно на Си очень аккуратно и занимает многие тысячи строк. Сам метод поиска нужного раздела по указанному на нём файлу небезопасен и неоптимален.

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

В итоге, мы стремимся добавить поддержку fuid и для метода disk, но частью однозначной спецификации устройства fuid не является. С этой целью предпочтительно использовать uuid.

(In reply to Leonid Krivoshein from comment #5)
> Найдя нужный раздел, загрузчик вполне может передать в параметрах загрузки
> его настоящий uuid.
> [...]
> В итоге, мы стремимся добавить поддержку fuid и для метода disk, но частью
> однозначной спецификации устройства fuid не является. С этой целью
> предпочтительно использовать uuid.
В рамках этого бага так и решили оставить. Сделал fuid дополнительной подсказкой на случай отсутствия uuid в спецификации, т.е. после переноса на другой диск иное значение не будет ни на что влиять, главное, чтобы файл был в корне. Но с оригинальным ISO-диском это будет ещё работать похожим на uuid образом, ускоряя поиск нужного носителя.

Собрал тестовый таск: #384524.

Также исправил некоторые старые ошибки, добавил возможность загрузки с распакованного в подкаталог образа, разделил fuid и squash, так что fuid больше не используется как внутренняя переменная, актуализировал документацию. Будет небольшое, но логичное изменение в поведении: если в параметрах загрузки указан fuid, то соответствующий файл обязан быть в корне, теперь это не сбрасывается в результате диалогов, т.е. пользователь не сможет ошибиться, выбрав не тот диск.

> grub: реализована автоматическая подстановка uuid в kernel cmdline. Это
> позволит переносить содержимое iso образа как есть на другие файловые системы.
Данный анонс, как я понимаю, подтверждает вышесказанное: https://lore.altlinux.org/devel-distro/60cebf58-af01-4137-a19f-e64e8e0bfd78@altlinux.org/

Тогда закрываем этот баг?

(Ответ для Leonid Krivoshein на комментарий #7)
> > grub: реализована автоматическая подстановка uuid в kernel cmdline. Это
> > позволит переносить содержимое iso образа как есть на другие файловые системы.
> Данный анонс, как я понимаю, подтверждает вышесказанное:
> https://lore.altlinux.org/devel-distro/60cebf58-af01-4137-a19f-
> e64e8e0bfd78@altlinux.org/
> 
> Тогда закрываем этот баг?

Да. Спасибо большое за идею задавать uuid непосредственно в grub уже при загрузке.