Hardware erkennen und Kernelmodule verstehen (LPIC-1 101.1) – Der solide Start in die Systemarchitektur

Die Erkennung, Konfiguration und Diagnose von Hardware ist eine Kernkompetenz im Alltag von Administratoren. Dieser Beitrag führt Schritt für Schritt durch die Themen der LPI-Lernunterlage zu 101.1 und bereitet sie praxisnah auf: Von BIOS/UEFI-Grundlagen über das Anzeigen erkannter Geräte bis zur Arbeit mit Kernelmodulen und den Pseudo-Dateisystemen /proc und /sys. Alle Inhalte der offiziellen Lektion sind enthalten und didaktisch neu strukturiert.

Warum wichtig für Sysadmin

In Rechenzentren, Homelabs und Cloud-Umgebungen entscheidet saubere Hardwareerkennung über Stabilität und Geschwindigkeit. Wer Bootreihenfolgen in UEFI versteht, Treiber (Kernelmodule) gezielt lädt oder sperrt und Ausgabequellen systematisch prüft (lspci, lsusb, /proc, /sys), löst Probleme schnell und vermeidet Ausfälle. Für LPIC-1 ist dieses Fundament prüfungsrelevant – für reale Betriebsaufgaben ist es unverzichtbar.

BIOS/UEFI: Geräte aktivieren, Bootreihenfolge festlegen

Firmware-Setups (früher BIOS, heute meist UEFI) bilden die Grundlage für die Betriebssystemerkennung. Hier werden integrierte Geräte aktiviert/deaktiviert, Schutzmechanismen gesetzt und die Bootreihenfolge definiert. Moderne Systeme brauchen selten manuelle IRQ/DMA-Eingriffe, dennoch ist das Verständnis wichtig – u. a. für Sonderfälle (Leistungs-/Sicherheitsfeatures der CPU, RAM-Timings, Deaktivieren nicht benötigter Funktionen).

Definition: UEFI ist der Nachfolger des klassischen BIOS auf x86-Systemen und bietet erweiterte Funktionen für Erkennung, Test, Konfiguration und Firmware-Updates. Umgangssprachlich wird oft weiterhin „BIOS“ gesagt.

• Bootreihenfolge setzen, damit das Gerät mit Bootloader an erster Stelle steht.
• CPU-Features (z. B. Virtualisierung) bei Bedarf aktivieren/deaktivieren.
• RAM-Parameter an Herstellerangaben anpassen, wenn Stabilität/Leistung relevant sind.

Geräte in Linux anzeigen: Von Bussen und Treibern

Der Kernel muss erkannte Geräte passenden Kernelmodulen (Treibern) zuordnen. Funktioniert etwas nicht, unterscheidet man: Wird die Hardware überhaupt erkannt (Hardware/Slot defekt?) oder fehlt/ passt der Treiber?

PCI-Geräte mit lspci

lspci listet Geräte am PCI-Bus (Onboard-Controller, Erweiterungskarten). Mit -s grenzt man nach Adresse ein, -v zeigt Details, -k liefert Treiberinfos.

# Alle erkannten PCI-Geräte anzeigen

andy@fedora:~$ lspci

01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)
04:02.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
04:04.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)
04:0b.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 70)

# Ausgabe: Liste erkannter PCI-Geräte mit Adresse, Klasse und Modell

# Details zu einem konkreten Gerät via Adresse + ausführlich

andy@fedora:~$ lspci -s 04:02.0 -v

04:02.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
    Subsystem: Linksys WMP54G v4.1
    Flags: bus master, slow devsel, latency 32, IRQ 21
    Memory at e3100000 (32-bit, non-prefetchable) [size=32K]
    Capabilities: [40] Power Management version 2
    kernel driver in use: rt61pci

# Kommentar: "kernel driver in use" zeigt das geladene Kernelmodul (Treiber)

# Zeigt verwendeten Treiber und verfügbare Module für ein Gerät

andy@fedora:~$ lspci -s 01:00.0 -k

01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)
    kernel driver in use: nvidia
    kernel modules: nouveau, nvidia_drm, nvidia

# Kommentar: Aktiver Treiber und alternative Module

