Cacher (Apt-cacher-ng): issues with fedora updates

User Support
12

Hi enmus.
Thanks for your help in troubleshooting my problem.

I’ve just checked back in yum.repos.d/fedora-cisco-openh264.repo because almost sure to haven’t messed them up; perhaps I think it’s exactly how salt has configured them; follows first 10 raws:

[fedora-cisco-openh264]
name=Fedora $releasever openh264 (From Cisco) - $basearch
metalink=http://HTTPS///mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-$releasever&arch=$basearch&protocol=http
type=rpm
enabled=1
metadata_expire=14d
repo_gpgcheck=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=True

So now?

(checking other post now…)

I think You were talking about this:

but I’ve got no luck…
dnf_update_cleaned_up.log (1.7 KB)

Thanks.
Cheers,
M.

13

Nope, I was talking to read all the way down from the point, meaning to try to clean cacher’s cache if nothing else helps.

14

Hi there,
I’ve searched a bit, but it seems to be missing the cacher “cache manager”: distkill.pl
https://www.unix-ag.uni-kl.de/~bloch/acng/html/maint.html#distkill

Do You suggest me to delete manually directory and files inside /var/cache/apt-cacher-ng ?
And in this case, only fedora directory?
Or *fedora* dirs?

Maybe something is moving… let me check…

Thanks,
M.

15

This is the only other thing I can suggest and I meant on

I’m sure someone else will have another suggestion.

16

Hi there,
probably I solved, but I’d like to have feedback from anyone else, before mark it as (possible) solution.

Briefly:
also thanks to:

I’ve searched in cache for repo references and found in mirrors.fedoraproject.org the metalink repo of my broken repositories.

So I removed by hand that (2) metalinks (all occurrences), and relauched upgrade and now it works…

Please let me know if anyone found same way to unlock fedora “not upgrading” issue…
Thanks,
M.

17

So doing it via webui as @Insurgo explained above didn’t help?

Please respond so it could help others too.

18

Hi enmus,
honestly I don’t know why, but in my cacher deploy there isn’t a browser and I haven’t installed one.
So webgui is unuseful for me…
But I can say that I runned many times acngtool, before last trick by hand, starting it from the /etc/cron.daily/<invocation> and each time I haven’t see any update working…
So I don’t think acngtool may be really useful in this matter…
Cheers,
M.

19

Done. Hopefully it’s as you intended.

1 Like
20

Thanks

21

You should be able to run it within any qube. I use dispVMs to access cacher’s webui.

22

no, it doesn’t work…
except from cacher I have a “vanilla” setup and the only way to access that page is from localhost of cacher…

23

Hi there,
yesterday new “locking” on updates.
So I did same procedure: remove the metalink old repo index (“updates” was the culprit) and relaunch of updates.
All working now, but I think I found a new problem:

  • in one of my fedora templates there are rpmfusion-* repo, that I cannot find in present metalinks…

Is there a limitation in cacher that skip all non standard repo?
Thanks.
M.

24

There isn’t such a limitation.
I’m not clear what you mean: can you post an example of part of the repo
definition from /etc/yum.repos.d - just the lines for metalink= will do

25

Not helpful.

You need to have a qube with netvm set to cacher, and then open browser
in that qube to http://:8082

26

Hi there,
I’ve created a clone of tetmplate and installed firefox onto it.
I’ve just expired / cleaned all cache and relaunched update.
Still fails.
Following logs.
PLease let me know if You need anything else.
Thanks,
M.

27

Hi there.
Following generated log.

I’ve modded repo in this way:

  • in rpmfusion-free.repo and rpmfusion-nonfree.repo
    I’ve removed the http forwarder added by cacher, to see if there’s any differences with other ones
    (You can see in next repo list that is there a backup of original ones)

