bootparam

NOMBRE

bootparam - introducción a los parámetros de arranque del núcleo de Linux

DESCRIPCIÓN

El núcleo Linux acepta ciertas 'opciones de la línea de orden' o 'parámetros de arranque' cuando se carga. En general esto sirve para suministrar al núcleo información sobre parámetros del equipo que el núcleo es incapaz de determinar por sí mismo, o para evitar o cambiar los valores que el núcleo detectaría. Cuando la BIOS inicia directamente el núcleo, no es posible especificar ningún parámetro, para emplear esta posibilidad debe utilizarse un cargador de inicio capaz de pasar parámetros (por ejemplo GRUB).

La lista de argumentos

La línea de órdenes del núcleo se analiza y divide en una lista de cadenas de caracteres (argumentos del arranque) separadas por espacios. La mayoría de argumentos de arranque toman la forma:

nombre[=valor_1][,valor_2]...[,valor_10]

donde 'nombre' es una palabra reservada única que se emplea para identificar a qué parte del núcleo se va a dar los valores (si hay alguno) asociados. Observe que el límite de 10 es real, puesto que el código actual sólo maneja 10 parámetros separados por coma por cada palabra reservada. Sin embargo, se puede reutilizar la misma palabra con hasta 10 parámetros adicionales más en situaciones inusualmente complicadas, suponiendo que la función setup ---vea un par de párrafos más adelante--- incluya soporte para ello. La mayor parte de la gestión está codificada en el archivo del núcleo de linux /init/main.c. Primero el núcleo mira a ver si el argumento es uno de los especiales 'root=', 'nfsroot=', 'nfsaddrs=', 'ro', 'rw', 'debug' o 'init'. El significado de estos argumentos especiales se describe más adelante. Luego recorre una lista de funciones setup para ver si la cadena del argumento especificado (como 'fu') ha sido asociada con una función setup ('fu_setup()') para un dispositivo particular o parte del núcleo. Si se le pasa al núcleo la línea fu=3,4,5,6 entonces el núcleo buscará en el vector bootsetups si 'fu' ha sido registrada. Si lo ha sido, entonces llamará a la función setup asociada con 'fu' (fu_setup()) y le pasará los argumentos 3, 4, 5 y 6 tal como se dieron en la línea de órdenes del núcleo. Cualquier cosa de la forma 'fu=bar' que no se acepte como una función setup tal como se ha descrito arriba se interpreta entonces como una variable de entorno que toma un valor. Un (¿inútil?) ejemplo sería poner 'TERM=vt100' como un argumento de arranque. Cualquier argumento restante que no han sido tomados por el núcleo ni han sido interpretados como variables de entorno se pasan entonces al PID 1, que normalmente es el programa init(1). El más usual de ellos es la palabra 'single', que ordena a init arrancar el sistema en modo monousuario, sin lanzar los demonios usuales. Eche un vistazo a la página del manual de la versión de init() instalada en su sistema para ver qué argumentos acepta.

Opciones de inicio no específicas de ningún dispositivo

'init=...'

Esto indica el programa inicial que ejecutará el núcleo. Si no se establece o no se puede encontrar, el núcleo intentará ejecutar /sbin/init, luego /etc/init, después /bin/init, más tarde /bin/sh y acabará dando un mensaje de pánico (y con razón) si todo esto falla.

'nfsaddrs=...'

Esto pone la dirección de arranque de NFS con la cadena dada. Esta dirección de arranque se emplea en caso de un arranque remoto, por red.

'nfsroot=...'

Esto pone el nombre de la raíz de NFS con la cadena dada. Si esta cadena no empieza con '/' ni ',' ni un dígito, entonces se le añade el prefijo '/tftpboot/'. Este nombre de raíz se emplea en caso de un arranque remoto.

'root=...'

Este argumento le dice al núcleo qué dispositivo se va a emplear como el sistema de archivos raíz al arrancar. El valor predeterminado de este valor se pone en tiempo de compilación, usualmente como el dispositivo raíz del sistema donde se construyó el núcleo. Para tomar otro valor, y seleccionar por ejemplo la segunda disquetera como el dispositivo raíz, uno utilizaría 'root=/dev/fd1'.