Merksatz: Erst erkennen, dann zuordnen. Mit lspci -k prüfst du in einem Schritt Gerät → aktiver Treiber → alternative Module.

USB-Geräte mit lsusb

lsusb zeigt Geräte am USB-Bus (Eingabegeräte, Sticks, Adapter). -v macht Ausgaben detailliert, -d filtert nach Vendor:Product, -t zeigt eine Baumansicht inkl. Treibern.

# Übersicht der USB-Geräte

andy@fedora:~$ lsusb

Bus 001 Device 029: ID 1781:0c9f Multiple Vendors USBtiny
Bus 001 Device 028: ID 093a:2521 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 020: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter

# Kommentar: Jede Zeile zeigt Bus/Device, Vendor-ID:Product-ID und Hersteller/Produkt

# Detaillierte Infos zu einem bestimmten USB-Gerät (Vendor:Product)

andy@fedora:~$ lsusb -v -d 1781:0c9f
Device Descriptor:
  idVendor           0x1781 Multiple Vendors
  idProduct          0x0c9f USBtiny
  ...

# Kommentar: Tiefe Geräte-Deskriptoren inkl. Klassen und Konfigurationen

# USB-Gerätehierarchie als Baum inkl. Treiber

andy@fedora:~$ lsusb -t

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 3: Dev 20, If 0, Class=Wireless, Driver=btusb, 12M

# Kommentar: "Driver=..." zeigt das zugeordnete Kernelmodul (z. B. btusb)

Definition: Kernelmodul/Treiber ist eine ladbare Komponente des Kernels, die ein Gerät steuert. Sie kann im Hauptkernel enthalten sein oder separat ausgeliefert werden.

Kernelmodule verwalten: lsmod, modprobe, modinfo, Blacklist

Die kmod-Werkzeuge sind der Alltagssatz für das Arbeiten mit Modulen: Anzeigen, Laden/Entladen, Parameter prüfen.

# Geladene Module anzeigen (Name, Speicherbedarf, Abhängigkeiten)

andy@fedora:~$ lsmod | head

Module                  Size  Used by
kvm_intel             138528  0
kvm                   421021  1 kvm_intel
snd_usb_audio         149112  2

# Kommentar: "Used by" listet abhängige Module/Anzahl der Nutzer

# Abhängigkeitskette eines Soundmoduls grepfiltern

andy@fedora:~$ lsmod | fgrep -i snd_hda_intel

snd_hda_intel          42658  5
snd_hda_codec         155748  3 snd_hda_codec_hdmi,snd_hda_codec_via,snd_hda_intel
snd_pcm                81999  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel

# Kommentar: Erkennbar: mehrere Module hängen voneinander ab

# Modul (und verkettete Abhängigkeiten) entladen

andy@fedora:~$ sudo modprobe -r snd-hda-intel

# Kommentar: Entlädt snd-hda-intel; schlägt fehl, wenn es "in use" ist (von Prozess belegt)

# Verfügbare Parameter eines Moduls anzeigen (nur Parameter)

andy@fedora:~$ modinfo -p nouveau

modeset:enable driver (default: auto, 0 = disabled, 1 = enabled, 2 = headless) (int)
...

# Kommentar: Hilfreich, um z. B. Kernel-Modus-Setting (KMS) zu beeinflussen

# Beispiel: KMS für nouveau deaktivieren (persistent)

andy@fedora:~$ echo 'options nouveau modeset=0' | sudo tee /etc/modprobe.d/nouveau.conf

# Kommentar: Setzt einen Modulparameter dauerhaft

# Beispiel: Modul "nouveau" pauschal nicht laden (z. B. bei proprietärem nvidia)

andy@fedora:~$ echo 'blacklist nouveau' | sudo tee -a /etc/modprobe.d/blacklist.conf

# Kommentar: Verhindert Autoload des Moduls

Merksatz: „in use“ schlägt Entladen fehl. Ursache ist fast immer ein aktiver Prozess/Abhängigkeit – erst Nutzer stoppen, dann modprobe -r.

Pseudo-Dateisysteme /proc und /sys: Der Blick ins Kernel-Gedächtnis

