Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.

[Otto Kratik]

Qubes 3.2

Ever since a routine qubes-dom0-update was interrupted in the middle of the upgrade process, I can no longer run any updates on dom0. Instead I see the message:

"Failed to synchronize cache for repo 'qubes-dom0-cached', disabling."

..in response to most commands that I attempt through yum/dnf/qubes-dom0-update to try fixing it. None of the usual approaches like --clean have been successful.

What should I try from here to correct the issue?

Thanks,
Otto

[Ivan Mitev]

Every time I had a "failed to synchronize..." erorr it was because there
was a problem with the proxy in sys-net. Restarting it usually did the
trick, eg:

sudo systemctl restart qubes-updates-proxy.service

(run the command sys-net ; the syntax is for R4.0, I don't have R3.2 to
test but it shouldn't be too different).

Check the proxy's status with

sudo systemctl status qubes-updates-proxy.service



>
> Thanks,
> Otto
>

[Otto Kratik]

On Friday, October 5, 2018 at 3:26:51 PM UTC-4, Ivan Mitev wrote:
> Every time I had a "failed to synchronize..." erorr it was because there
> was a problem with the proxy in sys-net. Restarting it usually did the
> trick, eg:
>
> sudo systemctl restart qubes-updates-proxy.service
>
> (run the command sys-net ; the syntax is for R4.0, I don't have R3.2 to
> test but it shouldn't be too different).
>
> Check the proxy's status with
>
> sudo systemctl status qubes-updates-proxy.service

Thanks for your help and suggestion. I just tried both of those commands and sys-net reports the update proxy is working perfectly, however there is no change in the result from dom0 and I get the same error message as before.

The original interruption glitch happened after dom0 had already successfully downloaded all updates, but during the upgrade/install of those new packages. Ever since then, this issue has occurred. So I am thinking something local has gotten messed up rather than a connection issue.

Any other ideas I should try in order to fix this?

Thanks...

[Ivan Mitev]

If you haven't done so, maybe try to clear dnf/yum's cache. Hopefully
someone more knowledgeable with the dom0 update mechanism may chime in.
Otherwise I'd suggest you file an issue...



>
> Thanks...
>

[appleo...@gmail.com]

hello,

I'm having the same issue.

dom0 fails to synchronize cache for repo 'qubes-dom0-current' and 'qubes-template-itl'.

I've tried the steps recommended above and the proxy seems to be opperating fine but whenever i try to update i am unable to.

My main goal is the get qubes-u2f working which wont' because it fails to synchronize.

[Otto Kratik]

It's been a few weeks, but I believe the synchronize cache issue resolved itself the next time I forcibly installed something on dom0 using yum/dnf or qubes-dom0-update. I don't remember which package I installed or reinstalled, but forcing it to perform an install from a repo that *was* working seemed to refresh everything again.

In my case the stuck pseudo-repo was the local qubes-dom0-cached one, so if qubes-dom-current isn't working I'm not sure the same procedure will be workable.

I'd go back and check my command line history, but I ended up having to reinstall the entire OS shortly afterward since the glitch that caused the entire situation in the first place (interrupted kernel update) was irrecoverable.

[alrojs]

thanks for a quick update, guess i'll have to try to reproduce this.

I'm on my third install and this issue has persisted through my 3 installs. My current install is pretty bare and still I see this issue.

first two installs was 4.0 and now currently on 4.0.1-rc1
hardware t450s

[hm...@tuta.io]

hello

I have exactly the same problem on two of my x230 Lenovo notebooks with Qubes version R4.0.1rc1.

I suspected it might be Coreboot/SeaBios, but obviously it's not.

Greetings

[Alex]

On 11/10/18 11:23 AM, hm...@tuta.io wrote:
> hello
>
> I have exactly the same problem on two of my x230 Lenovo notebooks with Qubes version R4.0.1rc1.

Have had this very issue on R4.0.

I checked by running, in dom0:
# qubes-dom0-update -v

That runs the dnf updater with the "-v" verbose flag. With that, the URL
for the repositories will be printed on screen, in red (because it's
happening in the UpdateVM).

I found that the URL being printed was
https://yum.qubes-os.org/r25-4/current/dom0/fc25/repodata/repomd.xml.metalink

instead of the correct
https://yum.qubes-os.org/r4.0/current/dom0/fc25/repodata/repomd.xml.metalink

(the yum.qubes-os.org domain can be navigated with a browser).

I found that inside [dom0]/etc/yum.repos.d/qubes-dom0.repo the url is
saved as
https://yum.qubes-os.org/r$releasever/current/dom0/fc25/repodata/repomd.xml.metalink

Changed that with nano to read "4.0" instead of "$releasever" and voilà,
updates went through.

Check, try and let the list know ;)

--
Alex

[hm...@tuta.io]

@Alex - Thank you for pointing that out.

I just tried to install version R4.0.1rc1 on the x230 again, but the installation breaks off when configuring ext4. It is probably due to the HW or Coreboot.

I will flash my x220 with Coreboot/SeaBios + Intel ME Cleaner and install R4.0.1rc1 again. Then i let you know if your tip worked.

PS. Under Qubes 3.0/3.1/3.2 i didn't have these problems.

Greetings

Sebi

[alrojs]

We're you able to get it working?

I will try this tip right now

[alrojs]

This worked! this pushed the update through!!!!!!!!!!!

[hm...@tuta.io]

@Alex - I tried the installation quickly on my HP x360 1030 G2. Your hint works fine. Thanks a lot Alex.

HW specifications: HP Elitebook x360 1030 G2
Intel Core i7 vPro 7th Gen
16GB RAM
256GB SSd
OS - Qubes R4.0.1rc1

PS:Test it soon on my x220.

Br
Sebi

[lion...@gmail.com]

This problem wasn't there until i updated and upgraded everything today , can anyone help on how to fix as i don't have much experience .

Thanks

[awokd]

lion...@gmail.com:

> This problem wasn't there until i updated and upgraded everything today , can anyone help on how to fix as i don't have much experience .
>
> Thanks
>

Look for recent posts to this mailing list with the above subject line
and [solved] in it. Think it had something to do with fixing releasever
by hand to 40.

[lion...@gmail.com]

Thank's just fix that :)

[unman]

Please bear in mind that if you do this you are breaking the logic of
dnf, and will have to *manually* update that entry if you upgrade the
system. You are almost bound to forget this.
$releasever is part of yum/dnf, not Qubes.

You can pass in --releasever=4.0 as an option, which would be a better
solution.

I havent encountered this bug myself,so cant account for it. It might be
helpful if those who have could say if they have enabled testing repos,
or are using plain 4.0 Qubes repositories. Any other detail would be
helpful.

unman

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This sounds like:

https://github.com/QubesOS/qubes-issues/issues/4477

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlvqaW4ACgkQ203TvDlQ
MDAAIQ/6A57l5meIGtBmpYGZgIwOzqE6LaOkfghfYot+pXVAdzAr+TXfkkAmy4fp
RmjagpufU2oVma2kwWAUjzVEZxgJI8KIQoBNN1vLiO3dH88KkDN4FJV5EJ1/QnBn
AsdVvhUSNz8l2x1qhDGlthpnNHXaho2laBXV6WLIhGl8WAgnvXCiLyT0PMm/+lPx
opnry33xATKxLBmvIuTVo0YtrHxIoaBicYdaZ3tCyefT3/MADfKjTG2kCMX6IExl
Ov9T2oyEnzkqeC4qOhDvhnLrwcfewt4hRCmsPV/Xv7Q8FBr3MyO/7CVbI38m9bkS
w7lq6uL5bS2HS4kseYOZQzqKEARjO83SEavwfyH+84uijDrfgoNqyFQcFVjpFyCo
bXc/Ncdo2HOflQxtVpuSJmsnSE9+BBzuXD+VXABxst6HGaHlP5Cy8566nJI9GEsk
8jb57cdg8lRHNHzy/uBw/tXyckhOfyjREdD7UG9tju/JYaECNoV+KsXNg2rCisCc
OH3OwS8aNDitvU8sH/J1JMgWh83HMyLH+8bJQoMbLVR6yALPdRyOUQcw15z0XIsG
NUJTr8tZVDVN+KECvVXgXs9LXrnEObyndPe4Mh9sXSZP6jsfDtBpDgTQfnEmXpJ0
yfQTU3hcgSvatqCRJy2DxroGpY8qk/r5vegUuytcuNhO6xo6yZo=
=TTVl
-----END PGP SIGNATURE-----

[Alex]

On 11/12/18 12:11 PM, unman wrote:
> On Sat, Nov 10, 2018 at 12:54:46PM +0100, Alex wrote:

>>[...]

>> Changed that with nano to read "4.0" instead of "$releasever" and voilà,
>> updates went through.
>>
>

> Please bear in mind that if you do this you are breaking the logic of
> dnf, and will have to *manually* update that entry if you upgrade the
> system. You are almost bound to forget this.
> $releasever is part of yum/dnf, not Qubes.

I am well aware of this, both the fact that I'm gonna forget about it
and that $releasever is part of the yum workflow. Actually, since I hate
"fedup", it's the way I update my other computers to a newer fedora
version: dnf upgrade --releasever=29.

> You can pass in --releasever=4.0 as an option, which would be a better
> solution.

That's true; but as the time of writing my original response, I could
not figure out how $releasever was being catenated with both "25" and
"4", so I imagined something "fixed" was automatically appended and
decided not to brute-force the --releasever param.

I use Qubes as my main workstation, so I don't have much time to
extensively try and fix things... Still, I love it so much I thought I'd
jump into the thread and post my workaround.

> I havent encountered this bug myself,so cant account for it. It might be
> helpful if those who have could say if they have enabled testing repos,
> or are using plain 4.0 Qubes repositories. Any other detail would be
> helpful.

A very plain installation of R4.0, some couple of months after the
official release (I had to upgrade the CPU to install R4.0 from R3.2, so
I had to wait for it to arrive from an ebay seller in the UK).

Looking at the bug linked by Andrew (github issue 4477), seems like
Marek already found the cause.

I'll monitor the issue and, as soon as this is resolved (which may
involve a temporal link from yum.qubes-os.org/r25-4/ to
yum.qubes-os.org/r4.0?), will revert the repo files in /etc/yum.repos.d
to the original ones.

Thank you everybody,
--
Alex