Arch Linux

Beemo

Member

Registered: 2024-12-20

Posts: 111

[SOLVED] warning: local is newer than core

warning: amd-ucode: local (20260810-2) is newer than core (20260810-1)
warning: ca-certificates-mozilla: local (3.127-1) is newer than core (3.126-1)
warning: harfbuzz: local (14.3.1-1) is newer than extra (14.3.0-1)
warning: harfbuzz-icu: local (14.3.1-1) is newer than extra (14.3.0-1)
warning: linux-firmware-amdgpu: local (20260810-2) is newer than core (20260810-1)
warning: linux-firmware-mediatek: local (20260810-2) is newer than core (20260810-1)
warning: linux-firmware-other: local (20260810-2) is newer than core (20260810-1)
warning: linux-firmware-realtek: local (20260810-2) is newer than core (20260810-1)
warning: linux-firmware-whence: local (20260810-2) is newer than core (20260810-1)
warning: nano: local (9.2-1) is newer than core (9.1-1)
warning: nss: local (3.127-1) is newer than core (3.126-1)

❯ sudo pacman -Syu --debug
...
:: Synchronizing package databases...
 core downloading...
 extra downloading...
debug: filesystem access has been restricted to /var/lib/pacman/sync/download-xbvAOh/, Landlock ABI is 9
debug: successfully restricted 83 syscalls via seccomp
debug: core.db: url is https://(redacted)/pub/archlinux/core/os/x86_64/core.db
debug: core.db: maxsize 134217728
debug: core.db: using time condition 1787014015
debug: core.db: opened tempfile for download: /var/lib/pacman/sync/download-xbvAOh/core.db.part (wb)
debug: extra.db: url is https://(redacted)/pub/archlinux/extra/os/x86_64/extra.db
debug: extra.db: maxsize 134217728
debug: extra.db: using time condition 1787014016
debug: extra.db: opened tempfile for download: /var/lib/pacman/sync/download-xbvAOh/extra.db.part (wb)
debug: core.db: curl returned result 0 from transfer
debug: core.db: response code 304
debug: core.db.sig: url is https://(redacted)/pub/archlinux/core/os/x86_64/core.db.sig
debug: core.db.sig: maxsize 16384
debug: core.db.sig: opened tempfile for download: /var/lib/pacman/sync/download-xbvAOh/core.db.sig.part (wb)
debug: core.db: file met time condition

So server sent a 304 even though the file is not up-to-date. Server timestamp is 1786965360 which is older than my 1787014015, but has newer package versions inside core.db.
When I last checked for update I might have used a VPN, or reflector happened to run, so it might have been a different server. It overwrote my local core.db with a older version.
I did not use pacman -Syy at any point.

What happened?

• Was there a rollback? (no?)

• Pacman uses local modification time to compare with server file modification time?

• Mirrors don't sync file modification time but uses their own local modification time?

Last edited by Beemo (2026-08-18 09:47:31)

Beemo

Member

Registered: 2024-12-20

Posts: 111

Re: [SOLVED] warning: local is newer than core

To avoid this issue in the future: How to select only up-to-date mirrors in reflector? Should I use --delay or --age? How does the Arch mirror website tell which are "Out of Sync Mirrors"?

Beemo

Member

Registered: 2024-12-20

Posts: 111

Re: [SOLVED] warning: local is newer than core

--delay seems to be the right option.

There will be some delay between when package is updated in the repo and when it appears on the mirror, which is unavoidable. But what I wanted to avoid is a mirror being so outdated that it still serves stale files days later. (Though the original issue might still be a bug...)

The check script runs on a regular basis and polls for the lastsync file in the root of our repository layout. This file is regularly updated on the central repository, so checking the value within allows one to see if the mirror has synced recently.

• μ Delay: The calculated average mirroring delay; e.g. the mean value of last check − last sync for each check of this mirror URL. Due to the timing of mirror checks, any value under one hour should be viewed as ideal.

Not sure about the detail of the checking script, but based on what's written on the website, this will select mirrors that sync frequently.
Might be overkill, as some mirrors may sync only when there is an actual package update? But there isn't a stat for that. So "delay" is the best we can get.

p.s.
But ofc, Gemini was adamant that I should use --age instead (which I think was slop), feel free to correct me if this is wrong...

Last edited by Beemo (2026-08-18 04:35:41)

killertofus

Member

Registered: 2025-02-10

Posts: 226

Re: [SOLVED] warning: local is newer than core

reflector --protocol https --sort rate --country "Country Here" --save /etc/pacman.d/mirrorlist

---

I Have Linux Perl Can i Download Gnome???

mpan

Member

Registered: 2012-08-01

Posts: 1,640

Website

Re: [SOLVED] warning: local is newer than core

There was one, just one information in this log that mattered, if we wished to investigate the issue. The mirror name. That single information is replaced with “(redacted)”.

Being left with nothing to digest, only some generic response is possible. This kind of situation usually happens after the user changes mirrors, and the new mirror is older than the old. In that scenario it’s completely benign and may be ignored. The new mirror, if working correctly, catches up with databases you have locally within a day. If on the other hand the warning appears out of the blue, with no mirror change, or persists for a long time, it’s not normal. Usually some kind of mirror breakage that requires changing a mirror to another. But what, and if, we can’t tell without knowing what mirror that was.

There is no need to adjust reflector in any way. If you invoke reflector and it selects an older mirror, it falls into the first category above. The issue will go away by itself quickly. There is no indication here of the mirror being not up-to-date. It might be the case and we could tell if we knew what mirror it is. But with its name hidden, the assumption has to be nothing is out of order and you’re using a perfectly fine mirror.

As for killertofus’ suggestion: the `--country` option is not needed. With some number of niche exceptions it only reduces quality of the results. If you’re affected by these exceptions, you know that. Instead, look at the `--latest` option. This is going to reduce the number of mirrors tested, and also selects the most recently updated ones.

Last edited by mpan (2026-08-18 07:29:46)

---

Paperclips in avatars?

Beemo

Member

Registered: 2024-12-20

Posts: 111

Re: [SOLVED] warning: local is newer than core

@mpan I have investigated the mirror, but it's not the one with the problem. Likely the one before it, which I don't the URL (because no --debug) and I couldn't find it in the log.
The timestamp on core.db is 2026-08-17 11:16, which agrees with other mirrors (including https://geo.mirror.pkgbuild.com/core/os/x86_64/).
Some mirrors don't show the same time, but it's likely just local time, e.g. https://hk.mirrors.cicku.me/archlinux/core/os/x86_64/ (2026-Aug-17 19:16:21) and https://ftp.u-strasbg.fr/linux/distribu … os/x86_64/ (2026-08-17 13:16)

To answer my own questions:

• pacman saves & uses the file modification time sent by the server, per HTTP spec. Also tested: after pacman -Syy, the epoch time shown in --debug is indeed 11:16.

• Mirrors do sync the actual modification time, far as I checked. But there was probably a buggy mirror that sent me a wrong time. And I'm guessing it sent date.now() instead of file time (1787014015 is about 2h before I made the post).

p.s. Unfortunately I prefer to keep the account anonymous online and the mirror URLs would reveal users' location.

Last edited by Beemo (2026-08-18 10:02:52)

olegkvapil14

Member

Registered: 2026-08-15

Posts: 4

Re: [SOLVED] warning: local is newer than core

upate core obviosly