[OpenBSD]

[FAQ Index] [Do sekce 4 - Průvodce instalací] [Do sekce 6 - Nastavení sítě]

5 - Vytvoření systému ze zdrojových kódů

Obsah


5.1 - Druhy OpenBSD

Existují tři "příchutě" OpenBSD:
  • -release: Verze OpenBSD dodávaná každých šest měsíců na CD.
  • -stable: Release, plus opravy považované za kritické pro bezpečnost a spolehlivost.
  • -current: Momentální verze OpenBSD, z které se stane další release.
    • Graficky se vývoj těchto příchutí dá znázornit takto: 
           ,------o-----------o----X                    3.1 Stable
       |      .           .
       |      .    ,------o---------o----X          3.2 Stable
       |      .    |      .         .
       |      .    |      .    ,----o----------o--> 3.3 Stable
       |      .    |      .    |    .          .
       |      .    |      .    |    .    ,-----o--> 3.4 Stable
       |      .    |      .    |    .    |     .
       |      .    |      .    |    .    |     .
 -->3.1Rel----->3.2Rel----->3.3Rel----->3.4Rel----> Current

          Čas --->

    Každých šest měsíců se kód větví do -current, -release a -stable -- -release se stane zmrazený bod ("Tag") v historii stromu zdrojových souborů - nikdy se nemění a je to to co je na CD discích a FTP serverech. -Current je místo, kde probíhá aktivní vývoj a stane se z něj další -release OpenBSD.

    -stable (také známý jako "Patch branch") je založen na -release, a jak každý může vidět, je to "větev" z hlavní vývojové cesty OpenBSD. Důležité opravy provedené do -current, jsou "back portovány" do větví i-stable. Na obrázku uvedeném výše odpovídají svislé tečkované čáry opravám chyb, které jsou přidávány do větvě -stable. Rovněž si můžete výše všimnout, že větev 3.1-stable byla ukončena po vydání 3.3-release, a 3.2-stable větev 3.2-stable byla ukončena po vydání 3.4-release -- starší verze jsou typicky podporovány 2 verze zpětně. Podpora starších verzí zabírá prostředky a čas, zatímco bychom mohli poskytovat podporu pro starší releasy, chtěli bychom se raději zaměřit na vylepšování a nové vlastnosti. Větev -stable je ze své podstaty velmi snadno buildovatelná z -release té samé verze (např. přechod z 3.4-release k 3.4-stable).

    Větev -stable je typicky shodná s -release, navíc obsahuje opravy, uvedené na stránce errata, a některé jednoduché opravy, které se nevyskytují v errata. Obvykle nejsou -stable a release na které je stable založen měněny, pokud změna vyžaduje úpravu manuálové stránky. Jinými slovy, podpora nových zařízení NEbude do -stable nikdy přidána a podpora pro nové vlastnosti bude přidána pouze vyjímečně, pokud je to velmi důležité.

    Varování: -current se neustále mění. Změny následují doslova minutu po minutě a časo se může stát, že v době, kdy zrovna aktualizujete zdrojové kódy, dojde k takové změně. Jak bylo zmíněno dříve, neexistuje žádný slib, že systém se podaří zkompilovat nebo že bude pracovat (samozřejmě, doufáme že ano). Je úplně možné a ne tak výjimečné, že si stáhnete zdrojové soubory -current a nepodaří se vám je zkompilovat, zatímco o pět minut později to může běžet docela dobře. Pokud nejste připraveni si s tím poradit, držte se od -current dále.

    Většina uživatelů běží buď -stable nebo -release. Mnoho lidí běží -current na produkčních systémech, a je důležité, že někteří lidé tak činí proto, aby identifikovali chyby a otestovali nové fíčury. Nicméně, pokud nevíte jak správně popsat, diagnostikovat a poradit si s problémem, neříkejte sobě (nebo komukoliv jinému), že "pomáháte projektu" tím, že běžíte -current. "Tohle nepracuje!" není užitečné hlášení o chybě. "Nedávné změny v driveru pciide poškodily kompatibilitu s mým IDE rozhraním založeném na Slugchip, dmesg funkčního a nefunkčního systému následují..." může být užitečné chybové hlášení.

    Stává se, že "normální" uživatelé chtějí žít na hraně a běží -current, nejčastěji tehdy, když mají zařízení, které není podporované v -release (a tím pádem i ve -stable), nebo chtějí použít novou fíčuru v -current. V tomto případě je volba buď používat -current nebo nepoužívat ono zařízení a -current může být menší zlo. Nicméně, člověk nemůže očekávat pomocnou ruku od developerů.

    Snapshots

    Mezi jednotlivými verzemi OpenBSD jsou na FTP serverech k dispozici tzv. snapshoty. Jak jméno napovídá, jedná se o build zdrojových kódů, který byl k dispozici v době výroby snapshotu pro tu kterou platformu. Pamatujte si, že u určitých platforem trvá řádově DNY, než je build snapshotu dokončen a dodán k distribuci. Nikdo nemůže slíbit, že snapshot bude kompletně fungovat, nebo jej půjde nainstalovat. Často je motivací k vytvoření snapshotu provedení důležité změny, kterou je třeba otestovat. Pro některé platformy se snapshoty vytvářejí denně, u jiných méně frekventovaněji. Pokud chcete provozovat -current, poslední snapshot je většinou to, co potřebujete a upgrade za použití snapshotu je obvykle dobrý odrazový můstek předtím než se pokusíte vybuildovat -current.

    Čas od času se někdo ptá, zda existuje způsob, jak získat kopii přesně toho kódu, ze kterého byl snapshot vytvořen. Odpověd zní ne. Jednak je diskutabilní, na co by to bylo dobré, jednak jsou snapshoty vytvářeny podle libovůle, podle časových možností a podle dostupných zdrojů. Na rychlých platformách můžete vytvořit několik snapshotů denně. Na pomalých platformách můžete čekat týden, než se snapshot vytvoří. Poskytování tagů nebo značek pro každý snapshot ve zdrojovém kódu by bylo nepraktické.

    Udržování věcí v souladu

    Je důležité porozumět že OpenBSD je Operační Systém, myšlený jako celek, nejenom kernel s několika utilitami. Musíte zajistit, aby kernel, "userland" (podpůrné utility a soubory) a strom portů byly, co se týče jejich verzí, v souladu. Jinak se mohou přihodit nepříjemné věci. Jinak řečeno (protože lidé prostě pořád dělají tuto chybu), nemůžete běžet úplně nový strom portů na měsíc starém systému nebo vytvářet kernel ze zdrojových souborů -current a očekávát, že bude fungovat s userlandem z -release. Ano, můžete namítat, že to znamená, že pokud byl nový program přidán dnes do portů, který chcete používat, bude k tomu nutný update. Litujeme, ale znovu opakujeme: naše zdroje jsou omezené.

    Dále je nutné porozumět tomu, že při upgrade zdrojových souborů je aktualizační proces podporován pouze v jednom směru: ze starého na nový, a z -stable na -current. Nemůžete provozovat 3.4-current či snapshot a poté se rozhodnout, že je to příliš nebezpečné a vrátíte se zpět k 3.4-stable. Pokud si vyberete jinou cestu než podporovanou, pak jste v tom sami.

    Ano, toto znamená že předtím než začnete používat -current měli byste se dlouze a důkladně zamyslet.

    5.2 - Proč bych měl vytvořit své vlastní jádro?

    Několik důvodů, přestože vlastní jádro většinou sestavují především zkušení uživatelé, kteří dobře rozumí celému systému.

  • váš počítač má obecně velmi málo paměti RAM a vy byste jí rádi co nejvíce ušetřili, což provedete vyřazením těch ovladačů zařízení z jádra, které nepoužíváte, např. GENERIC jádro i386 architektury má přibližně velikost 3,1 MB , průměrná velikost uživatelského jádra bez nepoužívaných ovladačů je cca 1,7MB.
  • Odstraníte některé původní volby, se kterými bylo jádro kompilováno a můžete naopak přidat jiné, které nebyly původně v konfiguraci zahrnuty
  • Můžete přidat některé volby experimentálního, zkušebního významu, které jsou k dispozici pro testování nového kódu jádra

    • Ve většině případů NEbudete potřebovat kompilovat vlastní jádro. GENERIC jádro bude obvykle tím, které potřebujete. Vlastně je tu i několik důvodů, ze kterých byste neměli chtít kompilovat vaše vlastní jádro. Hlavní důvod je ten, že je snadné udělat nějaké změny v nastavení jádra, které se zdají být logické, ale nefungují. To je nebezpečí, které váš zásah provází. Jestliže něco v novém jádře nefunguje tak jak by mělo, vyzkoušejte prosím nejprve GENERIC jádro, dříve než odešlete zprávu o chybě (bug report). Vývojáři budou obvykle ignorovat takové hlášení o chybě, které se zabývají vlastními jádry dokud nebude problém reprodukován také v GENERIC kernelu. Byli jste varováni.

    5.3 - Soubory pro konfiguraci jádra

    Generování OpenBSD jádra je řízeno z několika konfiguračních souborů, jež jsou umístěny standardně v adresáři /usr/src/sys/arch/<arch>/conf/. Všechny architektury mají soubor GENERIC, který se používá pro vygenerování standardního OpenBSD jádra pro danou platformu (GENERIC jádro). Dále zde mohou být další konfigurační soubory, které se používají pro vytvoření jádra s určitým zaměřením, např. pro minimální RAM, bezdiskové stanice apod.

    Konfigurační soubor je zpracován programem config(8), který vytváří konfiguraci a kompilační adresář v ../compile. V typické instalaci OpenBSD je kompilační adresář umístěn v /usr/src/sys/arch/<arch>/compile/. Program config(8) rovněž vytváří Makefile a další soubory, které jsou potřeba pro úspěšnou kompilaci jádra.

    Volby (options) při konfiguraci jádra jsou nastavení, kterými konfigurujete složení vašeho jádra. Tyto nastavení přidávají při kompilaci do jádra části kódu, který realizuje požadované operace. Takto můžete specifikovat přesně to co od svého jádra očekáváte, zahrnout podporu přesně pro ta zařízení, které potřebujete a která používáte, a naopak vyjmout z jádra ty ovladače, které jsou pro vás nepotřebné. Je zde spousta voleb, které můžete při konfiguraci zapnout nebo vypnout. Zde se zaměříme jen na některé z nich, především na ty, které se používají nejčastěji. Pro kompletní seznam těchto voleb si přečtěte manuálovou stránku příkazu options(4) a protože se seznam těchto voleb čas od času mění, ujistětě se, že máte manuálovou stránku pro stejnou verzi OpenBSD, jako tu, kterou kompilujete. Můžete se rovněž podívat na příklady konfiguračních souborů, které jsou dostupné pro vaši architekturu.

    Nepřidávejte, neodebírejte ani neměnte volby v konfiguračním souboru jádra, pokud pro to nemáte důvod! Jediná konfigurace jádra, která je podporována OpenBSD týmem je jádro GENERIC, s kombinací voleb nacházející se v /usr/src/sys/arch/<arch>/conf/GENERIC a /usr/src/sys/conf/GENERIC tak jak jsou dodávány OpenBSD týmem (tj. NE editovány). Reportování problémů s uživatelským jádrem téměř vždy vyústí v to, že budete vyzvání, aby jste reprodukovali problém s jádrem GENERIC. Ne všechny volby jsou kompatibilní jedna s druhou a mnoho voleb je požadováno k tomu, aby systém vůbec mohl fungovat. Není žádná garance toho, že tím, že se vám podaří jádro zkompilovat, tak bude také bez problémů běžet.

    Následuje seznam umístění konfiguračních souborů jádra pro jednotlivé architektury:

  • Konfigurační soubory pro architekturu Alpha
  • Konfigurační soubory pro i386
  • Konfigurační soubory pro macppc
  • Kon figurační soubory pro architekturu sparc
  • Kon figurační soubory pro architekturu sparc64
  • Konfiurační soubory pro vax
  • Konfigurační soubory pro hppa
  • Ostatní architektury

    Při bližším ohledání těchto souborů zjistíte, že obsahují řádku typu: 

    	include "../../../conf/GENERIC"
    To znamená, že se v nich odkazuje ještě na další konfigurační soubor. V tomto souboru se nacházejí na architektuře nezávislé volby. Při vytváření vašeho vlastního jádra se tedy určitě podívejte na /sys/conf/GENERIC.

    Konfigurační volby jádra by měly být napsány v konfiguračním souboru jádra ve formátu :

    option      jméno
    Kupříkladu pro přidáné volby "DEBUG" do jádra, přidejte řádek: 
         option      DEBUG
    Volby v OpenBSD jádře jsou překládány na volby preprocesoru při kompilaci, proto volba jako DEBUG způsobí kompilaci zdrojového kódu s volbou -DDEBUG. Což je ekvivalentní tomu, že bychom ve všech zdrojových souborech připsali #define DEBUG.

    Čas od času je potřeba vypnout nějakou volbu, která je už definovaná, typicky v souboru "src/sys/conf/GENERIC". I když byste mohli modifikovat kopii tohoto souboru, lepší volba je použít statement rmoption. Kupříkladu pokud skutečně nechcete zakompilovat interní debugger jádra (což vám nedoporučujeme!), použili v konfiguračním souboru řádek typu: 

         rmoption DDB
    option DDB je definováno v src/sys/conf/GENERIC, ale výše uvedený řádek rmoption ji deaktivuje.

    Ještě jednou bychom vás chtěli poprosit, aby se podívali do manuálové stránky options(4), kde naleznete dostatek informací o jednotlivých volbách jádra. Taktéž poznamenejme, že mnoho z těchto voleb má svoji vlastní manuálovou stránku -- vždycky si přečtěte všechno, co je o dané volbě k dispozici, než přikročíte k jejímu přidání nebo odstranění z jádra.

    5.4 - Tvorba vašeho vlastního jádra

    Úplné instrukce pro vytvoření vlastního jádra jsou v manuálové stránce afterboot(8).

    Pro kompilaci jádra, které bylo na CD-ROM potřebujete nejprve mít k ruce zdrojový kód. Zdrojový kód jádra se nachází jak na officiálním CD (disk 3), tak na FTP serverech. Následující příklad předpokládá, že CD3 je připojeno na /mnt: 

    # cd /usr/src
