Blog

Jedną z najbardziej charakterystycznych cech Enterprise Linuxa jest jego jądro, a raczej jego dosyć specyficzna wersja. Wykonując komendę „uname -r” jesteśmy z reguły w stanie od razu (nie patrząc nawet na tag dystrybucji) powiedzieć, że mamy do czynienia z rodziną EL. W przypadku wersji 6 dostaniemy wynik „2.6.32-*”, a w przypadku wersji 7 „3.10.0-*”. Natomiast w wersji beta wydania 8 mamy kernel „4.18”. W przypadku gdy wersja jądra to już 5.0 czy nawet 5.1 dla RC istnieje pewna bariera psychologiczna odnośnie „świeżości” naszego systemu. W tym artykule postaram się przybliżyć sposób wersjonowania projektu Kernela Linuxa oraz pokażę, jak w prosty sposób zainstalować naprawdę świeżą wersję jądra.

Zgodnie z oficjalną stroną projektu jądra Linuxa (https://www.kernel.org/category/releases.html), możemy wyróżnić jego następujące wersje (tekst poniżej jest w dużej mierze luźnym tłumaczeniem):

• Prepatch – nazywana także RC. Są to jądra przedwydaniowe. Są one skierowane głównie do deweloperów oraz entuzjastów. Zawierają wszystkie nowości, które muszą być przetestowane, zanim zostaną uznane za stabilne. Niestety do dziś lwia część procesu testowania jądra opiera się na użytkownikach. Jądra tego typu są utrzymywane i wydawane przez Linusa Torvaldsa.
• Mainline. Świeże jądra, utrzymywane przez Linusa Torvaldsa. Jest to drzewo, na którym opiera się rozwój jądra, cechują się jednak większą stabilnością od RC. Nowe wydanie następuje z reguły co 2-3 miesiące.
• Stable. Po każdym wydaniu jądra Mainline jest ono uznawane za stabilne. Wszystkie naprawy błędów (bugfix) odbywają się przez backport (reimplementację funkcjonalności/kodu z nowszych wersji do starszych) z jądra Mainline. Stabilna wersja jądra jest utrzymywana przez wybranego maintainera (opiekuna).
• Longterm. Są to wybrane wersje jądra, które również mają własnego opiekuna. Backportują one, co bardzo istotne, wybrane bugfixy z nowszych wersji. Ich czas życia to maksymalnie do około 6 lat.

Osobiście ze względu na doświadczenie w pracy i pewne skrzywienie zawodowe, chciałbym dodać do tej systematyki następujące wersje:

• Distribution Longterm. Jądra tego typu są utrzymywane przez dostawcę systemu operacyjnego. Są też jedną z najbardziej charakterystycznych cech systemów Enterprise. Jądra takie cechują się najwyższą dojrzałością i stabilnością. Posiadają one jednak mankamenty wynikające z konieczności „backportowania”, czyli reimplementacji kodu z nowszych wersji do starszych.
• Distribution Specific. Wszystkie inne wersje utrzymywane przez społeczność związaną z konkretnym projektem.

Zalety i wady nowszych wersji jądra

Wszystkie wersje (drzewa wersji) mają swoje zalety i wady. Z reguły można je opisać przeciwstawnie, gdzie po jednej stronie mamy stabilniejsze wersje a po drugiej bardziej rozwojowe wersje jądra Linuxa. Oznaczenie „N” w nawiasie oznacza nowszą wersję, natomiast „S” – starszą. Proste zestawienie wybranych zalet/wad ze względu na wersje:

• Wsparcie nowego sprzętu (N) / Brak wsparcia lub konieczność czekania na dodanie wsparcia dla nowszego sprzętu (S). Należy tutaj wziąć pewną poprawkę na rynek Enterprise, gdzie sterowniki do sprzętu potrafią być tworzone tylko dla wersji stabilnej i to na dodatek tylko dla wybranych dystrybucji. Sprzęt konsumencki z reguły jest lepiej wspierany przez nowsze wersje jądra.
• Szybkie poprawki bezpieczeństwa (N) / Czasami dłuższy czas oczekiwania na poprawkę bezpieczeństwa (S). Nie musi to wynikać z samego Kernela. Może się bowiem zdarzyć, iż backport będzie dotyczył również narzędzi służących do kompilacji. Czas oczekiwania z reguły wydłuża się ze względu na wiek i coraz większe różnice między wersjami.
• Implementacja bugfixów (N) / Implementacja wybranych bugfixów (S).
• Nowe funkcjonalności (N) / Brak niektórych nowych funkcjonalności (S). Mogą być one backportowane, ale nie muszą. Bardzo dużo zależy od firmy/projektu dostarczającej kernel.
• Możliwy brak stabilności (N) / Wysoka stabilność (S). Tutaj należy podkreślić, iż oprócz stabilności samego jądra mamy także do czynienia z innymi metrykami jak choćby stabilność binarnego interfejsu jądra (kABI).
• Wsparcie ze strony społeczności (N) / Wsparcie ze strony producenta (S).

Instalacja kernel-ml w Enterprise Linuxie w wersji 7

Przed instalacją kernela w wersji ML, chciałbym zaznaczyć, iż nie należy go instalować na systemach objętych wsparciem oraz na systemach krytycznych.
Pakiety, które nie pochodzą z oficjalnego źródła dystrybucyjnego, a szczególnie tak egzotyczne, powodują z reguły utratę wsparcia.
Instalację jądra ML mogę polecić z czystym sumieniem tylko osobom, które wiedzą, z czym wiąże się potencjalne ryzyko.

Najprostszym sposobem instalacji jądra z drzewa ML jest wykorzystanie pakietów kompilowanych przez społeczność repozytoriów ELRepo. Pakiety te mają podobne ustawienia kompilacji jak jądra tworzone dla Enterprise Linuxa.

By zainstalować repozytorium ELRepo, należy na samym początku zainstalować pakiet zawierający klucze oraz plik repozytorium.

sudo yum install https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

Następnie w pliku /etc/yum.repos.d/elrepo.repo należy włączyć repozytorium zawierające nowsze wersje pakietu jądra.

[elrepo-kernel]
name=ELRepo.org Community Enterprise Linux Kernel Repository - el7 
baseurl=http://elrepo.org/linux/kernel/el7/$basearch/
        http://mirrors.coreix.net/elrepo/kernel/el7/$basearch/
        http://mirror.rackspace.com/elrepo/kernel/el7/$basearch/
        http://repos.lax-noc.com/elrepo/kernel/el7/$basearch/
        http://mirror.ventraip.net.au/elrepo/kernel/el7/$basearch/
mirrorlist=http://mirrors.elrepo.org/mirrors-elrepo-kernel.el7
enabled=0 
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-elrepo.org
protect=0

Zmiana jest trywialna, gdyż wystarczy zmienić enabled=0 na enabled=1.

Po takim zabiegu mamy dostęp do dwóch pakietów zawierających nowsze wersje jądra systemu GNU/Linux. Pierwszym z nich jest kernel-ml, który polecam. Drugim jest kernel-lt. Odpowiada on za najnowszy kernel będący Longterm, w tym wypadku w wersji 4.4. Tabelka z tego typu jądrami jest dostępna w linku przytoczonym w pierwszym akapicie.

Po skończonej konfiguracji i ze świadomością konsekwencji można wreszcie wykonać:

sudo yum install -y kernel-ml

Zmiana ustawień grub

Po zainstalowaniu kernela w wersji ML domyślną jego wersją uruchamianą przy starcie wciąż będzie ta pochodząca z pakietu kernel. By to zmienić, należy edytować plik /etc/sysconfig/kernel zgodnie z przedstawionym diffem.

--- /etc/sysconfig/kernel.back	2019-03-28 12:27:21.356837751 +0100
+++ /etc/sysconfig/kernel	2019-03-28 12:25:00.369392851 +0100
@@ -3,4 +3,4 @@
 UPDATEDEFAULT=yes
 
 # DEFAULTKERNEL specifies the default kernel package type
-DEFAULTKERNEL=kernel
+DEFAULTKERNEL=kernel-ml

Najprostszym sposobem wymuszenia zmiany ustawień GRUB jest reinstalacja pakietu kernel-ml przy pomocy yuma.

sudo yum reinstall -y kernel-ml

Dzięki takiemu podejściu nie musimy sami generować konfiguracji GRUB. Sposób ten dotyczy zarówno EFI, jak i starego (legacy) trybu ładowania jądra.

Zakończenie

W ramach autorskiej uczciwości chciałbym jeszcze raz podkreślić, iż instalacja jądra w wersji ML z reguły oznacza brak/utratę wsparcia ze strony producenta systemu. Konieczne jest także wyłączenie mechanizmu Secure Boot lub dodanie odpowiednich kluczy.

Na sam koniec chciałbym pokazać, jak w prosty sposób sprawdzić, jak bardzo różne jest kABI obydwóch wersji jądra:

rpm -q --provides kernel | grep "0x" > kABI
rpm -q --provides kernel-ml | grep "0x" > kABI-ml
diff -y kABI kABI-ml