Паника GRUB при отсутствии раздела

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

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

С установочного образа многих дистрибутивов корневой раздел обычно монтируется в /mnt, соответственно, /boot должен также монтироваться в /mnt/, то есть, в процессе установки в качестве корневого раздела используется образ squashfs (могут быть другие варианты) с установочной флешки. Пользователь размечает диск (с помощью программы установки или самостоятельно), создаёт разделы, монтирует (опять же, сам, или с помощью инсталлятора) будущий корневой раздел в /mnt, монтирует, если есть, отдельные разделы в структуру каталогов под /mnt, например, будущий /boot монтируется в /mnt/boot, ESP монтируется в /mnt/boot/efi, и так далее. Чтобы не путаться, где какой раздел, надо, во-первых, использовать метки разделов, а во-вторых, назначать разделам GPT UUID, согласно сценарию использования этого раздела (команда t в fdisk).

Теперь по командам.

1. Необязательно, но я не пользуюсь виндой, и не уверен, что винда, GRUB и ядро поместятся в 100 МиБ, желательно иметь на ESP некий запас свободного места, поэтому мой ответ – да, 300 МиБ будет нормально. У меня ESP и /boot – это один раздел, поэтому я монтирую ESP напрямую в /boot, соответственно, путь к EFI-загрузчикам у меня /boot/EFI, а размер раздела – 256 МиБ. Суммарно занято 164 МиБ, это полный GRUB и ядро.
2. Вот тут внимательно. Убедись, что ты монтируешь в /boot именно нужный раздел и что именно он будет всегда монтироваться туда (если используешь /etc/fstab, там должна быть корректная запись для /boot). Установка загрузчика, когда все подготовительные процедуры выполнены, сводится к sudo grub-install /dev/sda, остальное сделает скриптовая машинерия из состава GRUB-а. Для NVMe SSD имена разделам даются по схеме /dev/nvme0n1p1, например.

Да, и ещё. Так как ESP должен быть c файловой системой FAT32, которая не поддерживает линуксовые права доступа, для безопасности крайне желательно всё же иметь отдельный от ESP раздел для /boot. Как вариант, можно поверх ESP замутить UMSDOS для поддержки линуксовых прав доступа, но это уже очень нестандартный кейс, использовать только на свой страх и риск.

убрать Debian-диск из GRUB или пометить его как optional, чтобы при отсутствии HDD GRUB не падал в rescue:

sudo nano /etc/grub.d/30_os-prober

найди строку os-prober

и замени на if [ -e /usr/bin/os-prober ]; then os-prober || true fi

sudo update-grub

Во-первых, не нужно редактировать файл, который будет перезаписан при обновлении (а файлы в /etc/grub.d/ будут перезаписаны при обновлении пакета GRUB), во-вторых, это требует, чтобы пакет os-prober был установлен, в-третьих, для включения в работу этого пакета в /etc/default/grub есть настройка GRUB_DISABLE_OS_PROBER, по умолчанию она закомментирована, нужно раскомментировать её и проследить, чтобы ей было присвоено значение false. Ну, а в-четвёртых, эта настройка нужна только в специфических случаях.

замутить UMSDOS

Его же ещё в 2.6 выкинули?

для безопасности

Для безопасности от чего? Обычно, ESP в линуксе монтируется с umask=077, то есть доступно только root. А если из под дуалбут винды захотят что-то сломать, то и до отдельного /boot дотянутся при желании.

Во-первых, не нужно редактировать файл, который будет перезаписан при обновлении

Я каждый раз редактирую, после каждого обновления. Оригинал обзываю приставкой «ориг», а копию grub17.cfg переименовываю в grub.cfg. А не нашёл я пока способа как автоматически его привести к тому виду, к которому ты хочешь. Я даже делал скрипт, от админа, который автоматом патчил grub.cfg, точнее обычный Replace (замена).