# tar xvzf /mnt/src.tar.gz
    Poznámka: Pokud stahujete z FTP serverů, budete potřebovat DVA soubory, src.tar.gz a sys.tar.gz. První jsou zdrojové kódy "userlandu" -- vše kromě jádra, druhý jsou zdrojové kódy jádra. Stáhněte a rozbalte oba dva jako výše, protože povětšinou budete potřebovat oba dva. Na CD-ROM jsou oba dva soubory kombinovány do jednoho.

    Při tvorbě vlastního jádra je nejjednodušší začít s GENERIC jádrem. To se nachází v /usr/src/sys/arch/${arch}/conf/GENERIC, kde $ARCH je vaše architektura. V tomto adresáři se rovněž nachází další příklady konfigurací. V následujícím vám ukážeme dva příklady pro kompilaci jádra. První kompiluje jádro v adesářovém stromu, který je pouze pro čtení. Druhý v zapisovatelném adresáři. 

    # cd /somewhere
# cp /usr/src/sys/arch/$ARCH/conf/SOMEFILE .
# vi SOMEFILE (uděláte změny, které chcete)
# config -s /usr/src/sys -b . SOMEFILE
    následované buď: 
        # make depend
         - NEBO -
    # make clean
# make
    Musíte spustit 'make depend' když provádíte nějaké změny (včetně updatů a patchů) ve vašem stromu zdrojových souborů (jinými slovy skoro vždy, dokud nepotřebujete spustit 'make clean').

    Pokud jste provedli změny do voleb konfigurace jádra, a/nebo jste udělali velké změny ve vašem stromě zdrojových souborů, měli byste použít 'make clean' namísto výše zmíněného 'made depend'. Vždy je bezpečné provést 'make clean', ačkoliv to může mít za následek delší čas kompilace, protože toho bude více buildováno.

    Pro kompilaci jádra uvnitř zapisovatelného adresářového stromu, vykonejte následující:

    # cd /sys/arch/$ARCH/conf # vi SOMEFILE (uděláte změny, které chcete) # config SOMEFILE (o tomhle si přečtěte více zde: config(8))
    # cd ../compile/SOMEFILE # make

    Kde $ARCH je architektura, kterou používáte, např. i386. Můžete rovněž spustit make depend pro zjištění závislostí, až budete kompilovat jádro příště.

    Umístění jádra na své místo: 

    # cp /bsd /bsd.old
