Indice
È 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.
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) descrive il processo di avvio del sistema
basato su systemd
(Debian recenti).
boot
(7) descrive il processo di avvio del sistema basato
su UNIX System V Release 4 (Debian più vecchie).
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.
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.
Tabella 3.1. Elenco di bootloader
pacchetto | popcon | dimensione | initrd | bootloader | descrizione |
---|---|---|---|---|---|
grub-efi-amd64 | I:227 | 158 | Supportato | GRUB UEFI | This is smart enough to understand disk partitions and filesystems such as vfat, ext4, …. (UEFI) |
grub-pc | V:25, I:746 | 533 | Supportato | 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 | Supportato | GRUB 2 | È l'immagine di ripristino avviabile di GRUB 2 (CD e floppy) (versione PC/BIOS) |
lilo | V:0, I:1 | 697 | Supportato | Lilo | Si basa sulla posizione dei settori dei dati sul disco fisso. (Vecchio) |
syslinux | V:3, I:44 | 344 | Supportato | Isolinux | Capisce il filesystem ISO 9660. Usato dal CD di avvio. |
syslinux | V:3, I:44 | 344 | Supportato | Syslinux | Capisce il filesystem MSDOS (FAT). Usato dai dischetti floppy di avvio. |
loadlin | V:0, I:0 | 90 | Supportato | Loadlin | Il nuovo sistema viene avviato dal sistema FreeDOS/MSDOS. |
mbr | V:0, I:6 | 50 | Non supportato | MBR di Neil Turton | Software libero che sostituisce MBR MSDOS. Capisce solo le partizioni su disco. |
![]() |
Avvertimento |
---|---|
Non mettere mano ai bootloader senza aver creato supporti avviabili di
ripristino (chiavette USB, CD o floppy) create da immagini nel pacchetto
|
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.
Tabella 3.2. The meaning of the menu entry of the above part of
/boot/grub/grub.cfg
setting | valore |
---|---|
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 |
![]() |
Suggerimento |
---|---|
You can customize GRUB splash image by setting
|
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. |
Il programma "/init
" viene eseguito come primo programma
in questo file system root in memoria. È un programma che inizializza il
kernel in spazio utente e passa il controllo allo stadio successivo. Questo
mini-sistema Debian offre flessibilità al processo di avvio, come la
possibilità di aggiungere moduli del kernel prima del processo di avvio
principale o di montare il file system root come cifrato.
Il programma "/init
" è uno script di shell se initramfs è
stato creato da initramfs-tools
.
Si può interrompere questa parte del processo di avvio per ottenere una
shell di root fornendo il parametro di avvio per il kernel
"break=init
" etc. Vedere lo script
"/init
" per ulteriori condizioni di interruzione. Questo
ambiente shell è abbastanza sofisticato da fare una buona ispezione
dell'hardware della macchina.
I comandi disponibili in questo mini-sistema Debian sono versioni minimali e
vengono principalmente forniti da uno strumento GNU chiamato
busybox
(1).
Il programma "/init
" è un programma binario di
systemd
se initramfs è stato creato da
dracut
.
I comandi disponibili in questo mini-sistema Debian sono un ambiente
systemd
(1) ridotto al minimo.
![]() |
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
».
"/sbin/init
" is symlinked to
"/lib/systemd/systemd
" after Debian 8 Jessie (released in
2015).
![]() |
Suggerimento |
---|---|
Si può verificare quale è l'effettivo comando init nel proprio sistema con
il comando « |
Tabella 3.3. Elenco di utilità di avvio per il sistema Debian
pacchetto | popcon | dimensione | descrizione |
---|---|---|---|
systemd
|
V:837, I:935 | 15615 | demone init (8) basato su eventi per concorrenza
(alternativa a sysvinit ) |
systemd-sysv
|
V:811, I:934 | 143 | le pagine di manuale e i collegamenti necessari affinché
systemd sostituisca sysvinit |
init-system-helpers
|
V:684, I:947 | 131 | strumenti ausiliari per commutare tra sysvinit e
systemd |
initscripts
|
V:70, I:256 | 171 | script per inizializzare ed arrestare il sistema |
sysvinit-core
|
V:7, I:8 | 279 | utilità init (8) in stile System-V |
sysv-rc
|
V:139, I:269 | 82 | meccanismo di cambiamento del runlevel in stile System-V |
sysvinit-utils
|
V:419, I:999 | 81 | utilità in stile System-V (startpar (8),
bootlogd (8), …) |
lsb-base
|
V:888, I:999 | 49 | funzionalità di script init Linux Standard Base 3.2 |
insserv
|
V:165, I:265 | 154 | strumento per organizzare la sequenza di avvio usando dipendenze LSB negli script init.d |
uswsusp
|
V:1, I:6 | 714 | strumenti per usare la sospensione software in spazio utente fornita da Linux |
kexec-tools
|
V:1, I:8 | 289 | strumento kexec per riavvii kexec (8) (riavvio a caldo) |
systemd-bootchart
|
V:0, I:1 | 128 | analizzatore delle prestazioni del processo di avvio |
bootchart2
|
V:0, I:0 | NOT_FOUND | analizzatore delle prestazioni del processo di avvio |
pybootchartgui
|
V:0, I:0 | NOT_FOUND | analizzatore delle prestazioni del processo di avvio (visualizzazione) |
mingetty
|
V:0, I:3 | 38 | getty (8) solo console |
mgetty
|
V:0, I:0 | 315 | 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. |
Questa sezione describe come viene avviato il sistema dal programma
systemd
(1) con PID=1
(cioè processo
init).
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 Sezione 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
": file di configurazione predefiniti
del sistema operativo
"/etc/systemd/system
": file di configurazione
dell'amministratore di sistema che scavalcano i file di configurazione
predefiniti del sistema operativo
"/run/systemd/system
": file di configurazione generati al
momento dell'esecuzione che scavalcano i file di configurazione installati
Le loro inter-dipendenze sono specificate dalle direttive
"Wants=
", "Requires=
",
"Before=
", "After=
", … (vedere
"MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" in
systemd.unit
(5)). Sono definiti anche i controlli delle
risorse (vedere systemd.resource-control
(5)).
Il suffisso dei file di configurazione delle unità codifica il loro tipo in questo modo:
*.service descrive un processo
controllato e supervisionato da systemd
. Vedere
systemd.service
(5).
*.device descrive un device esposto in
sysfs
(5) come albero di device
udev
(7). Vedere systemd.device
(5).
*.mount descrive un punto di mount del
file system controllato e supervisionato da
systemd
. Vedere systemd.mount
(5).
*.automount descrive un punto di mount
automatico del file system controllato e supervisionato da
systemd
. Vedere systemd.automount
(5).
*.swap descrive un device o file di swap
controllato e supervisionato da systemd
. Vedere
systemd.swap
(5).
*.path descrive un percorso monitorato da
systemd
per l'attivazione basata su percorso. Vedere
systemd.path
(5).
*.socket descrive un socket controllato e
supervisionato da systemd
per l'attivazione basata su
socket. Vedere systemd.socket
(5).
*.timer descrive un timer controllato e
supervisionato da systemd
per l'attivazione basata su
timer. Vedere systemd.timer
(5).
*.slice gestisce risorse con
cgroups
(7). Vedere systemd.slice
(5).
*.scope viene creato programmaticamente
usando le interfacce di bus di systemd
per gestire un
insieme di processi di sistema. Vedere systemd.scope
(5).
*.target raggruppa altri file di
configurazione di unità per creare punti di sincronizzazione durante
l'avvio. Vedere systemd.target
(5).
All'avvio del sistema (cioè init) il processo systemd
cerca di avviare "/lib/systemd/system/default.target
"
(normalmente un collegamento simbolico a
"graphical.target
"). Come prima cosa alcune speciali
unità target (vedere systemd.special
(7)) come
"local-fs.target
", "swap.target
" e
"cryptsetup.target
" sono richiamate per montare i file
system. Poi altre unità target vengono anch'esse richiamate dalle dipendenze
delle unità target. Per i dettagli leggere bootup
(7).
systemd
offre funzionalità di compatibilità
all'indietro. Gli script di avvio in stile SysV in
"/etc/init.d/rc[0123456S].d/[KS]name
"
sono comunque analizzati e telinit
(8) viene tradotto in
richieste di attivazione di unità systemd.
![]() |
Attenzione |
---|---|
Run level emulati da 2 a 4 hanno tutti collegamenti simbolici al
corrispondente " |
Il kernel gestisce il nome host del
sistema. L'unità systemd avviata
dasystemd-hostnamed.service
imposta il nome host del
sistema all'avvio al nome memorizzato in
"/etc/hostname
". Questo file dovrebbe contenere solamente il nome host del sistema, non un nome di
dominio pienamente qualificato.
Per visualizzare il nome host attuale eseguire
hostname
(1) senza alcun argomento.
Le opzioni usate per montare i file system normali dei dischi e di rete sono
impostate in "/etc/fstab
". Vedere
fstab
(5) e Sezione 9.6.7, «Ottimizzare il file system con opzioni di mount».
La configurazione dei file system cifrati è impostata in
"/etc/crypttab
". Vedere crypttab
(5)
Vedere wvdial
(1) e wvdial.conf
(5).
![]() |
Avvertimento |
---|---|
Dopo aver montato tutti i filesystem, i file temporanei in
" |
Le interfacce di rete sono tipicamente inizializzate in
"networking.service
" per l'interfaccia
lo
e "NetworkManager.service
" per le
altre interfacce nei moderni sistemi desktop Debian che usano
systemd
.
Vedere Capitolo 5, Impostazione della rete per come configurarle.
I messaggi di errore del kernel visualizzati nella console possono essere configurati impostando il loro livello di soglia.
# 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. For example, you can
display log from the last boot as:
$ journalctl -b
Tabella 3.5. List of typical journalctl
command snippets
Operazione | Esempio di comando |
---|---|
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 Sezione 9.3.2, «Analizzatori di registro».
The systemd
offers not only init system but also generic
system management operations with the systemctl
(1)
command.
Tabella 3.6. List of typical systemctl
command snippets
Operazione | Esempio di comando |
---|---|
Elencare tutte le configurazioni delle unità target | "systemctl list-units --type=target " |
Elencare tutte le configurazioni delle unità service | "systemctl list-units --type=service " |
Elencare tutti i tipi di configurazioni delle unità | "systemctl list-units --type=help " |
Elencare tutte le unità socket in memoria | "systemctl list-sockets " |
Elencare tutte le unità timer in memoria | "systemctl list-timers " |
Avviare "$unit " |
"systemctl start $unit " |
Fermare "$unit " |
"systemctl stop $unit " |
Ricaricare la configurazione specifica di un servizio | "systemctl reload $unit " |
Fermare e riavviare tutte le "$unit " |
"systemctl restart $unit " |
Avviare "$unit " e fermare tutte le altre |
"systemctl isolate $unit " |
Passare alla modalità "graphical " (sistema GUI) |
"systemctl isolate graphical " |
Passare alla modalità "multi-user " (sistema CLI) |
"systemctl isolate multi-user " |
Passare alla modalità "rescue " (sistema CLI a singolo
utente) |
"systemctl isolate rescue " |
Inviare il segnale kill a "$unit " |
"systemctl kill $unit " |
Controllare se il servizio "$unit " è attivo |
"systemctl is-active $unit " |
Controllare se il servizio "$unit " è fallito |
"systemctl is-failed $unit " |
Controllare lo stato di "$unit|$PID|device " |
"systemctl status $unit|$PID|$device " |
Mostrare le proprietà di "$unit|$job " |
"systemctl show $unit|$job " |
Ripristinare "$unit " fallita |
"systemctl reset-failed $unit" |
Elencare le dipendenze di tutti i servizi unità | "systemctl list-dependencies --all " |
Elencare i file di unità installati sul sistema | "systemctl list-unit-files " |
Abilitare "$unit " (aggiungere collegamento simbolico) |
"systemctl enable $unit " |
Disabilitare "$unit " (rimuovere collegamento simbolico) |
"systemctl disable $unit " |
Togliere maschera a "$unit " (rimuovere collegamento
simbolico a"/dev/null ") |
"systemctl unmask $unit " |
Mascherare "$unit " (aggiungere collegamento simbolico
a"/dev/null ") |
"systemctl mask $unit " |
Ottenere l'impostazione del target predefinito | "systemctl get-default " |
Impostare default-target a "graphical " (sistema GUI) |
"systemctl set-default graphical " |
Impostare default-target a "multi-user " (sistema CLI) |
"systemctl set-default multi-user " |
Mostrare l'ambiente del lavoro | "systemctl show-environment " |
Impostare la variabile "variable " dell'ambiente di lavoro
al valore "value " |
"systemctl set-environment variable=value " |
Disimpostare la variabile "variable " dell'ambiente di
lavoro |
"systemctl unset-environment variable " |
Ricaricare tutti i file di unità e i demoni | "systemctl daemon-reload " |
Spegnere il sistema | "systemctl poweroff " |
Spegnere e riavviare il sistema | "systemctl reboot " |
Sospendere il sistema | "systemctl suspend " |
Ibernare il sistema | "systemctl hibernate " |
Negli esempi soprastanti "$unit
" può essere un singolo
nome di unità (suffissi come .service
e
.target
sono opzionali) o, in molti casi, la specifica di
più unità (con glob in stile shell "*
",
"?
", "[]
" usando
fnmatch
(3) con corrispondenze con i nomi primari di tutte
le unità attualmente in memoria).
I comandi che cambiano lo stato del sistema negli esempi soprastanti sono
tipicamente preceduti da "sudo
" per ottenere i privilegi
amministrativi necessari.
L'output di "systemctl status $unit|$PID|$device
" usa il
colore del puntino ("●") per riassumere lo stato dell'unità a prima vista.
Un "●" bianco indica uno stato "inattivo" o "deattivato".
Un "●" rosso indica uno stato di "fallimento" o "errore".
Un "●" verde indica uno stato "attivo", "in ricaricamento" o "in attivazione".
Here are a list of other monitoring command snippets under
systemd
. Please read the pertinent manpages including
cgroups
(7).
Tabella 3.7. List of other monitoring command snippets under systemd
Operazione | Esempio di comando |
---|---|
Mostrare il tempo utilizzato per ogni passo di inizializzazione | "systemd-analyze time " |
Elencare tutte le unità col tempo di inizializzazione | "systemd-analyze blame " |
Carica e rileva gli errori nel file "$unit " |
"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 | Leggere sysfs in
"/sys/fs/cgroup/systemd/ " |
Con l'installazione predefinita molti servizi di rete (vedere Capitolo 6, Applicazioni per la rete) vengono avviati come processi demone dopo
network.target
al momento dell'avvio di sistema da
systemd
. "sshd
non fa eccezione. Come
esempio di personalizzazione cambiamo questo comportamento nell'avvio
on-demand di "sshd
".
Come prima cosa disabilitare l'unità di servizio installata dal sistema.
$ 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
per specificare un socket su cui restare in
ascolto
[Unit] Description=SSH Socket for Per-Connection Servers [Socket] ListenStream=22 Accept=yes [Install] WantedBy=sockets.target
sshd@.service
come file di servizio corrispondente di
sshd.socket
[Unit] Description=SSH Per-Connection Server [Service] ExecStart=-/usr/sbin/sshd -i StandardInput=socket
Poi ricaricare.
$ 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
Sezione 1.2.12, «procfs e sysfs»), loads required kernel modules
supporting it using the modprobe
(8) program (see Sezione 3.8.1, «L'inizializzazione dei moduli del kernel»), and creates corresponding
device nodes.
![]() |
Suggerimento |
---|---|
Se, per una qualche ragione
" Per le regole di montaggio in " |
Dato che il sistema udev è in qualche modo in costante evoluzione, in questo documento sono fornite informazioni base, lasciando i dettagli ad altra documentazione.
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.8, «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.6, «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
|
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.5.3, «Identificazione dell'hardware». Si può configurare l'hardware all'avvio per attivare le funzionalità dell'hardware desiderate. Vedere Sezione 9.5.4, «Configurazione dell'hardware». Si può probabilmente aggiungere il supporto per il proprio speciale dispositivo ricompilando il kernel. Vedere Sezione 9.10, «Il kernel». |