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

5 - Tworzenie systemu ze źródeł

Spis treści

• 5.1 - Wątki OpenBSD
• 5.2 - Dlaczego potrzebuję systemu zbudowanego ze źródeł?
• 5.3 - Tworzenie OpenBSD ze źródeł
  • 5.3.1 - Wprowadzenie
  • 5.3.2 - Instalacja lub uaktualnienie do najbliższej dostępnej wersji binarnej
  • 5.3.3 - Pobieranie odpowiedniego kodu źródłowego
  • 5.3.4 - Tworzenie jądra
  • 5.3.5 - Tworzenie przestrzeni użytkownika
• 5.4 - Tworzenie wydania
• 5.5 - Tworzenie X-ów
• 5.6 - Dlaczego potrzebuje własnego jądra?
• 5.7 - Tworzenie własnego jądra
• 5.8 - Konfiguracja kernela podczas startu systemu
• 5.9 - Zastosowanie config(8) do zmian w skompilowanym jądrze
• 5.10 - Otrzymywanie dokładniejszych informacji podczas startu systemu
• 5.11 - Typowe problemy, sztuczki i pytania związane z kompilacją i tworzeniem ze źródeł
  • 5.11.1 - Tworzenie zatrzymane przez błąd "Signal 11"
  • 5.11.2 - Instrukcja "make build" przerwana komunikatem "cannot open output file snake: is a directory"
  • 5.11.3 - Mój system nie działa bez IPv6!
  • 5.11.4 - Oops! Zapomniałem stworzyć katalogu /usr/obj!
  • 5.11.5 - Umieszczanie /usr/obj na jego własnej partycji
  • 5.11.6 - W jaki sposób mogę nie tworzyć części drzewa źródeł?
  • 5.11.7 - Gdzie mogę się dowiedzieć więcej na temat procesu tworzenia ze źródeł?
  • 5.11.8 - Nie widzę żadnej wersji snapshot w FTP. Gdzie się podziały?
  • 5.11.9 - W jaki sposób mogę załadować nowszą wersję kompilatora (gcc)?
  • 5.11.10 - Jaka jest najlepsza metoda uaktualnienia /etc, /var, oraz /dev?
  • 5.11.11 - Czy istnieje jakaś prosta droga do stworzenia wszystkich zmian w hierarchii plików?
  • 5.11.12 - Czy mogę cross-kompilować? Czemu nie?

5.1 - Wątki OpenBSD

• -release: Wersja OpenBSD publikowana co sześć miesięcy na CD.
• -stable: Wersja 'Release', wraz z łatami (ang. patches) naprawiającymi krytyczne dla bezpieczeństwa i wydajności elementy systemu.
• -current: Gdzie wykonywane są nowe prace rozwojowe i ewentualnie, przekształci się w następne wydanie 'Release'.

,------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

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

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

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ł?

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

• Kompilacja własnego systemu jako droga do uaktualnienia nie jest wspierana.
• NIE uzyskasz lepszej wydajności systemu poprzez zbudowanie go ze źródeł.
• Zmiany opcji kompilatora mogą bardziej zepsuć twój system niż go udoskonalić.

• Testy lub rozwijanie nowych funkcji.
• Kompilacja systemu powoduje spore obciążenie komputera, może być to droga do sprawdzenia czy system który właśnie złożyłeś lub nabyłeś jest faktycznie w całkiem dobrej kondycji.
• Chcesz podążać za odgałęzieniem -stable.
• Potrzebujesz wysoce dostosowanej wersji OpenBSD dla specjalnego oprogramowania.

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

• Uaktualnienie do najnowszej dostępnej wersji binarnej.
• Pobranie odpowiedniego kodu źródłowego.
• Kompilacja jądra i zabootowanie z niego.
• Budowa "przestrzeni użytkownika" ("make build").

• Budowa "release".
• Budowa X.

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

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

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

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

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

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

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

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

$ 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 ...

5.3.5 - Kompilacja przestrzeni użytkownika

• Czyścimy katalog /usr/obj i przebudowujemy dowiązania symboliczne:

  # rm -rf /usr/obj/* # cd /usr/src # make obj

  Zauważ, że wykorzystanie katalogu /usr/obj jest obowiązkowe. Niepowodzenie w tym kroku, zanim zostanie zbudowana reszta systemu najprawdopodobniej pozostawi twoje drzewo src w złej postaci.

• Upewnij się że wszystkie stosowne katalogi zostały utworzone.

  # cd /usr/src/etc && env DESTDIR=/ make distrib-dirs

• Skompiluj system:

  # cd /usr/src # make build

  Użytki z "przestrzeni użytkownika" zostaną skompilowane i zainstalowane we właściwej kolejności. Jest to najbardziej czasochłonny krok -- bardzo szybkie maszyny zdolne są wykonać go w czasie poniżej godziny, na maszynach bardzo wolnych może to potrwać kilka dni. Gdy ten krok zostanie zakończony, będziesz posiadał na miejscu nowe binarki w swoim systemie.

• Jeżeli kompilujesz wersję -current: Zaktualizuj /dev oraz /etc, ze zmianami podanymi w current.html. Jeżeli podążasz za wersją -stable po właściwym procesie uaktualnienia lub zainstalowaniu właściwych binarek startowych, ten krok nie jest ci potrzebny.

