Created attachment 10972 [details]
CLI output of dnf upgrade and urpmi --auto-update

It is rolling again on all instances since Sunday, 29th.

It was not the first mismatch between urpmi and dnf, and I will continue to watch this issue. Furthermore I would like to know, if there was any human interference on the mirror side.

Ulrich

There was..
I checked primary mirror, and I didn't see any issues...
so I assume some downstream Tier1 mirror had got stuck...

So I regenerated all hdlists and repodata to try and trigger a new sync from downstream mirrors, and it seems it worked

CC: (none) => tmb

Created attachment 11030 [details]
CLI output of dnf upgrade and urpmi --auto-update

Again a significant delay.

kernel 4.14.21 was reported on 2019-05-22 (https://bugs.mageia.org/show_bug.cgi?id=24853) and should have been synced to all mirrors.

(In reply to Ulrich Beckmann from comment #4)
> Created attachment 11030 [details]
> CLI output of dnf upgrade and urpmi --auto-update
> 
> Again a significant delay.
> 
> kernel 4.14.21 was reported on 2019-05-22
> (https://bugs.mageia.org/show_bug.cgi?id=24853) and should have been synced
> to all mirrors.

Maybe the repodata.old directories got in the way of properly updating the repodata? Those directories are only in Mageia 6 updates_testing:

$ find mageia/distrib/ | grep "repodata.old" | wc -l
135
$ find mageia/distrib/6/ | grep "repodata.old" | wc -l
135
$ find mageia/distrib/6/ | grep "repodata.old" | grep updates_testing | wc -l
135

for instance:
$ ls mageia/distrib/6/x86_64/media/core/updates_testing/ | grep repodata
repodata/
repodata.old.38576.20190516121509.982099/
repodata.old.49123.20190520095226.933642/
repodata.old.9966.20190513142630.738636/

repodata.old.49123.20190520095226.933642/ and repodata/ are both from 19 May, and contain identical files. The other repodata.old directories date from 12 and 16 May.

I sync from Princeton, but the same issue exists on distrib-coffee:
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/6/x86_64/media/core/updates_testing/repodata.old.49123.20190520095226.933642/

Summary: DNF metadata are missing since about a week => DNF updates_testing repodata don't get updated since 19 May

It works now, repos are synced.

I never tried to use specific mirrors with dnf.

You can clean the cache with # dnf clean all.

I assume that it is a mirror issue, because it shows itself also in a vm installation.

Packagekit uses the same metadata as dnf, but does not invoke dnf commands.
So one can check

# pkcon update

To clear the cache

# pkcon refresh force -c -1

(In reply to Ulrich Beckmann from comment #6)
> It works now, repos are synced.
> 

Thanks to whoever regenerated the repodata

Probably tmb again :-)

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Actually there is another delay.
The problem is still not understood, and a manual process is not sufficient.

So I reopen the bug report.

Ulrich

Resolution: FIXED => (none)
Status: RESOLVED => REOPENED

(In reply to Ulrich Beckmann from comment #8)
> Actually there is another delay.

When / how ?

If you mean in  Cauldron, then yes there was a bug in the script that we use when manually regenerating the repos, as it did not call createrepo at all, only urpmi metadata generation...
(I guess it was done to make it faster to recover during buildsystem breakages)

Anyway, I realized that yesterday and fixed it then...

> The problem is still not understood, and a manual process is not sufficient.
> 
> So I reopen the bug report.


I also updated infra to the new createrepo_c-0.14.2 last night, which I hope will prove to be more stable than the earlier one...

I got now the upgrades as expected in two different instances.
So closing, hopefully for ever.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED