f e l i x k r i c k l . x y z

Seit Anfang meines Studiums nutze ich hauptsächlich Linux Mint. Die Blog Einträge hier beziehen sich, wenn nicht anders gekennzeichnet, auf dieses Betriebssystem.

Jahr 2022


2022-07-24 – Installation von MestreNova 14.2.0 unter LMDE 5

Auf einem neuen Laptop Baujahr 2020 habe ich Linux Mint Debian Edition 5 als Betriebssystem installiert. Die letztere Version LMDE 4 konnte wegen einem zu alten Kernel nicht installiert werden. Die relativ aktuelle Hardware wird vom Auslieferungskernel von LMDE 4 noch nicht unterstützt. Mit dem Auslieferungskernel von LMDE 5 (Version 5.10.0) läuft alles.

Problematisch ist unter LMDE 5 allerdings die Installation von MestreNova 14.2.0. Da die HHU-D zur Zeit nur eine Lizenz bis zu dieser Version hat, können die neueren Versionen von MestreNova nicht verwendet werden. MestreLab bietet von der Version 14.2.0 noch ein .deb-Paket für Debian 10 an. LMDE 5 basiert aber bereits auf Debian 11 (Codename "Bullseye"); LMDE 4 basierte auf Debian 10 (Codename "Buster"). Versucht man also dieses .deb-Paket auf LMDE 5 zu installieren, verursacht dies einen unlösbaren Paketekonflikt; unter anderem ist das Paket lib32gcc1 betroffen.

Man kann den Paketekonflikt folgendermaßen lösen: Bevor die Installation von MestreNova versucht wird, erstellt man die Datei /etc/apt/sources.list.d/buster.list mit dem Inhalt:

deb http://ftp.at.debian.org/debian/ buster main contrib non-free

Wegen dem Hinzufügen dieser Paketquelle muss noch ein update gemacht werden:

apt update

Jetzt muss noch ein Paket in einer älteren Version installiert werden, von dem MestreNova 14.2.0 abhängig ist:

apt install -t=buster lib32stdc++6

Dieses darf später nicht auf die neuere Version aktualisiert werden!

Jetzt kann das .deb-Paket von MestreNova 14.2.0 installiert werden. Es werden dabei automatisch noch einige weitere Abhängigkeiten installiert.


2022-07-07 – Erstellen einer virtuellen Maschine aus einem lokalen Windows-System für die Nutzung auf einem Linux-Host

Will man ein lokales Windows 10 System (beispielsweise von einer Dual-Boot Installation) in eine unter Linux nutzbare Virtuelle Maschine (VirtualBox) konvertieren, bietet sich das Programm disk2vhd an. Dieses muss heruntergeladen und entpackt werden und im laufenden, lokalen Windows System als Administrator ausgeführt werden.

Im disk2vhd-Fenster wählt man nun das System-Laufwerk C und den Bootsektor (gekennzeichnet durch "Windows RE Tools") aus. Alle anderen Laufwerke wählt man ab. Von den drei oben rechts erscheinenden Optionen wird nur die Option "Volume Shadow Copy" ausgewählt; die beiden anderen werden nicht ausgewählt. Als VHD File Name kann man einen beliebigen Dateinamen wählen. Hier muss man nur darauf achten, dass man diese auf ein Laufwerk schreibt, das mit ntfs formatiert ist und über ausreichend Speicherplatz verfügt. Die vhd-Datei wird in etwa genauso groß sein, wie auf C Speicher belegt ist.

Durch Klick auf "Create" wird die Erstellung der vhd-Datei gestartet. Das kann einige Stunden dauern. Wenn der Prozess abgeschlossen ist, kann man Windows herunterfahren. Alles weitere erfolgt vom Linux-Host.

Im Linux System sollte man jetzt die vhd-Datei auf eine Partition kopieren, die auf einer SSD liegt (falls nicht schon von Windows aus geschehen). Optional kann man sie auch mit VBoxManage in eine vdi-Datei umwandeln:

VBoxManage clonemedium /PFAD/ZUR/VHDDATEI.VHD DATEINAME.vdi --format VDI

Ein wichtiger Schritt ist jetzt noch die Installation des Pakets "virtualbox-ext-pack". Dazu folgenden Befehl eingeben:

sudo apt-get install virtualbox-ext-pack

Jetzt wo alle Vorbereitungen abgeschlossen sind, kann im VirtualBox eine neue Maschine erzeugt werden. Am Schluss des Dialoges wo es um die Festplatte geht, wählt man "Vorhandene Festplatte verwenden" und klickt auf das gelbe Ordner-Symbol rechts neben der Auswahlleiste. Im Pop-Up Dialog klickt man auf das Piktogramm "Hinzufügen" und wählt die gewünschte vhd- bzw. vdi-Datei aus. Dann nur noch bestätigen und die Maschine sollte startfähig sein.


2022-06-30 – backup einer Windows-MBR Partition von Linux aus mit dd

Windows legt zum Booten am Beginn der System-Festplatte eine kleine Partition an, den sogenannten Master-Boot-Record (MBR). Wird diese Partition beschädigt kann man das System nicht mehr booten, selbst wenn die eigentliche System-Partition von Windows noch intakt ist. Bei mir liegt der MBR auf sda1, die System-Partition ist sda2. Um ein vollständiges Backup des MBR auf eine externe Festplatte zu schreiben habe ich folgendes getan:

  1. Auf der externen Festplatte eine neue Partition der Größe 1024 MB anlegen (die originale MBR-Partition ist bei mir 579 MB groß). Auf der externen Festplatte hatte ich schon einige Partitionen, also wurde die neue sdf5.
  2. Die neue Partition mit ntfs formatieren.
  3. Darauf achten, das beide Partitionen unmountet, also ausgehängt, sind.
  4. Die blocksize der originalen MBR-Partition ermitteln mit dem Befehl:
    blockdev --getbsz /dev/sda1
    (In aller Regel sind es 4096)
  5. Den folgenden dd-Befehl ausführen:
    sudo dd if=/dev/sda1 of=/dev/sdf5 bs=4096 status=progress
    Zur Erklärung: if steht für input file, of für output file, bs für blocksize und status=progress aktiviert die Fortschrittsanzeige. Wenn im letzten Schritt eine andere blocksize ermittelt wurde, muss das hier angepasst werden.
  6. Nachdem der dd-Prozess schon beendet wurde, können trotzdem noch Lese- oder Schreibprozesse auf die externe Festplatte ausstehen. Um sicher zu gehen, dass alle Prozesse abgeschlossen sind, sollte man noch folgenden kurzen Befehl geben:
    sync
  7. Die neue Partition sdf5 sollte jetzt noch auf die gleiche Größe verkleinert werden, wie die originale MBR-Partition sda1. Das kann man zum Beispiel von Windows aus in der Datenträgerverwaltung machen. Bei mir ist es auch mit dem grafischen Programm GParted gelungen, das auf den meisten Linux-Distributionen schon vorinstalliert ist.
  8. Um sich zusätzlich abzusichern, dass der Inhalt der beiden Partitionen identisch ist, gibt man folgenden compare-Befehl ein:
    sudo cmp -bl /dev/sda1 /dev/sdf5
    Wenn der Prozess ohne Ausgaben durchläuft sind die Inhalte der Partitionen identisch. Wenn man die neue Partition nicht auf die richtige Größe verkleinert hat, wird hier eine Meldung der folgenden Art erscheinen:
    Dateiende in /dev/sda1 nach Byte 607125504

(Die Partitions-Bezeichnungen müssen ggbf. individuell angepasst werden)


2022-06-12 – mehrere Sprachversionen einer Quelle mit Latex zitieren

Dieser Eintrag bezieht sich auf die Satzsprache Latex (genutzte Version: texlive 2021) und ist damit weitgehend vom Betriebssystem unabhängig.

Bei Artikeln aus dem Journal Angewandte Chemie gibt es meistens eine deutsche Version und eine englische, welche im zugehörigen Journal Angewandte Chemie International Edition erscheint. Optimal ist es hier, beide Versionen in einem Zitat unterzubringen und mit einer alphabetischen Aufzählung zu trennen. Erreicht wird das in Latex bei der Benutzung des biblatex-Pakets, indem man mit dem Befehl \defbibentryset{<key>}{<key1>,<key2>,<key3>...} die beiden Versionen zu einem "set" zusammenfasst.

key1 und key2 sind hier die eigentlichen bibtex-keys aus der .bib-Datei und der key ist die neue Bezeichnung für dieses set. Es ist weiterhin wichtig, dass man beim Einbinden des biblatex-Paktes das Attribut "subentry" vergibt. Nur dann werden die einzelnen Sprachversionen auch mit einer alphabetischen Aufzählung getrennt. Ansonsten findet man zwischen den Versionen nur eine Semikolon-Interpunktion, was unübersichtlicher wäre.

