![[índice]](../../images/back.gif){kind=small}
![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Índice de documentos] [Capítulo 4 - Guía de instalación] [Capítulo 6 - Redes]
,------o-----------o----X 3.1 Stable
| . .
| . ,------o---------o----X 3.2 Stable
| . | . .
| . | . ,----o----------o--> 3.3 Stable
| . | . | . .
| . | . | . ,-----o--> 3.4 Stable
| . | . | . | .
| . | . | . | .
-->3.1Rel----->3.2Rel----->3.3Rel----->3.4Rel----> Current
Time --->
El árbol del código se divide entre las ramas -current, -release y -stable cada seis meses; -release, la versión final, es el punto de congelación del historial de desarrollo del árbol de fuentes, nunca sufre cambios y es el código que se incluye en los CD y en los servidores de FTP. -current, la versión en desarrollo, es el árbol del código en el que se efectúan todos los cambios, y pasa a ser la próxima versión final (-release) de OpenBSD pasados seis meses.
-stable, la versión estable también conocida como «rama de parches», es una revisión de la última versión final, -release, o lo que es lo mismo una ramificación del código principal de OpenBSD. Según van apareciendo reparaciones importantes en la versión en desarrollo, estas reparaciones se «retro-portan» a las versiones estables. En el gráfico anterior, las líneas verticales de puntos representan reparaciones de errores que son incorporadas en las versiones estables. En el ejemplo también se puede observar que la versión 3.1-stable finalizó con la versión 3.3-release, y que la versión 3.2-stable finalizó con la versión 3.4-release. El soporte para las versiones antiguas sólo se continúa durante dos versiones. Para continuar con el soporte de versiones antiguas se necesita tiempo y recursos, y aunque querríamos ofrecer soporte continuado para versiones antiguas, preferimos centrarnos en el desarrollo de nuevas funcionalidades. La versión estable es, por su diseño, muy fácil de compilar e instalar partiendo desde la versión final de la misma versión (o sea, desde 3.4-release a 3.4-stable).
La revisión estable (-stable) es, en realidad, la versión final (-release) más los parches que aparecen en la página de erratas, además de algunas pequeñas reparaciones que no merecen una entrada en esa página. Generalmente, la operación en la que se basa el paso de -release está basado en -stable. Si las páginas del manual tienen que cambiar es probable que no aparezcan en -stable. En otras palabras, el soporte de nuevos dispositivos NO se añade a -stable, y el soporte de nuevas funcionalidades sólo se añade en raras ocasiones, cuando se considera que el cambio es muy importante.
Aviso: -current es el código de la versión en contínuo desarrollo. Los cambios se producen casi cada minuto y puede cambiar varias veces durante el tiempo que alguien tarda en bajarse el código fuente. Con el código de esta versión en desarrollo no es posible asegurar que la compilación del código vaya a funcionar siempre ...aunque siempre queda la esperanza. Bajarse el código fuente de la versión en desarrollo y que falle la compilación en un momento dado y que, cinco minutos más tarde sí que funcione, es algo bastante frecuente. Si no se está preparado para este tipo de problemas es aconsejable no utilizar -current.
Las versiones que la mayoría de usuarios deben utilizar son -stable o -release. Aunque hay muchos usuarios que utilizan -current en sus sistema de producción, y es importante que los usuarios expertos lo hagan para así poder identificar errores y para probar el funcionamiento de las nuevas funcionalidades. Sin embargo, los usuarios que no sepan cómo describir, diagnosticar y tratar correctamente un problema, no deben utilizar -current. Decir que algo «no ha funcionado» no es un informe útil para los desarrolladores.
Hay ocasiones en los que un usuario «normal» querrá ponerse al límite e instalar -current, en especial si el usuario tiene un dispositivo para el que no existe soporte en la versión final (y por lo tanto tampoco en la versión estable), o necesita alguna funcionalidad nueva de la versión en desarrollo. En este caso en el que las únicas opciones son las de instalar la versión en desarrollo o no utilizar el dispositivo, la primera puede ser vista como un mal menor, pero en ese caso no se puede esperar ayuda de los desarrolladores.
Entre una versión final de OpenBSD y la siguiente, el proyecto saca versiones preliminares o instantáneas, (snapshots), y las pone en los servidores de FTP. Estas versiones preliminares son versiones que se preparan con todo el código existente en el árbol de fuentes en el instante en el que el desarrollador coge una copia del código para una plataforma en concreto. Hay que tener en cuenta que, en algunas plataformas, puede significar DÍAS antes de que la versión instantánea sea recogida y disponible para su distribución. No se puede asegurar que las versiones instantáneas sean totalmente funcionales, ni siquiera que se instalen correctamente. La razón detrás de la distribución de estas versiones suele ser que haya un cambio para el que se necesiten informes de pruebas. En algunas plataformas hay versiones instantáneas que se recopilan casi a diario, mientras que en otras es mucho menos frecuente. Para alguien que quiera instalar -current por algún motivo específico, es muy probable que sólo sea necesario un snapshot, y actualizar el sistema con un snapshot es un buen comienzo antes de intentar compilar -current.
Una precuenta frecuente es si se puede obtener una copia del código exacto que se ha usado para recopilar una versión instantánea. La respuesta es no. Esto no tiene ningún beneficio significativo, y además las versiones instantáneas se recopilan cuando hay tiempo y recursos disponibles para hacerlo. Se pueden recopilar varios snapshots en un mismo día para una plataforma veloz, y tardar una semana o incluso más en recopilar un solo snapshot en una plataforma lenta. La inclusión de marcas o etiquetado en el árbol de fuentes para cada uno de los snapshot no sería práctico.
Es importante que quede claro que OpenBSD es un sistema operativo que debe ser utilizado al completo, no un núcleo para un sistema con unas cuantas utilidades integradas. Hay que asegurarse de que los árboles del núcleo del sistema, del modo de usuario (userland, las utilidades y archivos de soporte) y de los portes estén sincronizados en todo momento, o de lo contrario nos estaremos exponiendo a problemas nada agradables. Dicho de otra forma (debido a que algunos usuarios siguen cometiendo este error), no es posible tener un árbol de portes nuevo funcionando sobre un sistema que ya tenga un mes de tiempo, ni se puede recomponer un núcleo del sistema con el código fuente de -current y esperar que funcione con un sistema de la versión -release. Esto implica que sería necesario actualizar todo el sistema si se quisiera utilizar un nuevo programa que acabara de ser añadido al árbol de fuentes. Los sentimos, pero OpenBSD dispone de unos recursos limitados.
También es importante que quede claro que, cuando se lleva a cabo una actualización mediante el código fuente, el soporte para el proceso de actualización existe en una sola dirección: de una versión a otra más reciente, y desde -stable a -current. No se puede instalar una 3.4-current (o un snapshot) y luego decidir que es demasiado inestable y pretender volver a una versión 3.4-stable, y esperar para ello soporte o asistencia por parte de los desarrolladores. Si alguien elige un camino distinto debe esperar ninguna ayuda que no sea para reinstalar el sistema desde cero, y no puede esperar ninguna ayuda del equipo de desarrolladores de OpenBSD.
Así pues, antes de que cualquier usuario se decida a usar la versión -current es aconsejable que se lo piense bien.
Existen varias razones por las que un usuario puede decidirse a personalizar el núcleo, aunque esta práctica es sólo recomendable para aquellos usuarios que tengan un buen conocimiento general del sistema.
Para la mayoría de casos NO será necesario compilar un núcleo personalizado. El núcleo GENERIC contiene todo lo que el usuario puede necesitar. Lo cierto es que existen algunos motivos para no crear un núcleo personalizado, y el principal es que es muy fácil aplicar cambios a la configuración del núcleo que aparentan ser lógicos pero que no funcionan. Esto debe ser considerado como una señal de aviso, si algo en el sistema no funciona correctamente con el nuevo núcleo se debe probar con el núcleo GENERIC antes de enviar un informe sobre el error. Los desarrolladores, por regla general, ignorarán los informes de errores con núcleos pesonalizados a menos que el problema también pueda ser reproducido con un núcleo GENERIC.
El fichero de configuración se procesa mediante config(8), que crea un directorio de compilación y lo llena en ../compile ... que en una instalación normal estaría /usr/src/sys/arch/<arq>/compile/. La utilidad config(8) también crea un fichero Makefile y otros ficheros requeridos para poder componer el núcleo con éxito.
Las Opciones de Configuración del Núcleo son las opciones que se pueden añadir a la configuración del núcleo para incluir ciertas funcionalidades en el núcleo del sistema. De este modo es posible obtener el tipo exacto de soporte deseado, sin el soporte de aquellos dispositivos que sean innecesarios para el usuario. Existe una gran cantidad de opciones que nos permiten personalizar el núcleo, pero aquí sólo explicaremos algunas de ellas, las que se usan con más frecuencia. En la página del manual de options(4) hay una lista completa de opciones; como las opciones cambian de vez en cuando, es necesario leer la página del manual actualizada para la misma versión de OpenBSD que se vaya compilar. También se pueden mirar los ficheros de configuración de ejemplo que haya disponibles para la arquitectura.
¡No se deben añadir, eliminar, o cambiar opciones en el núcleo a menos que exista una buena razón para ello! La única configuración del núcleo para la que ofrece soporte el equipo de OpenBSD es la del núcleo GENERIC, la combinación de las opciones de /usr/src/sys/arch/<arq>/conf/GENERIC y /usr/src/sys/conf/GENERIC que incluye el equipo de OpenBSD (o sea, SIN cambios). Cuando alguien informa sobre un problema en un sistema con un núcleo personalizado, la respuesta suele ser siempre que se intente antes reproducir ese mismo problema en un sistema con un núcleo GENERIC. No todas las opciones son compatibles entre ellas, y muchas opciones son un requisito para que funcione el sistema. Que alguien consiga compilar un núcleo personalizado no significa que vaya a funcionar.
A continuación se pueden ver los ficheros de configuración específicos de cada plataforma:
Si nos fijamos en estos ficheros, por el principio podremos ver una
línea parecida a:
include "../../../conf/GENERIC"
Esto quiere decir que hace referencia a otro fichero de configuración, a uno en el que se guardan las opciones independientes de la plataforma. Cuando estemos creando nuestra propia configuración del núcleo debemos asegurarnos de mirar la configuración de /sys/conf/GENERIC.
Las opciones de configuración del núcleo se deben poner en el fichero de configuración del núcleo, y en el siguiente formato:
option nombre
Por ejemplo, para incluir la opción "DEBUG" en el
núcleo, añadiremos una línea como la siguiente:
option DEBUG
Las opciones que se incluyan en el núcleo de OpenBSD serán traducidas en opciones del preprocesador del compilador, y por consiguiente una opción como DEBUG se compilaría con la opción -DDEBUG, lo que equivale a incluir #define DEBUG por todo el núcleo.
A veces es probable que alguien quiera desactivar una opción que
ya esté definida en el fichero
"src/sys/conf/GENERIC". Aunque para ello se
podría modificar una copia de ese fichero, es mejor usar la
declaración rmoption. Por ejemplo, para desactivar el
depurador interno del núcleo (¡no es recomendable!),
bastaría con añadir una línea como la siguiente
rmoption DDB
en el fichero de configuración del núcleo. Aunque
option DDB está definido en
src/sys/conf/GENERIC, la directriz rmoption lo
desactiva.
La información específica sobre estas opciones se encuentra en la página del manual de options(4). Además, muchas de las opciones disponen de sus propias páginas del manual. Hay que leer toda la información existente sobre una opción antes de añadirla o eliminarla.
Las instrucciones completas para la creación de un núcleo personalizado se encuentran en la página del manual de afterboot(8).
Para recomponer un núcleo desde el CD-ROM el primer paso es disponer del código fuente. El código fuente se puede encontrar en el CD oficial (disco 3) o en los servidores de FTP. Para el siguiente ejemplo asumiremos que el CD3 ya está montado en /mnt:
# cd /usr/src
# tar xvzf /mnt/src.tar.gz
Nota: Si se va a obtener desde los servidores de FTP, se encontrarán dos archivos, src.tar.gz y sys.tar.gz. El primero es el «modo de usuario» (userland), todo excepto el núcleo del sistema; el segundo es el código fuente del núcleo. Estos archivos hay que extraerlos como se indica arriba, y la mayoría de usuarios necesitarán tener ambos. En el CD-ROM estos dos archivos están en uno solo.
A continuación, para personalizar el núcleo es más fácil empezar desde el núcleo GENERIC, que se encontrará en /usr/src/sys/arch/$ARCH/conf/GENERIC, en donde $ARCH es la arquitectura de la máquina que se vaya a usar. En ese directorio también hay otros ejemplos de configuración disponibles. He aquí dos ejemplo de compilación del núcleo. En el primer ejemplo se compilará dentro de un árbol de fuentes de sólo lectura, y en el segundo en un árbol de fuentes con permiso de escritura.
Cuando se haya realizado algún cambio en el árbol de fuentes (incluidos actualizaciones y parches) hay que ejecutar 'make depend' (en otras palabras, casi siempre a menos que se necesite ejecutar 'make clean').# cd /directorio # cp /usr/src/sys/arch/$ARCH/conf/FICHERO . # vi FICHERO (to make the changes you want) # config -s /usr/src/sys -b . FICHEROseguido por:# make depend - O POR - # make clean # make
Si se han efectuado cambios en las opciones de configuración del núcleo, y/o se han realizado cambios importantes en el árbol de fuentes, se debe usar 'make clean' en lugar de 'made depend'. Nótese que siempre es más seguro ejecutar 'make clean', aunque esto signifique un mayor tiempo de compilación ya que se recompilarán más partes.
Para compilar un núcleo desde dentro de un árbol de fuentes con permisos de escritura:
# cd sys/arch/$ARCH/conf
# vi FICHERO (para aplicar cualquier cambio deseado)
# config FICHERO (más información en config(8))
# cd ../compile/FICHERO
# make
En donde $ARCH es la arquitectura de la máquina (v.g. i386). También se puede ejecutar make depend para compilar las dependencias para la próxima vez que se recompile el núcleo.
Para colocar el núcleo en su sitio:
# cp /bsd /bsd.old
# cp /sys/arch/$ARCH/compile/FICHERO/bsd /bsd
Para usar el núcleo antiguo durante el arranque, desde el punto
de arranque:
boot> bsd.old
y se cargará el núcleo antiguo en lugar de /bsd.
En ocasiones, cuando se compila un nuevo núcleo se requiere que se instalen nuevo bloques de arranque. La información pertinente se encuentra en la sección Instalación de bloques de arranque, que ofrece un repaso sobre el uso del cargador de arranque de OpenBSD.
A veces, cuando se arranca el sistema, puede que el núcleo encuentre un dispositivo en un IRQ erróneo y que el usuario necesite utilizar ese dispositivo de forma urgente. Para ello, sin tener que recompilar el núcleo, se puede usar la configuración del núcleo en tiempo de arranque de OpenBSD. De esta forma se corregirá el problema por una vez, pero cuando se reinicie el sistema será necesario repetir este procedimiento. Por lo tanto sólo es una solución temporal, y será necesario recompilar el núcleo para resolver el problema definitivamente. Para usar esta funcionalidad el núcleo necesita disponer de la opción option BOOT_CONFIG compilada (el núcleo GENERIC la tiene).
La mayor parte de la información en esta sección se puede encontrar en la página del manual de boot_config(8).
Para arrancar en modo UKC (User Kernel Config, la
configuración del núcleo de usuario), hay que usar la
opción -c durante el arranque:
(NdelT: la configuración del teclado español no se
habrá activado, por lo que es necesario pulsar la tecla
'?' para obtener el carácter '-'):
boot> boot hd0a:/bsd -c
He aquí una lista de órdenes comunes desde el punto de inserción de UKC:
Una vez que ya esté configurado el dispositivo se puede usar quit o exit para continuar el proceso de arranque. Después de esto se debería corregir la configuración del núcleo compilando uno nuevo. Para ello véase la sección sobre Cómo crear un núcleo personalizado.
UKC> verbose
autoconf verbose enabled
UKC> quit
Ahora la información que aparecerá durante el arranque será muy amplia.
Las opciones -e y -u de la orden config(8) pueden ser muy útiles y con ellas se puede evitar malgastar tiempo compilando el núcleo. El indicador -e nos permite entrar en el punto de inserción de UKC de un sistema en ejecución. Los cambios aplicados surtirán efecto la próxima vez que se reinicie el sistema. El indicador -u comprueba si se ha llevado a cabo algún cambio en el núcleo en ejecución durante el arranque, o sea si se ha usado la orden boot -c para entrar en el punto de inserción de UKC durante el arranque del sistema.
El siguiente ejemplo se muestra la desactivación de los dispositivos ep* en el núcleo. Por seguridad se debe usar la opción -o que graba los cambios en el fichero que se especifique. Por ejemplo, config -e -o bsd.new /bsd, grabará los cambios en bsd.new. En el siguiente ejemplo no se usa la opción -o, y por lo tanto se ignorarán los cambios y no se grabarán en el fichero binario del núcleo. Para más información relacionada con mensajes de error y de aviso, véase la página del manual de config(8).
$ sudo config -e /bsd
OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MST 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
warning: no output file specified
Enter 'help' for information
ukc> ?
help Command help list
add dev Add a device
base 8|10|16 Base on large numbers
change devno|dev Change device
disable attr val|devno|dev Disable device
enable attr val|devno|dev Enable device
find devno|dev Find device
list List configuration
lines count # of lines per page
show [attr [val]] Show attribute
exit Exit, without saving changes
quit Quit, saving current changes
timezone [mins [dst]] Show/change timezone
nmbclust [number] Show/change NMBCLUSTERS
cachepct [number] Show/change BUFCACHEPERCENT
nkmempg [number] Show/change NKMEMPAGES
shmseg [number] Show/change SHMSEG
shmmaxpgs [number] Show/change SHMMAXPGS
ukc> list
0 audio* at sb0|sb*|gus0|pas0|sp0|ess*|wss0|wss*|ym*|eap*|eso*|sv*|neo*|cmpci*
|clcs*|clct*|auich*|autri*|auvia*|fms*|uaudio*|maestro*|esa*|yds*|emu* flags 0x0
1 midi* at sb0|sb*|opl*|opl*|opl*|opl*|ym*|mpu*|autri* flags 0x0
2 nsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
3 nsphyter* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|
vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep
*|ep*|ep* phy -1 flags 0x0
4 qsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
5 inphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
6 iophy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
7 eephy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
8 exphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
[...snip...]
ukc> disable ep
67 ep0 disabled
68 ep* disabled
69 ep* disabled
155 ep0 disabled
156 ep0 disabled
157 ep* disabled
158 ep* disabled
210 ep* disabled
ukc> quit
not forced
En el ejemplo anterior, se han desactivado en el núcleo todos los dispositivos ep*, y ya no se sondearán. Es posible que en algún caso en el que se haya usado el punto de inserción de UKC durante el arranque, mediante boot -c, el usuario necesite grabar los cambios de forma permanente. Para ello deberá usar la opción -u. En el ejemplo siguiente se ha arrancado la máquina en el punto de inserción de UKC, y se ha desactivado el dispositivo wi(4). Como los cambios realizados mediante boot -c NO son permamentes, hay que grabarlos. En este ejemplo, los cambios realizados desde boot -c, se grabarán en un nuevo fichero binario del núcleo, bsd.new.
$ sudo config -e -u -o bsd.new /bsd
OpenBSD 3.3 (GENERIC) #44: Sat Mar 29 13:22:05 MST 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
105 wi* disabled
106 wi* disabled
Enter 'help' for information
ukc> quit
La compilación de OpenBSD y de otros programas desde el código fuente es una tarea que fuerza al hardware mucho más que otros procesos, y que conlleva un uso intensivo de CPU, disco y memoria. En consecuencia, si el hardware tiene algún problema, el momento más normal para que aparezca es durante la compilación del sistema. Los fallos de Signal 11 están causados generalmente por problemas de hardware, que muy frecuentemente son debidos a problemas de memoria, aunque también se pueden deber a la CPU, la placa base o problemas de recalentamiento. El sistema puede estar muy estable para otras tareas, pero incapaz de compilar ciertos programas.
Lo mejor en estos casos es reparar o sustituir los componentes que causan el problema, ya que los problemas pueden aparecer de otras formas en el futuro. Si tenemos un equipo que deseamos utilizar y que no causa ningún otro problema aparte del mencionado, podemos instalar una versión preliminar o final.
Para más información, véase el documento de preguntas frecuentes sobre Sig11.
Esto es el resultado de dos errores distintos:
Es importante seguir las instrucciones con cuidado cuando se esté bajando o actualizando el código fuente y se vaya a compilar el árbol de fuentes.
[Índice de documentos] [Capítulo 4 - Guía de instalación] [Capítulo 6 - Redes]
www@openbsd.org