LINUX.ORG.RU

Вопросы по загрузчикам

 , ,


0

1

День добрый.

  1. Правильно ли я понимаю, что systemd-boot не может работать с каталогом boot? Без использования скриптов для uefi shell.

  2. Каких проблемм можно ожидать, если использовать FAT32 для раздела boot? Домашний ПК.

  3. У refind есть два конфига:

/boot/refind_linux.conf
esp/EFI/refind/refind.conf

Как я понимаю, первый отвечает за параметры загрузки ядра:

"Boot" "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw initrd=boot\initramfs-linux.img"

Второй, по идее, должен отвечать за конфигурацию меню. Тогда за что отвечают строки второго конфига, начинающиеся с menuentry? Как пример:

menuentry "Arch Linux" {
	icon     /EFI/refind/icons/os_arch.png
	volume   "Arch Linux"
	loader   /boot/vmlinuz-linux
	initrd   /boot/initramfs-linux.img
	options  "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw add_efi_memmap initrd=boot\intel-ucode.img initrd=boot\amd-ucode.img"
	submenuentry "Boot using fallback initramfs" {
		initrd /boot/initramfs-linux-fallback.img
	}
	submenuentry "Boot to terminal" {
		add_options "systemd.unit=multi-user.target"
	}
}

На виртуалке, я не заметил никакой разницы, даже при удалении второго конфига.

  1. Подгружается ли микрокод, при использовании виртуальной машины? ВМ Oracle VirtualBox, systemd-boot c конфигом:
...
initrd /amd-ucode.img
...

ничего не выводит на команду:

dmesg | grep microcode
  1. На что влияет опция ro или rw в конфиге загрузчика?
root=PARTUUID=... rw или ro 

Systemd по умолчанию rw, а refind - ro.

З.Ы. Оффтоп. Столкнулся с необходимостью написать хук для пакмана, методом тыка получилось оформить параметр Exec. Если я правильно понимаю, то он заполняется в соответствии с правилами написания скриптов? Хотелось бы ознакомиться с соответствующими руководствоми, желательно уровня «чайник».

refind умеет автоматически находить ядро в /boot и отрисовывать его в меню загрузки. Если есть файл /boot/refind_linux.conf, refind будет использовать параметры загрузки оттуда, если нет – сам выберет, что сможет (initrd тоже может автоматически найти, например). В таком случае в esp/EFI/refind/refind.conf можно ничего не прописывать.

В арч вики это расписано, в общем-то: https://wiki.archlinux.org/title/REFInd#For_kernels_automatically_detected_by_rEFInd

moonmadness
()
Ответ на: комментарий от moonmadness

Вот это меня и смущает, я не понимаю логику. У нас есть конфиг в /boot, в котором прописано все что связано с загрузкой ядра. Зачем добавлять еще секции связанные с загрузкой в другом конфиге, если сам загрузчик их игнорирует?

Пробовал экспериментировать

Ситуация 1. Одна система: Arch

/dev/sda1 - /boot/efi
/dev/sda2 - резерв
/dev/sda3 - /

Минимальная установка Arch, установка refind:

mkdir -p /boot/efi/EFI/BOOT/drivers_x64
cp /usr/share/refind/refind_x64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
cp /usr/share/refind/drivers_x64/ext4_x64.efi /boot/efi/EFI/BOOT/drivers_x64

То есть из всей установки, только efi приложение и драйвер на ext4. После чего меняем порядок загрузки: диск перед CD… и система спокойно загружается. Загрузчик использует текстовое меню, есть выбор нормал и сингл-юзер.

cp -r /usr/share/refind/{icons,fonts} /boot/efi/EFI/BOOT

Появился фон и иконки.

Ситуация 2. Одна система: Arch

/dev/sda1 - /boot/efi
/dev/sda2 - /boot
/dev/sda3 - /

Скопировал boot в новый раздел и примонтировал его:

