Почему большинство дистрибутивов объединяет в цепочку UEFI и личинку?

Учитывая, что UEFI был только определен в 2005 существует набор устаревшего оборудования там, которое не поддерживает спецификацию. Добавить UEFI к стандартному распределению потребовало бы тестирования двух путей выполнения кода вместо одного, и мало того, что загрузочный код является известно привередливым, это - один из наиболее раздраженно трудоемких битов кода для тестирования.

Дистрибутивы имеют ограниченные ресурсы и не может быть никаких причин вообще кроме того. Это может быть довольно просто и безопасно, но независимо от того, чего будет требоваться больше работ по техническому обслуживанию, потому что опция личинки должна сохраняться, если только для не системы UEFI.

Я уверен, что у всех есть список функций и опций, которые они хотели бы видеть, что дистрибутивы принимают (я дам Вам несколько страниц, lol), и несомненно многие из тех были бы "полностью легки, никакие стычки, честно...". Однако нет бесконечной суммы человеко-часов для реализации их. Когда сталкивающийся с решениями как это ("Делают нас, мы помещаем работу в эту функцию, по сравнению с некоторым другим?"), основные вопросы должны быть:

• Действительно ли это необходимо? (Ответ вот не).
• Сколько людей извлечет выгоду, и сколько? (IMO: некоторые, и не очень)
• Существует ли разумная альтернатива, посредством которой пользователь может разместить его сам без нас делающий что-нибудь? (По-видимому, существует.)

Причина люди используют дистрибутивы вообще, состоит в том, потому что все подвергаются ограничениям ресурсов (иначе, просто наймите команду, купите их некоторое пространство и оборудование, и сделайте, чтобы они сделали все для Вас точно, как Вы хотите). Таким образом, действительность - то, что дистрибутивы отражают обобщенные потребности своих пользователей.

Тем не менее я действительно думаю, что это будет вовремя принято как опция и я upvoted вопрос.

Быть предназначением загрузчики UEFI, кроме того, для расчистки усложнило бы контроль качества и поддержку. Дистрибутивы предназначаются для личинки, а не спецификации UEFI, потому что личинка является бесплатным программным обеспечением, hackable, более гибким, и высококачественным. Можно все еще получить чистую-UEFI начальную загрузку следующим учебное руководство и монтирование раздела UEFI на /boot, потому что, если Вы делаете это, обслуживание находится на Вас.

Они объединяют в цепочку UEFI и GRUB как временное решение по реализации.

Поскольку поддержка UEFI и сопроводительные проблемы (например, Защищенная загрузка) разрешены, все больше дистрибутивов будет использовать ее непосредственно. Тем временем это является все еще очень новым: Тенденции Google показывают скорее ограниченное принятие: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C%20%20bios&cmpt=q

Другие все упомянули потенциальные ловушки движения для чистого решения UEFI и/или поддержки и non-UEFI и чистые системы UEFI одновременно. Ядро UEFI могло бы работать над non-UEFY системой, но инструменты обновления ядра должны обновить или меню GRUB ИЛИ меню начальной загрузки UEFI ИЛИ обоих и т.д. и т.д.

Это действительно о контроле качества, как упомянуто: значительно проблемы с этим кодом оказывают высокое влияние: Когда компьютеру не удается загрузить новых пользователей, т.е. потенциальный Linux преобразовывает, угробит его как мусор и вернется к чему-то "безопасному".

Но поскольку я сказал, поскольку технология получает больше принятия, это станет стандартом.

Дополнительный код необходим для работы с ошибками в прошивке

При отсутствии цепочки grub дистрибутив больше полагается на прошивку для корректной загрузки. Так как любое программное обеспечение будет иметь проблемы, то и микропрограмма тоже склонна к этому. Теперь дистрибутив Linux должен будет написать, чтобы обработать и эти ошибки в микропрограмме.

Пример из реальной жизни. Материнская плата Asrock H81 pro BTC P1.80 позволяет создавать пункты меню загрузки с помощью efibootmgr. Можно создать несколько пунктов меню загрузки и изменить порядок загрузки с помощью efibootmgr --bootorder XXXX,YYYY,ZZZZ или установить временную следующую опцию загрузки с помощью efibootmgr --bootnext XXXX. Обе эти команды возвращают вывод, который дает вам идею, что порядок загрузки изменился или будет запущена следующая загрузка, например BootNext: XXXX. Однако при перезагрузке упрямая прошивка просто игнорирует только что запрошенную опцию загрузки и перезагружается в предыдущее значение BootCurrent:. Постоянное изменение порядка загрузки может быть произведено только из утилиты настройки микропрограммы. А не постоянное изменение вообще недоступно.

Настоящая проблема в том, что люди не понимают, как это работает. Например, в своем вопросе вы упоминаете, что три скрипта - это все, что необходимо, и большинство ответов здесь касаются всего / любого дополнительного обслуживания, которое потребуется для его работы, но правда в том, что вам эти скрипты не нужны. или любая дополнительная работа.

Все, что вам нужно, это привязать монтирование ESP - или где бы вы ни хотели сохранить ядро ​​- поверх / boot , что вы можете сделать с помощью одной строки в / etc / fstab ]. Сделайте это, и все текущие сценарии обновления ядра просто продолжат работать.

Мой файл `/ etc / fstab 'выглядит так:

LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#

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

Итак, в то время как загрузчик , такой как grub , на самом деле выполняет только больше работы, приложение меню, такое как rEFInd, выравнивает различия и упрощает все.

Файлы в /proc в основном реализованы как драйверы устройств. Они в основном реализованы в пути, сходном с последовательными устройствами (/dev/ttyS * ), за исключением того, что вместо возврата данных с аппаратного обеспечения программист возвращает данные, сгенерированные его программой.

В путь он похож на веб-сервер. Только вместо прослушивания tcp-сокета и ответа файлы /proc являются драйверами устройств, которые прослушивают запросы на чтение и отвечают.

В конструкции драйверов ядра Unix нет ничего, что вынуждало бы узлы устройств монтироваться только в /dev , поэтому люди воспользовались возможностью разработать и стандартизировать каталог /proc , чтобы содержать виртуальные устройства, которые возвращают некоторую информацию о времени выполнения. В настоящее время ядро Linux включает специальные методы для работы с драйверами /proc .

Вот статья о драйверах устройств, которая включает в себя пример драйвера /proc : http://www.linuxdevcenter.com/pub/a/linux/2007/07/05/devhelloworld-a-simple-introduction-to-device-drivers-under-linux.html

В идеале следует использовать ключи ssh вместо пароля открытого текста, хранящегося в файле/сценарии. Это выглядит как дубликат https://stackoverflow.com/questions/4594698/using-a-variables-value-as-password-for-scp-ssh-etc-instead-of-prompting-for

Я думаю, что если загрузка осуществляется только EFI и мы удаляем загрузчик, то это будет трудно как для поставщиков аппаратных средств, так и для производителей операционных систем. Поставщик аппаратных средств будет иметь больше ядер для тестирования, в то время как для компаний, которые выпускают ОС, это будет похоже на то, загружено ли их ядро различными FW.

Кроме того, при прямой загрузке ядра из EFI, куда в стеке будет помещаться безопасная загрузка? В текущем сценарии, как только управление переходит к загрузчику ОС, то загрузчик проверяет, правильно ли подписано ядро или нет. В случае, если мы загрузим ядро непосредственно из EFI, тогда я думаю, что это создаст беспорядок только как весь стек будет нарушен. Просто мнение из того, какое у меня понимание.