Project

General

Profile

Master Praktikum: Bausteine und Konzepte eines Linux-Remote-Boots

Inhalt

Aufgabe

Es wird ein Skript bzw. Dracut-Modul benötigt, dass ein initramfs basierend auf systemd baut. Das resultierende initramfs muss Netzwerk-Support bereitstellen, ein dnbd3 Blockdevice mounten können und einen "switch_root" auf das zuvor gemountete Dateisystem umsetzen. Das Framework sollte möglichst Distributionsunabhängig konstruiert sein. Es soll bereits vor dem "switch_root", bevor das eigentliche Zielsystem im Root-Verzeichnis eingebunden wird, systemd als init-System nutzen. Die Kernaufgabe eine initramfs ist es alle nötigen Anwendungen bereitzustellen, die benötigt werden, um dass finale Zielsystem einzubinden. In dieser konkreten Aufgabenstellung muss, dass initramfs ein nicht schreibbares Blockgerät eingebunden werden und eine schreibbare Zwischenshicht (Overlayfilesystem) zusätzlich eingebunden werden.

Mögliche Technologien für das Overlaykonzept

  • Dateibasierte Overlay-FS (Union-FS, Alternate-Union-FS, Overlay-FS)
    - Erfordert das patchen von Kerneln (Union-FS, Alternate-Union-FS)
    - Nicht im standard Linux-Kernel enthalten (Union-FS, Alternate-Union-FS)
    - Lässt sich nicht über das Root-System legen (Overlay-FS).
    - Bei wenigen Änderungen in einer großen Datei muss komplette Datei in der schreibbaren Schicht gespeichert werden.
  • Blockorientierte Overlay-FS (Network-Block-Device, DNBD3, Qemu-Copy-On-Write-Image, device-mapper)
    - NBD Treiber und device-mapper sind im Linux-Kernel enhalten
    - Weniger Netzwerkverkehr nötig, da nur geänderte Blöcke übertragen werden müssen statt ganze Dateien zu kopieren.
    - DNBD3 hat Failover-Strategien und verzichtet auf komplexe Strategien zum Schreiben in geänderte Blöcke über das Netzwerk
    - Das verfügbare qcow2-Format oder der Device-Mapper bietet eine Technologie, um blockorientiert Änderungen in einer zusätzlichen Dateisystemschicht zu speichern.

Verwendete Technologien

Zielablauf

Der generelle Ablauf vor bzw. während des Ladens des initramfs und dessen Minilinux-System:

  1. Boot PXE
  1. Laden des initramfs images
  2. Laden des Kernels
  1. Ausführen des iniramfs
  1. Ausführen von Systemd
  1. Bereitstellen aller benötigten Dienste und Hardware (Netzwerk hochbringen)
  2. Mounten des finalen Dateisystems als Wurzel
  3. Wechsel (switch_root) in die finale Distribution
  4. Starten / Weiterausführen von Systemd als Init-System

Quickstart

1. Aufsetzen einer Standard UEFI-ArchLinux-Distribution

Führe in einer UEFI-kompatiblen ArchLinux Live-Umgebung (z.B. VirtualBox Instanz mit eingehängter ArchLinux LiveCD und aktiviertem EFI-Support) folgenden Befehl aus (Achtung die erste gefundene Festplatte wird überschrieben).

wget https://raw.githubusercontent.com/archInstall/archInstall/master/archInstall.sh -O archInstall.sh && chmod +x archInstall.sh && ./archInstall.sh --output-system /dev/sda --verbose --debug

2. Erstellen eines Dracut-Initramfs mit Systemd

In der Linux Distribution, die als Template System dienen soll, sollte folgender Befehl ausgeführt werden:

wget http://git.openslx.org/openslx-ng/systemd-init.git/plain/builder/build-initramfs.sh -O build-initramfs.sh && chmod +x ./build-initramfs.sh && ./build-initramfs.sh --verbose --use-systemd-in-initramfs

Das Skript überprüft, ob alle benötigten Abhängigkeiten vorhanden sind, um ein rudimentäres initramfs zu bauen. Sollten nicht zwingend benötigte optionale Abhängigkeiten nicht gefunden werden Warnungen ausgegeben. Weitere Optionen, wie z.B. Ziel des initramfs-image oder das Hinzufügen zusätzlicher Dracut-Module, können durch Kommando-Zeilen-Argumente konfiguriert werden (Siehe auch ./build-initramfs.sh --help).

3. Das Templatesystem in eine Datei aus VirtualBox exportieren

