root=hdX,1 в GRUB

Но при этом они оба могут читать один конфиг-файл.

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

Так что «legacy, и только legacy» – мимо…

…у тебя. Это относится не к загрузчику а к БИОС.

grub-legasy и есть тот самый, что я выше назвал «грубПС».

Нет и нет. Grub-legacy – это grub-0.99.

Это верно. И могут использовать menu.lst и isolinux.cfg.

Нет, не потому что 0.99. Grub-legacy он стал, потому что появился grub-efi.

Спасибо.

Я думаю когда несколько устройств то такой переменной нет. И за место

root=hd0,1

нужно использовать.

–fs-uuid –set=root

разметка сьелась :(

search –fs-uuid –set=root

Опять :(

search --fs-uuid --set=root <UUID-of-the-filesystem>"

Если будет найден, то переменная root получит соответствующее значение.

«… –set …» - будет установлена переменная root.

«… –set=groot …» - будет установлена переменная «groot», например, чтобы не путать с одноимённым параметром ядра или чтобы не портить текущее значение root.

В вашем вопросе уже содержится вопрос. Предлагаю внимательно прочитать мои комментарии и прочитать постановку вопроса автора темы.

Вы этот конфиг пробовали править? Grub на его исправления реагирует, начинает другую ФС искать?

Реагирует. Если только вы его не вшили в grub.efi.

Это пять:

В вашем вопросе уже содержится вопрос.

У меня там как-бы два вопроса. Ну на один вы ответили, что именно у вас grub ищет grub.cfg рядом с grub.efi. Ну там сразу возникает другой вопрос — какой дистрибутив у вас. Вроде, был Arch, но, лучше подтвердите ещё раз, я не хочу перечитывать ЛОР в поисках вашего комента, что вы сменили дистр.

прочитать постановку вопроса автора темы.

Автор темы то тут каким боком. Это уже отдельная ветка, про то, как устроен груб изнутри. Использует ли grub внутри себя PARTUUID или нет. Ваши рассуждения про 99% случаев побоку, интерестно знать как устроен grub, а не «нужно/не нужно».

В grub первична переменная prefix, а не root. Пока ТС не покажет, что у него происходит с переменной prefix, для меня его ситуация интерестная, но не до конца понятная. Я в курсе, что встречаются BIOS, у которых загрузочный носитель — это не (hd0), как у большинства. Но, обычно, они всегда делают внутренний диск (hd0), а съёмным что достанется. А ТС, похоже, наоборот, съёмным (при наличии) всегда (hd0), а SSD — как получится.

Это пять:

Согласен опечатка.

Правильная фраза: «В вашем вопросе уже содержится ответ.».

Вроде, был Arch, но, лучше подтвердите ещё раз, я не хочу перечитывать ЛОР в поисках вашего комента, что вы сменили дистр.

Возможно, это у вас Arch, у меня Debian.

что именно у вас grub ищет grub.cfg рядом с grub.efi

Так работает в большинстве Linux и сценарии установки grub дистрибутивными скриптами поступают именно так. В deb-based, rpm-based и в том же Arch Linux. Если вы используете редкий дистрибутив, где руками пишете grub.cfg - это ваш выбор.

Можете прочитать вот это:

• https://lists.gnu.org/archive/html/help-grub/2016-03/msg00002.html
• https://lists.gnu.org/archive/html/help-grub/2016-03/msg00005.html

Если кратко, то EFI прошивка перед передачей управления EFI файлу загрузчика, в том числе grub читает файловую систему на ESP разделе и загружает оттуда EFI файл, в данном случае GRUB (grub.efi). Так вот, этот путь, а именно location (директория) и раздел запущенный EFI бинарник может прочитать из EFI прошивки и делает это. И именно на основе этого он и может прочитать grub.cfg, лежащий рядом с собой. Если вы при установке grub2 руками делаете как-то по другому - это ваш выбор. Но поведение grub2, в случае EFI: получить из EFI раздел и директорию (префикс), прочитать с $prefix/grub.cfg в качестве конфига.

Как видите, списки рассылки ещё от 2016 года. Поздравляю с разморозкой.

И в большинстве дистрибутивов в этот минимальный grub.cfg рядом с EFI файлом grub2 помещают search ФС и загрузку основного конфига. Но в случае расположения там целого конфига - всё будет так же работать. И по факту именно так и работает grur2 при установке с параметром removable.

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

Это для вас отдельная.

А я отвечал в контексте вопроса автора и дал рекомендации, что ни в случае grub-0.97, ни по факту в случае grub2 явно прописывать root для файловой системы загрузчика не нужно.

Но, обычно, они всегда делают внутренний диск (hd0), а съёмным что достанется. А ТС, похоже, наоборот, съёмным (при наличии) всегда (hd0), а SSD — как получится.

В терминологии IT, уже наверное как лет 30 жёсткий диск или SSD, установленные в корпус ПК относятся к классу съёмных устройств хранения.

Загрузчик работает через API (прерывания) базовой системы ввода вывода (BIOS) или Extensible Firmware Interface (EFI) и как прошивка сообщит ему порядок устройств - такой он и увидит. А это уже зависит от очерёдности инициализации и опроса прошивкой шин ввода/вывода и контроллеров накопителей.

То, что прописывается в MBR — просто адрес сектора, без раздела, без PARTUUID.

Там ещё boot drive. Как я понимаю, для сценария, когда /boot на другом устройстве.

Давайте другой вопрос, если установить grub 2 в MBR на гибридном разметке, то он какие PARTUUID возмёт — MBR или GPT? Если сделать sgdisk -G /dev/sda, grub продолжит загружаться или нет?

в grub 2 (кстати как и в grub legacy) есть опция embedded configuration. Там может быть и search по fs uuid. По partition uuid я ничего не нашел. В EFI бинарниках нахожу строки (,gpt2)/grub или встроенный скрипт (в зависимости от того, как создавался бинарник).

Что касается grub.cfg, расположенного рядом с efi image, то в моих экспериментах он игнорируется.

А это уже зависит от очерёдности инициализации и опроса прошивкой шин ввода/вывода и контроллеров накопителей.

Нет. У всех нормальных BIOS было, что 0x80 (hd0) — это тот диск, с которого считан и запущен загрузчик. И всякие траблы у разных загрузчиков вылазили, если это не так, и в grub добавляли map (0x80) (0x81) перед chainloader

В терминологии IT, уже наверное как лет 30 жёсткий диск или SSD, установленные в корпус ПК относятся к классу съёмных устройств хранения.

Чего? Производитель материнки/BIOS определяет, будет у того или иного SATA порта (и следовательно у подключенного туда накопителя) флаг Removeable. cat /sys/block/sda/removable

Можете прочитать вот это:

>> The efi binary is loaded from the EFI partition, and it queries the
>> firmware for the path it was loaded from. It was loaded from
>> (hd0,1)/EFI/grub. So it sets its prefix=(hd0,1)/EFI/grub. However, there is
>
> No, image created by grub-install does not do it. It looks for
> filesystem where /boot/grub was present at the time grub-install was
> invoked.
>

Я привёл последний коммент ветки, на которую вы дали ссылку, написано, что не делает.

Вот здесь https://stackoverflow.com/questions/35269943/how-does-the-grub-2-uefi-loader-... указано, что в Ubuntu 18 был такой встроенный (early) конфиг.

if [ -z "\$prefix" -o ! -e "\$prefix" ]; then
    if ! search --file --set=root /.disk/info; then
        search --file --set=root /.disk/mini-info
    fi
    set prefix=(\$root)/boot/grub
fi
if [ -e \$prefix/$platform/grub.cfg ]; then
    source \$prefix/$platform/grub.cfg
elif [ -e \$prefix/grub.cfg ]; then
    source \$prefix/grub.cfg
else
    source \$cmdpath/grub.cfg
fi

И вот это похоже на правду, $cmdpath как раз путь, откуда загрузили core.img (grub.efi). Груб всегда сначала читает встроенный в него конфиг, а тот, при таком содержимом, в конце-концов прочитает grub.cfg с ESP. Но у вас grub.efi без early grub config, странно.

Так работает в большинстве Linux ... в том же Arch Linux.

Где в wiki Arch Linux написано про grub.cfg рядом с grub.efi? Они там как раз показывают как руками создавать early grub config.

Это для вас отдельная.

Да, я пытаюсь отделять общие знания от частных проблем. А вы технично замешиваете всё в кучу, типа, в дебиан работает так, значит сам груб так работает, MBR grub типа использует «идентификатор раздела», но откуда инфа про PARTUUID писать не будем.

то в моих экспериментах он игнорируется.

Я предыдущем комменте, вроде бы, нашёл разгадку «grub.cfg, расположенного рядом с efi image», что там специальный встроенный конфиг.

У меня получалось, что grub можно спокойно копировать, менять UUID разделов и ФС, если без встроенного конфига, и у него ″(,gpt2)/grub″, то он будет просто на второй GPT-раздел лезть. То есть в нём вобще нет кода анализа/поиска по partition UUID.

Спасибо за уточнение. Промоделировал на установочном диске Arch. Действительно, там нет файла рядом с EFI файлом загрузчика, он не создаётся ни в обычном, ни в removable варианте установке.

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

А в Debian - патчат grub-install.c:

• https://sources.debian.org/src/grub2/2.12-9%2Bdeb13u2/util/grub-install.c

В оригинальном grub-install.c - по-другому:

• https://gitlab.freedesktop.org/gnu-grub/grub/-/blob/grub-2.12/util/grub-install.c?ref_type=tags

Спасибо за уточнение.

Значит в Debian такое поведение.

Так же при тесте в Arch Linux - в grub.cfg не указывал set root или search и как минимум меню из (,gpt2)/boot/grub/grub.cfg он прочитал. В целом должен прочитать и (,gpt2)/boot/vmlinuz… и прочее.

С некоторыми оговорками будет работать всё без явного set root / search и прочего.

Чтобы указывать UUID ФС нужны явные указания или патчи в grub-install.c.

Спасибо за исправление.

Вот что в EFI файле grub в Debian:

if [ -z "$prefix" -o ! -e "$prefix" ]; then
        if ! search --file --set=root /.disk/info; then
                search --file --set=root /.disk/mini-info
        set prefix=($root)/boot/grub
if [ -e $prefix/x86_64-efi/grub.cfg ]; then
        source $prefix/x86_64-efi/grub.cfg
elif [ -e $prefix/grub.cfg ]; then
        source $prefix/grub.cfg
else
        source $cmdpath/grub.cfg

Вот эта часть:

source $cmdpath/grub.cfg

загрузит конфиг из директории с EFI файлом.

Сталкивался с чем-то похожим.

Груб умеет определять UUID и «на лету» подставлять в конфиг. Что-то подобное:

menuentry "Arch Linux" {
    probe -s UUID -u $root
    linux /boot/vmlinuz-linux root=UUID=$UUID rw
    initrd /boot/initramfs-linux.img
}

Не про этот root разговор, а про root (prefix) для загрузчика.

…в этот минимальный grub.cfg рядом с EFI файлом grub2 помещают search ФС и загрузку основного конфига.

Да. Там действительно загружается «основной конфиг». Но, этот «маленькой конфиг» не для поиска системы, а для указания самому грубу, где ему искать свои остальные две сотни файлов. Если в этом «маленьком конфиге» указать что-то другое, то груб сможет только вывести: «grub rescue», больше ничего он сделать не сможет. Где искать систему, указывается в «основном конфиге».

Уважаемый, я не знаю что ты понимаешь под «поиск системы», но в случае сборки в Debian - в этом маленьком конфиге ты можешь поместить полный конфиг grub и он будет работать.

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

Будет, если груб найдёт сам себя.

А прочитать лучше тебе. Да и ответ не столько конкретно тебе. Чтобы ТС не заблудился в этом болоте.

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

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

И подумайте, можно ли или нет скопировать большой конфиг, в котором явно прописан search заместо малого и будет работать или нет.

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

«Кто ясно мыслит, тот кратко излагает.»

Не скажу что наизусть, но хорошо знаю, что есть во всех названных тобой конфигах. Скопировать можно всё. А вот каков будет результат, сказал двумя ответами выше. Да, кратко. Если в теме, то достаточно для понимания. Если не в теме, то не хватит толстого учебника и мне его не написать.

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

Я тут глянул ‘большой конфиг’ у LSF (хз как далеко от CRUX), и у меня есть ощущение что они его не генерят а руками правят. У меня в шапке такой номер не пройдет ;)

Зря он упомянул «обновление конфига». Да уже поздно…

Зависит не от «шапки», а от «головы». Хотя-бы, система вообще может быть установлена без загрузчика, а следовательно, не будет знать о его существовании, не будет гадить в конфиге. Только руками.

Только руками.

Да я не спорю, просто руками слишком много нужно делать (я не только про grub) а юзал бы автор какую нибудь Шапку(Fedora и т.д.) или тот же Дебиан(Убунта и т.д.) то скорее всего и не было бы у него проблем которые он озвучивал в теме.

Хотя-бы, система вообще может быть установлена без загрузчика,

Серьёзно? Вы для меня открытие сделали, к своему стыду, работаю с Linux с 2006 года я это не знал. Признаю ужас.

Если вам не понятно - это сарказм.

Остальные выводы предлагаю сделать самостоятельно.

А это как-раз к вопросу ТС. В его случае и нужен «загрузчик вне системы», чтобы не зависел ни от чего. И соответственно, конфиг сделанный руками, потому как неизвестно, какие будут компьютеры, какие системы. Лучше оба груба: грубПС и грубЕФИ. В том числе, сможет запускать и установленные системы. И что там «шапка творит с загрузчиками», до фени.

Конечно, сегодня существует Ventoy. Но им тоже нужно уметь пользоваться.

С некоторыми оговорками будет работать всё без явного set root / search и прочего.

Да, именно так. В доке на grub написано, если переменная root не установлена, то корень (устройство) берётся из prefix.

Получаем следующую картину. В случае, когда grub.cfg лежит на одном разделе с ядрами/initramfs, то устанавливать root не нужно. Если grub читает grub.cfg, значит у него всё хорошо и он знает нужный корень. А, если grub не может найти grub.cfg, то он из него всё равно ничего не прочитает и ″set root =″ в том числе.

И, это, вроде, всё просто, но в примере grub.cfg в CRUX (который у ТС), про это не написали. Там написано, что либо делайте ″set root″, либо указывайте устройство в пути к образу ядра.

Хотя строкой ниже в примере указано про search fs.uuid, хотя, может у ТС старый пример, а прочитал, но не понял.

Это какая-то стыдоба, что GRUB в 2026 году всё так же «убивает» загрузку системы от простого подключения/отключения/клонирования дисков, и, поджав хвост, прячется в консоли восстановления…

Попробуйте rEFInd, он, по идее, автоматически ищет всё сам и не страдает от нерешительности, как GRUB. Можно сделать флешку с rEFInd (с https://sourceforge.net/projects/refind/) , прямо с неё загрузиться и перебить любой загрузчик на rEFInd.

А в prefix у вас что при разных вариантах загрузки? То есть, если вызвать командную строку grub и там набрать echo $prefix , там тоже все время будет (hd0,1)/... или меняется?

меняется hd0,1/hd1,1 в зависимости от порта. USB = hd1,1. SSD, SD = hd0,1.
и не совпадает с root=hd0,1, root=hd0,1 сейчас вообще везде, и везде грузится. не знаю, но раньше, почему-то кое-где (на USB) нужно было root=hd1,1. не знаю что поменялось. сейчас правда UEFI стоит другая старая версия (2013г) и походу это биос от совсем другого ноута (нужно перепрошивать, мастер опять не тот биос зашил).

не знаю что поменялось.

а, материнку поменял на такую же. поэтому и биос перешивали.

вот до сих пор не понял почему ты привязываешься к числа перечислителя устройств hd=0,1 hd=1,1 если root проще указать через уже указанный выше search --fs-uuid --set=root <UUID-of-the-filesystem>

кроме uuid search умеет искать по label и какойто file