Saltar al contenido

Linux

GRUB2.- Cambiar el sistema operativo de arranque por defecto

  • admin 

Cambiar el sistema operativo de arranque por defecto.

Paso 1.- Conocer cual es el orden de las opciones de arranque en el grub2.

Podemos fijarnos cual es el orden de las opciones del menú cuando arranca el grub2 y contar desde cero (0) y de arriba hacia abajo. O abrimos el archivo /boot/grub/grub.cfg sin permisos de root, buscamos cada línea que comienza con menuentry; y ya que la tenemos localizadas contamos de la misma manera, desde 0 y de arriba hacia abajo.

Importante.- Se debe de abrir el archivo /boot/grub/grub.cfg sin permisos de root porque ese no se modifica. Esta generado automáticamente por update-grub (también se le llama con update-grub2 y /usr/sbin/grub-mkconfig, las tres son la mis cosa) cuando usamos templates de /etc/grub.d y/o cambiamos el archivo /etc/default/grub

Ejemplo:

Mis opciones de arranque en el grub2 están en este orden y junto a ellas le puse el número que le toca en GRUB_DEFAULT para arrancar desde ahí:

0 —– Ubuntu, Linux 2.6.31-14-generic
1 —– Ubuntu, Linux 2.6.31-14-generic (recovery mode)
2 —– Memory test (memtest86+)
3 —– Memory test (memtest86+, serial console 115200)
4 —– Ubuntu 8.04.2, kernel 2.6.24-24-generic (on /dev/sda1)
5 —– Ubuntu 8.04.2, kernel 2.6.24-24-generic (recovery mode) (on /dev/sda1)
6 —– Ubuntu 8.04.2, memtest86+ (on /dev/sda1)

Paso 2.- Abrimos el archivo /etc/default/grub y cambiamos la línea GRUB_DEFAULT. Le cambiamos el número que tiene por el que tiene la opción en el grub2 con la que va a arrancar por defecto y guardamos.

Abrimos el archivo con esta orden:

sudo nano /etc/default/grub

Ejemplo:

Quiero que arranque con el Ubuntu 8.04.2, kernel 2.6.24-24-generic (recovery mode) (on /dev/sda1) y como le toca el 5 la línea GRUB_DEFAULT queda:

GRUB_DEFAULT=5

Nota.- Para cambiar el archivo /etc/default/grub y evitarnos problemas es mejor usar el editor nano porque así evitamos introducir caracteres extraños y muchas veces invisibles en el código.

Paso 3.- Actualice el archivo /boot/grub/grub.cfg; ejecutando en consola update-grub

En la terminal cualquiera de estas dos:
sudo update-grub
sudo update-grub2
Nota: Necesario crear alias.

`alias update-grub=’grub2-mkconfig -o /boot/grub2/grub.cfg’`

This means that, when we write update-grub as administrator in terminal (in current session), it executes grub2-mkconfig -o /boot/grub2/grub.cfg command. Unfortunately, this type of alias is available for only current session.

