Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WinRPM.update() error reporting error code: 2148270085 #57

Open
hustf opened this issue Oct 24, 2015 · 27 comments
Open

WinRPM.update() error reporting error code: 2148270085 #57

hustf opened this issue Oct 24, 2015 · 27 comments

Comments

@hustf
Copy link
Contributor

hustf commented Oct 24, 2015

It hurts, sometimes, to use Windows. A related issue: #44

I tried the tagged version, master and nothttpclient branch. Same errors:

julia> WinRPM.update()
INFO: Downloading https://cache.e.ip.saba.us/http://download.opensuse.org/reposi
tories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270085
WARNING: Retry 1/5 downloading: https://cache.e.ip.saba.us/http://download.opens
use.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml
WARNING: Unknown download failure, error code: 2148270085
(...repeated 5 times) 
WARNING: received error 0 while downloading https://cache.e.ip.saba.us/http://do
wnload.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/re
pomd.xml
(...all of the above repeated, but win32 replaced by win64) 

Context:

Julia 0.4.0 Windows 8.1 64 bit
C:\Users\Fro>ping cache.e.ip.saba.us
Ping request could not find host cache.e.ip.saba.us. Please check the name and t
ry again.

C:\Users\Fro>ping download.opensuse.org

Pinging download.opensuse.org [2001:67c:2178:8::13] with 32 bytes of data:
Reply from 2001:67c:2178:8::13: time=58ms
Reply from 2001:67c:2178:8::13: time=58ms
Reply from 2001:67c:2178:8::13: time=58ms
Reply from 2001:67c:2178:8::13: time=58ms

Ping statistics for 2001:67c:2178:8::13:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 58ms, Maximum = 58ms, Average = 58ms
@tkelman
Copy link
Contributor

tkelman commented Oct 24, 2015

Try deleting https://cache.e.ip.saba.us/ from your local sources.list. @staticfloat your cache server is down, any idea what's up?

@staticfloat
Copy link
Member

DNS server went down, but it's back up again now. It's using my personal dynamic DNS server which isn't the stablest of things in the world. @StefanKarpinski is there a way we can get an A record to point cache.julialang.org -> 128.52.178.53? That should be stable as long as I don't destroy the cache server on OpenStack.

@hustf
Copy link
Contributor Author

hustf commented Oct 24, 2015

It works now, thanks. And thanks for the use of you personal server.
If you enable ping requests, that could perhaps be used as a time saver for WinRPM, and opting for a backup url?
Current ping:

C:\Users\Fro>ping cache.e.ip.saba.us

Pinging cache.e.ip.saba.us [128.52.178.53] with 32 bytes of data:
Request timed out.

@staticfloat
Copy link
Member

Since ping's could work while the server process itself is down, my suggested method to check whether the caching server is working or not is to simply visit the cache listing page (https://cache.e.ip.saba.us/).

@tkelman
Copy link
Contributor

tkelman commented Oct 28, 2015

@StefanKarpinski another ping on a related DNS issue: #57 (comment)

@cpminor
Copy link

cpminor commented Oct 30, 2015

I am having the same issue (Julia 0.4.0 / Win 7 / 64 bit) - failing to download file repomd.xml as above - but with error code: 2148270088. I removed the reference to the cache site from sources.list file in dir WinRPM. Confirmed that

http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_13.2/repodata/repomd.xml

is a valid file. Neither worked. Fixed issue by following the fix provided in related issue #44. Replaced the sites in sources.list with the Warwick sites. Worked!

@tkelman
Copy link
Contributor

tkelman commented Oct 30, 2015

Roughly where are you physically located? The opensuse mirrors are a little flaky, and we explicitly don't mirror that top repomd.xml file since it gets auto-updated frequently.

@tkelman
Copy link
Contributor

tkelman commented Nov 1, 2015

The cache server is down again. @StefanKarpinski we need you to do something about this.

@cpminor
Copy link

cpminor commented Nov 2, 2015

@tkelman
I am working in the U.S. north east. I was able to view and download what looks like a functional version of the repomd.xml file from the opensuse.org server in a browser, but was getting the return code error both with and without the reference to the cache in the links to opensuse.org in WinRPM's sources.list when trying to use WinRPM to install binaries needed for Gadfly, HDF5, and other packages.

@tkelman
Copy link
Contributor

tkelman commented Nov 2, 2015

@cpminor if the normal link doesn't work but changing to a different mirror does, I think that may be an issue on opensuse's side? Though it's worth trying some of the workarounds as in #40 (comment) of using a different download command, either curl or powershell rather than the IE API that's being used here. Long-term I think all of the downloading that this package, BinDeps, and Base.download are doing needs to be refactored to work more reliably.

@cpminor
Copy link

cpminor commented Nov 2, 2015

@tkelman - given that both the cached version and the opensuse versions of the file give an error when the file is both downloadable and human readable makes me think that an errant line return or binary character slipped in somewhere. WinRPM doesn't attempt any file cleanup (like running text files through *nix tr -d "\15\32" < file > file_new to remove errant ^M's from Windows contamination - a problem I have seen recently trying to compile other open source packages in Cygwin) it just bails out on any non-zero return code. I am also working from behind a proxy and haven't had any issues with Pkg functions after setting up proxy environment variables for git. A unified downloading mechanism with sensible fall backs seems like the best choice, aka the discussion at #40 (comment). I also wonder if the file couldn't be cached locally for some period of time as a further fall back.

@tkelman
Copy link
Contributor

tkelman commented Nov 2, 2015

The file is downloadable and human readable through your browser, but browsers go to a lot of effort to work properly with proxy settings. The error code you were seeing translates to INET_E_DOWNLOAD_FAILURE - https://msdn.microsoft.com/en-us/library/ms775145(v=vs.85).aspx, whereas the initially reported error was INET_E_RESOURCE_NOT_FOUND.

@cpminor
Copy link

cpminor commented Nov 2, 2015

@tkelman Nice work! I was looking for that error code myself and could not find it. My proxy settings are in both git config and Windows environment variables, and they seem to be working downloading non-WinRPM managed packages and to Warwick site (and others as well). But I am certainly not an expert on IE or Windows with proxy settings, so there could be an issue there I am just not yet aware of.

@digital-carver
Copy link

I got the same WARNING messages as @hustf , except the error code in my case was 2148270105. This is on Windows 7 64-bit, with Julia version 0.4.2.

Removing the two cache.e.ip.saba.us lines and replacing those with

http://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win32/openSUSE_Factory/
http://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win64/openSUSE_Factory/

(as suggested in this thread) seems to have resolved the problem.

@nalimilan
Copy link
Member

I see the same problem (error 2148270088, INET_E_DOWNLOAD_FAILURE) on a Windows 7 64-bit machine at my lab here. Neither removing the cache.e.ip.saba.us part nor moving to ftp5.gwdg.de made any difference, with either HTTPS or HTTP. Calling download on these URLs gives the same error. FWIW, I can browse these addresses just fine in both IE and Firefox.

If I pass a URL to a non-existent file, I get error 2148270086 (INET_E_OBJECT_NOT_FOUND) instead. So things are not completely broken. Also, if I use FTP instead of HTTP, Base.download returns without any error and without creating any file; but WinRPM.download (which uses URLDownloadToCacheFileW) still fails.

FWIW, downloads work from R, which uses InternetOpenUrl (with flags INTERNET_FLAG_KEEP_CONNECTION and INTERNET_FLAG_NO_CACHE_WRITE). It could be interesting to test another version based on this API for testing.

I've done a lot of research, but I couldn't find much information. Here are a few possibly interesting links:

@pfitzseb
Copy link

pfitzseb commented Mar 4, 2016

Just as another data point: I'm getting a similar error, error code: 2148270094, on several Windows machines in the uni network and deleting the cache prefix in sources.list gets rid of it.

@cpminor
Copy link

cpminor commented Mar 4, 2016

