Kapitel 3. Die Systeminitialisierung

Inhaltsverzeichnis

3.1. Ein Überblick über den Bootstrap-Prozess
3.1.1. Stufe 1: das BIOS
3.1.2. Stufe 2: der Bootloader
3.1.3. Stufe 3: das Mini-Debian-System
3.1.4. Stufe 4: das normale Debian-System
3.2. Systemd init
3.2.1. Der Rechnername
3.2.2. Das Dateisystem
3.2.3. Initialisierung der Netzwerkschnittstellen
3.2.4. Die Kernel-Meldungen
3.2.5. Die Systemmeldungen
3.2.6. System management under systemd
3.2.7. Customizing systemd
3.3. Das udev-System
3.3.1. Die Kernel-Modul-Initialisierung

Als Systemadministrator sollten Sie grob wissen, wie das Debian-System gestartet und konfiguriert wird. Obwohl die genauen Details in den Quelldateien der installierten Pakete und deren Dokumentation zu finden sind, ist dies für die meisten von uns ein bisschen viel.

Ich habe mein bestes gegeben, um einen schnellen Überblick über die wichtigsten Themen des Debian-Systems und dessen Konfiguration als Referenz für Sie bereitzustellen, basierend auf aktuellem und früherem Wissen von mir und anderen. Da das Debian-System sich ständig verändert, könnte sich die Situation teilweise verändert haben. Bevor Sie irgendwelche Änderungen an dem System vornehmen, sollten Sie die aktuellste Dokumentation der jeweiligen Pakete zu Rate ziehen.

[Tipp] Tipp

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

[Tipp] Tipp

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

Das Computer-System durchläuft verschiedene Phasen des Bootstrap-Prozesses vom Einschalten bis zur Bereitstellung des funktionalen Betriebssystems an den Benutzer.

Der Einfachheit halber beschränke ich meine Betrachtung auf die weit verbreitete PC-Plattform mit einer Standardinstallation.

Der typische Bootstrap-Prozess ist wie eine 4-stufige Rakete. Jede Stufe übergibt die Systemkontrolle an die jeweils nachfolgende Stufe:

Natürlich können diese unterschiedlich konfiguriert werden. Wenn Sie zum Beispiel Ihren eigenen Kernel kompilieren, werden Sie unter Umständen den Schritt mit dem Mini-Debian-System überspringen. Gehen Sie daher nicht davon aus, dass dies alles in Ihrem Fall zutrifft, solange Sie es nicht selbst überprüft haben.

[Anmerkung] Anmerkung

Bei ungewöhnlichen Computer-Plattformen wie dem SUN- oder dem Macintosh-System könnten das BIOS im ROM und die Partitionen auf der Festplatte sich stark von dem hier beschriebenen unterscheiden (Abschnitt 9.5.2, „Konfiguration der Plattenpartitionen“). Bitte suchen Sie in solch einem Fall an anderer Stelle nach Plattform-spezifischer Dokumentation.

Das BIOS ist die erste Stufe des Boot-Prozesses und wird durch das Einschalten des Rechners aufgerufen. Es liegt im Nur-Lese-Speicher (read only memory/ROM) und wird von einer speziellen Speicheradresse ausgeführt, auf die die CPU durch den Einschaltvorgang verwiesen wird.

Das BIOS führt die grundsätzliche Initialisierung der Hardware durch (POST: power on self test / Selbsttest nach dem Einschalten) und übergibt die Systemkontrolle an die nächste Stufe. Das BIOS wird üblicherweise mit der Hardware geliefert.

Im BIOS-Startbildschirm wird für gewöhnlich angezeigt, welche Taste(n) Sie drücken müssen, um das BIOS-Setup zu erreichen, in dem das Verhalten des BIOS konfiguriert werden kann. Typisch hierfür sind F1, F2, F10, Esc, Einfg und Entf. Wenn Ihr BIOS-Startbildschirm durch eine hübsche grafische Anzeige versteckt wird, müssen Sie eventuell eine oder mehrere Tasten wie z.B. Esc drücken, um diese Grafik auszublenden. Die hierzu benötigten Tasten sind je nach Hardware sehr unterschiedlich.

