[Index de la FAQ] [Section 1 - Introduction à OpenBSD] [Section 3 - Démarrer avec OpenBSD]

2 - Apprendre à connaître OpenBSD

Table des matières

• 2.1 - Pages Web intéressantes
• 2.2 - Listes de discussion
• 2.3 - Pages de manuel
• 2.4 - Rapporter des bogues

2.1 - Pages Web intéressantes

Le site officiel pour le projet OpenBSD se trouve à l'adresse : http://www.OpenBSD.org.

Beaucoup d'informations utiles s'y trouvent en ce qui concerne tous les aspects du projet OpenBSD.

L'OpenBSD Journal est un site de nouvelles et d'opinions autour d'OpenBSD.

OpenBSDsupport.org regroupe de la documentation maintenue par des utilisateurs et de qualité variable, mais qui a le mérite de couvrir des sujets ne faisant pas partie de la présente FAQ ou de toute autre documentation officielle.

Plusieurs utilisateurs ont mis en place des sites et des pages avec des informations spécifiques à OpenBSD. Un bon moteur de recherche vous facilitera la vie, comme le fera aussi une dose raisonnable de scepticisme. Comme d'habitude, n'utilisez pas aveuglément des commandes que vous ne comprenez pas.

2.2 - Listes de discussion

Le projet OpenBSD maintient plusieurs listes de discussion auxquelles les utilisateurs peuvent s'inscrire. Pour s'inscrire à une liste, il suffit d'envoyer un message à majordomo@openbsd.org. Cette adresse correspond à un service d'inscription automatique. Dans le corps du message, sur une seule ligne, vous devez inclure une commande d'inscription pour la liste désirée. Par exemple :

subscribe announce

Le gestionnaire automatique de la liste vous répondra, pour obtenir une confirmation de votre part afin que d'autres personnes ne vous inscrivent pas à une avalanche de courriel non sollicité. Le message contiendra des instructions sur différentes méthodes de confirmation, y compris un lien vers la page web du serveur de listes, la réponse au message de confirmation ou la réponse à majordomo@openbsd.org. Utilisez la méthode qui vous convient. Il est à noter que les trois techniques précitées impliquent un identifiant unique et limité dans le temps, tel que A56D-70D4-52C3, encore une fois pour s'assurer que vous êtes réellement la personne qui a demandé l'inscription à la liste de diffusion (c'est le vrai "opt-in").

Une fois que vous avez confirmé votre intention de vous joindre à la liste, vous serez immédiatement ajouté à celle-ci, et le service vous l'indiquera.

Pour se désabonner d'une liste, il vous faut encore envoyer un message à majordomo@openbsd.org. Cela ressemblera à :

unsubscribe announce

Si vous avez des difficultés avec le système des listes de discussion, veuillez d'abord lire le fichier d'aide qui peut être obtenu en envoyant un message à majordomo@openbsd.org avec dans le corps de celui-ci : "help".

Votre inscription aux listes de diffusion OpenBSD peut aussi être maintenue à travers l'interface Web disponible à l'adresse http://lists.openbsd.org

Parmi les listes de discussions les plus populaires, on peut citer :

• announce - Annonces importantes. Il s'agit d'une liste à faible débit.
• security-announce - Annonces des problèmes de sécurité. Il s'agit d'une liste à faible débit.
• misc - Questions et réponses générales d'utilisateurs. C'est la liste la plus active et elle devrait être la liste par "défaut" pour la plupart des questions.
• bugs - Bogues reçus par l'intermédiaire de sendbug(1) et discussions à leur sujet.
• source-changes - Liste recevant automatiquement les modifications apportées à l'arbre des sources CVS. Dès qu'un développeur modifie ("commit") l'arbre des sources d'OpenBSD, CVS envoie une copie (généralement brève) de son message "commit" à cette liste.
• ports - Discussions à propos de l'arbre des ports OpenBSD.
• ports-changes - Liste recevant automatiquement les modifications apportées à l'arbre des sources CVS qui concernent les ports.
• advocacy - Discussions sur la promotion d'OpenBSD et les messages hors-sujet dans misc...

Avant d'envoyer une question à misc ou toute autre liste de diffusion, parcourez les archives, pour y voir les questions fréquemment posées. Bien que cela puisse être la première fois que vous rencontrez un problème ou que vous avez une question, les autres participants de la liste peuvent avoir vu la même question plusieurs fois en plusieurs semaines et peuvent ne pas apprécier de la voir, une fois encore. Si votre question concerne du matériel, envoyez toujours un dmesg(8) !

