How AI Designed a Storage Layout I'd Have Spent Days Planning Myself

Prompt Your Way to Linux: Eine 4-teilige Serie

Teil 1: Die richtige Distro wählen → Teil 2: Speicher und Verschlüsselung → Teil 3: Manuelle Installation → Teil 4: Dienste und GPU

Wer schon einmal erlebt hat, wie um 3 Uhr nachts eine Root-Partition vollläuft und das System zum Stillstand bringt, weiß es bereits: Standard-Partitionierung ist eine Falle. Aber ein ordentliches verschlüsseltes LVM-Layout für sechs verschiedene Workloads auf drei physischen Festplatten zu entwerfen? Das ist ein ganzer Tag voller Planung im Alleingang, Dokumentenvergleiche, Größenberechnungen und ständigem Zweifeln an sich selbst.

So lässt man die KI die schwere Arbeit beim Speicherdesign übernehmen, damit man nicht einen ganzen Tag in Man-Pages versinkt. Man gibt die Workload-Anforderungen ein, erhält eine vollständige Architektur mit nachvollziehbarer Begründung zurück und versteht am Ende jede Schicht dessen, was man aufbaut.

In Teil 1 wurde die Distro ausgewählt und die Hardware erfasst. Jetzt kommt der Teil, bei dem die meisten entweder schlechte Standardeinstellungen akzeptieren oder ganz aufgeben: das Speicherdesign.

Mit Workloads beginnen, nicht mit Partitionsgrößen

Die Hardware aus Teil 1 ist erfasst: zum Beispiel ein älteres ThinkPad mit einem NVMe-Laufwerk, einer SSD und einer HDD. Die Spezifikationen zeigen, was möglich ist. Aber Workloads zeigen, was notwendig ist.

So geht man vor: Nicht die KI nach einer Partitionstabelle fragen. Keine Größen vorgeben. Nicht sagen "leg /home auf eine eigene Partition." Stattdessen Verhalten und Anforderungen beschreiben und die Architektur daraus ableiten lassen. Etwa so:

"Diese Maschine wird Docker-Container, PostgreSQL mit TimescaleDB, Redis, Ollama für lokale KI-Modelle betreiben und Angriffs-Artefakte aus einem Honeypot-Netzwerk speichern. Außerdem wird ein verschlüsselter Analyse-Arbeitsbereich benötigt, der vom Betriebssystem getrennt ist, sowie verschlüsselter Archivspeicher für langfristige Beweise. Entwirf die beste Partitionierungs- und Verschlüsselungsstrategie für die drei gefundenen Festplatten."

Der Unterschied ist klar: Es werden Einschränkungen und Ziele übergeben, nicht die Lösung im Detail vorgegeben. Wenn die Begründung stichhaltig ist, wird es das Design auch sein. Und wenn eine Entscheidung keinen Sinn ergibt, fällt das auf, weil man versteht, was die Maschine tatsächlich leisten soll.

Workloads nach Festplattenverhalten sortieren

Als erstes gilt es, Workloads nach IO-Muster zu trennen. Nicht nach Größe, nicht nach Wichtigkeit, sondern danach, wie jeder Workload tatsächlich auf die Festplatte zugreift.

Die drei Spuren

• Hohe IOPS, niedrige Latenz = NVMe. Hier leben Betriebssystem, Docker, Datenbanken und KI-Modelle. Diese Workloads führen viele kleine zufällige Lese- und Schreibvorgänge durch. Sie brauchen den schnellsten verfügbaren Speicher.
• Schneller Scratch-Bereich, isoliert = SSD. Der Analyse-Arbeitsbereich kommt hierher. Er braucht angemessene Geschwindigkeit für die Verarbeitung von Captures und den Betrieb von Tools, aber noch wichtiger ist, dass er vom OS-Laufwerk getrennt ist. Wenn Analysearbeit ein Dateisystem beschädigt oder eine Festplatte füllt, läuft das Betriebssystem weiter.
• Große Kapazität, sequenzielle Schreibvorgänge = HDD. Langfristiger Archivspeicher für Pcaps, Beweissicherungen und Backups. Sequenzielle Schreibleistung ist ausreichend. Kapazität ist wichtiger als Geschwindigkeit.

