Dlaczego większość dystrybucji łączy UEFI i grub?


31

Większość dystrybucji instaluje dodatkowy moduł ładujący w systemie UEFI. Sam UEFI jest programem ładującym, oferuje menu do wyboru różnych systemów operacyjnych lub poszczególnych jąder. Ponadto ustawienia UEFI można łatwo zmienić za pomocą narzędzi przestrzeni użytkownika, takich jak efibootmgr.

Jądra od wersji 3.3 obsługują EFI_STUB, co oznacza, że ​​jądro można załadować bezpośrednio z UEFI. Z jakiego powodu dystrybucje decydują się na użycie dodatkowego modułu ładującego? Większość samouczków na temat Linux / UEFI koncentruje się głównie na tym, jak skonfigurować dodatkowy moduł ładujący (rEFInd, grub2, ELILO itp.) Zamiast uruchamiania Linuksa za pomocą EFI_STUB.

Jedyne, czego brakuje w dystrybucjach, to wsparcie. Ponieważ większość dystrybucji zawiera drugi moduł ładujący, jądro nie jest dodawane do menu rozruchowego UEFI ani kopiowane na partycję systemową EFI.

Trzy skrypty są wystarczające, aby wykonać całą magię. Jeden, który kopiuje initramfs do ESP. Drugi kopiuje jądro do ESP i tworzy nowy wpis w menu rozruchowym UEFI. Trzeci skrypt usuwa stare jądro i initramfs z ESP i usuwa pozycję menu rozruchowego UEFI. Umożliwia to w pełni zautomatyzowane aktualizacje / czyszczenie jądra / initramfs bez interakcji użytkownika. Korzystam z tego podejścia od ponad roku i zadziałało bezbłędnie.

Dlaczego większość dystrybucji używa grub zamiast EFI_STUB?

Spinki do mankietów:

EDYCJA: Nie mówię o całkowitym usunięciu obsługi gruba, ale aby zaoferować wybór dla tych, którzy chcą go używać z różnych powodów. Dystrybucje mogłyby dostarczyć pakiet grub-efidla tych, którzy chcą połączyć UEFI i Grub oraz pakiet efistub-bootzawierający skrypty, o których wspomniałem powyżej.


4
Dlaczego powinni? Ustalili już metody przetwarzania / generowania pliku konfiguracyjnego grub. Ponadto pomaga, jeśli wszystkie systemy (spoza UEFI i UEFI) zachowują się tak samo.
Ulrich Dangel

Brzmi nieźle. Ale ponieważ zgodnie z tym linkiem możesz to zrobić, jeśli chcesz, może potencjalnym problemem dla dystrybucji jest zrobienie tego za Ciebie automatycznie. Betcha w końcu da ci taką możliwość.
goldilocks

1
@ Bakuriu Łatwiejszy do zrozumienia system, na przykład prostsza sekwencja uruchamiania, mniej wykonywany kod i nieco krótszy czas uruchamiania.
Marco

4
To pytanie należy odłożyć na bok, ponieważ podany powód wstrzymania jest nieprawidłowy. Pytanie ma prostą niekwestionowaną odpowiedź: UEFI nie zapewnia menu rozruchu. Niektóre implementacje to robią. Niektórzy tego nie robią, ponieważ w celu osiągnięcia docelowego czasu uruchamiania systemu Windows 8 BIOS nawet nie inicjuje urządzeń wejściowych . Nie mówiąc już o tym, czy użytkownik naciśnie klawisz. Musisz przejść przez Windows, aby dostać się do Linuksa lub odwrotnie. Ten pierwszy działa na niektórych systemach, ale wątpię, czy specyfikacja to gwarantuje. Ten ostatni nie działa (możesz wejść do konfiguracji UEFI z GRUBA, ale nie z Linuksa).
sourcejedi

1
@sourcejedi Twierdzisz, że nie pasuje do twoich źródeł. UEFI zapewnia menu startowe (interfejs użytkownika niespójny między dostawcami). mjg59 oznaczało, że nie możesz dostać się do menu uruchamiania bez filozoficznego kompromisu (akceptacja EULA W8). Ale ten problem będzie taki sam dla instalatorów z programami ładującymi GRUB spoza EFISTUB. Nie odpowiada więc, dlaczego wolimy gruba od EFISTUBA.
Lingzhu Xiang

Odpowiedzi:


10

