Gentoo Logo

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.



Drukuj

Zaktualizowano 16 lutego 2009

Oryginalna wersja tego dokumentu została po raz ostatni zaktualizowana 15 listopada 2011. Jeśli chcesz pomóc w aktualizacji tego dokumentu do najnowszej wersji, skontaktuj się z Łukaszem Damentko, koordynatorem polskiego projektu tłumaczeń dokumentacji Gentoo.

Podsumowanie: Przewodnik ten pokazuje jak dokonać migracji z baselayout-1 na baselayout-2 i OpenRC.

Doug Goldstein
Autor

Joshua Saddler
Autor

Roy Marples
Ofiarodawca

Michał Laszuk
Tłumacz

Donate to support our development efforts.

Copyright 2001-2012 Gentoo Foundation, Inc. Questions, Comments? Contact us.