WSL2/Ubuntu: apt-get stockt ...

WulfmanGER

Commander
Registriert
Juli 2005
Beiträge
2.271
Hallo in die Runde,

ich habe bei 2 PCs Ubuntu unter WSL2 am laufen. Einmal Windows 10 und einmal Windows 11. Auf beiden ist die gleiche Ubuntu-Version drauf (22.04/Jammy...). Anwendungsmässig läuft auch auf beiden das gleiche.

Jetzt wollte ich eine aktuelle Version von mkvtoolnix drauf packen. Wie das geht hab ich von der Seite: https://mkvtoolnix.download/downloads.html#ubuntu

Auf dem Windows 10-System hat es auf anhieb geklappt. Keine Probleme.
Auf dem Windows 11-System dauert ein "sudo apt-get update" mehrere Minuten (steht bei dem mkvtoolnix-Eintrag) - aber dann geht es durch. Ein sudo apt-get upgrade dauert ebenfalls mehrere Minuten (mkvtoolnix...) geht dann aber auch durch.

Hab es auch schon mit aptitude probiert. Kein Erfolg
Im Netz paar Tipps gelesen wie apt-get clean, check aber auch das hilft nicht.

Die /etc/apt/sources.list.d/mkvtoolnix.download.list hab ich auch mal ohne ".download" erstellt - auch das brachte nichts.

Verstehe nicht warum es unter WSL2@Win10 problemlos klappt und unter WSL2@Win11 so lahm ist. Beide Systeme sind generell von Updates etc. auf neusten Stand. Auf beiden war kein "apt-transport-https" installiert - hab ich bei 11 gemacht, als das problem schon da war (steht ja das man das bei Problemen installieren soll). Bei 10 hab ich es direkt installiert.

Woran kann das liegen?


In pi.hole sehe ich unmittelbar nach "update" eine DNS-Abfrage auf den mkvtoolnix-Server - also daran kann es nicht liegen. Auch kann ich den Server von WSL2@Win11 per ping erreichen. Keine Aussetzter. Schlechte Netzverbindung kann ich mir daher auch nicht vorstellen.

Grüße
Wulfman
Ergänzung ()

EDIT:

hab gerade mal versucht ob mir
sudo apt -oDebug::pkgAcquire::Worker=1 update
irgendwas rauswirft - Negativ. Außer das es beim ersten mal mit nur 4-5sek Verzögerung durch ging. Der Klassiker: Man schreibt etwas bei computerbase und schwupp ist das Problem erledigt. Hab dann normal apt update gemacht -> warte*warte*warte... abgebrochen. Dann noch mal den Debug-Befehl dauert jetzt ewig und bringt auch keine Fehlermeldungen....
 
Zuletzt bearbeitet: (vertipper)
Blöde Frage: Aber bevor Du das Repository hinzugefügt hast, hast Du schon einmal
Bash:
apt update && apt upgrade
ausgeführt?
Ergänzung ()

Wulfman_SG schrieb:
Man schreibt etwas bei computerbase und schwupp ist das Problem erledigt. Hab dann normal apt update gemacht -> warte*warte*warte... abgebrochen.
Verstehe ich gerade irgendwie nicht, ist es jetzt erledigt oder nicht?
Ergänzung ()

So wie ich das verstehe, erzwingt dieses apt-transport-https eine Übertragung per https. Möglich, dass er sich dann an den Standard-Ubuntu-Repositories aufhängt, weil die default mit http arbeiten.
 
Zuletzt bearbeitet:
Nein ist nicht erledigt. War nur komisch: das erste mal mit debug hab ich direkt nach "Absenden" hier gemacht und ging quasi sofort durch. Dann noch mal ein normales Update - und stocken. Und Debug-Update stockt jetzt auch wieder. Ubuntu hatte vermutlich nur gerade mal eine gute Zeit ;)

Ich hab auf beiden System exakt das gleiche gemacht:
wget für die Signatur
die 2 Zeile in die Datei geschrieben
sudo apt-get update

Ich hab auch Windows neugestartet - half auch nicht

So wie ich das verstehe, erzwingt dieses apt-transport-https eine Übertragung per https. Möglich, dass er sich dann an den Standard-Ubuntu-Repositories aufhängt, weil die default mit http arbeiten.

hab apt-transport-https erst installiert als es schon am Stocken war von daher - nein problem besteht mit ohne ohne apt-transport-https. Gerade mal deinstalliert - nein weiterhin dauert es 2-3min bis update fertig ist. Es hängt definitiv am mkvtoolnix-Eintrag - aber wie gesagt: ich hab jetzt mehrfach geprüft - da ist nichts - absolut nichts unterschiedlich.

Da ich noch eine alte mkv-Version hatte (die aus dem Standard-Repo), hab ich natürlich ein upgrade gemacht -> auch das stockt an der gleichen Stelle.

Irgendwas bringt das ganze zum stocken....
 
Wulfman_SG schrieb:
Im Netz paar Tipps gelesen wie apt-get clear
Also ich kenne nur
Bash:
apt clean
#ODER
apt auto-clean
Ergänzung ()

Ich schreibe das, weil apt clear bei mir unter Debian 11 eine Fehlermeldung wirft, bist Du sicher, dass apt clear, bzw. apt-get clear richtig ist?
 
_anonymous0815_ schrieb:
Also ich kenne nur
Bash:
apt clean
#ODER
apt auto-clean
Ergänzung ()

Ich schreibe das, weil apt clear bei mir unter Debian 11 eine Fehlermeldung wirft, bist Du sicher, dass apt clear, bzw. apt-get clear richtig ist?
meinte clean - vertipper. Und halt check
 
Hat hier keine mehr eine Idee? Irgendwie doof auf einem gleich aufgesetzten System einmal 1sek und auf dem anderen 5min zu warten - das macht irgendwie keinen sinn...
 
wenn ich jetzt genau wüsste was du meinst - gerne ;) ... bin kein Linux-Experte :(

Code:
Get:7 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages [213 kB]
0% [Working]
das 0% ist das problem-Repo ... dauert ca. 2-3min.

Code:
Ign:8 https://mkvtoolnix.download/ubuntu jammy InRelease
Hit:9 https://mkvtoolnix.download/ubuntu jammy Release
Fetched 1046 kB in 2min 14s (7823 B/s)
Reading package lists... Done

auf dem anderen System sieht das exakt genauso aus (ign, hit) - dauert aber nur die üblichen wenigen Sekunden.

Ich denke aber mal das du eine andere Ausgabe haben möchtest?
 
Zurück
Oben