Debian-based updatevm show "unable to detect release version" warning

[ydirson]

Qubes OS release

4.1-rc3

Brief summary

This warning is a bit scary. Not sure what it implies, but if it's harmless it would surely be better to get it silenced.

[unman]

Since the original reason behind this issue was a failure to install non-existent packages (#7230), and another issue, #5223, that should now be closed, I see no reason for this to remain open. #7229 is a cosmetic issue which does not affect the update process, and there is a long standing issue about Salt not giving adequate error feedback that affects both Fedora and Debian based updates.

For this reason I suggest this be closed.

[ydirson]

#7229 is a cosmetic issue which does not affect the update process

I rather see this as a UI issue. If there is no problem there's no reason to scare out the user.

[unman]

I don't believe that most users are scared. On a quick poll of 4.1 Debian users I know most of them had not even registered the message. I am not suggesting the issue be closed.

On Wed, Feb 02, 2022 at 05:14:30AM -0800, Yann Dirson wrote:

#7229 is a cosmetic issue which does not affect the update process

I rather see this as a UI issue. If there is no problem there's no reason to scare out the user.

-- Reply to this email directly or view it on GitHub: https://github.com/QubesOS/qubes-issues/issues/7229#issuecomment-1027928778 You are receiving this because you commented.

Message ID: @.***>

[ydirson]

On a quick poll of 4.1 Debian users I know most of them had not even registered the message.

It's understandable to skip that message when everything works - in my case it brought me off-track while trying to understand my problem :)

[andrewdavidwong]

@unman:

For this reason I suggest this be closed.

I am not suggesting the issue be closed.

I'm a bit confused.

[unman]

On Wed, Feb 02, 2022 at 01:36:52PM -0800, Andrew David Wong wrote:

@unman:

For this reason I suggest this be closed.

I am not suggesting the issue be closed.

I'm a bit confused.

So was I. gh throws me sometimes. I am not suggesting this issue be closed. But it is a minor cosmetic issue.

[andrewdavidwong]

The reason it's important to suppress harmless warning messages is because not everyone can be an expert in everything. Prudent people will heed the warning messages presented to them. If they lack the expertise to know that some of the messages are harmless and merely cosmetic, then they don't know how cautious they should be. They'll have to decide, with incomplete information, whether it's worth taking potentially-costly steps to avoid certain behaviors, for example, reducing efficiency and causing undue distress.

By contrast, people who assume "If it were a problem, someone would tell me" won't be affected by such things. However, the latter set of people will eventually fall victim to the not uncommon case in which something is a problem and yet no one has told them, which is why it generally pays to be prudent in the long run.

[ekaflaer]

This is still an issue in QubesOS 4.1.2 if sys-firewall runs on a Debian VM, in my case Debian 12.

$ /usr/lib/qubes/qubes-download-dom0-updates.sh --doit --nogui '--exclude=qubes-template-*' '--quiet' '-y' '--clean' '--action=upgrade'
Unable to detect release version (use '--releasever' to specify release version)
0 files removed
Unable to detect release version (use '--releasever' to specify release version)
Unable to detect release version (use '--releasever' to specify release version)
Error: Failed to download metadata for repo 'qubes-dom0-current': Cannot prepare internal mirrorlist: Status code: 404 for https://yum.qubes-os.org/r$releasever/current/dom0/fc32/repodata/repomd.xml.metalink (IP: 147.75.102.29)

If I change the dnf call in /usr/lib/qubes/qubes-download-dom0-updates.sh to also run the parameter --releasever=4.1 then it works as expected, but of course it does not survive a reboot:

$ /usr/lib/qubes/qubes-download-dom0-updates.sh --doit --nogui '--exclude=qubes-template-*' '--quiet' '-y' '--clean' '--action=upgrade'
0 files removed
No packages downloaded

Could you not statically add the releasever to the script because it is executed by the Dom0 underneath and the script will be upgraded during QubesOS ugprades anyway I suppose?

[ekaflaer]

My assumption that adding the parameter --releasever=4.1 fixes the issue was too early. While it does fix the error message and shows proper output it does neither provide nor download updates. After switching my sys-firewall template back to Fedora, 20 updated packages were presented.

Do you have any suggestions how to fix this without using the Fedora templates?

[andrewdavidwong]

@ekaflaer: This issue is just about the "unable to detect release version" warning message, which @unman said is merely a minor cosmetic issue. It sounds like you are experiencing a different problem. I suggest you follow the advice for getting help and support provided here.

[no-usernames-left]

This is still the case on 4.1.2:

Unable to detect release version (use '--releasever' to specify release version)
Unable to detect release version (use '--releasever' to specify release version)
Fedora 32 - x86_64 [download progress]
Fedora 32 - x86_64 - Updates [download progress]
Qubes Dom0 Repository (updates) [download progress]
Errors during downloading metadata for repository 'qubes-dom0-current':
  - Status code: 404 for https://yum.qubes-os.org/r$releasever/current/dom0/fc32/repodata/repomd.xml.metalink [IP addr]
[remainder similar, snipped]

[no-usernames-left]

This seems to be causing #8482.