Opened 3 years ago

Last modified 3 years ago

#17139 new bug

[Package Kit] Failed to download package haiku

Reported by: Scratch Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Kits/Package Kit Version: R1/beta3
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by diver)

I am unable to get downloads to complete after multiple tries throughout the day over several days.

I have installed beta3 from downloaded 32bit and 64bit images on three laptops and the initial updates could be downloaded and installed.

On all three machines, updates starting with the r1~beta3_hrev55181_51-1 to r1~beta3_hrev55181_52-1 entry are slated to download but never get past the first item.

The error message box Updates did not complete; Failed to download package haiku appears every time. There are a total of 7 items to this download all having to do with the same revision mentioned above.

Is there a way to download these with a torrent which is much less crash prone than the current scheme?

Attachments (5)

1.jpg (783.4 KB ) - added by Scratch 3 years ago.
2.jpg (736.0 KB ) - added by Scratch 3 years ago.
3.jpg (635.7 KB ) - added by Scratch 3 years ago.
4.jpg (663.3 KB ) - added by Scratch 3 years ago.
5.jpg (737.4 KB ) - added by Scratch 3 years ago.

Change History (18)

comment:1 by diver, 3 years ago

Component: - GeneralKits/Package Kit
Description: modified (diff)
Summary: Updates crash[Package Kit] Failed to download package haiku

comment:2 by nephele, 3 years ago

Did you try with SoftwareUpdater? if so could you try "pkgman update haiku" in the terminal and report the output here?

also the output of "pkgman list-repos"

comment:3 by Scratch, 3 years ago

Yes this was all in SoftwareUpdater which "reliably" fails.

This was a fresh install of beta3 from downloaded DVD images, 32 and 64 bit, both affected same way.

This is what Terminal:home:pkgman shows --

Welcome to the Haiku shell.

~> pkgman update haiku 100% repochecksum-1 [65 bytes] Validating checksum for Haiku. . .done. 100% repocache-2 [4.62 KiB] Validating checksum for Haiku. . .done. 100% repochecksum-1 [64 bytes] Validating checksum for HaikuPorts. . .done. 100% repocache-2 [1.39 MiB] Validating checksum for HaikuPorts. . .done The following changes will be made:

in system:

upgrade package haiku-hrev1~beta3_hrev55181_51-1 to hrev1~beta3_hrev55181_52-1 from repository Haiku upgrade package haiku_devel-hrev1~beta3_hrev55181_51-1 to hrev1~beta3_hrev55181_52-1 from repository Haiku

Continue? [yes/no] (yes) : yes Re-using download '/boot/system/packages/administrative/transaction-3/haiku-hrev1~beta3_hrev55181_52-1-x86_64.hpkg` from previous transaction (partial)

8% haiku-hrev1~beta3_hrev55181_52-1-x86_64... 3.80 MiB/47.54 MiB 13.30 LiB/s * Failed to download package haiku: Connection refused

~>


Welcome to the Haiku shell.

~pkgman list-repos

Haiku

base-url: https://eu.hpkg.haiku-os.org/haiku/r1beta3/x86_64/current identifier: tag:haiku-os.org,2001:repositories/haiku/r1bet3/x86_64 priority: 1

HaikuPorts

base-url: https://eu.hpkg.haiku-os.org/haikuports/master/x86_64/current identifier: tag:haikuports.org,2013:repositories/haikuports/master/x86_64 priority: 1

~>

The above was on my Panasonic CF-30 64 bit laptop running the new CD installed hrev1 beta3 install of Haiku.

by Scratch, 3 years ago

Attachment: 1.jpg added

by Scratch, 3 years ago

Attachment: 2.jpg added

by Scratch, 3 years ago

Attachment: 3.jpg added

by Scratch, 3 years ago

Attachment: 4.jpg added

by Scratch, 3 years ago

Attachment: 5.jpg added

in reply to:  4 comment:5 by madmax, 3 years ago

Replying to Scratch:

After a whole week of trying updates never get past 25%.

That seems too much to be some intermittent issue. I'm guessing you have not had this kind of problem before?

I cannot be more explicit that this!

You were explicit enough before, so not your fault.

