FreeBSD es un sistema operativo moderno para desktops, laptops, servidores, y sistemas embebidos con con soporte para un gran número de plataformas.

Esta basado en la versión “4.4BSD-Lite” de la U.C. Berkeley, con algunas mejoras de “4.4BSD-Lite2”. También esta basado indirectamente en el port que William Jolitz's hizo de “Net/2” de la U.C. Berkeley a i386™, conocido como “386BSD”, a pesar de que actualmente queda muy poco código de 386BSD.

FreeBSD es usado por compañias, proveedores de internet, investigadores, profesionales de las computadoras, estudiantes y usuarios hogareños alrededor del mundo para su trabajo educación y recreación.

Para información más detallada acerca de FreeBSD, vea el manual de FreeBSD.

El objetivo del proyecto FreeBSD es proveer un sistema operativo estable y veloz de propósito general que pueda ser usado para cualquier propósito sin ataduras.

Si. Estas restricciones no controlan como se usa el código, sino como se trata al proyecto FreeBSD en si mismo. La licencia esta disponible en licencia y puede ser resumida de la siguiente manera:

Muchos de nosotros hemos invertido significativamente en el proyecto y no nos molestaría recibir una pequeña compensación financiera ocasionalmente, pero de ninguna manera insistiremos en ello. Creeemos que nuestra primera y principal “misión” es proveer código a todos los consumidores, para cualquier propósito, de manera que el codigo se utilize de la manera más amplia posible y provea el mayor beneficio posible. Esta, creemos es una de las metas mas fundamentales del software libre, y una que apoyamos entusiastamente.

El código en nuestro arbol de codigo fuente que esta cubierto por la Licencia Pública General de GNU o la GNU Library General Public License (LGPL) viene con más restricciones, pero el menos del lado de forzar el acceso al código en lugar de su opuesto. Debido a las complejidades adicionales que pueden evolucionar del uso comercial de software GPL, intentamos reemplazar tal software con alternativas bajo la más permisiva licencia de FreeBSD cuando sea posible.

Para la mayoría de la gente, si. Pero esta pregunta no es tan simple.

La mayoría de la gente no usa realmente un sistema operativo. Usan aplicaciones. Estas aplicaciones son las que realmente utilizan el sistema operativo. FreeBSD fue diseñado para proveer un ambiente robusto y lleno de características para aplicaciones. Soporta una amplia variedad de navegadores web, suites ofimáticas, lectores de correo electrónico, programas gráficos, ambientes de programación, servidores de red, y mucho más. La mayoría de estas aplicaciones puede manejarse a través de La colección de Ports.

Si una aplicación solo esta disponible en un sistema operativo, ese sistema operativo no puede ser reemplazado. De todas maneras, hay muchas posibilidades de que haya una aplicación muy similar en FreeBSD. Como un sólido servidor para la oficina o internet o una confiable estación de trabajo, FreeBSD con toda seguridad hara todo lo que usted necesita. Muchos usuarios de computadoras alrededor del mundo, incluyendo novatos y administradores UNIX® experimentados, utilizan FreeBSD como su único sistema operativo de escritorio.

Los usuarios que migren a FreeBSD desde otro ambiente estilo UNIX® encontraran que FreeBSD es similar. Los usuarios de Windows® y Mac OS® pueden estar interesados en utilizar PC-BSD, una distribución de escritorio basada en FreeBSD. Los usuarios no-UNIX® deberían esperar invertir más tiempo aprendiendo la manera UNIX® de hacer las cosas. Este FAQ y el manual de FreeBSD son excelentes lugares para empezar.

Vale la pena señalar que la palabra “free” se usa de dos maneras aqui: una de ellas significa “sin costo” y la otra significa “haga lo que quiera”. Aparte de una o dos cosas que usted no puede hacer con el código de FreeBSD, por ejemplo pretender que lo escribio, puede hacer lo que desee con el mismo.

James Howard escribio una buena explicación de la historia y diferencias entre los varios proyectos, llamada El Arbol Familiar BSD que se esfuerza en responder esta pregunta. Parte de la información esta desactualizada, pero la parte histórica en particular sigue siendo precisa.

La mayoria de los BSDs comparten codigo y parches, aún hoy en día. Todos estos BSDs tienen un linaje en común.

Los objetivos de diseño de FreeBSD se describen en P: 1.2. Los objetivos de diseño de los otros BSDs populares pueden resumirse como sigue:

En cualquier punto del desarrollo de FreeBSD puede haber multiples ramas paralelas. Las versiones 10.X se hacen a partir de la rama 10-STABLE, y las versiones 9.X se hacen a partir de la rama 9-STABLE.

Hasta el lanzamiento de 9.0, la serie 9.X era la conocida como -STABLE. No obstante, a la fecha de lanzar 11.X, la rama 9.X sera designada para un estatus de “soporte extendido” y recibira solo arreglos para problemas importantes, por ejemplo los relacionados con seguridad.

La versión 10.2 es la última versión de la rama 10-STABLE; fue lanzada en Agosto del 2015. La versión 9.3 es la última versión de la rama 9-STABLE; fue lanzada en Julio del 2014.

Las versiones se hacen cada unos cuantos meses. Mientras que mucha gente se mantiene más al corriente con las fuentes de FreeBSD (vea las preguntas en FreeBSD-CURRENT y FreeBSD-STABLE) que eso, hacerlo requiere un compromiso mayor, ya que las fuentes son un blanco en movimiento.

Puede encontrarse más información acerca de las versiones de FreeBSD en la página de Ingenieria de Versiones y en release(7).

FreeBSD-CURRENT es la versión de desarrollo del sistema operativo, la cual a su debido tiempo se convertira en la nueva rama FreeBSD-STABLE. Como tal, solo sirve de interes a los desarrolladores trabajando en el sistema y entusiastas acérrimos. Vea la sección reelevante en el manual para obtener detalles acerca de correr -CURRENT.

Los usuarios que no esten familiarizados con FreeBSD no deberían usar FreeBSD-CURRENT. Esta rama suele evolucionar rápidamente y a veces, debido a errores puede ser imposible de compilar. Se espera que la gente que usa FreeBSD-CURRENT sea capaz de analizar, debuggear y reportar problemas.

Las versiones snapshot de FreeBSD son hechas basadas en en el estado actual de las ramas -CURRENT y -STABLE. Los objetivos detrás de cada version snapshot son:

No se asegura que un snapshot de -CURRENT pueda considerarse de “calidad para producción” para cualquier propósito. Si se necesita un sistema estable y probado en profundidad, use las versiones completas o snapshots de -STABLE.

Las versiones snapshot estan directamente disponibles desde snapshot.

Los snapshots oficiales se generan regularmente para todas las ramas desarrolladas activamente.

Cuando se lanzo FreeBSD 2.0.5, el desarrollo de FreeBSD se ramifico en dos. Una rama fue llamada -STABLE, y otra -CURRENT. FreeBSD-STABLE esta pensada para ser usada por proveedores de internet, y otras compañías comerciales para las cuales cambios bruscos o características experimentales son indeseables. Solo recibe arreglos de errores que hayan sido probados en profundidad y otras pequeñas mejoras incrementales. FreeBSD-CURRENT, por otra parte ha sido una linea continua desde que se lanzo 2.0 hasta 10.2-RELEASE y más allá. Para información más detallada acerca de las ramas vea “Ingenieria de lanzamientos de FreeBSD: Creando la Rama de Lanzamiento”, el estado de las ramas y la agenda de lanzamientos futuros puede encontrarse en la página de Información de ingeniería de lanzamientos.

10.2-STABLE es la rama activamente desarrollada de -STABLE. La última versión de la rama 10.2-STABLE es 10.2-RELEASE, la cual fue lanzada en Agosto del 2015.

La rama 11-CURRENT es la rama activamente desarrollada de -CURRENT para próxima generación de FreeBSD. Vea ¿Qué es FreeBSD-CURRENT? para más información acerca de esta rama.

El equipo de ingenieria de lanzamientos <re@FreeBSD.org> lanza una versión mayor de FreeBSD cada aproximadamente 18 meses y una nueva versión menor cada aproximadamente 8 meses, en promedio. Las fechas de lanzamiento se anuncian con antelación, de manera que la gente que trabaja en el sistema sabe cuando sus proyectos deben estar terminados y probados. Un período de prueba precede cada lanzamiento, para asegurarse que el agregado de nuevas características no comprometa la estabilidad del lanzamiento. Muchos usuarios ven esta precuación como una de las mejores cosas acerca de FreeBSD, a pesar de que el esperar que las ultimas mejoras lleguen a -STABLE puede ser un poco frustrante.

más información acerca del proceso de ingenieria de lanzamientos (incluyendo una agenda de futuros lanzamientos) puede encontrarse en las páginas de ingenieria de lanzamientos en el sitio de FreeBSD.

Para la gente que quiere o necesita algo de emoción, snapshots binarios se hacen semanalmente, como se dijo más arriba.

Las decisiones clave que tengan que ver con el proyecto FreeBSD, tales como la dirección general del proyecto y quien puede agregar codigo al arbol fuente, son hechas por un equipo central de 9 personas. Existe un equipo mucho más grande de más de 350 committers que estan autorizados a hacer cambios directamente al árbol de fuentes.

No obstante, la mayoría de los cambios no triviales se discuten por adelantado en las listas de correo, y no existen restricciones acerca de quien puede participar en la discusión.

Cada lanzamiento importante de FreeBSD esta disponible via FTP anónimo desde el sito FTP de FreeBSD:

Información acerca de como obtener FreeBSD en CD, DVD y otros medios puede encontrarse en el manual.

La base de datos de reporte de problemas de todos los pedidos de cambio por parte de los usuarios puede consultarse usando nuetra interfaz de consulta de PR basada en web.

La interfaz basada en web de envio de reporte de problemas puede ser usada para enviar reportes a través de un navegador web.

Antes de envíar un reporte de problemas, lea Escribiendo reportes de problemas para FreeBSD, un artículo acerca de como escribir buenos reportes de problemas.

El proyecto produce un amplio rango de documentación, disponible en linea a través de este link: http://www.FreeBSD.org/docs.html. Adicionalmente, la bibliografía al final de este FAQ, y la del manual referencian otros libros recomendados.

Si. La documentación esta disponible en un número de diferentes formatos y esquemas de compresión desde el sitio FTP de FreeBSD, en el directorio /pub/FreeBSD/doc/.

La documentación esta categorizada en un número de manera distintas. Estas incluyen:

Luego de elegir el formato y mecanismo de compresión, descargue los archivos comprimidos, descomprimalos, y luego copie los documentos apropiados a su lugar.

Por ejemplo, la versión HTML split del FAQ, comprimida usando bzip2(1), puede encontrarse en doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2. Para descargar y descomprimir dicho archivo, escriba:

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2
# tar xvf book.html-split.tar.bz2

Si el archivo esta comprimido, tar detectara automaticamente el formato apropiado y lo descomprimira correctamente, resultando en una colección de archivos .html. El principal se llama index.html, el cual contiene la tabla de contenidos, material introductorio, y vínculos a las otras partes del documento.

Vea la entrada del manual acerca de listas de correo y la entrada del manual acerca de grupos de noticias.

Si, la mayoría de las redes IRC hospedan un canal de chat de FreeBSD:

La wiki de FreeBSD tiene una buena lista de canales IRC.

Cada uno de estos canales es distinto y no esta conectado a los otros. Dado que sus estilos de conversacion pueden diferir, intente encontrar uno que se adecue a su estilo de conversación.

Los foros oficiales de FreeBSD estan ubicados en https://forums.FreeBSD.org/.

iXsystems, Inc., compañia padre de FreeBSD Mall, provee soporte comercial de software FreeBSD y PC-BSD, en adición a soluciones para el desarrollo y ajuste de FreeBSD.

BSD Certification Group, Inc. PROVEE certificaciones de administración de sistemas para DragonFly BSD, FreeBSD, NetBSD, y OpenBSD. Vea su sitio para más información.

Cualquier otra organización que provea entrenamiento y soporte deberá contactar al proyecto para ser listada aquí.

amd64 es el término usado por BSD para las arquitectura de x86 compatibles con 64 bits (también conocido como "x86-64" o "x64"). La mayoría de las computadoras modernas deberían usar amd64. El hardware más antiguo debería usar i386. Al instalar en una arquitectura no compatible con x86, elija la plataforma que se aproxime mejor al hardware.

En la página Obteniendo FreeBSD elija [iso] al lado de la arquitectura que coincide con el hardware.

Cualquiera de los siguientes puede ser usado:

Los usuarios de pc98 requerirán las siguientes imágenes de disquete: floppies/boot.flp, floppies/kern1.flp, floppies/kern2.flp, y floppies/mfsroot1.flp. Estas imagenes necesitaran ser escritas a disquetes por herramientas como dd(1).

Instrucciones completas acerca de este procedimiento y mas información acerca de problemas de instalación en general puede encontrarse en este la entra de manual acerca de instalar FreeBSD.

Esto puede ser ocasionado por no descargar la imagen en modo binary al usarFTP.

Algunos clientes FTP tienen por defecto el modo de transferencia ascii e intentan cambiar cualquier carácter de fin de línea para que use las convenciones del sistema del cliente. Esto con toda probabilidad corromperá la imagen de arranque. Verifique el checksum SHA-256 de la imagen de arranque descargada: si es exactamente la imagen que se encuentra en el servidor, entonces el proceso de descarga es el sospechoso.

Cuando use un cliente de FTP por línea de comandos, escriba binary en la pantalla de comandos FTP luego de conectarse al servidor y antes de comenzar a descargar la imagen.

Las instrucciones de instalación pueden encontrarse en la entrada del manual acerca de instalar FreeBSD.

FreeBSD requiere una PC 486 o mejor PC, 64 MB o más de RAM, y como mínimo 1.1 GB de espacio en el disco rígido.

Medios de instalación personalizados de FreeBSD pueden crearse compilando una versión personalizada. Siga las instrucciones en el artículo de Ingeniería de Lanzamientos .

Si Windows® es instalado primero, entonces si. El gestor de arranque de FreeBSD se las arreglara para arrancar tanto Windows® como FreeBSD. Si Windows® es instalado después, sobrescribirá el gestor de arranque. Si esto ocurre, vea la siguiente sección.

Depende del gestor de arranque. El menú de selección de arranque de FreeBSD puede reinstalarse usando boot0cfg(8). Por ejemplo, para restaurar el menu de arranque al disco ada0:

# boot0cfg -B ada0

El cargador de arranque no interactivo MBR bootloader puede instalarse usando gpart(8):

# gpart bootcode -b /boot/mbr ada0

Para situaciones mas complejas, incluyendo discos GPT, véase gpart(8).

La causa más frecuente de este problema es un lector de CD-ROM mal configurado. Muchas PCs se suministran con el CD-ROM como la unidad esclava en el controlador IDE secundario, sin ningún dispositivo maestro en el controlador. Esto es ilegal en la especificación ATAPI, pero Windows® no sigue la misma al pie de la letra, y el BIOS la ignora al arrancar. Esta es la causa de que el BIOS pudo ver el CD-ROM para arrancar del mismo, pero FreeBSD no puede verlo para completar la instalación.

Reconfigure el sistema de manera que el CD-ROM se encuentre en el dispositivo maestro del controlador al que esta acoplado, o asegúrese de que es el esclavo en un controlador IDE que también tiene un dispositivo maestro.