# cp /sys/arch/$ARCH/compile/SOMEFILE/bsd /bsd
    Pro přechod k vašemu starému jádru v čase startu systému napište pouze: 
    boot> bsd.old
    a vaše staré jádro bude nahráno namísto /bsd.

    Někdy budete potřebovat spolu s novým jádrem instalovat i nový boot blok. Více viz. faq14.8 o OpenBSD Bootloaderu. Zde naleznete základní přehled o jeho používání.

    5.5 - Konfigurace při bootu

    Někdy při startu systému se stane, že vaše jádro nalezne zařízení, ale možná se špatným IRQ. A možná právě toto zařízení budete muset ihned použít. Aniž byste museli vytvářet nové jádro, můžete zkusit konfiguraci OpenBSD jádra v okamžiku bootování. Tato konfigurace opraví váš problém pouze v jednom startu systému. Po rebootování budete muset tuto proceduru opakovat. Tento postup je tudíž myšlen jen jako dočasná záplata, a problém byste měli opravit opravou a rekompilací jádra. Vaše jádro musí být zkompilované s volbou option BOOT_CONFIG, což pro GENERIC jádra platí.

    Většina této dokumentace se nachází v manuálové stránce boot_config(8).

    Pro start s uživatelskou konfigurací jádra, ( User Kernel Config, UKC) , použijte při bootování volbu -c. 

    boot> boot hd0a:/bsd -c
    Nebo jakékoliv jiné jádro, které chcete nabootovat. Poté co provedete předchozí krok, obdržíte UKC prompt. Odtud můžete vykonávat příkazy přímo specifikující zařízení jádra, která chcete změnit, vypnout nebo zapnout.

    Zde je seznam příkazů v UKC.

    Jakmile jste jednou nakonfigurovali vaše zařízení, použijte quit nebo exit a continue pro pokračování bootování. Poté byste měli opravit nastavení jádra a zkompilovat nové jádro. Další info viz. Tvorba vašeho vlastního jádra.

    5.6 - Jak získat podrobnější výpis během bootování

    Podrobnější výpis při bootování může být velmi užitečný, pokud se snažíte ladit problémy. Pokud například systém nedetekuje floppy disk a potřebujete více informací, prostě rebootujete. Poté co obdržíte "boot>" prompt, bootujte s -c. Dostanete UKC>, pak vykonejte: 

    UKC> verbose
