Capitolo 3. Inizializzazione del sistema

Indice

3.1. Panoramica del processo di avvio
3.1.1. Stadio 1: il BIOS
3.1.2. Stadio 2: il bootloader
3.1.3. Stadio 3: il mini-sistema Debian
3.1.4. Stadio 4: il normale sistema Debian
3.2. Systemd init
3.2.1. Il nome host
3.2.2. Il filesystem
3.2.3. Inizializzazione delle interfacce di rete
3.2.4. I messaggi del kernel
3.2.5. I messaggi di sistema
3.2.6. System management under systemd
3.2.7. Customizing systemd
3.3. Il sistema udev
3.3.1. L'inizializzazione dei moduli del kernel

È bene che l'amministratore di sistema conosca almeno a grandi linee come viene avviato e configurato il sistema Debian. Anche se i dettagli precisi sono nei file sorgenti dei pacchetti installati e nella loro documentazione, essi sono un po' troppo per la maggior parte degli utenti.

Ho cercato di fornire una veloce panoramica dei punti chiave del sistema Debian e della loro configurazione, come punto di riferimento per l'utente, in base alle conoscenze attuali e passate mie e di altri. Dato che il sistema Debian è in costante evoluzione, la situazione potrebbe essere cambiata. Prima di fare qualsiasi modifica al sistema, si dovrebbe far riferimento alla documentazione più recente per ciascun pacchetto.

[Suggerimento] Suggerimento

bootup(7) describes the system bootup process based on systemd . (Recent Debian)

[Suggerimento] Suggerimento

boot(7) describes the system bootup process based on UNIX System V Release 4. (Older Debian)

Il sistema del computer passa attraverso varie fasi del processo di avvio, dall'accensione a quando offre all'utente il sistema operativo (SO) pienamente funzionante.

Per semplicità la spiegazione è limitata alla piattaforma PC tipica con l'installazione standard.

Il normale processo di avvio è come un razzo a quattro stadi. Ogni stadio del razzo passa il controllo del sistema allo stadio successivo.

Naturalmente questo può essere configurato in modo diverso. Per esempio, se è stato compilato un kernel personalizzato, si potrebbe saltare la fase con il mini-sistema Debian. Non dare per scontato che quanto detto valga per il proprio sistema fino a che non si abbia controllato direttamente.

[Nota] Nota

Per piattaforme PC non sorpassate, come il sistema SUN o Macintosh, il BIOS nella ROM e la partizione sul disco possono essere alquanto differenti (Sezione 9.5.2, «Configurazione del partizionamento dei dischi»). In questi casi, cercare la documentazione piattaforma specifica altrove.

Il BIOS è il primo stadio del processo di avvio che viene avviato dall'accensione. Il BIOS, che risiede nella ROM (read only memory, memoria in sola lettura) è eseguito da un particolare indirizzo di memoria al quale è inizializzato, dall'accensione, il contatore di programma della CPU.