Ersetze "NAME" mit dem Namen der virtuallen Maschiene aus VirtualBox und "ZIEL" mit dem Pfad an dem das verpackte Template-System gespeichert werden soll.

VBoxManage clonehd --format RAW ZIEL NAME

4. Erstellen einer OpenSLX Konfigurationsdatei

SLX_CONFIGURATION_LOCATION='/opt/openslx/'
SLX_DNBD3_SERVERS='132.230.4.201,132.230.4.202,10.0.2.2'
SLX_DNBD3_RID='0'
SLX_DNBD3_DEVICE='/dev/dnbd0'
SLX_DNBD3_IMAGE='archLinux/archLinux'
SLX_SYSTEM_PARTITION_IDENTIFIER='system'
SLX_TMP_PARTITION_IDENTIFIER=''
SLX_WRITABLE_DEVICE_IDENTIFIER=''
SLX_WRITABLE_DEVICE_PERSISTENT='yes'
# if empty will use all available ram
SLX_RAMDISK_SIZE=''
SLX_MOUNT_ROOT_OPTIONS='-o subvol=root'

5. VirtualBox für PXE konfigurieren

Virtualbox stellt einen eingebauten TFTP-Server zur Verfügung. Damit dieser funktioniert, muss folgendes Verzeichnis angelegt werden.

~/.VirtualBox/TFTP

In dieses Verzeichnis muss nun eine PXE-Installation gelegt werden. Zu beachten ist, dass die Boot-Datei (Endung .pxe) in "<VM-Name>.pxe" umbenannt wird. Eine Beispiel PXE liegt im Repository .

Jetzt können Kernel und Initramfs aus Punkt (2) hier hinein kopiert werden.

Die PXE-Konfiguration kann unter ~/.VirtualBox/TFTP/pxelinux.cfg/default angepasst werden. Wichtig sind hierbei die Kernel-Commandline-Parameter:
  • slxsrv
    Hier sollte der Webserver erreichbar sein (siehe Punkt (7)). Unter Virtualbox ist der Host standardmäßig unter 10.0.2.2 erreichbar.
  • slxbase
    Unterverzeichnis auf dem Webserver, unter der die entsprechende openSLX-Konfiguration liegt.
  • Kernel und initrd anpassen
DEFAULT menu.c32
TIMEOUT 300
ALLOWOPTIONS 0
PROMPT 0

MENU TITLE PXE-Boot

LABEL arch
MENU LABEL ^archLinux
KERNEL /vmlinuz-linux
APPEND initrd=/initramfs.img acpi_osi="!Windows 2012" ip=10.0.2.15::10.0.2.2:255.255.255.0 slxsrv=10.0.2.2:80,10.0.2.2:8080,10.0.2.2:8008,10.0.2.2:8090,10.0.2.2:8280,10.0.2.2:8888 slxbase=archLinux/
SYSAPPEND 2

LABEL arch
MENU LABEL ^archLinux debug
KERNEL /vmlinuz-linux
APPEND initrd=/initramfs.img loglevel=2 acpi_osi="!Windows 2012" rd.info rd.break=pre-pivot rd.break=pre-shutdown ip=10.0.2.15::10.0.2.2:255.255.255.0 slxsrv=10.0.2.2:80,10.0.2.2:8080,10.0.2.2:8008,10.0.2.2:8090,10.0.2.2:8280,10.0.2.2:8888 slxbase=archLinux/ systemd.log_level=info systemd.journald.forward_to_console=1
SYSAPPEND 2

6. Starten eines HTTP-Servers

Für die obige Beispiel-Konfiguration passt folgende Dateistruktur im Web-Server-Wurzelverzeichnis:

Web-Server-Wurzelverzeichnis
└──archLinux
   ├── archLinux.r10
   ├── config
   ├── initramfs-test.img
   └── vmlinuz-linux

Jetzt noch den Webserver starten. Bei einer installierten Python3-Version kann z.b. auf folgende Weise schnell ein einfach Web-File-Server gestartet werden:

python -m http.server

oder mit python2:

python -m SimpleHTTPServer

7. Starten des DNBD3-Servers

Bei unserer Beispielkonfiguration aus Punkt 6. sollte der DNBD3-Server mit dem gleichen Server-Wurzelverzeichnis gestartet werden wie unsere Webserver:

Pfad/zum/dnbd3-server --nodaemon --config Pfad/zum/dnbd3/config/ordner