So if you want to make alias permanent, follow these steps:

  • Open terminal
  • Type command:

    • gedit .bashrc

  • You can write the following command after ‘# ./etc/bashrc’ line or at the end of the document. Don’t write it in the middle because there are conditional situations so you can break everything:

    • alias update-grub=’sudo grub2-mkconfig -o /boot/grub2/grub.cfg’

    Proceso de arranque en Linux

    El Proceso de arranque en Linux es el proceso de inicialización del sistema operativo Linux. Es en muchos aspectos similar a los procesos de arranque de BSD y otros sistemas Unix, de los cuales deriva.

     

    Descripción general del proceso típico

    En Linux, el flujo de control durante el arranque es desde el BIOS, al gestor de arranque y al núcleo (kernel). El núcleo inicia el planificador (para permitir la multitarea) y ejecuta el primer espacio de usuario (es decir, fuera del espacio del núcleo) y el programa de inicialización (que establece el entorno de usuario y permite la interacción del usuario y el inicio de sesión), momento en el que el núcleo se inactiva hasta que sea llamado externamente.

    La etapa del cargador de arranque no es totalmente necesaria. Determinadas BIOS pueden cargar y pasar el control a Linux sin hacer uso del cargador. Cada proceso de arranque será diferente dependiendo de la arquitectura del procesador y el BIOS.

    1. El BIOS realiza las tareas de inicio específicas de la plataforma de hardware.
    2. Una vez que el hardware es reconocido y se inicia correctamente, el BIOS carga y ejecuta el código de la partición de arranque del dispositivo de arranque designado, que contiene la fase 1 de un gestor de arranque Linux. La fase 1 carga la fase 2 (la mayor parte del código del gestor de arranque). Algunos cargadores pueden utilizar una fase intermedia (conocida como la fase 1.5) para lograr esto, ya que los modernos discos de gran tamaño no pueden ser totalmente leídos sin código adicional.
    3. El gestor de arranque a menudo presenta al usuario un menú de opciones posibles de arranque. A continuación, carga el sistema operativo, que descomprime en la memoria, y establece las funciones del sistema como del hardware esencial y la paginación de memoria, antes de llamar a la función start_kernel().
    4. La función start_kernel() a continuación realiza la mayor parte de la configuración del sistema (interrupciones, el resto de la gestión de memoria, la inicialización del dispositivo, controladores, etc), antes de continuar por separado el proceso inactivo y planificador, y el proceso de Init (que se ejecuta en el espacio de usuario).
    5. El planificador toma control efectivo de la gestión del sistema, y el núcleo queda dormido (inactivo).
    6. El proceso Init ejecuta secuencias de comandos (Scripts) necesarios para configurar todos los servicios y estructuras que no sean del sistema operativo, a fin de permitir que el entorno de usuario sea creado y pueda presentarse al usuario con una pantalla de inicio de sesión.

    En el apagado, Init es llamado a cerrar toda las funcionalidades del espacio de usuario de una manera controlada, de nuevo a través de secuencias de comandos, tras lo cual el Init termina y el núcleo ejecuta el apagado.

    Espacio de usuario temprano

    El espacio de usuario temprano se utiliza en las versiones más recientes del kernel de Linux para sustituir tantas funciones como sea posible que originalmente se harían en el núcleo durante el proceso de inicio. Los usos típicos del espacio de usuario temprano son para detectar que controladores de dispositivos (Drivers) son necesarios para cargar el sistema de archivos del espacio de usuario principal y cargarlos desde un sistema de archivos temporal.

    Fase del cargador de arranque

    Un cargador de arranque (boot loader en inglés) es un programa diseñado exclusivamente para cargar un sistema operativo en memoria. La etapa del cargador de arranque es diferente de una plataforma a otra.

    Como en la mayoría de arquitecturas este programa se encuentra en el MBR, el cual es de 512 bytes, este espacio no es suficiente para cargar en su totalidad un sistema operativo. Por eso, el cargador de arranque consta de varias etapas. Las primeras operaciones las realiza el BIOS. En esta etapa se realizan operaciones básicas de hardware. En esta primera etapa se localiza el sector de arranque (o MBR) y se carga el cargador de este sector (normalmente una parte de LILO o GRUB).

    A partir de ese momento, el proceso de arranque continúa de la siguiente manera:

    La primera etapa del cargador de arranque carga el resto del gestor de arranque, que normalmente da un mensaje que pregunta que sistema operativo (o tipo de sesión) el usuario desea inicializar. Bajo LILO, esto se hace a través del mapa instalado que lee el archivo de configuración /etc/lilo.conf para identificar los sistemas disponibles. Incluye datos como la partición de arranque y la localización del kernel para cada uno, así como las opciones personalizadas en su caso. El sistema operativo seleccionado es cargado en la memoria RAM, un sistema de archivos mínimo inicial se establece en la memoria RAM desde un archivo de imagen (» initrd «), y junto con los parámetros adecuados, el control se pasa al sistema operativo activado recientemente.

    LILO y GRUB difieren en algunos aspectos:

    • LILO no entiende los sistemas de archivos, por lo que utiliza desplazamientos de disco sin procesar y el BIOS para cargar los datos. Se carga el código del menú y, a continuación, en función de la respuesta, carga, o el sector MBR del disco de 512 bytes como en Microsoft Windows, o la imagen del kernel de Linux.
    • GRUB por el contrario comprende los sistemas de archivos comunes ext2 , ext3 y ext4. Debido a que GRUB almacena sus datos en un archivo de configuración en vez de en el MBR y a que contiene un interfaz de línea de comandos, a menudo es más fácil rectificar o modificar GRUB si está mal configurado o corrupto.

    GRUB

    GRUB se carga y se ejecuta en 4 etapas:

    1. La primera etapa del cargador la lee el BIOS desde el MBR.
    2. La primera etapa carga el resto del gestor de arranque (segunda etapa). Si la segunda etapa está en una unidad grande, en ocasiones se carga una fase intermedia 1.5, que contiene código adicional para permitir que los cilindros por encima de 1024, o unidades tipo LBA, puedan leerse. El gestor de arranque 1.5 es almacenado (si es necesario) en el MBR o en la partición de arranque.
    3. La segunda etapa del gestor de arranque ejecuta y muestra el menú de inicio de GRUB que permite al usuario elegir un sistema operativo y examinar y modificar los parámetros de inicio.
    4. Después de elegir un sistema operativo, se carga y se le pasa el control.

    GRUB soporta métodos de arranque directo, arranque chain-loading, LBA, ext2, ext3, ext4 y hasta «un pre-sistema operativo en máquinas x86 totalmente basado en comandos». Contiene tres interfaces: un menú de selección, un editor de configuración, y una consola de línea de comandos.

    LILO

    LILO es más antiguo. Es casi idéntico a GRUB en su proceso, excepto que no contiene una interfaz de línea de comandos. Por lo tanto todos los cambios en su configuración deben ser escritos en el MBR y luego reiniciar el sistema. Un error en la configuración puede dejar el disco inservible para el proceso de arranque hasta tal grado, que sea necesario usar otro dispositivo (disquete, etc) que contenga un programa capaz de arreglar el error. Además, no entiende el sistema de archivos. En su lugar, la ubicación de los archivos de imagen se almacenan directamente en el MBR y el BIOS se utiliza para acceder a ellos directamente.

    Loadlin

    Otra forma de cargar Linux es desde DOS o Windows 9x, donde el núcleo de Linux reemplaza completamente la copia de funcionamiento de estos sistemas operativos. Esto puede ser útil en el caso de hardware que necesita ser conectado a través del software y la configuración de estos programas sólo está disponible para DOS y no para Linux, debido a cuestiones de secretos industriales y código propietario. Sin embargo, esta tediosa forma de arranque ya no es necesaria en la actualidad ya que Linux tiene drivers para multitud de dispositivos hardware. Aun así, esto era muy útil en el pasado.

    Otro caso es cuando Linux se encuentra en un dispositivo que el BIOS no lo tiene disponible para el arranque. Entonces, DOS o Windows pueden cargar el driver apropiado para el dispositivo superando dicha limitación del BIOS, y cargar Linux desde allí.

    Fase del kernel

    El kernel de Linux se encarga de todos los procesos del sistema operativo, como la gestión de memoria, planificador de tareas, I/O, comunicación entre procesos, y el control general del sistema. Este se carga en dos etapa: en la primera etapa el kernel (como un archivo imagen comprimido) se carga y se descomprime en memoria, y algunas funciones fundamentales como la gestión de memoria de base se establecen. El control entonces se cambia a la etapa final para iniciar el kernel principal. Una vez que el núcleo está en pleno funcionamiento – y como parte de su puesta en marcha, después de ser cargado y ejecutado – el kernel busca un proceso de inicio para ejecutar, que (separadamente) fija un espacio de usuario y los procesos necesarios para un entorno de usuario y ultimar la entrada . Al núcleo en sí entonces se le permite pasar a inactivo, sujeto a las llamadas de otros procesos.

    Fase de carga del kernel

    El kernel es cargado normalmente como un archivo imagen, comprimido dentro de otro con zlib como zImage o bzImage. Contiene una cabecera de programa que hace una cantidad mínima de instalación del hardware, descomprime la imagen completamente en la memoria alta , teniendo en cuenta cualquier disco RAM si está configurado. A continuación, lleva a cabo su ejecución. Esto se realiza llamando la función startup del kernel (en los procesadores x86 a través de la funciónstartup_32() del archivo /arch/i386/boot/head).

    Fase de inicio del kernel

    La función de arranque para el kernel (también llamado intercambiador o proceso 0) establece la gestión de memoria (tablas de paginación y paginación de memoria), detecta el tipo de CPU y cualquier funcionalidad adicional como capacidades depunto flotante, y después cambia a las funcionalidades del kernel para arquitectura no específicas de Linux, a través de una llamada a la función start_kernel().

    start_kernel ejecuta una amplia gama de funciones de inicialización. Establece el manejo de interrupciones (IRQ), configura memoria adicional, comienza el proceso de inicialización (procesa el espacio del primer usuario), y luego comienza la tarea inactiva a través de cpu_idle(). En particular, el proceso de inicio del kernel también monta el disco RAM inicial («initrd«) que se ha cargado anteriormente como el sistema raíz temporal durante la fase de arranque. Esto permite que los módulos controladores se carguen sin depender de otros dispositivos físicos y drivers y mantiene el kernel más pequeño. El sistema de archivos raíz es cambiado más tarde a través de la llamada a pivot_root(), que desmonta el sistema de archivos temporal y lo reemplaza por el real una vez que éste sea accesible. La memoria utilizada por el sistema de archivos temporal es entonces recuperada.

    Por lo tanto, el núcleo inicializa los dispositivos, monta el sistema de archivos raíz especificado por el gestor de arranque como de sólo lectura , y se ejecuta Init (/sbin/init), que es designado como el primer proceso ejecutado por el sistema (PID=1). También puede ejecutar opcionalmente initrd para permitir instalar y cargar dispositivos relacionados (disco RAM o similar), para ser manipulados antes de que el sistema de archivos raíz está montado.

    En este punto, con las interrupciones habilitadas, el programador puede tomar el control de la gestión general del sistema, para proporcionar multitarea preventiva, e iniciar el proceso para continuar con la carga del entorno de usuario en el espacio de usuario.

    El proceso de inicio

    El trabajo de Init es «conseguir que todo funcione como debe ser» una vez que el kernel está totalmente en funcionamiento. En esencia, establece y opera todo el espacio de usuario. Esto incluye la comprobación y montaje de sistemas de archivos, la puesta en marcha los servicios de usuario necesarios y, en última instancia, cambiar al entorno de usuario cuando el inicio del sistema se ha completado. Es similar a los procesos Init de Unix y BSD, de la que deriva, pero en algunos casos se ha apartado o se hicieron a la medida. En un sistema Linux estándar, Init se ejecuta con un parámetro, conocido como nivel de ejecución, que tiene un valor entre 1 y 6, y que determina que subsistemas pueden ser operacionales. Cada nivel de ejecución tiene sus propios scripts que codifican los diferentes procesos involucrados en la creación o salida del nivel de ejecución determinado, y son estas secuencias de comandos los necesarios en el proceso de arranque. Los scripts de Init se localizan normalmente en directorios con nombres como «/etc/rc...«. El archivo de configuración de más alto nivel para Init es /etc/inittab.

    Durante el arranque del sistema, se verifica si existe un nivel de ejecución predeterminado en el archivo /etc/inittab, si no, se debe introducir por medio de la consola del sistema. Después se procede a ejecutar todos los scripts relativos al nivel de ejecución especificado.

    Después de que se han dado lugar todos los procesos especificados, Init se aletarga, y espera a que uno de estos tres eventos sucedan:- que procesos comenzados finalicen o mueran; un fallo de la señal de potencia (energía); o una petición a través de /sbin/telinit para cambiar el nivel de ejecución.

    Working with Kernels

    • admin 

    • Listing Currently-Loaded Modules

    You can list all kernel modules that are currently loaded into the kernel by running the lsmodcommand:

    ~]$ lsmod
Module                  Size  Used by
xfs                   803635  1
exportfs                3424  1 xfs
vfat                    8216  1
fat                    43410  1 vfat
tun                    13014  2
fuse                   54749  2
ip6table_filter         2743  0
ip6_tables             16558  1 ip6table_filter
ebtable_nat             1895  0
ebtables               15186  1 ebtable_nat
ipt_MASQUERADE          2208  6
iptable_nat             5420  1
nf_nat                 19059  2 ipt_MASQUERADE,iptable_nat
rfcomm                 65122  4
ipv6                  267017  33
sco                    16204  2
bridge                 45753  0
stp                     1887  1 bridge
llc                     4557  2 bridge,stp
bnep                   15121  2
l2cap                  45185  16 rfcomm,bnep
cpufreq_ondemand        8420  2
acpi_cpufreq            7493  1
freq_table              3851  2 cpufreq_ondemand,acpi_cpufreq
usb_storage            44536  1
sha256_generic         10023  2
aes_x86_64              7654  5
aes_generic            27012  1 aes_x86_64
cbc                     2793  1
dm_crypt               10930  1
kvm_intel              40311  0
kvm                   253162  1 kvm_intel
[output truncated]
    Each row of lsmod output specifies:
    • the name of a kernel module currently loaded in memory;
    • the amount of memory it uses; and,
    • the sum total of processes that are using the module and other modules which depend on it, followed by a list of the names of those modules, if there are any. Using this list, you can first unload all the modules depending the module you want to unload.
    Finally, note that lsmod output is less verbose and considerably easier to read than the content of the /proc/modules pseudo-file.

    • Displaying Information About a Module

    You can display detailed information about a kernel module by running the modinfo <module_name>  command.

    Module names do not end in .ko

    When entering the name of a kernel module as an argument to one of the module-init-toolsutilities, do not append a .ko extension to the end of the name. Kernel module names do not have extensions: their corresponding files do.
    For example, to display information about the e1000e module, which is the Intel PRO/1000 network driver, run:

    Example 25.1. Listing information about a kernel module with lsmod

    ~]# modinfo e1000e
filename:       /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/net/e1000e/e1000e.ko
version:        1.2.7-k2
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     93CB73D3995B501872B2982
alias:          pci:v00008086d00001503sv*sd*bc*sc*i*
alias:          pci:v00008086d00001502sv*sd*bc*sc*i*
[some alias lines omitted]
alias:          pci:v00008086d0000105Esv*sd*bc*sc*i*
depends:
vermagic:       2.6.32-71.el6.x86_64 SMP mod_unload modversions
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm:           EEE:Enable/disable on parts that support the feature (array of int)
    Here are descriptions of a few of the fields in modinfo output:
    filename
    The absolute path to the .ko kernel object file. You can use modinfo -n as a shortcut command for printing only the filename field.
    description
    A short description of the module. You can use modinfo -d as a shortcut command for printing only the description field.
    alias
    The alias field appears as many times as there are aliases for a module, or is omitted entirely if there are none.
    depends
    This field contains a comma-separated list of all the modules this module depends on.

    Omitting the depends field

    If a module has no dependencies, the depends field may be omitted from the output.
    parm


    Each parm field presents one module parameter in the form parameter_name:description, where:
    • parameter_name is the exact syntax you should use when using it as a module parameter on the command line, or in an option line in a .conf file in the /etc/modprobe.d/ directory; and,
    • description is a brief explanation of what the parameter does, along with an expectation for the type of value the parameter accepts (such as int, unit or array of int) in parentheses.
    You can list all parameters that the module supports by using the -p option. However, because useful value type information is omitted from modinfo -p output, it is more useful to run:

    Example 25.2. Listing module parameters

    ~]# modinfo e1000e | grep "^parm" | sort
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm:           EEE:Enable/disable on parts that support the feature (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)

     

    •  Loading a Module

    To load a kernel module, run modprobe <module_name>  as root. For example, to load the wacom module, run:
    ~]# modprobe wacom
    By default, modprobe attempts to load the module from /lib/modules/<kernel_version>/kernel/drivers/. In this directory, each type of module has its own subdirectory, such as net/ and scsi/, for network and SCSI interface drivers respectively.
    Some modules have dependencies, which are other kernel modules that must be loaded before the module in question can be loaded. The modprobe command always takes dependencies into account when performing operations. When you ask modprobe to load a specific kernel module, it first examines the dependencies of that module, if there are any, and loads them if they are not already loaded into the kernel. modprobe resolves dependencies recursively: it will load all dependencies of dependencies, and so on, if necessary, thus ensuring that all dependencies are always met.
    You can use the -v (or --verbose) option to cause modprobe to display detailed information about what it is doing, which may include loading module dependencies. The following is an example of loading the Fibre Channel over Ethernet module verbosely:

    Example 25.3. modprobe -v shows module dependencies as they are loaded

    ~]# modprobe -v fcoe
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/scsi_tgt.ko
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/scsi_transport_fc.ko
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/libfc/libfc.ko
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/libfcoe.ko
insmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko

     

    Example 25.3, “modprobe -v shows module dependencies as they are loaded” shows that modprobeloaded the scsi_tgt, scsi_transport_fc, libfc and libfcoe modules as dependencies before finally loading fcoe. Also note that modprobe used the more “primitive” insmod command to insert the modules into the running kernel.

    Always use modprobe instead of insmod!

    Although the insmod command can also be used to load kernel modules, it does not resolve dependencies. Because of this, you should always load modules using modprobe instead.
    • Unloading a Module

     

    You can unload a kernel module by running modprobe -r <module_name>  as root. For example, assuming that the wacom module is already loaded into the kernel, you can unload it by running:
    ~]# modprobe -r wacom
    However, this command will fail if a process is using:
    • the wacom module,
    • a module that wacom directly depends on, or,
    • any module that wacom—through the dependency tree—depends on indirectly.
    Refer to Section 25.1, “Listing Currently-Loaded Modules” for more information about using lsmod to obtain the names of the modules which are preventing you from unloading a certain module.
    For example, if you want to unload the firewire_ohci module (because you believe there is a bug in it that is affecting system stability, for example), your terminal session might look similar to this:
    ~]# modinfo -F depends firewire_ohci
