Why I Stopped Guessing at Linux Distros and Started Asking AI to Reason Through It

Linux per Prompt: 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

Ich habe Linux öfter installiert, als ich zählen kann. Jedes Mal fiel die Wahl der Distro auf ein Bauchgefühl oder das, was ich zuletzt verwendet hatte. Das Problem dabei: Wenn man etwas Konkretes aufbaut, reicht ein Bauchgefühl nicht aus. Ein Security-Brain-Node, der Docker, PostgreSQL, lokale KI-Modelle und Paketerfassung über drei verschlüsselte Festplatten hinweg benötigt? Das ist ein Architekturproblem, kein Gefühlsproblem.

Dieses Kapitel zeigt, wie man das Gespräch so gestaltet, dass die KI echte Architektur liefert und keine Wikipedia-Zusammenfassung. Du gibst deine tatsächliche Arbeitslast ein, erhältst strukturiertes Denken zurück, ordnest deine Hardware einem Speicherplan zu und erkennst Firmware-Tücken, bevor sie dich Stunden kosten. Am Ende hast du eine wiederholbare Methode, die für jeden Build, jede Hardware und jede Distro funktioniert.

Der erste Prompt ist der wichtigste

Das tippen die meisten Leute in ChatGPT ein, wenn sie über Linux nachdenken:

„Welche Linux-Distro soll ich installieren?"

Und sie bekommen genau das zurück, was zu erwarten ist: eine Liste von Distributionen mit oberflächlichen Beschreibungen. Ubuntu ist anfängerfreundlich. Fedora hat neuere Pakete. Arch ist für Leute, die gerne leiden. Danke, ausgesprochen wenig hilfreich.

Das Problem ist nicht die KI. Es ist der Prompt. Man stellt eine allgemeine Frage und bekommt eine allgemeine Antwort. In dem Moment, in dem man von „Was soll ich installieren?" zu „Das muss diese Maschine leisten können" wechselt, verändert sich das Gespräch grundlegend.

Hier ist das Prompt-Muster, das tatsächlich funktioniert:

1I'm setting up a Linux machine for [specific role].
2My requirements are: [list workloads].
3The machine needs to support: [list services].
4What distribution should I consider and why?

Einfache Struktur. Massiver Unterschied in der Qualität der Ausgabe. Du gibst der KI genug Kontext zum Denken, nicht nur zum Aufsagen.

Was dein Build wirklich braucht

Bevor du diesen Prompt absendest, sei konkret über die Rolle. Sag nicht „ein Linux-Server". Sag, was er tut. Für einen Security-Brain-Node (den Build, durch den diese Serie führt) sieht die Liste der Arbeitslasten so aus:

• Docker-Container, die mehrere Sicherheitstools und Dienste ausführen
• PostgreSQL und Redis für strukturierte Daten und Caching
• Ollama zum Ausführen lokaler KI-Modelle (keine Cloud-Abhängigkeit)
• Zukünftiges NVIDIA-GPU-Passthrough für beschleunigte Inferenz
• Speicherung von Angriffs-Artefakten mit ordentlicher Trennung nach Beweismittelkette
• Verschlüsselter Multi-Disk-Speicher über NVMe, SSD und HDD
• Langfristige Stabilität ohne ständige Unterbrechungen durch Bleeding-Edge-Updates

Das ist keine „Welche Distro"-Frage mehr. Das ist eine Architekturfrage. Und wenn man sie so formuliert, beginnt die KI über Paket-Ökosysteme, Kernel-Support-Zeitpläne, Treiberverfügbarkeit und Community-Tooling nachzudenken. Deine Aufgabe ist es, die Einschränkungen zu liefern. Die Aufgabe der KI ist es, sie durchzudenken.

Wie das Denken aufgeschlüsselt wird

Gib der KI eine solche Arbeitslastliste und du bekommst nicht nur eine Antwort. Du bekommst die Begründung hinter jeder Option. Das ist zu erwarten:

Kali Linux erhält die stärkste Empfehlung. Es basiert auf Debian, was solides Paketmanagement und breite Kompatibilität bedeutet. Die Sicherheitstools sind vorinstalliert oder einen apt install entfernt. Rolling Releases halten die Tools aktuell, ohne die Instabilität von etwas wie Arch. Und die Community konzentriert sich genau auf die Art von Arbeit, für die diese Maschine gedacht ist.

Ubuntu Server landet als Zweitplatzierter. Hervorragende Docker-Unterstützung, riesige Community, LTS-Releases. Aber für einen sicherheitsorientierten Build würde man die ersten zwei Tage damit verbringen, Tools zu installieren, die Kali standardmäßig mitliefert. Es ist eine Allzweck-Grundlage, wenn man eine zweckgebundene braucht.

Debian Stable ist zu konservativ. Die Paketversionen hinken hinter dem zurück, was Ollama und neuere NVIDIA-Treiber benötigen. Man würde ständig mit Backports kämpfen.

Arch Linux hat die frischesten Pakete, aber Rolling-Release-Instabilität auf einer Maschine, die Produktionsdatenbanken und Docker-Dienste betreibt, ist eine Einladung zum Ärger. Ein schlechtes pacman -Syu und die PostgreSQL-Instanz ist ausgefallen.

Fedora Server ist interessant, führt aber RPM-basiertes Tooling ein, das nicht mit dem breiteren Kali/Debian-Ökosystem übereinstimmt, auf das die meisten Sicherheitstools ausgerichtet sind.

Für diesen Build fällt die Wahl auf Kali. Nicht weil es trendy ist oder weil ein YouTube-Video das gesagt hat, sondern weil das Arbeitslastprofil direkt auf das abbildet, wofür Kali entwickelt wurde, und das Debian-Fundament die Stabilität liefert, die Docker und PostgreSQL verlangen. Dein Build könnte in eine andere Richtung weisen. Das ist der ganze Sinn davon, die KI das durchdenken zu lassen, anstatt zu raten.

Das Hardware-Erkennungsgespräch

Wenn die Distribution feststeht, greif noch nicht nach dem ISO. Finde zuerst heraus, mit welcher Hardware du es genau zu tun hast. Hier wird das KI-Gespräch wirklich leistungsstark.

Probiere diesen Prompt:

1You are a security expert and are setting up a clean Kali Linux
2install. I'm sitting in front of the terminal. What commands do
3you want me to run to get you all the specs and hard drives
4available to plan this?

Lies das noch einmal. Du fragst nicht „Wie überprüfe ich meine CPU". Du sagst der KI, sie soll die gesamte Erkennungssequenz entwerfen, basierend auf dem, was sie für die Planung wissen muss. Das ist eine grundlegend andere Interaktion. Du setzt die KI für die Untersuchung ans Steuer, während du die Befehle ausführst und zurückberichtest.

Was die KI anfordert (und warum jede Kategorie wichtig ist)

Du bekommst eine strukturierte Liste von Befehlen zurück, nach Kategorie gruppiert. Keine zufälligen Befehle. Ein gezieltes Erkennungsprotokoll. Das ist zu erwarten:

Firmware-Modus (ls /sys/firmware/efi oder BIOS-Einstellungen prüfen): Dies bestimmt deine gesamte Boot-Strategie. UEFI bedeutet GPT-Partitionstabellen und ESP-Partitionen. Legacy-BIOS bedeutet MBR und andere Bootloader-Konfigurationen. Hier einen Fehler zu machen bedeutet eine Neuinstallation.

CPU und RAM (lscpu, free -h): Kernanzahl und Speichergröße bestimmen, wie viele Docker-Container gleichzeitig laufen können, ob lokale KI-Modelle in den Speicher passen und wie aggressiv die PostgreSQL-Konfiguration sein kann.

Festplatteninventar (lsblk -o NAME,SIZE,TYPE,ROTA,TRAN,MODEL, fdisk -l): Größe, Schnittstellentyp (NVMe, SATA) und Rotationsstatus jeder Festplatte. Das ist das Fundament der Speicherarchitektur.

Controller-Modi (BIOS-Einstellungen, dmesg | grep -i ahci): AHCI vs. RAID vs. IDE-Modus beeinflusst die Festplattenleistung und Linux-Kompatibilität. Einige Controller im RAID-Modus verbergen einzelne Festplatten vor dem Installer.

GPU-Hardware (lspci | grep -i vga, lspci -nn | grep -i nvidia): Aus zwei Gründen entscheidend. Erstens können NVIDIA-GPUs Installer-Abstürze verursachen, wenn sie nicht richtig behandelt werden. Zweitens bestimmt das genaue GPU-Modell, welche Treiberversion später benötigt wird.

Netzwerkgeräte (ip link, lspci | grep -i net): Während der Installation wird Netzwerkzugang für Paket-Downloads benötigt. Zu wissen, ob Intel-, Realtek- oder Broadcom-Netzwerktechnik vorhanden ist, bestimmt, ob Firmware-Pakete benötigt werden.

Vorhandene Partitionstabellen (fdisk -l, blkid): Vorhandene Daten oder Partitionsschemata müssen verstanden werden, bevor etwas gelöscht wird.

SMART-Gesundheit (smartctl -a /dev/sdX): Festplattengesundheitsdaten zeigen, welchen Laufwerken man für die Langzeitspeicherung vertrauen kann und welche unter hoher Last ausfallen könnten.

Das Workflow-Muster

So läuft das in der Praxis ab:

1. Die KI gibt eine Reihe von Befehlen
2. Du führst sie im Terminal aus
3. Du fügst die Ausgabe zurück in den Chat ein
4. Die KI interpretiert die Ergebnisse und stellt Folgefragen
5. Wiederholen, bis das vollständige Bild entsteht

Du musst nicht verstehen, was jede Zeile der lspci-Ausgabe bedeutet. Die KI liest sie, markiert das Relevante und erklärt, was es für deinen Build bedeutet. Betrachte es als kollaborative Fehlersuche: Du bist die Hände, die KI ist die Analytikerin. Diese Arbeitsteilung funktioniert, weil die KI dichte technische Ausgaben schneller verarbeiten kann, als die meisten Menschen sie lesen können.

Die KI interpretiert deine Hardware

Sobald du die Erkennungsbefehle durchgeführt hast, ist hier die Art von Inventar, mit dem du arbeiten wirst (das ist die genaue Hardware für den Build dieser Serie):

• NVMe SSD, 1 TB: Samsung 970 EVO Plus, ca. 3.500 MB/s sequenzieller Lesezugriff
• SATA HDD, 1 TB: Western Digital Blue, 5400 RPM, mechanisch
• SATA SSD, 128 GB: Ältere Kingston, ordentlich aber klein, SMART zeigt erhöhte Temperaturereignisse
• GPU: Intel integriert + NVIDIA GeForce (Hybrid/Optimus-Konfiguration)
• RAM: 32 GB DDR4
• CPU: Intel i7, 8 Kerne / 16 Threads

Rohe Spezifikationen sind nur Zahlen. Was zählt, ist, wie die KI sie auf deine Arbeitslast abbildet. Füge deine Hardware-Ausgabe zurück in den Chat ein und beobachte, wie sie eine Speicherarchitektur ableitet, basierend darauf, wie die Eigenschaften jeder Festplatte zu den zuvor beschriebenen Anforderungen passen.

Dreistufige Speicherarchitektur

Für einen Multi-Disk-Build wird die KI ein gestuftes System vorschlagen, bei dem jede Festplatte die Arbeitslasten übernimmt, für die sie am besten geeignet ist:

Stufe 1: NVMe (das Arbeitstier) für alles, was Geschwindigkeit braucht. Das Betriebssystem, Docker-Container-Speicher, PostgreSQL-Datenbanken, Redis-Daten und Ollama-KI-Modelle. Diese Arbeitslasten erzeugen hohe zufällige I/O-Last, und NVMe bewältigt das mühelos. Diese Festplatte erhält LUKS-Verschlüsselung mit LVM für flexibles Partitionsmanagement.

Stufe 2: SATA SSD (der aktive Arbeitsbereich) für laufende Analysen. Wenn man an einem Fall arbeitet, braucht man schnellen Zugriff auf extrahierte Samples, temporäre Tool-Ausgaben und laufende Daten. Die 128-GB-SSD bietet SSD-Geschwindigkeit, ohne die primäre NVMe mit flüchtigen Dateien zu belasten. Ebenfalls LUKS-verschlüsselt, als dedizierter Arbeitsbereich eingebunden.

Stufe 3: SATA HDD (das Kaltarchiv) für die Langzeitaufbewahrung. Paketmitschnitte, forensische Exporte, Beweisarchive und alles, was existieren muss, aber keinen schnellen Zugriff benötigt. Das mechanische Laufwerk ist hier perfekt: groß, günstig und zuverlässig für sequenzielle Schreibvorgänge. LUKS-verschlüsselt mit einem separaten Schlüssel.

„Lege deine Datenbanken nicht auf rotierende Scheiben, und verschwende keine NVMe-Bandbreite für Dateien, die du zweimal im Jahr öffnest. Passe die Speicherstufe dem Zugriffsmuster an."

Warum die kleine SSD als Root-Disk abgelehnt wird

Hier ist eine Falle, in die man tappen könnte: die kleinere SSD als Root-Disk zu verwenden, um die NVMe für Daten „frei" zu halten. Klingt logisch. Die KI wird dem energisch widersprechen, und hier ist der Grund.

Docker-Images und Container-Volumes allein können auf einer Security-Workstation 40-60 GB verbrauchen. Dazu kommen PostgreSQL-Datenverzeichnisse, Ollama-Modelldateien (die jeweils 4-8 GB groß sein können) und Systempakete, und man braucht mindestens 80-100 GB für eine komfortable Root-Partition. Auf einer 128-GB-Disk lässt das kaum Spielraum für Wachstum. Ein großer Docker-Pull und man ist bei 95 % Kapazität.

SMART-Daten fügen ein weiteres Problem hinzu. Wenn die SSD thermische Drosselungsereignisse protokolliert hat, versagt sie nicht, aber sie ist auch nicht die Festplatte, die man als System-Root haben möchte.

Die NVMe ist die offensichtliche erste Wahl. Schneller, größer, gesünder und genau für die Art von gemischter zufälliger/sequenzieller Arbeitslast gebaut, die eine Root-Partition mit Docker und Datenbanken erzeugt. Nicht zu viel darüber nachdenken.

Die Firmware-Prüfung, die Stunden spart

Hier zahlt sich der Erkennungsprozess aus, bevor ein einziges Byte auf die Festplatte geschrieben wird.

Einer der frühen Erkennungsbefehle könnte zeigen, dass deine Maschine im Legacy-BIOS-Modus läuft. Die Maschine funktioniert im Legacy-Modus einwandfrei. Aber für einen verschlüsselten Multi-Disk-Build ist das falsch. Genau das ist die Art von Dingen, die die KI erkennt und die man selbst vielleicht nicht zu prüfen denkt. Hier ist der Grund, warum es wichtig ist:

Legacy-BIOS + MBR begrenzt auf vier primäre Partitionen pro Festplatte. Für einen Drei-Disk-verschlüsselten Build mit LVM ist das eine echte Einschränkung. Man landet bei erweiterten Partitionen und logischen Volumes auf eine Weise, die unnötige Komplexität hinzufügt.

UEFI + GPT hebt die Partitionsanzahlbeschränkung auf, unterstützt nativ größere Festplattengrößen und bietet einen saubereren Boot-Prozess. Für einen verschlüsselten Multi-Volume-Build ist GPT schlicht das richtige Fundament.