Hier ein Minimalbeispiel:
\documentclass[ngerman,a4paper]{scrartcl}
\usepackage[subentry]{biblatex}
\bibliography{lit.bib}
\defbibentryset{angew-michalchuk}{michalchuk2022zeitaufgeloste,michalchuk2022time}
\begin{document}
Mein Text mit Zitation \cite{angew-michalchuk}
\printbibliography
\end{document}
mit lit.bib:
@article{michalchuk2022zeitaufgeloste,
title={Zeitaufgelöste In-Situ-Untersuchungen von mechanochemischen Reaktionen},
author={Michalchuk, Adam AL and Emmerling, Franziska},
journal={Angewandte Chemie},
volume={134},
number={21},
pages={e202117270},
year={2022},
doi={10.1002/ange.202117270},
publisher={Wiley Online Library}
}
@article{michalchuk2022time,
title={Time-Resolved In Situ Monitoring of Mechanochemical Reactions},
author={Michalchuk, Adam AL and Emmerling, Franziska},
journal={Angewandte Chemie International Edition},
volume={61},
number={21},
pages={e202117270},
year={2022},
doi={10.1002/anie.202117270},
publisher={Wiley Online Library}
}
Dieser Code gibt folgendes Ergebnis: defbibentryset

Obiges Beispiel ist ein dynamisches bibentry set. Alternativ kann man auch ein statisches implementieren, indem man es direkt in die .bib-Datei einbaut. Damit spart man sich den defbibentryset-Befehl in der Präambel. Der oben gezeigten .bib-Datei würde man entsprechend folgende Zeilen anhängen:

@set{angew-michalchuk,
entryset={michalchuk2022zeitaufgeloste,michalchuk2022time}
}

Das Ergebnis ist dasselbe.


2022-06-11 – In einem Verzeichnisbaum auschließlich alle Dateien schreibgeschützt machen Getestet auf:
  • GNU/Linux Mint "Una" Cinnamon

Um Dateien unter Linux-Dateisystemen mit einem Schreibschutz zu versehen, gibt es das Dateiattribut "i" (immutable). Genauer gesagt bewirkt dieses Attribut, dass folgende Operationen an einer Datei selbst als root unmöglich werden:

  • Umbennen
  • Inhalt ändern
  • Löschen

Erst wenn man das Attribut wieder entfernt, können diese Operationen wieder durchgeführt werden.

Nun zum Thema: Bestimmte Dateien die sich nicht ändern wie zum Beispiel

  • E-Books
  • Musik-Dateien
  • Wichtige Dokumente

wird man vielleicht schreibschützen wollen. Hat man die betreffenden Dateien in einem bestimmten größeren "Ast" des Dateisystems gespeichert, könnte man den Schreibschutz aktivieren indem man einfach den Befehl

sudo chattr -R +i /PFAD/ZUM/AST

benutzt. Das hat aber den Nachteil, dass hiermit auch die Ordner innerhalb dieses Astes immutable werden. Die Folge: Man kann auch keine neuen Dateien mehr innerhalb des Astes anlegen. Wenn man das aber will, hilft folgendes Einzeiler-Script. Damit werden nur alle Dateien innerhalb des Astes immutable gemacht, aber nicht die Ordner.

#!/bin/bash
sudo find $1 -type f -exec chattr +i {} \;

Als Argument wird der Pfad zum "Ast" des Dateisystems angegeben. Noch ein Hinweis: Viele Dateien mit dem Attribut zu versehen kann etwas dauern; wenn man das Skript benutzt sieht es dann eventuell so aus als würde das Hängen. Solange keine Fehlermeldungen kommen sollte aber alles funktionieren und man muss sich einfach gedulden.


2022-01-20 – Notiz zur Installation von texlive und texstudio

Dieser Blog-Eintrag richtet sich vor allem an solche, die texlive zum ersten Mal installieren. Er kann jedoch auch für fortgeschrittene Benutzer interessant sein.

Vorgestellt wird in diesem Blog-Eintrag ein Zusammenhang in Bezug auf:

  • GNU/Linux Mint "Una" Cinnamon bzw. GNU/Linux Mint Debian Edition 4 "Debbie"
  • texlive 2021 (Das Latex-Grundsystem)
  • texstudio 2.12.22+debian-1build1 von http://ftp.halifax.rwth-aachen.de/ubuntu focal/universe amd64 Packages (Ein beliebiger Latex-Editor)