I recently had another round of download failures with WinRPM.jl as well. I was able to fix it by using the ftp5.gwdg.de site with FTP protocol in place of HTTP or HTTPS. So my sources.list file is now:
ftp://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win32/openSUSE_Factory/
ftp://ftp5.gwdg.de/pub/opensuse/repositories/windows:/mingw:/win64/openSUSE_Factory/

 ----------------------Christian Minorchristian.minor@yahoo.com

On Monday, January 11, 2016 8:50 AM, Milan Bouchet-Valat <notifications@github.com> wrote:

I see the same problem (error 2148270088, INET_E_DOWNLOAD_FAILURE) on a Windows 7 64-bit machine at my lab here. Neither removing the cache.e.ip.saba.us part nor moving to ftp5.gwdg.de made any difference, with either HTTPS or HTTP. Calling download on these URLs gives the same error. FWIW, I can browse these addresses just fine in both IE and Firefox.If I pass a URL to a non-existent file, I get error 2148270086 (INET_E_OBJECT_NOT_FOUND) instead. So things are not completely broken. Also, if I use FTP instead of HTTP, Base.download returns without any error and without creating any file; but WinRPM.download (which uses URLDownloadToCacheFileW) still fails.FWIW, downloads work from R, which uses InternetOpenUrl (with flags INTERNET_FLAG_KEEP_CONNECTION and INTERNET_FLAG_NO_CACHE_WRITE). It could be interesting to test another version based on this API for testing.I've done a lot of research, but I couldn't find much information. Here are a few possibly interesting links:

@nalimilan
Copy link
Member

@pfitzseb That's the same error code as JuliaInterop/ZMQ.jl#90. (But note that you should also ensure you're using the latest WinRPM version, as the old caching server's certificate expired: a new server needs to be used.)

@pfitzseb
Copy link

pfitzseb commented Mar 4, 2016

Thanks @nalimilan, it seems most probably that that's the issue I'm seeing also. WinRPM is up to date, but I'm on Windows Server 2016, so the Enhanced Security thingy in IE is there as well.

@isuruf
Copy link

isuruf commented Sep 1, 2016

@nalimilan
Copy link
Member

We keep getting reports about this, we really need to find a solution or at least a workaround.

@ssfrr
Copy link

ssfrr commented May 19, 2017

I'm seeing this on Appveyor right now, but with error code 2148270105: https://ci.appveyor.com/project/ssfrr/portaudio-jl/build/1.0.39/job/6j3wy392wh0qbyna

It's been non-functional for the last 12 hours or so. Is there any workaround?

@pfitzseb
Copy link

That error seems to indicate a INET_E_INVALID_CERTIFICATE (with 2148270105 == Int(0x800C0019)). Seems to be a server side issue, I guess?

@staticfloat
Copy link
Member

If it's an invalid certificate, it might be SSL versioning problems. We just recently ran into a rash of problems as various services on the internet move away from older SSL versions and start accepting only modern ciphers such as those within TLS 1.1+. Powershell, for example, by default does not enable these modern ciphers unless you ask nicely with a line such as this one.

That being said, I can't imagine this is exactly that problem, because you're asking for an http:// url from the caching server, and it should be HTTP 301'ing you directly on to the source for all those repomd.xml files. So unless there's a problem with appveyor being able to connect to the cache.julialang.org server (there shouldn't be; everybody should be able to communicate over TLS 1.0, which the caching server supports) I'm not sure where this error is coming from.

Do those WinRPM operations work locally on your device?

@staticfloat
Copy link
Member

Huh, another thing to look at is that requests for WinRPM have been coming in with weird data, perhaps there is some kind of data corruption happening to the requests. I regularly log things like

"GET /http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_42.2/repodata/0a9a98ccc672b646a0694a73cc890d253c689e14ecf8413bf3dc09388fbf98dc-primary.xml.gz???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? HTTP/1.0"

on the caching server side.

@ssfrr
Copy link

ssfrr commented May 19, 2017

my issue seems to be resolved now on appveyor. I didn't get to a windows machine in time to check whether it was broken locally.

@skanskan
Copy link

I solved the problem editing the file sources.list and removing the string

https://cache.julialang.org/

That means replacing

https://cache.julialang.org/http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_42.2
with
http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_42.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants