Having problems updating this morning

Happy Thanksgiving

[demo@manjaro ventoy]$ sudo pacman-mirrors --fasttrack && sudo pacman -Syuu && pamac update -a
::INFO Downloading mirrors from Manjaro
::INFO => Mirror pool: https://repo.manjaro.org/mirrors.json
::INFO => Mirror status: https://repo.manjaro.org/status.json
::INFO Using custom mirror file
::INFO Querying mirrors - This may take some time
  ..... Global         : https://mirrors.manjaro.org/repo/

::ERROR Connection: HTTPSConnectionPool(host='mirrors.manjaro.org', port=443): Max retries exceeded with url: /repo/unstable/core/x86_64/core.db.tar.gz (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f75b454cdc0>: Failed to establish a new connection: [Errno 101] Network is unreachable'))

::INFO Writing mirror list
::INFO Mirror list generated and saved to: /etc/pacman.d/mirrorlist
:: Synchronizing package databases...
error: failed to synchronize all databases (no servers configured for repository)

Why? Just one is enough and should be -Syyu and only if you switched from unstable to testing or from testing to stable then you use -Syyuu …

On what branch is your system?
In principle, if /etc/pacman-mirrors.conf is not wrongfully altered, then by running:
sudo pacman-mirrors -f5 && sudo pacman -Syyu
you should get all sorted out.

After running it a few time it finally updated. Must have been a network glitch

Don’t you have libpamac (pamac-mirrorlist) installed :thinking:
It should update the mirror list automatically already.

Also see:

someone on here suggested that I use the command I posted when I update my system.
Should I not do that?

[demo@manjaro ventoy]$ pacman-mirrors
Pacman-mirrors version 4.23.2
Local mirror status for unstable branch
Mirror #1   OK  01:05   Global  https://mirrors.fossho.st/manjaro/
Mirror #2   OK  00:09   Global  https://mirrors.manjaro.org/repo/

Sure you can, but i prefer the service file which should already be installed on your system, except my override drop-in.
(At least i think it was installed by default, don’t really recall anymore)

And i use the GUI inside KDE to get notified when there are any updates to be performed…

By default the pamac-mirorlist.service is triggered by the pamac-mirorlist.timer that runs every OnCalendar=Thu *-*-* 7:00:00 - that means once a week, so if you catch in that between with outdated mirrors then you still have to run manually …

The updates of the database is run by pkgfile-update.service that is triggered by pkgfile-update.timer that runs daily every 6 hours by default.

I currently use a drop-in to override the current service file, but would be nice to have this for everyone by default.

I beg to differ. :smile:

ExecStartPost=/usr/bin/pacman -Sy

I didnt use -Syu on purpose because that would trigger an auto-upgrade without the admins consent.

The system should be updated at the same time as the database, but neither should be done automatically. If you were to do it, then it should have it’s own service and timer to avoid confusion etc. :smile:

I disagree :stuck_out_tongue_winking_eye:

What part of “no partial updates” do you disagree with? :crazy_face:

1 Like

Exactly the partial part is crucial, updating the database does not leave your system in such state, because you don’t update any packages yet, just the list of available packages…
Just like that list is updated on the remote servers doesn’t equal your installed packages being changed at same time.

Sure to stay in sync with that list you should update any available packages, but the time of doing that is left to the admin/user of the system and not automated.

(Unless i’m completely misunderstanding that command)

1 Like

Exactly, it can leave it in a partial update state the next time the user uses pacman -S, which is worse than a normal partial update in that the user doesn’t know about it.

By updating the database, it means they have to update the system every time they install a package. There may not be any updates but they still need to do it to ensure they don’t do a partial update. You’re effectively trying to take away any choice they have (at least when they need to install something).

If they keep track of when they last updated and when the database was updated then they may not always have to update, but why should anyone have to do that. Obviously any sensible person would just disable the service (mine’s already disabled anyway).

That’s assuming they actually know that pamac-mirrorlist.timer and pamac-mirrorlist.service exist, and that the service runs pacman -Sy, despite the name having nothing to do with updating pacman’s database.

If they don’t know that (and why should they) they’ll think the problem is with the software they just installed, instead of being in a partial update because a seemingly unrelated service for pamac decided to mess things up. So then they’ll waste their time (and potentially other peoples) trying to figure it out.

1 Like

If you’re so much against it, then file an issue to remove the two unit files from the libpamac package.
Because updating the mirror-list can have same effect due to the fact that not all mirrors are up-to-date at same time.
The default for that service is to select fastest eight mirrors, no matter their sync status with other mirrors :wink:

But we have derailed the original topic enough, if want to debate this more I suggest to create a new topic :kissing_closed_eyes:

Come on, are you serious? This is in pacman’s archwiki - first warning just below the index.
Of course you are free to do as you please, just don’t advocate for bad practice.

By the same logic, if you ride on a bike very fast, why wear a helmet? there is a chance you get in an accident driving, so why even wear a seatbelt?

1 Like

Not really. Because libpamac is for pamac and it will automatically sync packages every time it installs a package.

Don’t confuse pacman and pamac.

1 Like

How is it the same effect?

On one hand we update the local database behind the user’s back, causing them to perform a partial update without their knowledge.

On the other, we rebuild the mirrorlist behind their back, potentially wiping out their config and using mirrors they don’t want to use.

Either the new mirrors have the new database, the current database (ie same as local), or an older one. AFAIK only the latter is a potential problem and it’s easily solved by giving the database a version and checking the remote is >= the local version. Assuming there isn’t already a mechanism.

However I dislike the service and as mentioned I have disabled it.

So after all of that discussion which most of it was beyond my knowledge at this point.
Is this command not the way to update?

sudo pacman-mirrors --fasttrack && sudo pacman -Syuu && pamac update -a

commands are combined on one line just to run them back to back to get the job done.`

Used to rebuild the mirrorlist when you have a problem with your mirrors. man pacman-mirrors

Updates your system, but the second u downgrades any packages that are newer than in the repo. man pacman

–aur, -a
also upgrade packages installed from AUR

So it would seem it updates the system including the AUR packages, but I don’t use pamac :man_shrugging: . man pamac

Mostly use sudo pacman -Syu. If you have a problem with your mirrors, such as slow download speed, you know the command :arrow_double_up:, follow it up with either sudo pacman -Syyu or sudo pacman -Syyuu. Or use pamac instead.

I’d advise caution when updating AUR packages, as the repos can lag behind or vice versa, but it depends on what you have installed etc. Check the relative versions to find out for sure. I very rarely update my AUR packages, about once or twice a year if that, or as necessary, but as I say it depends on what you have installed.

pacman - ArchWiki

Very informative. Thanks for explaining all of that.
I will also go read the manual.

1 Like

There goes your partial updates :rofl:

If you are running Manjaro, i highly advise to use pamac instead of pacman, because the last one is for Arch and the first for Manjaro.
Yes Manjaro is an Arch based, but not same, especially with the AUR effect etc.