Technik

System und Booten

Das Linux-System unter der Haube und der Startvorgang unsere Linux-Distributionen im Einzelnen.

Bootvorgang

Eine exemplarische Darstellung inklusive Erläuterungen zu Linux-Bootvorgängen:

  1. Einschalten (Reset, POST - Power On Self Test)

  2. BIOS / UEFI mit Bootsequenz (Startreihenfolge; engl: Bootsequence / Startmedien)

    Übersicht Bootmedien:

    USB (Sticks / HD), Netzwerk (PXE / TFTP), Festplatten / SSDs, Optische Medien (CD/DVD)

  3. MBR lesen - Masterbootrecord mit Partitionstabelle (Nutzung von UEFI mit GPT ist anders: wir benötigen eine spezielle ESP - EFI System Partition mit Fat32/vfat Dateisystem)

    maximal 4 Partitionen: 4 Primäre oder 3 Primäre und 1 Erweiterte

    Hinweis:

    für das Booten von HDs > 2,2 TB wird UEFI mit GPT (GUID Partition Table) benötigt

    Erinnerung / Tipp: (ggf. nach Fehlschlag Parallelinstalation zu Windows)

    Win-Systeme benötigen als Bootstandard eine Aktive primäre Partition inkl. eines „sauberen“ MBR (Generischer MBR)

    → Reparatur-Tipp zum MBR: mit Win-DVD:

    bootrec /fixmbr (bzw. bootrec /fixboot für Bootsektor) in Reparaturkonsole

    Darstellung zu Partitionierungen:

    exemplarische Szenarios für Parallelinstallation mit Windows - Linktipp MS

  4. Linux-Bootmanager: GRUB2 (Übersicht Bootmanager und Technik Bootmanager folgt)

    Vorgänger / Bootalternativen: GRUB (Version 1), LILO (Linux Loader)

  5. Kernel und initrd (klassisch: init Ramdisk - initrd laden; Anm.: die Ramdisk ist optional)

    Symlinks bei openSUSE: vmlinux (komprimierter Kernel), initrd

    Analyse Kernel-Version: uname -a bzw. uname -r

  6. systemd (Erster Prozess mit ID „1“) (früher: SysVInit mit Urprozess init)

Anm.: moderne Linuxe benutzen nahezu ausschließlich systemd („abwärtskompatibel“ zu init).

Ubuntu hatte zwischenzeitlich upstart als init-Lösung (Ubuntu nutzt aber auch systemd ab Ubuntu 16.04 LTS)

Gründe für Abkehr von SysVinit zu alternativen init-Techiken:

  • Effizienter

  • Parallel arbeitend

  • Abhängigkeiten von Prozessen cleverer lösend

  • moderne Tools (journalctl, systemctl, …)

  • moderne Problemanalysen und Loggings

Tipp zur Startanalyse:

systemd-analyze blame (erzählt in ms - Millisekunden - die Geschichte der „Starts“)

oder auch:

systemd-analyze plot > grafische-analyse.svg (erstellt SVG-Grafik)

Systemd Analyse mit Plot

Systemd Analyse mit Plot

Technisch: systemd arbeitet mit Targets (z.B. graphical.target, multi-user.target) statt den klassischen Runleveln

Befehle:

init , telinit , runlevel , systemctl (statt sysctl bei init-Technik), journalctl (für Analyse/Logging)

Bootmanager GRUB2

Lilo (sehr alt und unflexibel), GRUB (Version 1 bzw. GRUB Legacy - Erläuterungen auf openSUSE Portal)

aktuell: GRUB2 (technisch extrem zu GRUB abweichend und mächtiger!)

GRUB-Ordner: /boot/grub2

GRUB konfigurieren mit /etc/default/grub und den /etc/grub.d/ Dateien

GRUB aktualisieren mit Befehl: grub2-mkconfig -o /boot/grub2/grub.cfg (siehe z.B. Suse)

Hinweis: manche Distros (siehe Debian, Ubuntu/s) haben ein kleines Hilfsskript namens update-grub, welches diese Syntax ersetzt!

Grub2-Techniken bedürfen genauer Recherche und Betrachtungen!

Hinweis zum Bootloader mittels YaST - System - Bootloader mögliche Speicherorte für GRUB: MBR (Master Boot Record), Bootsektor einer Partition

Erläuterungen zu GRUB2: Link Ubuntuusers-Wiki (Achtung „Ubuntu-Brille“),

Linupedia-Artikel

Runlevel

Wir wollen jetzt das Prozessmanagement unter Linux besser verstehen. Hierzu wieder ein Scribble aus einem meiner Seminare zum Thema:

SysVinit vs. SystemD

SysVinit vs. SystemD

Erinnerung: Runlevel ist ein klassischer Begriff von SysVinit / Init; neuere systemd-Technik arbeitet mit Begriff Targets

Beispielhafter Online-Beitrag zum Thema SystemD: Grundlagenartikel systemd von Heise.de

Die klassischen Runlevel als tabellarische Übersicht:

  • 0 - Stop/Halt

  • 1 / s / S - Single User (zu Wartungsarbeiten)

  • 2 - Multi-User (mit und ohne Netzwerk - je nach Distribution)

  • 3 - Multi-User und Netzwerk (klassische Serverumgebung LAMP und Co)

  • 4 - unbenutzt

  • 5 - Multi-User, Netzwerk, X-Server (heute mit Desktops wie KDE oder Gnome)

  • 6 - Reboot

Klassischer Ordner für Skripte /etc/init.d mit Unterordnern für die Runlevel

Momentaufnahme openSUSE 42.1 Runlevel 5:

/etc/init.d/rc5.d beinhaltet noch 3 Dienste mit entsprechenden (S Start - K Stop/Kill) Skripten

hier: avahi-daemon, postfix, udev

Diese init-Skripte arbeiten dann mit Parametern start | stop | restart | reload

Momentaufnahme openSUSE 42.3:

Keinerlei Skripte mehr in den Runlevel-Unterordnern /etc/init.d/rc0.d bis rc6.d (Anm.: nur noch in ./boot.d für AppArmor)

Anm.: Red Hat (und Co) arbeiten mit /etc/rc.d als Haupt-Skriptordner - siehe auch SymLink rc.d auf init.d bei openSUSE.

Hinweis

Zum Zeitpunkt Juli 2020 ist nur noch CentOS 6 / RHEL 6 mit den klassischen Runleveln nach SysVinit am Start.

Und CentOS 6 ist für Ende November 2020 abgekündigt!

Linux-Alternative mit SysVinit: antiX Linux (basierend auf Debian)

Aus dem Massenmarkt verschwindet SysVinit (Runlevel) also gerade und wir sollten uns dem am weitest verbreiteten Prozessmanagement bei den Linux-Distros zuwenden - dem SystemD.

SystemD

(Reference Manual Chapter: The systemd Daemon)

Die SysVinit-Technik wird durch systemd-Technik ersetzt bei Beibehaltung der alten (abwärtskompatiblen) init-Skript-Techniken und Ordnerstrukturen nach SysVinit.

Dadurch werden die Start-/Stoppmechanismen durch teils gleichzeitiges Abarbeiten von Aufrufen beschleunigt - siehe früher S- und K-Links in Runlevel-Ordnern alle mit gleicher Nummerierung (hier 50 - S50… / K50…)

Wir nehmen nur noch Skripte, die nicht sauber mit systemd arbeiten können - oder noch nicht umgeschrieben worden sind. Anm.: kann man kaum noch in den alten Runlevel-Ordnern finden!

Hinweis: seit openSUSE 42.3 und folgende openSUSE: es befinden sich nur im „allgemeinen“ Bootordner /etc/init.d/boot.d noch Start-/Stop-Skripte für die AppArmor-Technik - alles Andere mit SystemD-Techniken sauber umgesetzt.

Abwärtskompatible Runlevel-Tools lassen sich immer noch nutzen:

runlevel , init X (X = S, 0, 1, 3, 5, 6) , shutdown , halt , reboot

Wichtigste SystemD-Befehle:

  • systemctl - Manager für alle SystemD-Units: Dienste (.service), Timer (.timer) oder Targets (.target)

  • systemd-... - Tools für die SystemD-Analyze (siehe systemd-analyze) und Co

  • journalctl - Tool für die Auswertung und den Zugriff auf die SystemD-Journale