Allein diese Trennung verhindert den häufigsten Fehlerfall: ein Workload, der einem anderen Festplatten-IO oder Speicherplatz entzieht.

Warum jeder Dienst sein eigenes Logical Volume bekommt

Nicht bei drei Festplatten aufhören. Auf der NVMe den Speicher in sechs separate Logical Volumes aufteilen, jedes mit einem bestimmten Zweck:

• /var/lib/docker wird isoliert, weil Docker Speicher unvorhersehbar verbraucht. Ein außer Kontrolle geratener Container-Build oder vergessener Image-Cache sollte Root nicht füllen können.
• /var/lib/postgresql wird für unabhängige Größenanpassung, Backup-Snapshots und zukünftiges Performance-Tuning isoliert. Datenbanken haben einzigartige IO-Muster, die von dediziertem Speicher profitieren.
• /var/lib/ollama wird isoliert, weil KI-Modelle enorm groß sind und unabhängig wachsen. Ein einzelnes LLM kann 8 GB oder mehr groß sein. Model-Downloads sollen nicht mit dem Betriebssystem um Speicherplatz konkurrieren.
• /home wird isoliert, damit Benutzerdaten, Dotfiles und persönliche Konfigurationen OS-Neuinstallationen überstehen.
• Swap als eigenes Logical Volume, groß genug für Hibernation wenn nötig.
• Root (/) auf eine feste Größe begrenzt, damit nichts außerhalb der vorgesehenen Pfade es füllen kann. Wenn Root voll ist, hört das System auf zu funktionieren. Die Begrenzung ist defensives Design.

Verschlüsselung ist keine Option

Verschlüsselung ist hier keine Option, und die Begründung ist einfach. Dies ist ein Laptop-Formfaktor, der als Sicherheits-Workstation betrieben wird und sensible Daten im Ruhezustand speichert: Honeypot-Captures, Angriffs-Artefakte, Netzwerkanalyse-Ergebnisse. Wenn die Maschine gestohlen, verloren oder außer Betrieb genommen wird, muss jede Festplatte ohne die Passphrase unlesbar sein.

Vollständige Festplattenverschlüsselung mit LUKS ist die Grundlage für diesen Anwendungsfall. Punkt.

Freiraum in der Volume Group lassen

Dieses Detail trennt gutes LVM-Design von amateurhafter Arbeit. Etwa 5-10 % der Volume Group unzugewiesen lassen. Nicht verschwendet. Reserviert. Der Grund:

Mit LVM können Logical Volumes im laufenden Betrieb ohne Neustart vergrößert werden. Wenn Docker in sechs Monaten mehr Platz braucht, wird das LV erweitert und das Dateisystem in Sekunden angepasst. Wenn alles von Anfang an zugewiesen wurde, müsste ein Volume verkleinert werden, um ein anderes zu vergrößern, und Verkleinern ist langsam, riskant und bei bestimmten Dateisystemen manchmal unmöglich.

Absichtlicher Freiraum ist ein Feature, keine Verschwendung.

Das mentale Modell der Speicherschichten

Dieses mentale Modell ist das Wertvollste aus diesem gesamten Kapitel. Nicht die Partitionsgrößen. Nicht die Mount-Points. Dieser 8-Schichten-Stack, der erklärt, wie Linux-Speicher von oben nach unten tatsächlich funktioniert.

Die meisten Fehler, die bei der eigentlichen Installation auftreten, besonders mit fstab und crypttab in Teil 3, entstehen durch Verwechslung dieser Schichten. Eine UUID aus Schicht 2 schreiben, wo Schicht 6 erwartet wurde. Einen Gerätepfad aus Schicht 3 in einer Konfiguration referenzieren, die Schicht 1 benötigte. Jeder Speicherfehler lässt sich auf einen Schichten-Mismatch zurückführen.

Diesen Stack als Lesezeichen speichern. Ihn auf den Unterarm tätowieren. Sobald diese acht Schichten verinnerlicht sind, hört Linux-Speicher auf, mysteriös zu sein. Es sind einfach acht Dinge, jedes mit einer Aufgabe, der Reihe nach verbunden.

Das endgültige NVMe-Layout

Hier ist das vollständige Design für das primäre NVMe-Laufwerk:

Primäre NVMe (nvme0n1)

Innerhalb des LUKS-Containers auf nvme0n1p3:

nvme0n1p3 → cryptnvme (LUKS2) → LVM PV → vgkali (Volume Group)

Sekundäre Festplatten

SSD (sdb): sdb1 → cryptanalysis (LUKS2) → ext4 → /srv/analysis

HDD (sda): sda1 → cryptarchive (LUKS2) → ext4 → /srv/archive

Drei verschlüsselte Festplatten. Sechs Logical Volumes auf der primären. Jeder Workload in seiner eigenen Spur. Nichts teilt Speicherplatz mit etwas, mit dem es das nicht sollte.

Das Design in ein Build-Skript umwandeln

Sobald das Design feststeht, ist der nächste Prompt einfach:

„Gib mir die genauen Befehle, um dieses gesamte Speicher-Layout aus der Live-Kali-Umgebung heraus aufzubauen. Gehe davon aus, dass alle drei Festplatten gelöscht werden können."

Frage nach einem vollständigen Shell-Skript: vorhandene Signaturen löschen, GPT-Partitionstabellen erstellen, Partitionen mit sgdisk anlegen, LUKS2-Container mit sicheren Standardwerten erstellen, diese öffnen, physische LVM-Volumes initialisieren, die Volume-Gruppe erstellen, alle sechs logischen Volumes zuweisen, alles formatieren und dann das LUKS-Setup für SSD und HDD wiederholen.

Rechne mit ungefähr 80 Zeilen. Jeder Befehl sollte nachvollziehbar sein. Wenn dir irgendetwas im Skript keinen Sinn ergibt, bitte die KI, diese spezifische Zeile zu erklären, bevor du sie ausführst.

Was schiefgehen wird (und es wird nicht das Design sein)

Zur Warnung vorab: Das Design wird solide sein. Die Ausführung wird dich herausfordern. Hier sind die Fallen, auf die du achten solltest:

Windows-Zeilenenden. Wenn du das Skript auf einem Windows-Rechner schreibst und es über USB in die Live-Umgebung überträgst, endet jede Zeile mit \r\n statt mit \n. Bash versagt bei jedem einzelnen Befehl, und die Fehlermeldungen sind kryptisch. Behebe das mit sed -i 's/\r$//' script.sh, bevor du irgendetwas ausführst.

Shebang-Beschädigung. Hängt mit dem Zeilenenden-Problem zusammen. Die Zeile #!/bin/bash bekommt einen unsichtbaren Wagenrücklauf, sodass der Kernel den Interpreter nicht finden kann. Der Fehler sieht so aus, als würde das Skript nicht existieren, obwohl es eindeutig vorhanden ist.

Pfadverwirrung. Der USB-Stick wird unter einem bestimmten Pfad eingehängt, aber du referenzierst das Skript aus einem anderen Arbeitsverzeichnis. Tab-Vervollständigung und relative Pfade sind in einer Live-Umgebung unzuverlässig, wenn du mehrere Einhängepunkte jonglierst. Verwende absolute Pfade.

Falsche Ausführungssyntax. Das Vergessen von ./ vor dem Skriptnamen oder das Versäumnis, zuerst Ausführungsrechte zu setzen. Klassische Fehler, die nichts mit dem Speicher-Design zu tun haben, sondern alles mit Muskelgedächtnis.

„KI kann das Skript schreiben, aber du musst trotzdem verstehen, was du einfügst. Wenn ein Befehl für dich keinen Sinn ergibt, halte inne und frage nach."

Sobald die Zeilenenden- und Ausführungsprobleme behoben sind, ist der Speicheraufbau in unter zwei Minuten abgeschlossen. Jeder LUKS-Container öffnet sich. Jede LVM-Struktur wird sauber erstellt. Jedes Dateisystem wird formatiert. Das Design hält stand.

