Большинство дистрибутивов устанавливают дополнительный загрузчик в системе UEFI. UEFI сам по себе является загрузчиком, он предлагает меню для выбора различных операционных систем или отдельных ядер. Кроме того, настройки UEFI можно легко изменить с помощью таких инструментов, как пользовательское пространство efibootmgr
.
Ядра начиная с версии 3.3 поддерживают EFI_STUB, что означает, что ядро может быть загружено непосредственно из UEFI. По какой причине дистрибутивы решают использовать дополнительный загрузчик? В большинстве руководств по Linux / UEFI основное внимание уделяется настройке дополнительного загрузчика (rEFInd, grub2, ELILO и т. Д.) Вместо загрузки Linux с EFI_STUB.
Единственное, чего не хватает в дистрибутивах - это поддержка. Поскольку в большинстве дистрибутивов имеется второй загрузчик, ядро не добавляется в меню загрузки UEFI и не копируется в системный раздел EFI.
Три сценария достаточно, чтобы сделать всю магию. Тот, который копирует initramfs в ESP. Второй копирует ядро в ESP и создает новую запись в меню загрузки UEFI. Третий сценарий удаляет старое ядро и initramfs из ESP и удаляет пункт меню загрузки UEFI. Это позволяет полностью автоматизировать обновления / очистки ядра / initramfs без участия пользователя. Я использую этот подход более года, и он работал безупречно.
Почему большинство дистрибутивов используют grub вместо EFI_STUB?
Ссылки:
РЕДАКТИРОВАТЬ: Я не говорю об удалении поддержки Grub полностью, но предложить выбор для тех, кто хочет использовать его по разным причинам. Дистрибутивы могут предоставить пакет grub-efi
для тех, кто хочет связать UEFI и grub, и пакет, efistub-boot
содержащий скрипты, которые я упомянул выше.
источник
Ответы:
Учитывая, что UEFI был определен только в 2005 году, существует множество устаревшего оборудования, которое не поддерживает спецификации. Чтобы добавить UEFI к стандартному дистрибутиву, потребуется тестирование двух путей кода вместо одного, и не только общеизвестно, что загрузочный код заведомо привередлив, но и является одним из самых раздражающих кусков кода для тестирования.
источник
У дистрибутивов ограниченные ресурсы, и не может быть никаких причин, кроме этого. Это может быть достаточно просто и безопасно, но независимо от того, что для этого потребуется больше работ по техническому обслуживанию, потому что опция grub должна быть сохранена, хотя бы для систем без UEFI.
Я уверен, что у всех есть список возможностей и опций, которые они хотели бы видеть в дистрибутивах (я дам вам несколько страниц, смеется), и, без сомнения, многие из них были бы «совершенно легкими, без хлопот, честно говоря. .. ". Однако не существует бесконечного количества человеко-часов для их реализации. Когда мы сталкиваемся с такими решениями («Мы включаем работу в эту функцию против некоторых других?»), Основными вопросами должны быть:
Причина, по которой люди вообще используют дистрибутивы, заключается в том, что у всех есть ограничения по ресурсам (в противном случае, просто наймите команду, купите им немного места и оборудования, и пусть они сделают для вас все именно так, как вы хотите). Таким образом, реальность такова, что дистрибутивы отражают общие потребности своих пользователей.
Тем не менее, я думаю, что со временем это будет принято в качестве варианта, и я поставил вопрос.
источник
Ориентация на загрузчики UEFI в дополнение к grub усложнит контроль и поддержку качества. Дистрибутивы нацелены на grub, а не на спецификации UEFI, потому что grub - это бесплатное программное обеспечение, взломанное, более гибкое и высококачественное. Вы все еще можете получить загрузку с чистого UEFI, следуя инструкциям и подключив раздел UEFI
/boot
, потому что если вы сделаете это, обслуживание будет за вами.источник
Настоящая проблема в том, что люди не понимают, как это работает. Например, в своем вопросе вы упоминаете, что три сценария - это все, что необходимо, и большинство ответов здесь касаются всего / любого дополнительного обслуживания, которое потребуется для его работы - но правда в том, что вам не нужны эти сценарии или любая дополнительная работа.
Все, что вам нужно, это подключить ESP - или там, где вы хотите сохранить ядро - поверх
/boot
, что вы можете сделать с помощью одной строки/etc/fstab
. Сделайте это, и все текущие сценарии обновления ядра просто продолжат работать.Мой `/ etc / fstab 'выглядит так:
Тем не менее, здесь есть хорошее замечание по поводу настроек, специфичных для производителя. UEFI явно ничего не указать интерфейс для меню загрузки. Это для захвата и не будет соответствовать между машинами. Это раздражает, но это правда.
И поэтому, в то время как загрузчик, такой как на
grub
самом деле, только требует больше работы, приложение меню, такое как rEFInd, выравнивает различия и все упрощает.источник
efobootmgr
для обновления порядка загрузки и изменения ядра по умолчанию).\EFI\BOOT\BOOTX64.efi
и поэтому он может быть назван так. UEFI не может (по спецификации) обрабатывать аргументы ядра в первую очередь - и поэтому образ initramfs / kernel должен быть связан вместе в этом случае. но я не знаю, что вы имеете в виду по поводу именования версий - я думаю, что это делают только Debian, и я считаю, что это все равно непродуктивно. условное название для вашего ядраvmlinuz
. В любом случае, правильный способ сделать это с помощью менеджера загрузки, а не загрузчика . Используйте приложение EFI, которое находит ваше ядро и передает его имя EFI для загрузки - как это делает rEFInd.vmlinuz-4.2.0-1-amd64
которое я оставляю как есть, а затем использую,efibootmgr
чтобы добавить это в список загрузки и сделать его по умолчанию. Я вижу, что наименование ядраBOOTX64.efi
может быть решением. Но в любом случае для этого мне понадобился бы сценарий, и, кроме того, он не позволяет легко сохранять несколько ядер, если все они названы одинаково.Они объединяют UEFI и GRUB в качестве решения для временной реализации.
Когда поддержка UEFI и сопутствующие проблемы (например, Secure Boot) будут решены, все больше и больше дистрибутивов будут использовать ее напрямую. Между тем, это все еще очень ново: Google Trends демонстрирует довольно ограниченное принятие: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios & CMPT = д
Другие упоминали все потенциальные ловушки, связанные с использованием чистого UEFI-решения и / или одновременной поддержкой как не-UEFI, так и чисто UEFI-систем. Ядро UEFI может работать в системе, отличной от UEFY, но инструментам обновления ядра необходимо обновить либо меню GRUB, либо меню загрузки UEFI, либо оба, и т. Д. И т. Д.
На самом деле речь идет о контроле качества, как уже упоминалось: важные проблемы с этим кодом имеют большое влияние: когда компьютер не загружается новыми пользователями, то есть потенциальными конвертерами в Linux, он превращает его в мусор и возвращается к чему-то «безопасному».
Но, как я уже сказал, по мере того, как технология получает все большее распространение, она станет стандартом.
источник
Дополнительный код необходим для обхода ошибок прошивки
Когда нет цепочки grub, дистрибутив больше полагается на прошивку для корректной загрузки. Поскольку у любого программного обеспечения будут проблемы, прошивка также склонна к этому. Теперь дистрибутивам Linux придется написать, чтобы обойти эти ошибки прошивки.
Пример из реальной жизни в качестве примера. Материнская плата Asrock H81 pro BTC P1.80 позволяет создавать пункты меню загрузки с
efibootmgr
. Может быть создано несколько пунктов меню загрузки, и порядок загрузки может быть изменен с помощьюefibootmgr --bootorder XXXX,YYYY,ZZZZ
или может быть установлен временный параметр следующей загрузкиefibootmgr --bootnext XXXX
. Обе эти команды возвращают вывод, что дает вам представление о том, что порядок загрузки изменился или будет запущена следующая загрузкаBootNext: XXXX
. Однако при перезагрузке упрямая прошивка просто игнорирует вновь запрошенную опцию загрузки и перезагружается в предыдущееBootCurrent:
значение. Постоянное изменение порядка загрузки может быть сделано только из утилиты настройки прошивки. И непостоянные изменения не доступны вообще.источник
Я думаю, что если загрузка выполняется только EFI и мы удаляем загрузчик, то это будет трудно как для производителя HW, так и для производителя операционной системы. У поставщика HW будет больше ядер для тестирования, в то время как для компаний, производящих ОС, будет похоже на то, загружается ли их ядро различными FW.
Более того, при прямой загрузке ядра из EFI, где в стеке будет помещаться защищенная загрузка? В текущем сценарии, когда управление переходит к загрузчику ОС, тогда загрузчик проверяет, правильно ли подписано ядро или нет. В случае, если мы загружаем ядро напрямую из EFI, я думаю, что это создаст беспорядок только потому, что весь стек будет нарушен. Просто мнение, из того, что я понимаю.
источник