Home Dokumentacje Migracja na Baselayout-2 i OpenRC (Gentoo)
10 | 12 | 2019
Migracja na Baselayout-2 i OpenRC (Gentoo)

Migracja na Baselayout-2 i OpenRC

Spis treści:

1. Tło

Czym jest baselayout?

Baselayout dostarcza podstawowego zestawu plików takich jak /etc/hosts, niezbędnych do prawidłowej pracy wszystkich systemów. Dostarcza również podstawowego układu systemu plików używanego przez Gentoo (na przykład katalogi /etc, /var, /usr, /home).

Czym jest OpenRC?

OpenRC jest bazującym na zależnościach systemem uruchomieniowym, który może działać z dowolnym init dostarczanym przez system, zazwyczaj /sbin/init. Nie jest on jednak zastępstwem dla /sbin/init. Standardowy init używany w Gentoo Linux to sys-apps/sysvinit, natomiast Gentoo/FreeBSD korzysta z init FreeBSD zawartego w pakiecie sys-freebsd/freebsd-sbin.

Po co więc migrować?

Pierwotnie system uruchomieniowy Gentoo był wbudowany w baselayout 1 i w całości napisany w bashu. Doprowadziło to do kilku ograniczeń. Na przykład, pewne wywołania systemowe muszą być dostępne podczas uruchamiania systemu, a to wymagało dodania wywołań opartych na języku C. Wywołania te były dowiązane statycznie i stale zmuszały system uruchomieniowy do nadawania wspomnianego dostępu.

Dodatkowo, gdy Gentoo rozszerzyło się na inne platformy, takie jak Gentoo/FreeBSD czy Gentoo Embedded stało się niemożliwym, by wymagać systemu uruchomieniowego bazującego na bashu. Doprowadziło to do powstania baselayout 2, który napisany został w C i wymaga jedynie powłoki zgodnej z POSIX. Podczas rozwoju baselayout 2 ustalono, że najlepiej będzie, jeśli baselayout po prostu dostarczy podstawowych plików i układu systemu plików dla Gentoo, a system uruchomieniowy zostanie przeniesiony do osobnego pakietu. Tak powstał OpenRC.

OpenRC jest rozwijane głównie przez Roya Marples'a i wspiera wszystkie istniejące obecnie wariacje Gentoo (na przykład Gentoo Linux Gentoo/FreeBSD, Gentoo Embedded i Gentoo Vserver) oraz inne platformy takie jak FreeBSD i NetBSD.

2. Migracja na OpenRC

Migracja do OpenRC jest całkiem prosta; będzie ona umieszczona jako część zwyczajowych aktualizacji systemu dokonywanych za pomocą menadżera pakietów. Właściwie najważniejszy krok ma miejsce już po zainstalowaniu nowych pakietów >=sys-apps/baselayout-2 i sys-apps/openrc. Przed ponownym uruchomieniem komputera, krytycznym krokiem jest wykonanie dispatch-conf i upewnienie się, że pliki w /etc zostały zaktualizowane. Pominięcie tego może doprowadzić do nieuruchamiającego się systemu i wymagać będzie użycia Gentoo LiveCD, w celu przeprowadzenia poniższych kroków, które naprawią niedziałający system.

Gdy już wszystkie pliki konfiguracyjne zostaną zaktualizowane, zostanie jeszcze kilka rzeczy, które koniecznie należy sprawdzić przed ponownym uruchomieniem komputera.

/etc/conf.d/rc

Plik /etc/conf.d/rc jest przestarzały i wszystkie ustawienia w nim zapisane muszą zostać przeniesione do odpowiadających ustawień w /etc/rc.conf. Należy przeczytać oba pliki /etc/rc.conf i /etc/conf.d/rc, a następnie przenieść ustawienia. Po wykonaniu migracji należy skasować plik /etc/conf.d/rc.

Moduły jądra

Zazwyczaj gdy istniała potrzeba załadowania pewnych modułów automatycznie podczas uruchamiania systemu, były one umieszczone w /etc/modules.autoload.d/kernel-2.6 razem z wybranymi parametrami. W baselayout-2 plik ten nie jest już używany. Zamiast niego wszystkie dodatkowe moduły ładowane podczas startu i ich parametry, niezależnie od wersji jądra, zostały umieszczone w pliku /etc/conf.d/modules.

Przykładem starego stylu konfiguracji będzie:

Listing 2.1: /etc/modules.autoload.d/kernel-2.6

ivtv
cx88_dvb video_br=2

Konwersja powyższego skutkować będzie poniższym:

Listing 2.2: /etc/conf.d/modules

# Moduły ładowane automatycznie podczas uruchamiania
modules_2_6="ivtv cx88_dvb"
# Parametry modułów
module_cx88_dvb_args_2_6="video_br=2"