Biorąc pod uwagę, że UEFI został zdefiniowany dopiero w 2005 r., Istnieje wiele starszych urządzeń, które nie obsługują specyfikacji. Dodanie UEFI do standardowej dystrybucji wymagałoby przetestowania dwóch ścieżek kodu zamiast jednej, a kod rozruchowy jest nie tylko bardzo wybredny, ale jest to jeden z najbardziej irytująco czasochłonnych fragmentów kodu do przetestowania.


5
Testowanie jest nie tylko irytujące, ale irytujący kod może się nie udać. Zastanów się: co wolisz, jakiś problem, gdy system działa i działa normalnie, lub nie jest w stanie nawet uruchomić systemu? Program ładujący jest zdecydowanie jednym z elementów oprogramowania, które najbardziej odczuwam w związku z tym, że nie dotykam, chyba że jest to konieczne.
CVn

Powyższy komentarz @ MichaelKjörling powinien znaleźć się w odpowiedzi. Przejście na nowy moduł ładujący jest bardzo ryzykowne. Distro-twórcy chcą, aby ich użytkownicy mieli dobre wrażenia, ale ponadto chcą, aby każdy pojedynczy potencjalny nowy użytkownik miał bezbłędne wrażenia za pierwszym razem. Przykro mi, że nazwałem dystrybucję „dystrybucją”, ale w połączeniu z twórcami wydawało się to w porządku.
Johan

@Johan msw może swobodnie edytować ten punkt odpowiedzi, nie mam nic przeciwko. (Nie wystarczy sama odpowiedź, IMO.) Zarówno Tobu, jak i goldlilocks również dotykają tej kwestii.
CVn

3

Dystrybutorzy mają ograniczone zasoby i nie może być żadnych innych przyczyn. Może być dość prosty i bezpieczny, ale bez względu na to , co będzie wymagało więcej prac konserwacyjnych, ponieważ opcja grub musi zostać zachowana, nawet jeśli dotyczy to systemów innych niż UEFI.

Jestem pewien, że każdy ma listę funkcji i opcji, które chcieliby, aby dystrybucje przyjęły (dam ci kilka stron, lol) i bez wątpienia wiele z nich byłoby „całkowicie łatwe, bez kłopotów, szczerze mówiąc. .. ”. Jednak nie ma nieskończonej liczby osobogodzin na ich wdrożenie. W obliczu takich decyzji („Czy wkładamy pracę w tę funkcję, a niektóre inne?”) Podstawowe pytania powinny brzmieć:

  • Czy to konieczne? (Odpowiedź brzmi: nie).
  • Ile osób skorzysta i ile? (IMO: kilka i niewiele)
  • Czy istnieje rozsądna alternatywa, dzięki której użytkownik może dostosować się do własnych potrzeb bez robienia czegokolwiek? (Najwyraźniej jest.)

Powodem, dla którego ludzie w ogóle korzystają z dystrybucji, jest to, że wszyscy podlegają ograniczeniom zasobów (w przeciwnym razie po prostu zatrudnij drużynę, kup im trochę miejsca i sprzętu, i każ im robić wszystko dokładnie tak, jak chcesz). Tak więc rzeczywistość jest taka, że ​​dystrybucje odzwierciedlają ogólne potrzeby ich użytkowników.

To powiedziawszy, myślę, że z czasem zostanie to przyjęte jako opcja, i głosowałem za tym pytaniem.


2

Celowanie w bootloadery UEFI oprócz gruba skomplikowałoby kontrolę jakości i wsparcie. Dystrybucje są ukierunkowane raczej na GRUB niż na specyfikację UEFI, ponieważ GRUB jest wolnym oprogramowaniem, można go zhakować, jest bardziej elastyczny i wysokiej jakości. Nadal można uzyskać rozruch z czystego UEFI, postępując zgodnie z samouczkiem i instalując partycję UEFI na /boot, ponieważ jeśli to zrobisz, utrzymanie będzie na tobie.


Twoje twierdzenie o jakości jest dyskusyjne, ale myślę, że cel, dla którego jest ukierunkowany, nie ma z tym nic wspólnego. mają już tysiące wierszy źle napisanego skryptu powłoki do obsługi go, więc dlaczego mieliby chcieć 20 dobrych?
mikeserv

1