# Если скрипт запущен от имени пользователя root, то выполнится сразу, иначе будет запрошен пароль для root
if [ "$(id -nu)" != "root" ]; then
    sudo -k
    pass=$(whiptail --backtitle "Замена в grub.cfg (Grub2)" --title "Требуется права root" --passwordbox "Текущий пользователь: $USER\nВыполните аунтификацию для
root.\n\nВведите пароль для root:" 12 50 3>&2 2>&1 1>&3-)
    exec sudo -S -p '' "$0" "$@" <<< "$pass"
    exit 1
fi

sed -i 's/ --class ubuntu/ --class mint/g' /boot/grub/grub.cfg
sed -i -r 's/(submenu ".+?")\{/\1 --class folder \{/g' /boot/grub/grub.cfg

у меня папка grub - 16 Мб, с темой, с копиями grub.cfg, там если прошерстить, в том числе модули, можно в 2 раза, а то и более урезать без потери функционала.

Способ называется 40_custom. Файл /etc/grub.d/40_custom существует для пользовательского конфига. Поэтому он последний, что ничто не перезапишет определённое в нём, зато в нём можно переопределить всё сделанное ранее. Далее, есть ещё 41_custom. Он просто использует в качестве конфига файл custom.cfg.

Да я видел эти 40-вые и прочее, и гуглил, но так и не пришёл результату. Мне хотелось бы просто вставить конфиг и он бы это прямым текстом засунул, но оказалось не всё так просто. Когда-то я устанавливал «Grub Customizer» и он добавлял конфиг, который подвергался правке, я мог туда засунуть всё что угодно, кроме прописки значка –class=mint, но я не хочу ради этого ставить эту программу, так как 90% что она делает я могу сейчас настроить самостоятельно.

Именно это и делает 40_custom. Прочитай, что в нём написано в комментарии. Всё, что поместишь туда после комментария, попадёт в grub.cfg.

После изучения мануалов и интернетов нашёл два простых способа решения:

1. GRUB

После установки выполняем (под root):

grub-install --efi-directory=/boot/efi/ --boot-directory=/boot/efi/
update-grub --output=/boot/efi/grub/grub.cfg

Замечания:

• Для grub-install указаны только основные ключи, но могут потребоваться и другие (например –uefi-secure-boot). Также для экономии места можно установить только нужные локализации –locales=LOCALES и модули –install-modules=MODULES.
• Для debian update-grub является обёрткой над grub-mkconfig. Если у вас не debian, то используете grub-mkconfig.
• После того как удостоверитесь что всё работает, старую папку загрузчика /boot/efi/grub можно удалить.

2. SYSTEMD-BOOT

• В экспертном режиме Debian-Installer выбираем установку systemd-boot вместо grub.
• После перезагрузки раскоменчиваем строку timeout в файле /boot/efi/loader/loader.conf. Теперь systemd-boot будет при каждой загрузке искать другие efi загрузчики и динамически добавлять их в меню. При желании вы можете отключить этот авто-поиск опцией auto-entries no в этом же файле, и добавить пункт меню вручную, создав в папке /boot/efi/loader/entries файл конфигурации (например fums.conf), содержащий строки:

title   shitos
efi     /EFI/Microsoft/Boot/bootmgfw.efi

Замечания:

• Надо очень осторожно выбирать размер ESP раздела. На нём должно быть место как минимум для двух наборов ядро+initrd. В моём случае ядро весило ~11мб, полный initrd ~48мб, частичный (для virtualbox) initrd ~11мб. Соответственно стандартных виндовых 100мб хватает в обрез. Для справки: в Debian-Installer его дефолтный размер равен 800мб.
• Не очень ясна ситуация с защитой. Ядро вроде подписано, его не подменишь при secure boot. Но вот что насчёт защиты initrd (просто лежащим на общем fat16 разделе) я не понял.
• Чисто визуально процесс загрузки grub-ом выглядит лучше (и я не про меню, а про саму загрузку ядра), имхо. Кроме того у systemd-boot есть очень странная особенность - если графическое окружение не установлено, то даже когда уже выдано приглашение на вход (и даже после логина), на консоль продолжают выводиться журналируемые сообщения (при их возникновении). Выглядит это очень странно, мягко говоря.
• При установке debian 13 без инета, одного только DVD1 будет недостаточно - на нём только часть нужных пакетов.

3. windows bootmgr

Такого варианта для EFI просто нет. Насколько я понял шиндовс просто не умеет грузить linux в EFI.

ИТОГ

Я полюбил GRUB, этого мощного старика. :)

Спасибо всем кто помогал!