W powyższych przykładach moduły i ich parametry będą działać jedynie na jądrach z serii 2.6. Nowy sposób konfiguracji pozwala na łatwą kontrolę nad modułami i ich parametrami bazującą na wersji jądra.

Bardziej szczegółowy przykład:

Listing 2.3: Szczegółowy przykład /etc/conf.d/modules

# Always load ochi1394 and ieee1394, no matter the kernel
version
modules="ohci1394 ieee1394"
# Only load tun and usbserial for 2.6.x series kernels
modules_2_6="tun usbserial"
# Only load cx88_dvb for 2.6.23 kernels
modules_2_6_23="cx88_dvb"
# Only load ivtv for 2.6.23-gentoo-r5
modules_2_6_23_gentoo_r5="ivtv"

# For 2.6.23-gentoo-r5, pass video_br=2 to cx88_dvb
module_cx88_dvb_args_2_6_23_gentoo_r5="video_br=2"
# For 2.6.x series kernels, always pass vendor and product
module_usbserial_args_2_6="vendor=0x1410 product=0x2110"
# Always pass debug to ieee1394
module_ieee1394_args="debug"

Uwaga: Należy zwrócić uwagę na różnicę pomiędzy module_ a modules_.

Poziom uruchomieniowy boot

Poziom uruchomieniowy boot dokonuje kilku ważnych kroków dla każdego komputera. Sprawdza na przykład, czy główny system plików jest zamontowany w trybie zapisu i odczytu, czy partycje zostały sprawdzone i nie zawierają błędów, czy punkty montowania są dostępne i czy system plików /proc został uruchomiony podczas startu.

W OpenRC usługi zarządzające woluminami urządzeń blokowych nie są teraz uruchamiane standardowo podczas startu systemu. Zaliczają się do nich usługi takie jak: lvm, raid, swap, device-mapper (dm), dm-crypt, evms i podobne. Należy upewnić się, że skrypty init odpowiednie dla powyższych usług umieszczone są w poziomie uruchomieniowym boot. W przeciwnym wypadku, możliwym jest, że system nie będzie w stanie się uruchomić!

Podczas gdy ebuild OpenRC będzie usiłował dokonać migracji ustawień automatycznie, konieczne będzie sprawdzenie czy wszystko przebiegło prawidłowo:

Listing 2.4: Sprawdzenie wszystkich usług poziomu uruchomieniowego boot

# ls -l /etc/runlevels/boot/

Jeżeli wynik powyższego polecenia nie pokaże root, procfs, mtab, swap i fsck, należy wykonać poniższe polecenia, aby dodać je do poziomu uruchomieniowego boot:

Listing 2.5: Dodawanie krytycznych usług do poziomu uruchomieniowego boot

# rc-update add root boot
# rc-update add procfs boot
# rc-update add mtab boot
# rc-update add fsck boot
# rc-update add swap boot

W przypadku gdy użytkownik korzysta z mdraid bądź lvm, a nie widnieją one na powyższej liście, konieczne będzie wykonanie poniższych poleceń, by dodać te usługi do poziomu uruchomieniowego boot:

Listing 2.6: Dodawanie brakujących usług zarządzania woluminami do poziomu uruchomieniowego boot

# rc-update add raid boot
# rc-update add lvm boot

Udev

OpenRC nie uruchamia udev domyślnie, obecnie musi on być dodany na poziom uruchomieniowy sysinit. Ebuild OpenRC powinien wykryć czy udev był wcześniej używany i doda go do sysinit automatycznie. Dla pewności jednak warto sprawdzić czy to się naprawdę wydarzyło i czy udev tam się naprawdę znajduje.

Listing 2.7: Sprawdzanie czy udev jest uruchamiany

# ls -l /etc/runlevels/sysinit
lrwxrwxrwx 1 root root 14 2009-01-29 08:00 /etc/runlevels/sysinit/udev -> \
/etc/init.d/udev

Jeśli udev nie ma na liście, dodajemy go tam:

Listing 2.8: Dodawanie udev na poziom uruchomieniowy sysinit

# rc-update add udev sysinit

Sieć

Z powodu rozdzielenia baselayout i OpenRC na dwa różne pakiety, skrypt startowy net.eth0 może zostać usunięty podczas procesu aktualizacji. Aby zastąpić ten skrypt init należy wykonać poniższe:

Listing 2.9: Ponowne tworzenie brakującego skryptu net.eth0

# cd /etc/init.d
# ln -s net.lo net.eth0

W przypadku, gdy brakuje jakichkolwiek innych skryptów startowych sieci, należy dodać je ponownie, zwyczajnie zastępując eth0 nazwą brakującego urządzenia sieciowego.