El dispositivo raíz se puede definir simbólica o numéricamente. Una definición simbólica tiene el formato: dev/XXYN donde XX denota el tipo de dispositivo (por ejemplo 'hd' para ST-506 compatibles con un disco duro, siendo Y 'a'–'d'; 'sd' definiría un disco compatible SCSI siendo Y a'–'e'), Y representa una letra o cifra del driver y N el número (en formato decimal) de partición del dispositivo

Observe que esto no tiene nada que ver con la designación de estos dispositivos en el sistema de archivos. La parte '/dev/' es puramente convencional.

La especificación numérica, más fea y menos transportable, de los posibles dispositivos raíz de arriba en formato mayor/menor, se acepta también. (Por ejemplo, /dev/sda3 tiene de número mayor 8 y de menor 3, así que se podría poner 'root=0x803' de forma alternativa.)

'rootdelay='

Este parámetro define el tiempo de latencia (en segundos) antes de intentar montar el sistema de archivos raiz.

'rootflags=...'

Este parámetro define las opciones de montaje para el sistema de archivos raiz. Consulte fstab(5).

'rootfstype=...'

La opción 'rootfstype' indica al núcleo que el sistema de archivo raiz debe montarse como estuviese en el formato indicado. Un ejemplo de la utilidad de esta opción sería montar un sistema de archivos ext3 como si fuese ext2 eliminando así la parte transaccional migrando así de ext3 a ext2 directamente, sin necesidad de hacerlo desde un medio externo.

'ro' y 'rw'

La opción 'ro' le dice al núcleo que monte el sistema de archivos raíz como 'de lectura exclusiva', de modo que el programa de comprobación de consistencia del sistema de archivos (fsck) pueda hacer su trabajo en un sistema de archivos sin actividad. Ningún proceso puede escribir en archivos del sistema de archivos en cuestión hasta que éste se remonte con permisos para lectura y escritura, por ejemplo mediante 'mount -w -n -o remount /'. (Vea también mount(8).)

La opción 'rw' le dice al núcleo que monte el sistema de archivos raíz para lectura y escritura. Esto es lo que ocurre por defecto.

'resume=...'

Indica al núcleo la localización de toda la información para la reanudación después de hibernar. Suele coincidir con el archivo o partición swap. Por ejemplo:

resume=/dev/hda2
    

'reserve=...'

Se emplea para proteger regiones de E/S de pruebas. La forma de la orden es:

reserve=baseE/S,extensión[,baseE/S,extensión]...
    

En algunos equipos puede ser necesario evitar que ciertos controladores de periféricos comprueben la existencia de éstos (auto-pruebas) en una región específica. Esto puede ser porque algún dispositivo emite un error en la prueba, o porque algún otro se identifique erróneamente, o simplemente porque no queremos que el núcleo inicialice cierto hardware.

El argumento de arranque reserve especifica una región de un puerto de E/S que no debe ser probado. Un controlador no probará una región reservada, a menos que otro argumento de arranque explícitamente le especifique que lo haga.

Por ejemplo, la línea de arranque

reserve=0x300,32  blah=0x300
    

hace que ningún controlador pruebe la región 0x300--0x31f excepto el de 'blah'.

'panic=N'

Por omisión el núcleo no se reiniciará tras un error de pánico, esta opción hará que el núcleo rearranque tras N segundos (si N es mayor que cero). Este tiempo de latencia también se puede definir con

echo N > /proc/sys/kernel/panic
    

'reboot=[warm|cold][,[bios|hard]]'

Desde la versión Linux 2.0.22 un rearranque es por omisión un rearranque en frío. Uno obtiene el comportamiento antiguo con 'reboot=warm'. (Un rearranque en frío puede ser necesario para inicializar cierto hardware, pero puede destruir datos no escritos aún en un caché de disco. Un rearranque en caliente puede ser más rápido.)

'nosmp' y 'maxcpus=N'

(Sólo cuando se defina __SMP__ .) Una opción de línea de orden como 'nosmp' o 'maxcpus=0' deshabilitará por completo MPS (multiproceso simétrico); una opción como 'maxcpus=N' limita el número máximo de UCPs activados en el modo MPS a N.

Argumentos de arranque para uso de los desarrolladores del núcleo

'debug'

Los mensajes del núcleo son gestionados por el demonio de registro del núcleo (por ejemplo klogd(8) o similar) de modo que pueden ser registrados en disco. Los mensajes con una prioridad mayor que console_loglevel también se muestran en la consola. (Para estos niveles, consulte syslog(2).) Por defecto console_loglevel está puesta de modo que registre cualquier cosa más importante que mensajes KERN_DEBUG. El nivel de registro de la consola se puede establecer también en tiempo de ejecución mediante el archivo /proc/sys/kernel/printk (descrito en syslog(2)), la operación de syslog(2) SYSLOG_ACTION_CONSOLE_LEVEL o bien dmesg(8).

'profile=N'

Es posible habilitar una función de perfil del núcleo, si uno desea saber dónde está el núcleo gastando sus ciclos de CPU. El perfil se habilita poniendo la variable prof_shift a un valor distinto de cero. Esto se hace bien especificando CONFIG_PROFILE en la compilación, o mediante la opción 'profile='. Ahora el valor que tendrá prof_shift será N, cuando se dé, o CONFIG_PROFILE_SHIFT, cuando se haya dado éste, ó 2, el valor predeterminado. La significancia de esta variable es que da la granularidad del perfil: para cada pulso del reloj, si el sistema está ejecutando código del núcleo, se incrementa un contador:

profile[address >> prof_shift]++;
    

La información de perfil, sin procesar, puede verse directamente en /proc/profile aunque es preferible emplear una herramienta como readpropfile.c para verla mejor. Escribir en /proc/profile limpiará los contadores.

Argumentos de arranque para uso de disco en memoria

(Sólo si el núcleo ha sido compilado con CONFIG_BLK_DEV_RAM.) En general es una mala idea emplear un disco RAM en Linux; el sistema utilizará la memoria disponible más eficientemente sin él. Pero durante el arranque es útil a menudo cargar los contenidos del disquete en un disco RAM. Uno también podría tener un sistema en el cual deban cargarse primero algunos módulos (de sistemas de archivos o periféricos) antes de que se pueda acceder al disco principal.

En Linux 1.3.48 se cambió radicalmente el manejo de discos RAM. Anteriormente, la memoria se asignaba estáticamente, y había un parámetro 'ramdisk=N' para indicar su tamaño (que también podía establecerse en la imagen del núcleo al compilarlo). Actualmente los discos RAM emplean el búfer caché, y crecen dinámicamente. Para más información sobre esto puede leer el archivo Documentation/blockdev/ramdisk.txt ( Documentation/ramdisk.txt en núcleos más antiguos).

Hay cuatro parámetros, dos booleanos y dos enteros.

'load_ramdisk=N'

Si N=1, carga un disco RAM. Si N=0, no se carga. (Éste es el comportamiento predeterminado.)

'prompt_ramdisk=N'

Si N=1, pide la inserción del disquete. (Éste es el comportamiento predeterminado.) Si N=0, no se pregunta; por tanto, este parámetro nunca se necesita.

'ramdisk_size=N' o (anticuado) 'ramdisk=N'

Pone el tamaño máximo del disco RAM (o de los discos) a N kB. El valor predeterminado es 4096 (esto es, 4 MB).

'ramdisk_start=N'

Pone el número del bloque inicial (el desplazamiento desde el principio en el disquete donde empieza el disco RAM) a N. Esto es necesario si el disco RAM está tras una imagen del núcleo.

'noinitrd'

(Sólo si el núcleo fue compilado con CONFIG_BLK_DEV_RAM y con CONFIG_BLK_DEV_INITRD.) Actualmente es posible compilar el núcleo de forma que emplee initrd. Cuando se habilita esta característica, el proceso de arranque cargará el núcleo y un disco RAM inicial; entonces el núcleo convierte initrd a un disco RAM "normal", que se monta para lectura y escritura como el dispositivo raíz; luego se ejecuta /linuxrc; después de eso se monta el sistema de archivos raíz "de verdad", y el sistema de archivos initrd se mueve sobre /initrd; finalmente tiene lugar la secuencia de arranque habitual (o sea, la llamada a /sbin/init).

Para una descripción detallada de initrd, lea el archivo del código de Linux Documentation/admin-guide/initrd.rst o Documentation/initrd.txt en versiones anteriores a 4.10.

La opción 'noinitrd' le dice al núcleo que aunque haya sido compilado para la operación con initrd, no debe seguir los pasos anteriores, sino dejar los datos de initrd bajo /dev/initrd. (Este dispositivo sólo puede emplearse una vez; los datos son liberados tan pronto como el último proceso que lo haya utilizado cierre /dev/initrd.)

Argumentos de arranque para dispositivos SCSI

Notación general para esta sección: iobase -- el primer puerto de E/S que ocupa el anfitrión SCSI. Se especifica en notación hexadecimal y normalmente cae en el rango de 0x200 a 0x3ff. irq -- la interrupción de hardware a la que la tarjeta está configurada. Los valores válidos dependen de la tarjeta en cuestión, pero normalmente son 5, 7, 9, 10, 11, 12 y 15. Los otros valores se emplean normalmente para periféricos comunes como discos duros IDE, disquetes, puertos serie, etc. scsi-id -- La ID (identificación) que emplea el adaptador anfitrión para identificarse en el bus SCSI. Sólo algunos permiten que se cambie este valor, puesto que la mayoría lo tiene especificado de modo permanente e interno. El valor predeterminado más usual es 7, pero las tarjetas Seagate y Future Domain emplean el 6. paridad -- si el adaptador anfitrión SCSI espera que los dispositivos acoplados a él suministren un valor de paridad con todos los intercambios de información. El valor 1 indica que el control de paridad está activo, y el 0 que no. De nuevo, no todos los adaptadores admiten la selección del comportamiento de la paridad como argumento de arranque.

'max_scsi_luns=...'

Un dispositivo SCSI puede tener un número de 'sub-dispositivos' contenidos en él mismo. El ejemplo más común es uno de los nuevos CD-ROMs SCSI que manejan más de un disco a la vez. Cada CD se direcciona con un 'Número Lógico de Unidad' (NLU, o LUN) de ese dispositivo particular. Pero la mayoría de dispositivos, como discos duros, unidades de cinta magnética y otros por el estilo son dispositivos únicos, y tendrán el LUN 0.

Algunos dispositivos SCSI pobremente diseñados no pueden admitir que se compruebe la existencia de otros LUNs distintos del 0. Por lo tanto, si la opción de compilación CONFIG_SCSI_MULTI_LUN no está puesta, los núcleos nuevos sólo probarán de forma predeterminada el LUN 0.

Para especificar el número de LUNs probados en el arranque, uno introduce 'max_scsi_luns=n' como un argumento del arranque, siendo n un número entre 1 y 8. Para evitar problemas como los descritos anteriormente, uno debería emplear n=1 para evitar problemas con los dispositivos del párrafo anterior.

Configuración de unidades de cinta magnética SCSI

Algo de la configuración en tiempo de arranque del controlador de cinta magnética SCSI puede hacerse mediante lo siguiente:

st=tam_buf[,write_threshold[,bufs_max]]
    

Los primeros dos números se especifican en unidades de kB. El valor predeterminado de tam_buf es 32 kB, y el tamaño máximo que puede especificarse es de 16384 ridículos kB. write_threshold es el valor al cual el búfer es volcado a la cinta, siendo el predeterminado 30 kB. El máximo número de búferes varía con el de unidades detectadas, y el valor predeterminado es 2. Un ejemplo del modo de empleo sería

st=32,30,2
    

Los detalles pueden encontrarse en el archivo Documentation/scsi/st.txt o drivers/scsi/README.st en núcleos anteriores) del código fuente del núcleo.