En general, no. No hay nada en el sistema base que requiera la presencia del código fuente para operar. Algunos ports como sysutils/lsof, no compilaran a menos que el código este instalado. En particular, si el port compila un modulo de kernel u opera directamente sobre estructuras del kernel, el código fuente debe estar instalado.

Usualmente no. El kernel GENERIC incluido contiene los controladores que una computadora ordinaria requiere. freebsd-update(8), la herramienta de actualización binaria de FreeBSD, no puede actualizar kernels hechos a medida, otra razón para quedarse con el kernel GENERIC cuando sea posible. Para computadoras con una cantidad limitada de RAM, tales como los sistemas embebidos, puede valer la pena compilar una kernel mas pequeño, hecho a medida conteniendo únicamente los controladores requeridos.

FreeBSD 9 y posterior usan SHA512 por defecto. Las contraseñas en formato DES siguen estando disponibles para mantener compatibilidad con sistemas operativos viejos que usan el formato de contraseñas menos seguro. FreeBSD también soporta los formatos de contraseña Blowfish y MD5. Que formato de contraseña usar para las contraseñas nuevas esta controlado por la capacidad de autenticación passwd_format en /etc/login.conf, la cual toma los valores des, blf (si estos están disponibles) o md5. Vea la página de manual de login.conf(5) para más información acerca de capacidades de autenticación.

Para sistemas de archivos FFS, el sistema de archivo mas extenso esta limitado en la práctica por la cantidad de memoria requeridad para correr fsck(8) en el sistema de archivos. fsck(8) requiere un bit por fragmento, lo cual, con el tamaño de fragmentos por defecto de 4 KB es igual a 32 MB de memoria por cada TB de disco. Esto significa que en arquitecturas que limiten los procesos en espacio de usuario a 2 GB (e.j., i386™), el máximo sistema de archivos fsck(8)'able es de ~60 TB.

Si no hubiera un límite de memoria de fsck(8) en máximo tamaño de archivo sería de 2^64 (bloques) * 32 KB => 16 Exa * 32 KB => 512 ZettaBytes.

El máximo tamaño para un archivo de FFS es aproximadamente 2 PB con el tamaño de bloque por decto de 32 KB. Cada bloque de 32 KB puede apuntar a 4096 bloques. Con bloques triplemente indirectos, el cálculo es 32 KB * 12 + 32 KB * 4096 + 32 KB * 4096^2 + 32 KB * 4096^3. Incrementar el tamaño de bloque a 64 KB incrementara el tamaño máximo de archivo por un factor de 16.

El mundo y kernel están fuera de sincronización. Esto no esta soportado. Asegurese de usar make buildworld y make buildkernel para actualizar el kernel.

Arranque el sistema especificando el kernel directamente en la segunda fase, presionando cualquier tecla cuando | aparezca antes de que arranque el cargador.

Si. bsdconfig provee una buena interfaz para configurar FreeBSD post-instalación.

La razón más probable es la diferencia entre direcciones de memoria física y direcciones virtuales.

La convención para la mayoría del hardware de PC hardware es usar el área de memoria entre 3.5 GB y 4 GB para un propósito especial (usualmente para PCI). Este espacio de direcciones se usa para acceder a hardware PCI. Como resultado, la memoria real (física) no puede ser accedida en ese espacio de direcciones.

Lo que sucede con la memoria que debería aparecer en ese espacio es dependiente del hardware. Desafortunadamente, algunos equipos no hacen nada y la habilidad de usar los últimos 500 MB de RAM se pierde por completo.

Por suerte, la mayoría de los equipos de hardware remapean la memoria a una locación más alta de manera que pueda seguir siendo usada. No obstante, esto puede causar confusión al ver los mensajes de arranque.

En una versión de 32 bits de FreeBSD, la memoria parece perdida, dado que sera remapeado por encima de los 4 GB, que son imposibles de acceder para un kernel de 32 bits. En este caso, la solución es construir un kernel con PAE habilitado. Vea la entrada acerca de límites de memoria para más información.

En una versión de 64 bits de FreeBSD, o al correr un kernel con PAE habilitado, FreeBSD detectara y remapeara la memoria de manera correcta para que sea usable. Durante el arranque, sin embargo, puede parecer que FreeBSD este detectando más memoria de la que tiene realmente el sistema, debido al remapeo descrito anteriormente. Esto es normal y la memoria disponible sera corregida cuando el proceso de arranque termine.

Los errores Signal 11 son causados cuando un proceso intento acceder a una región de memoria cuyo acceso no fue concedido por el sistema operativo. Si algo como esto pasa a intervalos aparentemente aleatorios, comience a investigar la causa.

Estos problemas suele deberse a:

Probablemente no se trate de un error en FreeBSD si el problema ocurre al compilar un programa, pero la actividad que el compilador realiza cambia en cada iteración.

Por ejemplo, si make buildworld falla al intentar compilar ls.c a ls.o y, al correr de vuelta, falla en el mismo lugar, esto es una compilación fallida. Pruebe actualizar el código fuente e intentando nuevamente. Si la compilación falla en otro lugar, casi ciertamente es debido al hardware.

En el primer caso, use un debugger, tal como gdb(1) para encontrar el punto en el que el programa este intentando acceder a una dirección falsa y arreglarlo.

En el segundo caso, verifique la pieza de hardware que este fallando.

Causas comunes de esto incluyen:

Lea la sección acerca de Signal 11 para más explicaciones y una discusión acerca de como el software o hardware que verifica la memoria puede no detectar memoria defectuosa. Hay un extenso FAQ acerca de esto en el problema SIG11FAQ.

Finalmente, si nada de esto ayuda, es posible que sea un error en FreeBSD. Siga estas instrucciones para enviar un reporte de errores.

Los desarrolladores de FreeBSD están interesados en estos errores, pero necesitan mas información que solo el mensaje de error. Copie el mensaje de fallo entero. Luego consulte la sección del FAQ acerca de fallos de kernel, compile un kernel de depuración y obtenga un backtrace. Esto puede sonar difícil, pero no requiere habilidades de programación. Tan solo siga las instrucciones.

El kernel de FreeBSD solo permite que exista un cierto número de procesos en un punto determinado del tiempo. El número esta basado en la variable de sysctl(8) kern.maxusers. kern.maxusers también afecta varios otros límites del kernel, tales como los buffers de red. Si la máquina esta bajo una carga intensiva, incremente kern.maxusers. Esto incrementara estos otros límites del sistema, además del número máximo de procesos.

Para ajustar el valor de kern.maxusers, vea la sección Límites de proceso/archivo del manual. Mientras que esa sección se refiere a archivos abierto, los mismos límites aplican para los procesos.

Si la máquina tiene una carga ligera pero esta corriendo número muy alto de proceso, ajuste la variable kern.maxproc definiendola en /boot/loader.conf. La variable no se ajustara hasta que el sistema se reinicie. Para más información acerca de ajustar variables, vea loader.conf(5). Si estos procesos están siendo corridos por un solo usuario, ajuste kern.maxprocperuid para que sea uno menos que el nuevo valor de kern.maxproc. Debe ser al menos uno menos porque hay un programa del sistema, init(8), que debe estar corriendo constantemente.

La máquina remota puede estar ajustando el tipo de la terminal a un valor que no sea xterm el cual es requerido por la consola de FreeBSD. Alternativamente el kernel puede contener los valores equivocados para el ancho y alto de la terminal.

Verifique que el valor de la variable de entorno TERM sea xterm. Si la máquina remota no soporta eso, intente vt100.

Corra stty -a para verificar que dimensiones cree el kernel que tiene la terminal. Si son incorrectas, pueden cambiarse corriendo stty rows RR cols CC.

Alternativamente, si la máquina del cliente tiene x11/xterm instalado, entonces correr resize consultara a la terminal las dimensiones correctas y las ajustara.

El síntoma: hay un largo retraso entre el tiempo en que se establece la conexión TCP y el tiempo en el que el software del cliente pide una contraseña (o, en el caso de telnet(1), cuando aparece una pantalla de autenticación).

El problema: lo más probable, es que el retraso haya sido causado por el software del servidor intentando resolver la dirección IP del cliente a un nombre de host. Muchos servidores, incluyendo los servidores Telnet y SSH que vienen con FreeBSD, hacen esto para guardar el hostname en un archivo de log para referencias futuras del administrador.

La solución: si el problema ocurre siempre que se conecta la computadora cliente a cualquier servidor, el problema esta en el cliente. Si el problema ocurre solo cuando alguien se conecta a la computadora servidor, el problema esta en el servidor.

Si el problema esta en el cliente, la única solución es reparar el DNS de manera que el servidor pueda resolverla. Si esto ocurre en una red local, considerelo un problema del servidor y siga leyendo. Si esto ocurre en Internet, contacte a su ISP.

Si el problema es con el servidor en una red local, configure el servidor para resolver consultas de dirección a hostname para el rango de direcciones local. Vea hosts(5) y named(8) para más información. Si esto ocurre en la Internet, el problema puede ser que el resolver local del servidor no esta funcionando correctamente. Para verificar, intente buscar otro host tal como www.yahoo.com. Si esto no funciona, ese es el problema.

Luego de una instalación de cero de FreeBSD, también es posible que la información del dominio y servidor de nombres no exista en /etc/resolv.conf. Esto frecuentemente causara un retraso en SSH, dado que la opción UseDNS esta ajustada a yes (si) por defecto en /etc/ssh/sshd_config. Si esto esta causando el problema, llene la información faltante en /etc/resolv.conf o ajuste UseDNS a no en sshd_config como solución temporal.

Este mensaje de error indica que el número de descriptores de archivo disponibles en el sistema se agoto. Vea la subsección kern.maxfiles de la sección Ajustando límites del kernel del manual para una discusión y una solución.

La computadora tiene dos o más relojes, y FreeBSD eligió usar el incorrecto.

Corra dmesg(8), y verifique las líneas que contengan Timecounter. El del valor de calidad más alto que eligio FreeBSD.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Confirme esto verificando el sysctl(3)kern.timecounter.hardware.

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Puede tratarse de un timer ACPI roto. La solución más simple es deshabilitar el timer ACPI en /boot/loader.conf:

debug.acpi.disabled="timer"

O el BIOS puede modificar el reloj TSC quizás para cambiar la velocidad del procesador cuando se agonten las baterías, o al cambiar al modo de ahorro de engería, pero FreeBSD no sabe nada de estos ajustes y parece estar perdiendo o ganando tiempo.

En este ejemplo, el reloj i8254 también esta disponible, y puede ser seleccionando escribiendo su nombre en el sysctl(3) kern.timecounter.hardware.

# sysctl kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

La computadora debería empezar a medir el tiempo de manera más correcta a partir de ahora.

Para que este cambio corra automáticamente en tiempo de arranque, agregue la siguiente línea a /etc/sysctl.conf:

kern.timecounter.hardware=i8254

Esto significa que un proceso esta intentando paginar memoria al disco, y el intento de paginación se colgó intentando acceder al disco por más de 20 segundos. Puede estar causado por bloques defectuosos en el disco rígido, cableado del disco, cables, o cualquier otro tipo de hardware de E/S relacionado. Si el disco en si mismo esta defectuoso, los errores de disco aparecerán en /var/log/messages y en la salida de dmesg. En otro caso, verifique los cables y las conexiones.

El kernel de FreeBSD usa un número de primitivas de sincronización para manejar la contención de ciertos recursos. Cuando múltiples hilos de kernel intentan obtener múltiples primitivas de sincronización, existe el potencial para un interbloqueo, en donde dos hilos obtuvieron cada uno una primitiva y se bloquean eternamente esperando que el otro hilo libere la otra. Este tipo de problema de bloqueo puede evitarse si todos los hilos obtienen las primitivas en el mismo orden.

Un sistema diagnóstico en tiempo de ejecución llamado witness(4), habilitado en FreeBSD-CURRENT y deshabilitado por defecto para ramas stable y lanzamientos, detecta el potencial para interbloques debido a errores de bloque, incluyendo errores causados por la obtención de múltiples primitivas de sincronización con un orden diferente de distintas partes del kernel. El framework witness(4) intenta detectar este problema mientras ocurre y lo reporta imprimiendo un mensaje en la consola del sistema acerca de un lock order reversal (también conocido como LOR).

Es posible obtener falsos positivos, dado que witness(4) es conservativo. Un reporte que realmente sea positivo no significa que el sistema sufrió un interbloqueo; en su lugar, debería ser entendido como una advertencia que un interbloqueo podría haber ocurrido en ese lugar.

Significa que una función que puede dormirse fue llamada mientras un mutex (u otra primitiva de sincronización que no duerme) estaba bloqueado.

La razón por la que esto es un error es que los mutexes no fueron concebidos para ser tenidos por largos períodos de tiempo; se supone que solo se tengan para mantener durante períodos cortos de sincronización. Este contrato de programación permite que los controladores de dispositivo usen mutexes para sincronizarse con el resto del kernel durante las interrupciones. Las interrupciones (bajo FreeBSD) pueden no dormirse. Luego es imperativo que ningún subsistema en el kernel se bloquee por un período extendido de tiempo al mantener un mutex.

Para atrapar tales errores, pueden agregarse aserciones al kernel para interactuar con el subsitema witness(4) y emitir una alerta o un error fatal (dependiendo de la configuración del sistema) cuando una llamada potencialmente bloqueante es hecha mientras que se mantiene un mutex.

En resumen, estas alertas no son fatales, no obstante errores de coordinación pueden causar efectos indeseables variando desde un mínimo retraso en la respuesta del sistema a un completo bloqueo del mismo.

Para información adicional acerca de los bloqueos en FreeBSD vea locking(9).

Este error no significa que la utilidad touch(1) este faltante. En su lugar el error probablemente se debe a que las fechas de los archivos están ajustadas a una fecha futura. Si el reloj CMOS esta ajustado a tiempo local, corra adjkerntz -i para ajustar el reloj del kernel al arrancar en modo de un solo usuario.

Vaya a la página de ports para información acerca de paquetes de software que han sido porteados a FreeBSD. La lista actual contiene más de 24,000 y crece diariamente, vuelva y verifíquela seguido o subscribase a la lista de anuncios de FreeBSD para actualizaciones periódicas sobre nuevas entradas.

La mayoría de los ports deberían funcionar en todas las version soportadas de FreeBSD. Los que no lo hacen están marcados específicamente de esta manera. Cada vez que se realiza una versión de FreeBSD, se hace un snapshot del árbol de ports al momento de la versión que se incluye en el directorio ports/.

FreeBSD soporta paquetes binarios comprimidos para instalar y desinstalar ports fácilmente. Use pkg(7) para controlar la instalación de paquetes.

Cualquiera de los métodos listados aquí funciona:

Si. Vea http://www.FreeBSD.org/java/ para más información.

Si la versión de FreeBSD instalada se atrasa significativamente de -CURRENT o -STABLE, actualice la colección de ports usando las instrucciones en Usando la colección de ports. Si el sistema esta actualizado, alguien puede haber commiteado un cambio al port que funciona para -CURRENT pero que rompió el port para -STABLE. Envíe un reporte de errores, dado que se supone que la colección de ports funcione tanto para la rama -CURRENT como para -STABLE.

Primero, asegúrese de que la colección de ports esta actualizada. Errores que afecten la compilación de INDEX de una copia actualizada de la colección de ports tienen alta visibilidad y suelen arreglarse casi inmediatamente.

Hay raras ocurrencias en las que INDEX no compilara debido a casos extraños que involucren variables WITH_* o WITHOUT_* siendo ajustadas en make.conf. Si sospecha que este es el caso, intente hacer make de INDEX con esas variables desactivadas antes de reportar el error a la lista de correo de ports de FreeBSD .

