News Windows-Subsystem für Linux: WSL 1.0 als finale Version im Microsoft Store erschienen

jedi23 schrieb:
Okay dann ist die WSL App im Store, die ja das eigentliche Thema hier ist, also komplett überflüssig.
Nein beides wird gebraucht, denn ohne Distro kannst du WSL aktiviert haben, aber dann wird nichts ausgeführt (eben wie nen Hypervisor installiert, aber keine VM erstellt). Und umgekehrt ohne WSL aktiv zu haben, kannst du die Distro nicht ausführen (kein Hypervisor installiert und ergo is die VM nicht lauffähig).

Du kannst ja auch ohne GPU, aber mit Treiber keine 3D-Anwendung laufen lassen und mit GPU, aber ohne Treiber ebenso keine 3D-Anwendung laufen lassen. Ein bisschen schwanger geht nicht.

Beides wird gebraucht, damit die WSL auch ausgeführt werden kann. Ohne Straße keine Rennwagen und ohne Rennwagen keine Straße.
SI Sun schrieb:
Vielleicht war die für den Namen verantwortliche Person versehentlich mit jemandem im Gespräch, der die Namen für USB Standards definiert hat.
Nein, das Eine beschreibt einfach die Version des verwendeten Typs, das Andere die Version im Ganzen. Ist doch nicht so schwer... restic hat bspw. die Versionsnummer 0.14.0, kann intern aber mit Repos der Version 1 oder 2 arbeiten. Beides kann simultan verwendet werden und wird nicht einfach von Typ 1 auf Typ 2 geändert, weil beide Varianten im Ansatz grundverschieden sind.

In Windows kann ich ja auch Office 2010, 11, 13, 16, 19, 21 oder 365 installieren und niemand beschwert sich über "verwirrende Versionsnummern".
Cornuostium schrieb:
Ich kann dir aber auch nicht mehr genau sagen, was das Problem war.
Nutz einfach die offizielle Installation für $Linux: https://docs.docker.com/engine/install/ Dann läuft das ganz regulär wie in jedem anderen Linux auch. Wenn "geht nicht" bedeutet, dass du in der cmd.exe nicht auf docker zugreifen kannst, hängt das am nicht standardmäßig aktivierten Socket.

Dann einfach die /etc/docker/daemon.json öffnen und durch den hosts Key erweitern:
JSON:
{
    "hosts": [
        "tcp://0.0.0.0:2375",
        "unix:///var/run/docker.sock"
    ]
}
In Windows musst du dann nur die DOCKER_HOST Umgebungsvariable entsprechend setzen.

Ich habs mir aber einfacher (und sicherer) gemacht und eine docker.cmd in %PATH% gelegt:
Code:
@echo off

wsl --distribution $DeineDistro --exec docker %*
Das ruft die docker Binary einfach innerhalb der WSL auf. 🤷‍♂️ Läuft ja problemlos zusammen.
 
  • Gefällt mir
Reaktionen: cbmik und JackForceOne
Yuuri schrieb:
Nein beides wird gebraucht, denn ohne Distro kannst du WSL aktiviert haben, aber dann wird nichts ausgeführt (eben wie nen Hypervisor installiert, aber keine VM erstellt). Und umgekehrt ohne WSL aktiv zu haben, kannst du die Distro nicht ausführen (kein Hypervisor installiert und ergo is die VM nicht lauffähig).
Der einfachste Weg ist eigentlich, wie auch im Artikel erwähnt, einfach in der Eingabeaufforderung oder der Powershell wsl --install einzugeben. Das führt dann alle nötigen Schritte aus und installiert auch direkt Ubuntu als default WSL-Distro.
 
Yuuri schrieb:
Nutz einfach die offizielle Installation für $Linux: https://docs.docker.com/engine/install/ Dann läuft das ganz regulär wie in jedem anderen Linux auch. Wenn "geht nicht" bedeutet, dass du in der cmd.exe nicht auf docker zugreifen kannst, hängt das am nicht standardmäßig aktivierten Socket.
Nein, es gab irgendein Problem mit dem Docker Daemon. Ich weiß aber nicht mehr genau, was es war. Ist schon wieder zu lang her. Ich weiß nur, dass die Lösung entweder nicht trivial war oder eben darauf hinauslief, Docker Desktop zu installieren.
Ich hatte Docker per apt installiert. Und es ging in der Linux-Maschine nicht. Also es ließ sich nicht einmal docker run hello-world ausführen.
Ist am Ende auch egal. Ich wollte nur sagen, dass es durchaus Gründe dafür gibt, Docker Desktop zu nutzen.
 
Mein Win10 hat mir nun auch vorgeschlagen dass ich auf WSL1.0 updaten soll. Gesagt getan, nun geht aber keine einzige Distro mehr.
Verschiedene Fehler bekomme ich und alle “Container“ sind im State “stopped”.
Es meckert nun das ich wohl was mit nestedVM und Co nicht habe. Im Netz habe ich zu meinem Fehler leider nicht wirklich was finden können. Was ich wohl gefunden habe, dass die Kombi Win 10 und AMD EPYC/Ryzen wohl keine NestedVM Funktion hat??? Laut MS wäre hier eine Intel CPU von nöten oder AMD und Win 11 was aber mit meiner 1st Gen nicht wirklich geht??? Selbst alles ”neu“ aufsetzen wäre Hass weil ich die unterschiedlichen Container inkl. optic auf den Terminals konfiguriert hatte SSH usw. Das tue ich mir dann denke ich nicht noch mal an und nutze mein iPad oder Mac für die Art Aufgaben.
Habe nach 30 min aufn Sonntag Abend aufgegeben. Denke damit hat sich dann der Win Rechner ggf zur Daddelkiste only erledigt und geht dann noch weniger an bzw. wird demnächst auf Linux only gewechselt.
 
Cornuostium schrieb:
Nein, es gab irgendein Problem mit dem Docker Daemon. Ich weiß aber nicht mehr genau, was es war. Ist schon wieder zu lang her. Ich weiß nur, dass die Lösung entweder nicht trivial war oder eben darauf hinauslief, Docker Desktop zu installieren.
Ich hatte Docker per apt installiert. Und es ging in der Linux-Maschine nicht. Also es ließ sich nicht einmal docker run hello-world ausführen.
Ist am Ende auch egal. Ich wollte nur sagen, dass es durchaus Gründe dafür gibt, Docker Desktop zu nutzen.

Bei mir gerade anders rum, lange Docker Desktop genutzt, hatte z.b. komische Probleme mit JBoss in einem container.

bei hotdeploy (copy in deployment directory) gab es immer endless-loop zwischen isdeploying und deployed des Artefakts, da hat nur JBoss restart geholfen.

Irgendwann hatte ich, dann Totalausfall: "Docker failed to initialize" / "Docker Desktop shutting down".

Seitdem bin ich auf Ubuntu LTS @WSL2 und lasse dort docker laufen ohne Probleme.

Install in WSL2 Ubuntu:

Bash:
curl -fsSL  https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker-archive-keyring.gpg

sudo add-apt-repository "deb [arch=amd64]  https://download.docker.com/linux/ubuntu  $(lsb_release -cs) stable"

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io

sudo usermod -aG docker $USER
sudo service docker start

Zusätzlich für docker-compose (wenn dieses statt docker compose genutzt wird):

Bash:
sudo curl -SL https://github.com/docker/compose/releases/download/v2.6.0/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
sudo chmod 755 /usr/local/bin/docker-compose
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

sudo service docker restart
 
Zuletzt bearbeitet:
Ok, ich konnte mein Problem lösen. Nach einigem Hin und Her und Systemanalysen habe ich mich daran erinnert, dass ich mal mit der Datei .wslconfig herumgespielt hatte, weil ich in/für Docker etwas mehr RAM brauchte.
Ich habe die Datei .wslconfig einfach mal kurz umbenannt, um zu schauen, ob sich meine WSL Container mit der Standardeinstellung öffnen lassen, und Taa daaa ... sie siehe da, funktioniert wieder.
1669053597651.png

Selbst nachdem ich folgende Zeile auf "true" gesetzt habe,
Code:
# Disables nested virtualization
nestedVirtualization=true

funktioniert es noch. KA warum, aber Docker und WSL lassen sich wieder wie vor dem Update nutzen und mehr brauche ich aktuell auch nicht.
Selbst wenn ich das NestedVM wieder aus "false" setzen müsste, wäre das auch ok, solange ich meine 3 Dinge mit WSL und Docker erledigen kann.
Vielleicht hilft es ja dem einen oder anderen, wo es ein ähnliches Fehlerbild gibt.

Folgende Fehler habe ich beim Öffnen der App Terminals dann immer in der Ausgabe bei den unterschiedlichen Containern gesehen

Versuch eine neue Ubuntu 22.04 hinzuzufügen:
Code:
Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80040323
Error: 0x80040323 (null)

Bestehende Ubuntu Instanz öffnen:
Code:
Wsl/0x80070043

PS:
Ok, ich habe nun nochmal etwas mit dem Eintrag herumgespielt und muss diesen definitiv auf "false" lassen, sonst geht es einfach nicht.
Code:
# Disables nested virtualization
nestedVirtualization=false
Hintergrund scheint hier der Mangel an Integration/Möglichkeiten zu sein, da es scheinbar nicht möglich ist, mit einem AMD Ryzen/Epyc und Windows 10 das Feature NestedVM zu nuzten. Quele https://learn.microsoft.com/de-de/v...rtualization#amd-epycryzen-processor-or-later

AMD EPYC/Ryzen-Prozessor oder höher​

  • Der Hyper-V-Host muss Windows Server 2022/Windows 11 oder höher sein
  • VM-Konfigurationsversion 10.0 oder höher

Schade MS. Windows 11 ist für mich aber bislang keine Option.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: PHuV
Ich möchte jetzt mal meine Erkenntnisse aus meinen Installationsversuchen teilen, vielleicht hilft es ja auch anderen, die sich an die WSL herantasten möchten:

Zunächst einmal weiß ich, dass es einen praktischen Befehl für die PowerShell gibt, der alles automatisch einrichtet. Aber ich möchte den Weg über die Store App gehen.
Das ganze habe ich jetzt auch auf verschiedenen Windows 10 Rechnern ausprobiert und die Auswirkungen sind identisch.

  • Windows Komponente aktivieren und nach dem Neustart die WSL-Store App installieren.
  • Nach der Installation der Ubuntu Distribution aus dem Store erhalte ich folgende Fehlermeldung: WslRegisterDistgribution failed.
  • Aaalso einmal die WSL Store App deinstallieren und Ubuntu startet nun via WSL Systemkomponente.

Jetzt wollte ich mir mal die WSL Version anschauen, aber wsl --version liefert keine Auskunft, das kann wohl nur die Store App. Also mal im System32 Ordner nachgeschaut: v10.0.1941.1566

  • Jetzt wieder die WSL Store App installieren (Alternativ geht's auch mit wsl --update, hierbei wird auch die Store App installiert) und Ubuntu erneut starten. Und tadaa: die nächste Fehlermeldung "Die verpackte Version von Windows-Subsystem für Linux wird von windows-version 10.0.19045.2251 nicht unterstützt."

Tja, nach etwas googlen herausgefunden, dass man das KB5020030 installieren muss! Leider muss man das wohl manuell machen weil Windows Update das bisher nicht automatisch auf meinen Rechnern installiert hat! Außerdem hebt das Update die wsl.exe auf v10.0.1941.2311 an, was eigentlich überflüssig ist, da ja ab jetzt die wsl.exe aus dem WindowsApps Ordner benutzt wird o_O

Jetzt startet auch endlich Ubuntu mit der WSL App aus dem Windows Store! Gleich auch nochmal nachgeschaut, um welche WSL Version es sich jetzt nun handelt.
Code:
wsl --version
zeigt folgendes an:

WSL-Version: 1.0.0.0
Kernelversion: 5.15.74.2
WSLg-Version: 1.0.47
MSRDC-Version: 1.2.3575
Direct3D-Version: 1.606.4
DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows Version: 10.0.19045.2311

(Das die finale WSL-Version 1.0.0.0 auch WSL2 enthält, macht es Einsteigern auch nicht gerade leicher, aber das nur mal am Rande ;) )

Nun erst mal mit
Code:
uname -r
geschaut, welcher Kernel eigentlich genutzt wird: 4.4.0-19041-Microsoft. Okay, es scheint WSL1 aktiv zu sein, auf einem Windows 11 Rechner wird hierbei 5.15.74.2-microsoft-standard-WSL2 gemeldet. Also will ich jetzt zu WSL2 wechseln.

  • Also die Komponente VM-Plattform aktivieren (und ggf. im BIOS aktivieren) und nach dem Neustart
    Code:
    wsl --set-default-version 2
    ausführen.

Unbuntu meldet leider immer noch den alten Kernel.

  • Dazu Ubuntu einmal deregistrieren:
    Code:
    wsl --unregister Ubuntu
    Beim nächsten Start wird Ubuntu mit dem WSL2 Kernel neu initialisiert.

Et voilà, schon ist Linux unter WSL2 eingerichtet.

Schlussfolgerung:
Meine ursprüngliche Frage, was das ganze mit der Windows App soll, bleibt fragwürdig.
Wer die App nicht installiert, kann auch WSL2 nutzen und bekommt auch weiterhin Updates über Windows Update, wie z.B. mittels KB5020030 oder auch neue Kernels, z.B. das Qualitätsupdate WSL Update - 5.10.102.2. Also warum WSL2 zusätzlich auch über Windows Update verteilen? Es werden dann eh weiterhin die beiden Installationwege Systemkomponente und Store App "aktuell" gehalten, wobei die App dabei nur eine Art fast ring darstellt.
So wie ich das Verstanden habe, soll das ganze eine Art Übergang darstellen, so dass in naher Zukunft nur noch über die App aktualisiert wird. Aber mit der Logik kann man dann ja gleich alle Windows Updates in den App Store überführen.
Außerdem unschön: die wsl.exe aus der ursprünglichen Installation wird bei Aufruf quasi überbrückt, wie es auch der Edge Browser macht, wenn man den Internet Explorer startet.
Ich bleibe also dabei, die App ist irgendwie überflüssig, aber wir werden sie nicht mehr los :D
 
Zuletzt bearbeitet:
Das Kernel Update hatte ich vor der WSL 1.0 Version mal vor Monaten via

Code:
wsl --update

Von 4.4.x auf 5.x. gezogen. Merke da aber wenig Unterschied bei den paar Dingen, die ich mache.
 
Zurück
Oben