Vorbereitung der Speicherkarte

Wie bei den meisten Linux Distributionen ist es sinnvoll, den Speicher in Partitionen aufzuteilen. So ist es in jedem Fall sinnvoll, eine spezielle Boot-Partition anzulegen und wenn man persönliche Daten über eine komplette Neuinstallation hinweg mitnehmen möchte, lagert man das Home-Verzeichnis aus dem Root Dateisystem aus.

Mount-Point	Type	Dateisystem	bei 2GB SD	bei 16GB SD
/boot	Bios boot	fat32 (vfat)	100 MB	100 MB
/	Linux Filesystem	ext4	700 MB	3GB
/home	Linux Filesystem	ext4	all the rest	all the rest

Zuerst gilt es also die Speicherkarte einzustecken und herauszufinden, welchen Gerätenamen sie hat, z.B. sdc

# List block devices
lsblk

In der Ausgabe von lsblk kann zugleich überprüft werden, ob das Device bereits gemountet ist. Ist bei einer Partition ein Mountpoint angegeben, muss dieser Mountpoint ausgebunden werden. Häufige Ursache dafür sind die komfortablen automatischen Mount Funktionen der jeweiligen Distribution.

Ubuntu verwendet hierfür das Gnome Virtual File System und mountet das Gerät mit Benutzerrechten mit Hilfe von gvfs-mount. Der richtige weg um es wieder auszubinden wäre deshalb

# unmount on distros using gvfs
gvfs-mount -u [mountpoint]

Grundsätzlich gilt, eine Partition kann immer mit den selben Rechten entfernt werden, mit der sie eingebunden wurde. Bei manchen Distributionen mag es auch ausreichen, den normalen umount Befehl mit Benuterrechten auszuführen.

umount [mountpoint]

Theoretisch kann eine Partition auch mehrfach gemountet sein und evtl. wird nur ein Mountpoint angezeigt. Funktioniert keiner der beiden oben genannten Möglichkeiten, kann man mit Root-Rechten die Partition an jedem Mountpoint ausbinden, indem man stattdessen direkt die Partition angibt.

sudo umount /dev/sdxX

Häufig ist der Dateimanager auch so konfiguriert, dass er beim einstecken eines Massenspeichers jedes Mal direkt nach dem automatischen mounten den Inhalt im Dateimanger öffnet. Für nautilus kann man dieses Verhalten wie folgt abstellen.

$ gsettings set org.gnome.desktop.media-handling automount-open false

Partitionierung

Wir empfehlen eine SD-Karte mit mindestens 2GB zu verwenden. Für die Partitionierung kann man z.B. fdisk, cfdisk oder cgdisk verwenden.

sudo cfdisk -z /dev/sdX

-z: create a new partition table, choose gpt

Ansonsten sollte die graphische Ausgabe im Terminal selbsterklärend sein. Die Partitionsgröße angeben und danach den Typ anpassen. Wichtig ist vielleicht noch der Hinweis, dass auf der Speicherkarte nichts verändert wird, bis explizit der Write Vorgang angestoßen wird. Dann jedoch sind die alle Daten auf der Speicherkarte gelöscht und das neue Partitionslayout wurde geschrieben.

Man kann nur wieder lsblk verwendenn oder mit fdisk das genaue Partitionslayout mit Sektorangaben ausgeben.

# using lsblk
lsblk

# or fdisk
fdisk -l /dev/sdx

# example output
Gerät       Anfang     Ende Sektoren Größe Typ
/dev/sdx1     2048   206847   204800  100M BIOS boot
/dev/sdx2   206848  4401151  4194304    2G Linux-Dateisystem
/dev/sdx3  4401152 15974366 11573215  5,5G Linux-Dateisystem

Formatierung

Nachdem die Partitionen angelegt wurden, müssen diese mit dem passendenn Dateisystem formatiert werden. Unter manchen Distributionen kann es notwendig sein, die Werkzeuge für ein Dateisystem vorher nachzuinstallieren.

# arch-linux
sudo pacman -S dosfstools

# ubuntu
# seems to be already preinstalled
dpkg -s dosfstools

Danach kann das FAT-Dateisystem bequem mit wie jedes anndere andere Dateisystem mit mkfs angewandt werden. mkfs.vfat wählt zwar selbstständig die scheinbar geeignetete Größe, auf der sicherenn Seite is man aber wenn man mit dem Parameter -F 32 diese explizit angibt.

sudo mkfs.vfat -F 32 /dev/sdxX