depends:        firewire-core
~]# modinfo -F depends firewire_core
depends:        crc-itu-t
~]# modinfo -F depends crc-itu-t
depends:
    You have figured out the dependency tree (which does not branch in this example) for the loaded Firewire modules: firewire_ohci depends on firewire_core, which itself depends on crc-itu-t.
    You can unload firewire_ohci using the modprobe -v -r <module_name>  command, where -r is short for --remove and -v for --verbose:
    ~]# modprobe -r -v firewire_ohci
rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/firewire/firewire-ohci.ko
rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/firewire/firewire-core.ko
rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/lib/crc-itu-t.ko
    The output shows that modules are unloaded in the reverse order that they are loaded, given that no processes depend on any of the modules being unloaded.

    Do not use rmmod directly!

    Although the rmmod command can be used to unload kernel modules, it is recommended to use modprobe -r instead.
    • Setting Module Parameters

     

    Like the kernel itself, modules can also take parameters that change their behavior. Most of the time, the default ones work well, but occasionally it is necessary or desirable to set custom parameters for a module. Because parameters cannot be dynamically set for a module that is already loaded into a running kernel, there are two different methods for setting them.
    1. You can unload all dependencies of the module you want to set parameters for, unload the module using modprobe -r, and then load it with modprobe along with a list of customized parameters. This method is often used when the module does not have many dependencies, or to test different combinations of parameters without making them persistent, and is the method covered in this section.
    2. Alternatively, you can list the new parameters in an existing or newly-created file in the /etc/modprobe.d/ directory. This method makes the module parameters persistent by ensuring that they are set each time the module is loaded, such as after every reboot or modprobe command. This method is covered in Section 25.6, “Persistent Module Loading”, though the following information is a prerequisite.
    You can use modprobe to load a kernel module with custom parameters using the following command line format:
    Example 25.4. Supplying optional parameters when loading a kernel module

    ~]# modprobe <module_name> [parameter=value]
    When loading a module with custom parameters on the command line, be aware of the following:
    • You can enter multiple parameters and values by separating them with spaces.
    • Some module parameters expect a list of comma-separated values as their argument. When entering the list of values, do not insert a space after each comma, or modprobe will incorrectly interpret the values following spaces as additional parameters.
    • The modprobe command silently succeeds with an exit status of 0 if:
      • it successfully loads the module, or
      • the module is already loaded into the kernel.
      Thus, you must ensure that the module is not already loaded before attempting to load it with custom parameters. The modprobe command does not automatically reload the module, or alert you that it is already loaded.
    Here are the recommended steps for setting custom parameters and then loading a kernel module. This procedure illustrates the steps using the e1000e module, which is the network driver for Intel PRO/1000 network adapters, as an example:
    Procedure 25.1. Loading a Kernel Module with Custom Parameters

    1. First, ensure the module is not already loaded into the kernel:
      ~]# lsmod |grep e1000e
