You are not logged in.

#1 2021-07-06 12:58:18

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 386

Archlinux ISO download via BitTorrent

While not a complete Newbie in regards to ArchLinux, I wanted to download the newest image for recovery purposes. I am using rtorrent, but when I try to download the image using the magnet or torrent links, I am only getting a 'couldn't find any tracker'. This doesn't happen with other magnet/torrent links - am I forgetting something here?

Offline

#2 2021-07-06 17:16:56

remanifest
Member
Registered: 2021-07-01
Posts: 11

Re: Archlinux ISO download via BitTorrent

Works perfectly fine for me using qBittorrent. The seeders just pointed to http://169.229.226.30/archlinux/iso/latest/, http://94.247.111.11/archlinux/iso/latest/, and http://140.113.17.5/archlinux/iso/latest/ though.

Looks like it's just swarming from HTTP sources.

Last edited by remanifest (2021-07-06 18:16:15)

Offline

#3 2021-07-06 17:56:05

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: Archlinux ISO download via BitTorrent

remanifest: edit your post and remove the pointless long list of urls. It adds nothing to the post and just makes it a pain for people to have to scroll past.

blind: this has happened before with the magnet link. The torrent link should work fine in rtorrent (it does for me).

Last edited by jasonwryan (2021-07-06 17:57:56)


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#4 2021-07-07 17:41:04

cmm11
Member
Registered: 2018-02-18
Posts: 40

Re: Archlinux ISO download via BitTorrent

Had the same issue, the problem is rtorrent not liking the torrent having no tracker.
Easiest solution is to use another torrent client like deluge.

Last edited by cmm11 (2021-07-07 17:42:06)

Offline

#5 2021-07-11 08:26:58

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 681

Re: Archlinux ISO download via BitTorrent

The issue is that libtorrent's dht implementation utilized by rtorrent, in contrary to libtorrent-rasterbar's(as used by deluge/qbittorrent etc), specifically needs your peer incoming port(s) forwarded propperly, not the DHT port(if set different), but peer incoming port(s), as else magnets without fallback trackers(which is optional in spec) don't ever resolve as initial metadata never downloaded. Additionally, then rtorrent doesn't have any hardcoded DHT bootstrap nodes, so if starting completely fresh(so just newly generated rtorrent profile dir, and not downloaded anything previously i.e. empty dht file still), then even if having forwarded peer incoming port(s), then still won't work, though a workaround is adding into your .rtorrent.rc a scheduled event adding one or more bootstrap nodes after e.g. 5 secs, as cannot happen imidiately, as fails with DHT not up yet, but would then only work if having DHT to 'on' as if 'auto', then you would need time the adding of the magnet before around 5 secs roughly, or whatever defined, or restart rtorrent after addition etc(I scheduled myself an event adding bootstrap node upon torrent/magnet addition, as having dht set to 'auto', and this usually worked, but did fail once for me for some reason). Last, can often take 40-60 secs roughly to initialize/resolve such torrent without fallback trackers, whereas libtorrent-rasterbar clients is within 1-2 secs usually on popular content like arch-iso, as it's dht implementation is more aggresive and/or has been better profiled(lead-dev stated did that alot), and is same with empty dht state even, hence e.g. why I use deluge-console/deluged and not my otherwise favorite rtorrent(-ps(-ch)).

If not wanna install deluge/qbittorrent etc, just for this, then can just install libtorrent-rasterbar and use the magnet2torrent.py script originally by danfolks, though I prefer LordAro's fork with improvements, e.g. option to load into default client through xdg-open, and options for controling overwrite behaviour etc. It hasn't been updated in a while so to work you need delete a few lines - it's in Aur, where I posted link to my fixed version in the last comment there(for libtorrent 1.2.x support): https://paste.c-net.org/BoycottSymbols You could also use aria2c etc, but is very slow just like rtorrent I.e 40-60 secs, transmission is same btw, VS 1-2 secs of libtorrent-rasterbar utilizing scripts/clients. I asked Arvid on his mailinglist some years ago, about why his lib is so much faster for DHT lookups/bootstrap compared to other implementations, and he mainly thought it was because of his(and at bittorrent.inc) fair bit of profiling on this specifically, making biggest diff.

Last edited by mhertz (2021-07-11 15:34:51)

Offline

Board footer

Powered by FluxBB