I have a very good CPU, high RAM, I usually update when doing absolutely nothing else, yet the install (and download, but I understand it can be limited by whoever is sending the files to me) is egregiously slow, and I feel like it has further slowed down yet. Is there any setting which could be affecting this? Is there a fix? It is ridiculous. I used to have very fast file installs, so it is a newer issue.
Can you provide some clarity on what you are installing?
Are they AUR packages? If so, you might be building the software from source. It would help to have an example of something that was slow and how you installed it.
2 Likes
I just update my system, so I assume all of them are AUR. Every single package is slow. There is no difference. All of them take ages to update. From Firefox updates, through kernel and so on. The only things which don’t install slow are flatpak, but they’re different to normal updates.
In that case, have you tried speed-testing and updating your mirrors?
Something like this to update your Arch mirrors:
rate-mirrors --disable-comments-in-file --protocol=https arch --max-delay 7200 --completion=1 | sudo tee /etc/pacman.d/mirrorlist
And this to update EndeavourOS specific mirrors:
rate-mirrors --disable-comments-in-file --protocol=https endeavouros | sudo tee /etc/pacman.d/endeavouros-mirrorlist
Then run this to update your full system as usual:
eos-update --yay
1 Like
rate-mirrors would have to be installed manually from the AUR,
Alternatively, reflector-simple & eos-rankmirrors should work out of the box. reflector-simple might not be that sophisticated under the hood. But should work reliably.
1 Like
Ah yes sorry about that. I had noticed rate-mirrors had turned up in the Welcome app, so thought it might be installed as default, but it’s possible the Welcome app only includes it when it has been installed by the user. I’m not sure.
rate-mirrors is in EOS repo. So no need to install it from AUR.
I already did prior to this thread using reflector.
As stated before, it isn’t a download issue, but an install one.
Thanks nonetheless.
It was actually said it was both.
Anyway, one step of standard updates that can take a very long time, is integrating DKMS modules into the installed kernels.
This will list installed kernels:
ls /boot/vmlinuz*
This will list installed DKMS modules:
dkms status
I’d also point to @dalto’s original question, asking for clarity on what’s being installed/updated, and whether it is building from source.
You mentioned Firefox, so perhaps we can check that.
yay -Q | grep firefox
Does this help?
3 Likes
Can you post the hardware info ?
What do you try to install and which way ?
2 Likes
Further optimizations are feasible, but these are more advanced and should be made with precaution.
The advice to keep /etc/makepkg.conf unaltered and to make the changes within a copy “~/.config/pacman/makepkg.conf”, as suggested in the article definitely makes sense (don’t ask me who I know…)
In my case, I do use the ALHP repositories which are optimized for x86-64-v3 as well as -03, therefore I’ve also changed the march of the CFLAGS within in makepkg.conf and replaced the -02 flag accordingly.
From my perspective, if there are foreign packages that have to be complied, my impression is that it’s definitely faster as it makes use of the extended SIMD instruction sets as well as AVX in x86-64-v3.
But packages that are build via python or npm still take their time.
As a conclusion I’ld check sudo pacman -Qqm. Generally avoid packages that are explicitly labeled with the -git suffix and prefer -bin packages that are available precompiled and would only have to pass the checks before being installed without any compilation steps.
Last but not least, as I’ve mentioned the ALHP. One requirement when adding those repository is actually to reinstall all packages (e.g. replacing those packages in [core], [extra] & [multilb] with their counterparts within [*-x86-64-v3]. Thus, depending on your system. this may take some time and isn’t something done in a few minutes, may take an afternoon or so, at least an hour or two.
Anyway, some argue that x86-64-v3 (e.g. Zen 4) or the latest x86-64-v4 (e.g. Zen5) essentially don’t make a difference at all. That might be true in runtime comparisons of processes that are not parallelized. But if you’ve got a extended feature set your CPU micro-architecture is capable of… well if someone has an AMD Threadripper with an obscene amount of cores, it definitely could speed up thing dramatically. If it’s an entry level machine, a bit older with a low core count - not so much.
by any chance, is there any electron package being built? Its source is huge and of course, building it would take lot of time too
I wouldn’t suspect hardware slowdown because my over a decade old budget PC with a spinning platter disc still manages to install packages reasonably quick (including dkms modules)
Mirrors could be an issue (use the rate-mirror command suggested in a comment above) but mirrors don’t affect install speed.