5.4 - Kompilacja wersji -release

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

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

# cd /usr/src/distrib/crunch && make obj depend all install

# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel

# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old & # mkdir -p ${DESTDIR} ${RELEASEDIR}

Przystępujemy do tworzenia samego wydania:

# cd /usr/src/etc # make release

# cd /usr/src/distrib/sets # sh checkflist

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)

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

$ cd /usr/src $ cvs -qdanoncvs@anoncvs.example.org:/cvs checkout -P xenocara

Budowa Xenocara

# cd /usr/src/xenocara # make bootstrap # make obj # make build

Tworzenie wydania

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

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:

• Rzeczywiście wiesz co robisz i potrzebujesz OpenBSD na komputerze z małą ilością RAMu poprzez usunięcie niepotrzebnych sterowników urządzeń.
• Rzeczywiście wiesz co robisz i chcesz usunąć domyślne ustawienia lub dodać nowe, których standardowo nie włączono (i masz powód, aby to robić).
• Rzeczywiście wiesz co robisz i chcesz uaktywnić eksperymentalne ustawienia.
• Rzeczywiście wiesz co robisz i masz specjalne potrzeby, których nie spełnia GENERIC, i nie zamierzasz pytać dlaczego to nie działa (jeśli Ci się nie uda).

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

• Tak naprawdę nie potrzebujesz go.
• Nie uzyskasz szybszego systemu.
• Jest duża szansa, że Twój komputer będzie mniej niezawodny.
• Nie otrzymasz żadnego wsparcia od twórców systemu.
• Będziesz zmuszony odtworzyć każdy problem z jądrem GENERIC zanim programiści zajmą się Twoim raportem o błędzie.
• Użytkownicy i programiści będą się z Ciebie śmiać, kiedy popsujesz sobie system.
• Niestandardowe opcje kompilatora zwykle ułatwiają ujawnienie błędów kompilatora, zamiast poprawiać wydajność 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

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:

• Pliki konfiguracyjne dla jądra alpha
• Pliki konfiguracyjne jądra i386
• Pliki konfiguracyjne jądra macppc
• Pliki konfiguracyjne jądra sparc
• Pliki konfiguracyjne jądra sparc64
• Pliki konfiguracyjne jądra vax
• Pliki konfiguracyjne jądra hppa
• Pozostałe architektury

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

option      name=value

option DEBUG

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

include "arch/i386/conf/GENERIC" boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards pccom* at boca? slave ?

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

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

• add device - Dodaje urządzenie poprzez kopiowanie innego
• change devno | device - Modyfikuje jedno lub więcej urządzenie
• disable devno | device - Wyłącza jedno lub więcej urządzenie
• enable devno | device - Włącza jedno lub więcej urządzenie
• find devno | device - Znajduje jedno lub więcej urządzenie
• help - Krótkie podsumowanie komend UKC
• list - Wyświetlenie WSZYSTKICH znanych urządzeń
• exit/quit - Kontynuacja startu systemu
• show [attr [val]] - Pokazuje urządzenia z atrybutami i opcjonalnie z podaną wartością

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

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

Najczęstszym problemem jest jeden z poniższych:

• Nie rozpoczęcie z etapu pobrania właściwych wersji binarnych, łącznie z usiłowaniem aktualizacji ze źródeł lub założenie że tygodniowy snapshot jest "wystarczająco bliski".
• Pobranie kodu źródłowego z niewłaściwej gałęzi.
• Postępowanie niezgodne z opisem.
• Próby dostosowania lub "optymalizacji" systemu.

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"

• Drzewo CVS zostało ściągnięte lub uaktualnione nieprawidłowo. Kiedy jest wykonywana operacja sprawdzania CVS, należy stosować opcję "-P", natomiast podczas uaktualniania drzewa przez CVS, należy użyć opcję "-Pd" zgodnie z dokumentacją cvs(1), co zostało opisane także powyżej. Użycie powyższych opcji daje pewność, że katalogi są dodawane i usuwane z ciągle zmieniającego się drzewa OpenBSD.
• Nieprawidłowo stworzono katalog obj zanim podjęto proces kompilacji. Kompilacja drzewa bez katalogu /usr/obj nie jest wspierane.

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

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

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

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

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ł?

• release(8)
• afterboot(8)
• mk.conf(5)
• /usr/src/Makefile
• Patch Branches (-stable)
• (dla X) /usr/X11R6/README na twoim systemie

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)?

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:

• gcc3: /usr/src/gnu/usr.bin/gcc
• gcc2: /usr/src/gnu/egcs/gcc

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ą:

• Dodatki do /etc/protocols oraz /etc/services
• Nowe sysctls (zobacz /etc/sysctl.conf)
• Zmiany w domyślnych zadaniach cron'a. Zobacz /etc/daily, /etc/weekly, /etc/monthly, oraz /etc/security
• Wszystkie skrypty rc włącznie z netstart
• Zmiany urządzeń, patrz wcześniej
• Zmiany hierarchii plików w /etc/mtree, patrz poniżej
• Nowi użytkownicy (/etc/passwd) i grupy (/etc/group)

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?

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ć]