Tabla de contenidos
Es inteligente por su parte como administrador de sistemas conocer profundamente como el sistema Debian comienza y se configura. Aunque los detalles concretos están en el código fuente de los paquetes instalados y su documentación, es un poco abrumador para la mayoría de nosotros.
Hice lo mejor que pude para proporcionar un resumen de los puntos principales del sistema Debian y su configuración en base al conocimiento actual y previo mio y de muchos otros. Ya que el sistema Debian es un elemento en movimiento, la situación del sistema puede haber cambiado. Antes de realizar cualquier cambio en el sistema, debería consultar la documentación actual de cada paquete.
Sugerencia | |
---|---|
bootup(7)
describe el proceso de arranque del sistema basado en
|
Sugerencia | |
---|---|
boot(7) describes the system bootup process based on UNIX System V Release 4. (Older Debian) |
Un sistema de ordenador pasa por diferentes fases en el proceso de arranque desde el encendido hasta que le ofrece al usuario la funcionalidad completa del sistema operativo (SO).
Por simplicidad, limité la discusión a la de una típica plataforma PC con la instalación por defecto.
El proceso normal de arranque es como un cohete de cuatro fases. Cada fase del cohete cede el control del sistema a la siguiente.
Desde luego, esto puede ser configurado de otra manera. Por ejemplo, si compila su propio núcleo, puede saltar el paso del sistema mini-Debian. Así que, por favor, no asuma cuál es el caso de su sistema hasta que no lo compruebe por si mismo.
Nota | |
---|---|
Para plataformas de PC antiguas como los sistemas SUN o Macintosh, la BIOS en ROM y la partición en el disco puede ser bastante diferentes (Sección 9.5.2, “Configuración del particionado de disco”). Por favor busque la documentación específica de su plataforma para cada caso en el lugar correspondiente. |
La BIOS es la primera fase del proceso de arranque que comienza con hecho del encendido. La BIOS que reside en la memoria de solo lectura (ROM) se ejecuta desde una dirección de memoria específica con la que es inicializada el contador del programa por el hecho del encendido.
La BIOS realiza la inicialización básica del «hardware« (POST: encendido y autocomprobación (power on self test)) y pasa el control del sistema al siguiente paso. La BIOS es normalmente proporcionado con el «hardware«.
La pantalla de inicio de la BIOS normalmente muestra que tecla(s) pulsar para entrar en la configuración de la BIOS para cambiar su comportamiento. Las teclas normalmente utilizadas son F1, F2, F10, Esc, Ins, and Del. Si la pantalla de inicio de la BIOS está oculta por alguna otra pantalla, puede pulsar algunas teclas como Esc para inhabilitarla. Estas teclas tienen una gran dependencia del «hardware«.
La ubicación del «hardware« y la prioridad del código de comienzo de la BIOS se pueden seleccionar desde la pantalla de configuración del BIOS. Por lo general, los primeros sectores del primer dispositivo seleccionado (disco duro, disquete, CD-ROM,...) se cargan en la memoria y se ejecuta dicho código inicial. Este código inicial puede ser cualquiera de los siguientes:
El código del cargador de arranque
El código del núcleo del escalón del SO como FreeDOS
El código del núcleo del SO objetivo si encaja en su pequeño espacio
Normalmente, el sistema se inicia desde una partición especifica del disco duro primario. En los PC antiguos los dos primeros sectores del disco duro contienen el registro maestro de arranque (master boot record , MBR). La información de la partición del disco incluye la selección de arranque que es guardada al final del MBR. El código de arranque que primero se ejecuta después de la BIOS es el que ocupa el resto del MBR.
El cargador de arranque es la segunda fase del proceso de arranque que comienza con la BIOS. Carga la imagen del núcleo del sistema y la imagen de initrd en memoria y pasa el control a estos. La imagen de initrd es la imagen del sistema de archivos raíz y su compatibilidad depende del cargador usado.
The Debian system normally uses the Linux kernel as the default system kernel. The initrd image for the current 2.6/3.x Linux kernel is technically the initramfs (initial RAM filesystem) image. The basic initrd image is a compressed cpio archive of files in the root filesystem. The kernel can update microcode very early during boot before loading this basic initrd image. This is facilitated by the combined initrd image which is microcode binary blob in uncompressed cpio format followed by the basic initrd image.
Sugerencia | |
---|---|
You can inspect the content of the initrd image file using
lsinitramfs(8)
and
unmkinitramfs(8)
from the |
La instalación por defecto del sistema Debian ubica el la primera fase el código del cargador de arranque GRUB en el MBR para la plataforma PC. Existen muchos cargadores de arranque y opciones de configuración disponibles.
Tabla 3.1. Relación de cargadores de arranque
paquete | popularidad | tamaño | initrd | cargador de arranque | descripción |
---|---|---|---|---|---|
grub-legacy | V:0, I:2 | 729 | Soporte | Antiguo GRUB | Es lo suficientemente inteligente para comprender las particiones de disco y los sistemas de órdenes como vfat, ext3, .... |
grub-pc | V:27, I:825 | 532 | Soporte | GRUB 2 | Es lo suficientemente inteligente para entender las particiones de disco y los sistemas de archivos como vfat, ext4, …. (por defecto) |
grub-rescue-pc | V:0, I:1 | 6286 | Soporte | GRUB 2 | Imagen de rescate de inicio GRUB 2 (CD and disquete) (versión PC/BIOS) |
lilo | V:0, I:3 | 693 | Soporte | Lilo | Esto depende de las ubicaciónes de los sectores de datos en el disco duro (Old) |
syslinux | V:4, I:54 | 344 | Soporte | Isolinux | Entiende el sistema de archivos ISO9660. Es usado por arranque de CD. |
syslinux | V:4, I:54 | 344 | Soporte | Syslinux | Entiende el sistema de archivos MSDOS (FAT). Es usado para el arranque de diquete. |
loadlin | V:0, I:1 | 83 | Soporte | Loadlin | Nuevo sistema para el arranque del sistema FreeDOS/MSDOS. |
mbr | V:0, I:9 | 49 | No soportado | MBR por Neil Turton | Este el software libre que sustituye MBR de MSDOS. Solo comprende particiones de disco. |
Aviso | |
---|---|
No pruebe cargadores de inicio sin tener un medio de inicio de rescate (USB,
CD o disquete) creado de las imagenes del paquete
|
En el antiguo GRUB el archivo del menú de configuración está ubicado en
/boot/grub/menu.lst
». Por ejemplo, podría tener las
siguientes entradas:
title Debian GNU/Linux root (hd0,2) kernel /vmlinuz root=/dev/hda3 ro initrd /initrd.img
En GRUB 2, el archivo del menú de configuración está ubicado en
«/boot/grub/grub.cfg
». Se genera automáticamente por
«/usr/sbin/update-grub
» usando las plantillas de
«/etc/grub.d/*
» y configuraciones de
«/etc/default/grub
». Por ejemplo, puede tener el
contenido siguiente:
menuentry «Debian GNU/Linux« { set root=(hd0,3) linux /vmlinuz root=/dev/hda3 initrd /initrd.img }
Para estos ejemplos, los parámetros de GRUB tienen el siguiente significado:
Tabla 3.2. El significado de los parámetros de GRUB
parámetro GRUB | significado |
---|---|
root
|
usa la tercera partición de disco primario configurándolo como
«(hd0,2) » en el antiguo GRUB o como
«(hd0,3) » en GRUB 2
|
kernel
|
utiliza el núcleo ubicado en «/vmlinuz » con el parámetro
del núcleo: «root=/dev/hda3 ro »
|
initrd
|
utilice la imagen initrd/initramfs
ubicada en «/initrd.img »
|
Nota | |
---|---|
El valor del número de la partición que utiliza el antiguo programa GRUB es uno menos que utilizado por el núcleo de Linux y las herramientas de uso común. El programa GRUB 2 soluciona este problema. |
Sugerencia | |
---|---|
UUID (consulte Sección 9.5.3, “Acceso al particionado utilizando UUID”) puede ser utilizado para
identificar un dispositivo especial de bloque en vez del nombre del archivo
como « |
Sugerencia | |
---|---|
Si se utiliza GRUB, el parámetro del núcleo de
inicio esta asignado en |
Sugerencia | |
---|---|
Puede iniciar un cargador de arranque desde otro cargados de arranque mediante la técnica llamada chain loading. |
Consulte «info grub
» y
grub-install(8).
El sistema mini-Debian es la fase 3 del proceso de arranque que comienza con el cargador de arranque. Este ejecuta el núcleo del sistema con el sistema de archivos raíz en memoria. Esta es una fase preparatoria opcional del proceso de arranque.
Nota | |
---|---|
En este documento el término «el sistema mini-Debian« es como el autor describe la tercera fase del proceso de arranque. El sistema es conocido como initrd o sistema initramfs. El instalador de Debian usa un sistema parecido en memoria. |
El primer programa que se ejecuta en el sistema de archivo raíz en memoria
es /init
». Es un programa que inica el núcleo en el
espacio de usuario y entrega el control para la próxima fase. Este sistema
mini-Debian ofrece flexibilidad al módulo al proceso de arranque, como
agregar módulos del núcleo antes de que el proceso principal de arranque o
el montaje de un sistema de archivos raíz cifrado.
El programa /init
es una secuencia de códigos si initramfs
ha sido creado por initramfs-tools
.
Puede interrumpir esta parte del proceso de arranque para obtener un
intérprete de órdenes de supuerusuario dandole al arranque del núcleo el
parámetro «break=init
» etc. Consulte el archivo de
órdenes /init
» para conocer más formas de
interacción. Este entorno del intérprete de órdenes es suficientemente
complejo para realizar una reconocimiento avanzado del «hardware« de su
equipo.
Las órdenes disponibles en este sistema mini-Debian son básicas y las funciones principales las aporta la herramienta GNU llamada busybox(1).
El programa /init
es un programa binario
systemd
si initramfs fue crado por
dracut
.
Commands available in this mini-Debian system are stripped down systemd(1) environment.
Atención | |
---|---|
Necesita utilizar el parámetro « |
El sistema normal Debian es la cuarta fase del proceso de arranque el cual comienza con el sistema mini-Debian. El núcleo del sistema para el sistema mini-Debian continua ejecutandose en este entorno. El sistema de archivos raíz cambio del que existe en memoria a uno real sobre el sistema de archivos en disco duro.
El programa init es ejecutado en primer lugar
con el PID=1 preparando el proceso de arranque principal para el cominezo
de muchos programas. La ruta de archivo por defecto para el programa init es
«/sbin/init
» pero puede ser modificado por un párametro
de arranque del núcleo como «init=/path/to/init_program
».
El programa de inicio por defecto ha sido cambiado:
Antes de la versión squeeze
de Debian utiliza el sencillo
estilo SysV init.
La versión de Debian wheezy
mejora el estilo SysV de init
ordenando la secuencia de arranque con la cabecera LSB e inicia los archivos
de órdenes de inicio en paralelo.
Debian jessie
cambia su «init« por defecto a systemd para una inicialización en paralelo basada
en eventos.
Sugerencia | |
---|---|
Puede comprobar cual es el sistema init real que usa su equipo mediante la
orden « |
Sugerencia | |
---|---|
" |
Tabla 3.3. Relación de sistemas de arranque en el sistema Debian
paquete | popularidad | tamaño | descripción |
---|---|---|---|
systemd
|
V:750, I:858 | 13484 |
Demonio
init(8)
basado en eventos con concurrencia (opción a sysvinit )
|
systemd-sysv
|
V:733, I:852 | 122 |
redirecciona salida estándar y el error estándar de orden
al archivo foo
|
systemd-cron
|
V:0, I:1 | 139 | systemd units to provide cron daemon
and anacron functionality
|
init-system-helpers
|
V:745, I:876 | 133 |
helper tools for switching between sysvinit and
systemd
|
initscripts
|
V:188, I:509 | 213 | archivos de órdenes de inicio y parada del sistema |
sysvinit-core
|
V:10, I:13 | 263 | Programa estilo System-V init(8) |
sysv-rc
|
V:334, I:520 | 121 | Mecanismo de cambio del nivel de ejecución estilo System-V |
sysvinit-utils
|
V:729, I:999 | 131 | Programas estilo System-V (startpar(8), bootlogd(8), …) |
lsb-base
|
V:886, I:999 | 49 | Funcionalidad de secuencia de órdenes «Linux Standard Base« init 3.2 |
insserv
|
V:403, I:510 | 148 | herramientas para organizar la secuencia de arranque usando las dependencias del archivo de órdenes init.d LSB |
uswsusp
|
V:5, I:10 | 714 | herramientas para la suspensión de software en el espacio de usuario por Linux |
kexec-tools
|
V:1, I:7 | 271 | Reincio (reincio caliente) kexec(8) de la herramienta kexec |
systemd-bootchart
|
V:0, I:0 | 123 | analizador de desempeño del proceso de arranque |
bootchart2
|
V:0, I:1 | 94 | analizador de desempeño del proceso de arranque |
pybootchartgui
|
V:0, I:1 | 177 | analizados del desempeño del proceso de arranque (visualización) |
mingetty
|
V:0, I:3 | 35 | únicamente para consola getty(8) |
mgetty
|
V:0, I:1 | 319 | sustituto de «modem« inteligente getty(8) |
Sugerencia | |
---|---|
Consulte la wiki de Debian : AcelerandoElProcesodeArranque para los consejos actualizados para mejorar la velocidad del proceso de arranque. |
This section describes how system is started by the
systemd(1)
program with PID=1
(i.e., init process).
The systemd
init process spawns processes in parallel
based on the unit configuration files (see
systemd.unit(5))
which are written in declarative style instead of SysV-like procedural
style. These are loaded from a set of paths (see
systemd-system.conf(5))
as follows:
"/lib/systemd/system
": OS default configuration files
"/etc/systemd/system
": archivos de configuración del
administrador del sistema que anulan los archivos de configuración
predeterminados del sistema operativo
"/run/systemd/system
": archivos de configuración
generados durante la ejecución que anulan los archivos de configuración
instalados
Their inter-dependencies are specified by the directives
"Wants=
", "Requires=
",
"Before=
", "After=
", … (see "MAPPING
OF UNIT PROPERTIES TO THEIR INVERSES" in
systemd.unit(5)).
The resource controls are also defined (see
systemd.resource-control(5)).
El sufijo del archivo de configuración de la unidad codifica sus tipos como:
*.service describes the process
controlled and supervised by systemd
. See
systemd.service(5).
*.device describes the device exposed in the sysfs(5) as udev(7) device tree. See systemd.device(5).
*.mount describes the file system mount
point controlled and supervised by systemd
. See
systemd.mount(5).
*.automount describes the file system
auto mount point controlled and supervised by
systemd
. See
systemd.automount(5).
*.swap describes the swap device or file
controlled and supervised by systemd
. See
systemd.swap(5).
*.path describes the path monitored by
systemd
for path-based activation. See
systemd.path(5).
*.socket describes the socket controlled
and supervised by systemd
for socket-based
activation. See
systemd.socket(5).
*.timer describes the timer controlled
and supervised by systemd
for timer-based activation. See
systemd.timer(5).
*.slice manages resources with the cgroups(7). See systemd.slice(5).
*.scope is created programmatically using
the bus interfaces of systemd
to manages a set of system
processes. See
systemd.scope(5).
*.target groups other unit configuration files to create the synchronization point during start-up. See systemd.target(5).
Tras el arranque del sistema (esencialmente init), el proceso
systemd
intenta iniciar
/lib/systemd/system/default.target
(normalmente enlazado
simbólicamente a "graphical.target
". Primero, algunas
unidades objetivo especiales (vea
systemd.specia(7)
como "local-fs.target
", "swap.target
"
y "cryptsetup.target
" son llamadas a montar el sistema de
archivos. Luego, otras unidades objetivo son llamadas por las dependencias
de la unidad objetivo. Para más detalles, lea
bootup(7).
systemd
ofrece características de compatibilidad con
versiones anteriores. Los archivos de órdenes de inicio de estilo SysV en
"/etc/init.d/rc[0123456S].d/[KS]< <name>
" son
aún analizados y
telinit(8)
se traducen en solicitudes de activación de systemd.
Atención | |
---|---|
Emulated runlevel 2 to 4 are all symlinked to the same
" |
El núcleo mantiene el nombre del equipo
del sistema. El archivo de órdenes de init en el nivel de ejecución S, el
cual es un enlace simbólico a «/etc/init.d/hostname.sh
»
asigna el nombre del sistema en tiempo de arranque (usando la orden
hostname
) al nombre almacenado en
«/etc/hostname
». Este archivo debería contener únicamente el nombre del sistema, no un nombre de
dominio totalmente cualificado (FQDN).
Para obtener el nombre del equipo actual ejecute hostname(1) sin ningún parámetro.
The mount options of normal disk and network filesystems are set in
"/etc/fstab
". See
fstab(5)
and Sección 9.5.7, “Optimización de los sistemas de archivos a través de las opciones de montaje”.
The configuration of the encrypted filesystem is set in
"/etc/crypttab
". See
crypttab(5)
The configuration of software RAID with
mdadm(8)
is set in "/etc/mdadm/mdadm.conf
". See
mdadm.conf(5).
Aviso | |
---|---|
Trás montar todos los sistemas de archivos , los archivos temporales en
« |
Network interfaces are typically initialized in
"networking.service
" for the lo
interface and "NetworkManager.service
" for other
interfaces on modern Debian desktop system under systemd
.
See Capítulo 5, Configuración de red for how to configure them.
The kernel error message displayed to the console can be configured by setting its threshold level.
# dmesg -n3
Tabla 3.4. LIsta de niveles de error del núcleo
valor del nivel de error | nombre del nivel de error | significado |
---|---|---|
0 | KERN_EMERG | sistema no usable |
1 | KERN_ALERT | se deben tomar medidas de forma inmediata |
2 | KERN_CRIT | estado crítico |
3 | KERN_ERR | estado de error |
4 | KERN_WARNING | estado de aviso |
5 | KERN_NOTICE | estado normal pero significativo |
6 | KERN_INFO | información |
7 | KERN_DEBUG | mensajes de depuración |
Under systemd
, both kernel and system messages are logged
by the journal service systemd-journald.service
(a.k.a
journald
) either into a persistent binary data below
"/var/log/journal
" or into a volatile binary data below
"/run/log/journal/
". These binary log data are accessed
by the
journalctl(1)
command.
La orden de búsqueda especializada
grep-dctrl(1)
permite buscar en las copias locales de «status
» y la
metainformación «disponible
».
El sistema de mensajes puede ser personalizado tanto para el archivo de
registro y los mensajes por pantalla mediante
«/etc/default/rsyslog
» y
«/etc/rsyslog.conf
». Consulte
rsyslogd(8)
y
rsyslog.conf(5).
Consulte también Sección 9.2.2, “Analizador de registros”.
The systemd
offers not only init system but also generic
system management functionalities such as journal logging, login management,
time management, network management. etc..
The systemd(1) is managed by several commands:
the
systemctl(1)
command controls the systemd
system and service manager
(CLI),
the
systemsdm(1)
command controls the systemd
system and service manager
(GUI),
the
journalctl(1)
command queries the systemd
journal,
the
loginctl(1)
command controls the systemd
login manager, and
the systemd-analyze(1) analyzes system boot-up performance.
Here are a list of typical systemd
management command
snippets. For the exact meanings, please read the pertinent manpages.
Tabla 3.5. Registro de acciones de la orden aptitude
Operation | Type | nombre de la orden, |
---|---|---|
GUI for service manager | GUI |
"systemadm " (systemd-ui package)
|
List all target unit configuration | Unit |
"systemctl list-units --type=target "
|
List all service unit configuration | Unit |
"systemctl list-units --type=service "
|
List all unit configuration types | Unit |
"systemctl list-units --type=help "
|
List all socket units in memory | Unit |
"systemctl list-sockets "
|
List all timer units in memory | Unit |
"systemctl list-timers "
|
Start "$unit "
|
Unit |
"systemctl start $unit "
|
Stop "$unit "
|
Unit |
"systemctl stop $unit "
|
Reload service-specific configuration | Unit |
"systemctl reload $unit "
|
Stop and start all "$unit "
|
Unit |
"systemctl restart $unit "
|
Start "$unit " and stop all others
|
Unit |
"systemctl isolate $unit "
|
Switch to "graphical " (GUI system)
|
Unit |
"systemctl isolate graphical "
|
Switch to "multi-user " (CLI system)
|
Unit |
"systemctl isolate multi-user "
|
Switch to "rescue " (single user CLI system)
|
Unit |
"systemctl isolate rescue "
|
Send kill signal to "$unit "
|
Unit |
"systemctl kill $unit "
|
Check if "$unit " service is active
|
Unit |
"systemctl is-active $unit "
|
Check if "$unit " service is failed
|
Unit |
"systemctl is-failed $unit "
|
Check status of "$unit|$PID|device "
|
Unit |
"systemctl status $unit|$PID|$device "
|
Show properties of "$unit|$job "
|
Unit |
"systemctl show $unit|$job "
|
Reset failed "$unit "
|
Unit |
"systemctl reset-failed $unit"
|
List dependency of all unit services | Unit |
"systemctl list-dependencies --all "
|
List unit files installed on the system | Unit file |
"systemctl list-unit-files "
|
Enable "$unit " (add symlink)
|
Unit file |
"systemctl enable $unit "
|
Disable "$unit " (remove symlink)
|
Unit file |
"systemctl disable $unit "
|
Unmask "$unit " (remove symlink to
"/dev/null ")
|
Unit file |
"systemctl unmask $unit "
|
Mask "$unit " (add symlink to
"/dev/null ")
|
Unit file |
"systemctl mask $unit "
|
Get default-target setting | Unit file |
"systemctl get-default "
|
Set default-target to "graphical " (GUI system)
|
Unit file |
"systemctl set-default graphical "
|
Set default-target to "multi-user " (CLI system)
|
Unit file |
"systemctl set-default multi-user "
|
Show job environment | Environment |
"systemctl show-environment "
|
Set job environment "variable " to
"value "
|
Environment |
"systemctl set-environment variable=value "
|
Unset job environment "variable "
|
Environment |
"systemctl unset-environment variable "
|
Reload all unit files and daemons | Lifecycle |
"systemctl daemon-reload "
|
Shut down the system | System |
"systemctl poweroff "
|
Shut down and reboot the system | System |
"systemctl reboot "
|
Suspend the system | System |
"systemctl suspend "
|
Hibernate the system | System |
"systemctl hibernate "
|
View job log of "$unit "
|
Journal |
"journalctl -u $unit "
|
View job log of "$unit " ("tail -f "
style)
|
Journal |
"journalctl -u $unit -f "
|
Show time spent for each initialization steps | Analyze |
"systemd-analyze time "
|
List of all units by the time to initialize | Analyze |
"systemd-analyze blame "
|
Load and detect errors in "$unit " file
|
Analyze |
"systemd-analyze verify $unit "
|
Track boot process by the cgroups(7) | Cgroup |
"systemd-cgls "
|
Track boot process by the cgroups(7) | Cgroup |
"ps xawf -eo pid,user,cgroup,args "
|
Track boot process by the cgroups(7) | Cgroup |
Read sysfs under
"/sys/fs/cgroup/systemd/ "
|
Here, "$unit
" in the above examples may be a single unit
name (suffix such as .service
and
.target
are optional) or, in many cases, multiple unit
specifications (shell-style globs "*
",
"?
", "[]
" using
fnmatch(3)
which will be matched against the primary names of all units currently in
memory).
System state changing commands in the above examples are typically preceded
by the "sudo
" to attain the required administrative
privilege.
The output of the "systemctl status $unit|$PID|$device
"
uses color of the dot ("●") to summarize the unit state at a glance.
White "●" indicates an "inactive" or "deactivating" state.
Red "●" indicates a "failed" or "error" state.
Green "●" indicates an "active", "reloading" or "activating" state.
With default installation, many network services (see Capítulo 6, Aplicaciones de red) are started as daemon processes after
network.target
at boot time by
systemd
. The "sshd
" is no exception.
Let's change this to on-demand start of "sshd
" as a
customization example.
First, disable system installed service unit.
$ sudo systemctl stop sshd.service $ sudo systemctl mask sshd.service
The on-demand socket activation system of the classic Unix services was
through the indetd
superserver. Under
systemd
, the equivalent can be enabled by adding
*.socket and *.service unit configuration files.
sshd.socket
for specifying a socket to listen on
[Unit] Description=SSH Socket for Per-Connection Servers [Socket] ListenStream=22 Accept=yes [Install] WantedBy=sockets.target
sshd@.service
as the matching service file of
sshd.socket
[Unit] Description=SSH Per-Connection Server [Service] ExecStart=-/usr/sbin/sshd -i StandardInput=socket
Then reload.
$ sudo systemctl daemon-reload
Desde el núcleo de Linux 2.6 en adelante, el sistema udev aporta mecanismos automáticos de descubrimiento e inicialización de «hardware« (consulte udev(7)). Después del descubrimiento de cada dispositivo por parte del núcleo, el sistema udev comienza un proceso de usuario el cual usa la información del sistema de archivos sysfs (consulte Sección 1.2.12, “procfs y sysfs”), carga los módulos necesarios para el núcleo mediante el programa modprobe(8) (consulte Sección 3.3.1, “La inicialización del módulo del núcleo”) y crea los nodos de dispositivo correspondientes.
Sugerencia | |
---|---|
Si por cualquier motivo
« |
El nombre de los nodos del dispositivo puede ser configurado por los
archivos de relgas de udev en «/etc/udev/rules.d/
». Las
reglas predeterminadas actuales tienden a crear nombres generados
dinámicamente, dando como resultado nombres de dispositivo no estático
excepto para cd y red. Para añadir sus reglas personalizadas parecidas a lo
que hace con los dispositivios de cd y red, se pueden generar nombres de
dispositivo estáticos para, por ejemplo, llaveros de memoria,
también. Consulte «Escribiendo reglas
udev« o
«/usr/share/doc/udev/writing_udev_rules/index.html
».
Ya que udev es un sistema en evolución, dejaré los detalles para otra documentación y se describirá de forma mínima aquí.
Sugerencia | |
---|---|
Para las reglas de montaje de « |
El programa modprobe(8) nos permite configurar el núcleo de Linux en ejecución desde el proceso de usuario añadiendo o eliminando módulos al núcleo. El sistema udev (see Sección 3.3, “El sistema udev”) automatiza su llamada para ayudar a la inicialización de módulos en el núcleo.
No existen módulos que no correspondan a hardware ni módulos controladores
de hardware especiales como los que necesitan ser precargados al estar
enumerados en el archivo «/etc/modules
»
(consultemodules(5)).
Los módulos TUN/TAP aportan el dispositivo virtual de red punto a punto (TUN) y el dispositivo virtual de red ethernet (TAP),
Los módulos netfilter aportan capacidades de cortafuego (iptables(8), Sección 5.10, “Infraestructura Netfilter”) y
los móduloes del controlador watchdog timer.
Los archivos de configuración del programa
modprobe(8)
están ubicados en el árbol bajo el directorio
«/etc/modprobes.d/
» como se detalla en
modprobe.conf(5).
(Si quiere evitar que algunos módulos del núcleo se cargen de forma
automática, incluyalos en la lista negra que es el archivo
«/etc/modprobes.d/blacklist
».)
El archivo «/lib/modules/<version>/modules.dep
»
creado por el programa
depmod(8)
describe las dependencias de los módulos usados por el programa
modprobe(8).
Nota | |
---|---|
Si tiene problemas en la carga de módulos cuando se inicia su carga de
módulos o con
modprobe(8),
« |
El programa modinfo(8) muestra información acerca de los módulos del núcleo de Linux.
El programa
lsmod(8)
da formato al contenido de «/proc/modules
», mostrando
los módulos del núcleo que están cargados en este momento.
Sugerencia | |
---|---|
Puede determinar cual es el hardware de su sistema. Consulte Sección 9.4.3, “Identificación del hardware”. |
Sugerencia | |
---|---|
Puede configurar su hardware en tiempo de arranque y activar las funcionalidades del hardware conocidas. Consulte Sección 9.4.4, “Configuración del hardware”. |
Sugerencia | |
---|---|
Seguramente pueda añadir soporte a sus dispositivos especiales recompilando el núcleo. Consulte Sección 9.9, “El núcleo”. |