Nachdem man das aktuelle .tar.gz-file von tug.org heruntergeladen hat und die install-tl-Datei im Terminal durch

sudo ./install-tl

im entsprechenden Verzeichnis aufgerufen hat, wird dem Benutzer eine Reihe von künftigen Standard-Verzeichnissen für die Installation des texlive-Systems vorgeschlagen. Diese beschränken sich im wesentlichen auf das Verzeichnis /usr/local/texlive/JAHR (also z.B.: /usr/local/texlive/2022). Diese können zunächst mal in den default-Einstellungen bestätigt werden, oder aber auch im Installationsskript nach Belieben geändert werden. Für das Funktionieren von texlive an sich spielt es keine Rolle, wo dieses installiert wird. Es gibt aber zwei Punkte die hier wichtig sind:

  • Texstudio schaut m.W.n per default in /usr/share/texlive/JAHR nach den zur Kompilierung notwendigen binaries
  • Das Kompilieren läuft schneller, wenn das texlive-Verzeichnis auf einer SSD gespeichert ist.

Der erste Punkt ist insofern irrelevant, als dass man in Texstudio unter "Optionen" -> "TexStudio konfigurieren" -> "Befehle" Die Pfade für die jeweiligen Binaries angeben kann. Es kann aber sein, dass der default-Pfad von texlive und Texstudio zunächst nicht übereinstimmen. Das führt dann in Texstudio beim Kompilierversuch zu einer Fehlermeldung, die ausdrückt, dass das erste in der Präambel gefragte Paket nicht gefunden werden kann. Man kann also nicht Kompilieren, wenn man nicht dafür sorgt, dass die Pfade übereinstimmen.

Der zweite Punkt ist in Zusammenhang mit der Frage relevant, ob man ein System hat, bei dem die root-Partition und die /home-Partition auf verschiedenen Laufwerken liegen. Ist das der Fall und sollte eines der beiden Laufwerke eine SSD sein, sollte auf der SSD installiert werden. Um die binaries des texlive-Grundsystems braucht man sich keine Sorgen zu machen. Sie bei einer Backup-Routine zu integrieren ist unnötig, da sie jederzeit von den offiziellen Quellen neu bezogen werden können.

Allerdings sollte man sich bei eigens zugefügten Paketen oder Klassen um die Integration in die Backup-Routine sorgen machen. Denn diese bekommt man sonst nicht wieder. Eine Art, dies bei einem System zu realisieren, bei welchem man immer nur /home sichert, ist entweder die komplette Installation von texlive im /home (nicht zu empfehlen), oder die Installation im root mit einer Auslagerung des Unterverzeichnisses PFAD/texlive/texmf-local in das /home-Verzeichnis durch einen symbolischen Link. Denn im texmf-local Baum sollen ja eigene Pakete und Klassen untergebracht werden. So zum Beispiel bei mir geschehen durch:

mkdir ~/texlive
cd /usr/local/texlive
sudo mv texmf-local ~/texlive
sudo ln -s ~/texlive/texmf-local texmf-local

Bei diesem Aufbau werden die in ~/texlive/texmf-local liegenden Pakete auch von Texstudio gefunden.

Grundsätzlich würde ich von einer Installation des gesamten texlive-Systems im /home-Verzeichnis abraten, weil es unkonventionell und auch nicht nötig ist. Dazu kommt, dass man für die binaries noch die PATH Variable ändern muss, damit diese überhaupt ausgeführt werden dürfen. Das ist zwar durchaus möglich, aber für Anfänger nicht trivial.

Jahr 2021


2021-11-20 – Von Bruker Messgeräten generierte NMR-Ordner nach dem Messtitel umbenennen

An der HHU-D werden NMR-Spektren mit Bruker Geräten gemessen. Dabei erhält man über das Serversystem die Spektren in einem Ordner, welcher nach der Experimentnummer (meist 3 oder 4-stellig) benannt ist. Hierdurch wird aber der NMR-Titel, den man auf den Messzettel geschrieben hat, nicht ersichtlich. Dieser ist im entsprechenden Ordner unter pdata/1/title versteckt.