~]#
      Output indicates that the module is already loaded into the kernel, in which case you must first unload it before proceeding. Refer to Section 25.4, “Unloading a Module” for instructions on safely unloading it.
    2. Load the module and list all custom parameters after the module name. For example, if you wanted to load the Intel PRO/1000 network driver with the interrupt throttle rate set to 3000 interrupts per second for the first, second and third instances of the driver, and Energy Efficient Ethernet (EEE) turned on[6], you would run, as root:
      ~]# modprobe e1000e InterruptThrottleRate=3000,3000,3000 EEE=1
      This example illustrates passing multiple values to a single parameter by separating them with commas and omitting any spaces between them.
    • Persistent Module Loading

    As shown in Example 25.1, “Listing information about a kernel module with lsmod”, many kernel modules are loaded automatically at boot time. You can specify additional modules to be loaded by creating a new <file_name>.modules file in the /etc/sysconfig/modules/ directory, where <file_name> is any descriptive name of your choice. Your <file_name>.modules files are treated by the system startup scripts as shell scripts, and as such should begin with an interpreter directive (also called a “bang line”) as their first line:
    Example 25.5. First line of a file_name.modules file

    #!/bin/sh
    Additionally, the <file_name>.modules file should be executable. You can make it executable by running:
    modules]# chmod +x <file_name>.modules
    For example, the following bluez-uinput.modules script loads the uinput module:
    Example 25.6. /etc/sysconfig/modules/bluez-uinput.modules

    #!/bin/sh

