Qubes-dist-upgrade still fails - but for new reason!

I’ve had trouble updating templates based on 4.2 since the recent dom0 upgrade (about two weeks). It seems like 4.2 EOL came sooner than planned?

Anyway, I have tried running qubes-dist-upgrade --releasever=4.3 --all-pre-reboot

The result is this error:

Failed to download metadata (baseurl: "file:///var/lib/qubes/updates") for repository "qubes-dom0-cached": Usable URL not found

I am happy to debug, but I don’t know where to start. I’m comfortable with linux, but qubes-specific things are still very new to me. I can say that /var/lib/qubes/updates exists and contains repodata and rpm directories. dom0 was not carried over from previous installation. It is new with this install of 4.3.

I have another computer with only one carryover VM, and the process there went smoothly although it takes a long time!)

The error “Usable URL not found” from DNF on a file:// URL usually means the repodata exists as a directory but isn’t valid enough for DNF to use — either it’s empty, malformed, or was never properly initialized.

Since this is a fresh dom0 4.3 install, the local cache at /var/lib/qubes/updates likely has the directory structure but no actual RPMs (or stale/incomplete repodata), which trips up qubes-dist-upgrade when it tries to use that repo.

Start by checking what’s actually in those directories:

ls -lah /var/lib/qubes/updates/repodata/
ls -lah /var/lib/qubes/updates/rpm/

If rpm/ is empty or repodata/ has no repomd.xml, that’s your problem. DNF can’t make a usable repo from an empty cache.

The likely fix — regenerate the repodata:

sudo createrepo_c /var/lib/qubes/updates/

Then retry your qubes-dist-upgrade command. createrepo_c should be available in dom0 (it’s part of the createrepo_c package).

Also worth checking the repo definition itself:

cat /etc/yum.repos.d/qubes-dom0-cached.repo

Look for anything unexpected in the baseurl, enabled, or gpgcheck lines.

If the rpm/ directory is empty and regenerating repodata doesn’t help, the underlying issue is that the cache was never populated. In that case, you can try bypassing the cached repo entirely by passing --nogpgcheck or by temporarily disabling that repo:

sudo qubes-dist-upgrade --releasever=4.3 --all-pre-reboot --disablerepo=qubes-dom0-cached

The fact that your other machine worked suggests this isn’t a fundamental problem with the upgrade path — just something specific to how that local cache repo got set up on this install.

These were both empty.

Worked, wiht this warning:

C_CREATEREPOLIB: Warning: Cannot parse repomd: /var/lib/qubes/updates/repodata/repomd.xml

However after running that, /var/lib/qubes/updates/repodata now has three files in it. (…/rpm is still empty)

This file does not exist on either computer

I can’t see myself using a repo with gpg disabled, but more important, I’m not sure what you mean by “Doesn’t help” exactly. tmp/ is still empty. It’s repodata/ that is now populated.

The upgrade failed, just not at this step. And on the other computer, rmp/ and repodata/ were also empty, and /etc/yum.repos.d/qubes-dom0-cached.reop did not exist.

I can’t try running it again now because I need to use the computer, but also I’d like to hear your feedback on the above before I try again.

Hey,
You have backup of your installation and qubes? for case of fatal mistake/error during troubleshooting.

Also may help,

Your dom0 updates run well?
Do you try fully update dom0 before run qubes-dist-upgrade?

Funny you should ask about dom0 because recently (last two days ) it has failed to update. But that was not relevent when I posted this.

I don’t know what qubes-dist-upgrade is. I run the updates from the GUI.