Repo.puri.sm & arm01.puri.sm slow

Hardware Librem 5
1

bouncing and slow throughput of repo.puri.sm & arm01.puri.sm.
a download from Ubuntu.com went fine.

does anybody else experience the same?

as of today:

purism@pureos:~$ sudo apt install libshairplay0
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
The following packages were automatically installed and are no longer required:
dleyna-server gir1.2-totem-1.0 gir1.2-totemplparser-1.0 grilo-plugins-0.3 libdleyna-connector-dbus-1.0-1 libdleyna-core-1.0-5 libdmapsharing-3.0-2 libgrilo-0.3-0 liboauth0
libtotem0 python3-xdg
Use ‘sudo apt autoremove’ to remove them.
The following NEW packages will be installed:
libshairplay0
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 99,4 kB of archives.
After this operation, 214 kB of additional disk space will be used.
Err:1 https://repo.pureos.net/pureos byzantium/main arm64 libshairplay0 arm64 0.9.0~git20180824.096b61a+dfsg1-2
Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.pureos.net/pureos/pool/main/s/shairplay/libshairplay0_0.9.0~git20180824.096b61a%2Bdfsg1-2_arm64.deb Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 138.201.228.45 443]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

ak@mi:~/librem5/librem5-flash-image$ sudo ./scripts/librem5-flash-image
[sudo] password for ak:
2023-05-09 15:25:02 INFO Looking for librem5r4 plain byzantium image
2023-05-09 15:25:08 INFO Found disk image Build 14282 ‘plain librem5r4 byzantium image’ from Tue May 9 01:04:58 2023
2023-05-09 15:25:10 INFO Found uboot Build 85 from Thu Aug 25 15:22:41 2022
2023-05-09 15:25:10 INFO Downloading to ./tmp_librem5-flash-image_gokh9_h_
2023-05-09 15:25:11 INFO Downloading image from https://arm01.puri.sm/job/Images/job/Image%20Build/14282/artifact/librem5r4.img.xz
Download: 2%|██▍ | 14761984/896778472 [00:39<51:28, 285617.29it/s]2023-05-09 15:25:52 INFO Connection error, retrying | 62482766/4500000256 [00:39<4:16:44, 288070.08it/s]
Download: 8%|███████████▌ | 70729546/896778472 [01:45<06:46, 2032087.85it/s]2023-05-09 15:26:57 INFO Connection error, retrying | 152799494/4500000256 [01:45<32:09, 2252527.13it/s]
Download: 11%|███████████████▎ | 94331802/896778472 [02:32<10:34, 1264440.12it/s]2023-05-09 15:27:44 INFO Connection error, retrying | 601875064/4500000256 [02:31<13:53, 4677984.83it/s]
Download: 11%|████████████████▋ | 102770576/896778472 [02:55<16:10, 818529.91it/s2023-05-09 15:28:08 INFO Connection error, retrying | 650852829/4500000256 [02:55<12:10, 5268219.05it/s]
Download: 14%|████████████████████▊ | 127646447/896778472 [03:44<14:39, 874126.05it/s]2023-05-09 15:28:57 INFO Connection error, retrying | 783975296/4500000256 [03:44<14:24, 4296791.58it/s]
Download: 52%|████████████████████████████████████████████████████████████████████████████ | 470497561/896778472 [06:18<04:08, 1717473.93it/s2023-05-09 15:31:31 INFO Connection error, retrying██████████████████████████████████████████████████████████████ | 3052688604/4500000256 [06:18<03:57, 6086018.27it/s]
Download: 54%|██████████████████████████████████████████████████████████████████████████████▊ | 487106998/896778472 [06:46<03:24, 2004510.65it/s]2023-05-09 15:31:58 INFO Connection error, retrying██████████████████████████████████████████████████████████████▉ | 3113967805/4500000256 [06:46<03:08, 7346317.10it/s]
Download: 71%|███████████████████████████████████████████████████████████████████████████████████████████████████████▍ | 640098859/896778472 [09:00<01:53, 2252156.88it/s2023-05-09 15:34:12 INFO Connection error, retrying███████████████████████████████████████████████████████████████████████████████████▏ | 3718780379/4500000256 [09:00<04:22, 2975841.91it/s]
Download: 73%|█████████████████████████████████████████████████████████████████████████████████████████████████████████▉ | 655019750/896778472 [09:29<01:58, 2046959.13it/s]2023-05-09 15:34:41 INFO Connection error, retrying███████████████████████████████████████████████████████████████████████████████████ | 3746103830/4500000256 [09:29<04:12, 2989396.44it/s]
Download: 79%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████▏ | 706350587/896778472 [10:33<03:06, 1020182.23it/s2023-05-09 15:35:45 ERROR Max connection errors reached, aborting████████████████████████████████████████████████████████████████████████▎ | 3842696140/4500000256 [10:33<00:57, 11485263.97it/s]
2023-05-09 15:35:45 INFO Cleaning up.
Traceback (most recent call last):
File “/home/ak/librem5/librem5-flash-image/./scripts/librem5-flash-image”, line 537, in
sys.exit(main())
File “/home/ak/librem5/librem5-flash-image/./scripts/librem5-flash-image”, line 509, in main
download_image(urljoin(image_ref[‘url’], ‘artifact/{}.xz’).format(IMAGE.format(board)),
File “/home/ak/librem5/librem5-flash-image/./scripts/librem5-flash-image”, line 208, in download_image
for data in stream:
File “/home/ak/librem5/librem5-flash-image/./scripts/librem5-flash-image”, line 153, in resuming_stream
raise PrematureEndException()
main.PrematureEndException

1 Like
2

I am having a very similar issue trying to reflash a Librem 5. I followed Purism’s documentation here. But get much the same message that op received. The terminal starts a download, then reads “INFO Connection error”, and retries/restarts the download. This sequence repeats half a dozen times, until it quits trying the download. At which point, the terminal reads the same “ERROR Max connection errors reached, aborting” that op shows above.

My % of download completion never surpassed like 4%! My internet speed for this computer is 3mb/s download & ~2mb/s upload. So, I assume that is sufficient speed to re-flash a Librem phone, right?

Anyone know what the issue could be here? Thanks.

3

I’m not certain but I think this was a side-effect of the changes that Purism made in order to counter the DDoS attack that was conducted against them. If you want a definite answer, you will have to ask Purism. Someone really should hassle Purism about this!

In any case, I had exactly the same problem a few days ago when downloading a disk image for the Librem 5 (for the purposes of reflashing).

My workaround was to download manually using wget and execute the relevant functions of the flash script manually (since I needed to do some of that anyway in order to jigger with the LUKS encryption after download and before flashing) but that approach may not be for everybody as it requires a fair bit of extra knowledge.

Since I didn’t test this workaround myself, caveat emptor, but a workaround may be to add
--download-attempts 0
when you invoke the flash script. NB: This is a possible workaround. This will not stop the download repeatedly disconnecting but it may stop it from giving up after a certain number of disconnections.

That isn’t really relevant. The flash script has two distinct phases, performed one after the other.

  1. Download the disk image from Purism to the host computer.
  2. Write the disk image to the phone from the host computer.

(The script has options so that you can execute those phases independently, if you so desire.)

Only the first phase depends on your internet speed - and the first phase is where you are having the problem.

If your internet is anything like my internet, coupled with this Purism problem, your download will turn into a multi-hour nightmare. Allow time accordingly.

3 Likes
4

Wow, quite a thorough & well-written reply. Thanks :+1:
Unfortunatly, my Linux / terminal skill level is not on par with the workaround you described above (yet). I’ll try off-hours, when their servers theoretically see less demand & hope for more success.

I also did not know about the ddos attack! Don’t like that they’re being targeted!

5

All I am saying is that you replace the command
./scripts/librem5-flash-image
from the instructions with the command
./scripts/librem5-flash-image --download-attempts 0

That’s the workaround that I am suggesting to you. I am not suggesting to you the workaround that I myself used.

1 Like
6

Passing --stable

  • ensures one gets a validated image
  • use another server that is not prone to the download issues that arm01 is sometimes seeing
3 Likes
7

What do you mean by ‘Passing’? Does that mean to append the script recommended by the post above you with the suffix “- - stable”?
Thus:
./scripts/librem5-flash-image --stable

8

Yes, that’s what he means.

1 Like
9

I tried again recently. Fortunately, donwload speeds were much improved. Librem phone image downloaded in ~ 68 minutes, with only three ‘Connection error’ incidents.

Whether I need it for this install, or in the future, I’ll remember I can augment DL restart behavior by suffixing this type of script with “–download-attempts 0”