![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ Index] [Do sekce 1 - Úvod do OpenBSD] [Do sekce 3 - Začínáme s OpenBSD]
Oficiální stránka OpenBSD projektu se nachází na : http://www.OpenBSD.org/cs/.
Zde najdete mnoho potřebných informací o všech aspektech OpenBSD projektu.
OpenBSD magazín je zaměřen na novinky a zásady OpenBSD.
OpenBSDsupport.org je stránka sbírající "uživateli spravované" dokumenty různé kvality, ale většinou pokrývající témata,která nejsou součástí těchto FAQ nebo jiných oficiálních dokumentů..
Mnoho uživatelů zprovoznilo servery a stránky o informacích zaměřených na OpenBSD.Tak jako se vším na Internetu,kvalitní vyhledávač vám může ulehčit život,ovšem se správnou dávkou skepticismu.Tak jako vždy,nezadávejte do počítače slepě příkazy, kterým nerozumíte.
OpenBSD projekt udržuje několik populárních mailing listů do kterých se uživatelé mohou přihlásit a sledovat je.Pro přihlášení do mailing listu pošlete email na adresu majordomo@openbsd.org. Na této adrese běží automatická přihlašovací služba.V těle vaší zprávy musíte na jeden řádek napsat přihlašovací příkaz pro mailing list,ke kterému se chcete přihlásit. Například:
subscribe announce
Procesor tohoto listu by vám měl odpovědět dotazem na potvrzení vašeho zájmu o přihlášení k mailing listu. Díky tomu vás nemůže přihlásit někdo jiný jen kvůli tomu,aby vám zahltil schránku.Zpráva by měla obsahovat instrukce pro několik různých způsobů jak váš požadavek potvrdit,včetně odkazu na web stránku, formy odpovědi na potvrzovací zprávu a nebo odpověď pro majordomo@openbsd.org. Použijte metodu,která vám vyhovuje nejvíce.Sami uvidíte,že všechny tři metody obsahují unikátní a časově omezené identifikační číslo jako například A56D-70D4-52C3, opět proto aby se služba ujistila,že jste skutečně osoba,která požádala o přihlášení (toto je skutečný "opt-in").
Jakmile potvrdíte váš zájem o připojení,tak budete ihned přidáni do mailing listu a procesor listu vás bude informovat, že jste byli v pořádku přidáni.
Pro odhlášení z mailing listu můžete opět poslat zprávu na majordomo@openbsd.org. Může vypadat nějak takto:
unsubscribe announce
Pokud máte nějáké problémy s mailing list systémem,tak si prosím nejprve přečtěte nápovědu,kterou můžete obdržet tak, že zašlete zprávu na majordomo@openbsd.org s tělem zprávy "help".
Vaše přihlášení do mailing listů OpenBSD můžete také spravovat pomocí webového rozhraní http://lists.openbsd.org
Některé z nejvíce populárních mailing listů OpenBSD jsou:
Před položením otázky na misc nebo jiném mailing listu prosím prohlédněte archívy,protože většina běžných otázek byla již několikrát dotazována.Můžete to být poprvé co jste se setkali s problémem nebo otázkou,ale ostatní na mailing listech mohli vidět stejnou otázku několikrát v posledním týdnu a nemusí mít náladu vidět tuto otázku znova.Pokud pokládate otázku spojenou s hardware,tak vždy přiložte výpis z dmesg(8)!
Různé archívy,nápovědy pro další mailing listy a další informace můžete najít na stránce mailing listů.
Neoficiální mailing list,který by mohl zajímat nové uživatele OpenBSD a Unixu je OpenBSD Newbies list.
OpenBSD obsahuje bohatou dokumentaci ve formě manuálových stránek. Vynakládáme značné úsilí abychom se ujistili,že manuálové stránky jsou aktuální a přesné.Ve všech případech jsou manuálové stránky považovány za hlavní a ověřený zdroj informací o OpenBSD.
Pro přístup k manuálovým stránkám se ujistěte, že jste nainstalovali man52.tgz set.
Zde je seznam několika nejvíce užitečných manuálových stránek pro nové uživatele:
Začínáme
Všechny manuálové stránky od OpenBSD jsou dostupné na webové adrese http://www.openbsd.org/cgi-bin/man.cgi a také ve vašem počítači,pokud jste nainstalovali man52.tgz set.
Pokud znáte jméno příkazu nebo manuálové stránky,tak ji můžete číst po vykonání "man příkaz". Například: "man vi" k přečtení manuálové stránky o editoru vi. okud neznáte jméno příkazu nebo "man příkaz" nenajde manuálovou stránku,tak můžete prohledat databázi manuálových stránek za pomoci "apropos cokoliv" nebo "man -k cokoliv", kde "cokoliv" je slovo,které by mohlo být v titulku manuálové stránky kterou hledáte.Například:
# apropos "time zone" tzfile (5) - time zone information zdump (8) - time zone dumper zic (8) - time zone compiler
Čísla v závorkách indikují číslo sekce manuálových stránek, kde může být tato stránka nalezena.V některých případech můžete najít manuálové stránky se stejným jménem,které jsou ale v různých sekcích manuálových stránek.Dejme tomu,že chcete znát formát konfiguračních souborů pro cron daemona.Jakmile znáte sekci manuálových stránek, kde se nachází to co hledáte,tak můžete použít "man n příkaz", kde n je číslo sekce manuálových stránek.
# man -k cron cron (8) - clock daemon crontab (1) - maintain crontab files for individual users crontab (5) - tables for driving cron # man 5 crontab
Pro většinu z vás může být užitečné mít po ruce fyzickou kopii manuálových stránek. Zde jsou návody, jak vytvořit tisknutelnou kopii manuálové stránky.
Tyto se nalézají v src stromu.Manuálové stránky jsou ve stromu neformátované a často jsou v průběhu použivání CVS aktualizované. K zobrazení těchto stránek jednoduše použijte:
# mandoc <file> | more
Toto je užitečné pro získání čisté stránky bez netisknutelných
znaků.
Například:
# man <command> | col -b
Nezapomeňte, že <file> musí být zdrojový soubor manuálové stránky (pravděpodobně soubor, který končí číslem, např. tcpdump.8). PostScript verze manuálových stránek vypadají velmi pěkně.Mohou být vytištěny nebo zobrazeny na obrazovce s programem jako je například gv (GhostView). GhostView můžete nalézt v naší kolekci balíčků. Použijte následující mandoc(1) příkaz aby jste získali PostScript verzi z OpenBSD systémové manuálové stránky:
# mandoc -Tps <file> > outfile.ps
Pro lidi, kteří sestavují jejich systém ze zdrojů je zde několik možností jak mohou být manuálové stránky vytvořeny.Tyto volby mohou být uloženy do /etc/mk.conf (může být potřeba vytvořit tento soubor) a jsou přiloženy v průběhu sestavování systému. Jedna velmi užitečná volba je vytvoření komprimovaných manuálových stránek,jejímž efektem je úspora místa na disku.Tyto stránky mohou být zobrazeny normálním způsobem pomocí příkazu man.Pokud tuto volbu chcete použít,tak přidejte následující řádek do /etc/mk.conf:
Další užitečnou volbou je nechat systém generovat manuálové stránky v PostScript i ASCII formátu.Toto provedete nastavením volby MANPS=yes v /etc/mk.conf. Přečtěte si mk.conf(5) pro více detailů.MANZ=yes
Některá dokumentace pro OpenBSD je ve formátu info souborů, které jsou většinou umístěny v /usr/share/info. Toto je alternativní forma dokumentace poskytována GNU.Mnoho z těchto souborů je více aktuálních než manuálové stránky poskytované GNU a může k nim být přistupováno pomocí příkazu info(1) . Například pro zobrazení informací o GNU compileru, gcc(1), napište :
Po použití info doceníte a velmi si oblíbíte naše manuálové stránky!# info gcc
Standardní konfigurační soubor pro xterm(1) neumožňuje zobrazení barevných manuálových stránek.V případě,že je barevné chcete,tak zkopírujte soubor /etc/X11/app-defaults/XTerm-color do vašeho domovského adresáře a přejmenujte jej na ".Xdefaults". Buďte opatrní,aby jste nepřepsali nějaké současné nastavení v ".Xdefaults". Tento soubor obsahuje všechny nastavení,která potřebujete pro zapnutí barev v XTermu.Je ale třeba odkomentovat tři řádky než to bude fungovat:
Zbytek tohoto souboru vám umožňuje vybrat barvy pro různá nastavení. Jedno z nich související s manuálovými stránkami je:!*VT100*colorULMode: on !*VT100*underLine: off !*VT100*colorBDMode: on
Toto vytváří docela pekelný vzhled manuálových stránek, takže si nastavení upravte dle potřeby: můžeme doporučit red pro "colorUL" a magenta pro "colorBD"? Je zde také dostupný zobrazovač manuálových stránek pro X11, xman(1), který poskutuje alternativní (grafické) rozhraní pro manuálové stránky. Pročtěte si manuálové stránky pro xterm a xman pro více informací.*VT100*colorUL: yellow *VT100*colorBD: white
Pokud si přejete napsat manuálovou stránku pro vámi vytvořenou aplikaci, tak je zde užitečná referenčí příručka v mdoc(7).
A nakonec,než zašlete bug report,tak si přečtěte http://www.openbsd.org/report.html.
Správný bug report je jedna z nejdůležitějších povinností koncových uživatelů.Pro většinu opravdových chyb jsou důležité velmi detailni informace k jejich zkoumání.Vývojáři často dostávají mailem bug reporty jako je tento:
From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! I have a PC and it won't boot!!!!! It's a 486!!!!! |
Doufáme,že většina lidí chápe,proč takové reporty mažeme.Všechny bug reporty by měli obsahovat detailní informace.Pokud Joe User chce, aby mu někdo s tímto bugem pomohl, tak on nebo ona by měli přiložit více informací...něco jako toto:
From: smartuser@example.com
To: bugs@openbsd.org
Subject: 3.3-beta panics on a SPARCStation2
OpenBSD 3.2 installed from an official CD-ROM installed and ran fine
on this machine.
After doing a clean install of 3.3-beta from an FTP mirror, I find the
system randomly panics after a period of use, and predictably and
quickly when starting X.
This is the dmesg output:
OpenBSD 3.3-beta (GENERIC) #9: Mon Mar 17 12:37:18 MST 2003
deraadt@sparc.openbsd.org:/usr/src/sys/arch/sparc/compile/GENERIC
real mem = 67002368
avail mem = 59125760
using 200 buffers containing 3346432 bytes of memory
bootpath: /sbus@1,f8000000/esp@0,800000/sd@1,0
mainbus0 (root): SUNW,Sun 4/75
cpu0 at mainbus0: CY7C601 @ 40 MHz, TMS390C602A FPU; cache chip bug
- trap page uncached
cpu0: 64K byte write-through, 32 bytes/line, hw flush cache enabled
memreg0 at mainbus0 ioaddr 0xf4000000
clock0 at mainbus0 ioaddr 0xf2000000: mk48t02 (eeprom)
timer0 at mainbus0 ioaddr 0xf3000000 delay constant 17
auxreg0 at mainbus0 ioaddr 0xf7400003
zs0 at mainbus0 ioaddr 0xf1000000 pri 12, softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at mainbus0 ioaddr 0xf0000000 pri 12, softpri 6
zskbd0 at zs1 channel 0: reset timeout
zskbd0: no keyboard
zstty2 at zs1 channel 1: mouse
audioamd0 at mainbus0 ioaddr 0xf7201000 pri 13, softpri 4
audio0 at audioamd0
sbus0 at mainbus0 ioaddr 0xf8000000: clock = 20 MHz
dma0 at sbus0 slot 0 offset 0x400000: rev 1+
esp0 at sbus0 slot 0 offset 0x800000 pri 3: ESP100A, 25MHz, SCSI ID 7
scsibus0 at esp0: 8 targets
sd0 at scsibus0 targ 1 lun 0: <SEAGATE, ST1480 SUN0424, 8628> SCSI2 0/direct fixed
sd0: 411MB, 1476 cyl, 9 head, 63 sec, 512 bytes/sec, 843284 sec total
sd1 at scsibus0 targ 3 lun 0: <COMPAQPC, DCAS-32160, S65A> SCSI2 0/direct fixed
sd1: 2006MB, 8188 cyl, 3 head, 167 sec, 512 bytes/sec, 4110000 sec total
le0 at sbus0 slot 0 offset 0xc00000 pri 5: address 08:00:20:13:10:b9
le0: 16 receive buffers, 4 transmit buffers
cgsix0 at sbus0 slot 1 offset 0x0: SUNW,501-2325, 1152x900, rev 11
wsdisplay0 at cgsix0
wsdisplay0: screen 0 added (std, sun emulation)
fdc0 at mainbus0 ioaddr 0xf7200000 pri 11, softpri 4: chip 82072
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
root on sd0a
rootdev=0x700 rrootdev=0x1100 rawdev=0x1102
This is the panic I got when attempting to start X:
panic: pool_get(mclpl): free list modified: magic=78746572; page 0xfaa93000;
item addr 0xfaa93000
Stopped at Debugger+0x4: jmpl [%o7 + 0x8], %g0
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb> trace
pool_get(0xfaa93000, 0x22, 0x0, 0x1000, 0x102, 0x0) at pool_get+0x2c0
sosend(0x16, 0xf828d800, 0x0, 0xf83b0900, 0x0, 0x0) at sosend+0x608
soo_write(0xfac0bf50, 0xfac0bf70, 0xfac9be28, 0xfab93190, 0xf8078f24, 0x0)
at soo_write+0x18
dofilewritev(0x0, 0xc, 0xfac0bf50, 0xf7fff198, 0x1, 0xfac0bf70) at
dofilewritev+0x12c
sys_writev(0xfac87508, 0xfac9bf28, 0xfac9bf20, 0xf80765c8, 0x1000, 0xfac0bf70)
at sys_writev+0x50
syscall(0x79, 0xfac9bfb0, 0x0, 0x154, 0xfcffffff, 0xf829dea0) at syscall+0x220
slowtrap(0xc, 0xf7fff198, 0x1, 0x154, 0x1, 0xfac87508) at slowtrap+0x1d8
ddb> ps
PID PPID PGRP UID S FLAGS WAIT COMMAND
27765 8819 29550 0 3 0x86 netio xconsole
1668 29550 29550 0 3 0x4086 poll fvwm
15447 29550 29550 0 3 0x44186 poll xterm
8819 29550 29550 35 3 0x4186 poll xconsole
1238 29550 29550 0 3 0x4086 poll xclock
29550 25616 29550 0 3 0x4086 pause sh
1024 25523 25523 0 3 0x40184 netio XFree86
*25523 25616 25523 35 2 0x44104 XFree86
25616 30876 30876 0 3 0x4086 wait xinit
30876 16977 30876 0 3 0x4086 pause sh
16977 1 16977 0 3 0x4086 ttyin csh
5360 1 5360 0 3 0x84 select cron
14701 1 14701 0 3 0x40184 select sendmail
12617 1 12617 0 3 0x84 select sshd
27515 1 27515 0 3 0x184 select inetd
1904 1 1904 0 2 0x84 syslogd
9125 1 9125 0 3 0x84 poll dhclient
7 0 0 0 3 0x100204 crypto_wa crypto
6 0 0 0 3 0x100204 aiodoned aiodoned
5 0 0 0 3 0x100204 syncer update
4 0 0 0 3 0x100204 cleaner cleaner
3 0 0 0 3 0x100204 reaper reaper
2 0 0 0 3 0x100204 pgdaemon pagedaemon
1 0 1 0 3 0x4084 wait init
0 -1 0 0 3 0x80204 scheduler swapper
Thank you!
|
Přečtěte si report.html pro více informací o vytváření a odesílání bug reportů.Detailní informace o vašem hardware jsou potřebné pokud si myslíte, že chyba by mohla nějákým způsobem souviset s vaším hardware nebo jeho konfigurací.Obvykle je výstup z dmesg(8) dostačující. Detailní popis Vašeho problému je nutný.Jak jste viděli, tak dmesg popsal hardware a text vysvětlil,proč si Smart User myslí,že jeho systém nebyl poškozen (běžel zde 3.2 v pořádku), jak se tento pád objevil (spouštění X) a obsahoval výstup z příkazů "ps" a "trace" debuggeru.V tomto případě Smart User přiložil výstup zachycený na serial konzoli; Pokud toto nemůžete udělat, tak budete muset použít papír a tužku k zapsání pádu. (Toto byl skutečný problém a informace ve výše vypsaném reportu pomohli k opravě tohoto chování,které se týkalo Sun4c systémů).
Pokud by měl chytrý uživatel fungující OpenBSD systém, tak by mohl zaslat bug report z něj a použít k tomu utilitu sendbug(1) k zařazení do systému GNATS. Samozřejmě,že nemůžete použít sendbug(1) , když váš systém nenabíhá,ale můžete jej použít kdykoliv to je možné. Stále ale budete potřebovat přiložit detailní informace o tom, co se stalo, přesnou konfiguraci Vašeho systému a jak problém zopakovat. Příkaz sendbug(1) vyžaduje,aby váš systém byl schopný posílat elektronickou poštu do Internetu.Uvědomte si,že mail server používá spamd(8) založené na greylistingu a tak může trvat i půl hodiny nebo více, než server akceptuje Váš bug report.Buďte proto prosím trpěliví.
Po odeslání bug reportu pomocí sendbug(1) můžete být kontaktováni vývojáři se žádostí o další informace nebo Vám poskytnou patch k otestování. Můžete také sledovat archívy bugs@openbsd.org , detaily jsou na stránce mailing listů.
Ztratili jste "Panic message"?
V některých případech můžete přijít o úplně první zprávu "panic message",
která popisuje důvod pro panic.Toto je velmi důležitá zpráva,takže by
jste ji měli v reportu také mít.Můžete jí znovu získat za pomoci
příkazu "show panic" v ddb> nějak takto:
ddb> show panic 0: kernel: page fault trap, code=0 ddb> |
V tomto případě,byl řetězec pro panic "Kernel: page fault trap, code=0"
Poznámka speciálně pro SMP systémy:
Můžete získat "trace" pro každý z procesorů jako součást vašeho
reportu:
ddb{0}> trace
pool_get(d05e7c20,0,dab19ef8,d0169414,80) at pool_get+0x226
fxp_add_rfabuf(d0a62000,d3c12b00,dab19f10,dab19f10) at fxp_add_rfabuf+0xa5
fxp_intr(d0a62000) at fxp_intr+0x1e7
Xintr_ioapic0() at Xintr_ioapic0+0x6d
--- interrupt ---
idle_loop+0x21:
ddb{0}> machine ddbcpu 1
Stopped at Debugger+0x4: leave
ddb{1}> trace
Debugger(d0319e28,d05ff5a0,dab1bee8,d031cc6e,d0a61800) at Debugger+0x4
i386_ipi_db(d0a61800,d05ff5a0,dab1bef8,d01eb997) at i386_ipi_db+0xb
i386_ipi_handler(b0,d05f0058,dab10010,d01d0010,dab10010) at i386_ipi_handler+0x
4a
Xintripi() at Xintripi+0x47
--- interrupt ---
i386_softintlock(0,58,dab10010,dab10010,d01e0010) at i386_softintlock+0x37
Xintrltimer() at Xintrltimer+0x47
--- interrupt ---
idle_loop+0x21:
ddb{1}>
|
Opakujte "machine ddbcpu x" následované "trace" pro každý z procesorů na vašem počítači.
Typická havárie jádra na OpenBSD může vypadat např. takhle: (informace, které jsou důležité jsou tučně)
kernel: page fault trap, code=0 Stopped at _pf_route+0x263: mov 0x40(%edi),%edx ddb> |
První příkaz ke spuštění z ddb> promptu je "trace" (přečtěte si ddb(4) pro detaily):
ddb> trace _pf_route(e28cb7e4,e28bc978,2,1fad,d0b8b120) at _pf_route+0x263 _pf_test(2,1f4ad,e28cb7e4,b4c1) at _pf_test+0x706 _pf_route(e28cbb00,e28bc978,2,d0a65440,d0b8b120) at _pf_route+0x207 _pf_test(2,d0a65440,e28cbb00,d023c282) at _pf_test+0x706 _ip_output(d0b6a200,0,0,0,0) at _ip_output+0xb67 _icmp_send(d0b6a200,0,1,a012) at _icmp_send+0x57 _icmp_reflect(d0b6a200,0,1,0,3) at _icmp_reflect+0x26b _icmp_input(d0b6a200,14,0,0,d0b6a200) at _icmp_input+0x42c _ipv4_input(d0b6a200,e289f140,d0a489e0,e289f140) at _ipv4_input+0x6eb _ipintr(10,10,e289f140,e289f140,e28cbd38) at _ipintr+0x8d Bad frame pointer: 0xe28cbcac ddb> |
To nám říká, které volání funkce vedlo k havárii.
K nalezení přesného řádku v C kódu, který způsobil havári můžete udělat následující:
Najděte zdrojový soubor kde je funkce, která havarovala definována.
V tomto příkladu je to pf_route() v sys/net/pf.c.
Rekompilujte tento zdrojový soubor s podporou debug informací:
# cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC/ # rm pf.o # DEBUG=-g make pf.o |
Poté použijte objdump(1) pro získání disassemblováného výstupu:
# objdump --line --disassemble --reloc pf.o >pf.dis |
Ve výstupu použijte grep na jméno funkce (pf_route v našem příkladu):
# grep "<_pf_route>:" pf.dis 00007d88 <_pf_route>: |
Vemte první hex číslo a přičtěte offset z 'Stopped at' řádku:
0x7d88 + 0x263 == 0x7feb.
Sjeďte na tento řádek
(assembler instrukce má souhlasit s tou zmíněnou na 'Stopped at' řádku),
poté nahoru k nejbližšímu číslu C řádku:
# more pf.dis
/usr/src/sys/arch/i386/compile/GENERIC/../../../../net/pf.c:3872
7fe7: 0f b7 43 02 movzwl 0x2(%ebx),%eax
7feb: 8b 57 40 mov 0x40(%edi),%edx
7fee: 39 d0 cmp %edx,%eax
7ff0: 0f 87 92 00 00 00 ja 8088 <_pf_route+0x300>
|
Takže to je přesně řádek 3872 z pf.c, který zhavaroval:
# cat -n pf.c | head -n 3872 | tail -n 1
3872 if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {
|
Všimněte si, že jádro, které vytvořilo "crash" výstupu a objektový soubor pro objdump musí být zkompilovány z přesně stejného zdrojového souboru, jinak se offsety nebudou shodovat.
Pokud zašlete obojí, jak ddb> trace výstup, tak relevantní objdump sekci, tak to bude velmi užitečné.
[FAQ Index] [Do sekce 1 - Úvod do OpenBSD] [Do sekce 3 - Začínáme s OpenBSD]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org