if [ ! -c /dev/input/uinput ] ; then
        exec /sbin/modprobe uinput >/dev/null 2>&1
fi
    The if-conditional statement on the third line ensures that the /dev/input/uinput file doesnot already exist (the ! symbol negates the condition), and, if that is the case, loads the uinputmodule by calling exec /sbin/modprobe uinput. Note that the uinput module creates the /dev/input/uinput file, so testing to see if that file exists serves as verification of whether the uinput module is loaded into the kernel.
    The following >/dev/null 2>&1 clause at the end of that line redirects any output to /dev/null so that the modprobe command remains quiet.

    Módulos del Kernel Linux

    • admin 

    Fuente: http://web.mit.edu/rhel-doc/3/rhel-sag-es-3/ch-kernel-modules.html

    El kernel de Linux tiene un diseño modular. En el momento de arranque, sólo se carga un kernel residente mínimo en memoria. Por ello, cuando un usuario solicita alguna característica que no esta presente en el kernel residente, se carga dinámicamente en memoria un módulo kernel, también conocido algunas veces como un controlador.

    Durante la instalación, se prueba el hardware en el sistema. Basado en esta prueba y en la información proporcionada por el usuario, el programa de instalación decide qué módulos necesita cargar en el momento de arranque. El programa de instalación configura el mecanismo de carga dinámica para que funcione de forma transparente.

    Si se añade un nuevo hardware después de la instalación y este requiere un módulo kernel, el sistema debe ser configurado para cargar el módulo adecuado para el nuevo hardware. Cuando el sistema es arrancado con el nuevo hardware, se ejecuta el programa Kudzu detecta el nuevo hardware si es soportado y configura el módulo necesario para él. El módulo tambíen puede ser especificado manualmente modificando el archivo de configuración del módulo, /etc/modules.conf.

     

    Nota Nota
    Los módulos de tarjetas de vídeo usados para desplegar la interfaz del sistema X Window son parte del paquete XFree86, no del kernel; por lo tanto, este capítulo no se aplica a ellos.

    Por ejemplo, si un sistema incluye un adaptador de red SMC EtherPower 10 PCI, el archivo de configuración del módulo contiene la línea siguiente:

    alias eth0 tulip

    Si una segunda tarjeta de red es añadida al sistema y es idéntica a la primera tarjeta, añada la línea siguiente al archivo /etc/modules.conf:

    alias eth1 tulip

    Consulte el Manual de referencia de Red Hat Enterprise Linux para una lista alfabética de módulos de kernel y hardware soportado por los módulos.

    Nota: Kernels antiguos.

    40.1. Utilidades del módulo del kernel

    Está disponible un grupo de comandos para el manejo de módulos kernel si el paquete modutils está instalado. Use estos comandos para determinar si un módulo ha sido cargado exitósamente o cuando se esté probando módulos diferentes para una nueva pieza de hardware.

    El comando /sbin/lsmod muestra una lista de los módulos cargados actualmente. Por ejemplo:

    Module                  Size  Used by    Not tainted