FreeBSD no incluye una herramienta para actualizar ports, pero si tiene herramientas para hacer el proceso de actualización un poco más fácil. Herramientas adicionales están disponibles para simplificar el manejo de ports y son descriptas en la sección Actualizando portsen el manual de FreeBSD.

¡Si! Mientras que un sistema reciente correrá con software compilado bajo una versión vieja, hay cosas que pueden fallar al azar o no funcionar una vez que otros ports sean instalados o actualizados.

Cuando el sistema se actualiza, varias librerías compartidas, módulos cargables y otras partes del sistema serán reemplazadas por versiones más nuevas. Las aplicaciones que estén vinculadas contra las version más viejas pueden fallar al iniciar o, en otros casos, fallar al funcionar con propiedad.

Para más información, vea la sección acerca de actualizaciones en el manual de FreeBSD.

En general, no. Los desarrolladores de FreeBSD hacen lo posible para garantizar compatibilidad binaria en todas las versiones con el mismo número de versión mayor. Cualquier excepción será documentada en las notas de lanzamiento, y los consejos que se presenten allí deberán ser seguidos.

Mucha gente necesita escribir scripts de shell que sean portables a muchos sistemas. Por eso es que POSIX® especifica el shell y los comandos utilitarios en gran detalle. La mayoría de los scripts están escritors en el shell de Bourne (sh(1)), y porque varias interfaces de programación importantes (make(1), system(3), popen(3), y análogos en lenguajes de scripting de alto nivel como Perl y Tcl) son instruidos para usar el shell de Bourne para interpretar comandos. Porque el shell de Bourne es usado frecuentemente y ampliamente, es importante que sea rápido al iniciar, que se comporte de manera determinística, y que tenga una pequeña huella de memoria.

La implementación existente es nuestro mejor esfuerzo para satisfacer simultaneamente el mayor número de requerimientos de este tipo que podamos. Para mantener /bin/sh pequeña, no proveemos muchas de las características convenientes que tienen otros shells. Por esto es que otras shells con más características como bash, scsh, tcsh(1), y zsh están disponibles. Compare el uso de memoria de estas shell mirando las columnas “VSZ” y “RSS” en el listado del comando ps -u.

Para crear CDs de audio a partir de archivos MIDI, primero instale audio/timidity++ desde ports y luego instale manualmente el set de parches GUS por Eric A. Welsh, disponible en http://alleg.sourceforge.net/digmid.html. Luego de que TiMidity++ haya sido instalada con propiedad, los archivos MIDI pueden convertirse a archivos WAV con el siguiente comando:

% timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid

Los archivos WAV pueden posteriormente convertirse a otros formatos o grabarse en CDs de audio, como se describe en el manual de FreeBSD.

¡En absoluto! Vea la sección del manual acerca de configuración del kernel.

Los kérneles GENERIC que vienen con FreeBSD son compilados en modo de depuración. Los kernels que se compilan en modo de depuración contienen datos de depuración en archivos separados que se usan para la depuración. Las versiones de FreeBSD anteriores a 11.0 guardan estos archivos de depuración en el mismo directorio en que se encuentra el kernel , /boot/kernel/. En FreeBSD 11.0 y posteriores los archivos de depuración se guardan en /usr/lib/debug/boot/kernel/. Nótese que habrá muy poca o ninguna perdida de desempeño debida al uso de un kernel de depuración, y es útil mantener uno en caso de un pánico del sistema.

Cuando se agote el espacio en disco, hay diferentes opciones para reducir el tamaño de /boot/kernel/ y /usr/lib/debug/.

Para no instalar los archivos de símbolos, asegúrese de que la siguiente línea exista en /etc/src.conf:

WITHOUT_KERNEL_SYMBOLS=yes

Para más información vea src.conf(5).

Si desea evitar por completo compilar archivos de depuración, asegurese de que se cumpla lo siguiente:

Cualquiera de las opciones anteriores causaran que el kernel se compile en modo de depuración.

Para compilar e instalar solo los módulos especificados, listelos en /etc/make.conf:

MODULES_OVERRIDE= accf_http ipfw

Reemplaze accf_httpd ipfw con una lista de los módulos que necesita. Solo los módulos listados serán compilados. Esto reduce el tamaño del directorio del kernel y reduce la cantidad de tiempo requerido para compilar el kernel. Para más información, lea /usr/share/examples/etc/make.conf.

Los dispositivos innecesarios pueden ser removidos del kernel para reducir aún más su tamaño. Vea P: 7.1 para más información.

Para que estas opciones hagan efecto, siga las instrucciones para compilar y instalar el nuevo kernel.

Para referencias, el kernel de FreeBSD 11 en amd64 (/boot/kernel/kernel) ocupa aproximadamente approximately 25 MB.

Hay varias causas posibles para este problema:

El nombre del planificador siendo usado actualmente esta directamente disponible como el valor del sysctl kern.sched.name:

% sysctl kern.sched.name
kern.sched.name: ULE

kern.sched.quantum es el máximo número de ticks que puede correr un proceso sin ser apropiado por el planificador de 4BSD.

Vea la sección Añadir discos en el manual de FreeBSD.

La mejor manera es reinstalar el sistema operativo en el nuevo disco, y luego mover los datos. Esto es altamente recomendado al seguir -STABLE por más de un lanzamiento o al actualizar una versión en lugar de instalar una nueva. Instale booteasy en ambos discos con boot0cfg(8) y luego arranque en modo dual hasta que este contento con la nueva configuración. Saltéese el próximo párrafo para averiguar como mover los datos luego de hacer esto.

Alternativamente, particiones y marque el nuevo disco con sade(8) o gpart(8). Si los discos están formateados con MBR, booteasy puede instalarse en ambos discos con boot0cfg(8) de manera que la computadora pueda arrancar en modo dual con el viejo o el nuevo sistema luego de que se haya realizado el copiado.

Una vez configurado el nuevo disco, los datos no pueden simplemente copiarse. En su lugar utilice las herramientas que entiendan los archivos de dispositivos y las banderas del sistema, tales como dump(8). Aunque se recomienda mover los datos mientras se encuentre en modo de un solo usuario, esto no es requerido.

Cuando los discos esten formateados con UFS, nunca use nada excepto dump(8) y restore(8) para mover el sistema de archivos raíz. Estos comandos también deberían ser usados al mover una única partición a otra partición vacía. La secuencia de pasos para usar dump para mover los datos de una partición UFS a una nueva partición es:

Por ejemplo, para mover /dev/ada1s1a con /mnt como punto de montaje temporario, escriba:

# newfs /dev/ada1s1a
# mount /dev/ada1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -

Reorganizar particiones con dump lleva un poco más de trabajo. Para combinar una partición como /var con su padre, cree una nueva partición que sea lo suficientemente grande como para ambas, mueva la partición padre como se describió anteriormente, y luego mueva la partición hija al directorio vacío que creo la primera movida:

# newfs /dev/ada1s1a
# mount /dev/ada1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -
# cd var
# dump 0af - /var | restore rf -

Para separar un directorio de su padre, por ejemplo poniendo /var en su propia partición cuando no estaba ahi anteriormente, cree ambas particiones, luego monte la partición hija en el directorio apropiado en el punto de montaje temporario, luego mueva la vieja partición:

# newfs /dev/ada1s1a
# newfs /dev/ada1s1d
# mount /dev/ada1s1a /mnt
# mkdir /mnt/var
# mount /dev/ada1s1d /mnt/var
# cd /mnt
# dump 0af - / | restore rf -

Las utilidades cpio(1) y pax(1) también están disponibles para mover datos del usuario. Es sabido que estas utilidades pierden información de las baneras, de modo que úselas con cuidado.

Respuesta corta: Soft Updates pueden por lo general usarse de manera segura en todas las particiones.

Respuesta larga: Soft Updates tiene dos características que pueden ser indeseables en ciertas particiones. Primero, una partición con Soft Updates tiene una pequeña chance de perder datos durante una falla del sistema. La partición no se corrompera dado que los datos simplemente se perderan. Segundo, Soft Updates puede causar faltas de espacio temporales.

Al usar Soft Updates, el kernel puede tomar hasta treinta segundos para escribir los cambios al disco físico. Cuando un archivo grande se borra el archivo aún reside en el disco hasta que el kernel realmente realice el borrado. Esto puede causar una condición de carrera muy simple. Suponga que un archivo grande es borrado y otro archivo grande se crea inmediatamente. El primer archivo grande no ha sido removido aún del disco físico, de modo que el disco puede no tener suficiente espacio para el segundo archivo grande. Esto producirá un error diciendo que la partición no tiene suficiente espacio, aun cuando una gran cantidad de espacio acaba de liberarse. Un par de segundos más tarde, la creación de archivos funciona de manera esperada.

Si un sistema falla luego de que el kernel acepte un gran trozo de datos para escribir a disco, pero antes de que los datos sean realmente escritos, los mismos pueden perderse. El riesgo es extremadamente mínimo, pero generalmente es manejable.

Estos problemas afectan a todas las plataformas que utilicen Soft Updates. ¿Qué significa esto para la partición raíz?

La información vital en la partición raíz cambia de manera muy esporádica. Si el sistema fallo durante la ventana de treinta segundos luego de que se realice este cambio, es posible que se pierdan datos. El riesgo es negligible para la mayoría de las aplicaciones, pero tenga en cuenta que existe. Si el sistema no puede tolerar este riesgo... ¡No use Soft Updates en el sistema de archivos raíz!

/ es tradicionalmente una de las particiones más pequeñas. Si /tmp esta en /, puede haber problemas con el espacio intermitente. Realizar un symlink de /tmp a /var/tmp resolverá este problema.

Finalmente, dump(8) no funciona en modo vivo (-L) en un sistema de archivos, con Journaled Soft Updates (SU+J).

FreeBSD soporta muchos otros sistemas de archivos.

FreeBSD incluye el Network File System NFS y la colección de ports de FreeBSD Ports Collection provee varias aplicaciones de FUSE para soportar muchos otros sistemas de archivos.

Las particiones de DOS secundarias se encuentras luego de todas las particiones primarias. Por ejemplo, si E es la segunda partición DOS en el segundo dispositivo SCSI, habrá un dispositivo para “slice 5” en /dev. Para montarlo corra:

# mount -t msdosfs /dev/da1s5 /dos/e

SI, gbde(8) y geli(8). Vea la sección Encriptar particiones de disco del manual de FreeBSD.

Para arrancar FreeBSD usando GRUB, y añada lo siguiente a /boot/grub/menu.lst o /boot/grub/grub.conf, dependiendo de como sea usado por la distribución de Linux®.

title FreeBSD 9.1
	root (hd0,a)
	kernel /boot/loader

Donde hd0,a apunte a la partición raíz del primer disco. Para especificar el número de slice, utilice algo como esto (hd0,2,a). Por defecto, si el número de slice es omitido, GRUB busca la primera dado que tiene la partición a.

Instale LILO al inicio de la partición de arranque de Linux® en lugar de en el Registro de Arranque Principal Luego podrá arrancar LILO desde BootEasy.

Esto se recomienda al correr Windows® y Linux® dado que hace mucho más simple lograr que Linux® arranque nuevamente si Windows® es reinstalado.

Esto no puede lograrse con el cargador de arranque estándar sin reescribirlo. Existen varios otros cargadores de arranque en la categoría sysutils de la colección de ports.

Si el disco ya tiene un sistema de archivos en el, use un comando como este:

# mount -t msdosfs /dev/da0s1 /mnt

Si el disco solo puede ser usado con sistemas FreeBSD, particionelo con UFS o ZFS. Esto proveerá soporte para nombres de archivo largos, mejoras en performance y estabilidad. Si el disco va a ser usado por otros sistemas operativos, una opción más portable, tal como msdosfs, es preferible.

# dd if=/dev/zero of=/dev/da0 count=2
# gpart create -s GPT /dev/da0
# gpart add -t freebsd-ufs /dev/da0

Finalmente, cree un nuevo sistema de archivos:

# newfs /dev/da0p1

y móntelo:

# mount /dev/da0s1 /mnt

Es una buena idea agregar una línea a /etc/fstab (vea fstab(5)) de manera que pueda simplemente escribir mount /mnt en el futuro:

/dev/da0p1 /mnt ufs rw,noauto 0 0

El tipo de dispositivo a montar debe estar especificado. Esto se describe en la sección del manual acerca de Usar CDs de datos.

Esto usualmente significa que no hay CD en el dispositivo, o que el dispositivo no es visible en el bus. Refiérase a la sección Usando CDs de datos del manual para una discusión detallada de este problema.

El CD probablemente use la extensión “Joliet” para guardar información acerca de archivos y directorios. Esto se discute en la sección del manual Usando CDs de datos.

Esto significa que un archivo crudo fue grabado al CD, en lugar de crear un sistema de archivos ISO 9660. Dele un vistazo a la sección del manual acerca de Utilizar CDs de datos.

Esto se dicute en la sección del manual acerca de Escribir datos a un sistema de archivos ISO. Para más información acerca de trabajar con CD-ROMs, vea la sección acerca de crear CDs en el capítulo de almacenamiento en el manual.

Intentar montar un CD de audio producira un error como cd9660: /dev/acd0c: Invalid argument. Esto es porque mount solo funciona en sistemas de archivos. Los CDs de audio no tienen sistemas de archivos; solo tienen datos. En su lugar, utilice un programa que lea CDs de audio, como el paquete o port de audio/xmcd.

Por defecto, mount(8) intentara montar la última pista de datos (sesión) a un CD. Para cargar una sesión anterior, use el argumento de linea de comandos -s. Vea mount_cd9660(8) para ejemplos específicos.

Como root ajuste la variable de sysctl vfs.usermount a 1.

# sysctl vfs.usermount=1

Para hacer que esto persista a un reinicio, agregue la línea vfs.usermount=1 a /etc/sysctl.conf de modo que se vuelva a ajustar al inicio del sistema.

Los usuarios solo pueden montar dispositivos que tienen permisos para leer. Para permitir que los usuarios monten un dispositivo los permisos deben establecerse en /etc/devfs.conf.

Por ejemplo, para permitir a los usuarios montar el primer dispositivo de USB añada:

# Prmitir a todos los usuarios montar un dispositivo USB.
	    own       /dev/da0       root:operator
	    perm      /dev/da0       0666

Ahora todos los usuarios pueden montar dispositivos que podrían leer a un directorio propio:

% mkdir ~/my-mount-point
% mount -t msdosfs /dev/da0 ~/my-mount-point

Desmontar el dispositivo es fácil:

% umount ~/my-mount-point

Habilitar vfs.usermount, no obstante, tiene implicaciones de seguridad negativas. Una mejor manera de acceder a medios formateados con MS-DOS® es usar el paquete emulators/mtools en la colección de ports.

Esto se debe a como funcionan ambos comandos. du atraviesa el árbol de directorio, mide que tan largo es cada archivo, y presenta los totales. df únicamente le pregunta al sistema de archivos cuanto espacio tiene disponible. Pueden parecer cosas idénticas, pero un archivo sin una entrada de directorio afectara a df pero no a du.

