È 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 |
---|---|
bootup(7)
describes the system bootup process based on |
![]() |
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 |
---|---|
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 |
---|---|
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.
Tabella 3.1. Elenco di bootloader
pacchetto | popcon | dimensione | initrd | bootloader | descrizione |
---|---|---|---|---|---|
grub-legacy | V:0, I:2 | 710 | Supportato | GRUB Legacy | Intelligente abbastanza da capire partizioni su disco e filesystem come vfat, ext3, ... |
grub-pc | V:29, I:849 | 584 | Supportato | GRUB 2 | Intelligente abbastanza da capire partizioni su disco e filesystem come vfat, ext4, …. (predefinito) |
grub-rescue-pc | V:0, I:1 | 6294 | Supportato | GRUB 2 | È l'immagine di ripristino avviabile di GRUB 2 (CD e floppy) (versione PC/BIOS) |
lilo | V:0, I:3 | 693 | Supportato | Lilo | Si basa sulla posizione dei settori dei dati sul disco fisso. (Vecchio) |
syslinux | V:5, I:59 | 299 | Supportato | Isolinux | Capisce il filesystem ISO 9660. Usato dal CD di avvio. |
syslinux | V:5, I:59 | 299 | Supportato | Syslinux | Capisce il filesystem MSDOS (FAT). Usato dai dischetti floppy di avvio. |
loadlin | V:0, I:1 | 84 | Supportato | Loadlin | Il nuovo sistema viene avviato dal sistema FreeDOS/MSDOS. |
mbr | V:0, I:10 | 50 | Non supportato | MBR di Neil Turton | Software libero che sostituisce MBR MSDOS. Capisce solo le partizioni su disco. |
![]() |
Avvertimento |
---|---|
Do not play with boot loaders without having bootable rescue media (USB
memory stick, CD or floppy) created from images in the
|
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.
Tabella 3.2. Significato dei parametri di GRUB
parametro di GRUB | significato |
---|---|
root
|
usa la terza partizione sul primo disco fisso indicandola come
"(hd0,2) " in GRUB legacy o come
"(hd0,3) " in GRUB 2
|
kernel
|
usa il kernel che si trova in "/vmlinuz " con i parametri
"root=/dev/hda3 ro "
|
initrd
|
usa l'immagine initrd/initramfs che
si trova in "/initrd.img "
|
![]() |
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 |
---|---|
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
" |
![]() |
Suggerimento |
---|---|
Se viene usato GRUB, il parametro di avvio del
kernel viene impostato in |
![]() |
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 |
---|---|
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 |
---|---|
È necessario usare l'opzione " |
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 |
---|---|
Si può verificare quale è l'effettivo comando init nel proprio sistema con
il comando « |
![]() |
Suggerimento |
---|---|
" |
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 |
---|---|
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 |
---|---|
Emulated runlevel 2 to 4 are all symlinked to the same
" |
The kernel maintains the system hostname. The system unit started by
systemd-hostnamed.service
sets the system hostname at
boot time to the name stored in "/etc/hostname
". This
file should contain only the system
hostname, not a fully qualified domain name.
Per visualizzare il nome host attuale eseguire hostname(1) senza alcun argomento.
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 |
---|---|
Dopo aver montato tutti i filesystem, i file temporanei in
" |
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 Capitolo 5, Impostazione della rete for how to configure them.
The kernel error message displayed to the console can be configured by setting its threshold level.
# dmesg -n3
Tabella 3.4. Elenco dei livelli di errore del kernel
valore del livello di errore | nome del livello di errore | significato |
---|---|---|
0 | KERN_EMERG | il sistema è inutilizzabile |
1 | KERN_ALERT | bisogna agire immediatamente |
2 | KERN_CRIT | condizione critica |
3 | KERN_ERR | condizione di errore |
4 | KERN_WARNING | condizione di avvertimento |
5 | KERN_NOTICE | condizione normale ma significativa |
6 | KERN_INFO | messaggio informativo |
7 | KERN_DEBUG | messaggio a livello di debug |
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.
Under systemd
, the system logging utility
rsyslogd(8)
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.
I messaggi di sistema possono essere personalizzati da
"/etc/default/rsyslog
" e
"/etc/rsyslog.conf
" sia per il file di registro sia per
la visualizzazione a schermo. Vedere
rsyslogd(8)
e
rsyslog.conf(5).
Vedere anche Sezione 9.2.2, «Analizzatori di registro».
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 |
---|---|
Se, per una qualche ragione
" |
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 |
---|---|
Per le regole di montaggio in " |
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)).
moduli TUN/TAP che forniscono device virtuali di rete Point-to-Point (TUN) e device virtuali di rete Ethernet (TAP),
moduli netfilter che forniscono funzionalità di firewall netfilter (iptables(8), Sezione 5.10, «Infrastruttura netfilter» e
moduli driver watchdog timer.
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 |
---|---|
Se si hanno problemi di caricamento dei moduli all'avvio o con
modprobe(8),
" |
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 |
---|---|
Si può identificare l'esatto hardware sul proprio sistema. Vedere Sezione 9.4.3, «Identificazione dell'hardware». |
![]() |
Suggerimento |
---|---|
Si può configurare l'hardware all'avvio per attivare le funzionalità dell'hardware desiderate. Vedere Sezione 9.4.4, «Configurazione dell'hardware». |
![]() |
Suggerimento |
---|---|
Si può probabilmente aggiungere il supporto per il proprio speciale dispositivo ricompilando il kernel. Vedere Sezione 9.9, «Il kernel». |