Объясните о тонкостях UEFI

Кто именно добавляет загрузочные записи в меню?

Фирмварь, если умеет. Или утилитками.

С этими записями что-то делает Linux при загрузке?

Читает таблицу, она доступна из /sys, но писать в неё напрямую всё равно нельзя.

Я попал в заколдованный круг: efibootmgr показывал больше сотни дубликатов одной и той же записи, я их удалил, но с каждой перезагрузкой они добавляются опять.

Этим страдают некоторые дистры. Но если их так много, то это косяк.

То есть проблема в дистрибутиве или в uefi? Или в обоих?

Ты как-то не очень убедительно объяснил.

В дистрибутиве. Это он срёт в таблицу, только я пока не понял, как он это делает.

А ты чего хотел? Праздник же, не все в здравом уме. Объяснил, как мог. По крайней мере я старался.

Спасибо. Я пока не уверен, но успел с помощью видеокамеры в телефоне прочесть надпись типа «системный загрузчик не найден, но мы тут тебе ща быстро создадим новую запись». Как и почему оно пишет «\EFI\fedora\grubx64.efi» - я без понятия.

Как и почему

Как — понятно: он парсит таблицу, не находит там запись по каким-то критериям, и пишет её заново (чем — вопрос в федору, ибо утилит хватает). А вот почему не находит свою же запись — большой вопрос, и задавать его надо на багтрекер федоры.

Вот как оно работает: запускается shim, не находит записей и запускает fallback.efi, который смотрит в свой конфиг:

cat /boot/efi/EFI/fedora/BOOT.CSV 

��shim.efi,Fedora,,This is the boot entry for Fedora

И по нему создает загрузочную запись. Почему это точно так - я через интерфейс загрузил shim.efi - система стартовала без новых записей. Так что обходной путь найден.

и задавать его надо на багтрекер федоры.

https://bugzilla.redhat.com/show_bug.cgi?id=1295124 - пока молчат.

Остается решить как создать правильную запись и как остановить создание новых.

Остается решить как создать правильную запись и как остановить создание новых.

А они точно «не правильные»? То есть, если с них грузится то, что нужно, то оно не может быть не правильным. Оно может читаться как неверная запись, или игнорроваться как родная, и прописывать новую запись «чтобы было», хотя уже есть, но оно почему-то не признаёт своё, и прописывает.

// Я запутался в этой рекурсии. (=

Действительно не все так просто, я сочуствую обычным пользователям которые попали в аналогичную ситуацию.

Вот как все работает: http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/

Ни одна из существующих записей не принимается - почему - хз. Поэтому запускается резервный вариант - fallback.efi, который создает еще одну, «правильную» запись на его взгляд. Пути верные, я проверял. Пробовал создавать свои записи как написано в документации:

efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l '\EFI\fedora\grubx64.efi' -b 10

Но если вручную выбрать в биосе .efi-файл - никаких проблем, все работает как надо.

Действительно не все так просто, я сочуствую обычным пользователям которые попали в аналогичную ситуацию.

Не ты первый, не ты последний.

Ни одна из существующих записей не принимается - почему - хз.

Это косяк в парсере, я уже говорил. Пусть правят.

Или в биосе. Я для интереса скопировал запись с десктопа, только поменял пути - не заработало. Короче после всего этого извращенства имхо наилучшим путем является отключение UEFI.

Ну, EFI тоже может быть виноват, но это сводится к непониманию дистрового злодея, добавляющего запись. Всё равно это баг. Кстати, прошивку EFI тоже бы обновить, если обновление доступно.

наилучшим путем является отключение UEFI

А смысл? Я вот за четыре года от использования grub-efi-amd64 так и не ощутил каких то преимуществ, просто это очередная веха в развитии электроники, как 64-битная ОС, и рано или поздно такой способ загрузки останется единственным, а legacy вымрет как мамонты вымирают сейчас 32-битные программы.

grub-efi-amd64

а груб-то чего использовать в 2016 году?

Просто мне как-то влом чистить каждий раз таблицу, да и хз не гавкнется ли nvram из-за такого. А грузить руками .efi через F9 тупо.

Если secureboot отключаемый, или можно загрузить свои ключи, то веселее грузить сразу ядро, без этих говнобутоадеров. UEFI еще слишком молод, и на многих девайсах крайне крив

Так убери этот shim, если уверен что это он срет

Убирал, grub2-efi не грузит систему. О sboot нет никакого упоминания. Сейчас попробую еще 3-4 livecd для подтверждения идеи о баге в UEFI.

Что значит - не грузит? Shim его же потом запускает, нет? Можно еще grub-install для верности накатить.

Попробуй ядро прямиком еще.

# grub2-install --boot-directory=/mnt/system/boot --bootloader-id=Fedora  --target=x86_64-efi --efi-directory=/mnt/system/boot/efi

Вот так я делал, в итоге консоль grub2 при старте.

Просто нужно пользоваться законченным (относительно остальных) продуктом, а не тестовым глюкодромом. Намёк ясен?

Например?

r3lgar, vasily_pupkin, livecd убунты после ругательств запустился в legacy-mode, так что 99% дело в прошивке UEFI. Увы.

livecd убунты после ругательств запустился в legacy-mode, так что 99% дело в прошивке UEFI. Увы.