Cuando un programa esta usando un archivo, y el mismo es borrado, el archivo no se borra realmente del sistema de archivos hasta que el programa deja de usarlo. El archivo es luego inmediatamente borrado del listado de directorio, de todas formas. Como ejemplo, considere un archivo que sea lo suficientemente grande como para afectar la salida de du y df. Un archivo que este siendo visto con more puede ser borrado sin causar un error. La entrada es borrada del directorio de modo que ningún otro programa o usuario pueda accederla. No obstante, du muestra que el archivo no existe dado que ha atravesado el árbol de directorios y el archivo no esta listado. df muestra que sigue alli, dado que el sistema de archivos sabe que more sigue usando ese espacio. Una vez que la sesión de more termine, du y df estarán de acuerdo.

Esta situación es común en servidores web. Mucha gente crea un servidor web en FreeBSD y ser olvida de rotar los archivos de log. El log de acceso llena /var. El nuevo administrador borra el archivo, pero el sistema se seguira quejando de que la partición esta llena. Parar y reiniciar el programa del servidor web liberara el archivo, permitiendo que el sistema libere espacio en disco. Para prevenir que esto pase, configure newsyslog(8).

Note que Soft Updates puede retrasar la liberación de espacio en el disco y que puede tomar hasta 30 segundos para que el cambio sea visible.

Esta sección del manual describe como hacer esto.

Los fabricantes de discos calculan gigabytes como un millón de bytes cada uno, mientras que FreeBSD los calcula como 1,073,741,824 bytes cada uno. Esto explica porque, por ejemplo, los mensajes de arranque de FreeBSD reportan un disco que se supone que tenga 80 GB como si tuviera 76,319 MB.

También note que FreeBSD (por defecto) reserva 8% de espacio del disco.

Una porción de cada partición UFS (8%, por defecto) esta reservada para su uso por el sistema operativo y el root usuario. df(1) no cuenta ese espacio al calcular la columna Capacity (Capacidad), de modo que puede exceder el 100%. Note que la columna Blocks (Bloques) siempre es mayor que la suma de las columnas Used (Usado) y Avail (Disponibilidad), usualmente por un factor del 8%.

Para más detalles, busque -m en tunefs(8).

FreeBSD 10.1 y versiones anteriores hacen una prueba de memoria tempranamente en el proceso de arranque. Cuando el sistema tiene una cantidad pequeña de memoria, la prueba toma un par de segundos. A las computadoras con diez o miles de gigabytes de memoria puede llevarles varios minutos completar el test. El test de memoria puede deshabilitarse añadiendo hw.memtest.tests=0 a /boot/loader.conf.

Para más detalles, vea loader.conf(5).

Se necesita un mínimo de 4GB de RAM para un uso típico, pero la carga de trabajo individual puede variar ampliamente.

El ZIL (ZFS intent log) es un log de escritura utilizado para implementar semánticas de commiteo de escritura de posix entre fallos del sistema. Normalmente las escrituras están empaquetadas en grupos de transacción para escribirse al disco al llenarse (“Transaction Group Commit”). No obstante syscalls tales como fsync(2) requieren un compromiso de que los datos se escriban a un almacenamiento estable antes de regresar. El ZIL es necesario para escrituras que se reconocieron como realizadas pero que no estan en disco aún como parte de una transacción. Los grupos de transacción tienen una marca de tiempo. En el caso de un fallo la última marca de tiempo válida es encontrada y los datos faltantes se combinan desde el ZIL.

Por defecto, ZFS guarda el ZIL en el pool junto con el resto de los datos. Si una aplicación tiene una gran carga de escritura, guardar el ZIL en un dispositivo separado que tenga un rendimiento de escritura secuencial muy rápido y asincrónico puede mejorar el sistema en general. Para otro tipo de cargas, es poco probable que un SSD represente una gran mejora.

El L2ARC es una cache de lectura guardada en un dispositivo rápido tal como un SSD. Esta cache no persiste entre reinicios. Notese que la RAM es usada como primera capa de cache y el L2ARC solo es necesitado si hay RAM insuficiente.

L2ARC necesita espacio en el ARC para indexarlo. De modo que, extrañamente, un conjunto de trabajo que encaja perfectamente en el ARC dejara de encajar perfectamente si el L2ARC se usa porque una parte del ARC esta reteniendo el índice el L2ARC, pasando una parte del conjunto de trabajo al L2ARC que es más lento que la memoria RAM.

Generalmente hablando, no.

Deduplicación requiere una cantidad significativa de RAM y puede realentizar los tiempos de acceso del disco para lectura y escritura. A no ser que se estén guardando datos que están altamente duplicados, tales como las maquinas virtuales o respaldos hechos por el usuario, es posible que la dedpulicación haga más mal que bien. Otra consideración es la incapacidad de revertir el estado de deduplicación. Si los datos son escritos al habilitar deduplicación, deshabilitar dedup no causara que los bloques que fueron deduplicados se repliquen hasta que estos vuelvan a ser modificados.

Deduplicación también puede llevar a situaciones inesperadas. En particular, borrar archivos puede volverse mucho más lento.

Esto puede ocurrir porque el pool esta 100% lleno. ZFS requiere espacio en el disco para escribir los metadatos de transacción. Para restaurar el pool a un estado usable, trunque el archivo a borrar:

% truncate -s 0 archivo-sin-importancia

La truncación de archivos funciona porque no se inicia una nueva transacción, en su lugar se crean nuevos bloques de repuesto.

El soporte para TRIM en ZFS fue añadido a FreeBSD 10-CURRENT con la revisión r240868. El soporte para TRIM en ZFS se agrego a todas las ramas FreeBSD-STABLE en r252162 y r251419, respectivamente.

TRIM esta habilitado por defecto en ZFS, y puede ser deshabilitado agregando esta línea a /etc/sysctl.conf:

vfs.zfs.trim_disable=1

El archivo de configuración principal es /etc/defaults/rc.conf el cual se describe en rc.conf(5). Los scripts de arranque del sistema tales como /etc/rc y /etc/rc.d, los cuales son descritos en rc(8), incluyen este archivo. ¡No edite este archivo! En su lugar, para editar una entrada en /etc/defaults/rc.conf, copie la línea a /etc/rc.conf y cámbiela allí.

Por ejemplo, para arrancar named(8), el servidor de DNS incluido

# echo 'named_enable="YES"' >> /etc/rc.conf

Para arrancar servicios locales, coloque los scripts de shell en el directorio /usr/local/etc/rc.d. Los scripts de shell deben ser ejecutables, el modo de archivo por defecto es 555.

Use el comando adduser(8), o el comando pw(8) para situaciones más complicadas.

Para remover el usuario, use el comando rmuser(8)o, si es necesario, pw(8).

Esto usualmente esta provocado por editar el crontab del sistema. Esta no es la manera correcta de hacer las cosas, dado que el crontab del sistema tiene un formato distinto para los crontabs por usuario. El crontab del sistema tiene un campo extra, especificando como que usuario se debe correr el comando. cron(8) asume que este usuario es la primera palabra del comando a ejecutar. Dado que no existe tal comando, aparece este mensaje de error.

Para borrar el contrab extra e incorrecto:

# crontab -r

Esta es una característica de seguridad. Para hacer su a root, o cualquier otra cuenta con privilegios de superusuario, la cuenta de usuario debe ser miembra del grupo wheel. Si esta característica no estuviera, cualquiera con una cuenta en el sistema que haya adivinado la contraseña de root podría ganar acceso de superusuario al sistema.

Para permitir que alguien haga su a root, póngalo(s) en el grupo wheel usando pw:

# pw groupmod wheel -m lisa

El ejemplo anterior agregara al usuario lisa al grupo wheel.

Reinicie el sistema usando boot -s en el indicador de arranque para entrar en el modo de un solo usuario. Cuando se le pida un nombre de ruta para el shell, presione Enter y corra mount -urw / para re-montar el sistema de archivos raíz en modo de lectura/escritura. Quizas también tenga que correr mount -a -t ufs para montar el sistema de archivos donde esta definido su editor favorito. Si ese editor esta en un sistema de archivos de red, configure la red manualmente antes de montar sistemas de archivos en red, o use un editor que redia en el sistema de archivos local, como ed(1).

Para usar un editor de pantalla completa tal como vi(1) o emacs(1), corra export TERM=xterm en FreeBSD 9.0+ de manera que estos editores puedan cargar correctamente los datos desde la base de datos de termcap(5).

Luego de realizar estos pasos, edite /etc/rc.conf para arreglar el error de sintaxis. El mensaje de error que se muestra inmediatamente luego de los mensajes de arranque del kernel debería indicar que número de línea en el archivo tiene el problema.

Vea la entrada del manual acerca de imprimir para consejos sobre como solucionar el problema.

Vea la sección del manual acerca de utilizar localización, específicamente la sección acerca de configuración de la consola.

Si, FreeBSD soporta IPC de tipo System V, incluyendo memoria compartida, mensajes y semáforos, en el kernel GENERIC. Con un kernel personalizado, el soporte puede cargarse con los módulos de kernel sysvshm.ko, sysvsem.ko y sysvmsg.ko, o habilitado en el kernel por defecto agregando las siguientes líneas al archivo de configuración del kernel:

options    SYSVSHM          # enable shared memory
options    SYSVSEM          # enable for semaphores
options    SYSVMSG          # enable for messaging

Recompile e instale el kernel.

El servidor Sendmail es el software servidor de correo por defecto para FreeBSD, pero puede ser reemplazado con otro MTA instalado desde la colección de ports. Los ports disponibles incluyen mail/exim, mail/postfix, y mail/qmail. Busque en las listas de correo para discusiones sobre las ventajas y desventajas de los MTAs disponibles.

¡No se desespere! Reinicie el sistema, escriba boot -s en el indicador Boot: para entrar en modo de un solo usuario. Cuando se le pregunte que shell usar, presione Enter lo cual mostrara el símbolo #. Ingrese mount -urw / para remontar el sistema de archivos raíz como lectura/escritura, luego corra mount -a para remontar todos los sistemas de archivos. Corra passwd root para cambiar la contraseña de root luego corra exit(1) para continuar con el arranque.

Cuando use syscons(4), el controlador por defecto dela consola, compile e instale un nuevo kernel con esta línea en el archivo de configuración:

options SC_DISABLE_REBOOT

Esto también puede hacerse ajustando el siguiente sysctl(8) que no requiere un reinicio o una recompilación de kernel:

# sysctl hw.syscons.kbd_reboot=0

Use este comando de perl(1):

% perl -i.bak -npe 's/\r\n/\n/g' file(s)

donde file(s) es uno o más archivos a procesar. La modificación se hace en el lugar, con el archivo original guardado con la extensión .bak.

Alternativamente, use tr(1):

% tr -d '\r' < dos-text-file > unix-file

dos-text-file es el archivo que contiene texto de DOS mientras que unix-file contendrá la salida convertida. Esto puede ser un poco más rápido que usar perl.

Otra forma de reformatear archivos de texto de DOS es usar el port converters/dosunix de la colección de ports. Consulte su documentación para más detalles.

Vaya al modo de un solo usuario y luego vuelva al modo multiusuario:

# shutdown now
# return
# exit

Respuesta corta: es solo un nombre. RC significa “Release Candidate”. Esto quiere decir que un lanzamiento es inminente. En FreeBSD, -PRERELEASE típicamente significa el congelamiento de código antes de un lanzamiento. (Para algunos lanzamientos, la etiqueta -BETA fue usada en la misma manera que -PRERELEASE.)

Respuesta larga: FreeBSD deriva sus lanzamientos actuales de uno de dos lugares. Las versiones mayores, punto cero, tales como 9.0-RELEASE se ramifican del punto mas adelantado del torrente de desarrollo, comúnmente denominado -CURRENT. Versiones menores, tales como 6.3-RELEASE o 5.2-RELEASE, fueron snapshots de la rama -STABLE activa. A partir de 4.3-RELEASE, cada versión ahora también tiene su propia rama que puede ser seguida por gente que requiera una velocidad de desarrollo extremadamente conservadora (típicamente solo avisos de seguridad).

Cuando esta a punto de hacerse un lanzamiento, la rama desde la cual sera derivada debe pasar por un cierto proceso. Parte de este proceso es un congelamiento de código. Cuando el mismo se inicia, el nombre de la rama se cambia para reflejar que esta a punto de convertirse en una versión. Por ejemplo, si la rama se solía llamar 6.2-STABLE, su nombre sera cambiado a 6.3-PRERELEASE para indicar el congelamiento de código y remarcar que habrá un testo extra pre-lanzamiento. Las correcciones de errores pueden seguir siendo commiteadas para formar parte del lanzamiento. Cuando el código fuente esta en forma para ser lanzado el nombre sera cambiado a 6.3-RC para indicar que se esta por hacer un lanzamiento a partir del mismo. Una vez en la fase de RC, solo los errores más críticos serán reparados. Una vez que el lanzamiento (6.3-RELEASE en este ejemplo) y la rama de la versión se hayan hecho, la rama sera renombrada a 6.3-STABLE.

Para más información acerca de números de version y varias ramas de Subversion, vea el artículo de Ingenieria de lanzamientos .

Respuesta corta: el nivel de seguridad es mayor a 0. Reinicie directamente al modo de un solo usuario para instalar el kernel.

Respuesta larga: FreeBSD deshabilita cambiar las banderas del sistema cuando los niveles de seguridad son mayores a 0. Para verificar el nivel actual de seguridad:

# sysctl kern.securelevel

El nivel de seguridad no puede ser bajado en modo multiusuario, de manera que reinicie al modo de un solo usuario para instalar el kernel, o cambie el nivel de seguridad en /etc/rc.conf y luego reinicie. Vea la pagina de manial de init(8) para más detalles acerca de securelevel, y vea /etc/defaults/rc.conf y la página de manual de rc.conf(5) para más información acerca de rc.conf.

Respuesta corta: el sistema esta en un nivel de seguridad mayor a 1. Reinicie directamente a modo de un solo usuario para cambiar la fecha.

Respuesta larga: FreeBSD deshabilita cambiar el tiempo por más de un segundo a niveles de seguridad mayores que 1. Para verificar el nivel de seguridad:

# sysctl kern.securelevel

El nivel de seguridad no puede ser reducido en modo multiusuario. Reinicie a modo de un solo usuario para cambiar la fecha o cambie el nivel de seguridad en /etc/rc.conf y reinicie. Vea la página de manual de init(8) para detalles acerca de securelevel, y vea /etc/defaults/rc.conf y la página de manual de rc.conf(5) para más información acerca de rc.conf.

No, no hay ningún desbordamiento de memoria, y no esta usando 256 MB de memoria. Para comodidad, rpc.statd mapea una cantidad obscena de memoria a su espacio de direcciones. No hay nada horriblemente malo con esto desde un punto de vista técnico; solo desorienta a procesos como top(1) y ps(1).

rpc.statd(8) mapea su archivo de estado (residente en /var) a su espacio de direcciones; para evitar preocuparse acerca de remapearlo luego cuando necesite crecer, lo mapea con un tamaño generoso. Esto es muy evidente en el código fuente, donde es posible ver que el argumento de longitud de mmap(2) es 0x10000000, o un dieciseisavo del espacio de direcciones en IA32, o exactamente 256 MB.

El sistema esta corriendo con un securelevel mayor a 0. Baje el securelevel e inténtelo de vuelta. Para mayor información vea la entrada de FAQ de securelevel y la página de manual de init(8).

vnlru limpia y libera vnodes cuando el sistema llega al límite de kern.maxvnodes. Este hilo de kernel esta ocioso, y solo se activa cuando hay una cantidad enorme de RAM y los usuarios están accediendo a miles de archivos pequeños.

Las páginas con frecuencia se escriben a disco (una especie de sincronización de VM) cuando están en el estado inactivo, pero las paginas activas también pueden sincronizarse. Esto depende del rastreo que haga CPU de la disponibilidad del bit de modificación, y en ciertas situaciones puede haber una ventaja para un bloque de páginas de VM al ser sincronizadas, tanto si están activas como inactivas. En la mayoría de los casos comunes, es mejor pensar de la cola inactiva como una cola de páginas relativamente sin usar que pueden o no estar en proceso de ser escritas a disco. La paginas en cache pueden estar ya sincronizadas, no mapeadas, pero disponibles para su uso inmediato por un proceso con su vieja asociación o con una nueva asociación. Las páginas libres están disponibles al nivel de interrupción, pero las páginas en cache o libres pueden ser usadas en el estado de proceso para ser reusadas. Las páginas en cache no se bloquean adecuadamente para estar disponibles al nivel de interrupción.

Hay algunas otras banderas There are some other flags (e.g., busy flag or busy count) que pueden modificar algunas de las reglas descritas.

Hay varios tipos de “memoria libre”. Un tipo es la cantidad de memoria directamente disponible sin paginar nada a disco. Esto es aproximadamente el tamaño de una cola de cache + el tamaño de la cola libre (con un factor de reducción de potencia, dependiendo de como se configure el sistema). Otro tipo de “memoria libre” es la cantidad total de espacio VM. Esto puede ser complejo, pero depende de la cantidad de espacio de intercambio y memoria. Otros tipos de descripciones de “memoria libre” también son posibles, pero es relativamente inútil definirlos, en su lugar es importante asegurarse de mantener el rango de paginación bajo, para evitar que se agote el espacio de intercambio.

/var/empty es un directorio que el programa sshd(8) usa al realizar la separación de privilegios. El directorio /var/empty esta vació, su dieño es root y tiene la bandera schg habilitada. Este directorio no debería ser borrado.

Para ver lo que haría newsyslog(8), use lo siguiente:

% newsyslog -nrvv

Use tzsetup(8).

El sistema X Window (comúnmente X11) es el sistema de ventanas más ampliamente disponible capaz de correr en UNIX® o sistemas de tipo UNIX®, incluyendo FreeBSD. La X.Org Foundation administra estándares de protocolo de X, con la implementación de referencia actual, versión 11 release 7.7, de modo que las referencias suelen acortarse a X11.

Exiten muchas implementaciones disponibles para diferentes arquitecturas y sistemas operativos. Una implementación del código del lado del servidor es conocida propiamente como un servidor X.

Para instalar Xorg siga uno de los siguientes pasos:

Use el meta-port x11/xorg, que compila e instala todos los componentes de Xorg.

Use x11/xorg-minimal, que compila e instala solo los componentes de Xorg necesarios.

Instale Xorg desde los paquetes de FreeBSD:

# pkg install xorg

Luego de la instalación de Xorg, siga las instrucciones de la sección Configuración de X11 del manual de FreeBSD.

El sistema probablemente este corriendo en un securelevel elevado. No es posible iniciar X en un securelevel elevado porque X requiere acceso de escritura a io(4). Para más información vea la página de manual de init(8).

Hay dos soluciones a este problema: ponga securelevel en cero o corra xdm(1) (o un gestor gráfico alternativo) en tiempo de arranque antes de que securelevel sea elevado.

Vea P: 11.10 para más información acerca de correr xdm(1) en tiempo de arranque.

Al usar syscons(4), el controlador de consola por defecto, FreeBSD puede configurarse para soportar un puntero del mouse en cada pantalla virtual. Para evitar entrar en conflico con X, syscons(4) soporta un dispositivo virtual llamado /dev/sysmouse. Todos los eventos del mouse recibidos del dispositivo real del mouse se escriben al dispositivo sysmouse(4) mediante moused(8). Para usar el mouse en una o más consolas virtuales, and use X, vea P: 4.4.1 y configuremoused(8).

Luego edite /etc/X11/xorg.conf y asegúrese de que las siguientes líneas existan:

Section "InputDevice"
   Option          "Protocol" "SysMouse"
   Option          "Device" "/dev/sysmouse"
.....

Empezando con la versión 7.4 de Xorg, las secciones InputDevice en xorg.conf son ignoradas en favor de los dispositivos autodetectados. Para restaurar el viejo comportamiento, agregue la siguiente línea a la sección ServerLayout o a ServerFlags:

Option "AutoAddDevices" "false"

Algunas personas prefieran usar /dev/mouse bajo X. Para hacer que esto funcione, /dev/mouse debería estar vinculado a /dev/sysmouse (vea sysmouse(4)) añadiendo la siguiente línea a /etc/devfs.conf (vea devfs.conf(5)):

link    sysmouse    mouse

Este vínculo puede ser creado reiniciando devfs(5) con el siguiente comando (como root):

# service devfs restart

Si, si X se configura para un mouse de 5 botones. Para hacer esto, agregue las líneas Buttons 5 y ZAxisMapping 4 5 a la sección “InputDevice” de /etc/X11/xorg.conf, como se ve en este ejemplo:

Section "InputDevice"
   Identifier      "Mouse1"
   Driver          "mouse"
   Option          "Protocol" "auto"
   Option          "Device" "/dev/sysmouse"
   Option          "Buttons" "5"
   Option          "ZAxisMapping" "4 5"
EndSection

Para usar el mouse en Emacs, también agregue las siguientes líneas a ~/.emacs:

;; wheel mouse
(global-set-key [mouse-4] 'scroll-down)
(global-set-key [mouse-5] 'scroll-up)

Si, luego de configurar un par de cosas para hacerlo funcionar.

Para usar el controlador de synaptics de Xorg, primero remueva moused_enable de rc.conf.

Para habilitar synaptics, agregue las siguiente línea a /boot/loader.conf:

hw.psm.synaptics_support="1"

Agregue lo siguiente a /etc/X11/xorg.conf:

Section "InputDevice"
Identifier  "Touchpad0"
Driver      "synaptics"
Option      "Protocol" "psm"
Option      "Device" "/dev/psm0"
EndSection

Y asegurese de añadir la siguiente línea a la sección “ServerLayout”:

InputDevice    "Touchpad0" "SendCoreEvents"

Por razones de seguridad, la configuración por defecto es no permitir que la maquina abra una ventana directamente.

Para habilitar esta característica arranque X con el argumento opcional -listen_tcp:

% startx -listen_tcp

Las consolas virtuales proveen varias sesiones simultaneas en una misma máquina sin hacer nada complicado como configurar una red o correr X.

Cuando arranca el sistema, se mostrara un indicador de arranque en el monitor luego de mostrar los mensajes de inicio. Escriba su nombre de usuario y contraseña para comenzar a trabajar en la primera consola virtual.

Para iniciar otra sesion, tal vez para ver documentación para un programa o para leer mail mientras espera que termine una transferencia por FTP, mantenga Alt y presione F2. Esto mostrara el indicador de inicio para la segunda consola virtual. Para volver a la sesión original presione Alt+F1.

La instalación por defecto de FreeBSD tiene ocho consolas virtuales habilitadas. Alt+F1, Alt+F2, Alt+F3, y demás iran cambiando entre estas consolas virtuales.

Para habilitar más consolas virtuales, edite /etc/ttys (vea ttys(5)) y añada entradas para ttyv8 hasta ttyvc, luego del comentario acerca de “terminales virtuales”:

# Edit the existing entry for ttyv8 in /etc/ttys and change
# "off" to "on".
ttyv8   "/usr/libexec/getty Pc"         xterm  on secure
ttyv9   "/usr/libexec/getty Pc"         xterm  on secure
ttyva   "/usr/libexec/getty Pc"         xterm  on secure
ttyvb   "/usr/libexec/getty Pc"         xterm  on secure

Cuantas más terminales virtuales, más recursos son usados. Esto puede ser problemático en sistemas con 8 MB de RAM o menos. Considere cambiar secure a insecure.

Por ejemplo, para correr X y once consolas virtuales, la configuración para la terminal 12 debería ser:

ttyvb   "/usr/libexec/getty Pc"         xterm  off secure

La manera más fácil de activar las consolas virtuales es reiniciar.

Use Ctrl+Alt+Fn para cambiar a una consola virtual. Presione Ctrl+Alt+F1 para volver a la primera consola virtual.

Al estar en una consola de texto, use Alt+Fn para moverse entre ellas.

Para volver a la sesión de X, cambie a la consola virtual corriendo X. Si se inicio X desde la línea de comandos usando startx, la sesión X se adjuntara a la siguiente consola virtual sin uso, no la consola de texto desde la cual fue invocada. Para ocho terminales virtuales activas, X correra en la novena, de modo que useAlt+F9.

Hay dos escuelas de pensamiento acerca de como arrancar xdm(1). Una escuela arranca xdm desde /etc/ttys (see ttys(5)) usando el ejemplo provisto, mientras la otra corre xdm desde rc.local (see rc(8)) o desde un script de X en /usr/local/etc/rc.d. Ambas son igualmente válidas, y una puede funcionar en situaciones donde la otra no. En ambos casos el resultado es el mismo: X mostrara un indicador de inicio gráfico.

El método ttys(5) tiene la ventaja de documentar en que vty iniciara X will y pasar la responsabilidad de reiniciar el servidor X al desloguearse a init(8). El método rc(8) hace que sea fácil hacer kill a xdm si hay un problema arrancando el servidor X.

Si se carga desde rc(8), xdm debería iniciarse sin argumentos. xdm debe arrancar luego de que corra getty(8), o de lo contrario getty y xdm estarán en conflicto, bloqueando la consola. La mejor manera de solucionar esto es hacer que el script duerma por 10 segundos y luego inicie xdm.

Al iniciar xdm desde /etc/ttys, aún hay una posibilidad de conflicto entre xdm y getty(8). Una manera de evitar esto es añadir el número de vt en /usr/local/lib/X11/xdm/Xservers:

:0 local /usr/local/bin/X vt4

El ejemplo de arriba indicara al servidor X que corra en /dev/ttyv3. Note que el número es mayor en uno. El servidor X cuenta la vty desde uno, mientras que el kernel de FreeBSD numera la vty desde cero.

Cuando X se inicia con startx, los permisos en /dev/console no serán cambiados, lo que hace que cosas como xterm -C y xconsole no funcionen.

Esto es por la manera en que los permisos de consola están configurados por defecto. En un sistema multiusuario, uno no necesariamente quiere que cualquier usuario pueda escribir en la consola del sistema. Para usuarios que se están autenticando directamente en una maquina con una VTY, el archivo fbtab(5) existe para resolver tales problemas.

En resumen, asegurese de que una línea no comentada de esta forma se encuentre en /etc/fbtab (vea fbtab(5)):

/dev/ttyv0 0600 /dev/console

Se asegurara que quien sea que escriba un log en /dev/ttyv0 sea el dueño de la consola.

El mouse y el controlador del mouse pueden haberse dessincronizado. En casos raros, el controlador puede también haber reportado erróneamente errores de sincronización:

psmintr: out of sync (xxxx != yyyy)

Si esto sucede, deshabilite el codigo de verificación de sincronización ajustando las banderas del controlador para el controlador del mouse PS/2 a 0x100. Esto puede lograrse más fácilmente añadiendo hint.psm.0.flags="0x100" a /boot/loader.conf y reiniciando.

Escriba xmodmap -e "pointer = 3 2 1". Añada este comando a ~/.xinitrc o ~/.xsession para hacer que esto pase de manera automática.

La respuesta detallada a esta pregunta puede encontrarse en la sección Splash Screens en tiempo de arranque del manual de FreeBSD.

Si. Use xmodmap(1) para definir que funciones deben realizar las teclas.

Asumiendo que todos los teclados de windows sean estándares, los códigos de teclas para estas tres teclas son los siguientes:

Para hacer que la tecla Windowsizquierda imprima una coma, intente esto.

# xmodmap -e "keycode 115 = comma"

Para que los mapeos de teclas de Windows se habiliten automáticamente cada vez que se inicia X, ponga los comandos xmodmap en ~/.xinitrc o, preferiblemente, cree un archivo ~/.xmodmaprc e incluya las opciones de xmodmap, una por línea, luego añada la siguiente línea a ~/.xinitrc:

xmodmap $HOME/.xmodmaprc

Por ejemplo, para mapear las 3 teclas para que sean F13, F14, y F15, respectivamente. Esto haría relativamente simple mapearlas a funciones útiles dentro de aplicaciones o del gestor de ventanas.

Para hacer esto, coloque lo siguiente en ~/.xmodmaprc.

keycode 115 = F13
keycode 116 = F14
keycode 117 = F15

Para el gestor de escritorio x11-wm/fvwm2, uno podría mapear las teclas de manera que F13 iconifique o desiconofique la ventana en la que esta el cursor, F14 traiga la ventana en la que esta el cursor al frente o, si ya se encuentra al frente la lleve al fondo, y F15 haga surgir el menu principal de Workplace incluso si el cursor no esta en el escritorio, lo cual es útil cuando no hay ninguna parte del escritorio visible.

Las siguientes entradas en ~/.fvwmrc implementan la configuración mencionada:

Key F13        FTIWS    A        Iconify
Key F14        FTIWS    A        RaiseLower
Key F15        A        A        Menu Workplace Nop

La disponibilidad de la aceleración 3D depende de la versión de Xorg y el tipo de chip de video. Para un chip nVidia, use los controladores binarios provistos por FreeBSD instalando uno de los siguientes ports:

Las ultimas versiones de tarjetas nVidia estan soportadas por el port x11/nvidia-driver.

Los controladores más viejos están disponibles como x11/nvidia-driver-###

nVidia provee información detallada acerca de que tarjeta esta soportada por que controlador en su sitio web: http://www.nvidia.com/object/IO_32667.html.

Para Matrox G200/G400, vea el port x11-servers/mga_hal.

Para ATI Rage 128 y Radeon vea ati(4), r128(4) y radeon(4).

“Arranque sin disco rígido” significa que la instalación de FreeBSD se arranca desde la red, y lee los archivos necesarios desde un servidor en lugar del disco rígido. Para más detalles, vea la entrada del manual acerca del arranque sin disco rígido.

Si. Vea la entrada del manual acerca de redes avanzadas, específicamente la sección acerca de routing y gateways.

Usualmente, la gente que pregunta esto tiene dos PCs en su casa, una con FreeBSD y una con alguna versión de Windows® la idea es usar la instalación de FreeBSD para conectarse a la Internet y así poder usar Internet desde la instalación de Windows® a través de FreeBSD. Esto es únicamente un caso especial de la pregunta anterior y funciona perfectamente bien.

Los usuarios de dialup deben usar -nat y ajustar gateway_enable a YES en /etc/rc.conf. Para más información, vea ppp(8) o la entrada del manual acerca de PPP de usuario.

Si la conexión a Internet es sobre Ethernet, use natd(8). Puede encontrarse un tutorial en la sección natd del manual.

Si. ppp(8) provee soporte para conexiones entrantes y salientes.

Para más información acerca de como usar esto, vea el capítulo del manual acerca de PPP.

Si. Para instrucciones acerca de como usar NAT sobre una conexión PPP, vea la entrada de manual acerca de PPP. Para usar NAT sobre otro tipo de conección de red, vea la sección acerca de natd en el manual.

Si el alias esta en la misma subred que una dirección ya configurada en la interfaz, agregue netmask 0xffffffff a este comando:

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

De otro modo, especifique la dirección de red y netmask de la manera usual:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

Puede encontrarse más información en el manual Handbook de FreeBSD.

Algunas versiones del código NFS de Linux® solo aceptan pedidos de montaje de un puerto privilegiado; intente con el siguiente comando:

# mount -o -P linuxbox:/blah /mnt

El problema mas frecuente es no entender el formato correcto de /etc/exports. Revise exports(5) y la entrada de NFS en el manual, especialmente la sección acerca de configurar NFS.

Instale el paquete o port net/mrouted y añada mrouted_enable="YES" a /etc/rc.conf inicie este servicio en tiempo de arranque.

Vea la respuesta en el manual de FreeBSD.

Si el kernel fue compilado con la opción IPFIREWALL, este al tanto de que la política por defecto es bloquear todos los paquetes que no estén explícitamente permitidos.

Si el firewall esta mal configurado, restaure la operabilidad de la red escribiendo lo siguiente como root:

# ipfw add 65534 allow all from any to any

Considere ajustar firewall_type="open" en /etc/rc.conf.

Para más información acerca de configurar este firewall vea el capítulo del manual.

Posiblemente porque la traducción de direcciones de red (NAT) es necesaria en lugar de simplemente envíar paquetes needed. Una regla “fwd” solo envía paquetes, no cambia realmente los datos adentro del paquete. Considere esta regla:

01000 fwd 10.0.0.1 from any to foo 21

Cuando un paquete con una dirección de destino de foo llega a la máquina con esta regla, el paquete es enviado a 10.0.0.1, pero todavía tiene la dirección de destino de foo. La dirección de destino del paquete no se cambia a 10.0.0.1. La mayoría de las máquinas probablemente tiren un paquete que reciben con una dirección de destino que no sea la propia. Por consiguiente, usar una regla “fwd” no necesariamente funciona de la manera que espera el usuario. Este comportamiento es una característica y no un error.

Va el FAQ acerca de redirigir servicios , el manual de natd(8), o una de las varias utilidades para redirigir puertos en la colección de ports para la manera correcta de hacer esto.

FTP y otros pedidos de servicios pueden ser redirigidos con el port o paquete sysutils/socket. Reemplace la entrada del servicio en /etc/inetd.conf para llamar a socket, como se puede ver en este ejemplo para ftpd:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

donde ftp.example.com y ftp son el host y el puerto a los que redirigirse, respectivamente.

Hay tres herramientas de manejo de ancho de banda disponibles para FreeBSD. dummynet(4) esta integrada en FreeBSD como parte de ipfw(4). ALTQ fue integrada a FreeBSD como parte de pf(4). Bandwidth Manager de Emerging Technologies es un producto comercial.

La aplicación que esta corriendo requiere Berkeley Packet Filter (bpf(4)), pero el mismo fue removido de un kernel personalizado. Agregue esto al archivo de configuración del kernel y compile un nuevo kernel:

device bpf        # Berkeley Packet Filter

Use el set de herramientas SMBFS. El mismo incluye un set de modificaciones al kernel y un set de programas de espacio de usuario. Los programas y la información están disponibles como mount_smbfs(8) en el sistema base.

Este mensaje del kernel indica que alguna actividad esta provocando que envie una gran cantidad de respuestas ICMP o TCP reset (RST). Las respuestas ICMP son con frecuencia generadas como un resultado de intentos de conexiones a puertos UDP sin usar. Los resets de TCP son generados como el resultado de intentos de conexiones a puertos TCP sin abrir. Entre otros, este tipo de actividades puede causar los siguientes mensajes:

El primer número en el mensaje indica cuantos paquetes hubiera enviado el kernel si el límite no existiera, y el segundo indica el límite. Este límite se controla usando net.inet.icmp.icmplim. Este ejemplo ajusta el límite a 300 paquetes por segundo:

# sysctl net.inet.icmp.icmplim=300

Para deshabilitar estos mensajes sin deshabilitar la limitación de la respuesta, use net.inet.icmp.icmplim_output para deshabilitar la salida:

# sysctl net.inet.icmp.icmplim_output=0

Finalmente, para deshabilitar completamente la limitación de la respuesta, ajuste net.inet.icmp.icmplim a 0. Deshabilitar la limitación de respuesta esta desaconsejado por las razones listadas anteriormente.

Esto significa que algún dispositivo en la Ethernet local esta usando una dirección MAC en un formato que FreeBSD no reconoce. Esto fue probablemente causado por alguien que experimento con una tarjeta Ethernet en otro lugar de la red. Esto puede verse más comúnmente en redes de cable modem modernas. No es dañino, y no debería afectar el rendimiento del sistema en FreeBSD.

Porque un paquete esta viniendo de afuera de la red inesperadamente. Para deshabilitarlos, ajuste net.link.ether.inet.log_arp_wrong_iface a 0.

“Sandbox”es un término de seguridad. Puede significar dos cosas:

UNIX® implementa dos sandboxes principales. Uno es a nivel proceso, el otro es a nivel userid.

Cada proceso UNIX® esta completamente aislado de cualquier otro proceso UNIX®. Un proceso no puede modificar el espacio de direcciones de otro.

Un proceso UNIX® tiene por dueño una userid en particular. Si el ID de susuario no es el usuario root, es útil aislar el proceso de procesos adueñados por otros usuarios. El ID de usuario también se usa para aislar datos del disco.

securelevel es un mecanismo de seguridad implementado en el kernel. Cuando un securelevel es positivo, el kernel restringe ciertas tareas; ni siquiera el superusuario (root) tiene permitido hacerlas. El mecanismo securelevel limita la habilidad de:

Para verificar el estado del securelevel en un sistema corriendo:

# sysctl -n kern.securelevel

La salida contiene el valor actual del securelevel. Si es mayor a 0, al menos algunas de las protecciones de securelevel están habilitadas.

El securelevel de un sistema corriendo no puede ser reducido dado que esto arruinaría su propósito. Si una tarea requiere que el securelevel sea no-positivo, cambie las variables kern_securelevel y kern_securelevel_enable en /etc/rc.conf y reinicie.

Para más información acerca de securelevel y lo que hace en particular cada nivel, consulte init(8).

BIND usa un numero al azar de puertos de número alto para consultas saliente. Las versiones recientes elijen un nuevo puerto UDP al azar para cada consulta. Esto puede causar problemas para algunas configuraciones de red, especialmente si un firewall bloquea paquetes UDP entrantes en puertos particulares. Para pasar ese firewall intente usar las opciones avoid-v4-udp-ports y avoid-v6-udp-ports para evitar elegir números de puertos al azar en un rango bloqueado.

Felicitaciones por cierto. ¡Es buena práctica leer la salida de sockstat(1)y notar cosas raras!

Las versiones recientes de Sendmail soportan una característica de envió de correo que corre sobre el puerto 587. Esto no esta soportado universalmente, pero esta creciendo en popularidad.

No se preocupe. toor es una cuenta de superusuario “alternativa”, en donde toor es root escrito al revés. Su propósito es ser usada como un shell no estándar de manera que el shell por defecto para root no necesite cambiar. Esto es importante dado que los shells que no son parte del sistema base, pero que en su lugar son instalados desde ports o packages, se instalan en /usr/local/bin el cual, por defecto, reside en un sistema de archivos distinto. SI el shell de root esta localizado en /usr/local/bin y el sistema de archivos conteniendo /usr/local/bin) no esta montado, root no sera capaz de autenticarse para arreglar un problema y tenga que reiniciar al modo de un solo usuario para ingresar a la ruta de un shell.

Alguna gente usa toor para tareas diarias de root con un shell no estándar, dejando a root, con un shell estándar, para modo de un solo usuario o emergencias. Por defecto, un usuario no puede autenticarse usando toor dado quen o tiene una contraseña, de modo que autentiquese como root e ingrese una contraseña para toor antes de usarlo para autenticarse.

Primero, lea ppp(8) y la sección del manual sobre PPP . Para asistir en la solución de problemas, habilite los logs con el siguiente comando:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Este comando debe ser escrito en el indicador de comandos de ppp(8)o puede ser ingresado al inicio de la sección default en /etc/ppp/ppp.conf. Asegurese de que /etc/syslog.conf contenga las líneas mostradas a continuación y que el archivo /var/log/ppp.log exista:

!ppp
*.*        /var/log/ppp.log

Mucho de lo que esta pasando puede verse en el archivo de log. No se preocupe si no tiene sentido dado que puede tener sentido para alguien más.

Esto suele ser porque le nombre de host no puede resolverse. La mejor manera de arreglar esto es asegurarse de que /etc/hosts sea leído primero asegurando que la línea hosts este listada primero en /etc/host.conf. Luego, agregue una entrada en /etc/hosts para la máquina local. Si no hay una red local, cambie la línea localhost:

127.0.0.1        foo.example.com foo localhost

De otra manera, agregue otra entrada para el host. Consulte las paginas de manual relevantes para más detalles.

Cuando termine, verifique que este comando corra exitosamente: ping -c1 `hostname`.

En primer lugar, verifique que exista una ruta por defecto. Este comando debería mostrar dos entradas:

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0

Si una ruta por defecto no se muestra, asegurese de que la línea HISADDR haya sido agregada a /etc/ppp/ppp.conf.

Otra razón para que la línea de la ruta por defecto falte es que se haya añadido una ruta por defecto a /etc/rc.conf y esta línea no este en /etc/ppp/ppp.conf:

delete ALL

Si este es el caso, vuelva a la sección Configuración final del sistema del manual.

Este error suele ocurrir porque la siguiente sección falta en /etc/ppp/ppp.linkup:

MYADDR:
  delete ALL
  add 0 0 HISADDR

Esto solo es necesario para una dirección de IP dinámica o cuando la dirección del gateway por defecto es desconocida. Cuando se usa modo interactivo, puede escribirse lo siguiente luego de entrar en modo de paquetes. El modo de paquetes esta indicado por las letras PPP en mayúscula en la consola:

delete ALL
add 0 0 HISADDR

Vea la sección sobre PPP y direcciones de IP dinámicas del manual para más detalles.

El timeout por defecto de PPP es de 3 minutos. Esto puede ajustarse con la siguiente línea:

set timeout NNN

donde NNN es el número de segundos de inactividad antes que la conexión se cierre. Si NNN es cero, la conexión nunca se cerrara debido a un timeout. Es posible poner este comando en ppp.conf, o escribirlo en la consola en modo interactivo. También es posible ajustarlo en tiempo real mientras las línea esta activa conectandose a el servidor de socket de ppp usando telnet(1) o pppctl(8). Vea la pagina de manual de ppp(8) para más detalles.

Si Link Quality Reporting (LQR) esta configurado, es posible que muchos paquetes LQR se hayan perdido entre el sistema FreeBSD y el peer. ppp(8) deduce que por consiguiente la línea debe estar mal, y se desconecta. LQR esta deshabilitado por defecto y puede habilitarse con la siguiente línea:

enable lqr

A veces, en una línea de teléfono con mucho ruido, o incluso una línea con llamada en espera habilitada, el modem puede colgar porque incorrectamente piensa que perdió el portador.

Hay un parámetro en la mayoría de los modems para determinar que tan tolerante debe ser a perdidas temporales del portador. Vea el manual del modem para más detalles.

Mucha gente experiencia conexiones que se cuelgan sin explicación aparente. Lo primero es estable que lado de la conexión esta colgado.

Al usar un modem externo, intente usar ping(8) para ver si la luz TD se enciendie cuando se transmiten datos. Si se enciende pero la luz RD no, el problema esta en el otro extremo. Si TD no se enciende, el problema es local. Con un modem interno, use el comando set server en ppp.conf. Cuando el cuelgue ocurra, conéctese a ppp(8) usando pppctl(8). Si la conexión a la red súbitamente revive debido a la actividad en el socket de diagnóstico, o si no se conecta pero debido al comando set socket tiene éxito en tiempo de inicio, el problema es local. Si puede conectarse pero continúan los cuelgues, habilite los logs locales conset log local async y use ping(8) desde otra ventana o terminal para hacer uso del link. El log asincrónico another mostrara los datos siendo transmitidos y recibidos en el link. Si los datos salen pero nunca vuelven, el problema es remoto.

Habiendo establecido si el problema es local o remoto, existen dos posibilidades:

Puede hacerse muy poco acerca de esto. Muchos ISPs se rehúsan a ayudar a los usuarios que no corran Microsoft® OS. Agregue enable lqr a /etc/ppp/ppp.conf, permitiendo ppp(8) para detectar el fallo o cuelgue remoto. Esta detección es relativamente lenta y por consiguiente no muy útil.

Primero, intente deshabilitar toda la compresión local agregando lo siguiente a la configuración:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Luego reconectese para asegurarse de que esto no hace la diferencia. Si las cosas mejoran o si el problema se soluciona por completo, determine que ajuste hace la diferencia mediante prueba y error. Esta es información útil para el ISP, aunque puede evidenciar que este no es un sistema Microsoft®.

Antes de contactar el ISP, habilite el logueo asincrónico localmente y espere a que la conexión se cuelgue nuevamente. Esto puede usar bastante espacio de disco. La última lectura de datos del puerto puede ser interesante. Usualmente se trata de datos ASCII, y puede incluso describir el problema (Memory fault, Core dumped).

Si el ISP es servicial, deberían poder habilitar logueo en su extremo, luego cuando la siguiente desconexión ocurra, podrían ser capaces de decir porque su extremo tiene un problema.

En este caso, recompile ppp(8) con información de debug, y luego use gdb(1) para obtener un stack trace desde el proceso de ppp que esta parado. Para recompilar la utilidad ppp con información de debug, escriba:

# cd /usr/src/usr.sbin/ppp
# env DEBUG_FLAGS='-g' make clean
# env DEBUG_FLAGS='-g' make install

Luego, reinicie ppp y espere a que se cuelgue nuevamente. Cuando la compilación de depuración de ppp se cuelgue, inicie gdb en el proceso que se colgó escribiendo:

# gdb ppp `pgrep ppp`

En la consola de gdb, use los comandos bt o where para obtener un stack trace. Guarde la salida de la sesión de gdb, y “separese” del proceso que esta corriendo escribiendo quit.

Ocasionalmente, justo después de conectare, puede haber mensajes en el log que digan Magic is same. A veces, estos mensajes son inofensivos, y a veces un lado u el otro sale. La mayoría de las implementaciones de PPP no pueden sobrevivir a este problema, incluso si el link parace activarse, habrá pedidos de configuración repetidos y reconocimientos de configuración en el archivo de log hasta que ppp(8) eventualmente se rinda y cierre la conexión.

Esto normalemente sucede en maquinas del servidor con discos lentos que lancen una ppp(8) en el puerto y ejectuen ppp(8) desde un script de inicio u otro programa luego de la autenticación. Existen reportes de que esto sucede consistentemente al usar slirp. La razón es que en el tiempo entre que getty(8)salga y ppp(8) inicie, el ppp(8) del lado del cliente comienza a enviar paquetes Line Control Protocol (LCP). Porque ECHO sigue siendo cambiado para el puerto en el servidor, el cliente ppp(8) ve estos paquetes “reflejarse” de vuelta.

Una parte de la negociación LCP consiste en establecer un numero mágico para cada lado del link de manera que se puedan detectar “reflexiones”. El protocolo dice que cuando el peer intenta negociar el mismo número mágico, debe enviarse un NAK y se debe elegir un nuevo numero mágico. Durante el período en que el puerto del servidor tiene ECHO prendido, el cliente ppp(8) envía paquetes LCP, ve el mismo numero mágico en el paquete reflejado y le envía un NAK. También ve el reflejado el NAK (lo que también significa que ppp(8) debe cambiar su numero mágico). Esto produce un enorme número de potenciales cambios de números mágicos, todos los cuales se apilan en el buffer del tty del servidor. Tan pronto como ppp(8) inicia en el servidor, se satura de cambios de numero mágico y casi inmediatamente decide que intento lo suficiente negociar LCP y termina. Mientras tanto, el cliente, que ha dejado de ver las reflexiones, se vuelve satisfecho justo a tiempo para ver un cuelgue del servidor.

Esto puede evitarse permitiéndole al peer comenzar la negocación con la siguiente línea en ppp.conf:

set openmode passive

Esto le dice a ppp(8) que espere al que el servidor inicie las negociaciones LCP. Algunos servidor pueden no obstante nunca iniciar las negociaciones. En este caso, intente algo como:

set openmode active 3

Esto le dice a ppp(8) que sea pasivo por 3 segundos, y luego comience a enviar pedidos LCP. Si el peer comienza a enviar pedidos durante este período, ppp(8) responderá inmediatamente en lugar de esperar el período completo de 3 segundos.

Eixte actualmente un error de implementación en ppp(8) donde no se asocian las respuesta LCP, CCP & IPCP con sus pedidos originales. Como resultado, si una implementación de PPP es más lenta que la del otro lado por 6 segundos o más, el otro lado enviara dos pedidos de configuración LCP adicionales. Esto es fatal.

Considere dos implementaciones, A y B. A comienza a enviar pedidos LCP inmediatamente luego de conectarse y a B le lleva 7 segundos iniciar. Cuando B inicia, A ha enviado 3 REQs LCP. Asumimos que la línea tiene ECHO desactivado, de otra forma veríamos problemas con los números mágicos como vimos en la sección previa. B envía una REQ, y luego un ACK al primero de los REQs de A. Esto resulta en A entrando al estado OPENED y enviando un ACK (del primero) de vuelta a B. Mientras tanto, B envía de vuelta dos ACKs más en respuesta a las dos REQs adicionales enviadas por A antes de que B haya iniciado. B luego pasa a recibir el primero ACK de A y entra al estado OPENED. A revice el segundo ACK de B y vuelve al estado REQ-SENT, enviando otro REQ (adelantado) de acuerdo con la RFC. Luego recibe el tercer ACK y entra en el estado OPENED. En el entremedio, B recibe el REQ adelantado desde A, resultando en el mismo revirtiendo al estado ACK-SENT y enviando otro (segundo) REQ y ACK (adelantado) de acuerdo con la RFC. A obtiene el REQ, se pone en modoREQ-SENT y envía otra REQ. Inmediatamente recive el siguiente ACK y entra a modo OPENED.

Esto continua hasta que uno de los lados se de cuenta de que no están llegando a ningún lado y termine.

La mejor manera de evitar esto es configurar un lado para ser passive — esto es, hacer que un lado espere al otro para comenzar a negociar. Esto puede hacerse con el siguiente comando:

set openmode passive

Se debe tener cuidado con esta opción. Este comando también puede usarse para limitar la cantidad de tiempo que ppp(8) espera a que el peer comienze las negociaciones.

set stopped N

Alternativamente, el siguiente comando (donde N es el número de segundos a esperar antes de iniciar las negociaciones) puede ser usado:

set openmode active N

Verifique la página de manual para detalles.

Al usar shell o !, ppp(8) ejecuta un shell o los argumentos pasados. El programa ppp esperara a que el comando se complete antes de continuar. Cualquier intento de usar el link de PPP mientras se correr el comando aparecerá como un link paralizado. Esto es porque ppp(8) espera a que el comando se complete.

Para ejecutar comandos como este, use !bg en su lugar. Esto ejecutara el comando dado en el trasfondo, y ppp(8) puede continuar sirviendo el link.

No hay forma de que ppp(8) automáticamente determine que una conexión directa fue terminada. Esto es debido a que las líneas usadas en el cable de serie de un modem nulo. Al usar este tipo de conexión, LQR siempre debería ser habilitado con la siguiente línea:

enable lqr

LQR es aceptado por defecto si es negociado por el peer.

Si ppp(8) marca de manera inesperada, determine la causa y ajuste los filtros de marcación para prevenir dicha llamada.

Para determinar la causa, use la próxima línea:

set log +tcp/ip

Esto escribirá un log con todo el trafico de la conexión. La próxima vez que esta línea surja inesperadamente, la razón será logueada con una conveniente estampa temporal a su lado.

Luego, deshabilite el marcado bajo estas circunstancias. Usualmente, este tipo de problema se da debido a las búsquedas de DNS. Para prevenir que las búsquedas de DNS establezcan una conexión (esto no prevendrá que ppp(8) pase los paquetes a través de una conexión establecida), use lo siguiente:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

Esto no siempre es aceptable, dado que romperá las capacidades de demanda de marcado. La mayoría de los programas necesitaran una búsqueda de DNS antes de hacer otras cosas relacionadas con la red.

En el caso del DNS, intente determinar que es lo que esta realmente intentando resolver un nombre de host. La mayoría del tiempo, Sendmail es el culpable. Asegúrese de configurar Sendmail para que no realize ninguna búsqueda de DNS en su archivo de configuración. Vea la sección acerca de usar email con una conexión de dialup en el manual de FreeBSD para los detalles. Probablemente también quiera además agregar la siguiente línea a .mc:

define(`confDELIVERY_MODE', `d')dnl

Esto hara que Sendmail encole todo hasta que se corra la cola, usualmente cada 30 minutos, o hasta que se haga sendmail -q, tal vez desde /etc/ppp/ppp.linkup.

Continuo viendo los siguientes errores en mi archivo de log:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

Esto ocurre porque ppp(8) esta intentando negociar compresión Predictor1, pero el peer no quiere negociar compresión en absoluto. Los mensajes son inofensivos, pero pueden ser silenciados deshabilitando la compresión:

disable pred1

Para escribir en el log todas las líneas de la conversación de modem, agregue lo siguiente:

set log +connect

Esto hara que ppp(8) escriba en el log todo hasta la última cadena “expect” pedida.

Para ver la velocidad de conexión al usar PAP o CHAP, asegúrese de configurar ppp(8) para que espere la línea CONNECT entera, usando algo como esto:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Esto obtiene la línea CONNECT, no envía nada, y luego espera una nueva línea, forzando a ppp(8) a leer toda la respuesta CONNECT.

La utilidad ppp parsea cada línea en sus archivos de configuración de manera que pueda interpretar cadenas como set phone "123 456 789" correctamente y darse cuenta de que el número es solo un argumento. Para especificar un carácter ", escapeelo utilizando una barra invertida (\).

Cuando el interprete de chat parsea cada argumento, reinterpreta el argumento para buscar cualquier secuencia de escape especial tales como \P o \T. Como resultado de este doble parsea, recuerde usar el número correcto de escapes.

Para realmente envíar un carácter \, haga algo como:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Esto resultara en la siguiente secuencia:

ATZ
OK
AT\X
OK

Ó:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

Esto resultara en la siguiente secuencia:

ATZ
OK
ATDT1234567

FCS significa Frame Check Secuence (secuencia de verificación de marcos). Cada paquete PPP tiene un checksum asignado para asegurarse que los datos que están siendo recibidos son los datos que se envían. Si el FCS de un paquete entrante es incorrecto, el paquete es tirado y la cuenta de HDLC de FCS se incrementa. Los valores de error de HDLC pueden mostrarse usando el comando show hdlc.

Si el link esta mal o el controlador de serie comienza a desechar paquetes, producirá el error de FCS ocasional. Esto no suele ser algo por lo que valga la pena preocuparse, aunque ralentiza los protocolos de compresión substancialmente.

Si el link se paraliza tan pronto como se conecta y produce ung ran numero de errores de FCS, asegurese de que el modem no este usando control de flujo por software (XON/XOFF). Si el link debe usar control de flujo por software, use set accmap 0x000a0000 para decirle a ppp(8) que escapee los caracteres ^Q y ^S.

Otra razón para tener demasiados errores de FCS puede ser que el extremo remoto haya dejado de comunicarse con PPP. En este caso, habilite el logueo async para determinar si los datos entrantes son de un inicio de sesión o un indicador del shell. Si se trata de un indicador del shell en el textrmo remoto, es posible terminar ppp(8) sin desechar la línea usando close lcp seguido de term) para reconectarse al shell en la máquina remota.

Si nada en el archivo de log indica porque el ink fue terminado, pregúntele al administrador remoto o su ISP porque la sesión termino.

Si todo lo demás falla, envíe los detalles del error, los archivos de configuración, como se esta iniciando ppp(8), las partes reelevantes del archivo de log, y la salida de netstat -rn, antes y después de conectarse, a la lista de correo de preguntas generales de FreeBSD.

Hay una lista de las mismas en el capítulo Comunicaciones en serie del manual.

Las tarjetas multipuertos PCI que estén basadas en 16550 o clones están soportadas sin ningún esfuerzo extra.

Se ha reportado tambíen que algunas tarjetas clon variadas funcionan, especialmente aquellas que dicen ser compatibles con AST.

Vea uart(4) and sio(4) para obtener más información acerca de configurar tales tarjetas.

Vea esta sección del manual.

Mientras el kernel de FreeBSD arranca, verificara los puertos en serie para los que esta configurado el kernel. Vea los mensajes de inicio con atención o corra este comando luego de que el sistema haya arrancado:

% dmesg | grep -E "^sio[0-9]"
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A

Esta salida de ejemplo muestra dos puertos en serie. El primero esta en IRQ4, en la dirección de puerto 0x3f8, y tiene un chip de tipo 16550A-type UART. El segundo usa el mismo tipo de chip pero esta en IRQ3 y esta en la dirección de puerto 0x2f8. Las tarjetas de modem internas también son tratadas como puertos en serie, excepto que siempre tienen un modem adjuntado al puerto.

El kernel GENERIC incluye soporte para dos puertos en serie usando los mismos ajustes de dirección de puerto e IRQ en el ejemplo anterior. Si estos ajustes no son adecuados para el sistema, o si hay más tarjetas de modem o puertos en serie que los que tiene configurado el kernel, reconfigure usando las instrucciones en compilar un kernel para más detalles.

El tercer puerto en serie sio2, o COM3, esta en /dev/cuad2 para dispositivos de marcado saliente, y en /dev/ttyd2 para dispositivos de marcado entrante. ¿Cuál es la diferencia entre estas dos clases de dispositivos?

Al abrir /dev/ttydX en modo bloqueante, un proceso esperara a que el correspondiente dispositivo cuadX se vuelva inactivo, y luego espera a que la línea de detección del portador pase a estar activa. Cuando el dispositivo cuadX es abierto, se asegura de que el puerto en serie no este ya en uso por el dispositivo ttydX. Si el puerto esta disponible, se lo roba al dispositivo ttydX. Además, el dispositivo cuadX no se preocupa por la detección del portador. Con este esquema y un modem de auto-respuesta, los usuarios remotos pueden autenticarse y los usuarios locales aún pueden marcar fuera con el mismo modem y el sistema se ocupara de todos los conflictos.

La sección acerca de configuración del kernel provee información acerca de configurar el kernel. Para una tarjeta en serie multipuertos, coloque una línea sio(4) por cada puerte en serie en la tarjeta en el archivo device.hints(5). Pero coloque los especificadores IRQ en solo una de las entradas. Todos los puertos en la tarjeta deberían compartir un solo IRQ. Por consistencia, use el último puerto en serie para especificar el IRQ. También especifique la siguiente opción en el archivo de configuración del kernel:

options COM_MULTIPORT

El siguiente ejemplo de /boot/device.hints es para una tarjeta en serie AST de 4 puertos en IRQ 12:

hint.sio.4.at="isa"
hint.sio.4.port="0x2a0"
hint.sio.4.flags="0x701"
hint.sio.5.at="isa"
hint.sio.5.port="0x2a8"
hint.sio.5.flags="0x701"
hint.sio.6.at="isa"
hint.sio.6.port="0x2b0"
hint.sio.6.flags="0x701"
hint.sio.7.at="isa"
hint.sio.7.port="0x2b8"
hint.sio.7.flags="0x701"
hint.sio.7.irq="12"

Estas banderas indican que el puerto maestro tiene un número menor 7 (0x700), y que todos los puertos comparten un IRQ (0x001).

Vea la sección Comunicaciones en serieen el manual de FreeBSD.

Vea la sección acerca de Servicios de marcado en el manual de FreeBSD.

Esta información puede encontrarse en la sección Terminales del manual de FreeBSD.

Las utilidades tip(1) y cu(1) incluidas solo pueden acceder el directorio /var/spool/lock mediante el usuario uucp y el grupo dialer. Use el grupo dialer para controlar quien tiene acceso al modem o sistemas remotos agregando cuentas de usuario a dialer.

Alternativamente, todos pueden configurarse para correr tip(1) and cu(1) escribiendo:

# chmod 4511 /usr/bin/cu
# chmod 4511 /usr/bin/tip

FreeBSD mueve proactivamente las páginas sin usar, enteramente ociosas de la memoria principal a swap para lograr que mas memoria principal este disponible para su uso. Este uso intensivo de sqp se balancea al usar la memoria extra como cache.

Note que mientras que FreeBSD es proactivo en este modo, no decide arbitrariamente hacer swap de páginas cuando el sistema esta verdaderamente ocioso. Por consiguiente, el sistema no habrá pagina completamente a disco luego de dejarlo ocioso por una noche.

La respuesta simple es que la memoria libre es memoria gastada. Cualquier memoria que los programas no alocan activamente es usada en el kernel de FreeBSD como cache de disco. Los valores mostrados por top(1) marcados como Inact, Cache, y Buf son datos en cache con diferentes niveles de envejecimiento. Estos datos en cache significan que el sistema no tiene que acceder a un disco lento nuevamente para datos que accedió recientemente, incrementando la performance general. En general, un valor bajo para Free en top(1) es bueno, asumiendo que no sea muy bajo.

Los symlinks no tienen permisos, y por defecto, chmod(1) seguirá los symlinks para cambiar los permisos en el archivo fuente, de ser posible. Para el archivo, foo co un symlink llamado bar, este comando siempre tendrá éxito.

% chmod g-w bar

Sin embargo, los permisos en bar no habrán cambiado.

Al cambiar los modos de las jerarquías de archivo que tienen raíz en los archivos en lugar de los archivos mismos, use -H o -L en conjunto con -R para hacer que esto funciona. Vea chmod(1) y symlink(7) para más información.

% chmod 555 foo/

Si. Un programa de emulación de DOS, emulators/doscmd, esta disponible en la colección de ports de FreeBSD.

Si doscmd no es suficiente, emulators/pcemu emula un 8088 y suficientes servicios de BIOS para correr muchas aplicaciones de DOS en modo texto. Requiere el sistema X Window.

La colección de ports también tiene emulators/dosbox. El foco principal de esta aplicación es emular juegos viejos de DOS usando el sistema de archivos local para los archivos.

Vea el FAQ de Traducciones en la documentación en el Primer de documentación FreeBSD.

El sistema de correo de FreeBSD.org implementa algunas de las verificaciones de Postfix sobre el correo entrante y rechaza el correo que proviene de relays mal configurados o que parece ser spam. Algunos de los requisitos específicos son:

Otros consejos para ayudar a que el correo llegue incluyen:

Si tiene problemas con la infraestructura de correo de FreeBSD.org, envíe una nota con los detalles a <postmaster@freebsd.org>; Incluya un intervalo de hora/fecha de manera que los logs puedan ser revisados — y tenga en cuenta que solo mantenemos logs de correo por una semana. (Asegurese de especificar la zona temporal o el offset desde UTC.)

Mientras que FreeBSD no provee acceso abierto a ninguno de sus servidores, otros proveen sistemas UNIX® de acceso abierto. El costo varía y puede que estén disponibles servicios limitados.

Arbornet, Inc, también conocida como M-Net, ha estado proveyendo acceso abierto a sistemas UNIX® desde 1983. Empezando con un Altos corriendo System III, el sitio cambio a BSD/OS en 1991. En junio del 2000, el sitio cambio nuevamente a FreeBSD. M-Net puede ser accedido mediante telnet y SSH y provee acceso básico para la suite de software entera de FreeBSD. Sin embargo, el acceso a la red esta limitado a miembros y patrocinadores que donan al sistema, el cual es mantenido por una organización sin fines de lucro. M-Net también provee un sistema de bulletin board y un chat interactivo.

No tiene ningún nombre, sencillamente se lo llama “el demonio de BSD”. Si insiste en usar un nombre, llamelo “beastie”. Note que “beastie” se pronuncia “BSD”.

Más información acerca del demonio de BSD esta disponible en su pagina web.

Tal vez. El demonio de BSD esta registrado con derechos de autor por Marshall Kirk McKusick. Vea su Declaración acerca del uso de la figura del demonio de BSD para términos de uso detallados.

En resumen, la imagen puede ser usada de una manera respetuosa, para uso personal, mientras que se de el crédito apropiado. Antes de usar el logo comercialmente, contacte a Kirk McKusick <mckusick@FreeBSD.org> para obtener permiso.

Dibujos en Xfig y eps están disponibles en /usr/share/examples/BSD_daemon/.

Vea el glosario de FreeBSD.

La respuesta verdaderamente corta es que no debería. La respuesta un poco más larga es que solo porque usted es capaz de construir un cobertizo para bicicletas no significa que debería evitar que otros construyan uno solo porque no le gusta el color del que lo quieren pintar. Esta es una metáfora indicando que no necesita discutir sobre cada pequeña característica solo porque tiene el conocimiento para hacerlo. Algunas personas comentaron que la cantidad de ruido generada por un cambio es inversamente proporcional a la complejidad del cambio.

Una respuesta más larga y completa es que luego de una larga discusión acerca de si sleep(1) debería tomar argumentos de segundos fraccionales, <phk@FreeBSD.org> posteo un largo mensaje titulado “A bike shed (any color will do) on greener grass...”. Las porciones apropiadas de ese mensaje son citadas más abajo.

Q. ¿Alguien ha hecho alguna prueba de temperatura al correr FreeBSD? Se que linux Linux® es más frío que DOS, pero jamás vi alguna mención a FreeBSD. Parece que sobrecalienta bastante.

A. No pero he hecho numerosas pruebas de gusto en voluntarios que tomaron 250 microgramos de LSD-25 administrados previamente. El 35% de los voluntarios dijo que FreeBSD sabe a naranja, mientras que Linux® sabe a humo violeta. Ningún grupo menciono nada acerca de variaciones en la temperatura. Eventualmente debimos desechar los resultados de esta encuesta de todas formas al enterarnos que demasiado voluntarios estaban deambulando fuera del cuarto durante las pruebas, arruinando los resultados. Pensamos que la mayoría de los voluntarios están en Apple ahora, trabajando en su nueva GUI “scratch and sniff”. ¡Es un negocio divertido el nuestro!

En serio, FreeBSD usa la instrucción HLT (halt) cuando el sistema esta ocioso, de esta manera reduciendo su consumo de energía y eventualmente el calor que genera. Además, si ha configurado ACPI (Advanced Configuration and Power Interface), entonces FreeBSD también puede poner la CPU en modo de bajo consumo.

Q. ¿Hay algo “extraño” que FreeBSD hace al compilar el kernel que pueda causar que la memoria haga un sonido de rasguño? Al compilar (y por un breve momento luego de reconocer el disco floppy en el arranque), un extraño sonido como un arañazo emana de lo que parecen ser los bancos de memoria.

A. ¡Si! Vera frecuentes referencias a “demonios” en la documentación de BSD y lo que la mayoría de la gente no sabe es que esto se refiere a entidades genuinas e incorpóreas que ahora poseen su computadora. El sonido de arañazos que viene desde su memoria es de hecho un silbido de alta frecuencia intercambiado por los demonios mientras deciden como lidiar con varias tareas administrativas del sistema.

Si el sonido lo empieza a molestar, un buen fdisk /mbr desde DOS se librara de ellos, pero no se sorprenda si reaccionan adversamente e intentan detenerlo. De hecho, si en cualquier punto del ejercicio usted escucha la voz satánica de Bill Gates viniendo desde el parlante incorporado... ¡Salga corriendo y no mire hacia atrás! Libre de las influencias de contrapeso de los demonios de BSD, los demonios gemelos de DOS y Windows® suelen poder asegurarse el control total de su máquina y la condenación eterna de su alma. ¿Ahora que lo sabe, dada la oportunidad preferiría acostumbrarse a los sonidos de rasguños, verdad?

Mil ciento sesenta y nueve.

Veintitrés para quejarse en -CURRENT que las luces están apagadas;

Cuatro para declarar que es un problema de configuración, y que tales cuestiones pertenecen a -questions;

Tres para envíar PRs acerca de ello, uno de los cuales fue enviado erróneamente bajo doc y consiste solo de “esta oscuro”;

Uno para commitear un foco de luz no probado que rompe buildworld, y luego revertirlo cinco minutos después;

Ocho para agredir a los que envíaron el PR por no incluir parches en sus PRs;

Cinco para quejarse de que buildworld esta roto;

Treinta y uno para responder que funciona para ellos, y que deben haber actualizado en un mal momento;

Uno para postear un parche para un nuevo foco de luz a -hackers;

Uno para quejarse de que tuvo parches para esto hace tres años, pero cuando los envío a -CURRENT fueron ignorados, y que tuvo malas experiencias con el sistema de PR; además, el nuevo foco de luz propuesto no es reflexivo.

Treinta y siete para gritar que los focos de luz no pertenecen en el sistema base, que los commiters no tienen derecho a hacer estas cosas sin consultar con la comunidad, y ¡¿QUE ESTA HACIENDO CORE ACERCA DE ESTO?!

Doscientos para quejarse del color del cobertizo de bicicletas.

Tres para señalar que el parche no respeta style(9);

Diecisiete para quejarse de que el nuevo foco de luz propuesto esta bajo la GPL;

Quinientos ochenta y seis para iniciar una discusión acerca de las ventajas comparativas de la GPL, la licencia BSD, la licencia MIT, la NPL, y la higiene personal de fundadores no especificados de la FSF;

Siete para mover varias partes del thread a -chat y -advocacy;

Uno para commitear el foco de luz sugerido, aunque brille de manera más tenue que el viejo;

Dos para revertirlo con una furiosa discusión en un mensaje de commit, arguyendo que FreeBSD esta mejor en la oscuridad que con un foco de luz oscuro;

Cuarenta y seis para discutir vociferantemente acerca de la reversión del foco de luz tenue y demandando una declaración por parte de -core;

Once para pedir un foco de luz más pequeño de manera que entre en su Tamagotchi si deciden hacer un port de FreeBSD para esa plataforma;

Setenta y tres para quejarse acerca de SNR en -hackers y -chat y cancelar su subscripción como protesta;

Trece para postear “cancelar subscripción”, “¿Como cancelo la subscripción?”, o “Por favor sáquenme de la lista”, seguidos del pie usual;

Uno para hacer un commit de un foco de luz funcional mientras que todo el mundo esta demasiado ocupado agrediendo a todos los demás como para notarlo;

Treinta y uno para señalar que el nuevo foco de luz seria un 0.364% más brillante si se compila con TenDRA (aunque tendría que ser remodelado en forma cúbica), y que FreeBSD debería cambiar a TenDRA en lugar de usar GCC;

Uno para quejarse de que el nuevo foco de luz no tiene carenados;

Nuevo (incluyendo los que crearon el PR) para preguntar “¿Qué es MFC?”;

Cincueta y siete para quejarse acerca de que las luces estuvieron apagadas por dos semanas luego de que se cambio el foco.

Nik Clayton <nik@FreeBSD.org> añade:

Me estaba riendo bastante con esto.

Y luego pense, “Un momento ¿No debería haber '1 para documentarlo.' en algún lugar de esa lista?”

Y luego me ilumine :-)

Thomas Abthorpe <tabthorpe@FreeBSD.org> dice: “Ninguno ¡Los verdaderos hackers de FreeBSD no tienen miedo a la oscuridad!”

Va a un disipador de datos especial en la CPU en donde es convertido en calor el cual es ventilado a través del conjunto disipador de calor / ventilador. Esto es por lo que el enfriado de CPU es cada vez más importante; mientras la gente se acostumbra a procesadores más rápidos se vuelven descuidados con sus datos y más y más termina en /dev/null, sobrecalentando sus CPUs. Si borra /dev/null (lo cual efectivamente deshabilita el su effectively el disipador de datos de CPU) su CPU podría correr a menos temperatura pero su sistema se volverá rápidamente constipado con todos los datos en exceso y comenzara a comportarse erráticamente. Si tiene una conexión de red rápida puede enfriar su CPU leyendo datos de /dev/random y enviándolos a algún lugar; sin embargo corre el riesgo de sobrecalentar su conexión de red y / o hacer enojar a su ISP, dado que la mayoría de los datos terminaran siendo convertidos en calor por su equipo, pero ellos generalmente tienen buena disipación de calor, de modo que si no se sobrepasa estará bien.

Paul Robinson añade:

Hay otros métodos. Como todo buen sysadmin sabe, es parte de las prácticas estándares envíar datos a la pantalla de variedad interesante para mantener los pixies y hacer feliz a sus fotos. Los pixies de pantalla (comúnmente mal escritos o renombrados como “pixels”) son categorizados por el tipo de sombrero que llevan puesto (rojo, verde o azul) y se esconderán o aparecerán (de esta forma mostrando el color de su sombrero) cuando reciban un pedazo de comida. Las tarjetas de video convierten datos en comida para pixies y se la mandan a los pixies — cuanto más cara la tarjeta, mejor es la comida, y mejor se comportan los pixies. También necesitan estimulación constante — por esto es que existen los salvapantallas.