Die Hardware und die Reihenfolge des Codes, der durch das BIOS gestartet wird, kann über das BIOS-Setup ausgewählt werden. Typischerweise werden die ersten paar Sektoren des ersten gefundenen, vorgewählten Gerätes (Festplatte, Diskette, CD-ROM, …) in den Speicher geladen und dieser initiale Code wird dann ausgeführt. Das kann folgendes sein:

  • ein Bootloader-Code;

  • der Kernel-Code eines Ursprungs-Betriebssystems wie z.B. FreeDOS;

  • der Kernel-Code des Ziel-Betriebssystems, falls er in diesen kleinen Speicherbereich passt.

Gewöhnlich wird das System von der angegebenen Partition der primären Festplatte gestartet. Die ersten zwei Sektoren der Festplatte enthalten auf normalen PC-Systemen den Master Boot Record (MBR). Die Partitionsinformationen inklusive der Boot-Auswahl sind am Ende des MBR gespeichert. Der in der ersten Stufe vom BIOS ausgeführte Bootloader-Code liegt im Rest des MBR.

Der Bootloader ist die zweite Stufe des Boot-Prozesses und wird durch das BIOS gestartet. Er lädt das System-Kernel-Image und das initrd-Image in den Speicher und übergibt diesen die Kontrolle. Das initrd-Image ist ein Abbild des Wurzeldateisystems und seine Unterstützung hängt von dem verwendeten Bootloader ab.

Das Debian-System nutzt normalerweise den Linux-Kernel als Standard-System-Kernel. Das initrd-Image des aktuellen 2.6/3.x-Linux-Kernels ist technisch gesehen ein initramfs-Image (initial RAM filesystem). Das initramfs-Image ist ein mit gzip komprimiertes cpio-Archiv der Dateien im Wurzeldateisystem.

[Warnung] Warnung

Obiges gilt nicht mehr für das neue Multi-Segment-initramfs. Lesen Sie dazu Bug #790100.

Eine Standardinstallation des Debian-Systems auf der PC-Plattform legt den ersten Teil des GRUB-Bootloaders (stage 1) im MBR ab. Es sind allerdings viele weitere Bootloader und Konfigurationsoptionen verfügbar.


[Warnung] Warnung

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.

Bei GRUB Legacy ist die Datei zur Konfiguration des Menüs unter "/boot/grub/menu.lst" abgelegt. Sie enthält zum Beispiel Einträge wie den folgenden:

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

Bei GRUB 2 ist die Datei zur Konfiguration des Menüs unter "/boot/grub/grub.cfg" gespeichert. Sie wird automatisch durch "/usr/sbin/update-grub" unter Verwendung von Vorlagen aus "/etc/grub.d/*" und Einstellungen aus "/etc/default/grub" erzeugt. Die Einträge sehen aus wie folgt:

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

Die GRUB-Parameter in diesen Beispielen haben folgende Bedeutungen:


[Anmerkung] Anmerkung

Der Wert der Partitionsnummer, wie er von GRUB Legacy verwendet wird, ist um 1 kleiner als der normal durch den Linux-Kernel und andere Werkzeuge genutzte. Das GRUB-2-Programm behebt dieses Problem.

[Tipp] Tipp

Die UUID-Kennung (lesen Sie dazu Abschnitt 9.5.3, „Zugriff auf Partitionen über die UUID-Kennung“) kann statt dem Gerätenamen (z.B. "/dev/hda3") genutzt werden, um ein block-orientiertes Gerät eindeutig zu identifizieren, z.B. mittels "root=UUID=81b289d5-4341-4003-9602-e254a17ac232 ro".

[Tipp] Tipp

Bei der Nutzung von GRUB sind die Kernel-Boot-Parameter in /boot/grub/grub.cfg festgelegt. Auf Debian-Systemen sollten Sie /boot/grub/grub.cfg jedoch nicht direkt verändern. Ändern Sie stattdessen den GRUB_CMDLINE_LINUX_DEFAULT-Wert in /etc/default/grub und führen Sie dann update-grub(8) aus, um /boot/grub/grub.cfg zu aktualisieren.

[Tipp] Tipp

Sie können über einen Bootloader einen weiteren Bootloader starten, diese Technik nennt man Chain loading.

Weitere Infos finden Sie unter "info grub" und grub-install(8).

Das Mini-Debian-System ist die dritte Stufe des Boot-Prozesses und wird durch den Bootloader gestartet. Es lässt den System-Kernel mit seinem eigenen Wurzeldateisystem im Speicher laufen. Dies ist ein optionaler, vorbereitender Schritt des Boot-Prozesses.

[Anmerkung] Anmerkung

Der Begriff "Mini-Debian-System" wurde von dem Autor erfunden, um diese dritte Stufe des Boot-Prozesses in diesem Dokument zu beschreiben. Dieses System wird normalerweise initrd- oder initramfs-System genannt. Ein ähnliches System wird im Speicher auch durch den Debian Installer verwendet.

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.

[Achtung] Achtung

Sie müssen die Option "-n" für den mount-Befehl verwenden, wenn Sie sich im Nur-Lese-Wurzeldateisystem befinden.

Das normale Debian-System ist die vierte Stufe des Boot-Prozesses und wird von dem Mini-Debian-System gestartet. Der System-Kernel des Mini-Debian-Systems läuft in dieser Umgebung weiter. Das verwendete Wurzeldateisystem wird von dem im Arbeitsspeicher umgeschwenkt zu dem auf der echten Festplatte.

Das Programm init wird als erstes Programm mit PID=1 ausgeführt und erledigt die eigentliche Hauptarbeit beim Booten, das Starten verschiedener Programme. Der Standardpfad zum init-Programm ist "/sbin/init", aber er kann über einen Kernel-Boot-Parameter wie "init=/pfad/zum/init-programm" auch geändert werden.

Das Standard-Init-Programm hat sich im Laufe der Zeit verändert:

  • Vor Squeeze verwendete Debian das einfache SysV-artige Init.

  • Debian Wheezy verbesserte das SysV-ähnliche Init durch Sortierung der Boot-Reihenfolge mittels LSB-Header und parallelen Start der Boot-Skripte.

  • Debian Jessie schwenkt um auf systemd, ein ereignisbasiertes Init-System mit paralleler Initialisierung.

[Tipp] Tipp

Mittels "ps --pid 1 -f" können Sie überprüfen, welcher init-Befehl letztlich auf Ihrem System verwendet wird.

[Tipp] Tipp

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

Tabelle 3.3. Liste von Boot-Hilfsprogrammen für das Debian-System

Paket Popcon Größe Beschreibung
systemd V:703, I:805 11933 Ereignis-basierter init(8)-Daemon für gleichzeitige Ausführung (Alternative zu 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 Skripte zur Initialisierung und zum Herunterfahren des Systems
sysvinit-core V:13, I:17 225 System-V-ähnliche init(8)-Werkzeuge
sysv-rc V:477, I:673 123 System-V-ähnlicher Mechanismus zum Wechsel des Runlevels
sysvinit-utils V:791, I:999 110 System-V-ähnliche Werkzeuge (startpar(8), bootlogd(8), …)
lsb-base V:877, I:999 49 Zur Linux Standard Base 3.2 konforme init-Skript-Funktionalität
insserv V:539, I:660 140 Werkzeug, um die Boot-Reihenfolge unter Verwendung von LSB-konformen init.d-Skript-Abhängigkeiten zu organisieren
uswsusp V:4, I:11 699 Werkzeuge, um das durch Linux bereitgestellte Userspace-Software-Suspend zu verwenden
kexec-tools V:1, I:8 270 Werkzeug für kexec(8)-Neustarts (Warmstarts)
systemd-bootchart V:0, I:0 122 Performance-Analyseprogramm für den Boot-Prozess
bootchart2 V:0, I:1 94 Performance-Analyseprogramm für den Boot-Prozess
pybootchartgui V:0, I:1 177 Performance-Analyseprogramm für den Boot-Prozess (Visualisierung)
mingetty V:0, I:3 35 getty(8) nur für die Konsole
mgetty V:0, I:1 301 Intelligenter getty(8)-Ersatz für Modems

[Tipp] Tipp

Unter Debian Wiki: BootProcessSpeedup finden Sie aktuelle Tipps zur Beschleunigung des Boot-Prozesses.

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.

[Achtung] Achtung

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 Abschnitt 9.5.7, „Optimierung von Dateisystemen über mount-Optionen“.

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

[Warnung] Warnung

Bei jedem Systemstart werden nach dem Einbinden aller Dateisysteme temporäre Dateien in "/tmp", "/var/lock" und "/var/run" gelöscht.

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.

Tabelle 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 Kapitel 6, Netzwerkapplikationen) 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

Für Linux-Kernel der 2.6-Reihe und neuer bietet das udev-System Mechanismen für automatische Hardware-Erkennung und -initialisierung (lesen Sie dazu udev(7)). Nach der Erkennung eines Gerätes durch den Kernel startet das udev-System einen User-Prozess. Dieser verwendet Informationen aus dem sysfs-Dateisystem (Näheres in Abschnitt 1.2.12, „procfs und sysfs“), lädt über den Befehl modprobe(8) benötigte Kernel-Module, die die Hardware unterstützen (Details in Abschnitt 3.3.1, „Die Kernel-Modul-Initialisierung“), und erstellt die zugehörigen Geräteknoten (device nodes).