Den selben Vorgang wiederholt man nun für die restlichen Partitionen. Meist wird hier das Linux typische ext-Dateisystem verwendet. Version 2 kann aufgrundvon fehlendem Journaling evtl. zu Datenverlust führen, wenn während Schreibvorgängen das Gerät stromlos gemacht wird. Kein Problem stellt das für Read-only Partitionen.

mkfs.ext4 /dev/sdxX     # /
mkfs.ext4 /dev/sdxX     # /home

Fernzugriff auf gemountete Partitionen

Gemountete Partitionen sind nicht direkt über das Netzwerk erreichbar, aber man kann entweder das Gerät selbst oder ihren Speicher als virtuelles Dateisystem durchreichen. Zwischen UNIX-basierten Rechnern, erziehlt Network File System (NFS) die beste Netzwerk Performance und ist nicht besonders schwer einzurichten. Ist es gewünscht, Dateien mit Windows auszutauschen, sollte man einen Blick auf Samba werfen.

Massenspeicher wie z.B. USB-Sticks und SD-Karten werden in der Regel automatisch gemountet. Probleme ergeben sich aber, wenn man den gemounteten Ordner dann teilen möchte. Eine etwas sauberere Lösung kann man mit autofs realisieren.

Autofs

Dieser Punkt kann überschritten werden, wennn der Fernzugriff auf ein Verzeichnis gehen soll, dass auf dem Server immer eingebunden ist. Befindet sich das Verzeichnis auf einem externen Massenspeicher, lohnt sich ein Blick auf autofs

$ sudo apt install autofs