Il BIOS effettua l'inizializzazione base dell'hardware (POST (power on self test, auto-test di accensione) e passa il controllo del sistema allo stadio successivo fornito dall'utente. Il BIOS è di solito fornito con l'hardware.

La schermata di avvio del BIOS indica solitamente quale tasto o tasti premere per entrare nella schermata di impostazioni del BIOS, per configurarne il comportamento. Tasti comunemente usati sono F1, F2, F10, Esc, Ins e Canc. Se la schermata di avvio del BIOS è nascosta da una bella schermata grafica, si può premere dei tasti, come Esc, per disabilitarla. Quali tasti vadano premuti dipende fortemente dall'hardware.

Dalla schermata di impostazioni del BIOS si può scegliere la posizione hardware e la priorità del codice avviato dal BIOS. Tipicamente vengono caricati in memoria i primi pochi settori del primo dispositivo selezionato trovato (disco fisso, dischetto floppy, CD-ROM, ...) e viene eseguito questo codice iniziale che può essere una qualsiasi tra le cose seguenti.

  • Il codice del bootloader

  • Il codice del kernel di SO di passaggio come FreeDOS

  • Il codice del kernel del sistema operativo finale, se può essere contenuto in questo piccolo spazio

Tipicamente il sistema viene avviato dalla partizione specificata del disco fisso primario. I primi 2 settori del disco fisso nei PC vecchi contengono ilmaster boot record (MBR). Le informazioni sulle partizioni del disco, inclusa la selezione per l'avvio sono memorizzate alla fine di questo MBR. Il primo codice boot loader eseguito dal BIOS occupa la parte restante di questo MBR.

Il bootloader è il secondo stadio del processo di avvio che è iniziato dal BIOS. Carica l'immagine kernel del sistema e l'immagine initrd in memoria e passa il controllo ad essi. L'immagine initrd è l'immagine del file system radice ed il suo supporto dipende dal bootloader usato.

Il sistema Debian normalmente usa il kernel Linux come kernel predefinito del sistema. L'immagine initrd dell'attuale kernel Linux 2.6/3.x è tecnicamente l'immagine initramfs (initial RAM filesystem). Questa è un archivio cpio compresso con gzip dei file nel filesystem root.

[Avvertimento] Avvertimento

Quanto sopra non è più vero con il nuovo initramfs multi-segmento. Vedere il bug n. 790100.

L'installazione predefinita del sistema Debian posiziona, per la piattaforma PC, il codice di primo stadio del bootloader GRUB nell'MBR. Sono disponibili molti bootloader e opzioni di configurazione.


[Avvertimento] Avvertimento

Do not play with boot loaders without having bootable rescue media (USB memory stick, CD or floppy) created from images in the grub-rescue-pc package. It makes you boot your system even without functioning bootloader on the hard disk.

Per GRUB Legacy, il file di configurazione del menu è "/boot/grub/menu.lst". Contiene, per esempio, delle voci come quella seguente.

title           Debian GNU/Linux
root            (hd0,2)
kernel          /vmlinuz root=/dev/hda3 ro
initrd          /initrd.img

Per GRUB 2, il file di configurazione del menu è "/boot/grub/grub.cfg". Viene generato automaticamente da "/usr/sbin/update-grub" usando modelli da "/etc/grub.d/*" e impostazioni da "/etc/default/grub". Contiene, per esempio, delle voci come quella seguente.

menuentry "Debian GNU/Linux" {
        set root=(hd0,3)
        linux /vmlinuz root=/dev/hda3
        initrd /initrd.img
}

Negli esempi precedenti i parametri di GRUB hanno i seguenti significati.


[Nota] Nota

Il valore per il numero di partizione usato dal programma GRUB Legacy è minore di uno rispetto a quello normale usato dal kernel Linux e dagli strumenti di utilità. il programma GRUB 2 ha risolto questo problema.

[Suggerimento] Suggerimento

Per identificare un particolare dispositivo a blocchi si può usare il suo UUID (vedere Sezione 9.5.3, «Accedere alle partizioni usando UUID») invece del suo nome file come "/dev/hda3", ad esempio "root=UUID=81b289d5-4341-4003-9602-e254a17ac232 ro".

[Suggerimento] Suggerimento

Se viene usato GRUB, il parametro di avvio del kernel viene impostato in /boot/grub/grub.cfg. Nei sistemi Debian non si dovrebbe modificare direttamente il file /boot/grub/grub.cfg. Si dovrebbe modificare il valore GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub ed eseguire update-grub(8) per aggiornare /boot/grub/grub.cfg.

[Suggerimento] Suggerimento

Si può avviare un bootloader da un altro bootloader usando una tecnica chiamata caricamento a catena.

Vedere "info grub" e grub-install(8).

Il mini-sistema Debian è il terzo stadio del processo di avvio che viene iniziato dal bootloader. Esegue il kernel del sistema con il suo filesystem root in memoria. Questo è uno stadio opzionale preparatorio del processo di avvio.

[Nota] Nota

L'espressione "sistema Debian mini" è stata coniata per descrivere il terzo stadio del processo di avvio in questo documento. Normalmente ci si riferisce a questo sistema come sistema initrd o initramfs. Un sistema simile in memoria è usato dall'installatore Debian.

The "/init" program is executed as the first program in this root filesystem on the memory. It is a program which initializes the kernel in user space and hands control over to the next stage. This mini-Debian system offers flexibility to the boot process such as adding kernel modules before the main boot process or mounting the root filesystem as an encrypted one.

  • The "/init" program is a shell script program if initramfs was created by initramfs-tools. You can interrupt this part of the boot process to gain root shell by providing "break=init" etc. to the kernel boot parameter. See the "/init" script for more break conditions. This shell environment is sophisticated enough to make a good inspection of your machine's hardware. Commands available in this mini-Debian system are stripped down ones and mainly provided by a GNU tool called busybox(1).

  • The "/init" program is a binary systemd program if initramfs was created by dracut. ** Commands available in this mini-Debian system are stripped down systemd(1) environment.

[Attenzione] Attenzione

È necessario usare l'opzione "-n" per il comando mount quando si è nel filesystem root in sola lettura.

Il sistema Debian normale è il quarto stadio del processo di avvio che viene iniziato dal mini-sistema Debian. Il kernel di sistema del mini-sistema Debian continua ad essere in esecuzione anche in questo ambiente. Il filesystem root viene cambiato da quello in memoria all'effettivo filesystem sul disco fisso.

Il programma init viene eseguito come primo programma con PID=1 per effettuare il processo principale di avvio di far partire molti programmi. Il percorso di file predefinito per il programma init è «/sbin/init», ma può essere cambiato con un parametro di avvio del kernel come in «init=/percorso/del/programma_init».

Il programma init predefinito ha subito cambiamenti:

  • Prima di squeeze Debian usava il semplice init in stile SysV.

  • Debian wheezy migliora l'init in stile SysV ordinando la sequenza con intestazioni LSB e avviando gli script di avvio in parallelo.

  • Debian jessie è passata come init predefinito a systemd per l'inizializzazione pilotata da eventi e in parallelo.

[Suggerimento] Suggerimento

Si può verificare quale è l'effettivo comando init nel proprio sistema con il comando «ps --pid 1 -f».

[Suggerimento] Suggerimento

"/sbin/init" is symlinked to "/lib/systemd/systemd" after Debian jessie.

Tabella 3.3. Elenco di utilità di avvio per il sistema Debian

pacchetto popcon dimensione descrizione
systemd V:703, I:805 11933 demone init(8) basato su eventi per concorrenza (alternativa a sysvinit)
systemd-sysv V:684, I:798 112 the manual pages and links needed for systemd to replace sysvinit
systemd-cron V:0, I:1 133 systemd units to provide cron daemon and anacron functionality
init-system-helpers V:704, I:826 129 helper tools for switching between sysvinit and systemd
initscripts V:284, I:667 205 script per inizializzare ed arrestare il sistema
sysvinit-core V:13, I:17 225 utilità init(8) in stile System-V
sysv-rc V:477, I:673 123 meccanismo di cambiamento del runlevel in stile System-V
sysvinit-utils V:791, I:999 110 utilità in stile System-V (startpar(8), bootlogd(8), …)
lsb-base V:877, I:999 49 funzionalità di script init Linux Standard Base 3.2
insserv V:539, I:660 140 strumento per organizzare la sequenza di avvio usando dipendenze LSB negli script init.d
uswsusp V:4, I:11 699 strumenti per usare la sospensione software in spazio utente fornita da Linux
kexec-tools V:1, I:8 270 strumento kexec per riavvii kexec(8) (riavvio a caldo)
systemd-bootchart V:0, I:0 122 analizzatore delle prestazioni del processo di avvio
bootchart2 V:0, I:1 94 analizzatore delle prestazioni del processo di avvio
pybootchartgui V:0, I:1 177 analizzatore delle prestazioni del processo di avvio (visualizzazione)
mingetty V:0, I:3 35 getty(8) solo console
mgetty V:0, I:1 301 rimpiazzio di getty(8) per smart modem

[Suggerimento] Suggerimento

Vedere la pagina del Wiki Debian sulla velocizzazione del processo di avvio per i più recenti suggerimenti su come velocizzare il processo di avvio.

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": system administrator configuration files which override the OS default configuration files

  • "/run/systemd/system": run-time generated configuration files which override the installed configuration files

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)).

The suffix of the unit configuration file encodes their types as:

  • *.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).

Upon system start up (i.e., init), the systemd process tries to start the "/lib/systemd/system/default.target (normally symlinked to "graphical.target"). First, some special target units (see systemd.special(7)) such as "local-fs.target", "swap.target" and "cryptsetup.target" are pulled in to mount the filesystems. Then, other target units are also pulled in by the target unit dependencies. For details, read bootup(7).

systemd offers backward compatibility features. SysV-style boot scripts in "/etc/init.d/rc[0123456S].d/[KS]<name>" are still parsed and telinit(8) is translated into systemd unit activation requests.

[Attenzione] Attenzione

Emulated runlevel 2 to 4 are all symlinked to the same "multi-user.target".

The mount options of normal disk and network filesystems are set in "/etc/fstab". See fstab(5) and Sezione 9.5.7, «Ottimizzare il file system con opzioni di mount».

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).

[Avvertimento] Avvertimento

Dopo aver montato tutti i filesystem, i file temporanei in "/tmp", "/var/lock" e "/var/run" vengono ripuliti ad ogni avvio.

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.

Tabella 3.5. List of typical systemd management command snippets

Operation Type Command snippets
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"
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 Capitolo 6, Applicazioni per la rete) 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

Per i kernel Linux 2.6 e successivi, il sistema udev fornisce un meccanismo di rilevazione e inizializzazione automatiche dell'hardware (vedere udev(7)). Per ogni dispositivo rilevato dal kernel, il sistema udev avvia un processo utente che usa le informazioni del filesystem sysfs (vedere Sezione 1.2.12, «procfs e sysfs»), carica, usando modprobe(8) (vedere Sezione 3.3.1, «L'inizializzazione dei moduli del kernel»), i moduli del kernel necessari per il supporto del dispositivo e crea i nodi di device corrispondenti.