Der entsprechende Konfigurationsordner sollte wie folgt aussehen:

Pfad/zum/dnbd3/config/ordner
├── alt-servers
└── server.conf

alt-servers kann zunächst erstmal leer sein.

server.conf beinhaltet:

[dnbd3]
; relative root directory for images, ending in .r[1-9][0-9]*
basePath=Pfad/zum/Web-Server-Wurzelverzeichnis
; artificial connection delay for connecting servers
serverPenalty=100000
; artificial connection delay for connecting clients
clientPenalty=0
; is this server a proxy? if true, requests for non-existing images will be relayed to known alt-servers
isProxy=true
; if proxy is true and an image is incomplete, should idle bandwidth be used to replicate missing blocks?
backgroundReplication=true
; timeout in ms for send/recv on connections to uplink servers (used for replication)
uplinkTimeout=1250
; timeout in ms for send/recv on connections to clients (using an image on this server)
clientTimeout=15000

; Log related config
[logging]
; log file path and name
; protip: use SIGUSR2 to reopen log file
file=./dnbd3.log
; which type of messages to log to file
fileMask=ERROR WARNING MINOR INFO DEBUG1
; which to log to console (stdout)
consoleMask=ERROR WARNING MINOR INFO
; Valid types (warning: specifying invalid types will not yield an error!)
; ERROR     Fatal error, server will terminate
; WARNING   Major issue, something is broken but keep running
; MINOR     Minor issue, more of a hickup than serious problem
; INFO      Informational message
; DEBUG1    Debug information, used for medium verbosity
; DEBUG2    Used for debug messages that would show up a lot

Aufsetzen einer Test-Arbeitsumgebung

1. Aufsetzen einer Standard UEFI-Linux-Distribution (Beispiel ArchLinux, Ubuntu, CentOs7)

Führe in einer UEFI-kompatiblen ArchLinux Live-Umgebung (z.B. VirtualBox Instanz mit eingehängter ArchLinux LiveCD und aktiviertem EFI-Support) folgenden Befehl aus (Achtung die erste gefundene Festplatte wird überschrieben).

wget https://raw.githubusercontent.com/archInstall/archInstall/master/archInstall.sh -O archInstall.sh && chmod +x archInstall.sh && ./archInstall.sh --output-system /dev/sda --verbose --debug

Um sich das Gast-System unter VirtualBox einzurichten empfiehlt sich folgende Quelle: https://wiki.archlinux.org/index.php/VirtualBox

Bei Ubuntu oder CentOs7 müssen entsprechend ähnliche Schritte durchgeführt werden. Im Allgemeinen reicht es die jeweilige Minimalinstallation durchzuführen und dann durch iteratives Ausführen der "build-initramfs.sh" zu prüfen ob die Umgebung bzw. das Template-System allen Annahmen der initramfs Build-Logik genügt.

VirtualBox mit CentOS7 als Gast

Unter CentOS ist das Einrichten einer entsprechenden Gast-Konfiguration mit Virtual-Box etwas aufwändiger als bei den anderen Distributionen, daher ist ein funktionierender Weg zum Ziel hier detailierter beschrieben. Zunächst sollte man Dynamic Kernel Module Support einrichten:

  1. Aktualisiere Paketdatenbank: yum update
  2. Intalliere wget: yum install wget
  3. Intalliere C-Compiler: yum install gcc
  4. Lade erweitertes rpmforfe Repository: wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm
  5. Installiere Repository: rpm -Uvh rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm
  6. Lade das DKMS-Paket: wget ftp://rpmfind.net/linux/epel/5/x86_64/dkms-2.2.0.3-30.el5.noarch.rpm
  7. Installiere DKMS-Paket: yum localinstall dkms-2.2.0.3-30.el5.noarch.rpm --nogpgcheck
  8. Aktiviere rpmforge Repository: yum --enablerepo rpmforge install dkms
  9. Installiere Entwicklertools zum bauen von Paketen: yum groupinstall "Development Tools"
  10. Installiere Metainformation zum Kernel: yum install kernel-devel

Installieren der VirtualBox-Guest-Addition:

  1. Lege die VirtualBox-Guest-Addition-CD ein.
  2. Mounte CD: mount /dev/sr0 /mnt/ && cd /mnt/ && ./VBoxLinuxAdditions.run && reboot

Erstellen eines Testboot Eintrags für Grub2:

- Füge in /etc/grub.d/40_custom den folgenden Inhalt hinzu:

menuentry 'test' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option '__MENUEINTRAG_NAME__' {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod part_msdos
    insmod xfs
    set root='hd0,msdos1'
    if [ x$feature_platform_search_hint = xy ]; then
        search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' __HDD_UUID__
    else
        search --no-floppy --fs-uuid --set=root __HDD_UUID__
    fi
    linux16 /vmlinuz-3.10.0-123.el7.x86_64 root=UUID=__HDD_UUID__ ro rd.lvm.lv=centos/swap crashkernel=auto  rd.lvm.lv=centos/root vconsole.font=latarcyrheb-sun16 vconsole.keymap=de rhgb quiet 
    initrd16 /initramfs-test.img
}

- Füge neuen Menüeintrag in die automatisch generierte Grub2 Konfigurations2-Datei hinzu: grub2-mkconfig -o /boot/grub2/grub.cfg

Beispiel Dracut-Erweiterung

Im Folgenden wird erklärt wie man zusätzliche Funktionalität in das initramfs einbauen sollte. Dracut bietet ein Modul-System, um zur Bauzeit und Laufzeit gemäß der gegenseitigen Abhängigkeiten von Modulen auf konsistente Weise Funktionalität ein und abschalten zu können. Das folgende Beispiel beschreibt ein Modul welches von unserem Modul "dnbd3-rootfs" abhängt und zur Laufzeit ein komprimiertes Archiv herunterlädt und dieses in das zu bootende System integriert, um noch vor dem finalen pivot-root dynamisch Änderungen am finalen Root vorzunehmen.

Module erstellen

Ein Dracut-Modul ist ein Ordner, der sich im Dracut-Projekt unter "/modules.d" befindet. Der Ordner beginnt mit einer Zahl zwischen 1 und 100 und einem aussagekräftigen Namen als Suffix. Module können von anderen Modulen abhängen und werden entsprechend topologisch sortiert und eingehängt wenn sie direkt oder indirekt (als Abhängigkeit) selektiert wurden. Die Präfix-Zahl des Modul-Ordnernamens definiert in welcher Reihenfolge die Module vorbereitet werden. Je kleiner die Zahl desto früher werden diese zur Bauzeit verarbeitet. Alle Dracut eigenen Module haben Präfixe von 90 bis 99. Sie manipulieren Umgebungsvariablen die durch Module mit kleineren Prioritäten gesetzt wurden.

Funktionalität und Abhängigkeiten

Die "module-setup.sh" Datei repräsentiert das zentrale Manifest zur Definition von Abhängigkeiten und Dateien sowie Anwendungen die im Initramfs benötigt werden. Es handelt sich um ein simples Shell-Skript, dass zur Bauzeit durch Dracut importiert wird. Es können verschiedene Funktionen definiert werden, die die Funktionalität des Modules spezifizieren. Mithilfe verschiedener sogenannter "Hooks" werden Zeitpunkte während des Bootprozesses definiert, die vor oder nach Bereitstellung bestimmter Ereignisse durch Module spezifizierte Skripte ausführen.

Zunächst erstellen wir die Datei "module-setup.sh" mit dem Inhalt:

#!/usr/bin/env bash
# -*- coding: utf-8 -*-

source "$(cd "$(dirname "${BASH_SOURCE[0]}")" && cd '../' && \
    cd *'dnbd3-rootfs/scripts/rebash' && pwd)/core.sh" 
core.import exceptions
core.import logging

check() {
    local __doc__='
    Checks whether needed assumptions are satisfied.

    Example:

    `check`
    '

    # Here we could build our package file.

    # Tell dracut that this module should only be included if it is required
    # explicitly.
    return 255
}

Wir importieren die Import-Funktionalität von rebash, Exception-Handling und verschiedene Logging-Methoden. Die definierte Check-Funktion wird von dracut ausgeführt bevor das entsprechende Modul gebaut wird. Der sogennante Docstring ist der Wert der Variable "__doc__" und sollte zur Dokumentation der Funktion sowie der Spezifikation von Tests verwendet werden (Mehr dazu unter rebash - doctest). Durch den Rückgabewert kann gesteuert werden ob das aktuelle Modul integriert werden soll (0 entspricht "ja - immer" 255 entspricht "ja - wenn explizit oder indirekt selektiert"). Diese Funktion bietet die Möglichkeit die Integration eines Modules vorzubereiten. In unserem Fall könnte man z.B. das Archiv bauen, welches später mit Hilfe eines Webserver bereitgestellt werden soll um dynamisch in die finale Distribution integriert zu werden:

#!/usr/bin/env bash
# -*- coding: utf-8 -*-

source "$(cd "$(dirname "${BASH_SOURCE[0]}")" && cd '../' && \
    cd *'dnbd3-rootfs/scripts/rebash' && pwd)/core.sh" 
core.import exceptions
core.import logging

check() {
    local __doc__='
    Checks whether needed assumptions are satisfied.

    Example:

    `check`
    '
    if tar --dereference --create --verbose --gzip --file "${moddir}source" "${moddir}target.tar.gz" 
    then
        logging.error "Files from source in \"${moddir}source\" couldn't be packed into \"${moddir}target.tar.gz\"." 
        # Tell dracut that this module should only be included if it is required explicitly.
        return 255
    # Tell dracut that this module failed building and shouldn't be included yet.
    return 1
}

Dracut stellt die Umgebungsvariable "moddir" bereit, welche die Pfad zum aktuellen Modul-Ordner enthält. Wurde das Archiv erfolgreich gebaut, wird das Modul integriert, sonst nicht.
In unserem Beispiel wollen wir einen zusätzlichen Systemd-Dienst im Finalen System registrieren. Das tar-Archiv enthält daher folgende Struktur:

usr
└── lib
    └── systemd
        └── system
            ├── example.service
            └── multi-user.target.wants
                └── example.service

Inhalt der Datei example.service:

[Unit]
Description=Simple example service
After=dracut-pre-mount.service network.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=true
KillMode=none
ExecStart=/usr/bin/bash -c '/usr/bin/echo test >/tmp/test-output.txt'

Der Service schreibt das Wort "test" in die Datei "/tmp/test-output.txt".

In der Funktion depends() werden die Abhängigkeiten definiert:

...

depends() {
    local __doc__='
    Outputs all dependent dracut modules to make this module work.

    >>> depends
    dnbd3-rootfs
    '
    echo dnbd3-rootfs
}

Die Standard-Ausgabe der Funktion "depends" definiert eine leerzeichen-getrennte Liste von Modulenamen (ohne Prioritäts-Prefix).

Nun schreiben wir ein Skript, welches zur Laufzeit (während des Bootvorgangs) das Paket herunterlädt und ihre Dateien an die entsprechenden Orte in der finalen Distribution kopiert. Inhalt der Datei "apply-package.sh":

#!/usr/bin/env bash
# -*- coding: utf-8 -*-

source '/usr/lib/rebash/core.sh'
core.import exceptions
core.import logging
type emergency_shell >/dev/null 2>&1 || source /lib/dracut-lib.sh

exceptions.try
{
    logging.set_commands_level debug
    logging.set_level debug
    # NOTE: "getarg" raises an exception so deactivate exceptions for now.
    exceptions.deactivate
    slx_server="$(getarg slxsrv=)" 
    slx_server_base="$(getarg slxbase=)" 
    exceptions.activate

    logging.info 'Getting package.'
    IFS_backup="$IFS" 
    IFS=','
    for host in ${slx_server}; do
        logging.info "Trying host \"$host\"." 
        if wget --timeout 5 \
            "http://${host}/${slx_server_base}config.tar.gz" \
            --output-document - | tar --extract --verbose --gzip --directory \
                "$NEWROOT" 
        then
            break
        fi
    done
    IFS="$IFS_backup" 
}
exceptions.catch
{
    logging.error "$exceptions_last_traceback" 
    emergency_shell "error in ${BASH_SOURCE[0]}" 
}

Dracut ignoriert grundsätzlich Fehler, die zur Laufzeit innerhalb eines "Hooks" getriggert werden. Daher werde Fehler mit Hilfe von rebash explizit behandelt. Sollte ein unerwarteter Fehler auftreten wird die normale Programausführung sofort abgebrochen (exceptions.activate) und dracuts "emergency_shell" gestartet. Auf diese Weise wird vermieden, dass schwer zu interpretierende Symptome gar nicht erst entstehen können (Fail Fast). Das Skript liest die Kernel-Kommand-Line-Konfiguration aus, welche spezifiziert woher das entsprechende Archiv geladen werden soll und entpackt dieses direkt in das finale System (durch Dracut spezifiziert mit der Variable NEWROOT).

Nun müssen wir unsere Script noch in der module-setup.sh registrieren:

Mit Hilfe der "install" Funktionen können einzelne Dateien und ganze Anwendungen definiert werden, die dann von dracut in das Initramfs kopiert werden. Dracut löst hierbei Abhängigkeiten von Binaries dynamisch auf (z.B. shared libraries):