[Tipp] Tipp

Falls "/lib/modules/<kernel-version>/modules.dep" mittels depmod(8) aus irgendeinem Grund nicht korrekt erstellt wurde, könnte es beim Laden der Module durch das udev-System Probleme geben. Führen Sie "depmod -a" aus, um dies zu beheben.

Die Namen der Geräteknoten können über udev-Regel-Dateien in "/etc/udev/rules.d/" konfiguriert werden. Aktuelle Standardregeln neigen dazu, dynamisch generierte Namen zu erzeugen, was (außer bei CD- und Netzwerkgeräten) dazu führt, dass sich die Gerätenamen von Mal zu Mal ändern. Indem Sie Ihre eigenen Regeln hinzufügen (ähnlich denen für CD- und Netzwerkgeräte), können Sie auch für andere Geräte wie z.B. USB-Memory-Sticks fest zugeordnete Gerätenamen vergeben. Lesen Sie dazu "Writing udev rules" oder "/usr/share/doc/udev/writing_udev_rules/index.html".

Da das udev-System immer ein wenig im Wandel ist, überlasse ich die Details anderen Dokumenten und beschränke mich hier auf das Nötigste.

[Tipp] Tipp

Für die Regeln zum Einbinden von Dateisystemen in "/etc/fstab" müssen Geräteknoten nicht fest zugeordnet sein. Sie können auch UUIDs verwenden, um Geräte einzubinden, statt der Gerätenamen wie "/dev/sda". Lesen Sie dazu Abschnitt 9.5.3, „Zugriff auf Partitionen über die UUID-Kennung“.

Das modprobe(8)-Programm erlaubt es, einen laufenden Linux-Kernel über einen User-Prozess zu konfigurieren, indem Kernel-Module hinzugefügt und entfernt werden. Das udev-System (Näheres in Abschnitt 3.3, „Das udev-System“) automatisiert dessen Aufruf, um bei der Initialisierung des Kernel-Moduls zu helfen.

Es gibt Module, die nicht zu bestimmter Hardware gehören, sowie spezielle Hardware-Treibermodule wie die folgenden, die im Voraus geladen werden müssen, indem Sie in die Datei "/etc/modules" eingetragen werden (Details in modules(5)):

Die Konfigurationsdateien für das modprobe(8)-Programm sind unterhalb des "/etc/modprobes.d/"-Verzeichnisses abgelegt, wie in modprobe.conf(5) beschrieben. (Falls Sie vermeiden möchten, dass einige Kernel-Module automatisch geladen werden, sollten Sie erwägen, diese in die Datei "/etc/modprobes.d/blacklist" einzutragen.)

Die Datei "/lib/modules/<version>/modules.dep" (erzeugt durch das Programm depmod(8)) beschreibt Abhängigkeiten zwischen den Modulen; diese Abhängigkeiten werden von modprobe(8) genutzt.

[Anmerkung] Anmerkung

Wenn Sie Probleme beim Laden von Modulen feststellen, entweder während des Systemstarts oder beim Nachladen mit modprobe(8), kann "depmod -a" diese Probleme möglicherweise durch Neuerstellung der "modules.dep"-Datei beheben.

Der Befehl modinfo(8) zeigt Informationen über ein Linux-Kernel-Modul an.

Das lsmod(8)-Programm formatiert den Inhalt von "/proc/modules" zu einer hübschen Ausgabe, um anzuzeigen, welche Kernel-Module gerade geladen sind.

[Tipp] Tipp

Sie können die Hardware in Ihrem System exakt identifizieren. Lesen Sie dazu Abschnitt 9.4.3, „Hardware-Identifikation“.

[Tipp] Tipp

Möglicherweise wollen Sie Hardware während des Systemstarts konfigurieren, um bestimmte erwartete Hardware-Funktionalitäten zu aktivieren. Näheres finden Sie in Abschnitt 9.4.4, „Hardware-Konfiguration“.

[Tipp] Tipp

Unterstützung für spezielle Geräte können Sie unter Umständen durch Neukompilieren des Kernels hinzufügen. Details finden Sie in Abschnitt 9.9, „Der Kernel“.