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.
Here is a rough overview of the key points of the Debian system initialization. Since the Debian system is a moving target, you should refer to the latest documentation.
Debian Linux Kernel Handbook is the primary source of information on the Debian kernel.
bootup
(7) describe el proceso de arranque del sistema
basado en systemd
. (Debian reciente)
boot
(7) describeel proceso de arranque del sistema basado
en 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.
The Unified Extensible Firmware Interface (UEFI) defines a boot manager as part of the UEFI specification. When a computer is powered on, the boot manager is the 1st stage of the boot process which checks the boot configuration and based on its settings, then executes the specified OS boot loader or operating system kernel (usually boot loader). The boot configuration is defined by variables stored in NVRAM, including variables that indicate the file system paths to OS loaders or OS kernels. An EFI system partition (ESP) is a data storage device partition that is used in computers adhering to the UEFI specification. Accessed by the UEFI firmware when a computer is powered up, it stores UEFI applications and the files these applications need to run, including operating system boot loaders. (On the legacy PC system, BIOS stored in the MBR may be used instead.)
The boot loader is the 2nd stage of the boot process which is started by the UEFI. It loads the system kernel image and the initrd image to the memory and hands control over to them. This initrd image is the root filesystem image and its support depends on the bootloader used.
The Debian system normally uses the Linux kernel as the default system kernel. The initrd image for the current 5.x Linux kernel is technically the initramfs (initial RAM filesystem) image.
There are many boot loaders and configuration options available.
Tabla 3.1. Relación de cargadores de arranque
paquete | popularidad | tamaño | initrd | cargador de arranque | descripción |
---|---|---|---|---|---|
grub-efi-amd64 | I:228 | 158 | Soporte | GRUB UEFI | This is smart enough to understand disk partitions and filesystems such as vfat, ext4, …. (UEFI) |
grub-pc | V:25, I:745 | 533 | Soporte | GRUB 2 | This is smart enough to understand disk partitions and filesystems such as vfat, ext4, …. (BIOS) |
grub-rescue-pc | V:0, I:1 | 6380 | Soporte | GRUB 2 | Imagen de rescate de inicio GRUB 2 (CD and disquete) (versión PC/BIOS) |
lilo | V:0, I:1 | 697 | Soporte | Lilo | Esto depende de las ubicaciónes de los sectores de datos en el disco duro (Old) |
syslinux | V:3, I:44 | 344 | Soporte | Isolinux | Entiende el sistema de archivos ISO9660. Es usado por arranque de CD. |
syslinux | V:3, I:44 | 344 | Soporte | Syslinux | Entiende el sistema de archivos MSDOS (FAT). Es usado para el arranque de diquete. |
loadlin | V:0, I:0 | 90 | Soporte | Loadlin | Nuevo sistema para el arranque del sistema FreeDOS/MSDOS. |
mbr | V:0, I:6 | 50 | 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
|
For GRUB 2, the menu configuration file is located at
"/boot/grub/grub.cfg
" and its key part of menu entry
looks like:
menuentry 'Debian GNU/Linux' ... { load_video insmod gzio insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1 echo 'Loading Linux 5.10.0-6-amd64 ...' linux /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-5.10.0-6-amd64 }
For this part of /boot/grub/grub.cfg
, this menu entry
means the following.
Tabla 3.2. The meaning of the menu entry of the above part of
/boot/grub/grub.cfg
setting | valor |
---|---|
GRUB2 modules loaded | gzio , part_gpt ,
ext2 |
root file system partition used | partition identified by
UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 |
kernel image path in the root file system | /boot/vmlinuz-5.10.0-6-amd64 |
kernel boot parameter used | "root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet " |
initrd image path in the root file system | /boot/initrd.img-5.10.0-6-amd64 |
![]() |
Sugerencia |
---|---|
You can customize GRUB splash image by setting
|
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
.
Los comandos disponibles en este sistema mini-Debian son básicamente el
ambiente systemd
(1).
![]() |
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
».
"/sbin/init
" is symlinked to
"/lib/systemd/systemd
" after Debian 8 Jessie (released in
2015).
![]() |
Sugerencia |
---|---|
Puede comprobar cual es el sistema init real que usa su equipo mediante la
orden « |
Tabla 3.3. Relación de sistemas de arranque en el sistema Debian
paquete | popularidad | tamaño | descripción |
---|---|---|---|
systemd
|
V:835, I:936 | 15615 | Demonio init (8) basado en eventos con concurrencia
(opción a sysvinit ) |
systemd-sysv
|
V:813, I:934 | 143 | redirecciona salida estándar y el error estándar de orden
al archivo foo |
init-system-helpers
|
V:685, I:948 | 131 | herramientas de ayuda para cambiar entre sysvinit y
systemd |
initscripts
|
V:69, I:253 | 171 | archivos de órdenes de inicio y parada del sistema |
sysvinit-core
|
V:7, I:8 | 279 | Programa estilo System-V init (8) |
sysv-rc
|
V:136, I:266 | 82 | Mecanismo de cambio del nivel de ejecución estilo System-V |
sysvinit-utils
|
V:413, I:999 | 81 | Programas estilo System-V (startpar (8),
bootlogd (8), …) |
lsb-base
|
V:890, I:999 | 49 | Funcionalidad de secuencia de órdenes «Linux Standard Base« init 3.2 |
insserv
|
V:162, I:262 | 154 | herramientas para organizar la secuencia de arranque usando las dependencias del archivo de órdenes init.d LSB |
uswsusp
|
V:1, I:6 | 714 | herramientas para la suspensión de software en el espacio de usuario por Linux |
kexec-tools
|
V:1, I:8 | 289 | Reincio (reincio caliente) kexec (8) de la herramienta
kexec |
systemd-bootchart
|
V:0, I:1 | 128 | analizador de desempeño del proceso de arranque |
bootchart2
|
V:0, I:0 | NOT_FOUND | analizador de desempeño del proceso de arranque |
pybootchartgui
|
V:0, I:0 | NOT_FOUND | analizados del desempeño del proceso de arranque (visualización) |
mingetty
|
V:0, I:3 | 38 | únicamente para consola getty (8) |
mgetty
|
V:0, I:0 | 315 | 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. |
Esta sección describe como el programa systemd
(1) inicia
el sistema con PID=1
(i.e., proceso de inicio).
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.
The spawned processes are placed in individual Linux control groups named after the unit which they belong to in the private systemd hierarchy (see cgroups and Sección 4.7.4, “Linux security features”).
The unit configuration files are loaded from a set of paths (see
systemd-system.conf
(5)) as follows:
«/lib/systemd/system
»: archivos de configuración por
defecto del sistema operativo
"/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
Las interdependencias se describen mediante directivas
«Wants=
», «Requires=
»,
«Before=
», «After=
», … (consulte
"MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" en
systemd.unit
(5)). El control de recursos esta también
definido (consulte systemd.resource-control
(5)).
El sufijo del archivo de configuración de la unidad codifica sus tipos como:
*.service describe el proceso que está
controlado y supervisado por systemd
. Consulte
systemd.service
(5).
*.device describe el dispositivo
utilizado por sysfs
(5) como el árbol de dispositivos
udev
(7). Consulte systemd.device
(5).
*.mount describe el punto de montaje del
sistema de archivos que está controlado y supervisado por
systemd
. Consulte systemd.mount
(5).
*.automount describe puntos de
automontaje de sistemas de archivos que están controlados y supervisados por
systemd
. Consulte
systemd.automount
(5).
*.swap describe dispositos o archivos de
intercambio controlado y supervisado por
systemd
. Consulte systemd.swap
(5).
*.path describe rutas supervisadas por
systemd
para la activación basada en la ruta. Consulte
systemd.path
(5).
*.socket describe conexiones controladas
y supervisadas por systemd
para la activación basada en
conexiones. Consulte systemd.socket
(5).
*.timer describe el temporizador
controlado y supervisado por systemd
para la activación
en función de temporizadores. Consulte systemd.timer
(5).
*.slice gestiona recursos mediante
cgroups
(7). Consulte systemd.slice
(5).
*.scope se crean de forma programada
utilizando los interfaces del bus de systemd
para
gestionar un conjunto de procesos del sistema. Consute
systemd.scope
(5).
Los grupos *.target y otros archivos de
configuración de units se usan para crear puntos de sincronización durante
el arranque. Consulte 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.special
(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 también analizados y
telinit
(8) se traducen a peticiones de activación de
systemd.
![]() |
Atención |
---|---|
Los niveles de inicio emulados del dos al cuatro son enlaces simbólicos al
mismo « |
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.
Las opciones de montaje de discos normales y de sistemas de archivos en red
se configuran en «/etc/fstab
». Consulte
fstab
(5) y Sección 9.6.7, “Optimización de los sistemas de archivos a través de las opciones de montaje”.
Los sistemas de archivos cifrados se configuran en
«/etc/crypttab
». Consulte crypttab
(5)
La configuración de RAID mediante software con mdadm
(8)
está en «/etc/mdadm/mdadm.conf
». Consulte
mdadm.conf
(5).
![]() |
Aviso |
---|---|
Trás montar todos los sistemas de archivos , los archivos temporales en
« |
Comunmente el interfaz lo
se inicializa mediante
«networking.service
» y el resto de interfaces de un
sistema de escritorio moderno Debian que use systemd
mediante «NetworkManager.service
».
Para configurarlos consulte Capítulo 5, Configuración de red.
El mensaje de error que se muestra en la consola se determina mediante la configuración de su nivel de umbral.
# 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. For example, you can
display log from the last boot as:
$ journalctl -b
Tabla 3.5. List of typical journalctl
command snippets
Operation | nombre de la orden, |
---|---|
View log for system services and kernel from the last boot | "journalctl -b --system " |
View log for services of the current user from the last boot | "journalctl -b --user " |
View job log of "$unit " from the last boot |
"journalctl -b -u $unit " |
View job log of "$unit " ("tail -f "
style) from the last boot |
"journalctl -b -u $unit -f " |
Under systemd
, the system logging utility
rsyslogd
(8) may be uninstalled. If it is installed, it
changes its behavior to read the volatile binary log data (instead of
pre-systemd default "/dev/log
") and to create traditional
permanent ASCII system log data. This can be customized by
"/etc/default/rsyslog
" and
"/etc/rsyslog.conf
" for both the log file and on-screen
display. See rsyslogd
(8) and
rsyslog.conf
(5). See also Sección 9.3.2, “Analizador de registros”.
The systemd
offers not only init system but also generic
system management operations with the systemctl
(1)
command.
Tabla 3.6. List of typical systemctl
command snippets
Operation | nombre de la orden, |
---|---|
List all target unit configuration | "systemctl list-units --type=target " |
List all service unit configuration | "systemctl list-units --type=service " |
List all unit configuration types | "systemctl list-units --type=help " |
List all socket units in memory | "systemctl list-sockets " |
List all timer units in memory | "systemctl list-timers " |
Start "$unit " |
"systemctl start $unit " |
Stop "$unit " |
"systemctl stop $unit " |
Reload service-specific configuration | "systemctl reload $unit " |
Stop and start all "$unit " |
"systemctl restart $unit " |
Start "$unit " and stop all others |
"systemctl isolate $unit " |
Switch to "graphical " (GUI system) |
"systemctl isolate graphical " |
Switch to "multi-user " (CLI system) |
"systemctl isolate multi-user " |
Switch to "rescue " (single user CLI system) |
"systemctl isolate rescue " |
Send kill signal to "$unit " |
"systemctl kill $unit " |
Check if "$unit " service is active |
"systemctl is-active $unit " |
Check if "$unit " service is failed |
"systemctl is-failed $unit " |
Check status of "$unit|$PID|device " |
"systemctl status $unit|$PID|$device " |
Show properties of "$unit|$job " |
"systemctl show $unit|$job " |
Reset failed "$unit " |
"systemctl reset-failed $unit" |
List dependency of all unit services | "systemctl list-dependencies --all " |
List unit files installed on the system | "systemctl list-unit-files " |
Enable "$unit " (add symlink) |
"systemctl enable $unit " |
Disable "$unit " (remove symlink) |
"systemctl disable $unit " |
Unmask "$unit " (remove symlink to
"/dev/null ") |
"systemctl unmask $unit " |
Mask "$unit " (add symlink to
"/dev/null ") |
"systemctl mask $unit " |
Get default-target setting | "systemctl get-default " |
Set default-target to "graphical " (GUI system) |
"systemctl set-default graphical " |
Set default-target to "multi-user " (CLI system) |
"systemctl set-default multi-user " |
Show job environment | "systemctl show-environment " |
Set job environment "variable " to
"value " |
"systemctl set-environment variable=value " |
Unset job environment "variable " |
"systemctl unset-environment variable " |
Reload all unit files and daemons | "systemctl daemon-reload " |
Shut down the system | "systemctl poweroff " |
Shut down and reboot the system | "systemctl reboot " |
Suspend the system | "systemctl suspend " |
Hibernate the system | "systemctl hibernate " |
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.
Here are a list of other monitoring command snippets under
systemd
. Please read the pertinent manpages including
cgroups
(7).
Tabla 3.7. List of other monitoring command snippets under systemd
Operation | nombre de la orden, |
---|---|
Show time spent for each initialization steps | "systemd-analyze time " |
List of all units by the time to initialize | "systemd-analyze blame " |
Load and detect errors in "$unit " file |
"systemd-analyze verify $unit " |
Show terse runtime status information of the user of the caller's session | "loginctl user-status " |
Show terse runtime status information of the caller's session | "loginctl session-status " |
Track boot process by the cgroups | "systemd-cgls " |
Track boot process by the cgroups | "ps xawf -eo pid,user,cgroup,args " |
Track boot process by the cgroups | Read sysfs under
"/sys/fs/cgroup/systemd/ " |
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 inetd
(or xinetd
)
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
The udev system provides mechanism for the
automatic hardware discovery and initialization (see
udev
(7)) since Linux kernel 2.6. Upon discovery of each
device by the kernel, the udev system starts a user process which uses
information from the sysfs filesystem (see
Sección 1.2.12, “procfs y sysfs”), loads required kernel modules
supporting it using the modprobe
(8) program (see Sección 3.8.1, “La inicialización del módulo del núcleo”), and creates corresponding
device nodes.
![]() |
Sugerencia |
---|---|
Si por cualquier motivo
« Para las reglas de montaje de « |
Ya que udev es un sistema en evolución, dejaré los detalles para otra documentación y se describirá de forma mínima aquí.
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.8, “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.6, “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 |
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.5.3, “Identificación del hardware”. Puede configurar su hardware en tiempo de arranque y activar las funcionalidades del hardware conocidas. Consulte Sección 9.5.4, “Configuración del hardware”. Seguramente pueda añadir soporte a sus dispositivos especiales recompilando el núcleo. Consulte Sección 9.10, “El núcleo”. |