iptable_filter          2412   0 (autoclean) (unused)
ip_tables              15864   1 [iptable_filter]
nfs                    84632   1 (autoclean)
lockd                  59536   1 (autoclean) [nfs]
sunrpc                 87452   1 (autoclean) [nfs lockd]
soundcore               7044   0 (autoclean)
ide-cd                 35836   0 (autoclean)
cdrom                  34144   0 (autoclean) [ide-cd]
parport_pc             19204   1 (autoclean)
lp                      9188   0 (autoclean)
parport                39072   1 (autoclean) [parport_pc lp]
autofs                 13692   0 (autoclean) (unused)
e100                   62148   1
microcode               5184   0 (autoclean)
keybdev                 2976   0 (unused)
mousedev                5656   1
hid                    22308   0 (unused)
input                   6208   0 [keybdev mousedev hid]
usb-uhci               27468   0 (unused)
usbcore                82752   1 [hid usb-uhci]
ext3                   91464   2
jbd                    56336   2 [ext3]

    Por cada línea, la primera columna es el nombre del módulo, la segunda columna es el tamaño del módulo y la tercera es el recuento de usos.

    La información después del recuento de usos varía un poco por módulo. Si se lista (unused) en la línea del módulo, el módulo no está siendo usado actualmente. Si (autoclean) está en la línea para el módulo, este puede ser limpiado automáticamente por el comando rmmod -a. Cuando se ejecuta este comando, cualquier módulo que este etiquetado con autoclean, que no ha sido usado desde la acción previa de autoclean, será descargado. Red Hat Enterprise Linux no realiza esta acción de autoclean por defecto.

    Si el nombre de un módulo esta listado al final de la línea entre corchetes, el módulo entre corchetes es dependiente del módulo listado en la primera columna de la línea. Por ejemplo, en la línea

    usbcore                82752   1 [hid usb-uhci]

    los módulo del kernel hid usb-uhci dependen del módulo usbcore.

    La salida /sbin/lsmod es la misma que la salida de /proc/modules.

    Para cargar un módulo del kernel, use el comando /sbin/modprobe seguido del nombre del módulo. Por defecto, modprobe intenta cargar el módulo desde los subdirectorios/lib/modules/<kernel-version>/kernel/drivers/. Hay un subdirectorio para cada tipo de módulo, tal como el subdirectorio net/ para los controladores de interfaces de red. Algunos módulos del kernel tienen dependencias, es decir que otros módulos deben ser cargados antes para que el otro se cargue. El comando /sbin/modprobe verifica estas dependencias y carga los módulos necesarios antes de cargar el módulo específico.

    Por ejemplo, el comando

    /sbin/modprobe hid

    carga cualquier dependencia de módulos y luego el módulo hid.

    Para imprimir a la pantalla todos los comandos a medida en que /sbin/modprobe los ejecuta, use la opción -v. Por ejemplo:

    /sbin/modprobe -v hid

    Se despliega una salida similar a lo siguiente:

    /sbin/insmod /lib/modules/2.4.21-1.1931.2.399.ent/kernel/drivers/usb/hid.o
Using /lib/modules/2.4.21-1.1931.2.399.ent/kernel/drivers/usb/hid.o
Symbol version prefix 'smp_'

    El comando /sbin/insmod también existe para cargar módulos kernel; sin embargo no resuelve dependencias. Por ello se recomienda el uso de /sbin/modprobe.

    Para descargar módulos del kernel, use el comando /sbin/rmmod seguido por el nombre del módulo. La utilidad rmmod sólo descarga módulos que ya no son usados y que no son una dependencia de otro módulo en uso.

    Por ejemplo, el comando

    /sbin/rmmod hid

    baja el módulo del kernel hid.

    Otra utilidad muy conveniente es modinfo. Use el comando /sbin/modinfo para mostrar información sobre el módulo del kernel. La sintaxis general es:

    /sbin/modinfo [options] <module>

    Las opciones incluyen -d, lo cual muestra una breve descripción del módulo, y -p lo que lista los parámetros que el módulo soporta. Para una lista completa de las opciones, consulte la página del manual de modinfo (man modinfo).

    Cómo cambiar los niveles de ejecución en Fedora 15 y posteriores

    Con la aparición de Fedora 15 Lovelock, muchas cosas han cambiado en esta distribución GNU/Linux y una de ellas es la forma de configurar los distintos niveles de ejecución del sistema.

    Recordemos que en versiones anteriores, la configuración de los distintos niveles de ejecución que por defecto podía emplear el sistema, se realizaba por medio de la edición del archivo ‘inittab’.

    • $ su -c ‘nano /etc/inittab’

    id:nivel-ejecución:initdefault:

    Siendo ‘nivel-ejecución’ uno de los siguientes valores:

    0 –  Detiene todos los procesos activos en el sistema y realiza un completo apagado del equipo.

    1 – Nivel monousuario sin acceso a los servicios de red.

    2 – Nivel multiusuario en modo consola sin acceso a los servicios de red.

    3 – Nivel multiusuario en modo consola con acceso a los servicios de red.

    4 – Nivel no usado.

    5 – Nivel multiusuario en modo gráfico (X11).

    6 – Detiene todos los procesos activos en el sistema y realiza el reinicio del equipo.

    En la actualidad, ha variado sustancialmente ésta forma de establecer los distintos niveles de ejecución del sistema (ahora llamados target), debido al uso de ‘systemd‘ en detrimento del archivo ‘inittab’.

    Puesto que el actual sistema cuenta por defecto con dos (target) principales: (multi-user) equivalente al modo 3 y (graphical) equivalente almodo 5, la forma de pasar de un modo a otro, es la siguiente: 

    • $ su -c ‘ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target’ (para el modo 3) ó
    • $ su -c ‘ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target’ (para el modo 5)
    • Reiniciar el sistema.