Prawdziwy problem polega na tym, że ludzie nie rozumieją, jak to działa. Na przykład w swoim pytaniu wspominasz, że trzy skrypty to wszystko, co jest konieczne, a większość odpowiedzi tutaj dotyczy wszystkich / wszelkich dodatkowych czynności konserwacyjnych, które byłyby wymagane, aby działało - ale prawda jest taka, że ​​nie potrzebujesz tych skryptów lub jakakolwiek dodatkowa praca.

Wszystko, czego potrzebujesz, to powiązanie zamontowania ESP - lub gdziekolwiek chcesz zachować jądro - /bootco możesz zrobić za pomocą jednej linii /etc/fstab. Zrób to, a wszystkie obecne skrypty aktualizacji jądra będą po prostu nadal działać.

Mój `/ etc / fstab 'wygląda następująco:

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
#

Warto tu jednak wspomnieć o ustawieniach specyficznych dla producenta. UEFI wyraźnie nie nie podać interfejs do menu startowego. To jest do zgarnięcia i nie będzie spójne między maszynami. To denerwujące, ale prawdziwe.

I tak, podczas gdy moduł ładujący taki jak grubtylko wymaga więcej pracy, aplikacja menu - taka jak rEFInd - wyrównuje różnice i upraszcza wszystko.


1
Nie rozumiem, jak to może działać. Zauważ, że nazwy plików jądra i initramfs obejmują wersję. Jeśli nie ma żadnych skryptów, uruchomisz stare jądro po zainstalowaniu nowego. Lub inaczej:: Jak zmienić domyślne jądro, aby wskazywało na nowe? (Moje skrypty używają efobootmgrdo aktualizacji kolejności rozruchu i zmiany domyślnego jądra).
Marco,

@Marco - cóż, domyślną ścieżką rozruchową jest \EFI\BOOT\BOOTX64.efii dlatego można ją nazwać. UEFI nie może (według specyfikacji) obsługiwać argumentów do jądra w pierwszej kolejności - tak więc obraz initramfs / jądro musi być w tym przypadku powiązany. ale nie wiem, co masz na myśli nazywanie wersji - myślę, że robią to tylko debianie i i tak uważam to za nieproduktywne. konwencjonalna nazwa twojego jądra to vmlinuz. W każdym razie właściwym sposobem na to jest menedżer rozruchu, a nie moduł ładujący . Użyj aplikacji EFI, która znajduje jądro i przekazuje swoją nazwę do EFI w celu uruchomienia - tak jak robi to rEFInd.
mikeserv

Używam Debiana, a nazwa jądra to np. vmlinuz-4.2.0-1-amd64Które zostawiam bez zmian, a następnie używam, efibootmgraby dodać to do listy startowej i ustawić jako domyślną. Widzę, że nazewnictwo jądra BOOTX64.efimoże być rozwiązaniem. Ale w jakikolwiek sposób musiałbym mieć skrypt, aby to zrobić, a ponadto nie pozwala to łatwo zachować wielu jąder, jeśli wszystkie mają takie same nazwy.
Marco,

@Marco - nie potrzebujesz całego osobnego skryptu - twój menedżer pakietów - prawdopodobnie, prawdopodobnie - uruchomi jakiś skrypt, kiedy jądro zostanie zainstalowane w celu zbudowania initramfs. prawdopodobnie robi tam setki rzeczy, aby wypracować już nazwę twojego jądra, ale tylko jedna dodatkowa linia zmieni nazwę na cokolwiek zechcesz. i możesz z łatwością zachować tyle jąder, ile chcesz, jeśli zachowasz drzewo rozruchowe . rEFInd obsługuje go, ustawiając domyślny obraz rozruchowy jako ostatnio zmodyfikowany obraz jądra w swoich ścieżkach wyszukiwania.
mikeserv

Modyfikowanie skryptów podstawowych instalowanych przez menedżera pakietów jest złym pomysłem. Mogą być aktualizowane, co z kolei usuwa twoje zmiany, aw tym konkretnym przypadku może nawet doprowadzić do awarii systemu. Istnieją katalogi dla skryptów użytkownika, które są wywoływane po instalacji jądra / initramfs i które mają być używane do takiego właśnie celu. BTW: Sugerujesz edytowanie skryptów w swoich komentarzach. Jednak w swojej odpowiedzi stwierdzasz „nie potrzebujesz tych skryptów ani dodatkowej pracy”, co nie jest prawdą (przynajmniej w przypadku Debiana).
Marco,

0

Łączą UEFI i GRUB jako tymczasowe rozwiązanie implementacyjne.

Gdy wsparcie UEFI i towarzyszące mu problemy (np. Bezpieczny rozruch) zostaną rozwiązane, coraz więcej dystrybucji będzie z niego korzystać bezpośrednio. Tymczasem jest to wciąż bardzo nowe: Google Trends pokazuje raczej ograniczone przyjęcie: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios i cmpt = q

Inni wspominali o potencjalnych pułapkach przejścia na rozwiązanie czysto UEFI i / lub jednoczesną obsługę zarówno systemów nieużywających UEFI, jak i czystego UEFI. Jądro UEFI może działać w systemie innym niż UEFY, ale narzędzia do aktualizacji jądra muszą aktualizować albo menu GRUB LUB menu rozruchowe UEFI LUB oba itd. Itd.

W rzeczywistości chodzi o kontrolę jakości, jak wspomniano: ważne problemy z tym kodem mają duży wpływ: gdy komputer nie uruchomi nowych użytkowników, tj. Potencjalna konwersja Linuksa, porzuci go jako śmieci i wróci do czegoś „bezpiecznego”.

Ale, jak powiedziałem, gdy technologia będzie coraz częściej stosowana, stanie się standardem.


Mam nadzieję, że nie - ale to głównie dlatego, że mam poważne obawy dotyczące trybów Lockdown UEFI i „obietnicę” Microsoftu, aby upewnić się, że zawsze będzie podpisany obraz dla systemu Linux do użytku ...
Shadur

0

Dodatkowy kod jest niezbędny do obejścia błędów oprogramowania układowego

Gdy nie łączy łańcuchowego gruba, dystrybucja polega bardziej na oprogramowaniu układowym, aby poprawnie uruchomić. Ponieważ każde oprogramowanie będzie miało problemy, oprogramowanie układowe również jest na to podatne. Teraz dystrybucje Linuksa będą musiały napisać, aby obejść te błędy oprogramowania.

Przykład prawdziwego życia. Płyta główna Asrock H81 pro BTC P1.80 umożliwia tworzenie pozycji menu rozruchu za pomocą efibootmgr. Można utworzyć wiele pozycji menu rozruchu, a kolejność rozruchu można zmienić za pomocą efibootmgr --bootorder XXXX,YYYY,ZZZZlub tymczasową opcję następnego rozruchu można ustawić za pomocą efibootmgr --bootnext XXXX. Obie te komendy zwracają dane wyjściowe, co daje pogląd, że kolejność rozruchu uległa zmianie lub na przykład uruchomi się następny rozruch BootNext: XXXX. Jednak przy ponownym uruchomieniu uparte oprogramowanie wewnętrzne ignoruje nowo wybraną opcję rozruchu i restartuje się do poprzedniej BootCurrent:wartości. Trwałej zmiany kolejności rozruchu można dokonać tylko za pomocą narzędzia do konfiguracji oprogramowania układowego. A niestała zmiana nie jest w ogóle dostępna.


-2

Myślę, że jeśli rozruch jest obsługiwany tylko przez EFI i usuniemy program ładujący, będzie to trudne zarówno dla dostawcy sprzętu, jak i twórców systemów operacyjnych. Sprzedawca HW będzie miał więcej jąder do przetestowania, podczas gdy dla firm tworzących system operacyjny będzie tak, jakby ich jądro było ładowane przez inną FW.

Co więcej, w przypadku bezpośredniego uruchamiania jądra z EFI, gdzie w stosie zmieści się bezpieczny rozruch? W bieżącym scenariuszu, gdy kontrola przejdzie do bootloadera systemu operacyjnego, bootloader sprawdza, czy jądro jest poprawnie podpisane, czy nie. W przypadku, gdy ładujemy jądro bezpośrednio z EFI, myślę, że spowoduje to bałagan tylko wtedy, gdy cały stos zostanie zakłócony. Tylko opinia z tego, co rozumiem.


to głupie. Powodem, dla którego bootloader sprawdza klucz, jest to, że UEFI tego nie robi. ładowanie łańcucha jest zbędne, aby zabezpieczyć rozruch podpisanego jądra, wystarczy sprawdzić klucz w oprogramowaniu układowym - sposób, w jaki powinien on działać.
mikeserv
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.