I agree, I've always found that wget works better than aria2c and curl as the urpmi downloader.

or we use aria2 with metalink (needs mirrorbrain or co)

(In reply to Manuel Hiebel from comment #2)
> or we use aria2 with metalink (needs mirrorbrain or co)

Which we don't currently have set up. Switching the default from aria2c to
wget is a very simple change that works with what we have now.

Still valid with Mga7-beta3 (March 24th)

Adding mirrors for the different media always ends up with an error message saying the media couldn't be downloaded, which is misleading since they all seem absolutely usable right away (run # urpmi --auto-update in a terminal to see they are up-to-date).

Pushing the priority up.

Keywords: (none) => 7beta3
CC: (none) => sebsweb
Priority: Normal => High

How do I change drakconf to use wget instead of aria ?
With aria (likely due to my company paranoid proxy) the installation timeout and is impossible to install any new software from GUI.

CC: (none) => mtm_spm

Using rpmdrake, select Options, then select Media Manager.

That will run drakrpm-edit-media.

In drakrpm-edit-media (aka Media Manager), select Options, then Global Options.
Use the selection box for the "Download program to use" and select wget.
Note that wget must be installed for the option to use it to be shown.

If you're using a text only install, edit the global options in
/etc/urpmi/urpmi.cfg and add a line with ...
  downloader: wget

For example, in my system ...
# head -n 6 /etc/urpmi/urpmi.cfg
{
  downloader: wget
  resume: 1
  verify-rpm: 1
  xml-info: always
}

Hi,
This is High priority bug for a good reason.

Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please make the status to Assigned when you are working on this.
Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it.

On October 1st 2020, we will drop priority to normal.

This really is night and day; repeated failures trying to update and install new packages, with default for a couple hours tries now and then!

( Additionally it fail with unspecified error in the popup, should rise a bug for that too; user is completely lost! )

Changed to wget and no failures.

Circumstances: live xfce 64 with persistence on Dell M4400 laptop, wifi, mirror umu.se

Keywords: 7beta3 => 8final
CC: (none) => fri

BTW, default is now not aria, but curl

(Mageia 8 final Live Plasma and Xfce checked)

Summary: Change default downloader from aria2c to wget => Change default package downloader from wget

Doh, thanks, it was late night, deleted wrong set of words... :)

Not being able to update or install new packages is severe and hard to fis for new users who dont know.  The error messages are not helpful at all, as they complain about the packages instead!

I believe the problem is triggered by a combination of wifi harware and router.
(and possibly versions of drivers, protocol...)
Basically always fail on my Dell M4400, never on Thinkpad T400, same router.

IMO it deserves a visual place, so in Errata now:
https://wiki.mageia.org/en/Mageia_8_Errata#Downloading_software

Keywords: (none) => IN_ERRATA8

Another reference: in Bug 28744 report.bug contain a few curl failures, but maybe not enough to point finger at curl.

On my affected laptop Dell Precision M4400, both wget and also aria2 works perfectly.

Without changing from curl it is impossible to update a mga8 install at all, it does not get through the initial batch of gcc, rpm etc packages.

FWIW same problem on my "new" laptop Thinkpad T510
So default setting is failing on 2 of 4 laptops here...

Two recent questions on this from users on our forum:
https://forums.mageia.org/en/viewtopic.php?t=14417

Source RPM: urpmi-8.114-2.mga7.src.rpm => urpmi
Whiteboard: MGA7TOO, MGA8TOO => MGA8TOO
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=28539

Added error message example and urpmi --clean tip to errata.

I'm not against it but I think I remember that at some point we were defaulting to wget which didn't work for some people.

I tried to do a quick search in history.
Prior to 2009, drakx was using its own downloader:
https://gitweb.mageia.org/software/drakx/commit/?id=f1c5acfa0a593ef6ac6cac6fa8d7fbaf7e8600af

Urpmi always defaulted to curl if installed:
https://gitweb.mageia.org/software/rpm/urpmi/commit/?id=c9fdb6d4e5b72adba69f81692ee12c2e20366a85

CC: (none) => thierry.vignaud

As per the start of this bug report, it was aria2c that had the most problems,
then curl, with wget being much more reliable.

I'm not really partial to any of them, provided they work.  If you want to fix curl (or that's an MGA problem rather than a curl problem), that's fine with me.

If we're updating the download support, I did have a previous bug report saying that an install referencing a hostname for the repository did a DNS lookup for each reference rather than do it once and cache the IP address, which would be much more efficient.  Not to mention that it would seem to circumvent this problem, since curl is complaining midstream about no longer being able to resolve the repository hostname.

CC: (none) => ftg

I suspect the main problem with curl is that by default it doesn't retry on transient errors. Using the --retry option could help.

CC: (none) => mageia

Actually, the error reported by curl was that it couldn't resolve a hostname that it had used countless times before in the same install.

Coincidentally, in bug#28539, we see that the install stage1 can't resolve a hostname even though it has been passed a valid DNS server address and installed it in /etc/resolv.conf.  This could be some anomaly between whatever the stage 1 installer and perl in stage 2 uses for DNS as opposed to the standard resolver.