Um hier mehr Übersicht zu haben, habe ich ein kurzes bash-Skript geschrieben, welches die NMR-Ordner umbenennt, sodass nach der Experiment-Nummer noch der eigentlich Titel der Messung angezeigt wird. Dieses kann wie bei meinem blog-Eintrag von 2021-10-07 über das Kontextmenü angewendet werden. Hier der Inhalt des Skriptes:

#!/bin/bash
for NMR_FOLDER in $@;
do
DELIMITER="_";
EXP_TITLE=$(cat $NMR_FOLDER/pdata/1/title | sed 's/\ /_/g');
mv $NMR_FOLDER $NMR_FOLDER$DELIMITER$EXP_TITLE
done

Angewendet wird das Skript mit Rechtsklick auf einen oder mehrere ausgewählte Experiment-Ordner im Dateimanager.


2021-11-07 – Modifikation des "Compress PDF"-Scriptes von Ricardo Ferreira

Auf dem Forum LinuxMintUsers.de fand ich einen Hinweis auf ein einfaches bash-Script zur Komprimierung von pdf-Dateien. Dieses wurde von Ricardo Ferreira erstellt und ist bei launchpad verfügbar. Es lässt sich über das Kontextmenü im Nemo-Dateimanager anwenden, wenn es in ~/.local/share/nemo/scripts abgelegt wird und ausführbar gemacht wird. Man kann es auf einzelne oder eine Auswahl von pdf-Dateien gleichzeitig ausführen. Dabei wird ein Fenster geöffnet, in welchem man zwischen fünf Komprimierungs-Optionen wählen kann. Hat man eine ausgewählt, wird noch über ein zweites Fenster abgefragt, unter welchem Dateinamen das komprimierte pdf abgespeichert werden soll.

Durch Ausprobieren habe ich gefunden, dass die Option "niedrige Qualität (150 dpi)" bisher für alle getesteten pdfs den besten Kompromiss aus Qualität und Dateigröße bietet. Auch finde ich es nicht sinnvoll, jedesmal einen neuen Dateinamen eingeben zu müssen. Ich habe daher einige Komponenten des Skriptes auskommentiert und mit wenigen Zeilen ersetzt, die dafür sorgen, dass die beiden Auswahlfenster übersprungen werden und stattdessen die Option "niedrige Qualität (150 dpi)" immer durchgeführt wird. Auch der Dateiname für das komprimierte pdf kann nun nicht mehr ausgewählt werden, sondern entspricht stets dem Dateinamen der Eingabedatei zuzüglich des Suffix "_opt". Auf diese Weise spart man sich einige Tipperei und Klickerei und hat dennoch weiterhin die Option, die Komprimierung "rückgängig" zu machen, falls es nicht den Wünschen des Anwenders entspricht, indem man einfach die komprimierte Datei löscht und gegebenenfalls die Eingabedatei auf andere Art noch mal bearbeitet.

Eine Möglichkeit, das Beste aus beiden Welten zu behalten, wäre zum Beispiel, sich das originale Skript von Ricardo Ferreira in /usr/bin zu legen und bei Bedarf über die Befehlszeile auszuführen und meine Modifikation in .local/share/nemo/scripts abzulegen, um über das Kontextmenü darauf zugreifen zu können.

Hier also mein modifiziertes Skript zum Download:

compress-pdf (15,3 kB)

Das Skript unterliegt dem Urheberrecht von Ricardo Ferreira und wird unter der Gnu Public License v3.0 verteilt.


2021-10-27 – Gescannte Dokumente "lesbar" machen

Mit dem ocrmypdf Paket können gescannte Dokumente so bearbeitet werden, dass der Text markiert und an anderer Stelle eingefügt wird. Um diese Option im Kontextmenü nutzen zu können, muss eine Datei "ocr" im Verzeichnis ~/.local/share/nemo/scripts/ mit folgendem Inhalt erzeugt und ausführbar gemacht werden:

INPUT=$@
DATEINAME=$(echo $INPUT | sed 's/\./\t/' |awk '{print $1}')
ENDUNG="_ocr.pdf"
OUTPUT="$DATEINAME$ENDUNG"

ocrmypdf $INPUT $OUTPUT

Vergleiche mit dem letzten Blogpost.


2021-10-07 – LaTeX Dokumente kompilieren mit Rechtsklick auf die Datei

Ein Terminal zu öffnen, nur um den Pfad zu einer .tex-Datei einzugeben und dann "pdflatex DATEI" einzugeben, ist mehr Aufwand, als sein muss. Einfacher ist es, eine script-Datei mit dem schlichten Inhalt:

~/texlive/2021/bin/x86_64-linux/pdflatex $@

im Verzeichnis ~/.local/share/nemo/scripts/ abzulegen, z.B. mit dem Dateinamen "pdflatex". Zum Schluss muss man nur noch den Modus der script-Datei auf 757 setzen:

chmod 757 ~/.local/share/nemo/scripts/pdflatex

und sollte nun den Befehl über das Kontextmenü im Dateimanager auf beliebige .tex-Dateien anwenden können.

Beachte: Der erste Befehl gilt nur für Systeme, bei denen texlive im /home-Verzeichnis installiert wurde. Wenn die binary "pdflatex" in einem anderen Verzeichnis liegt, muss das natürlich entsprechend angepasst werden. Wo die Datei "pdflatex" im eigenen System liegt kann überprüft werden, indem man

type pdflatex

im Terminal eingibt.


2021-10-07 – Zugriff auf das VPN der HHU Ein viel einfacherer Weg, als vom ZIM empfohlen, auf das VPN der HHU unter Linux Systemen zuzugreifen, ist der Weg über das Terminal. Man muss so oder so zunächst openvpn installieren. Die .ovpn-Datei der HHU muss im entsprechenden Ordner abgelegt werden und ein einfaches alias, eingetragen in die ~/.bash_aliases genügt:
sudo apt-get install openvpn
alias hhuvpn='sudo openvpn ~/.openvpn/HHU-VPN.ovpn'
Wo genau die .ovpn-Datei liegt spielt im Grunde keine Rolle. Sie in den Konfigurationsordner ~./openvpn zu legen ergibt Sinn, aber solange man im alias den richtigen Pfad angibt, kann die Datei an beliebiger Stelle des Dateisystems platziert werden.

2021-10-06 – Mein "schreibmit"-alias

Das Ziel: Die Inhalte des Terminals "live" in eine Datei schreiben, um später einen Anhaltspunkt dafür zu haben, was am System geändert worden ist.

Die Lösung: Die linux-utillity "script" aus BSD 3. Diese wird mit einer Pfadangabe in ein alias inkorporiert:

alias schreibmit='script -a ~/terminal-logs/via-script/$(date +%Y-%m-%d_%H:%M)'

und in die ~/.bash_aliases eingefügt. Um das "mitschreiben" sauber zu beenden, muss

exit

eingegeben werden. Das Terminal schließt sich dann nicht, es wird nur "script" beendet.

Zur Bedienung von "script" befragt man "man":

man script

2021-10-05 – VirtualBox Machines im root Verzeichnis speichern

Nachdem bei meinem Setup

  • root-Verzeichnis auf sda1, einer SSD
  • /home-Partition auf sdb1, einer HDD

entsprechend dem default meine virtuellen Maschinen auf einer HDD lagen (nämlich in ~/'VirtualBox VMs') und diese hörbar beanspruchten, hatte ich überlegt wie ich die Maschinen auf die SSD verschieben könnte. Es war zu klären, ob das Rechte-System dies erlauben würde.

Wie sich gezeigt hat, war ein einfacher symlink hierfür ausreichend. Es wurde der Ordner /vboxVMs erstellt:

sudo mkdir /vboxVMs

Die virtuellen Maschinen wurden in dieses Verzeichnis verschoben, und rekursiv mit dem Modus 757 versehen:

sudo mv ~/'VirtualBox VMs'/* /vboxVMs/
sudo chmod -R 757 /vboxVMs

Das default Verzeichnis für die virtuellen Maschinen wurde dann gelöscht und der symlink "an selber Stelle gesetzt":

rm -r ~/'VirtualBox VMs'
ln -s /vboxVMs ~/'VirtualBox VMs'

Nach diesen fünf Kommandos waren die virtuellen Maschinen erfolgreich auf die SSD verbracht worden und konnten ohne Änderungen in den Konfigurationsdateien weiterhin ganz normal gestartet / betrieben werden. Sollte man den Speicherort ohne symlink ändern wollen, so könnte man das allerdings auch tun, indem man eben in der Konfigurationsdatei VirtualBox.xml den Pfad ändert. Diese Konfigurationsdatei war bei mir im Ordner ~/.config/VirtualBox zu finden. Der Speicherpfad für die virtuellen Maschinen ist in der .xml bei "defaultMachineFolder" eingetragen.