Failed in attempting to update the source: winget #2666
Comments
ghost
added
the
|
Hello, same here: Actual behavior Logs: Environment: |
|
Same here: Env: |
|
+1 |
|
I'm also having this issue. So I dug deeper into what was happening And then attempted to get the response of the cache directly which resulted in: So it looks like a problem on the CDN? |
It doesn't work - your output still notes that the There are dozens of related issues on this repo (e.g #2664), not sure how many are duplicates because I've seen different error codes in logs. I have the same issue. Possible steps to reproduce (maybe red herring, could just be coincidence)
QuestionsAre there some keys in the registry which need correcting? |
|
When I try to manually download the source.msix file from https://cdn.winget.microsoft.com/cache/source.msix this results in a 0kb file. Seems like this may be the problem. The source has no content. |
|
+1 Same error with different winget versions: |
|
+1 Also same error across multiple machines (4 tested). |
What's the source URL given by |
It should be https://cdn.winget.microsoft.com/cache which is the same as https://winget.azureedge.net/cache
CDN for the production environment has been having a bunch of issue over the past couple of weeks. PPE, INT, & TEST doesn't seem to be affected. |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
..as other have pointed out, this is because a 0 byte file is being returned by the Azure Content Delivery Network (see
|
|
So, after reading through this thread, this sounds like an actual outage issue/bug with the winget cdn, and not a configuration issue on my system? Is that correct? |
@ItzLevvie do you have the URL for the working repositories? I had a catastrophic failure on my drive and had to install a brand new OS. Can't install anything back with Winget for my powershell needs right now. Much appreciated. |
|
cc @ShaguarWKL: You could probably use I do want to point out that there are several packages missing from that source; some of them are outdated; and for some of them — you will also likely run into hash errors.
It's recommended to wait until the |
|
should have read that first :/ ended up with a clean full reinstall of windows for the same result... |
Yeah, almost did that as this error came a day after I fresh installed Win10 due to boot and SSD issues, but I remembered to try system recovery and it did not help either (fortunately you can always undo the system restore). |
|
+1 winget source update |
|
same here / should of read this post first before wasting my day troubleshooting. Can someone please confirm that the winget services is having issues and it's not me or my computer. |
|
I’ve periodically checked the sources.msix throughout the day on multiple isps. The issue definitely lies there
|
|
Well, at least I know that my system isn't broken. However, does anyone have an idea of when this issue will be fixed? |
|
The same question |
damn, we both lost 3 hrs in our life, but mine on searching the whole internet |
|
Same here. I tried every recommendation for this issue but had no luck. I can't even get verbose logs. Temporary Fix: |
|
The cache may be outdated because the client couldn't connect to download the latest preIndexed package. The DO may have policies affecting the behavior of WinGet. If you run |
|
The CDN still has some flakiness issues, it seems; I had to use the "force a different IP" workaround to get things working here just now. Location is US (specifically, central Ohio); IP served was 152.195.19.97. I switched to 152.199.52.147 as suggested above (by way of the new Hosts File Editor in PowerToys; good stuff :) ) and that temporarily mitigated the problem. |
|
resolved in US, now working |
|
Hey everyone. We've been digging through the root cause and believe we may have gotten to the bottom. Publishing has been re-enabled back to its normal automatic cadence.
In administrator mode |
|
Still getting error from US: winget source reset --force winget source update Updating all sources... |
|
@srevo can you run the commands with "--verbose-logs" and share them? |
I've run winget source update --verbose-logs 022-11-10 18:40:05.385 [CORE] WinGet, version [1.3.2691], activity [{E6F1020C-A0E1-4AD6-95F7-2D2448EE400E}] 2022-11-10 18:40:05.832 [REPO] Source add/update failed, waiting a bit and retrying: winget 2022-11-10 18:40:07.889 [REPO] Failed to update source: winget |
|
|
I'm getting errors on my windows 10 machines too. This issue doesn't appear to be resolved. |
|
The {
"$schema": "https://aka.ms/winget-settings.schema.json",
// For documentation on these settings, see: https://aka.ms/winget-settings
// "source": {
// "autoUpdateIntervalInMinutes": 5
// },
}
Would they just be output into console if such policies exist?
|
|
Hi! Same here: Verbose logs: |
|
I have the same issue and same logs as Lupsoris. Using winget v1.3.2691 on Win11. |
|
Some users reported it as solved, but I still see this issue occur in Europe/Germany. Did I miss the workaround? |
Nope. Just have to wait for solution from MS. |
|
Still getting this issue. Any response from Microsoft even acknowledging the issue? |
|
I'm also still having this issue, EU-west 1. It's very annoying. The IP-address is Brazil works fine though. |
|
I don't see the issue anymore from Germany. |
|
Issue appears to be resolved. Tested OK in USA. |
|
Tested again this morning and working fine for me. USA (central Ohio), cdn.winget.microsoft.com resolves to 152.192.19.97 (as it did before). Seems like some nodes have caught up and some are still being twitchy - like a bad replication or something is slowly rippling its way through the whole CDN or something. |
Problem also solved here, Belgium - Europe. |
|
winget source list msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0 winget source update --verbose-logs █████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 1024 KB / 5.12 MB ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0% ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0% Failed when searching source: winget Failed when searching source; results will not be included: winget winget --info Windows: Windows.Desktop v10.0.19045.2251 Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir Links Privacy Statement https://aka.ms/winget-privacy All machines hosted in east us 2 |
|
US - North East, still not working, But my logs look different, I have "Access Denied" sprinkled about |
|
Hello everyone. We've made several changes to our deployments to address the problems here. There were some changes to the way we publish to Azure storage, and permissions on some of the files as well as the CDN configuration. We believe this has all been mitigated with respect to the zero-byte file. We're still tracking: We switched temporarily to a manual CDN purge for a couple of days while we worked through the issue. We have also added the ability to purge the CDN with each publish run, but the code is behind a feature toggle and is currently disabled. If we need to resort to that in the future, it will cause a few minutes of delay for each publish run, but it's available in the event we need it. I'm going to go ahead and close this issue due to the number of people following this and getting e-mail notifications. If you are still encountering trouble, please create a new issue, or find one that appears to be the same so we can try to help with those other classes of issues. |
I see the same here in Germany today. Still not working. Resolution of cdn.* to IP address is OK, but the upgrade command does not work. |
|
Hi! Die Quelle "msstore" erfordert, dass Sie die folgenden Verträge vor der Verwendung anzeigen. Stimmen Sie allen Nutzungsbedingungen der Quelle zu? ...but I do not get possibility to enter "Y (yes) or N (no)". Any ideas? |
and others
Brief description of your issue
winget upgradesays:Will try solutions at Issue #1656 next
Edit:
winget source reset --forceseems to (not) have worked:Steps to reproduce
Run
winget upgradeExpected behavior
Download fresh package list.
Actual behavior
Some kind of exception in WindowsPackageManager.dll
Log from
winget upgrade --verbose-logs:Environment
The text was updated successfully, but these errors were encountered: