Slackware unter WSL: Warum eigentlich Slackware und wie man es installiert

13.08.2026 7 Min. Lesezeit

Das Windows Subsystem for Linux, kurz WSL, ist inzwischen eine ziemlich bequeme Möglichkeit, eine Linux-Umgebung direkt unter Windows zu betreiben. Wer eine Linux-Shell, Compiler, Skripte oder Entwicklungswerkzeuge benötigt, muss dafür keine virtuelle Maschine mehr aufsetzen.

Bei der Auswahl der Distribution landet man allerdings sehr schnell bei Ubuntu. Das ist nachvollziehbar: Ubuntu ist gut dokumentiert, wird von Microsoft prominent unterstützt und lässt sich mit wenigen Klicks oder einem einzigen Befehl installieren.

Aber muss es deshalb Ubuntu sein?

Für meinen Anwendungsfall lautet die Antwort: nein. Ich wollte bewusst Slackware unter WSL einsetzen.

Warum Slackware unter WSL?

Slackware ist nicht die Distribution, die man typischerweise als erste Antwort auf die Frage „Welche Linux-Distribution soll ich unter WSL verwenden?“ bekommt.

Gerade das macht sie für mich interessant.

Slackware verfolgt einen sehr geradlinigen Ansatz. Es gibt wenig Magie zwischen dem Administrator und dem System. Konfigurationen liegen dort, wo man sie erwartet, Pakete werden nicht von einer Vielzahl zusätzlicher Abstraktionsschichten verwaltet und das System bleibt vergleichsweise transparent.

Für eine WSL-Umgebung ist das durchaus attraktiv.

WSL selbst stellt bereits einen großen Teil der Infrastruktur bereit, die bei einer klassischen Linux-Installation notwendig wäre. Es geht also weniger darum, unter Windows einen vollständigen Server mit eigener Hardwareabstraktion zu simulieren. Stattdessen möchte ich eine möglichst schlanke und nachvollziehbare Linux-Umgebung bekommen.

Slackware passt gut zu diesem Ansatz.

Das WSLackware-Projekt bietet dafür ein für WSL angepasstes Slackware-Root-Dateisystem an. Für meinen Anwendungsfall verwende ich die dort angebotene Installationsvariante 3: WSL Import.

WSL selbst installieren

Bevor Slackware ins Spiel kommt, muss zunächst WSL auf dem Windows-System vorhanden sein.

Ich installiere WSL dabei zunächst ganz normal mit den Windows-Bordmitteln. WSL und die eigentliche Linux-Distribution sind dabei zwei unterschiedliche Dinge: WSL stellt die Umgebung bereit, in der anschließend eine Distribution ausgeführt wird.

Für diesen Artikel gehe ich davon aus, dass WSL bereits eingerichtet ist.

WSLackware installieren

Für Slackware verwende ich das Projekt WSLackware von MahStudio.

Ich verwende bewusst Methode 3: WSL Import.

Der Vorteil dieser Variante ist für mich, dass sie sehr direkt ist. Es wird kein zusätzlicher Installer benötigt. Stattdessen erhält man ein install.tar.gz, das direkt als Root-Dateisystem in WSL importiert wird.

Nach dem Download der gewünschten WSLackware-Version liegt beispielsweise eine Datei

install.tar.gz

vor.

In meinem Fall erfolgt der Import mit:

wsl.exe --import WSlackware C:\WSlackware .\install.tar.gz

Die drei entscheidenden Parameter sind dabei:

WSlackware – der Name, unter dem die Distribution in WSL registriert wird
C:\WSlackware – das Verzeichnis, in dem WSL das Dateisystem der Distribution ablegt
.\install.tar.gz – das zu importierende Root-Dateisystem

Nach dem Import ist Slackware als eigene WSL-Distribution registriert.

Das lässt sich anschließend beispielsweise mit

wsl.exe --list --verbose

überprüfen.

Die ersten Schritte nach dem Import

Wer bisher nur Ubuntu unter WSL verwendet hat, könnte an dieser Stelle etwas überrascht sein.

Bei einer klassischen Ubuntu-Installation wird man durch einen Einrichtungsprozess geführt. Benutzername und Passwort werden abgefragt und anschließend landet man direkt in einer mehr oder weniger fertigen Benutzerumgebung.

Beim direkten Import eines Root-Dateisystems ist das anders.

Hier importiert WSL zunächst genau das, was im Archiv enthalten ist.

Bei der von mir verwendeten install.tar.gz gibt es deshalb nach dem ersten Start keinen klassischen Installationsassistenten, der die komplette Einrichtung übernimmt.

Der erste Schritt ist daher, selbst einen normalen Benutzer anzulegen.

Zum Beispiel:

adduser

Dabei sollte man nicht dauerhaft als root arbeiten. root wird für administrative Aufgaben benötigt; für die normale Arbeit sollte ein eigener Benutzer verwendet werden.

Den Standardbenutzer für WSL festlegen

Mit dem Anlegen des Benutzers ist allerdings noch eine Kleinigkeit zu erledigen.

Ohne weitere Konfiguration startet eine neue WSL-Session weiterhin als root. Damit sich Slackware wie eine normale Linux-Installation verhält, lege ich deshalb in /etc/wsl.conf den gerade angelegten Benutzer als Standardbenutzer fest:

[user]
  default=shl

Dabei ist shl natürlich durch den eigenen Benutzernamen zu ersetzen.

Danach sollte die WSL-Distribution einmal vollständig beendet und neu gestartet werden, damit die Änderung wirksam wird.

Damit landet man bei einem normalen Start direkt beim eigenen Benutzer und muss nicht jedes Mal von root auf den Arbeitsbenutzer wechseln.

Von der Minimalinstallation zur vollständigen Slackware-Installation

Die importierte WSLackware-Installation ist zunächst bewusst schlank.

Das ist für manche Anwendungsfälle bereits genau das Richtige. Wer lediglich eine kleine Shell-Umgebung oder bestimmte Werkzeuge benötigt, muss nicht zwangsläufig eine vollständige Slackware-Installation daraus machen.

Ich wollte dagegen eine möglichst vollständige Slackware-Umgebung.

Dafür kommt slackpkg ins Spiel.

Zunächst muss in /etc/slackpkg/mirrors ein passender Mirror für die verwendete Slackware-Version aktiviert werden.

Anschließend wird die Paketdatenbank initialisiert:

slackpkg update gpg
slackpkg update

Danach können neue Pakete installiert werden:

slackpkg install-new

Wer aus der minimalistischen Installation eine deutlich vollständigere Slackware-Umgebung machen möchte, kann anschließend das Meta-Paket slackware64 installieren:

slackpkg install slackware64

Damit lässt sich aus dem schlanken Ausgangssystem Schritt für Schritt eine wesentlich umfangreichere Slackware-Installation machen.

WSL als echtes Linux-System

Bis hierhin könnte man Slackware unter WSL noch als besonders komfortable Linux-Shell betrachten.

Mit einer weiteren Konfiguration wird es aber deutlich interessanter.

Aktuelle WSL-Versionen bieten neben dem klassischen NAT-Netzwerk auch weitere Netzwerkmodi. Insbesondere der mirrored mode kann interessant sein, wenn die Linux-Umgebung stärker in das Windows-Netzwerk integriert werden soll.

Für Szenarien, in denen die WSL-Instanz selbst aus dem Netzwerk erreichbar sein soll, ist das ein entscheidender Unterschied zum klassischen WSL-NAT-Modell.

Damit wird beispielsweise ein Zugriff auf einen in Slackware laufenden SSH-Server möglich.

SSH in Slackware aktivieren

Slackware bringt mit sshd den klassischen OpenSSH-Server mit.

Nach der entsprechenden Konfiguration kann der Dienst zunächst manuell gestartet werden:

/etc/rc.d/rc.sshd start

Wenn SSH bei jedem Start der WSL-Instanz automatisch aktiviert werden soll, kann man das ebenfalls über /etc/wsl.conf erledigen.

Meine Konfiguration sieht dann beispielsweise so aus:

[user]
  default=shl

[boot]
  command="/etc/rc.d/rc.sshd start"

Damit passieren beim Start zwei Dinge:

WSL startet direkt mit meinem normalen Benutzer shl.
Der SSH-Dienst wird beim Start der Distribution aktiviert.

Natürlich sollte ein SSH-Server nicht einfach ungeschützt ins Netzwerk gestellt werden. Insbesondere bei einer aus dem Netzwerk erreichbaren WSL-Instanz sollte man sich Gedanken über Authentifizierung, Firewall-Regeln und die erlaubten Netzwerkzugriffe machen.

Und plötzlich fühlt sich WSL wie ein echtes Linux an

Genau diese Kombination finde ich an diesem Setup besonders interessant.

Windows stellt die Virtualisierung beziehungsweise WSL-Infrastruktur bereit.

Slackware läuft darin als eigenständige Linux-Umgebung.

Die WSL-Netzwerkkonfiguration sorgt dafür, dass die Umgebung bei Bedarf aus dem Netzwerk erreichbar ist.

Und SSH stellt die klassische Remote-Administration bereit.

Damit kann ich mich beispielsweise von einem anderen Rechner per SSH auf meine Slackware-Instanz verbinden.

Noch interessanter wird das Ganze, wenn man die Maschine nicht nur interaktiv administriert, sondern beispielsweise mit Ansible verwaltet.

Dann sieht die WSL-Instanz aus Sicht eines Administrators kaum noch anders aus als ein kleines physisches oder virtuelles Linux-System:

             Windows
                │
                │ WSL
                ▼
        ┌─────────────────┐
        │   Slackware     │
        │                 │
        │      sshd       │◄──── SSH
        │                 │
        └─────────────────┘
                ▲
                │
             Ansible

Das ist natürlich kein vollständiger Ersatz für eine klassische VM oder einen echten Server. WSL bleibt eine von Windows bereitgestellte Umgebung.

Für Entwicklungs-, Test- und Automatisierungsaufgaben ist diese Kombination aber ausgesprochen praktisch.

Warum nicht einfach Ubuntu?

Damit ist auch die ursprüngliche Frage beantwortet.

Wenn das Ziel lediglich lautet:

Ich brauche irgendein Linux unter Windows.

dann ist Ubuntu wahrscheinlich die naheliegendere Wahl.

Wenn das Ziel dagegen lautet:

Ich möchte eine schlanke, transparente Linux-Umgebung, die ich selbst konfigurieren und anschließend wie ein Linux-System per SSH und Ansible verwalten kann.

dann wird Slackware unter WSL plötzlich interessant.

Der Weg ist dabei etwas weniger bequem als bei einer vorkonfigurierten Distribution.

Aber genau darin liegt für mich der Reiz.

Ich bekomme kein System, das mir möglichst viele Entscheidungen abnimmt. Ich bekomme eine Basis, aus der ich mir meine eigene Linux-Umgebung bauen kann.

Und dann kommt Zscaler

Damit ist die eigentliche Slackware-Installation geschafft.

In einer privaten Umgebung wäre damit wahrscheinlich bereits der wichtigste Teil erledigt.

In einer Unternehmensumgebung wartet allerdings unter Umständen noch ein anderes Problem.

Wenn der Windows-Rechner durch eine Corporate-Sicherheitsinfrastruktur wie Zscaler geschützt wird, vertraut Windows möglicherweise einer unternehmensinternen Root CA, während Slackware diese CA noch nicht kennt.

Der Browser unter Windows funktioniert.

curl unter Slackware dagegen möglicherweise nicht.

Die Lösung besteht darin, die von der Unternehmensumgebung bereitgestellte Root CA in Slackware zu importieren und den Linux-Trust-Store entsprechend zu aktualisieren, aber das beschreibe ich im Detail an anderer Stelle.