/proc und /sys sind RAM-basierte Pseudo-Dateisysteme. Sie persistieren nicht, enthalten aber live Kernel-/Hardware-Infos. /proc spiegelt v. a. Datenstrukturen (Prozesse, CPU, IRQ), /sys bietet Geräte- und Treiberansichten (SysFS), die u. a. udev nutzt.

# CPU-Infos prüfen (Modell, Flags, Bugs/Meltdown-Hinweis)

andy@fedora:~$ grep -E 'model name|bugs' /proc/cpuinfo | head -n 6

model name  : Intel(R) Core(TM) ...
bugs        : spectre_v1 spectre_v2 meltdown

# Kommentar: "bugs" listet bekannte Schwachstellen wie cpu_meltdown

# Interrupt-Statistik und IO-Ports einsehen

andy@fedora:~$ head -n 5 /proc/interrupts
           CPU0       CPU1
  24:    123456          0   IO-APIC   24-fasteoi   eth0

andy@fedora:~$ head -n 10 /proc/ioports
0000-001f : dma1

# Kommentar: Diagnose von Gerätezuteilungen (IRQs, IO-Ports)

/sys und udev: Bei Geräteereignissen (Hotplug) legt udev anhand von Regeln (/etc/udev/rules.d/) dynamisch Gerätedateien in /dev an – heute auch für Coldplug beim Systemstart.

Definition: Hotplug = Erkennung/Konfiguration im laufenden Betrieb (z. B. USB einstecken). Coldplug = Erkennung beim Boot.

Gerätedateien unter /dev und Blockgeräte-Namen

/dev enthält Gerätedateien. Für Blockgeräte (Massenspeicher) sind heute fast alle Datenträger SCSI-artig als sd* benannt – unabhängig von echter Hardware. Ausnahmen sind SD-Karten (/dev/mmcblk0p1) und NVMe-SSDs (/dev/nvme0n1p1).

• Erste erkannte Platte: /dev/sda, Partitionen: /dev/sda1, /dev/sda2, …
• Zweite Platte: /dev/sdb1, /dev/sdb2, …
• NVMe: /dev/nvme0n1p1, /dev/nvme0n1p2, …
• SD-Karte: /dev/mmcblk0p1, /dev/mmcblk0p2, …

# Blockgeräte-Überblick (Kurzform)

andy@fedora:~$ lsblk

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda           8:0    0  477G  0 disk
├─sda1        8:1    0  512M  0 part /boot
└─sda2        8:2    0  476G  0 part /
nvme0n1     259:0    0  953G  0 disk
└─nvme0n1p1 259:1    0  953G  0 part /data

# Kommentar: Einheitlicher Blick auf sd*, nvme*, mmcblk*

Fragen aus den LPI Lernmaterialien (geführt & offen) – didaktisch beantwortet

1. OS bootet nach Einbau einer zweiten SATA-Platte nicht. Was ist die Ursache? → Die Bootreihenfolge im BIOS/UEFI ist falsch; Gerät mit Bootloader steht nicht an erster Stelle.
2. Grafikkarte prüfen, ohne Gehäuse zu öffnen? → Mit lspci (ggf. -k/-v) die vom OS erkannten Spezifikationen anzeigen.
3. Zu 03:00.0 RAID bus controller … das Kernelmodul finden? → lspci -s 03:00.0 -v oder lspci -s 03:00.0 -k ausführen.
4. modprobe -r bluetooth meldet „in use“. Wahrscheinlichste Ursache? → Ein laufender Prozess nutzt das Modul; erst Prozess/Abhängigkeiten stoppen.
5. Ältere x86-Server booten nicht ohne Tastatur. Abhilfe? → In der BIOS/UEFI-Option die Sperre „Halt on Keyboard Error/No Keyboard“ deaktivieren.
6. Warum gibt es auf ARM (z. B. Raspberry Pi) oft kein lspci? → ARM-Boards besitzen keinen PCI-Bus; daher ist lspci nicht erforderlich.
7. Router mit Linux, externe USB-Festplatte, keine weiteren Blockgeräte – wie heißt das Device in /dev? → /dev/sda (USB-Platten werden wie SCSI/SATA behandelt).
8. Meltdown-Anfälligkeit prüfen? → In /proc/cpuinfo die Zeile bugs: prüfen (z. B. cpu_meltdown).