Alles mit dem Einfügen-und-Prüfen-Muster verifizieren

Gehe nicht von Erfolg aus. Nachdem das Skript abgeschlossen ist, füge deine Terminal-Ausgabe wieder in die KI ein und bitte sie, das Ergebnis zu prüfen:

„Hier ist meine lsblk- und lvs-Ausgabe. Wurde alles korrekt aufgebaut?"

Füge die rohe Terminal-Ausgabe ein und bitte die KI, sie Zeile für Zeile durchzugehen. Sie sollte bestätigen: cryptnvme aktiv, vgkali vorhanden mit sechs logischen Volumes in den richtigen Größen, korrekte Dateisysteme auf jedem, sekundäre Festplatten verschlüsselt und formatiert.

Dieses Einfügen-und-Verifizieren-Muster ist eine der nützlichsten Techniken für die Systemadministration mit KI. Du führst einen Befehl aus, fügst die Ausgabe ein und fragst, ob die Realität dem Plan entspricht. Es erkennt Probleme, die du übersehen würdest, weil du zu nah an der Arbeit bist:

• Ein logisches Volume, das versehentlich mit dem falschen Dateisystemtyp formatiert wurde
• Ein Volume, das in Megabyte dimensioniert wurde, obwohl Gigabyte gemeint waren
• Eine fehlende Partition, die das Skript stillschweigend übersprungen hat
• Ein LUKS-Container, der sich nicht wirklich geöffnet hat

Das lässt sich mit fast jedem Systemzustand machen: lsblk, lvs, pvs, vgs, blkid, fdisk -l, cryptsetup status. Einfügen. KI darum bitten, es zu prüfen. Das ist schneller und gründlicher als alles selbst zu überprüfen.

Das Fazit: Design aus Arbeitslasten ableiten, nicht aus Standardwerten

Das hier verwendete Speicher-Layout wurde nicht aus einer Vorlage übernommen oder aus einem Forum-Beitrag kopiert. Es wurde aus tatsächlichen Arbeitslastanforderungen abgeleitet. Docker braucht Speicherisolierung. Datenbanken brauchen dediziertes IO. KI-Modelle brauchen Platz zum Wachsen. Sicherheitsartefakte brauchen Verschlüsselung im Ruhezustand. Archive brauchen Kapazität statt Geschwindigkeit.

Jede Entscheidung lässt sich auf eine echte Anforderung zurückführen. Das ist der Unterschied zwischen einem Speicher-Layout, das sechs Monate übersteht, und einem, das beim ersten unerwarteten Ereignis auseinanderfällt.

Dieser Ansatz funktioniert für jeden Aufbau, nicht nur für Sicherheits-Workstations. Erkläre der KI, was die Maschine tun wird. Beschreibe die Dienste, die Datenmuster, die Wachstumserwartungen, die Fehlerszenarien, die du überstehen möchtest. Dann lass sie herausfinden, wie die Festplatten zu organisieren sind. Die Begründungen, die sie dir zeigt, sind wertvoller als die endgültige Partitionstabelle, denn du wirst verstehen, warum jede Entscheidung getroffen wurde und wann sie möglicherweise geändert werden muss.

Deine Festplatten sind partitioniert, verschlüsselt und in logische Volumes aufgeteilt. Die Architektur ist fertig. Jetzt kommt der Teil, der die meisten Menschen wirklich herausfordert: ein Betriebssystem auf all dem installieren, ohne einen grafischen Installer, der dich an die Hand nimmt.

In Teil 3: Manuelle Installation wirst du die verschlüsselten Volumes einhängen, Kali von Grund auf neu aufsetzen, fstab und crypttab so konfigurieren, dass alles beim Booten entsperrt wird, und eine funktionierende Bootloader-Konfiguration erstellen. Hier wird das 8-Schichten-Modell wirklich auf die Probe gestellt, und eine einzige falsche UUID kann dich vor einem GRUB-Rescue-Prompt stehen lassen. Hol dir Kaffee.