This is the complete list of repo in /etc/yum.repos.d of my fedora modded template:
adobe-linux-x86_64.repo
fedora-cisco-openh264.repo
fedora-updates-testing.repo
fedora-updates.repo
fedora.repo
google-chrome.repo
qubes-r4.repo
rpmfusion-free-updates-testing.repo
rpmfusion-free-updates.repo
rpmfusion-free.repo
rpmfusion-free.repo.bck
rpmfusion-nonfree-updates-testing.repo
rpmfusion-nonfree-updates.repo
rpmfusion-nonfree.repo
rpmfusion-nonfree.repo.bck

Then that’s the update log session.
Thanks,
M.

dnf_update.log (3.3 KB)

28

I access it over qrexec without a problem.

29

I can tell you that this isnt going to work.
That means that dnf will try to access the repository using https.
When that request gets to cacher, cacher has no idea what it means
because it is encrypted.
as there is no special treatment for https traffic, the request will fail

Can you please give me the line I asked for before?
The metalink data in the repo definitions.

Also, are you updating over Tor?

30

Hi unman.
I’m sorry: I tought it was a better evidence…
Yes I’m updating by sys-whonix.
And from previous log:

“modded”:
RPM Fusion for Fedora 36 - Free 0.0 B/s | 0 B 00:02
Errors during downloading metadata for repository ‘rpmfusion-free’:

“unmodded”:
RPM Fusion for Fedora 36 - Free - Updates 582 B/s | 512 B 00:00
Errors during downloading metadata for repository ‘rpmfusion-free-updates’:

If You need internal ones too:
for first one

  • metalink=HTTPS://mirrors.rpmfusion.org/metalink?repo=free-fedora-$releasever&arch=$basearch&protocol=http

for second one:

  • metalink=http://HTTPS///mirrors.rpmfusion.org/metalink?repo=free-fedora-updates-released-$releasever&arch=$basearch&protocol=http

I hope it’s everything You need…
Otherwise, just ask.
Thanks,
M.

31

TLDR - problem with caching fedora updates repository may be fixed by
setting in acng.conf:
VfilePatternEx: .*fedora.*updateinfo.*xml.zck$
DontCache: .*fedora.*updates.*updateinfo.xml.zck

This post covers problems using cacher with fedora updates are reported, e.g by
@weyoun.six:

* At least one of the zchunk checksums doesn???t match in
http://mirror.init7.net/fedora/fedora/linux/updates/36/Everything/x86_64/repodata/73c60d6746840b97edeca71d4a9b31
3aaf88e648ead74abbf7d23fe3747a002c-primary.xml.zck
* At least one of the zchunk checksums doesn???t match in
http://mirror.init7.net/fedora/fedora/linux/updates/36/Everything/x86_64/repodata/afdb89258121bb4cd97ead414e06ed
3b561e270aab025cfccc0d5166960d2bd5-filelists.xml.zck

I believe that this affects the updates repository because of the effect
of mirroring. If you hit the right mirrors at the right time, then the
cached data matches, and the update will continue.

apt-cacher-ng categorises data between static data, that should not
change, and volatile data. These are set using configuration entities,
PFilePattern and VFilePattern.
You can use the acngtool utility at /usr/lib/apt-cacher-ng/acngtool to
see the full configuration, with acngtool cfgdump

You can use “Ex” versions of these patterns to override the defaults.
I have changed the patterns so that .*fedora.*updateinfo.xml.zck is
set in VFilePatternEx, so that updateinfo is treated as volatile.
Because of the issues with mirror synchronising, I found it necessary
not to cache updateinfo.xml.zck data from the fedora update
repositories:
DontCache: .*fedora.*updates.*updateinfo.xml.zck

This combination seems to fix the issue, at minor cost. The updateinfo
files are no longer cached, but the packages still are.
I have tested it with combination of cacher and Tor/clearnet, and will
push an updated package that will update the acng.conf file idc.

It’s important to realise that even with no caching proxy and clearnet
access, dnf update can still throw errors. With Tor, the errors are more
frequent. All one can do is wait and retry.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes