[OpenBSD]

[Spis treści] [Sekcja 4 - Instalacja OpenBSD] [Sekcja 6 - Sieć]

5 - Tworzenie systemu ze źródeł


Spis treści



5.1 - Wątki OpenBSD

OpenBSD występuje w trzech "wątkach": Graficznie, rozwój tych wątków wygląda tak:
       ,------o-----------o----X                    3.9 Stable
       |      .           .
       |      .    ,------o---------o----X          4.0 Stable
       |      .    |      .         .
       |      .    |      .    ,----o----------o--> 4.1 Stable
       |      .    |      .    |    .          .
       |      .    |      .    |    .    ,-----o--> 4.2 Stable
       |      .    |      .    |    .    |     .
       |      .    |      .    |    .    |     .
 -->3.9Rel----->4.0Rel----->4.1Rel----->4.2Rel----> Current 

          Time --->

-Current to stan w którym prowadzone są aktywnie prace, i ewentualnie, przeradza się w następną wersję -release OpenBSD. Co sześć miesięcy, kiedy wydawana jest nowa wersja OpenBSD, -current jest oznaczane, i staje się -release: zamrożonym punktem w historii drzewa źródłowego. Każda wersja -release nie jest nigdy zmieniana: one właśnie są dostępne na CD i serwerach FTP.

Wersja -stable oparta jest na -release, i jest odgałęzieniem głównej ścieżki rozwoju OpenBSD. Gdy ważne poprawki są wprowadzane do wersji -current, są włączane do odgałęzienia -stable, z tego powodu -stable nazywana jest "gałęzią paczkową". W powyższej ilustacji, pionowe wykropkowane linie oznaczają uaktualnienia, które są włączane do gałęzi -stable. W powyższym przykładzie można zauważyć, że gałąź 3.9-stable kończy się wraz z ukazaniem się 4.1-release, oraz 4.0-stable kończy się w momencie utworzenia 4.2-release -- starsze wersje są standardowo wspierane aż do dwóch wydań wstecz. Wspieranie starszych wersji jest czynnością wymagającą wysiłku i czasu, i dlatego w czasie, kiedy moglibyśmy usprawniać starsze wydania, wolimy skupić się na rozwijaniu nowych funkcji systemu. Gałąź -stable jest, z założenia, bardzo prosta do utworzenia z -release tej samej wersji (np., przejście z 4.2-release do 4.2-stable).

Gałąź -stable składa się z -release i łatek, które są umieszczane na stronie z poprawkami. Działanie -stable jest takie samo jak działanie -release na którym bazuje. Jeśli istnieje potrzeba zmiany podręcznika man, to prawdopodobnie nie zostanie to uwzględnione w -stable. Innymi słowy, wsparcie dla nowego urządzenia lub nowa funkcjonalność NIE zostanie dodane do -stable.

Warte uwagi jest, że nazwa "-stable" w zamierzeniu nie implikuje niestabilności wersji -current. Co więcej, -current zmienia się i rozwija, tymczasem działania i API na -stable nie są zamierzone na zmiany, zatem nie powinno być potrzebne ponowne uczenie się systemu lub zmiany plików konfiguracyjnych, a także nie powinieneś mieć problemów z dodawaniem dodatkowych aplikacji do swojego systemu.

W rzeczywistości, jako że naszym zamierzeniem jest ciągle ulepszać OpenBSD, celem jest osiągnięcie -current jako bardziej niezadownego, bardziej bezpiecznego i oczywiście posiadającego większą funkcjonalności niż -stable. Mówiąc bardziej dosadnie, "najlepszą" wersją OpenBSD jest -current.

Ostrzeżenie: -current jest "uciekającym celem". Zmienia się z minuty na minutę, i może ulec wielu zmianom zanim ukaże się w postaci kodu źródłowego. Chociaż developerzy ciężko pracują by mieć pewność że system zawsze się skompiluje oraz że nie zawiera żadnych poważnych błędów, jest zupełnie możliwą sytuacja w której pobranie źródeł -current nie zakończy się poprawną kompilacją, tymczasem pięć minut później wszystko będzie zupełnie w porządku. Są także oznaczone dni i zmiany w głównym systemie, gdy developerzy korzystają z jednorazowych narzędzi, co oznacza że uaktualnienia ze źródeł nie będą możliwe. Jeżeli nie jesteś gotowy by się na to godzić, trzymaj się z dala od -current.

Większość użytkowników powinna korzystać z -stable lub -release. Jak już zaznaczyliśmy, wielu ludzi korzysta z -current **on production systems**. Jest to bardzo ważne, że jest ktoś kto to robi, aby zidentyfikować błędy i przetestować nowe funkcje. Jednak jeśli nie wiesz, jak prawidłowo opisać, zdiagnozować i poradzić sobie z problemem, nie mów sobie (ani komukolwiek innemu), że "pomagasz w projekcie" poprzez uruchamianie wersji -current. "To nie działa!" nie jest użytecznym raportem o błędach.. "Ostatnie zmiany w sterowniku pciide przerwały ich kompatybilność z moim interfejsem IDE opartym na układzie Slug. Przesyłam dmesg działającego i uszkodzonego systemu..." może być użytecznym raportem.

Zdarzają się przypadki, w których "zwykli" użytkownicy chcą być na bieżąco i korzystają z -current. Najczęstszą przyczyną jest przypadek, kiedy użytkownik posiada urządzenie, które nie jest wspierane przez -release (tak więc również niewspierane przez -stable), lub chce korzystać z nowych udogodnień wersji -current. W tym przypadku, wybór może być pomiędzy -current lub nie korzystaniem z urządzenia, i -current będzie mniejszym złem. Jednakże użytkownik nie powinien wówczas oczekiwać pomocy od twórców systemu.

Snapshoty

Pomiędzy kolejnymi oficjalnymi wydaniami OpenBSD, tworzone są snapshoty -- chwilowe wersje obrazujące dokonujące się przemiany -- dostępne na FTP. Jak sama nazwa wskazuje, są to skompilowane wersje kodu, który znajdował się w drzewie źródeł danej platformy sprzętowej, w momencie skopiowania. Należy pamiętać, że dla niektórych platform, czas pomiędzy kolejnymi "snapshotami" może wynosić wiele DNI, nim zostanie udostępniony. Niestety nikt nie obiecuje, że "snapshoty" są całowicie funkcjonalne, a nawet że można je zainstalować. Często stworzenie "snapshota" jest spowodowane zmianą, która wymaga testowania. Niektóre platformy mają tworzone "snapshoty" prawie codziennie, inne o wiele rzadziej. Jeśli pragniesz korzystać z -current, najnowszy "snapshot" będzie zwykle tym, czego potrzebujesz, dlatego instalacja " snapshota" jest zwykle dobrym punktem startu przed próbą samodzielnej kompilacji -current ze źródeł.

Czasem pada pytanie, czy jest jakaś możliwość otrzymania kopii źródeł kodu, który został użyty do stworzenia "snapshota". Odpowiedź brzmi nie. Po pierwsze, nie ma z tego żadnej znaczącej korzyści. Po drugie, "snapshoty" są tworzone kiedy jest ochota, czas pozwala i są dostępne niezbędne zasoby. Na szybkich platformach możliwe jest tworzenie kilku "snapshotów" dziennie. Na wolniejszych, może to zająć tydzień lub dłużej, aby go stworzyć. Wykonywanie etykiet (ang. tag) bądź zakładek w kodzie źródłowym drzewa dla każdego "snapshota" byłoby dość niepraktyczne. Po trzecie, snapshoty często zawierają eksperymentalny kod który nie został jeszcze dodany do drzewa.

Upgrade vs. Update

Często natrafiamy na odniesienia do uaktualnienie ("upgrade") lub aktualizacja ("update") instalacji OpenBSD. Nawet jeśli słowa te mają zbliżone znaczenia to w przypadku OpenBSD są używane do określenia zupełnie różnych rzeczy.

Uaktualnienie (upgrade) jest procesem instalacji nowej wersji OpenBSD, z nowymi funkcjonalnościami. Przykładowo, przejście z wersji v4.1 do wersji v4.2, lub przejście z migawki z 12 czerwca do migawki z 20 czerwca. W procesie uaktualnienia (upgrade) należy zwrócić uwagę na dokumenty Podążanie za -current lub Przewodnik uaktualnienia (przy zmianie wydania) po to by wykonać wszystkie zmiany konieczne do uruchomienia uaktualnionej wersji OpenBSD.
Aktualizacja (update) jest procesem wprowadzania do systemu poprawek (łatek) w celu poprawienia jego działania BEZ zmiany podstawowych funkcjonalności systemu (przyp. tłum. - nie są dodawane np. nowe sterowniki,) lub binarnej kompatybilności. Proces ten wykonywany jest zazwyczaj zgodnie z procesem wprowadzania łatek lub z procesem "podążania" za -stable. Gdy "aktualizujesz" system, przechodzi on z -release do -stable (lub "patched" -release) z zachowaniem wersji wydania, przykładowo z 4.2-release do 4.2-stable. Później możesz zaktualizować system do nowszej wersji -stable tego samego wydania. Proces aktualizacji jest zazwyczaj mało bolesny ponieważ nie zmieniają się pliki konfiguracyjne, np. te w katalogu /etc.

Zatem, możesz zainstalować system z płyty CD (np. wydanie 4.1-release), następnie zaktualizować go kilka razy do 4.1-stable, później uaktualnić go do 4.2-release z płyty CD, aktualizując go dalej kilkukrotnie i ponownie uaktualniając do następnego wydania.

Utrzymywanie zgodności pomiędzy elementami systemu

Ważne jest zrozumienie, iż OpenBSD jest systemem operacyjnym, który powinien być traktowany jako całość, a nie jako jądro wraz z dołączoną grupą narzędzi. Musisz być pewny, że jądro, "userland" (dołączone narzędzia i pliki) i drzewo oprogramowania "ports" są ze sobą zgodne, bo jeśli nie mogą wystąpić nieoczekiwane kłopoty. Mówiąc innymi słowy (ponieważ ludzie popełniają błędy), nie możesz korzystać z najświeższego drzewa portów na systemie sprzed miesiąca, lub przekompilować jądro ze źródeł -current i spodziewać się, że będzie ono funkcjonować z oprogramowaniem pochodzącym z -release. Tak, to oznacza, że musisz uaktualniać cały swój system, jeśli chcesz korzystać z nowego programu, który został właśnie dzisiaj dodany do drzewa portów. Przepraszamy, powtórzymy to jeszcze raz, OpenBSD ma ograniczone zasoby.

Warto również pamiętać, że uaktualnienie jest możliwe tylko w jednym kierunku: ze starszej do nowszej wersji, czyli ze -stable do -current. Nie możesz korzystać z 4.2-current (lub snapshota), następnie stwierdzając, że jesteś narażony na zbyt duży stres, chcesz wykonać krok w tył do 4.2-stable. Jestes sam jeśli wybierzesz jakąkolwiek inną ścieżkę, niż ta która jest wspierana, i nie spodziewaj się, że ktokolwiek z twórców OpenBSD będzie Ci pomagał podczas przywracania uszkodzonego systemu.

Chodzi o to, aby się poważnie zastanowił, zanim zaczniesz korzystać z -current.

5.2 - Dlaczego potrzebuję systemu zbudowanego ze źródeł?

Właściwie, jest bardzo prawdopodobne że nie potrzebujesz.

Kilka powodów dlaczego NIE budować ze źródeł:

Kilka powodów dlaczego możesz chcieć lub potrzebować uaktualnienia systemu ze źródeł:

Zespół OpenBSD bardzo regularnie umieszcza nowe snapshoty oparte na kodzie -current dla wszystkich platform. To jest właściwie wszystko czego możesz potrzebować do uruchomienia -current.

Najczęstszym powodem do budowy systemu ze źródeł jest chęć podążania za gałęzią -stable, gdzie budowa ze źródeł jest jedyną dostępną opcją.

5.3 - Budowa OpenBSD ze źródeł

5.3.1 - Wprowadzenie

Budowanie OpenBSD ze źródeł pociąga za sobą kilka kroków: Jest także kilka dodatkowych kroków jakie niektórzy użytkownicy mogą wykonać, w zależności od tego czy chcą posiadać środowisko X:

5.3.2 - Instalacja lub uaktualnienie do najnowszej dostępnej wersji binarnej.

Pierwszym krokiem do zbudowania systemu ze źródeł jest upewnienie się że zainstalowane binaria są najnowszymi dostępnymi. Użyj poniższej tabeli by zorientować się gdzie się znajdujesz, gdzie chcesz się znaleźć, oraz z jakimi binariami powinieneś rozpocząć:

Jesteś w: Cel Uaktualnij binaria do: później ...
Old -release New release Newest release Gotowe!
-release -stable Newest release Fetch & build -stable
Old -stable -stable Newest release Fetch & build -stable
-release -current Latest Snapshot (optional) Fetch & build -current
Old -current -current Latest Snapshot (optional) Fetch & build -current

Jest zalecane, żeby instalować binaria korzystając z opcji "Upgrade" w medium instalacyjnym. Jeżeli jest to niemożliwe, możesz także rozpakować binaria jak to opisano w tutaj. Bez względu na to będziesz musiał przejść cały proces uaktualnienia, włączając w to tworzenie użytkowników lub inne zmiany konieczne w katalogu /etc.

5.3.3 - Pobieranie właściwego kodu źródłowego

Źródła OpenBSD są zarządzane przy wykorzystaniu systemu kontroli wersji CVS, tak więc pobieranie kopii żądanych źródeł na twoją lokalną maszynę odbywa się przy pomocy cvs(1). Możesz to wykonać korzystając z serwera AnonCVS (maszyny przechowującej publicznie dostępną kopię całego repozytorium CVS wykorzystywanego w projekcie OpenBSD), lub z lokalnego repozytorium zarządzanego przez ciebie przy pomocy programów CVSup, lub CVSync, dostępnych w systemie pakietów. CVSup może być także wykorzystane w opcji "checkout", nie będzie to jednak objęte w tej dokumentacji. Jeżeli posiadasz kilka maszyn na których chcesz zarządzać drzewem źródeł, możesz stwierdzić ze lepiej jest posiadać lokalne repozytorium CVS, tworzone i zarządzane przy pomocy CVSup oraz CVSync.

W sytuacji gdy zdecydujesz się na skorzystanie z serwera AnonCVS, musisz sprawdzić ("checkout") drzewo źródeł, a następnie zarządzić uaktualnienie ("update") by wciągnąć uaktualnione pliki do twojego lokalnego drzewa.

Polecenie CVS(1) posiada wiele opcji, a niektóre z nich są wymagane do sprawdzenia i uaktualnienia przydatnego drzewa. Inne polecenia mogą spowodować uszkodzenie drzewa. Ważne jest by zrozumieć i podążać za wskazówkami w tym miejscu.

Podążanie za -current

W tym przypadku założymy, że używamy publicznego serwera AnonCVS, anoncvs@anoncvs.example.org:/cvs. Założymy także ze korzystasz z powłoki sh(1), (jeżeli korzystasz z innej powłoki będziesz musiał dostosować niektóre z z podanych poleceń).

Do pobrania całego drzewa źródeł CVS -current, możesz użyć:

# cd /usr
# export CVSROOT=anoncvs@anoncvs.example.org:/cvs
# cvs -d$CVSROOT checkout -P src

Gdy już posiadasz drzewo, możesz je później uaktualnić:

# cd /usr/src
# export CVSROOT=anoncvs@anoncvs.example.org:/cvs
# cvs -d$CVSROOT up -Pd
Podążanie za -Stable
Jeżeli chcesz korzystać z alternatywnej "gałęzi" drzewa, takiej jak gałąź -stable, użyjesz opcji "-r" łącznie z checkout:
# cd /usr
# export CVSROOT=anoncvs@anoncvs.example.org:/cvs
# cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P src
Spowoduje to wciągnięcie plików źródłowych z gałęzi OPENBSD_4_2, znanej także jako "Patch branch" lub "-stable". Będziesz mógł uaktualnić kod w podobny sposób:
# cd /usr/src
# export CVSROOT=anoncvs@anoncvs.example.org:/cvs
# cvs -d$CVSROOT up -rOPENBSD_4_2 -Pd
Właściwie CVS jest wystarczająco miły by oznaczyć "etykietą" w sprawdzanym systemie plików, tak że nie będziesz musiał pamiętać o części "-rOPENBSD_4_2", zapamięta to aż do momentu gdy wyraźnie wyczyścisz tą flagę lub ustawisz inną korzystając z opcji "-A" w "update". Jakkolwiek, prawdopodobnie lepiej jest podać więcej informacji do linii poleceń CVS, niż mniej.

Jak dotychczas posiadasz tylko drzewo "src", będziesz musiał wykonać podobne kroki dla "xenocara" oraz "portów". Jako że wszystkie części OpenBSD muszą być utrzymywane w zgodności, wszystkie drzewa z których korzystasz powinny być sprawdzane i uaktualniane w tym samym czasie. Możesz połączyć sprawdzanie w jedną linię (pokazano dla -stable):

  # export CVSROOT=anoncvs@anoncvs.example.org:/cvs
  # cd /usr
  # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P src ports
  # cd /usr/src
  # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P xenocara
Jakkolwiek, uaktualnienia muszą być wykonywane katalog-po-katalogu.

W tym momencie, nie ważne czy podążasz za -stable czy -current powinieneś mieć użyteczne drzewo źródeł. Bądź bardzo uważny z tym jakie drzewo pobierasz - dość łatwo można spróbować skompilować -current myśląc ze to -stable.

Wstępne ładowanie drzewa źródeł: src.tar.gz, sys.tar.gz

Chociaż możesz pobrać całe drzewo źródeł z serwera AnonCVS, często będziesz mógł zaoszczędzić czas oraz łącze poprzez wstępne załadowanie drzewa źródeł z płyt CD OpenBSD lub z serwera FTP. W szczególności jest to prawdziwe jeżeli korzystasz z wersji -stable, ponieważ zmiany występujące pomiędzy tą wersją a wersją -release na której jest oparta obejmują niewiele plików.

Aby rozpakować drzewo źródeł z CD do /usr/src (zakładając że CD jest podmontowane w /mnt):

  # cd /usr/src; tar xzf /mnt/src.tar.gz
  # tar xzf /mnt/xenocara.tar.gz
  # cd /usr; tar xzf /mnt/ports.tar.gz
Pliki źródeł do pobrania z serwerów FTP są podzielone na dwie części by ograniczyć czas potrzebny do ich pobrania dla osób chcących pracować tylko z częścią drzewa źródeł. Pliki te to sys.tar.gz, zawierający pliki wykorzystywane do budowy jądra, oraz src.tar.gz zawierające aplikacje "przestrzeni użytkownika", z wyjątkiem drzewa portów oraz źródeł X11. Generalnie jednak będziesz potrzebował obu tych plików. Zakładając, że pobrane pliki src.tar.gz i sys.tar.gz znajdują się w /usr:
  # cd /usr/src
  # tar xzf ../sys.tar.gz
  # tar xzf ../src.tar.gz
  # tar xzf ../xenocara.tar.gz
  # cd /usr
  # tar xzf ports.tar.gz

Nie wszyscy mogą planować rozpakowywanie wszystkich paczek plików, ale jako że system musi być aktualny, generalnie będziesz potrzebował wszystkich części drzewa źródeł.

Znane sztuczki z CVS

Jak wskazywaliśmy wcześniej, niektóre opcje są niezbędne do pobrania poprawnego drzewa /src w OpenBSD. Opcja "P" powyżej jest jedną z nich: "obcina" (usuwa) katalogi które są puste. W ciągu lat, katalogi są tworzone i kasowane w drzewie źródeł OpenBSD, czasem nazwy starych katalogów są na bieżąco wykorzystywane jako nazwy plików. Bez opcji "-P", drzewo źródeł które przed chwilą pobrałeś NIE skompiluje się pomyślnie.

Podobnie jest z opcją "-d" w poleceniu "update" -- tworzy nowe katalogi, które mogły zostać dodane do drzewa od czasu twojego inicjującego sprawdzenia. Aby uzyskać poprawną aktualizację, musisz użyć opcji -Pd.

Doświadczeni użytkownicy mogą się zastanawiać dlaczego CVSROOT zostało podane i wykorzystane w przykładzie, chociaż cvs(1) zarejestruje lokalizację serwera CVS w sprawdzanym drzewie. Jest to prawdą, jakkolwiek wielokrotnie zdarzało się, że niektórzy potrzebowali nadpisać domyślny serwer anoncvs, wiele osób zaleca by zawsze wyraźnie sprecyzować nazwę repozytorium. Nie zmienia to także niczego w sytuacji gdy zmienna środowiskowa CVSROOT może być użyta bezpośrednio przez cvs(1), jest używane tylko jeżeli nic innego jej nie nadpisuje (np. cvs(1) zwróciłby błąd bez tego), tymczasem podanie jej w poleceniu cvs(1) nadpisuje wszystkie pozostałe wartości.

Często użytecznym jest korzystanie z .cvsrc w twoim katalogu domowym i określenie w nim niektórych z tych opcji. Przykładowy plik .cvsrc:

$ more ~/.cvsrc
cvs -q -danoncvs@anoncvs.example.org:/cvs
diff -up
update -Pd
checkout -P
Powinno to spowodować by cvs(1) korzystał z serwera anoncvs@anoncvs.example.org:/cvs, likwidując zazwyczaj niepotrzebne wyjście ("-q" oznacza "quiet" - "cicho") dla wszystkich operacji, polecenie "cvs up" domyślnie korzysta z opcji -Pd, natomiast polecenie "cvs diff" zapewnia "unified diffs" poprzez "-u", a polecenie "cvs checkout" wykorzystuje opcję "-P". Pomimo iż jest to poręczne, jeżeli zapomnisz tego pliku, lub będziesz starał się uruchomić te polecenia na maszynie bez tego pliku, będziesz miał problemy.

Ponieważ drzewa źródeł zawierają dużą ilość przeważnie małych plików, wykorzystanie soft updates dla partycjina której znajdują się drzewa źródeł powinno dać znaczący wzrost wydajności

5.3.4 - Kompilacja jądra

Załóżmy że chcesz skompilować standardowe jądro (GENERIC lub GENERIC.MP). Normalnie jest to to co chcesz zrobić. Nie rozważaj kompilacji standardowego jądra jeżeli nie opanowałeś standartowego procesu kompilacji.

Jest oczywiste, że jądro jest NAJBARDZIEJ zależną od urządzeń częścią systemu. Źródła jądra znajdują się w katalogu /usr/src/sys. Niektóre części kodu jądra OpenBSD są wspólne dla wszystkich platform, inne są bardzo charakterystyczne dla danego procesora lub architektury. Jeżeli zajrzysz do katalogu /usr/src/sys/arch/, może zobaczyć rzeczy które wyglądają niego zagmatwane -- na przykład znajdują się tam katalogi mac68k, m68k oraz mvme68k. W tym przypadku systemy mvme68k oraz mac68k, wykorzystują ten sam procesor, lecz komputery oparte są bardzo różne, i wymagają zupełnie różnych jąder (znacznie więcej niż tylko procesor wchodzi do konstrukcji komputera). Jednakże, fragmenty jądra są wspólne, te fragmenty znajdują się w katalogu m68k. Jeżeli po prostu kompilujesz jądro, katalogi bazowe dla architektur, jak np. m68k nie powinny cię martwić, będziesz pracował wyłącznie ze "złożoną architekturą" taką jak mvme68k.

Jądra są kompilowane w oparciu o pliki konfiguracyjne , które znajdują się w katalogu /usr/src/sys/arch/<your platform>/conf Budowa jądra polega na wykorzystaniu programu config(8) do stworzenia i wypełnienia katalogu kompilacji, co zakończy się w /usr/src/sys/arch/<your platform>/compile/<KernelName>. W naszym przykładzie zakładamy że korzystasz z platformy i386:

# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean && make depend && make
[...lots of output...]
# make install
Zastąp "i386" w pierwszej linii nazwą twojej architektury. Polecenie machine(1) powie ci jaka jest nazwa twojej aktualnej platformy, zatem oczywistym uogólnieniem będzie użycie polecenia "cd /usr/src/sys/arch/`machine`/conf" zamiast pierwszej linii.

W tym punkcie, zrestartuj komputer by uruchomić to nowe jądro. Zwróć uwagę, że nowe jądro powinno działać zanim przejdziesz do następnego kroku, chociaż jeżeli podążałeś za radą powyżej dotyczącą uaktualnienia do najbardziej świeżego dostępnego "snapshota", może to nie być aż tak istotne. Czasem jednak, zmieniasz API, i stare jądro nie będzie w stanie uruchamiać nowych aplikacji, ale nowe jądro będzie generalnie je wspierać.

Zmiana w opisanym wyżej procesie: drzewo źródeł tylko do odczyty

Czasem możesz chcieć pewność że twój katalog /usr/src/sys pozostanie niezmieniony. Możesz to uzyskać postępując jak poniżej:
$ cd /somewhere
$ cp /usr/src/sys/arch/i386/conf/GENERIC .
$ config -s /usr/src/sys -b . GENERIC
$ make clean && make depend && make
... lots of output ...
Zauważ, że możesz skompilować jądro nie będąc rootem, ale musisz nim być by je zainstalować.

5.3.5 - Kompilacja przestrzeni użytkownika

Jest to charakterystyczny proces wykorzystywany w OpenBSD. Metody wykorzystywane w innych systemach operacyjnych z którymi możesz być zaznajomiony, najprawdopodobniej nie zadziałają w OpenBSD, i rozśmieszy cię jeżeli spytasz dlaczego.

5.4 - Kompilacja wersji -release

Czym jest "wydanie" (ang. release) i dlaczego mógłbym chcieć zrobić własne?

Wydanie jest kompletnym zestawem plików które mogą być wykorzystane do zainstalowania OpenBSD na innym komputerze. Jeżeli posiadasz tylko jeden komputer z działającym OpenBSD, naprawdę nie masz najmniejszego powodu by tworzyć wydanie, jako że w powyższym procesie kompilacji zrobiłeś wszystko czego potrzebujesz. Jako przykładowy proces tworzenia wydania może służyć proces kompilacji -stable na szybkiej maszynie, a następnie wykonanie wydania które będzie instalowane na pozostałych maszynach w twoim biurze.

Proces tworzenia wydania wykorzystuje binarki utworzone w katalogu /usr/obj w procesie opisanym powyżej, musisz zatem najpierw pomyślnie zakończyć tworzenie, i nic nie może naruszać katalogu /usr/obj. Moment w którym to może być problematyczne jest w sytuacji gdy korzystasz z dysku pamięci jako /usr/obj dla uzyskania nieco lepszej wydajności podczas procesu budowania, nie powinieneś restartować komputera pomiędzy krokami "build" a "release".

Tworzenie wydania wymaga dwóch katalogów roboczych, które będziemy nazywać DESTDIR i RELEASEDIR. Wszystkie pliki które są częścią "czystej" instalacji OpenBSD będą kopiowane do ich właściwego miejsca przeznaczenia w katalogu DESTDIR. Następnie zostaną (s)tarowane(1) i umieszczone w RELEASEDIR. Ostatecznie RELEASEDIR będzie zawierał kompletne wydanie OpenBSD. Podczas tworzenia wykorzystywany jest także katalog /mnt, zatem nie powinien być wykorzystywany do niczego innego podczas budowy. W celach przykładowych wykorzystamy DESTDIR jako /usr/dest oraz /usr/rel jako RELEASEDIR.

Proces tworzenia wydania wymaga dwóch narzędzi które nie są dostępne w podstawowym OpenBSD, crunch oraz crunchgen(1), wykorzystywane do stworzenia jednego wykonywalnego pliku tworzonego z kilku osobnych binariów. Nazwa tego pojedyńczego pliku wykonywalnego jest wywoływana przez ustalenie który komponent binarny jest wykonywany. W ten sposób szereg osobnych plików programów jest upychany do ramdysku jądra który znajduje się na dyskietkach startowych lub innych startowych mediach. Narzędzia te muszą być skompilowane przez rozpoczęciem procesu tworzenia Wystarczy by zbudowano je raz, jednak ludzie którzy często zapominają o tym kroku, a te programy kompilują się szybko, niektórzy wolą budować crunch oraz crunchgen za każdym razem jako część skryptów które wykorzystują do tworzenia wydania.

Musisz posiadać uprawnienia root'a by stworzyć wydanie.

Tworzenie wydania

Najpierw, jeżeli nie było to wcześniej wykonywane na danej maszynie zbuduj crunch oraz crunchgen:
# cd /usr/src/distrib/crunch && make obj depend all install
Następnie definiujemy zmienne środowiskowe DESTDIR i RELEASEDIR:
# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
Teraz czyścimy DESTDIR i tworzymy katalogi jeżeli jest to konieczne:
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
RELEASEDIR normalnie nie musi byc pusty przed rozpoczęciem tworzenia wydania, jednakże, jeżeli nastąpiły jakieś zmiany w plikach wydania lub ich nazwach, stare pliki mogą pozostać zaśmiecając miejsce. Możesz zatem chcieć wyczyścić ten katalog przez rozpoczęciem.

Przystępujemy do tworzenia samego wydania:

# cd /usr/src/etc
# make release
Po tym jak wydanie jest gotowe, dobrym pomysłem jest je sprawdzić by mieć pewność że pliki tar pasują do tego co jest w DESTDIR. Wyjście z tego kroku powinno być naprawdę minimalne.
# cd /usr/src/distrib/sets
# sh checkflist
Zakończyłeś i sprawdziłeś pliki wydania w katalogu RELEASEDIR. Pliki te mogą być wykorzystane do instalacji lub uaktualnienia OpenBSD na innych maszynach.

Miarodajne instrukcje na temat tworzenia wydania znajdują się w release(8).

Uwaga: Jeżeli zamierzasz rozpowszechniać pliki wynikowe przez HTTP do wykorzystania przez skrypty aktualizacji, będziesz potrzebował dodać plik "index.txt", zawierającą listę wszystkich plików z twojego nowo utworzonego wydania.

# /bin/ls -1 >index.txt

5.5 - Budowa środowiska X (4.2 Xenocara)

Uwaga: poniższe instrukcje dotyczą OpenBSD 4.2 i późniejszych. Jeżeli chcesz budować środowisko X dla 4.1 lub wcześniejszych (powinieneś jednak wykonać upgrade!), możesz poszukać wcześniejszych instrukcji w systemie cvsweb.

Począwszy od X.org v7, X-y zmieniły się w "system modularny", rozdzielając drzewo x.org na więcej niż trzysta mniej-lub-bardziej niezależnych pakietów.

Aby uprościć życie użytkownikom OpenBSD utworzony został system "meta-kompilacji" nazywany Xenocara. System tem "konwertuje" X-y ponownie w jedno duże drzewo by następnie kompilować je w jednym procesie. Jako dodatkowy bonus, ten proces jest znacznie bardziej podobny do procesu budowy pozostałej części OpenBSD, niż w poprzednich wersjach.

Oficjalny zestaw instrukcji do kompilacji X-ów znajduje sie na twoim komputrze w pliku /usr/src/xenocara/README oraz w release(8).

Pobieranie kodu źródłowego

"Zazwyczaj" drzewo źródeł xenocara znajduje się w /usr/src/xenocara, oraz w module xenocara w CVS. Zatem proces pobierania źródeł wygląda tak:
  $ cd /usr/src
  $ cvs -qdanoncvs@anoncvs.example.org:/cvs checkout -P xenocara

Budowa Xenocara

Do budowy standardowego drzewa xenocara w OpenBSD nie są wymagane żadne dodatkowe narzędzia.
  # cd /usr/src/xenocara
  # make bootstrap
  # make obj
  # make build
Jeżeli chcesz wykonać kilka modyfikacji kodu źródłowego, prawdopodobnie będziesz musiał dodać kilka packages. Szczegóły opisane są w pliku /usr/src/xenocara/README.

Tworzenie wydania

Jest podobne to tworzenia systemu głównego wydania. Po pomyślnym zbudowaniu X, definiujesz DESTDIR oraz RELEASEDIR, w tym samym celu co poprzednio. RELEASEDIR może być tym samym katalogiem co RELEASEDIR w głównym systemie, natomiast DESTDIR, będzie wyczyszczony i przebudowany w tym procesie. Jeżeli wykonasz to ostrożnie, nie będzie problemów, jednak użycie osobnego DESTDIR może być "bezpieczniejsze".

W ramach przykładu użyjemy DESTDIR oraz RELEASEDIR odpowiednio w /usr/dest i /usr/rel. Musisz to wykonać po zakończeniu powyżej opisanego procesu.

  # export DESTDIR=/usr/dest
  # export RELEASEDIR=/usr/rel
  # test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \
       rm -rf ${DESTDIR}- &
  # mkdir -p ${DESTDIR} ${RELEASEDIR}
  # make release
Gdy proces ten się zakończy, otrzymasz zestawy plików wydania w katalogu $RELEASEDIR.

5.6 - Dlaczego potrzebuję niestandardowego jądra?

Wiele wskazuje na to, że aktualnie nie potrzebujesz go.

Niestandardowe jądro to takie jądro, które jest tworzone na bazie pliku konfiguracyjnego innego, niż standardowy GENERIC. Niestandardowe jądro może bazować na kodzie wydań -release, -stable (stabilnym) lub -current (bieżącym), podobnie jak jądro GENERIC. Podczas gdy kompilacja własnego jądra GENERIC jest wspierana przez zespół OpenBSD, kompilacja własnego, niestandradowego jądra nie jest.

Standardowa konfiguracja jądra OpenBSD (GENERIC) jest stworzona tak, aby była użyteczna dla większości osób. Prawdopodobieństwo tego, że uda Ci się usprawnić swój system poprzez modyfikację jądra jest o wiele mniejsze niż to, że uszkodzisz swój system. Jest wiele osób, które twierdzą, że musisz tworzyć swoje jądro w celu osiągnięcia optymalnej wydajności, ale to nie jest prawda w OpenBSD. Jedynie najbardziej zaawansowani i znający się na rzeczy użytkownicy, uruchamiający bardzo wymagające programy muszą martwić się o niestandardowe jądro lub nawet cały system.

Kilka powodów dla których możesz chcieć lub potrzebujesz stworzyć niestandardowe jądro:

Oto kilka powodów dla których nie powinieneś posiadać własnego jądra systemu:

Usunięcie sterowników urządzeń może przyspieszyć proces uruchamiania się systemu, jednak może skomplikować przywracanie systemu, podczas problemów ze sprzętem, i bardzo często proces ten jest wykonywany błędnie. Usunięcie sterowników urządzeń nie sprawi tego, żeby system uruchamiał się znacząco szybciej, choć samo jądro jest mniejsze. Usunięcie procesów debugowania i sprawdzania błędów może spowodować odczuwalny wzrost wydajności, ale uniemożliwi rozwiązanie problemów z systemem jeśli coś pójdzie źle.

Przypominamy ponownie, twórcy systemu zwykle ignorują raporty dotyczące specyficznych jąder systemów, chyba że problem powtarza się również przy jądrze GENERIC. Pamiętaj, ostrzegaliśmy.

5.7 - Budowa standardowego jądra

Zakładamy, że przeczytałeś powyższy tekst, i naprawdę bawi cię ból. Zakładamy także, że posiadasz cel który nie może być osiągnięty ani przez Boot time configuration (UKC>) ani config(8)ing a GENERIC kernel. Jeżeli oba powyższe nie są prawdziwe, powinieneś przyczepić się do GENERIC. Naprawdę.

Generowanie jądra OpenBSD jest kontrolowana przez pliki konfiguracyjne, które domyślnie są zlokalizowane w katalogu/usr/src/sys/arch/<arch>/conf/. Wszystkie architektury posiadają plik GENERIC, który jest wykorzystywany do generowania standardowego jądra OpenBSD dla tej platformy. Mogą także znajdować się tam inne pliki konfiguracyjne, które są używane do tworzenia jąder o konkretnym przeznaczeniu, na przykład, dla systemów o małej ilości pamięci RAM, bezdyskowych stacji roboczych, itp.

Pliki konfiguracyjne są przetwarzane przez program config(8), który tworzy i zapełnia katalog kompilacyjny - ../compile (w przypadku typowej instalacji), czyli w katalogu /usr/src/sys/arch/<arch>/compile/. config(8) tworzy także Makefile, oraz inne pliki niezbędne do pomyślnego zbudowania jądra.

Opcje konfiguracji jądra umożliwiają umieszczenie w jądrze pewnych funkcji rozszerzających funkcjonalność. Pozwalają na wybór elementów, które będą wspierane (a które nie) -- np. dla urządzeń, których nie ma w systemie. Jest mnóstwo opcji, które pomogą dostosować jądro do własnych potrzeb. W tym dokumencie przedstawimy tylko niektóre z nich, te najczęściej używane. Sprawdź stronę podręcznika options(4), aby uzyskać bardziej szczegółową listę, a ponieważ zmienia się ona od czasu do czasu, powinieneś upewnić się, że jest przeglądasz podręcznik z tej samej wersji, której jądro budujesz. Możesz także przeglądnąć przykład plików konfiguracyjnych dla Twojej architektury.

Nie umieszczaj żadnej opcji w swoim jądrze, chyba że masz powód żeby to zrobić! Nie edytuj pliku konfiguracyjnego jądra GENERIC!! Najbardziej przetestowany jest zawsze zestaw opcji jądra GENERIC. Zwykle jest to kombinacja opcji w /usr/src/sys/arch/<arch>/conf/GENERIC i /usr/src/sys/conf/GENERIC dostarczonych przez drużynę OpenBSD (tzn. NIE edytowane). Zgłaszanie problemu na dostrajanym jądrze prawie zawsze spowoduje, że zostaniesz poproszony, aby spróbować zreprodukować problem na jądrze GENERIC. Nie wszystkie opcje są kompatybilne ze sobą nawzajem, oraz wiele opcji jest wymaganych aby system działał. Nie ma gwarancji, że tylko dlatego, że zdołałeś skompilować dostrojone jądro, będzie ono działać. Nie ma gwarancji, że jądro które daje się konfigurować (config(8)) pozwoli się zbudować.

Specyficzne konfiguracje dla poszczególnych platform:

Gdy przyjrzyjmy się bliżej tym plikom i wtedy zobaczymy na górze taki wpis:

   include "../../../conf/GENERIC"
Co oznacza, że odnosimy się do konfiguracji zawartej w innym pliku konfiguracyjnym. Ten plik zawiera opcje niezależne od platformy sprzętowej. Zatem gdy tworzysz własną konfigurację jądra zobacz także sys/conf/GENERIC.

Wszystkie opcje przedstawione poniżej powinny być umieszczane w pliku konfiguracyjnym jądra w następującym formacie:

option      name
lub
option      name=value
Na przykład, aby wstawić opcje debugowania w jądro, powinieneś dodać poniższą linię:
     option      DEBUG
Opcje w jądrze OpenBSD są tłumaczone na opcje preprocesora kompilatora, dlatego opcja taka jak DEBUG mogłaby być wprowadzona poprzez kompilację z opcją -DDEBUG. Co jest równoznaczne z #define DEBUG w każdym fragmencie jądra.

Czasem możesz chcieć wyłączyć jakąś opcje, która jest już zdefiniowana, zwykle w pliku "src/sys/conf/GENERIC". Mimo, iż mógłbyś zmodyfikować kopie tego pliku, lepszym rozwiązaniem byłoby wykorzystanie wyrażenia rmoption. Na przykład, jeśli naprawdę chciałbyś wyłączyć wewnętrzny debugger jądra (nie polecane!), dodałbyś linię podobną do tej:

   rmoption DDB
w pliku konfiguracyjnym jądra. option DDB jest zdefiniowana w src/sys/conf/GENERIC, lecz powyższa linia rmoption wyłącza ją.

Ponownie, proszę zobacz options(4) w celu uzyskania większej ilości informacji o tych opcjach. Zauważ także, że wiele opcji posiada własne strony man -- zawsze przeczytaj wszystko co jest dostępne o danej opcji przed dodaniem lub usunięciem jej z swojego jądra.

Tworzenie własnego jądra

W tym przypadku zbudujemy jądro które obsługuje wieloportową kartę szeregową na złączu ISA boca(4). Karta ta nie znajduje się w jądrze GENERIC ze względu na konflikty z innymi sterownikami. Innym powszechnym powodem by tworzyć własne jądro jest posiadanie ramy RAID, która jest zbyt duża by posiadać ją w typowym jądrze. Są dwie proste metody by zbudować własne jądro: skopiowanie pliku konfiguracyjnego dla jądra GENERIC i wyedytowanie go, lub stworzenie "nakładającego" pliku "zawierającego" standardowe jądro GENERIC oraz dodatkowe potrzebne opcje niedostępne w GENERIC. W naszym przypadku plik "nakładający" będzie miał postać:
include "arch/i386/conf/GENERIC" 

boca0  at       isa? port 0x100 irq 10     # BOCA 8-port serial cards
pccom* at       boca? slave ?
Dwie linie dotyczące boca(4) zostały skopiowane z zakomentowanych linii w GENERIC, z dostosowanym IRQ według potrzeby. Do zalet korzystania z "nakładającego" pliku należy automatyczne uaktualnianie dowolnych niepowiązanych zmian z dowolnymi innymi uaktualnieniami w kodzie źródłowym. Wadą jest natomiast brak możliwości usuwania urządzeń (chociaż generalnie, jest to i tak zły pomysł).

Innym sposobem na wygenerowanie stosownego jądra jest wykonanie kopii standartowego GENERIC, nadanie jej innej nazwy, a następnie wyedytowanie potrzebnych fragmentów. Wadą takiego rozwiązania są późniejsze uaktualnienia konfiguracji GENERIC, które należy włączyć do twojej kopii, lub będziesz musiał ponownie stworzyć twój plik konfiguracyjny.

W każdym przypadku, po stworzeniu stosownego pliku konfiguracyjnego dla jądra, użyj config(8) aby stworzyć jądro, tak jak to opisano powyżej.

Pełne informacje dotyczące tworzenia własnego jądra znajdziesz na stronie manuala afterboot(8).

5.8 - Konfiguracja jądra podczas startu systemu

Czasem podczas startu systemu może się okazać, że twoje jądro znajduje nowe urządzenia, ale być może na złym przerwaniu (IRQ). I możliwe, że będziesz musiał użyć tego urządzenia właśnie teraz. Abyś nie musiał przekompilowywać jądra możesz użyć konfiguracji jądra OpenBSD podczas startu systemu. Taka operacja rozwiąże twój problem tylko ten jeden raz. Jeśli uruchomisz komputer ponownie, będziesz musiał powtórzyć tą procedurę. Więc jest to tylko tymczasowa naprawa, i powinieneś usunąć ten problem korzystając z config(8). Aby korzystać z konfiguracji podczas startu systemu jądro twojego systemu musi posiadać wpis option BOOT_CONFIG, który jest zawarty w jądrze GENERIC.

Większość informacji w tym temacie może być znalezione w podręczniku boot_config(8).

Aby dostać się do Konfiguracji Jądra przez Użytkownika (ang. UKC = User Kernel Config), podczas startu systemu użyj opcji -c.

boot> boot hd0a:/bsd -c
Lub zastosuj twoją nazwę jądra, które chcesz zastosować. Użycie tego spowoduje pojawienie się znaku zachęty UKC. W tym miejscu możesz wydawać komendy bezpośrednio do jądra określając urządzenia które chcesz zmienić, wyłączyć lub włączyć.

Poniżej znajduje się lista najczęstszych komend UKC.

Gdy już skonfigurujesz swoje jądro, użyj komendy quit lub exit, aby kontynuować start systemu. Następnie powinieneś skorygować na trwałe ustawienia twojego jądra zgodnie z opisem w zawartym w Użycie config(8) do zmiany swojego jądra.

5.9 - Zastosowanie config(8) do zmian w skompilowanym jądrze

Parametry -e i -u polecenia config(8) mogą być wyjątkowo pożyteczne i oszczędzą czas na kompilację jądra. Parametr -e pozwala na wprowadzenie ustawień dla UKC (ang. User Kernel Config) stosowanych przy starcie systemu. Zmiany te będą działały przy następnym uruchomieniu komputera. Natomiast opcja -u pokazuje jakie zmiany zostały dokonane podczas startu systemu, czyli te, wprowadzone po komendzie boot -c w menu UKC.

Poniższy przykład dotyczy wyłączanie urządzeń ep* w jądrze. Przez wzgląd na bezpieczeństwo powinieneś używać opcji -o, która zapisuje zmiany do podanego pliku. Dla przykładu : config -e -o bsd.new /bsd zapisze zmiany do bsd.new. Nasz przykład nie korzysta z opcji -o, dlatego zmiany są po prostu ignorowane, i nie są zapisywane do pliku jądra. Aby uzyskać więcej informacji odnoszących się do błędów i ostrzeżeń przeczytaj stronę podręcznika config(8).

$ sudo config -e /bsd
OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
warning: no output file specified
Enter 'help' for information
ukc> ?
        help                            Command help list
        add         dev                 Add a device
        base        8|10|16             Base on large numbers
        change      devno|dev           Change device
        disable     attr val|devno|dev  Disable device
        enable      attr val|devno|dev  Enable device
        find        devno|dev           Find device
        list                            List configuration
        lines       count               # of lines per page
        show        [attr [val]]        Show attribute
        exit                            Exit, without saving changes
        quit                            Quit, saving current changes
        timezone    [mins [dst]]        Show/change timezone
        nmbclust    [number]            Show/change NMBCLUSTERS
        cachepct    [number]            Show/change BUFCACHEPERCENT
        nkmempg     [number]            Show/change NKMEMPAGES
        shmseg      [number]            Show/change SHMSEG
        shmmaxpgs   [number]            Show/change SHMMAXPGS
ukc> list
  0 audio* at sb0|sb*|gus0|pas0|sp0|ess*|wss0|wss*|ym*|eap*|eso*|sv*|neo*|cmpci*
|clcs*|clct*|auich*|autri*|auvia*|fms*|uaudio*|maestro*|esa*|yds*|emu* flags 0x0
  1 midi* at sb0|sb*|opl*|opl*|opl*|opl*|ym*|mpu*|autri* flags 0x0
  2 nsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
  3 nsphyter* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|
vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep
*|ep*|ep* phy -1 flags 0x0
  4 qsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
  5 inphy** at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
  6 iophy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
  7 eephy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
  8 exphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
[...snip...]
ukc> disable ep
 67 ep0 disabled
 68 ep* disabled
 69 ep* disabled
155 ep0 disabled
156 ep0 disabled
157 ep* disabled
158 ep* disabled
210 ep* disabled
ukc> quit
not forced

W powyższym przykładzie, wszystkie urządzenia ep* są wyłączane w jądrze i nie będą badane. Czasami kiedy użyjesz menu UKC podczas startu, poprzez komendę boot -c, chciałbyś aby te zmiany były zapisane na stałe. Wówczas należy użyć opcji -u. W następnym przykładzie, komputer startuje wykonując menu UKC i urządzenie wi(4) jest wyłączane. Po zmianach dokonanych przy pomocy boot -c, które nie są stałe, należy je zapisać. Ten przykład zapisuje zmiany przeprowadzone komendą boot -c do nowego jądra bsd.new.

$ sudo config -e -u -o bsd.new /bsd
OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
105 wi* disabled
106 wi* disabled
Enter 'help' for information
ukc> quit

5.10 - Otrzymywanie dokładniejszych informacji podczas startu systemu

Otrzymywanie dokładniejszych informacji podczas startu systemu może być bardzo pomocne, gdy próbujesz ustalić powody problemów z bootowaniem. Jeśli nie możesz wystartować systemu z dyskietki i potrzebujesz dokładniejszych informacji, po prostu ponownie uruchom komputer. Kiedy otrzymasz znak zachęty "boot>", wystartuj poprzez komendę boot -c. To doprowadzi Cię do UKC>, gdzie wykonaj:
UKC> verbose
autoconf verbose enabled
UKC> quit

Wówczas otrzymasz bardzo szczegółowe komunikaty dotyczące włączającego się systemu.

5.11 - Najczęstsze problemy, sztuczki i pytania związane z kompilacją i budowaniem jądra

W większości przypadków problemy związane z kompilacją systemu, wynikają z nieprzestrzegania podanych powyżej instrukcji. Zdarzają się czasem istotne problemy z budową wersji -current z najnowszego snapshota, jednak niepowodzenie budowy wersji -release lub -stable, prawie zawsze jest winą użytkownika.

Najczęstszym problemem jest jeden z poniższych:

Jakkolwiek poniżej znajdują się inne dodatkowe problemy na jakie możesz natrafić:

5.11.1 - Tworzenie zatrzymane przez błąd "Signal 11"

Tworzenie OpenBSD i innych programów wprost ze źródeł jest zadaniem, które zmusza sprzęt do większego wysiłku, intensywnie wykorzystuje procesor, dysk i pamięć. Dlatego jeśli masz sprzęt, który nie jest w pełni sprawny, najbardziej prawdopodobnym momentem wystąpienia objawów niepoprawnego działania jest właśnie czas kompilacji. Sygnał błędu nr 11 jest zwykle spowodowany przez problemy ze sprzętem, bardzo często są to uszkodzenia pamięci, ale może być także procesor, płyta główna lub problemy z chłodzeniem. Twój system może być aktualnie bardzo stabilny, jednak nie umożliwi Ci kompilacji programów.

Prawdopodobnie najlepszym rozwiązaniem problemu będzie naprawa bądź wymiana elementów, które powodują problem, gdyż usterki mogą objawiać się także w innych przypadkach w przyszłości. Jeśli posiadasz sprzęt, który chcesz nadal stosować, a nie powoduje innych problemów oprócz tych związanych z kompilacją, po prostu zainstaluj "snapshota" lub wydanie "release".

Aby uzyskać więcej informacji na ten temat, zobacz Sig11 FAQ.

5.11.2 - Instrukcja "make build" przerwana komunikatem "cannot open output file snake: is a directory"

Powyższy komunikat jest spowodowany dwoma oddzielnymi błędami: Ważne jest, aby postępować zgodnie z instrukcjami podczas pobierania i uaktualniania oraz tworzenia własnego drzewa.

5.11.3 - Mój pozbawiony IPv6 system nie działa!

Tak. Prosimy nie rób modyfikacji których konsekwencji nie rozumiesz w twoim podstawowym systemie. Jedna "mała" zmiana w jądrze może mieć bardzo poważne skutki dla całej reszty systemu. Prosimy przeczytaj jeszcze to raz.

5.11.4 - Oops! Zapomniałem utworzyć katalogu /usr/obj!

Wykonując "make build" zanim wykonasz "make obj", skończysz z plikami obiektowymi rozsianymi w twoim katalogu /usr/src. Jest to bardzo źle. Jeżeli chcesz uniknąć ponownego pobierania całego drzewa src, możesz spróbować poniższego zestawu by pozbyć się plików obj:
    # cd /usr/src
    # find . -type l -name obj | xargs rm
    # make cleandir
    # rm -rf /usr/obj/*
    # make obj

5.11.5 - Umieszczenie /usr/obj na jego własnej partycji

Jeżeli często budujesz system, możesz stwierdzić że szybciej będzie jeżeli umieścisz /usr/obj na osobnej partycji. Oczywiście tak jest korzystniej, zazwyczaj szybciej jest:
    # umount /usr/obj
    # newfs YourObjPartition
    # mount /usr/obj
niż "rm -rf /usr/obj/*".

5.11.6 - Jak mogę uniknąć tworzenia części drzewa?

Możesz czasem chcieć nie budować pewnych części drzewa, zazwyczaj dlatego, że zainstalowałeś inne narzędzie zamiast dołączonego z pakietów, lub chcesz mieć "mniejsze" wydanie release z jakiegokolwiek powodu. Rozwiązaniem jest wykorzystanie opcji SKIPDIR w /etc/mk.conf.

Uwaga: istnieje możliwość utworzenia w ten sposób uszkodzonego systemu Skutki używania tej opcji nie są wspierane przez projekt OpenBSD.

5.11.7 - Gdzie mogę się dowiedzieć więcej na temat procesu tworzenia ze źródeł?

Tutaj dostępne są inne materiały:

5.11.8 - Nie widzę żadnej wersji snapshot w FTP. Gdzie się podziały?

Wersje snapshot mogą być usuwane kiedy stają się stare (lub nie jest już istotny) lub zbliża się moment wydania nowej wersji -release.

5.11.9 - Jak mogę załadować nowszą wersję kompilatora (gcc)?

Tak naprawdę powinieneś po prostu zainstalować najnowszy snapshot.

OpenBSD wspiera obecnie dwa kompilatory w drzewie, gcc v3.3.5 stosowana na większości platform, lecz także gcc v.2.95.3 wykorzystywany na kilku platformach na które nie został przeniesiony, lub może nie być nigdy przeniesiony gcc3, ze względu na niedostateczne wsparcie lub słabą wydajność.

Te dwa kompilatory znajdują się w osobnych częściach drzewa:

Ponieważ aktualizacja kompilatora jest trochę jak problem z kurą i jajkiem, zmiany w drzewie kompilatora wymagają nieco dodatkowej uwagi. Musisz zbudować kompilator dwukrotnie -- najpierw musisz wygenerować nowy kod ale działający z kodem wygenerowanym przez stary kompilator, następna budowa stworzy zupełnie nowy kompilator. Generalnie możesz wykonać następującą procedurę:

    Jeżeli twoja platforma korzysta z gcc 2.95.3:
    # rm -r /usr/obj/gnu/egcs/gcc/*
    # cd /usr/src/gnu/egcs/gcc
     - or -
    Jeżeli twoja platforma korzysta z gcc 3.3.5:
    # rm -r /usr/obj/gnu/usr.bin/gcc/*
    # cd /usr/src/gnu/usr.bin/gcc
									         
    Procedura wspólna dla gcc v3.3.5 i gcc v2.95.3
    # make -f Makefile.bsd-wrapper clean
    # make -f Makefile.bsd-wrapper obj
    # make -f Makefile.bsd-wrapper depend
    # make -f Makefile.bsd-wrapper
    # make -f Makefile.bsd-wrapper install
    # make -f Makefile.bsd-wrapper clean
    # make -f Makefile.bsd-wrapper depend
    # make -f Makefile.bsd-wrapper
    # make -f Makefile.bsd-wrapper install

Następnie wykonaj normalne make build.

5.11.10 - Jaki jest najlepszy sposób na aktualizację /etc, /var, oraz /dev?

Zgodnie z ustaloną polityką, oprogramowanie w OpenBSD nie modyfikuje plików w /etc automatycznie. Oznacza to, że zawsze należy do administratora wykonanie niezbędnych modyfikacji w /etc. Aktualizacje nie są wyjątkiem. Chcąc zaktualizować pliki w tych katalogach, najpierw określ jakie zmiany zaszły w plikach podstawowych (dystrybucji), i następnie ręcznie wprowadź te zmiany.

Dla przykładu, by zorientować się jakie się zmieniły ostatnio, wykonaj

    # cd /usr/src/etc
    # ls -lt |more

Chcąc zobaczyć wszystkie zmiany w /etc pomiędzy arbitralnymi wersjami OpenBSD, możesz wykorzystać CVS. Przykładowo, zmiany pomiędzy wersjami 4.1 i 4.2 ujawni polecenie:

    # cd /usr/src/etc
    # cvs diff -u -rOPENBSD_4_1 -rOPENBSD_4_2
By zobaczyć różnice pomiędzy wersjami 4.2 a -current ("HEAD"), wykonaj:
    # cd /usr/src/etc
    # cvs diff -u -rOPENBSD_4_2 -rHEAD
Skrypt /dev/MAKEDEV nie jest uaktualniany automatucznie jako część procesu tworzenia, jednakże jest instalowany jako część uaktualnienia binarnego. Jako generalną zasadą, dobrym pomysłem jest wykonanie kopii (jeżeli jest to wymagane) i uruchomienie tego skryptu w twoim drzewie źródeł podczas aktualizacji:
    # cd /dev
    # cp /usr/src/etc/etc.`machine`/MAKEDEV ./
    # ./MAKEDEV all

Gdy już określone zostały zmiany, wprowadź je do lokalnego drzewa, zachowując każdą zmianę lokalnej konfiguracji jaką możesz wykonać.

Typowe zmiany /etc na które należy zwrócić uwagę pomiędzy wersjami release, zawierają:

Zmiany te są podsumowane w upgrade42.html (dla aktualizacji do 4.2-release) lub current.html (dla aktualizacji do -current).

5.11.11 - Czy istnieje jakaś prosta droga do stworzenia wszystkich zmian w hierarchii plików?

Od czasu do czasu, pliki lub katalogi są dodawane lub usuwane z pliku hierarchy. Także, informacje o uprawnieniach dla części systemu plików mogą się zmieniać. Jako najprostszym sposobem by mieć pewność, że twoja hierarchia jest aktualna jest wykorzystanie narzędzia mtree(8).

Najpierw zdobądź najnowsze źródła, następnie wykonaj poniższe:

    # cd /usr/src/etc/mtree
    # install -c -o root -g wheel -m 600 special /etc/mtree
    # install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree
    # mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

Twoja hierarchia plików powinna być od teraz aktualna.

5.11.12 - Czy mogę cross-kompilować? Czemu nie?

Narzędzia do cross-kompilacji znajdują się w systemie dla developerów pracujących nad nową platformą. Nie są jednak utrzymywane w zalożeniu generalnego użytku.

Gdy developerzy wprowadzają nową platformę jednym z pierwszych wielkich testów jest natywna kompilacja. Budowa systemu ze źródeł powoduje znaczne obciążenie systemu operacyjnego i komputera, a więc stanowi bardzo dobry test o tym jak dobrze system działa. Z tego powodu w OpenBSD proces budowy systemy odbywa się na platformie na którą system jest przeznaczony, co nazywane jest "budową natywną". Bez natywnej budowy znacznie trudniej jest mieć pewność że różne platformy rzeczywiście działają, a nie tylko się bootują.

[Spis treści] [Sekcja 4 - Instalacja OpenBSD] [Sekcja 6 - Sieć]


[powrót] www@openbsd.org
$OpenBSD$