Zusammenfassung

• Firmware (BIOS/UEFI): Geräte aktivieren/deaktivieren, Bootreihenfolge korrekt setzen, CPU/RAM-Optionen gezielt nutzen.
• Erkennung & Treiber: lspci (PCI) und lsusb (USB) sind die Ersthelfer; mit -k Treiberbezug prüfen.
• Kernelmodule: lsmod zeigt geladene Module; modprobe lädt/entlädt; modinfo liefert Parameter; Blacklisting unter /etc/modprobe.d/*.conf.
• Pseudo-FS: /proc und /sys sind Live-Sichten in Kernel/Hardware; udev erzeugt dynamisch /dev-Einträge.
• Blockgeräte-Namen: Einheitlich sd*, Ausnahmen NVMe (nvme0n1pX) und mmcblk (SD-Karten).
• Diagnose-Praxis: Erst erkennen (Bus), dann Treiberzuordnung prüfen, dann Module/Parameter/Blacklists gezielt einsetzen.

Wissensprüfung mit Multiple-Choice-Fragen

1. Welche Angabe zeigt den aktiven Treiber für ein PCI-Gerät?
   • A) lspci -vv
   • B) lspci -k
   • C) lsusb -t
   • D) modinfo
2. Welche Datei enthält Live-Informationen über CPU-Bugs wie Meltdown?
   • A) /etc/cpuinfo
   • B) /sys/cpu/bugs
   • C) /proc/cpuinfo
   • D) /var/log/dmesg
3. Warum schlägt modprobe -r <modul> häufig fehl?
   • A) Falsche Kernelversion
   • B) Modul signiert
   • C) Modul ist „in use“
   • D) Kein Eintrag in /etc/modules
4. Welche Aussage zu udev ist korrekt?
   • A) Erzeugt statische Nodes beim Installieren
   • B) Legt Gerätedateien dynamisch in /dev an
   • C) Setzt nur Netzwerknamen
   • D) Arbeitet ausschließlich bei Hotplug, nicht bei Coldplug
5. Wie filtert man ein bestimmtes USB-Gerät nach Vendor:Product?
   • A) lsusb -s
   • B) lsusb -d
   • C) lsusb -k
   • D) lsusb -p
6. Welche Namenskonvention gilt für NVMe-Partitionen?
7. Wo werden persistente Moduloptionen empfohlen abgelegt?
   • A) /boot/grub/grub.cfg
   • B) /etc/modprobe.d/*.conf
   • C) /etc/modules
   • D) /usr/lib/modules.conf
8. Welcher Befehl zeigt geladene Module mit ihren Abhängigkeiten?
   • A) modinfo
   • B) lsmod
   • C) insmod
   • D) depmod -a
9. Wozu dient lspci -s 03:00.0 -v konkret?
   • A) Alle PCI-Geräte sehr ausführlich
   • B) Nur Gerät 03:00.0 detailliert
   • C) Nur Kernelmodule anzeigen
   • D) Nur Klassenfilter „Storage“
10. Was ist der wichtigste Firmware-Schritt nach Einbau einer zweiten Platte, wenn das System nicht mehr bootet?
    • A) C-States deaktivieren
    • B) RAM-XMP laden
    • C) Secure Boot ausschalten
    • D) Bootreihenfolge korrekt einstellen

Antworten mit Begründung

1. B → -k zeigt „kernel driver in use“ und mögliche Module.
2. C → /proc/cpuinfo enthält je CPU eine bugs:-Zeile.
3. C → Module lassen sich nicht entladen, solange sie genutzt werden.
4. B → udev erstellt dynamisch Gerätedateien; es verarbeitet Hot- und Coldplug.
5. B → -d vendor:product filtert gezielt ein USB-Gerät.
6. D → NVMe: nvmeXnYpZ, z. B. /dev/nvme0n1p1.
7. B → Persistente Optionen/Blacklist in /etc/modprobe.d/*.conf.
8. B → lsmod listet geladene Module und „Used by“.
9. B → -s wählt die Adresse, -v liefert Details zu genau diesem Gerät.
10. D → Das Boot-Device muss an Position 1 stehen.