search

GrapheneOS-Archive / legacy_bugtracker

See the new issue tracker for GrapheneOS at https://github.com/GrapheneOS/os_issue_tracker.
112 stars 11 forks source link

Downloading updates often fail #448

Closed wcat closed 7 years ago

wcat commented 7 years ago

it happens quite often that some updates are simply impossible to download on my nexus 5x. The procedure, after a while, fails by telling me that the update download was unsuccessful. It is possible (but I don't know how to check if it is so) that it fails immediately after it has fully downloaded the update (some failure in checking signatures/hashes?). It is happening now with 2016.09.21.10.30.07 and with 2016.09.17.19.33.24. Rebooting the phone or trying many times the download doesn't help. I simply have to wait for other updates.

acabrol commented 7 years ago

I have the same issue for the 3 latest updates on my nexus 6p.

thestinger commented 7 years ago

See https://github.com/copperhead/bugtracker/issues/427.

wcat commented 7 years ago

seems to be a different issue I was getting this error from time to time even before Nougat. Anyway I've updated the Updater app but it still fail. With adb logcat I get:

09-23 17:33:42.557 6972 8555 D DownloadManager: [63] Starting 09-23 17:33:42.681 6972 8296 W DownloadManager: [63] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out 09-23 17:33:42.685 6972 8296 D DownloadManager: [63] Finished with status CANNOT_RESUME 09-23 17:33:44.274 6972 8555 W DownloadManager: [63] Stop requested with status CANNOT_RESUME: Expected partial, but received OK 09-23 17:33:44.274 6972 8555 D DownloadManager: [63] Finished with status CANNOT_RESUME

thestinger commented 7 years ago

That's a genuine issue with your network. The updates are very large since there are no deltas yet (and either way they will only be used if you're on the past version) so it's not surprising that people with flaky connections have issues downloading them.

thestinger commented 7 years ago

Download it on a more reliable connection, or download it on another machine and sideload it.

wcat commented 7 years ago

In the case it is still a bug of the updater since the connection is stable. I can download them with no issues with web browsers/wget/...

I also get those messages before the others:

09-23 17:23:40.618 7937 8292 D DownloadService: Looking for incremental ota for source=2016.09.14.05.23.28, target=2016.09.21.10.30.07 09-23 17:23:40.678 7937 7959 D NetworkSecurityConfig: No Network Security Config specified, using platform default 09-23 17:23:42.041 7937 7937 V DownloadService: Downloading full zip 09-23 17:23:42.117 6972 8296 D DownloadManager: [63] Starting 09-23 17:23:42.155 6972 8296 W System : ClassLoader referenced unknown path: 09-23 17:23:42.155 6972 8296 W System : ClassLoader referenced unknown path: /data/app/com.cyanogenmod.updater-1/lib/arm64 09-23 17:33:42.495 4546 4546 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. c9d92a0 #u0a8/63 DownloadManager:com.android.providers.downloads

I will try by sideloading it.

thestinger commented 7 years ago

In the case it is still a bug of the updater since the connection is stable.

It's not an updater bug. It's not even the updater downloading it, it's Android's standard DownloadManager service as you can see from the log. It's identical to stock Android.

wcat commented 7 years ago

still weird that with the same device/network:

thestinger commented 7 years ago

It doesn't mean it's a bug. It looks like it's timing out, which could be because the speed dropped below a minimum threshold for too long. I'm not going to believe it's a bug without evidence. It works fine for all but a rare few people and it's the standard Android DownloadManager without modifications.

wcat commented 7 years ago

