Не удаётся установить Debian 12 на отдельном разделе

Не хотим.

Хм. Интересно. По идее GRUB2-EFI в Debian должен уметь расшифровывать LUKS1 и работать с LVM. Или ты LUKS2 используешь? Для него нужен отдельный раздел с нешифрованным /boot.

Злой ты. Новичек вроде адекватный.

Очевидный обходной путь – сделать мелкий раздел в 1-2 гигабайт в ext4 и монтировать его как /boot без шифрования – другой раздел с шифрованием и LVM без изменений оставить.

Оу, а 500 МБ - мало? А то я уже тут программное обеспечение устанавливаю

На пределе. 1 ядро влезет, чудом 2, но при обновлении ОС проблемы гарантированы. 1 гигабайт с современными ядрами самый минимум, лучше 2, а вот больше не надо.

И не путай /boot с /boot/efi, это EFI раздел, он в FAT32 обычно. Вот ему и 200 метров обычно с запасом. Если у тебя стоит Windows, он уже есть, установщик Debian его сам подхватывает обычно.

Установил. Хорошо, я изменю размер на 2 ГБ. Спасибо.

P. S. Офигеть, я смог.

Хорошо, я постараюсь не путать

Что-то дофига, аж целый гигабайт :)

du -shx /boot
50M	/boot
ls -hl /boot
итого 37M
drwxr-xr-x 3 root root  512 фев  8 20:06 EFI
drwxr-xr-x 6 root root  512 мая  5 23:14 grub
-rwxr-xr-x 1 root root 8,7M июн  7 00:44 initramfs-linux.img
-rwxr-xr-x 1 root root  13M мая 12 20:56 intel-ucode.img
-rwxr-xr-x 1 root root  15M июн  7 00:44 vmlinuz-linux

Только у меня не Debian, а Arch.

В Arch и правда легче ядро. В Debian оно собрано с большим числом дров, сразу с поддержкой mdadm и LVM, например – в Arch для этого нужно его пересобирать, поправив хуки. Плюс Arch только 1 ядро хранит, а Debian – 3 последних.

В принципе, ничто не мешает тот же LVM и mdadm встроить в initrd, для этого пересобирать ядро не придётся.

Вот ему и 200 метров обычно с запасом.

Актуальная рекомендация для ESP, чтобы хватило надолго — 1-2 Гб. Чтобы туда помещались эти самые ядра и прошивки для обновлений. Windows сейчас создаёт раздел 500 Мб, Fedora — до 600, ряд других дистрибутивов ориентируются на 500/512 Мб.

https://fedoraproject.org/wiki/Changes/BiggerESP

Ну я об этом и говорил. Пересобрать initrd точнее, да.

Хотя на ESP можно хранить ядра Linux, в том числе и в формате, что позволяет UEFI грузить Linux напрямую, по умолчанию в большинстве Linux ядра лежат в /boot, а в /boot/efi только GRUB2-EFI, а он сам по себе мало весит.

Увеличение ESP в Fedora как раз и связано с отказом в будущем от этой схемы, и монтированием ESP сразу в /boot, с тем чтобы ядро+initramfs грузилось UEFI напрямую.

Debian – 3 последних

Но зачем? По идее, достаточно держать одно «ремонтное» ядро, в случае проблем всегда можно загрузиться с ним и откатить версию ядра. Я вообще просто поддерживаю дистрибутивную флешку в актуальном состоянии.

Это всё так, но переход на UKI уже не за горами, и я думаю, он будет много где. Технология хорошая, нужная.

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

В Debian точно не в пределах релиза и не ранее 14 версии, 13 уже на заморозке.

передача ядру параметров не очень удобна

С точки зрения Леннарта нашего Поттеринга, параметры ядра должны быть зашиты в подписанный UKI, чтобы нельзя было их изменить. Потому что в норме их менять и не нужно. И это имеет смысл, если реализовывать Secure Boot нормально, а не как он сделан сейчас в большинстве дистрибутивов.

Это, опять-таки, может привести к проблемам при неработоспособности ядра.

Вот эту проблему, по-хорошему, надо решать системно, а не перебором параметров и прочими привычными процедурами. Да, реальность в линуксе такая, но стремиться к лучшему надо всё равно.

Так почему не сделать сразу нормально, чтобы потом не париться? Кстати, в 13 systemd-boot вроде получил достаточно официальный статус (подписывается для SB), а он не умеет ничего, кроме FAT32 (и правильно делает!).

500 мб для debian, в особенности, если при установке выбрать опцию добавлять в initramfs драйверы, только необходимые для загрузки системы хватит если не на 10 ядер, то уж на 5 точно и при условии, что модули grub и его конфиг будет лежать там же.

Смотри: по сообщению можно судить, что автор, скорее всего, недавно использует Linux или ставит первый раз.

Будешь ли лично ты, первый раз используя что-либо сразу использовать более сложные варианты настройки или использования?

Нет, ты поставишь, скорее всего, в обычном режиме.

В случае автора, в обычном режиме без шифрования и прочего.

Автор же пишет:

Выделил 64 гигабайта, создал раздел под названием debian (использовать как: том для шифрования), шифрованный том

Нафейхуа спрашивается?

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

Далее судя по этому:

Далее создал группу debian-vg и в неё добавил: root (ext4, /), swap (раздел подкачки), home (ext4, /home).

Он либо, всё же более-менее разбирается, значит здесь разумно предоставить вывод таблицы разделов:

fdisk -l

Он не указал в каком варианте он загрузился, uefi или bios, вполне возможно, что загрузился в BIOS режиме, а Windows 100% установлена в UEFI режиме.

А так, почитать хотя бы вот это:

• https://wiki.debian.org/GrubEFIReinstallOnLUKS
• https://wiki.debian.org/ru/Crypt

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

Иначе, он может поступить как в случае Windows, т.е. сделать авто разметку / установку с удалением всех данных на накопителе и даже автоматом в таком случае поставится и шифрованная система.

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

Здесь же минимально необходимая информация для анализа не предоставлена.

Вот поэтому и не хочу.

Плюс Arch только 1 ядро хранит,

В ролинге одно? Не верю !

а Debian – 3 последних.

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

А нафига, если эти ядра в кэше пакмана лежат, также три штуки по умолчанию. В арче зато по умолчанию генерится дополнительный (fallback) initrd, на случай чего. Само-то ядро не ломается, а вот корень, разрабы опасаются, что может не примотироваться в один «прекрасный» момент. Бывало у меня такое, но давно, когда ещë в ходу ext3 была.

Новое ядро внезапно может не загрузить систему, вероятность 0 но она есть. Хотя согласен, в случае АРЧа для админов локал-хостов это пофигу.

Не загрузится только если диск внезапно даст сбой, но в этом случае ремонтное ядро не поможет. Так что это пустая трата места :) Ядро грузится всегда, даже если какой-нибудь модуль создаёт проблемы. Я с 2011 года ни разу не сталкивался с незагружающимся ядром. Неисправность загрузчика – это не тот случай.

А я вот однажды столкнулся.

Ядро грузится всегда, даже если какой-нибудь модуль создаёт проблемы. Я с 2011 года ни разу не сталкивался с незагружающимся ядром.

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

У него арч, а это админ-локал-хоста. Вот когда у кого нибудь HPE отвалится полка тогда он поймет про что речь.