Para llevar más sus sugerencias, podría arrojar datos al azar a la consola, por consiguiente dejando que los pixies lo consuman. Esto hace que no se produzca calor en absoluto, mantiene los pixies felices y se deshace de sus datos realmente rápido, incluso si hace que las cosas se vean un poco desorganizadas en su pantalla.

Accidentalmente, como un ex-administrador de un gran ISP que ha experimentado muchos problemas intentando mantener una temperatura estable en el cuarto de servidores, desaconsejo fuertemente el que la gente envíe datos indeseados a la red. A las hadas que se encargan de el intercambio de paquetes y el ruteo también les molesta.

Instale games/sl y espere a que ella se equivoque al escribir sl en vez de ls.

Vea el Manual de arquitectura de FreeBSD.

Además, la mayor parte del conocimiento general acerca de UNIX®es directamente aplicable a FreeBSD.

Vea el artículo acerca de Contribuir a FreeBSD para consejos específicos acerca de como hacer esto. ¡La ayuda es más que bienvenida!

Hay actualmente 3 ramas activas/semi activas en el repositorio Subversion de FreeBSD. (Las ramas anteriores cambian muy raramente, que es por lo cual solo hay 3 ramas de desarrollo activas):

HEAD no es realmente un tag de rama. Es una constante simbólica para el torrente de desarrollo actual, no ramificado conocido como -CURRENT.

En este momento, -CURRENT es el torrente de desarrollo 11.X; la rama 10-STABLE, stable/10/, se ramifico de -CURRENT en Enero del 2014 y la rama 9-STABLE, stable/9/, se ramifico de -CURRENT en Septiembre del 2011.

Si, esto puede hacerse sin descargar el árbol de código fuente entero usando la utilidad CTM.

Vea el artículo en Contribuyendo a FreeBSD para aprender como enviar código.

¡Y gracias por haberlo pensado!

Este es un típico pánico de kernel:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x40
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xf014a7e5
stack pointer           = 0x10:0xf4ed6f24
frame pointer           = 0x10:0xf4ed6f28
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 80 (mount)
interrupt mask          =
trap number             = 12
panic: page fault

Este mensaje no es suficiente. Mientras que el valor del puntero de instrucción es importante, también depende de la configuración varía en cada imagen de kernel. Si es un kernel GENERIC desde uno de los snapshots, es posible que alguien más rastree la función problemática, pero para un kernel personalizado, solo usted puede decirnos donde ocurrió el fallo.

Para proceder:

Sin embargo, la mejor manera de rastrear la causa del pánico es capturando un volcado de fallos, y luego usando kgdb(1) para generar un seguimiento de pila sobre el volcado de fallos.

En cualquier caso, el método es este:

El proceso make(1) habrá compilado dos kernels. /usr/obj/usr/src/sys/MYKERNEL/kernel y /usr/obj/usr/src/sys/MYKERNEL/kernel.debug. kernel fue instalado como /boot/kernel/kernel, mientras que kernel.debug puede ser usado como la fuente de símbolos de depuración para kgdb(1).

Para capturar un volcado de pila, edite /etc/rc.conf y ajuste dumpdev para que apunte a la partición swap o AUTO. Esto causara que los scripts de rc(8) usen el comando dumpon(8) para habilitar vocados de fallos. Este comando también puede correrse manualmente. Luego de un pánico, el volcado de fallos puede recuperarse usando savecore(8); si dumpdev esta ajustado en /etc/rc.conf, los scripts de rc(8) correran savecore(8) automáticamente y colocaran en volcado de fallos en /var/crash.

Una vez que se haya recuperado el volcado de fallos, obtenga un seguimiento de pila de esta manera:

% kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0
(kgdb) backtrace

Nótese que hay varias pantallas de información. En lo posible, use script(1) para capturarlas todas. Usar la imagen unstripped del kernel con todos los símbolos de depuración debería ahora mostrar la línea exacta del codigo fuente del kernel donde ocurrio el pánico. El seguimiento de pila suele leerse desde el fondo hacía arriba para rastrear la secuencia exacta de eventos que llevaron al fallo. kgdb(1) puede también usarse para imprimir el contenido de varias variables o estructuras para examinar el estado del sistema en el momento del fallo.

ELF toolchain por defecto no hace que los símbolos definidos a un ejecutable sean visibles al linker dinámico. Consecuentemente dlsym() busca en los descriptores obtenidos desde llamadas a dlopen(NULL, flags) y no podrá encontrar tales símbolos.

Para buscar, usando dlsym(), por símbolos presentes en el ejecutable principal de un proceso, vincule el ejecutable usando la opción --export-dynamic para el linker ELF (ld(1)).

Por defecto, el espacio de direcciones del kernel es de 1 GB (2 GB ppara PAE) para i386. Al correr un servidor que es intensivo sobre la red o usar ZFS, esto probablemente no sea suficiente.

Agregue la siguiente línea al archivo de configuración del kernel para incrementar el espacio disponible y recompile el kernel:

options KVA_PAGES=N

Para encontrar el valor correcto de N, divida el tamaño de espacio de direcciones deseado (en megabytes) por cuatro. (Por ejemplo, 512 para 2 GB.)