autoconf verbose enable
UKC> quit

    Následovat budou extrémně podrobné startovací hlášky.

    5.7 - Použití příkazu config(8) pro změnu zkompilovaného jádra

    Volby -e a -u příkazu config(8) mohou být velmi užitečné a šetří čas strávený kompilací jádra. Volba -e umožňuje, abyste vstoupili do UKC neboli User Kernel Configu v běžícím systému. Změny, které provedete, se pak objeví při dalším bootu. Volba -u testuje , zda byly provedeny při bootování v jádře nějaké změny. Za předpokladu, že jste použili boot -c pro vstup do UKC při bootování systému.

    Následující příklad nám ukazuje vyřazení ep* zařízení z jádra. Pro šetrnost vašeho počínání musíte použít volbu -o, která zapisuje provedené změny do souboru, který uvedete. Např. config -e -o bsd.new /bsd zapíše změny do bsd.new . Příklad nepoužívá volbu -o , proto změny jsou ignorovány a nejsou zapsány zpět do binárky jádra. Pro více informací o tom, jak obdržet chybové a varovné hlášky, čtěte manuálovou stránku config(8). 

    $ sudo config -e /bsd
OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MST 2003
    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

    V předcházejícím příkladě byla všechna zařízení ep* v jádře vypnuta a nebudou zkoušena při startu. V některých situacích, kdy použijete při bootu UKC, pomocí boot -c, budete chtít změny uložit trvale. Provést to můžete pomocí volby -u . V následujícím příkladě, počítač nabootoval do UKC a zařízení wi(4) bylo odstraněno. Protože změny při boot -c NEJSOU trvalé, musí být zapsány. Tento příklad zapisuje změny provedené z boot -c do nového jádra uloženého v bsd.new. 

    $ sudo config -e -u -o bsd.new /bsd
OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MST 2003
    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.8 - Společné problémy při kompilaci a buildování

    5.8.1 - Build se zastavil s chybou "Signal 11"

    Buildování OpenBSD a dalších programů ze zdrojových kódů je úloha, která klade vyšší nároky na hardware než většina ostatních, intezivně používá procesor, disky a paměť. Výsledkem je, že pokud máte problémový hardware, s vysokou pravděpodobností se tyto problémy objeví v průběhu buildování. Chyby typu Signal 11 jsou typicky způsobeny problémy s hardware, často se také jedná o problémy s pamětí, ale může to být také problém CPU, základní desky nebo třeba přehřátí. Můžete mít systém, který je v podstatě velmi stabilní, ale na kterém nejste schopni zkompilovat programy, (tomuhle moc nevěřím, pozn. překladatele).

    Zřejmě zjistíte, že je nejjednodušší opravit nebo nahradit komponenty, které způsobují chyby, protože problémy se do budoucna budou s nejvyšší pravděpodobností prohlubovat. Pokud máte hardware, který chcete skutečně použít a máte s ním problémy, jednoduše nainstalujte snapshot nebo release (nebo třeba zkuste NetBSD).

    Více informací najdete např. v Sig11 FAQ.

    5.8.2 - "make build" skončí s hláškou "cannot open output file snake: is a directory"

    Jedná se o výsledek dvou různých chyb:
    • Nesprávně jste provedly update či stažení vašeho CVS stromu. V průběhu operace CVS checkout musíte použít volbu "-P", pokud provádíte update zdrojových kódů s CVS, musíte použít volby "-Pd" programu cvs(1), jak je zdokumentováno v průvodci anoncvs, upgrade-minifaq a FAQ. Tyto volby vám zajistí, že jsou přidány nové adresáře a odstraněny prázdné adresáře, které už nejsou ve stromu zapotřebí.
    • Nesprávně jste vytvořili adresář obj před započetím buildu. Buildování stromu bez adresáře /usr/obj není podporováno.
    Je důležité pečlivě následovat instrukce, když stahujete a aktualizujete vaše zdrojové kódy a buildujete váš strom.

    [FAQ Index] [Do sekce 4 - Průvodce instalací] [Do sekce 6 - Nastavení sítě]

    +[zpět] www@openbsd.org
    Originally [OpenBSD: faq5.html,v 1.90 ]
    $Translation: faq5.html,v 1.18 2004/01/11 21:41:15 certik Exp $
    $OpenBSD: faq5.html,v 1.18 2004/01/16 20:30:20 jufi Exp $