Der nächste Schritt, wenn die KI das meldet: drei Firmware-Änderungen vor der Installation.

1. Auf UEFI-Modus umschalten in den BIOS-Einstellungen
2. Secure Boot deaktivieren (Kalis Installer kann mit Secure Boot umgehen, aber es fügt Reibung während der Ersteinrichtung und Treiberinstallation hinzu, besonders mit NVIDIA)
3. AHCI-Modus verifizieren für SATA-Controller (könnte bereits eingestellt sein, aber bestätigen)

Das ist die Art von Problem, nach dem man nicht sucht, bis es einen erwischt. Es während der Erkennung zu entdecken, bevor der USB-Stick überhaupt geflasht wird, spart echte Zeit und Frustration. Der Firmware-Wechsel dauert fünf Minuten in den BIOS-Einstellungen. Das Problem mitten in der Installation zu entdecken bedeutet, von vorne anzufangen.

Deine wiederholbare Methode

Hier ist, worauf dieser gesamte Prozess hinausläuft: eine Methodik, die für jeden Build, jede Hardware und jede Distribution verwendet werden kann. Das merken.

Schritt 1: Ziele mit Genauigkeit beschreiben. Nicht „Ich möchte Linux", sondern „Ich brauche ein System, das diese Dienste ausführt, diese Arbeitslasten bewältigt und diese Art von Daten speichert." Je spezifischer man ist, desto besser kann die KI über die Optionen nachdenken.

Schritt 2: Die KI die Erkennung entwerfen lassen. Nicht einzelne Befehle googeln. Der KI sagen, welche Rolle sie spielt, und sie bitten, die Untersuchung zu entwerfen. Sie wird nach Dingen fragen, an die man selbst nicht gedacht hätte.

Schritt 3: Ausführen und zurückberichten. Die Befehle ausführen, die Ausgabe einfügen. Du bist die Hände, die KI ist die Analytikerin. Diese Arbeitsteilung funktioniert, weil die KI dichte technische Ausgaben schneller verarbeiten kann, als die meisten Menschen sie lesen können.

Schritt 4: Die KI gegen deine Ziele interpretieren lassen. Rohe Spezifikationen sind ohne Kontext bedeutungslos. Eine 128-GB-SSD ist für eine Media-Server-Root-Partition in Ordnung. Sie ist gefährlich klein für eine Docker-lastige Security-Workstation. Die KI ordnet Hardware den Arbeitslastanforderungen zu und markiert Unstimmigkeiten, die man selbst übersehen würde.

Schritt 5: Iterieren, bis das Bild vollständig ist. Erkennung ist selten eine einzige Runde. Die KI wird Folgefragen stellen. „Was zeigt smartctl für diese ältere SSD?" oder „Ist die NVIDIA-GPU der primäre Displayadapter?" Jede Runde verfeinert den Plan.

„Du musst keine Linux-Befehle auswendig lernen. Du musst wissen, was du aufbaust. Die KI übernimmt die Übersetzung zwischen Zielen und Umsetzung."

Diese Methodik funktioniert, egal ob man einen Heim-Medienserver, eine Entwicklungsworkstation, ein Netzwerkgerät oder ein Penetrationstest-Rig einrichtet. Die Befehle ändern sich. Das Muster bleibt gleich.

Jetzt hast du eine Distro festgelegt, ein vollständiges Hardware-Inventar, einen gestuften Speicherplan und saubere Firmware-Einstellungen. Alles von hier an ist Ausführung. Teil 2 nimmt all das und verwandelt es in ein tatsächliches Partitionsschema: verschlüsselte Volumes, LVM-Layout, Einhängepunkte und das Vorbereitungsskript, das alles validiert, bevor der Installer eine Festplatte berührt. Dort wird der Build real.

Als nächstes: Teil 2: Speicher und Verschlüsselung behandelt das Design verschlüsselter Volumes, das LVM-Layout und das Sicherheitsprüfskript, das deine Hardware vor Beginn der Installation validiert. Terminal bereithalten.