Ein paar beispielhafte Aufrufe:

  • systemctl bzw. systemctl list-units - alle SystemD Units auflisten

  • systemctl list-units --type service --state running - alle laufende Dienste (.service) auflisten

  • journalctl -u ssh - Journal für Unit SSH (bzw. SSHD) aufrufen

Hinweis zu Systemd-Journal: ein eigener Service - mit eigener Konfiguration (siehe /etc/systemd/journald.conf - Storage). Per Default sind die Journale der Dienste nicht persistent - sie können also nur in einer Linux-Session genutzt werden.

Hier mal eine ausführlichere Gegenüberstellung von SysVinit vs. SystemD:

SysVinit

systemd

Bemerkungen

Runlevel

Targets

Bezeichungen für gewünschte Bootumgebung

/etc/inittab

keine /etc/inittab (!!) in Ordnern diverse Dateien: (z.B.) /usr/lib/systemd/system

Konfigurationsdatei(en)

runlevel init telinit sysctl chkkonfig

runlevel (wegen Kompatibilität) init (w. K.) telinit (w. K.) systemctl journalctl systemd- (z.B. systemd-analyze blame)

Tools

service sshd status

systemctl status sshd.service

Status openSSH Server

service sshd start

systemctl start sshd.service

Starten openSSH Server

service sshd stop

systemctl stop sshd.service

Stoppen openSSH Server

service sshd restart

systemctl restart sshd.service

Restarten openSSH Server

service sshd reload

systemctl reload sshd.service

Konfiguration openSSH Server neu laden

chkconfig sshd on

systemctl enable sshd.service

openSSH im Runlevel/Target aktivieren

chkconfig sshd off

systemctl disable sshd.service

openSSH im Runlevel/Target deaktivieren

Man. Suche in Logdateien

journalctl -u sshd.service

Journal für openSSH (als root)

chkconfig –list

systemctl list-unit-files systemctl list-dependencies multi-user-target

Übersicht Dienste in Runleveln/im Target

init 3 (oder) telinit 3

systemctl isolate runlevel3.target systemctl isolate multi-user.target

in Runlevel 3 wechseln bzw. in multi-user.target

init 5 (oder) telinit 5

systemctl isolate runlevel5.target systemctl isolate graphical.target

in Runlevel 5 wechseln bzw. in graphical.target

systemctl isolate default.target

in Standard-Runlevel wechseln bzw. in default.target

init 0 (oder) telinit 0 shutdown -h poweroff

systemctl isolate runlevel0.target systemctl isolate poweroff.target shutdown -h poweroff

Rechner ausschalten

init 6 (oder) telinit 6 shutdown -r reboot

systemctl isolate runlevel6.target systemctl isolate reboot.target shutdown -r reboot

Rechner rebooten

Tabelle zu SysVinit vs. systemd (siehe auch Link Fedoraprojekt (Link)

Praktische Übungen: systemctl start | stop | enable | disable

Partitionierungen

Klassische Gerätename:

  • /dev/hda (für die alten EIDE Controller Geräte - dann /dev/hdb, ... )

  • /dev/sda (für den ersten Datenträger SCSI, SATA, USB - dann /dev/sdb, ... )

Die eingerichteten Partitionen erhalten Nummern: /dev/sda1, /dev/sda2, ...

Anm. bei MBR ist dann /dev/sda5 als erste logische Partition (log.LW) in einer erweiterten Partition!

Wir begannen also mit Bezeichnern für EIDE-Geräte: /dev/hda (Kürzel HD klassisch für HardDisk). Die sda-Bezeichner wurden dann für SCSI, SATA und heute auch USB-Medien eingeführt.

Es gibt aber auch Bezeichner /dev/vda (Virtuelle Datenträger) oder /dev/ nvme0n1 (Solid State Modul per NVme angeschlossen).

Alternativ: Verwendung von Geräten-ID-Bezeichnern (siehe später GRUB oder auch /etc/fstab )

Aktuelle Distributionen nutzen sehr häufig diese UUID als eindeutige Bezeichner für die Partitionen/Datenträgerbereiche.

Vorteil UUID: dann werden die Datenträgerbereiche auch sauber gemountet, wenn diese mal statt auf /dev/sda2 auf /dev/sdb1 liegen sollten!

Eine Einstimmung auf die Dateisysteme, mit denn man dann die Partitionen formatiert - eine kurze Übersicht:

  • ext2

  • ext3 (Anm.: ext2 mit journaling FS)

  • ext4

  • xfs (beherrscht gleich ACL - erweiterte Berechtigungen)

  • BtrFS (kann Snapshots)

  • ReiserFS

  • ZFS (wird aktuell als BtrFS-Alternative von Ubuntu gepuscht - Lizenzprobleme!? beachten)

Und die Microsoft-Dateisystem können wir mit Linux natürlich auch nutzen:

  • Fat16

  • Fat32 (VFat)

  • NTFS

Hinweis

Die folgenden Beispiele für openSUSE - wir nutzen aber auch immer die alternativen Distros!

Hier: Abweichung von Install-Vorschlag aus der Standard-Setup-Install-Routine von openSUSE (siehe YaST), denn openSUSE würde gerne

  • BtrFs als Dateisystem für das System ( Ordner / bzw. /boot) und

  • xfs für die Daten (siehe /home )

vorschlagen.

Aber wir wollen (erst einmal) BtrFs vermeiden und auch zu Übungszwecken die „klassischen“ Ext-Dateisysteme Ext4 nutzen!

Plan für eine Einteilung/Partitionierung:

Partitionierungsvorschlag

Partitionierungsvorschlag

Beispiel für Installation mit folgenden Partitionen: 3 primäre Partitionen /dev/sda1 bis /dev/sda3 in einem MBR-basierten System.

Mount

Nutzung

Eigenschaften

/

Root-Partition

Größe: 70 GiB Gerät: /dev/sda1 (primäre Partition) Filesystem: ext4

/home

Benutzerverzeichnisse

Größe: 50 GiB Gerät: /dev/sda2 (primäre Partition) Filesystem: ext4

swap

Auslagerungspartition, VMM Virtual Memory Management

Größe: 7 GiB Gerät: /dev/sda3 (primäre Partition) Filesystem: swap

Wichtig: bei UEFI bitte als erste Partition: 512 MiB / vFat / ESP

Die Größen der Bereiche orientieren sich hier an den typischen VHDX-Platten-Größen beim Hyper-V (127 GB) und müssen in der Praxis natürlich nach eigenenen Ansprüchen optimiert werden.

Hinweis

Für die flexible Nutzung von Datenträgern nutzen wir später LVM (Logical Volume Management).

Erste Analyse und Tools rund um unsere Partitionen mit den folgenden Tools:

lsblk, blkid, fdisk -l /dev/sda bzw. gdisk (für UEFI/GPT) , cfdisk

Falls es Probleme bei Darstellungen (z.B. Umlaute und Sonderzeichen werden falsch dargestellt) mit Konsolentool cdisk geben sollte, kann man sich mit env behelfen:

Lösung: env LANG=C cfdisk

Erklärung: in Umgebung des auszuführenden Programms (env) wird als Sprache C eingestellt, was der Sprache/Kodierung des Programms entspricht (hier „englisch“).

Mounten

Das Einbinden von Datenspeichern/Datenträgern und anderen Komponenten (siehe virtuelle Systeme) in das System.

Befehle: (Geräte/Datenträger werden automatisch erkannt und per Klick gemountet)

mount (der eigentliche Hauptbefehl zum Einbinden von Laufwerken/Mounten)

umount (Mounten beenden)

Hinweis: heutzutage geschieht das Mounten bei allen Wechselmedien (optische, USB) durch den User (technisch: im Userspace - siehe: FUSE). Auch für spezielle Anbindungen von Datenspeichern per SSH existieren solche Tools/Vorgehensweisen (z.B. sshfs).

Aktuellen Mount-Status anzeigen:

mount ohne Parameter (oder natürlich alternativ:

cat /etc/mtab

cat /etc/mtab | grep ^/dev/ (nur die Einträge mit /dev am Anfang - also Geräte)

Anweisungen für das System zum Mounten beim Systemstart:

cat /etc/fstab

Darstellung der Techniken und Vorgehensweisen mit einem USB-StickTools:

fdisk , mkfs.ext4 , mount

Alle Analysen wieder mit Hilfe von

lsblk , blkid , fdisk -l , cfdisk

… tbc …