![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Índice da FAQ] [Seção 1 - Introdução ao OpenBSD] [Seção 3 - Primeiros passos com o OpenBSD]
O sítio Web oficial do projeto OpenBSD está localizado em: http://www.OpenBSD.org.
Muitas informações valiosas, que abordam todos os aspectos do projeto OpenBSD, podem ser encontradas aqui.
O Jornal do OpenBSD é um sítio de notícias e opiniões focado no OpenBSD.
O sítio OpenBSDsupport.org é uma coleção de documentações "mantida por usuários", de qualidade variada, que cobre tópicos que não estão nesta FAQ ou outra documentação oficial.
Muitos usuários criam sítios e páginas com informações específicas sobre o OpenBSD. Como tudo na Internet, uma boa ferramenta de pesquisas facilita sua vida, mas sempre com uma dose saudável de ceticismo. Nunca digite comandos cegamente (sem saber o que eles fazem) no seu computador.
O projeto OpenBSD mantém muitas listas populares de discussão, nas quais usuários podem se inscrever e segui-las. Para se inscrever numa lista de discussão, mande uma mensagem de correio eletrônico para majordomo@openbsd.org. Esse endereço é um serviço de inscrição automático. No corpo da sua mensagem, em uma única linha, você deve incluir um comando de inscrição para a lista que você deseja se juntar. Por exemplo:
subscribe announce
O processador de correio eletrônico da lista vai te responder, perguntando pela confirmação da sua intenção de se juntar à lista, desse modo outros não podem inscrever você e te inundar de mensagens não solicitadas. A mensagem contém instruções sobre os vários meios para confirmar, o que inclui uma página Web com links de servidores de listas, responder a mensagem de confirmação ou responder para majordomo@openbsd.org. Use qualquer método que é conveniente para você. Você notará que todas as três técnicas envolvem um número de identificação único e com tempo limitado, tal como A56D-70D4-52C3, para ter novamente a certeza que você é realmente a pessoa que está requisitando essa inscrição na lista de discussão (esse é um "opt-in" real).
Após ter confirmado sua intenção de se inscrever, você será imediatamente adicionado à lista, e o processador de correio eletrônico irá lhe notificar que você foi adicionado com sucesso.
Para desinscrever-se da lista, você deve novamente enviar uma mensagem de correio eletrônico para majordomo@openbsd.org, com algo parecido com isto:
unsubscribe announce
Se você tiver qualquer dificuldade com o sistema de lista de discussão, por favor, primeiro leia o arquivo de ajuda que pode ser obtido enviando uma mensagem de correio eletrônico para majordomo@openbsd.org com a mensagem de corpo "help".
Sua inscrição nas listas de discussão do OpenBSD também pode ser mantida através da interface Web em http://lists.openbsd.org
Algumas das mais populares listas de discussão do OpenBSD são:
Antes de postar uma pergunta na misc ou em qualquer outra lista de discussão, por favor, verifique os arquivos; as questões mais comuns já foram respondidas repetidamente. Embora possa ser a primeira vez que você encontrou um problema ou uma pergunta, outros nas listas de discussão podem ter visto a mesma pergunta várias vezes na última semana, e não gostam de vê-la novamente. Se você fizer uma pergunta possivelmente referente a hardware, sempre inclua um dmesg(8)!
Você pode encontrar vários arquivos, outros guias de listas de discussão e mais informações na página de listas de discussão.
Uma lista de discussão não-oficial que pode ser de interesse para novos usuários do OpenBSD e Unix é a lista Iniciantes no OpenBSD.
O OpenBSD vem com uma extensa documentação em forma de páginas de manual. Um esforço enorme é feito para ter certeza que as páginas de manual estão atualizadas e precisas. Em todos os casos, as páginas de manual são consideradas fontes de informação confiável do OpenBSD.
Para acessar as páginas de manual, tenha certeza de que instalou os pacotes contidos em man52.tgz.
Esta é uma lista de algumas das mais úteis páginas de manual para novos usuários:
Primeiros passos
Você pode encontrar todas as páginas de manual do OpenBSD na Web, em http://www.openbsd.org/cgi-bin/man.cgi, e também no seu computador, se você instalou o pacote man52.tgz.
Geralmente, se você conhece o nome de um comando ou página de manual, você pode lê-la executando "man comando". Por exemplo: "man vi" para ler sobre o editor vi. Se você não sabe o nome do comando, ou se "man comando" não encontra a página de manual, você pode procurá-la na base de dados, executando "apropos qualquer_coisa" ou "man -k qualquer_coisa", onde "qualquer_coisa" é uma palavra comum que talvez apareça no título da página de manual que você está procurando. Por exemplo:
# apropos "time zone" tzfile (5) - time zone information zdump (8) - time zone dumper zic (8) - time zone compiler
Os números entre parêntesis indicam a seção do manual onde a página se encontra. Em alguns casos, você pode encontrar páginas de manual com nomes idênticos vivendo em seções separadas do manual. Por exemplo, assuma que você quer saber o formato dos arquivos de configuração do "daemon" cron. Após descobrir a seção do manual da página que você quer, você vai executar "man n comando", onde n é o número da seção do manual.
# man -k cron cron (8) - clock daemon crontab (1) - maintain crontab files for individual users crontab (5) - tables for driving cron # man 5 crontab
Para muitos, ter uma cópia em papel da página de manual pode ser útil. Aqui estão algumas dicas para fazer uma cópia imprimível de uma página de manual.
Essas páginas são encontradas na árvore src. As páginas de manual são encontradas na árvore sem um formato, e muitas vezes, através do uso do CVS, elas são atualizadas. Para ver essas páginas, simplesmente digite:
# mandoc <arquivo> | more
Isto é útil para se obter uma página de manual correta, sem caracteres
não-imprimíveis.
Exemplo:
# man <comando> | col -b
Note que <arquivo> precisa ser o arquivo fonte da página de manual (provavelmente um arquivo que termina em um número; por exemplo, tcpdump.8). A versão em PostScript da página de manual tem uma aparência muito boa. Eles podem ser imprimidos ou visualizados na tela com um programa como gv (GhostView). O GhostView pode ser encontrado em nossa coleção de pacotes. Use as seguintes opções do comando mandoc(1) para obter a versão PostScript de uma página de manual do OpenBSD:
# mandoc <arquivo> > arquivo_de_saída.ps
Para as pessoas que estão construindo seu sistema a partir do código fonte, existem várias opções relativas ao modo que as páginas de manual são construídas. Essas opções podem ser colocadas em /etc/mk.conf (pode ser necessário criar esse arquivo) e são usadas durante a construção do sistema. Uma opção especialmente útil é gerar páginas de manual comprimidas para economizar espaço em disco. Estas podem ser visualizadas normalmente, usando o comando man. Para configurar isso, adicione em /etc/mk.conf o seguinte:
Outra opção útil permite gerar páginas de manual no formato PostScript, como também em texto ASCII. Isso é feito definindo a opção MANPS=yes no /etc/mk.conf. Veja mais detalhes em mk.conf(5).MANZ=yes
Algumas das documentações do OpenBSD vêm na forma de arquivos info, tipicamente armazenados em /usr/share/info. Essa é uma forma alternativa de documentação fornecida pelo projeto GNU. Muitos desses arquivos são mais atualizados que as páginas de manual fornecidas pelo projeto GNU, e podem ser acessados com o comando info(1). Por exemplo, para ver informações sobre o compilador GNU, gcc(1), digite:
Depois de usar o info, você irá realmente apreciar nossas páginas de manual!# info gcc
O arquivo de configuração padrão para o xterm(1) não mostra páginas de manual coloridas. Para obter uma saída colorida, copie o arquivo /etc/X11/app-defaults/XTerm-color para o seu diretório home, e o renomeie para ".Xdefaults". Tome cuidado para não sobrescrever alguma configuração atual no ".Xdefaults". Esse arquivo contém todas as configurações que você precisa para ativar as cores no XTerm. No entanto, três linhas precisam ser descomentadas para isso funcionar:
O resto desse arquivo permite que você escolha cores para várias configurações. As únicas relevantes às páginas de manual são:!*VT100*colorULMode: on !*VT100*underLine: off !*VT100*colorBDMode: on
Isso gera uma aparência terrível nas páginas de manual, então personalize o quanto for necessário: nós podemos sugestionar vermelho para "colorUL" e magenta para "colorBD"? Existe também um visualizador de páginas de manual para o X11, xman(1), o qual providencia uma interface alternativa (gráfica) para as páginas de manual. Veja as páginas de manual do xterm e xman para mais informações.*VT100*colorUL: yellow *VT100*colorBD: white
Se você deseja escrever sua própria página de manual para um aplicativo que você escreveu, existe um guia de referência útil em mdoc(7).
Finalmente, antes de submeter qualquer relato de falha, por favor leia http://www.openbsd.org/report.html.
Um relato apropriado sobre uma falha é uma das mais importantes responsabilidades dos usuários finais. Uma informação detalhada é requerida para diagnosticar a maioria das falhas sérias. Desenvolvedores frequentemente recebem, via correio eletrônico, relatos de falhas como este:
From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! I have a PC and it won't boot!!!!! It's a 486!!!!! |
Felizmente, a maioria das pessoas entende que tais relatos são sumariamente excluídos. Todos os relatos de falhas devem conter informações detalhadas. Se Joe User estivesse realmente esperando alguém para ajudá-lo a encontrar essa falha, ele ou ela deveria fornecer mais informações... algo como isto:
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!
|
Veja em report.html mais informações sobre criação e submissão de relatos de falha. Informações detalhadas sobre seu hardware são necessárias se você acha que a falha pode estar de algum modo relacionado ao seu hardware ou à configuração dele. Normalmente, a saída do dmesg(8) é suficiente nesse respeito. Uma descrição detalhada do seu problema é necessária. Você irá notar que o dmesg descreve o hardware, o texto explica o porquê que Smart User pensa que o seu sistema não está defeituoso (a versão 3.2 funciona corretamente), como esse travamento foi causado (iniciando o X), e a saída dos comandos "ps" e "trace" do depurador. Nesse caso, Smart User providenciou a saída capturada em um console serial; se você não pode fazer isso, você vai ter que usar papel e caneta para escrever a mensagem de travamento. (Esse foi um problema real, a informação no relato acima ajudou a levar à correção desse problema que afetava sistemas Sun4c.)
Se Smart User tivesse um sistema OpenBSD funcionando, a partir do qual ele submeteria um relato de falha, ele deveria usar o utilitário sendbug(1) para submeter esse relato de falha ao GNATS, o sistema de rastreamento de falhas. Obviamente, você não pode usar o sendbug(1) quando seu sistema não inicia, mas você deve usar ele sempre que for possível. Você vai precisar incluir informação detalhada sobre o que aconteceu, a configuração exata do seu sistema, e como reproduzir o problema. O comando sendbug(1) requer que seu sistema esteja configurado para enviar correio eletrônico corretamente na Internet. Note que o servidor de mensagem usa spamd(8) baseado em "greylisting", então pode levar meia ou uma hora até que o servidor de mensagem aceite seu relato de falha, então por favor seja paciente.
Depois de submeter um relato de falha via sendbug(1), você pode ser contatado por desenvolvedores que precisam de informações adicionais ou com correções que precisam de testes. Você também pode monitorar os arquivos da lista de discussão bugs@openbsd.org, detalhes na página de listas de discussão.
Perdeu a "Panic message"?
Sob certas circunstâncias, você pode perder a primeira mensagem de
pânico, determinando a razão para o pânico.
Essa é uma mensagem muito importante, então você precisa relatá-la
também.
Você pode obter isso novamente, usando o comando "show panic" no ddb>,
algo como isto:
ddb> show panic 0: kernel: page fault trap, code=0 ddb> |
Nesse caso, a frase de pânico foi "Kernel: page fault trap, code=0"
Nota especial para sistemas SMP:
Você deve obter um "trace" de cada processador como parte do seu relato:
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}>
|
Repita o "machine ddbcpu x" seguido por "trace" para cada processador em sua máquina.
Um típico travamento de kernel pode se parecer com isto: (as coisas para serem olhadas estão marcadas com a fonte em negrito)
kernel: page fault trap, code=0 Stopped at _pf_route+0x263: mov 0x40(%edi),%edx ddb> |
O primeiro comando para ser executado a partir do prompt ddb> é o "trace" (veja mais detalhes em ddb(4)):
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> |
Isso nos diz qual chamada de função levou ao travamento.
Para encontrar a linha específica de código fonte na linguagem C
que causou o travamento, você pode fazer o seguinte:
Encontre o arquivo de código fonte onde a função que causou o travamento
está definida.
Neste exemplo, ela seria pf_route() em sys/net/pf.c.
Recompile este arquivo de código fonte com informações de depuração:
# cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC/ # rm pf.o # DEBUG=-g make pf.o |
Então utilize o objdump(1) para obter o objeto desmontado:
# objdump --line --disassemble --reloc pf.o >pf.dis |
Na saída, utilize o grep para encontrar o nome da função (pf_route, no nosso exemplo):
# grep "<_pf_route>:" pf.dis 00007d88 <_pf_route>: |
Pegue esse primeiro número hexadecimal e adicione o "offset" da linha
'Stopped at':
0x7d88 + 0x263 == 0x7feb.
Role para baixo até aquela linha (a instrução do montador deve
corresponder àquela delimitada na linha 'Stopped at'), então levante
até o número de linha mais próximo do código fonte na linguagem C:
# 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>
|
Portanto, é precisamente a linha 3872 do pf.c que causa o travamento:
# cat -n pf.c | head -n 3872 | tail -n 1
3872 if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {
|
Note que o kernel que produziu a saída do travamento e o arquivo objeto para o objdump devem ser compilados a partir do mesmo arquivo de código fonte, caso contrário os offsets não corresponder-se-ão.
Se você fornecer a saída do trace do ddb> e a seção relevante do objdump, isso será muito útil no relato da falha.
[Índice da FAQ] [Seção 1 - Introdução ao OpenBSD] [Seção 3 - Primeiros passos com o OpenBSD]
![[voltar]](../../images/back.gif){kind=small}
www@openbsd.org