Discos duros

Parámetros del Controlador de Disco/CD-ROM IDE

El controlador IDE acepta una serie de parámetros, que van desde especificaciones de la geometría del disco, a soporte para chips controladores deficientes. Opciones específicas de una unidad se dan como 'hdX=', con X en el rango 'a'–'h'.

Las opciones no específicas de una unidad se dan con el prefijo 'hd='. Observe que emplear un prefijo específico de unidad para una opción no específica de unidad, todavía funcionará, y la opción será aplicada simplemente como se espera.

Observe también que 'hd=' puede emplearse para referirse a la siguiente unidad no especificada de la secuencia (a, ..., h). Para las discusiones que siguen, se citará la opción 'hd=' por brevedad. Consulte el archivo Documentation/ide/ide.txt (o Documentation/ide.txt en anteriores versiones. En las versiones más antiguas debería consultar drivers/block/README.ide del código fuente del núcleo.

Las opciones 'hd=cils,cabezas,sectores[,pcomes[,irq]]'

Estas opciones se emplean para especificar la geometría física del disco. Sólo son obligatorios los tres primeros valores. Los valores de cilindros/cabezas/sectores serán los empleados por fdisk. El valor de precompensación de escritura no se tiene en cuenta para discos IDE. El valor de IRQ especificado será el empleado para la interfaz donde resida la unidad, y no es realmente un parámetro específico de la unidad.

La opción 'hd=serialize'

La interfaz IDE dual con el chip CMD-640 está mal diseñada pues cuando se emplean unidades en la interfaz secundaria al mismo tiempo que en la primaria, se corromperán datos. Con esta opción se le dice al controlador que se asegure de que nunca se usan a la vez ambas interfaces.

La opción 'hd=noprobe'

No comprobar la existencia de esta unidad. Por ejemplo,

hdb=noprobe hdb=1166,7,17
    

inhabilitará las pruebas de existencia, pero al especificar la geometría de la unidad se registrará ésta como un dispositivo de bloque válido, y por tanto utilizable.

La opción 'hd=nowerr'

Algunas unidades tienen aparentemente el bit WRERR_STAT permanentemente encendido. Esto activa una solución para estos aparatos con este fallo.

La opción 'hd=cdrom'

Esto le dice al controlador IDE que hay un CD-ROM compatible ATAPI puesto en el lugar de un disco duro IDE normal. En la mayoría de los casos el CD-ROM se identifica automáticamente, pero si no ocurre así, esto puede ayudar.

Opciones del Controlador de Disco Estándar ST-506 ('hd=')

El controlador estándar de disco puede aceptar argumentos de geometría para los discos, similar al controlador IDE. Observe sin embargo que sólo espera tres valores (C/CZ/S) -- más o menos de tres y sin decir nada no se tendrá en cuenta ninguno. Además, sólo acepta 'hd=' como argumento; o sea, nada de 'hda=' ni nada por el estilo. El formato es como sigue:

hd=cils,cabezas,sects
    

Si hay dos discos instalados, lo de arriba se repetirá con los parámetros de geometría del segundo disco.

Dispositivos de red Ethernet

Controladores diferentes hacen uso de parámetros diferentes, pero todos comparten al menos un IRQ, un valor de dirección base del puerto de E/S, y un nombre. En su forma más genérica, el aspecto es el siguiente:

ether=irq,iobase[,parám_1[,...parám_8]],nombre

El primer argumento no numérico se toma como el nombre. Los valores de los parám_i (cuando sean de aplicación) normalmente tienen significados diferentes para cada controlador/tarjeta. Usualmente se emplean para especificar cosas como direcciones de memoria compartida, selección de interfaz, canal DMA y cosas así. El empleo más común de este parámetro es el forzar la autocomprobación de una segunda tarjeta de red, puesto que por omisión sólo se prueba una. Esto se puede hacer simplemente con:

ether=0,0,eth1

Observe que los valores de cero para el IRQ y la dirección base de E/S en el ejemplo anterior le dicen al controlador o controladores que prueben la existencia de la(s) tarjeta(s). El documento 'Ethernet-Howto' tiene documentación extensa sobre cómo usar varias tarjetas de red y sobre los valores de los parámetros parám_i específicos a cada tarjeta/controlador donde haya que emplearlos. Los lectores interesados deberán irse a la sección de su tarjeta particular en ese documento.

El controlador de disquetera

Existe multitud de opciones para el controlador de la disquetera, todas ellas listadas en Documentation/blockdev/floppy.txt (o Documentation/floppy.txt en núcleos más antiguos; incluso drivers/block/README.fd en los realmente antiguos). Consulte este archivo para más detalles.

El controlador de sonido

El controlador de sonido también puede aceptar argumentos durante el inicio para sobreescribir los valores con los que ha sido compilado. Esto no se recomienda, pues es bastante complejo. Se describe en el archivo Documentation/sound/oss/README.OSS ( drivers/sound/Readme.linux en núcleos realmente antiguos). Dichos argumentos deben ser de la siguiente forma:

sound=dispositivo1[,dispositivo2[,dispositivo3...[,dispositivo10]]]

donde cada valor dispositivoN está en el formato: 0xTaaaId y los bytes se emplean como sigue: T - tipo de dispositivo: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16, 7=SB16-MPU401 aaa - dirección de E/S en hexadecimal. I - línea de interrupción en hexadecimal (i.e. 10=a, 11=b, ...) d - canal DMA. Como puede ver es bastante lioso, y lo mejor que puede hacer es compilar el controlador con los valores deseados como se recomienda. Un argumento de arranque como 'sound=0' anulará el controlador de sonido completamente.

El controlador de la impresora de línea

'lp='

 

Sintaxis:

lp=0
lp=auto
lp=reset
lp=port[,port...]
    

Es posible indicarle al controlador de la impresora qué puertos usar y qué puertos no usar. Esto último puede ser útil si no quiere que el controlador de impresora reclame todos los puertos paralelos disponibles, con el fin de que otros controladores (p.e. PLIP, PPA) puedan usarlos.

El formato para el argumento es de varios nombres de puerto. Por ejemplo, lp=none,parport0 usaría el primer puerto paralelo para lp1, y deshabilitaría lp0. Para deshabilitar el controlador de impresora por completo, puede usar lp=0.

VÉASE TAMBIÉN

klogd(8), mount(8) Consulte la información más actualizada en el siguiente archivo del código fuente del núcleo: Documentation/admin-guide/kernel-parameters.txt.

TRADUCCIÓN

La traducción al español de esta página del manual fue creada por Gerardo Aburruzaga García <[email protected]>, Miguel Pérez Ibars <[email protected]> y Marcos Fouces <[email protected]> Esta traducción es documentación libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD. Si encuentra algún error en la traducción de esta página del manual, envíe un correo electrónico a [email protected]