(In reply to Martin Whitaker from comment #20)
> I suspect the main problem with curl is that by default it doesn't retry on
> transient errors.

That default sounds really stupid...!

> Using the --retry option could help.

Is it possible to set the current drak tools to use curl with --retry?

(I could try using it so then for a while as a test)

You can use

  urpmi --downloader curl --retry 5 ...

(you only need the --downloader option if you have configured urpmi to use another method)

thanks, will try that.

Any way to command curl ---retry for the updater app or drakrpm?

According to TV in bug#28539 if you're using the legacy boot image (the one with a command line where you can enter parameters) saying "linux downloader=wget".

I am (also) chasing the problem users have when using mgaapplet and GUI tools for regular updating and program install.

'man urpmi.cfg' tells me you can add the --retry option in /etc/urpmi/urpmi.cfg. I've not tried it.

Tested drakrpm with curl attempting to making it retry by editing /etc/urpmi/urpmi.cfg, per 'man urpmi.cfg' :

Adding the line
    retry
After the line specifying the downloader does not work.
Checking by launching urpmi, urpmi spits out that it do not recognise that option.

Adopting to style of the other options, I changed it to
    retry: 3
Then it did not complain, but it also did not help
(using MCC -> update, like normal users - did not try using plain urpmi yet.)
Could also be that it drops connection so often that retries is futile:
When running, it takes just a second to fail all kernel related packages, not much at all got retrieved.
I guess curl use some protocol/dialect incompatible with something or a combination of things between internet and me. 

Both wget and aria2 works, every time I tried.  curl never.

I issued
# urpmi -clean
in between tests.

Interestingly, this machine worked mostly OK with default curl using our previous routers, but not the new ones, which apparently make this problem worse.  Could also be some change upstream lately.

__Equipment:

Laptop: Asus A717, wifi Atheros QCA6174, driver ath10k_pci (mga8 x86_64 Plasma)

Router(s): TP-link Deco S4, on latest fw (20210607), mesh of 3 units, laptop not using the one connected to fibre modem.  Administration app say all are well.

Fibre modem: hard to reach, can check if interest...

Fibre operator: IP-Only installed fibre, modem, their station

Internet supplier: Bredband2 (maybe too cheap, lost connection due to power failure (no UPS) almost all of monday due to storm, while others around using other suppliers had no problem.  No working fallback, nor excuse. so guess they generally don't aim for reliability...)

(In reply to Martin Whitaker from comment #23)
> You can use
> 
>   urpmi --downloader curl --retry 5 ...

Unfortunately retries do not help.

Small packages work either way, but large like kernel is impossible for me on all machines using curl, also with --retry


$ sudo urpmi --downloader curl kernel-desktop-5.10.16-1.mga8
-> "bad rpms"

$ sudo urpmi --clean
$ sudo urpmi --downloader curl --retry 5 kernel-desktop-5.10.16-1.mga8
-> "bad rpms"

$ sudo urpmi --clean
$ sudo urpmi --downloader wget kernel-desktop-5.10.16-1.mga8
-> success

This test was on my wired ethernet workhorse.
Before "upgrading" (duh!) the router, curl worked here.

Acer Aspire One laptop *do* work reliably per default settings.
Running updated 64-bit mga8, Xfce
wifi: Qualcomm Atheros AR9285, driver ath9k
CPU&GPU: Atom N450

Another one on the *failing* list is Thinkpad T43, with
Booted 32-bit mga8 Xfce live
wifi: Intel PRO/Wireless 2200BG (Calexico2), driver ipw2200
CPU Pentium M

Trying a netinstall now it of course fail for the same reason...
Is there a way today to trick mga8 netinstall to use wget or aria?

*** Bug 30075 has been marked as a duplicate of this bug. ***

CC: (none) => kmmos1

*** Bug 31049 has been marked as a duplicate of this bug. ***

CC: (none) => westel

This is still happening in the installer during fresh installs.  Again, it's a 6 RC from curl trying to download media.cfg using the same hostname that stage 1 used to load stage 2.

Elevating to release-blocker since not being able to run the install is sort of critical.

Priority: High => release_blocker

I had previously thought that the problem was that stage 2 was losing knowledge of the DNS server which DHCP passed to stage 1, but I've just tried an HTTP install from my in-house cauldron mirror using an IP address rather than a hostname and it fails the same way but with a curl error 7 (TCP connect failed) trying to get media.cfg.  So the problem is not necessarily anything in curl but instead that stage 2 is losing the network completely by the time it looks for media.cfg.

Just as a followup, since I couldn't get a netinstall to work, I downloaded the MGA9 Alpha and did a DVD install.  The wifi works perfectly.

Still valid mga9 alpha1 live plasma, curl 7.86.0-1

Changing the default to wget would only partially fix the original complaint, as urpmi will still use aria2c to download metadata. You have to explicitly set the downloader to override that. And it's aria2c that causes me the most problems with my nearest mirror (mirrorservice.org). That's not to say I'm against changing the default though.

However, as there's been no progress on this, I've modified the stage 2 installer to let the user select a specific downloader, both when adding additional media at the beginning, and when configuring update media at the end. I've also allowed the user to select a specific mirror when configuring update media, rather than always using the nearest mirror.

Great, thanks
I note to docteam ML for documenting