umount /boot/efi
mount /dev/sda2 /mnt
mv /boot/* /mnt/
blkid /dev/sda2 >> /etc/fstab
nano /etc/fstab # исправил соответствующие строки
umount /mnt
mount -a

Проверка ls показала, что все на своих местах. reboot показывает, что загрузчик работает, но не может загрузить, т.к. не находит корень, видит только initrd=\initramfs-linux.img

Загружаемся с CD:

mount /dev/sda3 /mnt
arch-chroot /mnt
mount -a
mkrlconf # создает /boot/refind_linux.conf
nano /boot/refind_linux.conf # убираем строки, отвечающие за загрузку с CD
exit
reboot

Все опять работает. Попробуем по другому:

rm /boot/refind_linux.conf
cp /usr/share/refind/refind.conf-sample /boot/efi/EFI/BOOT/refind.conf
nano /boot/efi/EFI/BOOT/refind.conf # устанавливаем timeout на 5 секунд
reboot

Повторяется ситуация, загрузчик - ок, но корень не найден. Время на выбор, изменилось на 5 секнд, следовательно файл refind.conf подхватывается. Попробуем указать PARTUUID прямо в конфиге. Опять грузимся через CD:

mount /dev/sda3 /mnt
arch-chroot /mnt
mount -a
blkid /dev/sda3 >> /boot/efi/EFI/BOOT/refind.conf
nano /boot/efi/EFI/BOOT/refind.conf # ищем menuentry "Arch Linux", указываем PARTUUID, не забываем про кавычки, остальное оставляем как есть.
exit
reboot

И опять облом. Возможно я что-то делаю не так или чего-то не понимаю, но файл /boot/refind_linux.conf - является обязательным.

Убеждаемся, повторив загрузку с CD, выполнив mkrlconf и отредактировав созданный /boot/refind_linux.conf

Если он обязательный и в нем прописываются опции загрузки, то зачем соответствующие секции в /boot/efi/EFI/BOOT/refind.conf?

Дуалбут? Пробовал с Arch и Endeavours. Конечно не то, чтобы между ними большая разница. Но он уже стоял на виртуалке для тестов, я добавил диск, на который поставил Arch:

/dev/sda1 - /boot/efi
/dev/sda2 - / #корень Endeavours
/dev/sdb1 - / #корень Arch

Из ESP посносил все что было, включая grub от Endeavours, оставив только:

/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/drivers_x64/ext4_x64.efi

В /boot от Endeavours снес запчасти от grub, для чистоты эксперимента. И создав на каждом корне по refind_linux.conf.

Да загрузчик в текстовом режиме, но видит обе системы и они загружаются. Более того, в refind_linux.conf на арче, второй записью прописан PARTUUID от раздела Endeavours, и с него она вполне загружается, только нужно сделать дополнительные шаги, чтобы выбрать эту запись.

В общем, скорее всего, я чего-то не догоняю. Но на данный момент, логика не прослеживается.

ComIngSoon
() автор топика

Каких проблемм можно ожидать, если использовать FAT32 для раздела boot? Домашний ПК.

Никаких. Кроме того, элегантнее будет совместить ESP и boot-раздел, просто монтируя ESP в /boot. На машине с UEFI отдельный boot-раздел - лищняя сущность.

Столкнулся с необходимостью написать хук для пакмана, методом тыка получилось оформить параметр Exec. Если я правильно понимаю, то он заполняется в соответствии с правилами написания скриптов?

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

token_polyak ★★★★
()
Последнее исправление: token_polyak (всего исправлений: 3)
Ответ на: комментарий от token_polyak

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

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

ComIngSoon
() автор топика
Ответ на: комментарий от raspopov

Добрый, по большей части, это мои тараканы.

И я склоняюсь к systemd-boot, а не к refind. Последний, рассматривается именно как альтернатива, потому что мне не нравится идея /boot в FAT32 или отдельного extended boot раздела. Первое вызывает подозрение, а второе отторжение, как избыточное. Собственно, с этим и связаны первые два вопроса в теме.

Почему refind, а не grub? Нужно пояснить, что я новичек в linux, которому не нравится устанавливать все подряд. Отсюда Arch, который дает возможность выбора установки. Так же у меня есть свободное время, поэтому пытаюсь понять, что именно я делаю. При изучении темы загрузки системы с UEFI, я зацепился за возможность обойтись без загрузчика (EFISTUB). Выглядит красиво: избавится от прокладки, которая не нужна, но идея писать в память материнки… не зашла. Следовательно нужен загрузчик, который не будет этого делать. Под более менее пристальное рассмотрение попали grub, systemd-boot и refind. Где-то на этом моменте, возникла идея не использовать установку по скрипту, а использовать команды копирования.

Первым рассматривался grub, так как на него у меня уже был готов чек лист установки, но в wiki нет раздела по ручной установке. Скрипты, же лезут в память матери. Об опции --removable, можно сказать, что узнал вот только сейчас. Помимо прочего, его efi приложение, наиболее «жирное».

Вторым был systemd-boot, он уже часть системы, что несомненый плюс (для меня), для использования нужно одно efi приложение (наиболее «худое»!), два конфига и один хук на пакман, чтобы обновить это самое приложение, при выходе новой версии. Легко, просто и понятно. Еще бы он мог работать с каталогом /boot на корне.

refind стал третьим, который я рассматривал на уровне составления чек листа и экспериментов с установкой, а не простого пролистывания wiki. В нем, как и написано в теме, я столкнулся с непомниманием логики. Если забить на это недопоминание… я не вижу смысла в графике для загрузчика, по большоме счету, timeout = 0 будет в большинстве случаев. А когда он не в 0, то все равно никто не будет на него сидеть и любоваться. Естественно, это только мое мнение.

Про время загрузки, я не заморачиваюсь. Еще летом использовал комп с hdd и хрюшей из далекого 2008… так что кто из них загружается на пару секунд быстрее, мне все равно.

ComIngSoon
() автор топика
Ответ на: комментарий от Nanaju_Ko-wired

Мне это мало что говорит, но в systemd-boot есть «Установки с зашифрованной корневой директорией» в которой как раз упоминается luks

https://wiki.archlinux.org/title/Systemd-boot_(Русский)#Установки_с_зашифрованной_корневой_директорией

ComIngSoon
() автор топика
Ответ на: комментарий от ComIngSoon

Выглядит красиво: избавится от прокладки, которая не нужна

Эта прокладка избавляет тебя от сложностей при настройке и добавляет гибкости. Причём чем толще прокладка, тем более гибким и простым в настройке оно будет. GRUB вполне справится и с /boot в корне, и ОС тебе сам найдёт, так как у него есть свои драйверы файловых систем и генератор конфигурации os-prober.

nebularia ★★★
()
Последнее исправление: nebularia (всего исправлений: 1)
Ответ на: комментарий от nebularia

Возможно я чего-то не знаю или вообще пишу фигню, но:

  1. Ограниченное количество циклов записи у этой памяти. Насколько там душманская память, я не знаю.

  2. Нет жесткого стандарта на реализацию UEFI, производитель как хочет, так и делает.

  3. Лезть туда, где ошибка ПО может превратить систему в кирпич, желания тоже не много.

  4. Как покажет себя условная связка из grub + grub-btrfs + timeshift? То есть гипотетическая ситуация, когда в системе снимки создаются раз в день, соответственно раз в день происходит обновление загрузчика. Есть ли гарантия, что обновление загрузчика идет без перезаписи прошивки? Распространяется ли она на все загрузчики, средства создания снимков и дополнительных пакетов, реализующих их взаимодействие?

К примеру, timeshift предлагает установить/переустановить grub и обновить его меню… на системе в которой grub никогда и не было. Хз, откуда он его взял.

Если хотите проверить, то нужен диск с ext4. На btrfs, по памяти, мне такого не предлагали. Снимок сделан штатными методами timeshift. Ими же и восстанавливаюсь: востановить / параметры загрузчика (дополнительные). В этом меню, по умолчанию установлены следующие галки: (Пере)установить GRUB2, Обновить меню GRUB. И если для меню используется grub-mkconfig, то для установки, предположительно, это будет grub-install. Который, как раз, и лезет в прошивку.

  1. Использование загрузочной записи… А зачем каждый загрузчик, считает своим долгом, создать себе отдельный каталог и отдельную запись? Нет, я понимаю, если бы они не могли грузить больше чем одну систему, но ведь они могут. Пропиши себя по стандартному пути ESP/EFI/BOOT/BOOTX64.EFI, используй стандартную загрузочную запись, а все остальное добей конфигурационными файлами.
ComIngSoon
() автор топика