Nach der Installation gibt es eine Master Konfigurationsdatei /etc/auto.master in der man seine Unterkonfigurationen bekannt mancht. Beispielhaft habe ich hier /automnt /etc/auto.automnt --timeout=5 --ghost hinzugefügt um mein Gerät nach /automnt zu mounten. Die Option ghost` verhindert, dass automatische generierte Mountpoints nach dem Timeout oder dem entfernen des Geräts nicht wieder verschwinden, sondern schlicht leer sind. Autofs löst (unbind) sich nach jedem abgeschlossenen Schreibvorgang (sync) vom eigentlichen Medium und verbindet sich für jeden Zugriff erneut. Es ist empfohlen diesen Ordner direkt im Wurzelverzeichnis und nicht in einem Unterverzeichnis zu erstellen.

$ sudo sh -c 'echo "/automnt /etc/auto.automnt --timeout=5 --ghost" >> /etc/auto.master'
$ sudo mkdir /automnt
$ sudo chmod 777 /automnt

Der Grund warum man das Verzeichnis im Wurzelverzeichnis anlegen sollte ist, dass autofs alle Überordner blockiert. Man sollte also /media oder mnt verwenden, wenn diese von einem anderen Tool oder für andere Zwecke bereits verwendet werden. https://wiki.ubuntuusers.de/Autofs#Die-Master-Map-Datei

Nun können wir die Sub Konfigurationsdateien dort anlegen, wo sie oben angegeben wurden und die spezifischen Mount Optionen mitgeben.

$ sudo sh -c 'echo \
    "BOOT -fstype=vfat,sync,uid=0,gid=46,umask=007 :/dev/disk/by-label/BOOT" \
    >> /etc/auto.master'

BOOT ist in diesem Fall die Partitionsbezeichnung (Label) und diese wird auch als Name des Mountpoints verwendet, was auf unserer SD-Karte ein FAT32 Dateisystem ist. Außerdem werden die Berechtigungen gesetzt. Beim Mountvorgang wird hier root wird als Besitzer und plugdev als Gruppe verwendet, was jedem registrierten Nutzer den Zugriff auf den gemounteten Ordner ermöglicht. Es wird viel darüber diskutiert, dass sync option langsam und schädlich für Flash-Speicher sein könnte, aber es wird damit sichergestellt, dass jeder Schreibvorgang auch sofort umgesetzt wird.

In den meisten Fällen is es besser /dev/disk/by-uuid/... zu verwenden, aber da wir vllt mehrere SD-Karten verwenden, die beim selben Label auch das gleiche Verhalten zeigen sollen macht diese Konfiguration so durchaus Sinn. Man sollte sich dieser Situation aber bewusst sein, da es zu Fehlern führen könnte, wenn mehrere Massenspeicher mit dem selben Label gleichzeitig verwendet werden.

Dieser Vorganng kann natürlich für weitere Partitionen verwendet werden.

Nachdem alle Konfigurationen abgeschlossen sind, wird der Dienst neu gestartet.

$ sudo service autofs restart

Man kann jetzt überprüfen ob das Gerät ordungsgemäß nach /automnt/BOOT gemountet wurde.

Kleine Randnotiz: Man kann autofs auch mit FTP nutzen, aber das Asprechverhalten könnte dadurch stark verzögert werden und ich habe noch keine Möglichkeit gefunden den filetype auf binary zu setzen, damit keine Probleme mit größeren Dateien auftreten. Mehr Informationen dazu finden sich auch https://wiki.archlinux.org/index.php/Autofs#Remote_FTP.

NFS-Server

Ein nettes How-To ist hier zu finden https://help.ubuntu.com/community/SettingUpNFSHowTo

$ sudo apt install nfs-kernel-server

Lokales Verzeichnis

Will man z.B. das Root-Filesystem für den RaspberryPi bereitstellen, ist die Konfiguration besonders einfach.

Nach der Installation legt man lediglich die Datei /etc/exports an und trägt dort das Verzeichnis und den berechtigten Client ein.

$ sudo vim /etc/exports

# Freigabe gilt für alle IPs von 192.168.1.1 bis 192.168.1.255, mit Lese-/Schreibrechten:
/pfad/zum/ROOTFS       192.168.1.0/255.255.255.0(rw,async)

Verzeichnis liegt auf einem externen Massenspeicher

Unser Ziel ist es den Ordner so schnell wie möglich bereitzustellen, sobald der Massenspeicher mit dem NFS-Server verbunden wird. Um dies zu ermöglichen ohne dabei Einfluss auf bisherige Einstellungenn zu nehmen, macht gerade für NFS die Kombination mit autofs Sinn.

$ sudo vim /etc/exports
...
/automnt                  U64(rw,no_subtree_check,async,fsid=0,crossmnt) \
                    localhost(rw,no_subtree_check,async,fsid=0,crossmnt) \
              172.29.170.0/24(rw,no_subtree_check,async,fsid=0,crossmnt) \
              172.29.173.0/24(rw,no_subtree_check,async,fsid=0,crossmnt)

/automnt/BOOT             U64(rw,no_subtree_check,async) \
                    localhost(rw,no_subtree_check,async) \
              172.29.170.0/24(rw,no_subtree_check,async) \
              172.29.173.0/24(rw,no_subtree_check,async)

In der exports wird der Zugriff auf die bereitgestellten NFS-Shares geregelt. Hier kann sowohl der Hostname des Rechners als auch desssen IP verwendet werden. Außerdem kann ein ganzer IP-Range freigegeben werden.

Die Option fsid=0 erlaubt ein Hauptverzeichnis in dem sich unterschiedliche Shares finden, dies is jedoch für den Zugriff nicht notwendig. crossmnt erweitert diese Einstellung so, dass es möglich ist in diesem Hauptverzeichnis Shares zu haben die selbst wiederum auf unterschiedlichen Dateisystemen liegen.

Nach einen Neustart des NFS-Server Dienstes sind die Shares verfügbar.

$ sudo service nfs-kernel-server restart

In Verbindung mit dem zuvor beschriebenen autofs ist das Verzeichnis jetzt erreichbar aber leer, solange der Massenspeicher nicht verbunden wurde.

Wird der Massenspeicher häufig getrennt und wieder neu verbunden, erweist sich der timeout teilweise als zu lang und unzuverlässig. Das Gerät wird nach einen Schreibvorgang nicht vollständig getrennt und so kann es teilweise lange dauern bis autofs einen remount erkennt. Um hier Abhilfe zu schaffen kann man eine zusätzliche udev Regel verwenden, die einen richtigen unmount auslöst, wenn der Massennspeicher entfernt wird.

$ sudo vim /etc/udev/rules.d/80-BOOT-unmount.rules

# Auto-unmount USB storage (on remove):
ACTION=="remove", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="BOOT", RUN+="/usr/bin/logger  auto umounting  %k"
ACTION=="remove", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="BOOT", RUN+="/bin/umount /automnt/BOOT"
ACTION=="remove", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="BOOT", RUN+="/bin/umount -lf /automnt/BOOT"

NFS-Client

Auf der Client Seite ist das mounten eines NFS Share genauso einfach wie für eine lokale Partition.

$ sudo apt install nfs-common
$ sudo mkdir /mnt/BOOT
$ sudo mount [NFS-SERVER]:/automnt/BOOT /mnt/BOOT

Es kann vorkommen, dass ein Share nicht mehr erreichbar ist, z.B. wenn der Server zwischendurch nicht erreichbar war.

Möchte man ein bereitgestelltes Root-Filesystem booten, muss man dies im Bootloader konfigurieren und dort als Bootargument übergeben.

$ sudo umount /mnt/BOOT