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

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:

• Jak odtworzyć partycję rozruchową EFI?

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.

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.

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.

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.

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.

Łą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.

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.

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.