Także, /etc/conf.d/net nie korzysta już ze składni znanej z basha. Należy więc przyjrzeć się plikowi /usr/share/doc/openrc/net.example, w którym podano instrukcje dotyczące konfiguracji. Konwersja powinna być stosunkowo nieskomplikowana. Dla przykładu konfiguracja statycznie przypisanego IP powinna zostać zmieniona jak niżej:

Listing 2.10: Stary styl konfiguracji /etc/conf.d/net

config_eth0=( "192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255" )
routes_eth0=( "default via 192.168.1.100" )

Listing 2.11: Nowy styl konfiguracji /etc/conf.d/net

config_eth0="192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255"
routes_eth0="default via 192.168.1.100"

Zegar

Ustawienia zegara zmieniły nazwę z /etc/conf.d/clock na natywne narzędzie systemowe regulujące zegar. Oznacza to, że w Linuksie będzie to /etc/conf.d/hwclock, natomiast we FreeBSD będzie to /etc/conf.d/adjkerntz. Nazwa skryptu init umieszczonego w /etc/init.d/ także została zmieniona na odpowiednią dla danego systemu. Należy się więc upewnić, że jest umieszczona w odpowiednim poziomie uruchomieniowym.

Dodatkowo, zmienna TIMEZONE nie jest już obecna w wymienionym pliku. Można ją teraz znaleźć w pliku /etc/timezone. Jeśli plik ten nie istnieje, oczywiście należy go utworzyć umieszczając w nim swoją strefę czasową. Należy więc jeszcze raz przyjrzeć się obydwu plikom aby być pewnym ich poprawności.

Właściwa wartość dla tego pliku jest odpowiadająca strefie czasowej użytkownika ścieżka z /usr/share/zoneinfo. Na przykład, osoba mieszkająca na wschodnim wybrzeżu Stanów Zjednoczonych Ameryki powinna użyć ustawienia:

Listing 2.12: /etc/timezone

America/New_York

XSESSION

Zmienna XSESSION nie jest już obecna w /etc/rc.conf. W zamian zmienną tę możemy ustawić na użytkownika w pliku ~/.bashrc (lub odpowiedniku) lub na cały system w katalog /etc/env.d.

Poniżej znajduje się przykład ustawienia zmiennej XSESSION dla całego systemu:

Listing 2.13: Ustawianie zmiennej XSESSION

# echo 'XSESSION="Xfce4"' > /etc/env.d/90xsession

Ważne: Po utworzeniu pliku w /etc/env.d koniecznym jest wykonanie env-update. Aby nowe ustawienia odniosły skutek należy wylogować się i zalogować ponownie. W przypadku użycia pliku ~/.bashrc, aby nowe ustawienia zostały zastosowane należy wydać polecenie source ~/.bashrc.

EDITOR i PAGER

Zmienna EDITOR nie jest już obecna w /etc/rc.conf. Obydwie zmienne EDITOR i PAGER ustawione są domyślnie w /etc/profile. Namawia się użytkowników do ustawienia ich samodzielnie wedle potrzeb w pliku ~/.bashrc (lub odpowiedniku) bądź utworzenia pliku /etc/env.d/99editor i ustawienie tam zmiennych.

Ważne: Po utworzeniu pliku w /etc/env.d, koniecznym jest, aby wykonać env-update. Aby nowe ustawienia odniosły skutek należy wylogować się i zalogować ponownie. W przypadku gdy zmienna została ustawiona w ~/.bashrc, można wczytać nowe ustawienia wykonując source ~/.bashrc.

Logowanie uruchomienia systemu

Poprzednio, aby logować proces uruchamiania systemu musieliśmy użyć pakietu app-admin/showconsole. Obecnie jednak, OpenRC posiada wewnętrzny system logowania. Nie musimy więc stosować sztuczek jakich używa showconsole. Aby logować informacje z uruchamiania systemu wystarczy ustawić odpowiednią zmienną w pliku /etc/rc.conf. Logi pojawią się w pliku /var/log/rc.log.

Listing 2.14: Uaktywnienia logowania w pliku /etc/rc.conf

rc_logger="YES"

Zakończenie

W momencie gdy wszystkie pliki konfiguracyjne i skrypty rozruchowe zostaną zaktualizowane, ostatnią rzeczą którą należy zrobić jest ponowne uruchomienie komputera. Jest to konieczne, ponieważ informacje o stanie systemu nie są zachowywane podczas aktualizacji. Należy więc dostarczyć ich poprzez ponowne uruchomienie.

 

 
Linki sponsorowane

W celu realizacji usług i funkcji na witrynach internetowych ZUI "ELPRO" stosujemy pliki cookies. Korzystanie z witryny bez zmiany ustawień dotyczących plików cookies oznacza, że będą one zapisywane w urządzeniu wyświetlającym stronę internetową. Więcej szczegółów w Polityce plików cookies.

Akceptuję pliki cookies z tej witryny.