...

install() {
    local __doc__='
    Copies all needed files into the initramfs image and registers all needed
    dracut hooks.

    Example:

    `install`
    '
    inst_hook pre-pivot 00 "$moddir/apply-package.sh" 
    inst_multiple tar wget
}

Die Dracut-Funktion "inst_hook" installiert die übergebene Datei "apply-package.sh" in das Initramfs und führt diese mit Priorität 0 kurz vor dem "pivot-root" aus. Zu diesem Zeitpunkt ist, das finale System zwar bereits gemountet und schreibbar, jedoch noch nicht "gestartet" (pivot-root). Dracut liest automatisch die Shebang des Scripts "apply-package.sh" ein und installiert den entsprechend benötigten Interpreter (bash). Mit der Funktion "inst_multiple" können verschieden Programmaufrufe übergeben, werden. Dracut löst automatische alle benötigten Abhängigkeiten auf und kopiert diese in das initramfs, um diesen Programmaufruf im finalen System zu ermöglichen.

Nun sollte das Modul funktionieren. Das gesamte Beispiel-Modul kann hier runtergeladen werden.

Bootprozess









Dienste im Initramfs

Zu beachten ist, dass vor dem systemd eigenem Switch-Root eine umfangreiche Aufräum-Prozedur initiiert wird. Im Allgemeinen bleiben somit alle Prozesse, welche im iniramfs gestartet wurden nicht bestehen, wenn das finale System eingehängt wird.

Manuell gestartete Dienste

Um Prozesse zu markieren, die überleben" sollen müssen diese und im aktiven Prozessname mit einem "@" beginnen. Um Dienste generisch so zu markieren kann folgendes C-Program als Wrapper für den eigentlichen Prozess verwendet werden:

#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>

void print_array(int argc, char *argv[]) {
    // Helper function to print given array with given length.
    int i = 0;
    int j = 0;
    for (i = 0; i < argc; i ++) {
        j = 0;
        while(argv[i][j] != '\0')
            printf("%c", argv[i][j++]);
        printf(" ");
    }
    printf("\n");
}
int main(int argc, char *argv[]) {
    int count;
    // Last item acts as null pointer.
    char **copy = calloc(sizeof(char *), argc);
    // Slice first given command line argument.
    for (count = 0; count < argc - 1; count++)
        copy[count] = strdup(argv[count + 1]);
    // Adding systemd indicator to preserve wrapped process during changing
    // root filesystem. We mark wrapper and child process.
    argv[0][0] = '@';
    copy[0][0] = '@';
    if (-1 == execvp(argv[1], copy)) {
        perror("Executing child process failed.");
        return -1;
    }
}

Der Aufruf erfolgt z.B. so:

systemd-preserve-process-marker qemu-nbd -t -p 2000 "$QCOW_CONTAINER" &

Automatisch gestartete Dienste mit Service-Datei

Wird systemd bereits im initramfs genutzt, können Dienste die vor dem pivot-root gestartet werden und dannach bestehen bleiben sollen, mit der Direktive: IgnoreOnIsolate=true markiert werden. So werden diese Dienste entsprechend nicht beim pivot-root von Systemd beendet.

Quellen

bootProcess.png (32.3 KB) Torben Sickert, 02/29/2016 05:25 PM

hook1.png (40.7 KB) Torben Sickert, 02/29/2016 05:25 PM

hook2.png (36.4 KB) Torben Sickert, 02/29/2016 05:25 PM

overview.png (38.1 KB) Torben Sickert, 02/29/2016 05:29 PM

hook4.png (42.7 KB) Torben Sickert, 02/29/2016 05:29 PM

hook5.png (36.6 KB) Torben Sickert, 02/29/2016 05:30 PM

hook7.png (36.3 KB) Torben Sickert, 02/29/2016 05:30 PM

hook8.png (35.9 KB) Torben Sickert, 02/29/2016 05:30 PM

hook9.png (36.8 KB) Torben Sickert, 02/29/2016 05:30 PM

exampleDracutModule.tar.gz (1.4 KB) Torben Sickert, 03/29/2016 04:27 PM

hook3.png (30.7 KB) Torben Sickert, 03/29/2016 06:14 PM

hook6.png (29.6 KB) Torben Sickert, 03/29/2016 06:19 PM

stackWithMarkedTechnologies.png (120 KB) Torben Sickert, 03/29/2016 07:42 PM