The installer is trying to reuse previous partial downloads. I don't think the error message is what you should get if those are somehow broken, and it seems unlikely that it would happen in all three machines, but let's try removing them just in case. Move the transaction-'number' directories from /boot/system/packages/administrative/ to somewhere else. You want to remove them from there so that the download starts anew, but you also want to recover their data in case a developer needs something to investigate the issue. Try again (preferably with pkgman update haiku, as you did) and report on your results.

comment:6 by nephele, 3 years ago

After a whole week of trying updates never get past 25%.

That seems too much to be some intermittent issue. I'm guessing you have not had this kind of problem before?

This sounds like some sort of server issue or so, I think I had a similar issue and worked around it.

In this case anyhow the package kit would download up to the 25% or so, get the connection refused error, and then delete the stuff it has appended to the file because it got an error, so resumeable downloads don't actually help in this case :/

comment:7 by Scratch, 3 years ago

On my faster machine (Lenovo T410), I don't find a 'boot' directory but double clicking on the 'HITACHI HTS541680J9SA00' desktop folder shows the 'home' folder. Double clicking on 'system' opens window showing 'packages'. Double clicking on packages opens a new window containing 'administrative'. In 'administrative' there are state folder 29 folders with dates ranging from 2021-07-26 thru 2021-07-31. Next are transaction folder numbered from -1 thru -8. All the transaction-x folders are empty. I managed to create a 'new folder' in the administrative directory but the I am unable to move it or any of the transaction-x folders. The state folders show a long list of 'activated' packages but none from the list I have been trying to download as updates.

in reply to:  7 comment:8 by madmax, 3 years ago

Replying to Scratch:

double clicking on [...] double clicking on [...] double clicking on [...]

You can save quite some clicking and windows with drill-down.

All the transaction-x folders are empty.

So that's not the same machine as the one from comment:3, but having the same problem the theory that partial downloads might have something to do with it is completely discarded and my comments are just noise.

I managed to create a 'new folder' in the administrative directory but the I am unable to move it or any of the transaction-x folders.

When you rename, move or delete content in the system folder, Tracker warns you that you may break something and only allows you to cancel. The same alert tells you to hold down the Shift key if you are really sure of what you are doing to activate the button for the action.

Remove that 'new folder', you were not supposed to create it.

The state folders show a long list of 'activated' packages but none from the list I have been trying to download as updates.

Yes, completely normal. That's data to boot to previous states from the bootloader if something goes wrong, so if anything they contain packages you had installed in the past.

comment:9 by Scratch, 3 years ago

OK, I now know how to drill-down and how to enable the grayed-out keys. I moved the previous transaction folders to the trash as a temporary location w/out emptying the contents of course. Another try at updates ended up exactly the same with the download of the first item failing at something below 10%. A new folder 'transaction-1' folder appeared in the administrative folder and was again empty. Previously I found that our wifi has ethernet jacks for direct connection which I also tried with the same results.

comment:10 by jt15s, 3 years ago

I'm using Haiku in a VM (VMWare Player) and I experience the same issue, though for me pkgman manages to download quite a few updates before displaying the same error message. I do note though that I can retry updating and pkgman will reuse the files from the previous download, unlike what happened with Scratch.

Last edited 3 years ago by jt15s (previous) (diff)

comment:11 by jt15s, 3 years ago

Oops, my mistake, looks like the error message I always get is different. Mine is "interrupted system call" not "Connection refused". Will file a new bug report for this.

comment:12 by Scratch, 3 years ago

Just today, at approx. 10AM Mountain time in the US, I decided to try again after another typical failure as described above. This time updates completed!!!!!!! I proceeded to update installs on two other machines (32 & 64 bit) and even re-installed on hard drives that had nightly versions of beta3. Something has changed and download of hrev1~beta3_hrev55181_62-1 is now consistently successful. What changed exactly? Thanks to who or whatever fixed it!

comment:13 by nephele, 3 years ago

There are severall issues at play that make downloading files again a bit troublesome:

  • Server sometimes returns connection refused spuriously (Is this still an issue?)
  • Package kit deletes file download progress on connection refused
  • Package kit tries to treat files in state/ as partially downloaded
  • Package kit does not understand Range erorr to mean "already fully downloaded"

I think in your case you only got the first two issues here, and most likely the server now does no longer refuse the connection, regardless these are some things to patch to make resumed download more resilient in the future.

Note: See TracTickets for help on using tickets.