ok I've done some further testing: the issue seems to be in fact related to DownloadManager since even if I use Chromium the connection is still dropped but not if I use Fennec or wget. However it's almost surely not a network issue since the connection is dropped exactly 10 minutes after it starts (I've tested this multiple times). You can see it from the previous logs:

09-23 17:23:42.117 6972 8296 D DownloadManager: [63] Starting 09-23 17:33:42.495 4546 4546 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. c9d92a0 #u0a8/63 DownloadManager:com.android.providers.downloads

another example:

09-24 09:29:29.133 6972 20556 D DownloadManager: [69] Starting 09-24 09:39:29.129 4546 4546 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. 91e3188 #u0a8/69 DownloadManager:com.android.providers.downloads

wcat commented 7 years ago

to make things even more weirder downloading other files with DownloadManager like copperhead factory images doesn't cause the issue. So far it seems that the timeout occurs only with copperhead updates, regardless if the download is started from chromium or from the updates list.

I managed to download the update in less than 10 minutes by using the mobile connection (which is a lot faster) and also with the newest update this issue is still present.

wcat commented 7 years ago

Ok forget the previous post I've probably downloaded the factory image using the mobile connection the issue is always reproducible.

To reproduce it just open logcat: adb logcat | grep DownloadManager and download a file (with DownloadManager, for example by using Chromium) big enough to let the download last more than 10 minutes (or limit the bandwith accordingly) for example this file https://dumps.wikimedia.org/other/pagecounts-ez/wikistats/csv_wp_edits.zip is 8.7GB it should be big enough. Otherwise here there are files of various sizes https://dumps.wikimedia.org/other/pagecounts-ez/wikistats/.

Exactly every 10 minutes the download will get interrupted, and there are two cases:

If you try with the previous link you will experience the first behaviour, this is an example of the output:

09-26 15:59:09.536 21252 23846 W DownloadManager: Path appears to be invalid: /storage/emulated/0/Download/csv_wp_reverts.zip 09-26 15:59:09.653 21252 28847 D DownloadManager: [93] Starting 09-26 15:59:11.418 21252 28847 W DownloadManager: fallocate() not supported; falling back to ftruncate() 09-26 16:09:09.649 4669 4669 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. 1dd9c05 #u0a8/93 DownloadManager:com.android.providers.downloads 09-26 16:09:09.732 21252 29405 D DownloadManager: [93] Starting 09-26 16:09:09.828 21252 28847 W DownloadManager: [93] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out 09-26 16:09:09.829 21252 28847 D DownloadManager: [93] Finished with status WAITING_TO_RETRY 09-26 16:09:12.399 21252 29405 W DownloadManager: fallocate() not supported; falling back to ftruncate() 09-26 16:09:12.556 21252 29405 W DownloadManager: [93] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out 09-26 16:09:12.559 21252 29405 D DownloadManager: [93] Finished with status WAITING_TO_RETRY 09-26 16:09:45.993 21252 29433 D DownloadManager: [93] Starting 09-26 16:09:47.458 21252 29433 W DownloadManager: fallocate() not supported; falling back to ftruncate() 09-26 16:19:45.993 4669 4669 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. 534ce7a #u0a8/93 DownloadManager:com.android.providers.downloads 09-26 16:19:46.072 21252 29816 D DownloadManager: [93] Starting 09-26 16:19:46.157 21252 29433 W DownloadManager: [93] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out 09-26 16:19:46.160 21252 29433 D DownloadManager: [93] Finished with status WAITING_TO_RETRY 09-26 16:19:47.822 21252 29816 W DownloadManager: fallocate() not supported; falling back to ftruncate() 09-26 16:19:47.975 21252 29816 W DownloadManager: [93] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out 09-26 16:19:47.978 21252 29816 D DownloadManager: [93] Finished with status WAITING_TO_RETRY

The issue at hand with the updater is that the resume is not supported on the web server which hosts the copperhead updates, so unless you have a connection faster enough to download it in less than 10 minutes the download is going to fail.

wcat commented 7 years ago

the bug should probably reopened, since the logs prove that almost surely that this is not caused by a network error.

thestinger commented 7 years ago

It's not a bug. We aren't going to be moving away from OpenShift and it prevents having a proper Content-Length for these files which would alleviate most annoyances like this.

thestinger commented 7 years ago

i.e. take it up with OpenShift (the fact that they force gzip compression for all files, don't respect no-transform, and they do it in a non-standards-compliant way that breaks the headers)

wcat commented 7 years ago

well dropping the connection every 10 minutes for "no" reasons is (imho) kind of a bug.

Since sideloading require unlocking the device (and thus wiping the data), as a workaround is there a way to "trick" the updater to use an already downloaded file?

thestinger commented 7 years ago

well dropping the connection every 10 minutes for "no" reasons is (imho) kind of a bug.

It's not for no reason, and it's not a bug.

Since sideloading require unlocking the device (and thus wiping the data)

Sideloading doesn't require unlocking the device.

as a workaround is there a way to "trick" the updater to use an already downloaded file?

No.

thestinger commented 7 years ago

I'm not interested in arguing about this. If someone wants to finally get the Content-Length issue solved, take it up with OpenShift. It's not our fault that it can't track progress.