Чому більшість дистрибуторів ланцюжок UEFI і grub?

Більшість дистрибутивів встановлюють додатковий завантажувач у системі 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?

Посилання:

• Як відтворити завантажувальний розділ EFI?

EDIT: Я не говорю про повне видалення підтримки grub, а про те, щоб запропонувати вибір тим, хто хоче використовувати її з різних причин. Розподіл може забезпечити пакет grub-efiдля тих, хто хоче зв’язати UEFI і grub, і пакет, efistub-bootякий містить сценарії, про які я згадував вище.

Зважаючи на те, що UEFI був визначений лише у 2005 році, там є маса застарілого обладнання, яке не підтримує специфікацію. Щоб додати UEFI до стандартного розповсюдження, потрібно тестувати два шляхи коду замість одного, і це не лише те, що завантажувальний код є сумно вибагливим, це один з найбільш дратуючих трудомістких бітів коду для тестування.

Дистрибуція має обмежені ресурси, і поза цим може бути зовсім ніяких причин. Це може бути досить простим і безпечним, але незалежно від того, для чого знадобиться більше робіт з технічного обслуговування, тому що опція збитку повинна підтримуватися, якщо тільки для систем, які не належать до УЄФІ.

Я впевнений, що у кожного є список функцій та варіантів, які вони хотіли б бачити у дистрибутивах (я дам вам кілька сторінок, коханий), і, без сумніву, багато з них були б "абсолютно легко, без клопоту, чесно. .. ". Однак не існує нескінченної кількості годин людини на їх виконання. Якщо ми стикаємося з такими рішеннями ("Чи ми вкладаємо роботу над цією функцією порівняно з деякими іншими?"), Основними питаннями повинні бути:

• Це потрібно? (Відповідь тут - ні).
• Скільки людей піде на користь, а скільки? (ІМО: кілька, і не багато)
• Чи є розумна альтернатива, за допомогою якої користувач може влаштувати себе, не роблячи нічого? (Мабуть, є.)

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

Однак, я думаю, що вчасно це буде прийнято як варіант, і я підтримав це питання.

Орієнтація на завантажувачі UEFI на додаток до grub ускладнить контроль якості та підтримку. Дистрибуції орієнтовані на грубку, а не на специфікацію UEFI, тому що grub - це вільне програмне забезпечення, рухоме, гнучкіше та якісне. Ви все одно можете отримати завантаження з чистою UEFI, дотримуючись підручника та встановивши розділ UEFI /boot, оскільки якщо ви це зробите, технічне обслуговування залежить від вас.

Справжня проблема полягає в тому, що люди не розуміють, як це працює. Наприклад, у своєму запитанні ви зазначаєте, що три сценарії - це все, що необхідно, і більшість відповідей тут стосується всього / будь-якого додаткового обслуговування, яке потрібно для його роботи - але правда, ці сценарії вам не потрібні. або будь-яка додаткова робота.

Все, що вам потрібно, - це прив’язати кріплення 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 - вирівнює різниці та спрощує все.

Вони розпочали ланцюжок UEFI та GRUB як рішення про тимчасове впровадження.

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

Інші згадували про можливі проблеми, пов'язані з досягненням чистого рішення UEFI та / або підтримки одночасно як систем, що не є UEFI, так і чистими системами UEFI. Ядро UEFI може працювати в системі, яка не є UEFY, але інструменти оновлення ядра повинні оновлювати або меню GRUB, або меню завантаження UEFI АБО і те, і інше і т.д.

Дійсно, про контроль якості, як згадувалося: важливо, що проблеми з цим кодом мають високий вплив: Коли комп'ютер не зможе завантажувати нових користувачів, тобто потенційних перетворювачів Linux, він викине його як сміття і повернеться до чогось "безпечного".

Але, як я вже говорив, у міру того, як технологія набуває більшої популярності, вона стане стандартом.

Для усунення помилок вбудованого програмного забезпечення необхідний додатковий код

Якщо ланцюжок не пов'язаний, дистрибутив більше покладається на програмне забезпечення для правильного завантаження. Оскільки будь-яке програмне забезпечення матиме проблеми, прошивка також схильна до цього. Тепер дистрибутивам 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, то я думаю, що це створить безлад лише тоді, коли буде порушено весь стек. Просто думка з того, що я розумію.