Vous pouvez consulter plusieurs archives, d'autres lignes de conduite relatives aux listes de diffusion ainsi que d'autres informations dans la page des listes de diffusion.

Une liste de diffusion non officielle qui pourrait intéresser les nouveaux utilisateurs d'OpenBSD et d'Unix est la liste appelée OpenBSD Newbies.

2.3 - Pages de manuel

OpenBSD est fourni avec une abondante documentation sous la forme de pages de manuel. Un effort considérable est fourni pour s'assurer que les pages de manuel sont à jour et correctes. Dans tous les cas, celles-ci sont à considérer comme la source faisant autorité concernant les informations sur OpenBSD.

Pour accéder aux pages du man, assurez-vous d'avoir installé le tarball man52.tgz et de l'ensemble des fichiers.

Voici une liste des pages de manuel les plus utiles pour les nouveaux utilisateurs :

Débutants

• afterboot(8) - les choses à vérifier après le premier redémarrage complet.
• help(1) - aide pour les nouveaux utilisateurs et administrateurs.
• hier(7) - agencement des systèmes de fichiers.
• man(1) - affiche les pages de manuel.
• intro(1) - introduction aux commandes générales, voir aussi les introductions aux autres sections de manuel : intro(2), intro(3), intro(4) (remarque : intro(4) est spécifique à chaque plate-forme), intro(5), intro(6), intro(7), intro(8) et intro(9).
• adduser(8) - commande pour ajouter de nouveaux utilisateurs.
• vipw(8) - édite le fichier de mots de passe principal.
• disklabel(8) - lecture et écriture du disklabel.
• reboot, halt(8) - arrêt et redémarrage du système.
• shutdown(8) - arrêt du système à un temps donné.
• dmesg(8) - réaffichage des messages de démarrage du noyau.
• sudo(8) - exécuter des commandes en root mais sans se loguer en root.
• mg(1) - éditeur de texte fonctionnant comme emacs.

• boot(8) - procédures de bootstrapping système.
• boot_config(8) - comment changer la configuration du noyau au boot.
• gcc-local(1) - modifications spécifiques à OpenBSD pour gcc(1).
• ifconfig(8) - configure les paramètres de l'interface réseau.
• login.conf(5) - format du fichier de configuration des classes de connexion.
• netstat(1) - affiche le statut du réseau.
• release(8) - compile et prépare une distribution OpenBSD.
• sendbug(1) - envoi d'un rapport de bogues (PR) sur OpenBSD à un site central.
• style(9) - guide de style pour le code source du noyau OpenBSD.
• sysctl(8) - obtenir ou paramétrer des états noyau.

Vous pouvez trouver toutes les pages de manuel OpenBSD sur le web à l'adresse http://www.openbsd.org/cgi-bin/man.cgi ainsi que sur votre ordinateur si vous installez l'archive de fichiers man52.tgz.

En général, si vous connaissez le nom d'une commande ou d'une page de manuel, vous pouvez la lire en tapant "man commande". Par exemple : "man vi" pour obtenir la page de manuel de l'éditeur vi. Si vous ne connaissez pas le nom d'une commande ou si "man commande" ne trouve pas la page de manuel vous pouvez chercher dans la base de données des pages de manuel en tapant `apropos quelque_chose' ou "man -k quelque_chose", où "quelque_chose" est une expression qui a des chances d'apparaître dans le titre de la page de manuel que vous recherchez. Par exemple :

# apropos "time zone"
tzfile (5) - time zone information
zdump (8) - time zone dumper
zic (8) - time zone compiler

Le numéro entre parenthèses indique la section de manuel dans laquelle cette page a été trouvée. Dans certains cas, vous pourrez trouver des pages de manuel avec des noms identiques dans différentes sections du manuel. Par exemple, supposons que vous souhaitiez connaître le format des fichiers de configuration du service cron. Une fois que vous connaissez la section de manuel pour la page que vous recherchez, tapez "man n commande", où n est le numéro de la section correspondante.

# man -k cron
cron (8) - clock daemon 
crontab (1) - maintain crontab files for individual users
crontab (5) - tables for driving cron
# man 5 crontab

Il est utile pour bon nombre de personnes de disposer d'une version papier d'une page de manuel. Voici les indications pour obtenir une version imprimable d'une page de manuel.

Comment est-ce que j'affiche le code source d'une page de manuel (par exemple, un de ces fichiers finissant par un numéro, comme tcpdump.8) ?

On les trouve dans les sources. Les pages de manuel non formatées se trouvent dans les sources et elles seront souvent mises à jour par l'utilisation de CVS. Pour les visualiser, il faut juste taper :

# mandoc <file> | more

Comment est-ce que j'obtiens une page de manuel sans caractères de contrôle ou de formatage ?

Il est utile d'obtenir une page de manuel sans caractères non imprimables.
Exemple :

# man <command> | col -b

Comment puis-je obtenir une copie PostScript d'une page de manuel ?

Remarquez que <file> doit être le fichier source de la page de manuel (certainement un fichier finissant par un numéro comme tcpdump.8). Les versions PostScript des pages de manuel ont une belle apparence. Elles peuvent être imprimées ou visualisées à l'aide d'un programme comme gv (GhostView). GhostView est disponible dans notre collection de Paquetages. Utilisez les options suivantes de la commande mandoc(1) pour obtenir une version PostScript à partir d'une page de manuel système d'OpenBSD :

# mandoc -Tps <file> > outfile.ps

Comment générer des copies compressées des pages de manuel ?

Pour les personnes qui compilent leur système à partir des sources, il existe un certain nombre d'options permettant de contrôler la manière dont les pages de manuel sont construites. Ces options figurent dans /etc/mk.conf (il peut être nécessaire de créer ce fichier) et sont incluses durant les compilations système. Une option particulièrement utile permet de générer des pages de manuel compressées pour économiser de l'espace disque. Celles-ci peuvent être consultées de la manière habituelle avec la commande man. Pour cela, ajoutez la ligne suivante à /etc/mk.conf :

MANZ=yes

Que sont les fichiers info ?

Une partie de la documentation d'OpenBSD est sous la forme de fichiers info. Ces fichiers se trouvent typiquement sous /usr/share/info. C'est une forme de documentation alternative fournie par GNU. Plusieurs fichiers info sont plus à jour que les pages de manuel fournis par GNU et peuvent être visualisés à l'aide de la commande info(1). Par exemple, pour voir les informations sur le compilateur GNU, gcc(1), tapez :

# info gcc

Comment afficher les pages de manuel en couleur dans un XTerm ?

Le fichier de configuration par défaut de xterm(1) n'affiche pas les pages de manuel en couleur. Afin d'avoir un affichage couleur, copiez le fichier /etc/X11/app-defaults/XTerm-color dans votre répertoire personnel et renommez-le en ".Xdefaults". Veillez à ne pas écraser un paramétrage particulier dans ".Xdefaults". Ce fichier contient tous les paramètres dont vous aurez besoin pour activer les couleurs sous XTerm. Cependant, trois lignes doivent être décommentées auparavant :

!*VT100*colorULMode: on
!*VT100*underLine: off
!*VT100*colorBDMode: on

*VT100*colorUL: yellow
*VT100*colorBD: white

Comment écrire ma propre page de manuel ?

Si vous souhaitez écrire votre propre page de manuel pour une application que vous avez écrite, il existe aussi un guide de référence bien pratique dans mdoc(7).

2.4 - Rapporter des bogues

Finalement, avant de soumettre un rapport de bogue, merci de lire http://www.openbsd.org/fr/report.html .

Faire un rapport de bogue correct est l'une des plus grandes responsabilités conférée aux utilisateurs. Des informations très détaillées sont nécessaires pour diagnostiquer les bogues les plus sérieux. Les développeurs reçoivent fréquemment des rapports de bogues par mail du style :

From: joeuser@example.com To: bugs@openbsd.org Subject: HELP!!! I have a PC and it won't boot!!!!! It's a 486!!!!!

Heureusement la plupart des gens savent que de tels rapports sont rapidement effacés. Tous les rapports de bogues doivent contenir des informations détaillées. Si Joe User souhaite que son bogue soit corrigé, il faudrait que son rapport ressemble à ça :

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!

Consultez report.html concernant la manière de créer et d'envoyer des rapports des bogues. Des informations détaillées à propos de votre matériel sont nécessaires si vous pensez que le bogue peut être, de quelque manière que ce soit, lié à votre matériel ou à sa configuration. Habituellement, un dmesg(8) est suffisant. Une description détaillée de votre problème est nécessaire. Vous remarquerez que le dmesg décrit le matériel, le texte explique pourquoi Smart User pense que son système n'est pas défectueux (3.2 fonctionnait convenablement), comment ce "crash" était causé (en démarrant X), et inclut le détail des commandes "ps" et "trace" afin de permettre aux développeurs de déboguer. Dans ce cas, Smart User a fourni ces détails capturés via une console série, si vous ne savez pas le faire, vous pouvez utiliser une feuille et un stylo afin de retranscrire le "crash". (L'exemple ci-dessus était un problème réel qui affectait les systèmes sun4c, et les informations fournies dans le précédant rapport ont aidé à le résoudre).

Si notre ami Smart User possède un système OpenBSD fonctionnel et qu'il veut soumettre un rapport de bogue, il peut le faire en utilisant l'utilitaire sendbug(1) qui enverra le rapport au système de suivi des bogues GNATS. Évidemment, vous ne pouvez utiliser sendbug(1) si votre système ne démarre pas mais utilisez-le dès que c'est possible. Vous aurez toujours à inclure des informations détaillées sur ce qui s'est passé, la configuration de votre système et comment reproduire le problème. La commande sendbug(1) nécessite que votre système puisse envoyer des messages électroniques sur l'Internet. Notez que le serveur de messagerie utilise la fonctionnalité "greylisting" de spamd(8). Il peut alors s'écouler jusqu'à une demi-heure avant que le serveur de messagerie n'accepte votre rapport. Soyez donc patient.

Après avoir envoyé un rapport de bogue via sendbug(1), vous pourrez être contacté par les développeurs pour fournir de plus amples informations ou tester des correctifs. Vous pouvez également consulter les archives de la liste de diffusion bugs@openbsd.org, de plus amples informations se trouvant sur la page des listes de discussion.

Comment fournir plus d'informations utiles aux développeurs ?

Vous avez perdu le "Panic message" ?
Dans certaines conditions, vous pouvez perdre le tout premier message d'une panique système, et il s'agit de celui qui donne la raison de la panique. Ce message est très important, vous devez donc l'inclure dans votre rapport. Vous pouvez le retrouver en utilisant la commande "show panic" dans ddb> comme suit :

ddb> show panic 0: kernel: page fault trap, code=0 ddb>

Dans ce cas, le message était "Kernel: page fault trap, code=0".

Remarque pour les systèmes SMP :
Vous devez obtenir une "trace" pour chaque processeur et les insérer dans votre rapport :

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

Répétez la commande "machine ddbcpu x" suivie de "trace" pour chaque processeur de votre machine.

Comment récupérer des informations d'un crash du noyau ?

Un crash du noyau typique sur OpenBSD ressemble à cela : (les choses à regarder sont en gras dans le texte)

kernel: page fault trap, code=0 Stopped at _pf_route+0x263: mov 0x40(%edi),%edx ddb>

La première commande à exécuter du prompt ddb> est "trace" (voir ddb(4) pour plus de détails):

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>

Cela nous informe de la fonction qui nous a conduit au crash.

Pour retrouver précisément la ligne de code C qui a causé le crash, vous pouvez faire les choses suivantes :
Trouvez le fichier source où la fonction qui a crashé a été définie. Dans cet exemple, cela doit être pf_route() dans sys/net/pf.c. Recompilez le fichier source avec les informations de débogage :

# cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC/ # rm pf.o # DEBUG=-g make pf.o

Puis utilisez objdump(1) pour avoir le désassemblage :

# objdump --line --disassemble --reloc pf.o >pf.dis

Sur la sortie, un grep sur le nom de la fonction (pf_route dans notre exemple) :

# grep "<_pf_route>:" pf.dis 00007d88 <_pf_route>:

Prenez le premier nombre hexadécimal et ajoutez l'offset de la ligne 'Stopped at' : 0x7d88 + 0x263 == 0x7feb.
Allez vers cette ligne (l'instruction assembleur doit correspondre à celle de la ligne 'Stopped at'), puis sur le numéro de ligne C le plus proche :

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

Dans notre cas, c'est précisément la ligne 3872 de pf.c qui crashe :

# cat -n pf.c | head -n 3872 | tail -n 1 3872 if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {

Il faut remarquer que le noyau qui produit la sortie du crash et le fichier objet pour objdump doivent être compilés avec les mêmes fichiers sources, sinon l'offset ne correspondra pas.

Si vous fournissez aussi bien la sortie de ddb> trace et la section objdump correspondante, c'est très utile.

[Index de la FAQ] [Section 1 - Introduction à OpenBSD] [Section 3 - Démarrer avec OpenBSD]