Ты прошивку обновлял? А то тут тоже какие-то странности.

Да, последняя версия за 03.2015 и переустановка не решила проблему. Попробую в качестве последней меры gummiboot & rEFInd.

в итоге консоль grub2 при старте.

С uefi всё впорядке, он своё дело сделал. Загрузил grubx64.efi.

А вот grub у тебя уже поставился криво, не находит свои файлы в /boot.

Возможно, из-за того, что устанавливал с livecd. Как минимум попробуй установку с livecd из chroot'а. Как правило помогает. А лучше, как либо загрузись в систему, и сделай grub2-install из неё.

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

Да, я устанавливал c livecd. Может я как-то не так ставлю grub2?

 #grub2-install --efi-directory=/boot/efi/ --target=x86_64-efi --boot-directory=/boot/

# ls /boot
ls /boot/
config-4.4.0-0.rc6.git1.1.fc24.x86_64
config-4.4.0-0.rc6.git1.2.fc24.x86_64
efi
elf-memtest86+-5.01
extlinux
grub2
initramfs-0-rescue-bb2c3a03e7b04a319db82f9de985513a.img
initramfs-4.4.0-0.rc6.git1.1.fc24.x86_64.img
initramfs-4.4.0-0.rc6.git1.2.fc24.x86_64.img
initrd-plymouth.img
lost+found
memtest86+-5.01
System.map-4.4.0-0.rc6.git1.1.fc24.x86_64
System.map-4.4.0-0.rc6.git1.2.fc24.x86_64
vmlinuz-0-rescue-bb2c3a03e7b04a319db82f9de985513a
vmlinuz-4.4.0-0.rc6.git1.1.fc24.x86_64
vmlinuz-4.4.0-0.rc6.git1.2.fc24.x86_64

# ls /boot/efi/
EFI  loader  mach_kernel  System

/boot/grub2/grub.cfg

Может я как-то не так ставлю grub2?

#grub2-install --efi-directory=/boot/efi/ --target=x86_64-efi --boot-directory=/boot/

Попробуй в chroot установить загрузчик, просто установи пакет grub-efi... как он там называется в твоём дистрибутиве.

Я так понял, что после установки из chroot'а так же grub console?

Ставишь вроде правильно, но я по грабу не спец. С livecd ты, я надеюсь, не в legacy грузишься? Без efi-vars это всё может не работать.

По-хорошему, надо попробовать поставить из твоей загруженной системы, но для этого надо сперва загрузиться, да.

Ну и переустановить grub2-efi, grub2-efi-modules, как советует анон тоже не помешает.

Можно попробовать сделать grub-standalone. Опять же из chroot, и в efi-режиме.

Кстати, множественные записи в efibootmgr при загрузке с live/сломанного grub не создаются? И каким livecd ты пользуешься?

С livecd ты, я надеюсь, не в legacy грузишься?

Я гружусь простым выбором .efi-файла через фирмварь, efivars -l показывает ~20 файлов. LiveCD - последние Fedora & Ubuntu. Пробовал все перечисленное плюс даунгрейд пакетов, увы никаких перемен.

Кстати, множественные записи в efibootmgr при загрузке с live/сломанного grub не создаются?

Нет, как я уже выяснил выше, их создает shim, точнее его /EFI/BOOT/fallback.efi.

Взлетело только одно решение - systemd-boot. Команда установки сама прописала себя в boot entries, немного шаманства с конфигами и все работает заработало. Не знаю сколько хейтеров сожгли для жертвоприношения Леннарт и компания и к какой темной магии прибегали, но Grub2 & Shim так и не заработали.

Cпасибо уходит Ivan_qrt, r3lgar и остальным.

[root@probook ~]# bootctl 
System:
     Firmware: UEFI 2.00 (HPQ 4096.01)
  Secure Boot: disabled
   Setup Mode: user

Loader:
      Product: systemd-boot 228
    Partition: /dev/disk/by-partuuid/2bab38e7-5a34-4693-a7a0-e4b517d91268
         File: └─/EFI/Boot/Bootx64.efi

Boot Loader Binaries:
          ESP: /dev/disk/by-partuuid/2bab38e7-5a34-4693-a7a0-e4b517d91268
         File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 228)
         File: └─/EFI/Boot/BOOTX64.EFI (systemd-boot 228)

Boot Loader Entries in EFI Variables:
        Title: Linux Boot Manager
           ID: 0x0003
       Status: active
    Partition: /dev/disk/by-partuuid/2bab38e7-5a34-4693-a7a0-e4b517d91268
         File: └─/EFI/systemd/systemd-bootx64.efi

# cat /boot/loader/loader.conf 
default C854-87AD-*
timeout  4

# cat /boot/loader/entries/C854-87AD-4.4.0-0.rc6.git1.2.fc24.x86_64.conf 
title      Fedora 24 (Rawhide)
version    4.4.0-0.rc6.git1.2.fc24.x86_64
machine-id bb2c3a03e7b04a319db82f9de985513a
linux      /vmlinuz-4.4.0-0.rc6.git1.2.fc24.x86_64
initrd     /initramfs-4.4.0-0.rc6.git1.2.fc24.x86_64.img
options    root=UUID=30b151db-ac66-433b-af0a-eef79aae9218 rw quiet