Во времена #EFI & #UEFI этот самый #GRUB уже и не нужен.
Во-первых, полно и других разнообразных UEFI boot manager'ов.

Во-вторых, не особо то они и нужны вообще как класс. Компьютер можно загружать и напрямую через EFI-stub ядра ОС, образы которых давно собираются как EFI-приложения (раз и два).
Т.е. надо идти в настройки UEFI материнской платы и смотреть загрузочные записи, хранящиеся в #NVRAM — дописывать туда все те параметры\аргументы, которые UEFI при старте компа будет подставлять в качестве аргументов командной строки. Так же как и GRUB или другой boot manager грузящий vmlinuz-файл.

Цивилизованный старт
Использовать то, что было известно как #gummiboot, а теперь стало называться #systemd-boot. Там вполне удобные текстовые файлы в /boot/loader/entries/... через которые можно передать нужные значения и аргументы в переменные. Например такие как используются для #LUKS разделов:

options rd.luks.options=password-echo=no options rd.luks.data=UUID=/dev/disk/by-id/nvme-VENDOR-partN options rd.luks.name=UUID=my-enc-swap options resume=/dev/mapper/my-enc-swap options rd.luks.data=UUID2=/dev/disk/by-id/nvme-VENDOR-partY options rd.luks.name=UUID2=my-enc-root options root=/dev/mapper/my-enc-rootНе обязательно задавать таким образом по одной опции на строке, можно устраивать свалку пихая всё в одну большую строку.

Комментарий №1
В данном примере, это когда swap идёт не файлом, а отдельным разделом на диске, такое размещение упрощает использование swap для hibernate.

Комментарий №2
Все эти LUKS-опции не обязательно указывать при каждом запуске системы в /boot/loader/entries/... файлах или через загрузочные записи UEFI внутри #NVRAM
Можно прописать всё это сопоставление и через файл /etc/crypttab.initramfs перед генерацией\созданием #initramfs образа.

#linux

Now that I have #uboot, #systemdboot and #nixos running on my phone, no one will be able to stop me, mwuahahah

#weeknotes

Про полнодисковое шифрование #FDE средствами #Luks
На ровном месте проявилась проблема, что идентификаторы разделов (partitions) теряются в определённых обстоятельствах. Потому система не может загрузиться, из-за чего в опции rd.luks.data приходится использовать /dev/disk/by-id/... вместо UUID'а раздела на диске.

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

Например, это затирание было замечено после того как выполнялось выставление флагов allow-discards, no_read_workqueue и no_write_workqueue через:
cryptsetup open --type luks2 --persistent --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue ...

Соответственно, для `systemd-boot` загрузчика в файле /boot/loader/etries/your-system-100.500.conf приходится указывать нечто сродни:
options    rd.luks.data=7f2df3a2-3c68-492e-bbd6-1ccf956379c0=/dev/disk/by-id/nvme-VENDOR_MODEL_SERIAL_ID_-partN
options    rd.luks.name=7f2df3a2-3c68-492e-bbd6-1ccf956379c0=crypto_dev_name
... или ...
options    rd.luks.data=2b507209-fcf1-4aae-a55a-1ba4e908cc8b=/dev/disk/by-id/ata-VENDOR_MODEL_SERIAL_ID_-partN
Где:

• partN — это part1 или part2... part3 и т.д. номер разделов.
• Используемые UUID'ы это из Luks-заголовка, т.е видимые через cryptsetup luksDump и отсутствующие в выдаче:
  lsblk -f
• Идентификаторы разделов конкретного диска ...-VENDOR_MODEL_SERIAL_ID_-partN можно наблюдать через:
  ls /dev/disk/by-id/

Тоже самое касается и /etc/cryptsetup.initramfs, если таковой используется.

Почему #systemd-boot?
Использование #GRUB весьма неразумно при полнодисковом шифровании, так же использовать GRUB затруднительно, когда при старте надо открывать несколько шифрованных разделов.
Например, один из разделов на диске может быть swap, в который сохраняется система при hibernate. Да swap может быть и файлом на основном разделе, но далеко не всех такое устраивает и не все файловые системы это поддерживают.

#lang_ru #linux #LUKS

Почти на любой не особо древней материнской плате можно использовать NVMe-диск M.2 вставленный через PCI-адаптер (PCI x4) в какой-нибудь из нескольких PCI-слотов (желательно с четырьмя и более каналами).
В таком случае SATA-диски проигрывают по скорости в несколько раз, даже при наличии на материнской плате поддержки лишь древней второй версии #PCIe (PCIe v.2). На вполне конкретных примерах вместо 390 Мб/с наблюдается стабильные 1,7 Гб/с.

Загрузка системы на NVMe
Обычно, людей останавливает тот момент, что BIOS (точнее EFI) древних материнских платах не позволяет загружаться с NVMe-дисков, но это не является проблемой в случае таких систем как линуксы.
Т.е. сама по себе система (ОС) может располагаться на nvme-диске, но загрузчик системы с #initramfs и образом ядра при этом на совершенно другом диске или же вообще на вынимаемом носителе.
Для запуска системы нужен boot-раздел весьма скромный по размерам, хватит и 200-300 мегабайт. И располагаться таковой boot-раздел может хоть на flash'ке, хоть на SD-карточке или же быть разделом на SATA-диске.

Как работает загрузка ОС?
При включении питания #UEFI, оно же #EFI, читает записи в своей энергонезависимой памяти #NVRAM в поисках информации о том, какие EFI System Partition (ESP) на каких носителях следует использовать в каком порядке.
#ESP это обычный раздел (partition) с файловой системой FAT16 или FAT32, которую прекрасно понимает EFI-система и на ней смотрит файлы являющиеся загрузчиками сродни: #rEFInd, #GRUB или #systemd-boot
Так же, в качестве загрузчика может быть и специально собранный образ ядра ОС — например, т.н. EFI boot stub.

Или проще добавить поддержку #NVMe?
Иногда вполне реально научить комп грузиться с NVMe. Надо взять «Intel ME Tools» и снять дамп SPI Flash чипа на материнской плате, а в снятый образ EFI-системы добавить NVMe-драйвер (через «UEFI Tool»). После чего, уже пропатченный образ записывается обратно в SPI Flash чип на материнской плате.

Доводилось такое выполнять, используя «Flash Programming Tool» (fpt.exe) из пакета «Intel ME Tools» и это не из под Windows, а из под #FreeDOS. Создавая загрузочную флешку через dd и докидывая на неё один файл «fpt.exe».
Не сказать чтобы удобно, но дампить и шить из под Windows требует сперва установить и саму эту ОС и нужные драйвера от материнской платы вместе с Intel ME/AMT. И выходит, что в ряде случаев проще и быстрее лишние пару раз загрузиться с флешки.

В более поздних версиях «Intel ME Tools» для более новых материнских плат (чипсетов, PCH) появился вариант «Flash Programming Tool» и для линухов. Ненаглядный «flashrom» в ряде случаев бесполезен, может снять дамп лишь с одного из чипов, коих обычно две штуки. Т.е. вместо 12 Мб сделает дамп лишь 8 Мб, то же FPT во время работы показывает с какого SPI-чипа сколько снято или в него записано.

#nvme #nvmessd #linux #hardware #intel #IntelME #lang_ru @Russia