[Suggerimento] Suggerimento

Se, per una qualche ragione "/lib/modules/<versione-kernel>/modules.dep non viene generato in modo appropriato dal depmod(8), i moduli non possono essere caricati come dovuto dal sistema udev. Per risolvere il problema eseguire "depmod -a".

Il nome dei nodi di device può essere configurato dai file di regole di udev in "/etc/udev/rules.d/". Le regole predefinite attuali tendono a creare nomi generati dinamicamente che hanno come risultato nomi di device non fissi, tranne che per dispositivi CD e di rete. Aggiungendo le proprie regole personalizzate, in modo simile a quelle per i dispositivi CD e di rete, si possono creare nomi di device statici anche per altri dispositivi, come chiavette USB. Vedere "Scrivere regole udev" o "/usr/share/doc/udev/writing_udev_rules/index.html".

Dato che il sistema udev è in qualche modo in costante evoluzione, in questo documento sono fornite informazioni base, lasciando i dettagli ad altra documentazione.

[Suggerimento] Suggerimento

Per le regole di montaggio in "/etc/fstab", non è necessario che i nodi di device siano statici. Si possono usare gli UUID per montare i dispositivi, al posto dei nomi di device come "/dev/sda". Vedere Sezione 9.5.3, «Accedere alle partizioni usando UUID».

Il programma modprobe(8) permette di configurare il kernel Linux in esecuzione da processi utente, aggiungendo e rimuovendo moduli del kernel. Il sistema udev (vedere Sezione 3.3, «Il sistema udev») automatizza la sua invocazione per facilitare l'inizializzazione dei moduli del kernel.

Ci sono moduli non-hardware e speciali moduli con driver hardware, come quelli elencati in seguito, che devono essere precaricati elencandoli nel file "/etc/modules" (vedere modules(5)).

I file di configurazione per il programma modprobe(8) sono contenuti nella directory "/etc/modprobes.d/", come spiegato in modprobe.conf(5). (Se si desidera evitare l'autocaricamento di alcuni moduli del kernel, considerare la loro aggiunta nella lista nera nel file "/etc/modprobes.d/blacklist".)

Il file "/lib/modules/<versione>/modules.dep" generato dal programma depmod(8) descrive le dipendenze dei moduli usate dal programma modprobe(8).

[Nota] Nota

Se si hanno problemi di caricamento dei moduli all'avvio o con modprobe(8), "depmod -a" potrebbe risolverli rigenerando il file "modules.dep".

Il programma modinfo(8) mostra informazioni su un modulo del kernel Linux.

Il programma lsmod(8) formatta in un bel modo i contenuti di "/proc/modules", mostrando quali moduli del kernel siano attualmente caricati.

[Suggerimento] Suggerimento

Si può identificare l'esatto hardware sul proprio sistema. Vedere Sezione 9.4.3, «Identificazione dell'hardware».

[Suggerimento] Suggerimento

Si può configurare l'hardware all'avvio per attivare le funzionalità dell'hardware desiderate. Vedere Sezione 9.4.4, «Configurazione dell'hardware».

[Suggerimento] Suggerimento

Si può probabilmente aggiungere il supporto per il proprio speciale dispositivo ricompilando il kernel. Vedere Sezione 9.9, «Il kernel».