Problems with announced Fedora 35 templates

Viktor Ransmayr

unread,

May 28, 2022, 3:28:03 PM5/28/22

to qubes-users

Hello Qubes Community,

I run into a problem already in the very first step of the standard installation method:

If I perform "sudo qubes-dom0-update qubes-template-fedora-35" in a 'dom0' terminal, I receive the following error msg:

[vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35
Redirecting to 'qvm-template install fedora-35'
[Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory
ERROR: qrexec call 'qubes.TemplateSearch' failed.
[vr@dom0 ~]$

My Qubes R4.1 system so far had two 'dom0' updates, which successfully finished using the Qubes Updater ...

If I try it manually, I always receive the following feedback:

[vr@dom0 ~]$
[vr@dom0 ~]$ sudo qubes-dom0-update
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
No updates available
[vr@dom0 ~]$

Any ideas on why the template is not found - and - what I should additionally check on my system?

With kind regards,

Viktor

Steve Coleman

unread,

May 28, 2022, 3:54:40 PM5/28/22

to Viktor Ransmayr, qubes-users

I reported a similar problem a few days ago. At the time the f35 templates were not appearing on some indexes and the devs were looking into it.

I just used a browser to download the rpm's from itl and installed them locally.

Note : You should be using qvm-template command with R4.1, which is why the forwarding message.

--

Viktor Ransmayr

unread,

May 29, 2022, 4:39:53 AM5/29/22

to qubes-users

Hello slcoleman,

stevenlc...@gmail.com schrieb am Samstag, 28. Mai 2022 um 21:54:40 UTC+2:

On Sat, May 28, 2022, 3:28 PM Viktor Ransmayr <viktor....@gmail.com> wrote:
Hello Qubes Community,

I run into a problem already in the very first step of the standard installation method:

If I perform "sudo qubes-dom0-update qubes-template-fedora-35" in a 'dom0' terminal, I receive the following error msg:

[vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35
Redirecting to 'qvm-template install fedora-35'
[Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory
ERROR: qrexec call 'qubes.TemplateSearch' failed.
[vr@dom0 ~]$

My Qubes R4.1 system so far had two 'dom0' updates, which successfully finished using the Qubes Updater ...

If I try it manually, I always receive the following feedback:

[vr@dom0 ~]$
[vr@dom0 ~]$ sudo qubes-dom0-update
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
No updates available
[vr@dom0 ~]$

Any ideas on why the template is not found - and - what I should additionally check on my system?

I reported a similar problem a few days ago. At the time the f35 templates were not appearing on some indexes and the devs were looking into it.

I just used a browser to download the rpm's from itl and installed them locally.

Note : You should be using qvm-template command with R4.1, which is why the forwarding message.

Thanks for your quick reply!

However, when I try to list the available templates using the 'qvm-template' command, I get the same error message:

[vr@dom0 ~]$ qvm-template list

[Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory
ERROR: qrexec call 'qubes.TemplateSearch' failed.
[vr@dom0 ~]$

With kind regards,

Viktor

Steve Coleman

unread,

May 29, 2022, 2:45:29 PM5/29/22

to Viktor Ransmayr, qubes-users

I just checked my own system and ran a python3 trace on the command. The file /etc/qubes-rpc/qubes.TemplateSearch should be on the sys-firewall , assuming the default configuration. If you use a different OS or changed your "Dom0 update qube" in the "Global Settings" for dom0 updates then that update VM may not have this file installed. I would start by looking there.

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e401d5aa-3837-4beb-bd23-1e8dcc6853b8n%40googlegroups.com.

Viktor Ransmayr

unread,

May 30, 2022, 4:37:56 AM5/30/22

to qubes-users

Hello slcoleman & Qubes Community,

stevenlc...@gmail.com schrieb am Sonntag, 29. Mai 2022 um 20:45:29 UTC+2:

On Sun, May 29, 2022 at 4:39 AM Viktor Ransmayr <viktor....@gmail.com> wrote:
stevenlc...@gmail.com schrieb am Samstag, 28. Mai 2022 um 21:54:40 UTC+2:

Thanks for your quick reply!

However, when I try to list the available templates using the 'qvm-template' command, I get the same error message:

[vr@dom0 ~]$ qvm-template list
[Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory
ERROR: qrexec call 'qubes.TemplateSearch' failed.
[vr@dom0 ~]$

I just checked my own system and ran a python3 trace on the command. The file /etc/qubes-rpc/qubes.TemplateSearch should be on the sys-firewall , assuming the default configuration. If you use a different OS or changed your "Dom0 update qube" in the "Global Settings" for dom0 updates then that update VM may not have this file installed. I would start by looking there.

I've not modified anything - and - the "Global Settings" look OK.

I tried to open a console in 'sys-firewall' - but - can't login :-(

I had expected that I could do so, using my credentials, i.e. user 'vr' plus my password ...

FYI-#1: I have performed an 'in-place-upgrade' from 4.0 to 4.1 a little bit over a week ago - and - did not notice any issues, other than this one ...

FYI-#2: Here are the installed packages from dom0:

xen_version : 4.14.5
Linux 5.10.112-1.fc32.qubes.x86_64

Installed Packages:

grub2-qubes-theme.x86_64 5.14.4-2.fc32
kernel-qubes-vm.x86_64 1000:5.4.156-1.fc25.qubes
kernel-qubes-vm.x86_64 1000:5.4.190-1.fc25.qubes
kernel-qubes-vm.x86_64 1000:5.10.112-1.fc32.qubes
python2-qubesadmin.noarch 4.0.32-1.fc25
python2-qubesimgconverter.x86_64 4.0.31-1.fc25
python3-qubesadmin.noarch 4.1.23-1.fc32
python3-qubesdb.x86_64 4.1.13-1.fc32
python3-qubesimgconverter.x86_64 4.1.16-1.fc32
qubes-anaconda-addon.noarch 4.1.8-1.fc32
qubes-artwork.noarch 4.1.12-1.fc32
qubes-artwork-plymouth.noarch 4.1.12-1.fc32
qubes-audio-daemon.x86_64 4.1.21-1.fc32
qubes-audio-dom0.x86_64 4.1.21-1.fc32
qubes-core-admin-addon-whonix.noarch 4.1.1-1.fc32
qubes-core-admin-client.noarch 4.1.23-1.fc32
qubes-core-dom0.noarch 4.1.27-1.fc32
qubes-core-dom0-linux.x86_64 4.1.21-1.fc32
qubes-core-dom0-linux-kernel-install.x86_64 4.1.21-1.fc32
qubes-core-qrexec.x86_64 4.1.18-1.fc32
qubes-core-qrexec-dom0.x86_64 4.1.18-1.fc32
qubes-core-qrexec-libs.x86_64 4.1.18-1.fc32
qubes-db.x86_64 4.1.13-1.fc32
qubes-db-dom0.x86_64 4.1.13-1.fc32
qubes-db-libs.x86_64 4.1.13-1.fc32
qubes-desktop-linux-common.noarch 4.1.12-1.fc32
qubes-desktop-linux-manager.noarch 4.1.14-1.fc32
qubes-dist-upgrade.noarch 4.0.6-1.fc25
qubes-gpg-split-dom0.x86_64 2.0.59-1.fc32
qubes-gui-daemon.x86_64 4.1.21-1.fc32
qubes-gui-dom0.x86_64 4.1.21-1.fc32
qubes-img-converter-dom0.x86_64 1.2.11-1.fc32
qubes-input-proxy.x86_64 1.0.26-1.fc32
qubes-input-proxy-receiver.x86_64 1.0.26-1.fc32
qubes-libvchan-xen.x86_64 4.1.7-1.fc32
qubes-manager.noarch 4.1.23-1.fc32
qubes-menus.noarch 4.1.12-1.fc32
qubes-mgmt-salt.noarch 4.1.14-1.fc32
qubes-mgmt-salt-admin-tools.noarch 4.1.14-1.fc32
qubes-mgmt-salt-base.noarch 4.1.4-1.fc32
qubes-mgmt-salt-base-config.noarch 4.1.1-1.fc32
qubes-mgmt-salt-base-overrides-libs.noarch 4.0.2-1.fc25
qubes-mgmt-salt-base-topd.noarch 4.1.3-1.fc32
qubes-mgmt-salt-config.noarch 4.1.14-1.fc32
qubes-mgmt-salt-dom0.noarch 4.1.14-1.fc32
qubes-mgmt-salt-dom0-qvm.noarch 4.1.4-1.fc32
qubes-mgmt-salt-dom0-update.noarch 4.1.8-1.fc32
qubes-mgmt-salt-dom0-virtual-machines.noarch 4.1.16-1.fc32
qubes-pdf-converter-dom0.x86_64 2.1.12-1.fc32
qubes-release.noarch 4.1-1
qubes-release-notes.noarch 4.1-1
qubes-repo-templates.noarch 4.1.2-1.fc32
qubes-rpm-oxide.x86_64 0.2.4-1.fc32
qubes-usb-proxy-dom0.noarch 1.1.1-1.fc32
qubes-utils.x86_64 4.1.16-1.fc32
qubes-utils-libs.x86_64 4.1.16-1.fc32
qubes-windows-tools.noarch 4.1.68-1
xfce4-settings-qubes.x86_64 4.0.5-2.fc32

Any feedback on what else I should try is highly appreciated!

With kind regards,

Viktor

Viktor Ransmayr

unread,

May 30, 2022, 5:31:56 AM5/30/22

to qubes-users

Hello everyone,

A small but important clarification !

Viktor Ransmayr schrieb am Montag, 30. Mai 2022 um 10:37:56 UTC+2:

Hello slcoleman & Qubes Community,

stevenlc...@gmail.com schrieb am Sonntag, 29. Mai 2022 um 20:45:29 UTC+2:
On Sun, May 29, 2022 at 4:39 AM Viktor Ransmayr <viktor....@gmail.com> wrote:
stevenlc...@gmail.com schrieb am Samstag, 28. Mai 2022 um 21:54:40 UTC+2:

Thanks for your quick reply!

However, when I try to list the available templates using the 'qvm-template' command, I get the same error message:

[vr@dom0 ~]$ qvm-template list
[Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory
ERROR: qrexec call 'qubes.TemplateSearch' failed.
[vr@dom0 ~]$

I just checked my own system and ran a python3 trace on the command. The file /etc/qubes-rpc/qubes.TemplateSearch should be on the sys-firewall , assuming the default configuration. If you use a different OS or changed your "Dom0 update qube" in the "Global Settings" for dom0 updates then that update VM may not have this file installed. I would start by looking there.

I've not modified anything - and - the "Global Settings" look OK.

I tried to open a console in 'sys-firewall' - but - can't login :-(

I had expected that I could do so, using my credentials, i.e. user 'vr' plus my password ...

I tried to open a console in 'sys-firewall' - and - could not login.

However, I (obviously) could open a terminal in 'sys-firewall' ...

Here's the content of /etc/qubes-rpc/ :

[user@sys-firewall ~]$ cd /etc/qubes-rpc/
[user@sys-firewall qubes-rpc]$ ls
qubes.Backup qubes.PdfConvert qubes.SuspendPostAll
qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre
qubes.DetachPciDevice qubes.ResizeDisk qubes.SuspendPreAll
qubes.Filecopy qubes.Restore qubes.USB
qubes.GetAppmenus qubes.SaltLinuxVM qubes.USBAttach
qubes.GetDate qubes.SelectDirectory qubes.USBDetach
qubes.GetImageRGBA qubes.SelectFile qubes.UpdatesProxy
qubes.Gpg qubes.SetDateTime qubes.VMRootShell
qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell
qubes.InstallUpdatesGUI qubes.ShowInTerminal qubes.WaitForSession
qubes.OpenInVM qubes.StartApp
qubes.OpenURL qubes.SuspendPost
[user@sys-firewall qubes-rpc]$

With kind regards,

Viktor

Viktor Ransmayr

unread,

Jun 9, 2022, 1:10:45 AM6/9/22

to qubes-users

Hello Qubes Community,

With Fedora 34 having reached EOL now, is there anything else I can do, other than a complete new installation of Qubes OS R4.1 ?

With kind regards,

Viktor

Catacombs

unread,

Jun 10, 2022, 8:56:48 AM6/10/22

to qubes-users

With Fedora 34 having reached EOL now, is there anything else I can do, other than a complete new installation of Qubes OS R4.1 ?

With kind regards,

Viktor

HI, I am not an extremely knowledgeable Qubes user, but, I did not want your post to go on like no one cared. I am pretty sure the developers do care, they just need to spend their time working on --- stuff. And that might include exactly what will be helpful to you.

I had some problems installing and using Fedora 35, and then updating it later. Sigh.

When I originally installed Qubes 4.1, I chose the option to update over Tor. Used to be I needed to start the Tor Browser for that to work. If nothing else, Tor Browser downloads really slowly. I once started to download an iso of like a gigabyte, and it would take hours. I am suggesting that in some cases, trying to download can have timing issues where some things drop out. And I can guess the system set up by our Qubes developers is not supposed to do that. and I can not prove that it does. Just when it rains here. My connection hiccups. I am just tolerant and try again.

I like the solution I think the developers are working on right now.

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

Which explains itself.

Demi Marie Obenour

unread,

Jun 10, 2022, 5:42:57 PM6/10/22

to Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

At least in the default setup (no sys-gui-gpu), your credentials are
specific to dom0. Everything else will let you log in on the console
as any valid user without a password. “root” will give you a root
shell, while “user” will give you a shell as the same user that GUI
programs run as.

> > I tried to open a console in 'sys-firewall' - and - could not login.
> >
> > However, I (obviously) could open a terminal in 'sys-firewall' ...
> >
> > Here's the content of /etc/qubes-rpc/ :
> >
> > [user@sys-firewall ~]$ cd /etc/qubes-rpc/
> > [user@sys-firewall qubes-rpc]$ ls
> > qubes.Backup qubes.PdfConvert qubes.SuspendPostAll
> > qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre
> > qubes.DetachPciDevice qubes.ResizeDisk qubes.SuspendPreAll
> > qubes.Filecopy qubes.Restore qubes.USB
> > qubes.GetAppmenus qubes.SaltLinuxVM qubes.USBAttach
> > qubes.GetDate qubes.SelectDirectory qubes.USBDetach
> > qubes.GetImageRGBA qubes.SelectFile qubes.UpdatesProxy
> > qubes.Gpg qubes.SetDateTime qubes.VMRootShell
> > qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell
> > qubes.InstallUpdatesGUI qubes.ShowInTerminal qubes.WaitForSession
> > qubes.OpenInVM qubes.StartApp
> > qubes.OpenURL qubes.SuspendPost
> > [user@sys-firewall qubes-rpc]$
> >
>
> With Fedora 34 having reached EOL now, is there anything else I can do,
> other than a complete new installation of Qubes OS R4.1 ?

Installing “qubes-core-agent-dom0-updates” in sys-firewall’s template
should fix the problem.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKjutoACgkQsoi1X/+c
IsGWOhAAolEkyR9ouRejSxMZi1MFngp04eHAUa4r2eARrD74FVkHNaiJ5h3d90JT
fEEO+e+zFnIRvXGxXG8ITtjJsep9ohuYSOY0kiIHWYkAU+FSHrCO8QDnLlqCt5Nx
9rBbgfgKAmpU8/wJxWOm8++rrCuW/7jp79hQ1VwcrPsZuc0fkvq9FB8WgbCPiV+X
qcOmWdeP5OVu/QQ8Rb7HPARLDqYVjiuYaDkVklmgsaEKlI87dsgRryVYIl3SmLyL
8ga4fJoiGaKAu57FcgkvEiXLS06qdBMYYJUwtc+c3EFnnaVbILKfJopa9dDeDsEa
J8JOjJr+ZKpnnxVQMIffaPmWVGlTcirAuqv4QV88Z6tEdqAO2OwIvjieefQ28REc
h3/DnpjAtbo6rDnz2QLkcawNp7kETA+GYuhC6HNrUML4RnxTaN4BJI+DzQEyWHsX
FNhV6ce2pLv4lzNXAQby8NRSqQdHd2bhCiMNFcdKR4QZIX0ZzS0bQmGyBJYQu5vt
LHjTLb+582mpNZowL8X0caCrYNUWCQhfUn75a/5pUqAbA3ud1Hwfgo9025eogha4
F0MWiRhnCOfpGY/eCJqo34vMv+RVG9MReSlzO4mLxFKuFlrjJMVVZ8qeXJUc8gdk
qwUsNDhB7h+7EudL4Vl8SOIKJxCfCeQ7bye1vz7LOaJlj68QEoM=
=19/c
-----END PGP SIGNATURE-----

Viktor Ransmayr

unread,

Jun 11, 2022, 3:22:49 AM6/11/22

to qubes-users

Hello user 'catacombs',

Catacombs schrieb am Freitag, 10. Juni 2022 um 14:56:48 UTC+2:

HI, I am not an extremely knowledgeable Qubes user, but, I did not want your post to go on like no one cared. I am pretty sure the developers do care, they just need to spend their time working on --- stuff. And that might include exactly what will be helpful to you.

I had some problems installing and using Fedora 35, and then updating it later. Sigh.

When I originally installed Qubes 4.1, I chose the option to update over Tor. Used to be I needed to start the Tor Browser for that to work. If nothing else, Tor Browser downloads really slowly. I once started to download an iso of like a gigabyte, and it would take hours. I am suggesting that in some cases, trying to download can have timing issues where some things drop out.   And I can guess the system set up by our Qubes developers is not supposed to do that. and I can not prove that it does.   Just when it rains here. My connection hiccups.   I am just tolerant and try again.

I like the solution I think the developers are working on right now.

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

Which explains itself.

Thnaks for making me aware about the planned release of Qubes OS 4.1.1.

With kind regards,

Viktor

Viktor Ransmayr

unread,

Jun 11, 2022, 3:41:08 AM6/11/22

to qubes-users

Hello Demi,

Demi Marie Obenour schrieb am Freitag, 10. Juni 2022 um 23:42:57 UTC+2:

> >> I've not modified anything - and - the "Global Settings" look OK.
> >>
> >> I tried to open a console in 'sys-firewall' - but - can't login :-(
> >>
> >> I had expected that I could do so, using my credentials, i.e. user 'vr'
> >> plus my password ...
> >>

At least in the default setup (no sys-gui-gpu), your credentials are
specific to dom0. Everything else will let you log in on the console
as any valid user without a password. “root” will give you a root
shell, while “user” will give you a shell as the same user that GUI
programs run as.

Thanks for that clear explanation.

> > I tried to open a console in 'sys-firewall' - and - could not login.
> >
> > However, I (obviously) could open a terminal in 'sys-firewall' ...
> >
> > Here's the content of /etc/qubes-rpc/ :
> >
> > [user@sys-firewall ~]$ cd /etc/qubes-rpc/
> > [user@sys-firewall qubes-rpc]$ ls
> > qubes.Backup qubes.PdfConvert qubes.SuspendPostAll
> > qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre
> > qubes.DetachPciDevice qubes.ResizeDisk qubes.SuspendPreAll
> > qubes.Filecopy qubes.Restore qubes.USB
> > qubes.GetAppmenus qubes.SaltLinuxVM qubes.USBAttach
> > qubes.GetDate qubes.SelectDirectory qubes.USBDetach
> > qubes.GetImageRGBA qubes.SelectFile qubes.UpdatesProxy
> > qubes.Gpg qubes.SetDateTime qubes.VMRootShell
> > qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell
> > qubes.InstallUpdatesGUI qubes.ShowInTerminal qubes.WaitForSession
> > qubes.OpenInVM qubes.StartApp
> > qubes.OpenURL qubes.SuspendPost
> > [user@sys-firewall qubes-rpc]$
> >
>
> With Fedora 34 having reached EOL now, is there anything else I can do,
> other than a complete new installation of Qubes OS R4.1 ?

Installing “qubes-core-agent-dom0-updates” in sys-firewall’s template
should fix the problem.

I checked which 'qubes-core' packages are installed in the 'sys-firewall' VM on my system.

Here are the results:

[user@sys-firewall ~]$
[user@sys-firewall ~]$ dnf list --installed | grep qubes-core
qubes-core-agent.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current
qubes-core-agent-dom0-updates.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current
qubes-core-agent-nautilus.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current
qubes-core-agent-network-manager.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current
qubes-core-agent-networking.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current
qubes-core-agent-passwordless-root.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current
qubes-core-agent-qrexec.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current
qubes-core-agent-systemd.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current
[user@sys-firewall ~]$

So the package is installed - but - it is on version '4.0.65-1.fc34'. - That does not look right to me ...

Do you have any further suggestions, what I could still try?

Or should I just wait until the dev-team will release Qubes OS version 4.1.1?

With kind regards,

Viktor

Steve Coleman

unread,

Jun 11, 2022, 11:52:19 AM6/11/22

to qubes-users

On Thursday, June 9, 2022 at 1:10:45 AM UTC-4 viktor....@gmail.com wrote:

Hello Qubes Community,

Here's the content of /etc/qubes-rpc/ :

[user@sys-firewall ~]$ cd /etc/qubes-rpc/
[user@sys-firewall qubes-rpc]$ ls
qubes.Backup qubes.PdfConvert qubes.SuspendPostAll
qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre
qubes.DetachPciDevice qubes.ResizeDisk qubes.SuspendPreAll
qubes.Filecopy qubes.Restore qubes.USB
qubes.GetAppmenus qubes.SaltLinuxVM qubes.USBAttach
qubes.GetDate qubes.SelectDirectory qubes.USBDetach
qubes.GetImageRGBA qubes.SelectFile qubes.UpdatesProxy
qubes.Gpg qubes.SetDateTime qubes.VMRootShell
qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell
qubes.InstallUpdatesGUI qubes.ShowInTerminal qubes.WaitForSession
qubes.OpenInVM qubes.StartApp
qubes.OpenURL qubes.SuspendPost
[user@sys-firewall qubes-rpc]$

With Fedora 34 having reached EOL now, is there anything else I can do, other than a complete new installation of Qubes OS R4.1 ?

Sorry for not replying for a while but somehow I had been blacklisted from posting to the forum. Still not sure why that happened. I did reply by email but that bounced with a forum gateway denial response. I could login to the forum but it would not let me reply to anything. Other Discourse forums were also giving me problems so its possible somebody was spamming using my email address and thus put me on some kind of global blacklist, but that is just a guess.

It looks to me that your current sys-firewall template is not up to date for your current R4.1 version, or just broken. If you have any other templates on your system (e.g. debian-11, fc35-minimal, fc35-xfce ) you might want to try switching sys-firewall to something else and then try to use qvm-template to download a working template of the f35 flavor. If that does not work you might try to just download a new template manually from here:

https://yum.qubes-os.org/r4.1/templates-itl/rpm/

If needed, you will need to move that rpm to media accessible to your dom0 for the local rpm utility install. Once that template is installed, update the template asap, and then you should switch your sys-firewall to use that template and then try qvm-template again. Once sys-firewall has an up-to-date and working template this problem should be resolved.

btw - I learned this the hard way myself years ago (R3.1 days) and now I always keep an extra unmodified template around for emergencies such as this. I also use a different and more simplified template tailored explicitly for both sys-net and sys-firewall so that future updates are less likely to break my connectivity. If anything happens to my connectivity I can just switch one or both VM's to use that alternate template while I debug the problem.

When migrating to Qubes R4.1 I also had a similar problem after restoring my old templates from backup onto the new Qubes R4.1 system. The old templates did not work correctly with the new system so I needed to get a pristine fc35 template to get things working while I upgraded my older fc34 templates in place. Mixing the two on the new system was just a can-of-worms and updating them all in place to f35 is advisable rather than leaving them around as fc34 in a broken state. If your customizations to your fc34 template was minimal then making a clean break to fc35 is likely a very good idea.

I hope this helps.

Demi Marie Obenour

unread,

Jun 11, 2022, 1:03:38 PM6/11/22

to Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jun 11, 2022 at 12:41:08AM -0700, Viktor Ransmayr wrote:
> Hello Demi,
>
> Demi Marie Obenour schrieb am Freitag, 10. Juni 2022 um 23:42:57 UTC+2:
>
> > > >> I've not modified anything - and - the "Global Settings" look OK.
> > > >>
> > > >> I tried to open a console in 'sys-firewall' - but - can't login :-(
> > > >>
> > > >> I had expected that I could do so, using my credentials, i.e. user
> > 'vr'
> > > >> plus my password ...
> > > >>
> >
> > At least in the default setup (no sys-gui-gpu), your credentials are
> > specific to dom0. Everything else will let you log in on the console
> > as any valid user without a password. “root” will give you a root
> > shell, while “user” will give you a shell as the same user that GUI
> > programs run as.
> >
>
> Thanks for that clear explanation.

You’re welcome!

You should be able to manually change your DNF repositories in
sys-firewall’s template. “dnf --best --refresh distro-sync” should then
take care of the rest, unless I have missed something.

> Or should I just wait until the dev-team will release Qubes OS version
> 4.1.1?

You should not have to do this.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKkyuUACgkQsoi1X/+c
IsFmyQ/+Mvzo04A53PLM8Oc6Iu3hZzK6MbqMNon9Tc+YGDU2Wizwhdj02Xy0XXIt
BshmNrnPn0bAtZs5hbcjRFc1Bvk6fnQ8/7tscHEuauqnXe1yN8TsB/Zt6JWxKAbl
VvkWb33/+fGZyMn3FJxrvsDRMgjYDn020hEfic+R0jAmJubpzfBva0xXP8Pgd2Aa
mAV4YGAlKzXRny142yQt8m0iDXyZGQe3gAdIyMXuL0q30KKF4L6rbKNDX8y5dJ3/
I05kakpi+MZyiVzO2d2U5Ylen3RE1J+zvhVkTwUGX3S2zOwWdrW4iTgYvF8Bvxxh
Hfu8WpBjgkLxZKaoh8yy/HbzJEmrVPRs4gMc8Cvwb1umcseszDZXVOtyMsSZp+T3
nBEvdZ2LpTezd0qKL2p2AiyvEZVjQQdBDGKQ3o1b2lVWVt5fR3dSFC9DLizVsabz
kV3k+tVl6MfUPvWIZdKondxDutxTLb5DIfGfKh3VfQr7Dhzpvs6lVJN3W/V8nMDm
EbiHceJF9AOzkU+fhueMi7srxxkgO46BNFttsNnjVxhJEp5ARLvPSH0ckNYweZV2
M7IUwUg4pmMCtrY8cM2li1977MkbNoHyGRlnIcORvzD/su1wc2OZOeg8S0wnx4tU
kP8uelWiM2sQaIY30CRL6F/8itnYXs6sykKr0exeoktOAdbA2lM=
=p7Aa
-----END PGP SIGNATURE-----

Demi Marie Obenour

unread,

Jun 11, 2022, 1:07:03 PM6/11/22

to Steve Coleman, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The forum mirror of the mailing list is read-only. Not sure if that is
the culprit.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKky7IACgkQsoi1X/+c
IsH/AhAAnVrY9/dKsAeplvGFe4YStiCDMOZ4OjhVWVZUUWMDBLliWO97BM6Mngd6
gq1RTUF4tyXoaCEu3hgChB/zlWJsRAZeaJcR1AXixULHvIy5zDdbUGqhB5fthqTm
9pOeKCElb9SXKbwpWXkSoP3XidYRn+nG4wrGziASfHRI7LTvIRBVa08Zr5b0Bn8f
ngmFjMmQ5LTdYf+1cszfjwvL/YsVAvOfCwShuixt8EjFt30f0fTAlYEQ1At7aTdL
ISp+P4BLgg01oZ63+gHyW8aYpRNtMjCig4EmTHXhfruI5Z9j+uK7FpYZ9jhE5V/B
Yg4bIvGxWXIM5PoCKSuU3/jqG+9m9R/X7iCbw7Bv6YAXgBHTXwuVczj74L1Afr2O
/5wupFiMQGVXetiVZPpdsXPEnHrmcpzdoV7cJ3yKdnF5YGTpbEui3fL6c3w+Hpj/
9GOkUhs4/y+8myNEhq5EGpuFCHnUBeOjWznlarITOwSXdKIwWi2NKj/PL27k3eSf
htsNhI7LMRC9j5rC/SVFoItZWfmRJ/nabxdzIBL1Gwb5ewYKMp1h9T5Pkvltg021
i0oy8Ief4r3QyIoeHwYpeE3zqwTa7G+3zCRrVtGUVEOkysYM4y2xJcBUhgihfH0b
fx+49ILWrBeMeorTFCy/2dKlW01m1z6hF383RwgNdsacKC/HM+U=
=j6j5
-----END PGP SIGNATURE-----

Viktor Ransmayr

unread,

Jun 12, 2022, 3:48:45 AM6/12/22

to qubes-users

Hello Demi,

Demi Marie Obenour schrieb am Samstag, 11. Juni 2022 um 19:03:38 UTC+2:

> Do you have any further suggestions, what I could still try?

You should be able to manually change your DNF repositories in
sys-firewall’s template. “dnf --best --refresh distro-sync” should then
take care of the rest, unless I have missed something.

This sounded like a very simple exercise, however it did not improve anything :-(

Here are my logs & notes:

###

I have not changed the templates for the 'sys- * ' VMs - and - I have also not yet created any specific 'sys- * ' VMs.

* Therfore this needs to be applied to the 'fedora-34' template - OK - See "Log-001".
* Close all Study-VMs - and - close / restart the affected 'sys- * ' VMs ...

### 2022-06-12 ~ 08:30 (UTC)

Try now to download the new 'fedora-35' templates again - OK? - See "Log-002".

### Log-001

[user@fedora-34 ~]$
[user@fedora-34 ~]$ dnf --best --refresh distro-sync
Error: This command has to be run with superuser privileges (under the root user on most systems).
[user@fedora-34 ~]$ sudo dnf --best --refresh distro-sync
Fedora 34 - x86_64 73 kB/s | 21 kB 00:00
Fedora 34 openh264 (From Cisco) - x86_64 3.9 kB/s | 989 B 00:00
Fedora 34 - x86_64 - Updates 18 kB/s | 19 kB 00:01
Qubes OS Repository for VM (updates) 14 kB/s | 3.8 kB 00:00
Qubes OS Repository for VM (updates) 121 kB/s | 210 kB 00:01
Dependencies resolved.
================================================================================
Package Architecture Version Repository Size
================================================================================
Downgrading:
dkms noarch 3.0.2-1.fc34 updates 58 k

Transaction Summary
================================================================================
Downgrade 1 Package

Total download size: 58 k
Is this ok [y/N]: y
Downloading Packages:
dkms-3.0.2-1.fc34.noarch.rpm 194 kB/s | 58 kB 00:00
--------------------------------------------------------------------------------
Total 37 kB/s | 58 kB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Downgrading : dkms-3.0.2-1.fc34.noarch 1/2
Running scriptlet: dkms-3.0.2-1.fc34.noarch 1/2
Running scriptlet: dkms-3.0.3-1.fc34.noarch 2/2
Cleanup : dkms-3.0.3-1.fc34.noarch 2/2
Running scriptlet: dkms-3.0.3-1.fc34.noarch 2/2
Verifying : dkms-3.0.2-1.fc34.noarch 1/2
Verifying : dkms-3.0.3-1.fc34.noarch 2/2
Notifying dom0 about installed applications

Downgraded:
dkms-3.0.2-1.fc34.noarch

Complete!
[user@fedora-34 ~]$

### Log-002

[vr@dom0 ~]$

[vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35
Redirecting to 'qvm-template install fedora-35'

[Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory
ERROR: qrexec call 'qubes.TemplateSearch' failed.
[vr@dom0 ~]$

[vr@dom0 ~]$
[vr@dom0 ~]$ sudo qubes-dom0-update
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
No updates available

[vr@dom0 ~]$ sudo qubes-dom0-update --clean --console --show-output

Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...

warning: Converting database from bdb_ro to sqlite backend
0 files removed
Fedora 32 - x86_64 6.8 MB/s | 70 MB 00:10
Fedora 32 - x86_64 - Updates 6.2 MB/s | 30 MB 00:04
Qubes Dom0 Repository (updates) 947 kB/s | 3.8 MB 00:04
Last metadata expiration check: 0:00:03 ago on Sun Jun 12 08:40:15 2022.
Dependencies resolved.
Nothing to do.
Complete!
No packages downloaded

No updates available
[vr@dom0 ~]$

###

I really do appreciate your personal support - as well as - the one from the Qubes OS community in general.

I'm using these troubles ( I'm having / making ;-) to learn more about Qubes OS - and - hope that eventually I'll be able to give back myself ...

With kind regards,

Viktor

Viktor Ransmayr

unread,

Jun 12, 2022, 4:44:42 AM6/12/22

to qubes-users

Hello Steve,

stevenlc...@gmail.com schrieb am Samstag, 11. Juni 2022 um 17:52:19 UTC+2:

It looks to me that your current sys-firewall template is not up to date for your current R4.1 version, or just broken. If you have any other templates on your system (e.g. debian-11, fc35-minimal, fc35-xfce ) you might want to try switching sys-firewall to something else and then try to use qvm-template to download a working template of the f35 flavor.

Your suggestion was obviously the next step I tried. - Unfortunately again it did not improve anything :-(

Here are my logs & notes:

###

Change the template for 'sys-firewall' from 'fedora-34' to 'debian-11'.

* Close all Study-VMs - and - close the affected 'sys-whonix' VM ...
* Perform the template change ...
* Try now to download the new 'fedora-35' templates - Not OK - See "Log-001".

### Log-001

[vr@dom0 ~]$

[vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35
Redirecting to 'qvm-template install fedora-35'

[Qrexec] /bin/sh: 0: cannot open /etc/qubes-rpc/qubes.TemplateSearch: No such file

ERROR: qrexec call 'qubes.TemplateSearch' failed.
[vr@dom0 ~]$

[vr@dom0 ~]$
[vr@dom0 ~]$ sudo qubes-dom0-update --clean --console --show-output

Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...

0 files removed
Unable to detect release version (use '--releasever' to specify release version)
Fedora 32 - x86_64 - Updates 6.3 MB/s | 35 MB 00:05
Fedora 32 - x86_64 6.3 MB/s | 63 MB 00:09
Qubes Dom0 Repository (updates) 572 kB/s | 3.8 MB 00:06
Last metadata expiration check: 0:00:05 ago on Sun Jun 12 09:48:13 2022.

Dependencies resolved.
Nothing to do.
Complete!
No packages downloaded

No updates available
[vr@dom0 ~]$

###

Thanks a lot for your support in trying to find a solution for my problem.

With kind regards,

Viktor

unman

unread,

Jun 12, 2022, 8:49:15 AM6/12/22

to Viktor Ransmayr, qubes-users

Hi Viktor

My vanilla debian-11 template *does* have
/etc/qubes-rpc/qubes.TemplateSearch.
That file is provided by qubes-core-agent-dom0-updates.
I currently have version 4.1.36-1

I suggest you make sure that you have that package installed and that
your debian-11 template is fully updated.
That should resolve the problem.

unman

Demi Marie Obenour

unread,

Jun 12, 2022, 10:48:52 AM6/12/22

to Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Jun 12, 2022 at 12:48:45AM -0700, Viktor Ransmayr wrote:
> Hello Demi,
>
> Demi Marie Obenour schrieb am Samstag, 11. Juni 2022 um 19:03:38 UTC+2:
>
> > > Do you have any further suggestions, what I could still try?
> >
> > You should be able to manually change your DNF repositories in
> > sys-firewall’s template. “dnf --best --refresh distro-sync” should then
> > take care of the rest, unless I have missed something.
> >
>
> This sounded like a very simple exercise, however it did not improve
> anything :-(
>
> Here are my logs & notes:

What is the contents of /etc/yum.repos.d in your fedora-34 template?
You might have repositories pointing at the R4.0 repos.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKl/M0ACgkQsoi1X/+c
IsEGzw//ex9Dg92JaQilUQDIy2UD+H8VPiWMo+mRUQwM9Ydtp4GdjH3Veal5542R
aWxB6ScO84hK+6JIBx3DsiAbXKOZCiLqtGCmuy6M7BCLagXj6ExSxT9iCtRqKAFM
V0GxitfS8bZ6GqsH9ve+7sHAHr6Q4eTAnVGbxeAv60wDqt97/EDhWK+P1A1/CYkg
86eQvdk5bSqQEbKCdDAb1ydTd8aacEcXxsQ3saY+NWoSIquqq55YFQkFBMBVebOy
CX8YXYopWM/HdnywAwLE7Iusb4DW1xwjAoh72yQkbi1zGVy6WGdSQ+rHYZQMrxd5
3q8ZujynmI3iCdPVHjRFHodWVQ5xwRxZZd9ccNK+J/4fZpsMPXidPnaAFJUtK/b4
ZRWJuAzqOt85a5026AjVKz/0Pxpqwy3njVqggmypkJwtzWdIgFauCEKR4ncKN6aY
3X+wWlJOTgz4T+DkKlRH6ID+78PE1274wOaQh4AVdyGODO3zmfIp4/AXIT2iNcn/
pS+W30lVnPqunu4uqTJLfXbiKBCcSkbfRk7ZZ3KbEuxc5TFKJi2VhuV299Tq0iCs
+jsHBUyBYy2JEG0v9KfE1JyNKUlV+H3knF+zChn+cOB5VVPFjYYXIBfn28P82BKM
5+m6wiXncbzVDF18QRtWmntQHaN2qLI+7lUTnJT+J46o2n48wA4=
=vGIz
-----END PGP SIGNATURE-----

Viktor Ransmayr

unread,

Jun 12, 2022, 12:01:02 PM6/12/22

to qubes-users

Hello Demi,

Demi Marie Obenour schrieb am Sonntag, 12. Juni 2022 um 16:48:52 UTC+2:

What is the contents of /etc/yum.repos.d in your fedora-34 template?
You might have repositories pointing at the R4.0 repos.

Here's the content:

[user@fedora-34 ~]$
[user@fedora-34 ~]$ cd /etc/yum.repos.d
[user@fedora-34 yum.repos.d]$ ls -all
total 68
drwxr-xr-x 2 root root 4096 May 20 21:05 .
drwxr-xr-x 114 root root 12288 Jun 12 17:11 ..
-rw-r--r-- 1 root root 183 Oct 2 2021 adobe-linux-x86_64.repo
-rw-r--r-- 1 root root 728 Apr 28 2021 fedora-cisco-openh264.repo
-rw-r--r-- 1 root root 1344 Apr 28 2021 fedora-updates-testing.repo
-rw-r--r-- 1 root root 1286 Apr 28 2021 fedora-updates.repo
-rw-r--r-- 1 root root 1239 Apr 28 2021 fedora.repo
-rw-r--r-- 1 root root 191 Oct 2 2021 google-chrome.repo
-rw-r--r-- 1 root root 1483 May 5 02:00 qubes-r4.repo
-rw-r--r-- 1 root root 1324 Oct 2 2021 rpmfusion-free-updates-testing.repo
-rw-r--r-- 1 root root 1264 Oct 2 2021 rpmfusion-free-updates.repo
-rw-r--r-- 1 root root 1248 Oct 2 2021 rpmfusion-free.repo
-rw-r--r-- 1 root root 1369 Oct 2 2021 rpmfusion-nonfree-updates-testing.repo
-rw-r--r-- 1 root root 1309 Oct 2 2021 rpmfusion-nonfree-updates.repo
-rw-r--r-- 1 root root 1312 Oct 2 2021 rpmfusion-nonfree.repo
[user@fedora-34 yum.repos.d]$

With kind regards,

Viktor

Demi Marie Obenour

unread,

Jun 12, 2022, 12:18:56 PM6/12/22

to Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Can you check that qubes-r4.repo points to the R4.1 repository and not
the R4.0 repository? The symptoms you are describing are consistent
with it pointing to the R4.0 repository.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKmEeoACgkQsoi1X/+c
IsHoSw//WbVx6GB+e+uC2HRtt0i3kj1FdxU05FMqHEtL/mdjQ7DStoZCDrsl4BP5
ZsLznbO3XsXSIZgJKFS7CjHUFhJkDjB8kxP/1jQhGwhzF6ngqWTs4MMQA/jmNSq0
apqu7U8p+PElXyzU3aXIO3WLpuujIX+jmNzb2GRybmpVkei4AsMPhEhQn5Aan0cB
8sIyHJXxcM9n5oh0uLpLyEIaUw9qroW0OX5Akit/Qb6xGGypHawyJElslzA32KPF
WG9tGTyPICKgeIjXiJOM0TrLEOCwZGFQ7OzuNA8XRTw2UfZ5DU3n/0FlUehcxXAB
1kYfubwNiKfaLTyM+yHy9AIhTOTJBTEC158/75lXqfyuWZXGyHhkQZs+rZH4mwiZ
brj1hVhyRafMU2XxxShrpYejBJJc9MuPxxU8dpTmaeTw/w/CW0rNpLNXjzprbo6J
j5r7YDZR6oKDF9NEtfNRji4D8Mu0kvNVXaE0d8LQY4fqmaGDB2dEpLKgChkdDxQ4
EPaIWCgwm0JN4p9Fltw+AwmBOweeKJS/Y+gWSgFyicolSDEd9tgJoYfJvLZC811K
HUIZKEZJ5YBlvKawpLT5H+SacGcgFAbyxEmbMzpb3HcwRNMTsyO+Wbq4oCdTjUIG
S+OUJbP6tFFOzGhcB+rgbWCusFCeErj2zsd8CUCBUCduxN3R5MA=
=Ih/Q
-----END PGP SIGNATURE-----

Viktor Ransmayr

unread,

Jun 12, 2022, 12:35:32 PM6/12/22

to Viktor Ransmayr, qubes-users

Hello Demi,

Here's the content of this file:

[user@fedora-34 yum.repos.d]$

[user@fedora-34 ~]$ cd /etc/yum.repos.d

[user@fedora-34 yum.repos.d]$ cat qubes-r4.repo
[qubes-vm-r4.0-current]
name = Qubes OS Repository for VM (updates)
baseurl = https://yum.qubes-os.org/r4.0/current/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current/vm/fc$releasever
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=1

[qubes-vm-r4.0-current-testing]
name = Qubes OS Repository for VM (updates-testing)
baseurl = https://yum.qubes-os.org/r4.0/current-testing/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current-testing/vm/fc$releasever
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=0

[qubes-vm-r4.0-security-testing]
name = Qubes OS Repository for VM (security-testing)
baseurl = https://yum.qubes-os.org/r4.0/security-testing/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/security-testing/vm/fc$releasever
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=0

[qubes-vm-r4.0-unstable]
name = Qubes OS Repository for VM (unstable)
baseurl = https://yum.qubes-os.org/r4.0/unstable/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/unstable/vm/fc$releasever
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable
gpgcheck = 1
enabled=0

[user@fedora-34 yum.repos.d]$

You were right - but - I have no clue what went wrong & what to do next ...

With kind regards,

Viktor

Steve Coleman

unread,

Jun 12, 2022, 3:40:30 PM6/12/22

to qubes...@googlegroups.com

It looks to me like your template is a 4.0 Template regardless of the fedora revision.

Here is what I would do:

1) Download a R4.1 fedora-35 template rpm here:

https://ftp.qubes-os.org/repo/yum/r4.1/templates-itl/rpm/qubes-template-fedora-35-4.0.6-202205081759.noarch.rpm

2) The rpm needs to be moved someplace where dom0 can install it.

3) dom0> sudo dnf install /path/to/template.rpm

or sudo rpm -i /path/to/template.rpm

4) Update the template first to get all the current security patches

5) switch sys-firewall to use the new template and restart sys-firewall

6) Then use qvm-template to retrieve any other templates you need for R4.1 usage.

Demi Marie Obenour

unread,

Jun 12, 2022, 4:59:36 PM6/12/22

to viktor....@googlemail.com, Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

$ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo

should fix that.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKmU7IACgkQsoi1X/+c
IsEu8w/9E4EhJw1XTyY40RJ0QuTZJeD8DlnMW6NRn57qMIpzfdp2zEnWlkpUrO1R
8pzzREOSiZSwy9LU73V4VApkJBgGH4ERoiM7wedZlvst44/jGS1KEJyuE1ALJF1D
S5f4/DDgQsOxat0b4EzSv1NFRbROxv0VkYdvEkFTaiMV8L2LfpJVbadpDfS5Q615
rrHYzgZF4Fr5F+p/sF0h/YLcefCXMidvBiVs0RhTHVcNqCH5v0VGBPtOLqXfbARq
bwvWb3pHo++RDUmTPbkvh80f0suBlTqLSuPS4DLcm21mrPHcDAlmHOiYispcS9JO
FHXf7rJkpIbpvtQGI6fop0+WchOENulU/l15L+ECpzwm+GeM6Z7/7/QEyckPyUFu
wB3oUfrYH1oEv40oGPU0ovO+5kuMStkbaAejHFBejeOjGB/MBY586X/xi5bZcaCE
fFYmEKGP1/311MZSybSi0XezVUODdXhSHLOOyDkribkGSS7rJS9HcPpvQryjxvOu
e2efA9Bo+/1Fzd/vdljZpF4xOxzPRtq+3zCp78PKQoFFsMYJXnOiIM8tehYZeyi5
CMrtCDUW1c4GEV3v+JNfW3AgIBC22lkpB6Z5w1vdiMEqNLNJrAE9Olzz4coWPoss
MR/mXIvPR1/VVcYXC359dKkWZGtsRAwC0EzDBwIsn4bdEuc96qI=
=G4ZN
-----END PGP SIGNATURE-----

Demi Marie Obenour

unread,

Jun 12, 2022, 5:02:58 PM6/12/22

to Steve Coleman, qubes...@googlegroups.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

That’s not a good idea. For one, it is insecure. This could be fixed
with appropriate uses of rpmcanon and rpmkeys -K, but it is much simpler
to just fix the repo file. The R4.1 packages will then install over the
R4.0 ones.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKmVHsACgkQsoi1X/+c
IsFJExAAuvjlsXLTlDCcmB6dSCl9gT95KmZKT8jPuXl3RL+Y2d24jOhdvdVcCtpH
9VZGOCuilKxv/lR0KjfEXfs8sH7PEcN1Y996Vb2+IUhkUxyYbCi2J7kRkmNYbaVh
aJlCP4xkxZEfG8ryEFSt6XWOaO0Owb3oPhA+RFa99T3gtRwTs33O2s1+jlsbsQtT
TMlrRyP6tMFhKmp8jRs+88JYoAFyqmX0w+T+tAYkuUgUHL3CGJuUVtkGLEC3re6/
+LtsvpyQ57X/2nT3Y7O4K4gZtIlRVNIogUEvLtNrz5EgMiFC6C3pZVaZhXrXwtSe
7GcaBsH4cRoHGQz6OB+1KznZmDoi2+8Hem/vE/jNNkYFMxRW5Wk1rN6STvw9jKVp
BUzGk2rtwzpYjrZhPSuU4vjVygnAEhCcLXahkdasnn2Tg1CeNSM7onF9TDYDHPhU
eIxs79hb5w9WmMMuc+1bVgB4A1wu/ev8fAfJSr4x1jzo4rfNMzaPDaNfdeMmqH/3
K3EflFnO0r9R/ko7c8wMo5HUddKja9RElGEgzs8fV94LYGHmEfqgMQlSyS+EzCdC
DUVsZ2lsURHGh9n8xc+brnSptJb4tiTtDilbnGu4OR67vt1ZHXz3zNSEg3LCFRIj
cyXrAeq7tJINW0tFHp0KHWB9No8h4KhvZxKdbGKGtxaeYL8R3LU=
=cdDa
-----END PGP SIGNATURE-----

Viktor Ransmayr

unread,

Jun 13, 2022, 3:14:57 PM6/13/22

to qubes-users

Hello Demi,

On Sun, 12 Jun 2022, 22:59 Demi Marie Obenour, <de...@invisiblethingslab.com> wrote:

> You were right - but - I have no clue what went wrong & what to do next ...

$ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo

should fix that

Upgrade of template is still running ...

I'll provide another update as soon as it's finished.

With kind regards

Viktor

Viktor Ransmayr

unread,

Jun 14, 2022, 12:42:14 AM6/14/22

to qubes-users

Hello Demi,

It is still running, after more than 10 hours. - This should have finished by now, correct?

Here are my notes & logs:

###

Change the template for 'sys-firewall' back from 'debian-11' to 'fedora-34'.

* Close all Study-VMs - and - close the affected 'sys-whonix' VM ...

### 2022-06-13 ~ 18:48 (UTC)

* Perform the template change - and - get back here ;-)

### 2022-06-13 ~ 18:51 (UTC)

Open the 'fedora-34' template & apply the suggested change - OK? - See "Log-002".

### 2022-06-13 ~ 19:00 (UTC)

Start the update of 'fedora-34' template suggested by Qubes Updater - See "Log-003".

* 2022-06-13 ~ 19:15 (UTC) -> Still ongoing
* 2022-06-13 ~ 19:30 (UTC) -> Still ongoing
* 2022-06-13 ~ 20:00 (UTC) -> Still ongoing
* 2022-06-13 ~ 21:00 (UTC) -> Still ongoing
* ...
* 2022-06-14 ~ 05:45 (UTC) -> Still ongoing ???

### Log-002

[user@fedora-34 yum.repos.d]$
[user@fedora-34 yum.repos.d]$ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo
[user@fedora-34 yum.repos.d]$
[user@fedora-34 yum.repos.d]$

[user@fedora-34 yum.repos.d]$ cat qubes-r4.repo

[qubes-vm-r4.1-current]

name = Qubes OS Repository for VM (updates)

baseurl = https://yum.qubes-os.org/r4.1/current/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current/vm/fc$releasever

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=1

[qubes-vm-r4.1-current-testing]

name = Qubes OS Repository for VM (updates-testing)

baseurl = https://yum.qubes-os.org/r4.1/current-testing/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current-testing/vm/fc$releasever

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=0

[qubes-vm-r4.1-security-testing]

name = Qubes OS Repository for VM (security-testing)

baseurl = https://yum.qubes-os.org/r4.1/security-testing/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/security-testing/vm/fc$releasever

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1
enabled=0

[qubes-vm-r4.1-unstable]

name = Qubes OS Repository for VM (unstable)

baseurl = https://yum.qubes-os.org/r4.1/unstable/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/unstable/vm/fc$releasever

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable
gpgcheck = 1
enabled=0

[user@fedora-34 yum.repos.d]$

###

I intend to cancel the upgrade operation. - Any other suggestion?

With kind regards,

Viktor

Demi Marie Obenour

unread,

Jun 14, 2022, 2:41:32 PM6/14/22

to Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jun 13, 2022 at 09:42:14PM -0700, Viktor Ransmayr wrote:
> Hello Demi,
>
> Viktor Ransmayr schrieb am Montag, 13. Juni 2022 um 21:14:57 UTC+2:
>
> >
> > On Sun, 12 Jun 2022, 22:59 Demi Marie Obenour, <
> > de...@invisiblethingslab.com> wrote:
> >
> >>
> >> > You were right - but - I have no clue what went wrong & what to do next
> >> ...
> >>
> >> $ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo
> >>
> >> should fix that
> >>
> >
> > Upgrade of template is still running ...
> >
> > I'll provide another update as soon as it's finished.
> >
>
> It is still running, after more than 10 hours. - This should have finished
> by now, correct?

Yes, unless you have a very slow network connection. I recommend using
dnf interactively for this, not Salt; Salt’s lack of progress feedback
will make this extremely frustrating.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKo1lMACgkQsoi1X/+c
IsGXCRAAmIRX1+KRbpgC6wfYjsBPMPpp15R5LA5DfLWdmvzW+y2RtwNdGXCM8bOj
Z0rkl8OXHwIgYq9Y7B9YT99zQ9nvM6Gv32/VQ8fE3RDKAnqsVx1Uu2HvO8krcEtL
5saEE0ZagSFP16ncQPStkKVnmhpSiGumy6dthQV9noXB3PUM9Yrr85QQfxgeGrbb
nR7Xf9tEx8btIcdEkyTJXlBYcvtz0ff4M4RKRFXaS3yhQHq8sQOkp6PWcEBtro5u
wutdFC5lE5i3JWnwjtf4nWxNYg4Ivhbszz+1CpdwskOGvx2eWGtICmZe86960AWx
/c7htwvIH45tNMNA04hsLeZel2zfwcLUaj90D4wEE7MLzgt1KX4iND0wEAQaspeo
x+8apP/dBVxeNaVmUohzmc7hvustAvDqTNzwcFpjOE4i73Y0zp/0la8bXfdg1Csv
P1F3Vp+8kQHUQO5pgtY/Jdyd3rckF4rRewglvJS50Z6q6SdtfCtG8k7XL2NEvpry
st23C0IO2p/Fd59/tuUMiXXgDF9nYc/3ngF5PP/bBkjvLmn6fA7ow2MOrCGGUFPZ
UW6Us8PZs8kiJYWwZ2/Goe1wIfIxtRyKbGjt3HPEc8eVBjCRQkw1akJZkKEwbgJh
Z3JgN24yJffMySH8B3dq2Bizy8rKfncmQlt9p4VztGQKByILqks=
=hjJB
-----END PGP SIGNATURE-----

Viktor Ransmayr

unread,

Jun 14, 2022, 11:34:51 PM6/14/22

to qubes-users

Hello Demi,

This turns into a never ending story ;-)

Demi Marie Obenour schrieb am Dienstag, 14. Juni 2022 um 20:41:32 UTC+2:

> >> > You were right - but - I have no clue what went wrong & what to do next
> >> ...
> >>
> >> $ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo
> >>
> >> should fix that
> >>
> >
> > Upgrade of template is still running ...
> >
> > I'll provide another update as soon as it's finished.
> >
>
> It is still running, after more than 10 hours. - This should have finished
> by now, correct?

Yes, unless you have a very slow network connection. I recommend using
dnf interactively for this, not Salt; Salt’s lack of progress feedback
will make this extremely frustrating.

I performed the operation you suggested, but it did not succeed either ...

Here's the log from dnf:

[user@fedora-34 ~]$
[user@fedora-34 ~]$ sudo dnf -y --refresh upgrade
Fedora 34 - x86_64 78 kB/s | 21 kB 00:00
Fedora 34 openh264 (From Cisco) - x86_64 1.0 kB/s | 989 B 00:00
Fedora 34 - x86_64 - Updates 93 kB/s | 20 kB 00:00
Qubes OS Repository for VM (updates) 13 kB/s | 3.8 kB 00:00
Dependencies resolved.

Problem 1: package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed
- package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed
- cannot install both xen-libs-4.14.1-7.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64
- cannot install both xen-libs-4.14.5-1.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64
- cannot install the best update candidate for package qubes-libvchan-xen-4.0.9-1.fc34.x86_64
- problem with installed package xen-libs-2001:4.8.5-39.fc34.x86_64
Problem 2: package qubes-vm-dependencies-4.1.21-1.fc34.noarch requires xen-runtime, but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenguest.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxendevicemodel.so.1()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenlight.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxentoolcore.so.1()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxlutil.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenfsimage.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenhypfs.so.1()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenstat.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxencall.so.1(VERS_1.2)(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenfsimage.so.4.14(libfsimage.so.1.0)(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxengnttab.so.1(VERS_1.2)(64bit), but none of the providers can be installed
- package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenhypfs.so.1(VERS_1.0)(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenguest.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxendevicemodel.so.1()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenlight.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxentoolcore.so.1()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxlutil.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenfsimage.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenhypfs.so.1()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenstat.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxencall.so.1(VERS_1.2)(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenfsimage.so.4.14(libfsimage.so.1.0)(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxengnttab.so.1(VERS_1.2)(64bit), but none of the providers can be installed
- package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenhypfs.so.1(VERS_1.0)(64bit), but none of the providers can be installed
- cannot install both xen-libs-4.14.1-7.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64
- cannot install both xen-libs-4.14.5-1.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64
- cannot install the best update candidate for package xen-libs-2001:4.8.5-39.fc34.x86_64
- cannot install the best update candidate for package qubes-vm-dependencies-4.0.12-1.fc34.noarch
================================================================================
Package Arch Version Repository Size
================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
xen-libs x86_64 4.14.1-7.fc34 fedora 631 k
xen-libs x86_64 4.14.5-1.fc34 updates 619 k
Skipping packages with broken dependencies:
qubes-libvchan-xen x86_64 4.1.7-1.fc34 qubes-vm-r4.1-current 16 k
qubes-vm-dependencies noarch 4.1.21-1.fc34 qubes-vm-r4.1-current 12 k
xen-runtime x86_64 4.14.1-7.fc34 fedora 9.1 M
xen-runtime x86_64 4.14.5-1.fc34 updates 9.1 M

Transaction Summary
================================================================================
Skip 6 Packages

Nothing to do.
Complete!
[user@fedora-34 ~]$

Should I retry the cmd as follows - or - is this to risky?

[user@fedora-34 ~]$ sudo dnf -y --refresh --best --allowerasing upgrade

With kind regards,

Viktor

Demi Marie Obenour

unread,

Jun 15, 2022, 12:57:07 PM6/15/22

to Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Don’t use -y, that way you can check what is going to happen before it
does. Also you might want to clone the VM first; feel free to delete
the clone once everything is working.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKqD1sACgkQsoi1X/+c
IsH0xw/+P7PjA2M9goUEwi7nPE9Q5YRqBDJi+DPphApFpzqN0PfuyV/1CcEkDK/1
RtHM1KSW5ll/u0FIIfjvSta2AlltGXd3hooJ73W0KIUw+JyRQu7cNnIOxpZMuelE
uimdWYRQNmeqYIaVLICS/Xzl0eG9nMnnnePhagmGmcIkSz0h7ATT9XMAeVzXshBB
N1HIRCHJVXoCRsifo8QIjuFryYaaAElbF1czs//eqgt++Iy8FWPHiaonMj1fZpyz
vH8Hebxklk7fPkf1JIjuYPYMB6RJQh6QVBksFe7RVpec40vtYpcR6pp4XJ4XW7kF
gojZlcc+180Pq7sDIisEdGkvYwzozcYtJFcV253Q9iBauQhf4n6ackOh3Ot0Xct0
5RssYNyI6zJ9gJ3SSGnqw08SBHRXcfVZiz1X7hOBcUt86R00eQcL4Ck2+1o3k2XM
GL/aMKfV1mIIyEm1ISwkIgljnzsJ+1O5k1Nkd6JsGrB7dfi/92TRi9CeQ5ka9Bc7
5kjZycfbY5m9rwWe3tweAazhgIHbqg9RTktFI2e/UIoEvRS6WjJ1iYDoKCAOqcGw
2cZ0xYG9JaCYdJhz9cgisPdrY69GuIk47V706YWHEnyLiyWz49qHrozz4V+diILm
SgOT8ciO+19W1G/OJPgq4eQv33A9T6OAuO7MAgeVq7Yd8inQeLk=
=H6pN
-----END PGP SIGNATURE-----

Viktor Ransmayr

unread,

Jun 16, 2022, 1:34:42 AM6/16/22

to qubes-users

Hello Demi,

The never ending story - episode 2 ;-)

Demi Marie Obenour schrieb am Mittwoch, 15. Juni 2022 um 18:57:07 UTC+2:

Don’t use -y, that way you can check what is going to happen before it
does. Also you might want to clone the VM first; feel free to delete
the clone once everything is working.

I cloned the template - and - revised the cmd until no further improvement suggestions were given.

Unfortunately w/o success. - Below you find again my notes & logs:

### Notes

Clone 'fedora-34' template - and - apply the revised dnf command - Not OK - See "Log-001".

* Re-try command with the new additional option suggested - Not OK - See "Log-002".

### Log-001

[user@fedora-34-test ~]$
[user@fedora-34-test ~]$ sudo dnf --refresh --best --allowerasing upgrade
Fedora 34 - x86_64 63 kB/s | 21 kB 00:00
Fedora 34 openh264 (From Cisco) - x86_64 959 B/s | 989 B 00:01
Fedora 34 - x86_64 - Updates 80 kB/s | 19 kB 00:00
Qubes OS Repository for VM (updates) 16 kB/s | 3.8 kB 00:00
Error:
Problem: cannot install the best update candidate for package qubes-gui-agent-4.1.25-1.fc34.x86_64
- problem with installed package qubes-gui-agent-4.1.25-1.fc34.x86_64

- cannot install the best update candidate for package qubes-libvchan-xen-4.0.9-1.fc34.x86_64

- package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libvchan-xen.so()(64bit), but none of the providers can be installed
- package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires qubes-libvchan, but none of the providers can be installed
- package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed

- package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed
- cannot install both xen-libs-4.14.1-7.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64
- cannot install both xen-libs-4.14.5-1.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64

- package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libxengnttab.so.1()(64bit), but none of the providers can be installed
- package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libxengnttab.so.1(VERS_1.0)(64bit), but none of the providers can be installed

- cannot install the best update candidate for package xen-libs-2001:4.8.5-39.fc34.x86_64

(try to add '--skip-broken' to skip uninstallable packages)
[user@fedora-34-test ~]$

### Log-002

[user@fedora-34-test ~]$
[user@fedora-34-test ~]$ sudo dnf --refresh --best --allowerasing --skip-broken upgrade
Fedora 34 - x86_64 75 kB/s | 21 kB 00:00
Fedora 34 openh264 (From Cisco) - x86_64 3.9 kB/s | 989 B 00:00
Fedora 34 - x86_64 - Updates 82 kB/s | 19 kB 00:00
Qubes OS Repository for VM (updates) 15 kB/s | 3.8 kB 00:00
Error:
Problem: cannot install the best update candidate for package qubes-gui-agent-4.1.25-1.fc34.x86_64
- problem with installed package qubes-gui-agent-4.1.25-1.fc34.x86_64

- cannot install the best update candidate for package qubes-libvchan-xen-4.0.9-1.fc34.x86_64

- package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libvchan-xen.so()(64bit), but none of the providers can be installed
- package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires qubes-libvchan, but none of the providers can be installed
- package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed

- package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed
- cannot install both xen-libs-4.14.1-7.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64
- cannot install both xen-libs-4.14.5-1.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64

- package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libxengnttab.so.1()(64bit), but none of the providers can be installed
- package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libxengnttab.so.1(VERS_1.0)(64bit), but none of the providers can be installed

- cannot install the best update candidate for package xen-libs-2001:4.8.5-39.fc34.x86_64

[user@fedora-34-test ~]$

###

It looks like I'm running out of options - and - I an now considering a new installation from scratch as my only way going forward!

Or do you still have any other suggestion?

With kind regards,

Viktor

Viktor Ransmayr

unread,

Jun 16, 2022, 2:43:33 AM6/16/22

to qubes-users

Hello Demi,

The never ending story took an unexpected turn ...

Viktor Ransmayr schrieb am Donnerstag, 16. Juni 2022 um 07:34:42 UTC+2:

It looks like I'm running out of options - and - I an now considering a new installation from scratch as my only way going forward!

Or do you still have any other suggestion?

For whatever reason I re-tried to install the 'fedora-35' template - and - succeeded.

Based on the 'naming' ( * :4.0.6-202205081759) I initially thought that the repos were again pointing to R4.0 - but - they are pointing to R4.1 :-)

See "Log-001" & "Log-002".

### Log-001 from 'dom0'

[vr@dom0 ~]$
[vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35
Redirecting to 'qvm-template install fedora-35'

Downloading 'qubes-template-fedora-35-0:4.0.6-202205081759'...
qubes-template-fedora-35-0:4.0.6-202205081759: 100%|▉| 1.75G/1.75G [06:25<00:00,
Installing template 'fedora-35'...
fedora-35: Importing data
[vr@dom0 ~]$

### Log-002 from 'fedora-35' template

[user@fedora-35 ~]$
[user@fedora-35 ~]$ cd /etc/yum.repos.d
[user@fedora-35 yum.repos.d]$
[user@fedora-35 yum.repos.d]$
[user@fedora-35 yum.repos.d]$ cat qubes-r4.repo

[qubes-vm-r4.1-current]
name = Qubes OS Repository for VM (updates)
baseurl = https://yum.qubes-os.org/r4.1/current/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current/vm/fc$releasever
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1

repo_gpgcheck = 1

enabled=1

[qubes-vm-r4.1-current-testing]
name = Qubes OS Repository for VM (updates-testing)
baseurl = https://yum.qubes-os.org/r4.1/current-testing/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current-testing/vm/fc$releasever
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1

repo_gpgcheck = 1

enabled=0

[qubes-vm-r4.1-security-testing]
name = Qubes OS Repository for VM (security-testing)
baseurl = https://yum.qubes-os.org/r4.1/security-testing/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/security-testing/vm/fc$releasever
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary
skip_if_unavailable=False
gpgcheck = 1

repo_gpgcheck = 1

enabled=0

[qubes-vm-r4.1-unstable]
name = Qubes OS Repository for VM (unstable)
baseurl = https://yum.qubes-os.org/r4.1/unstable/vm/fc$releasever
#baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/unstable/vm/fc$releasever
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable
gpgcheck = 1

repo_gpgcheck = 1
enabled=0

[user@fedora-35 yum.repos.d]$

###

With kind regards,

Viktor

Demi Marie Obenour

unread,

Jun 16, 2022, 4:10:03 AM6/16/22

to Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I think I see what is happening. DNF thinks that
xen-libs-2001:4.8.5-39.fc34.x86_64 is *better* than
xen-libs-4.14.5-1.fc34.x86_64, but it is actually *worse*. So it gets
confused. I suggest trying “dnf install --allowerasing” with an
explicit list of packages (including version numbers, but no --best).
If that fails, “dnf shell” is the ultimate sledgehammer: it allows
performing arbitrary installs and removes in a single transaction, so
you can use it to override DNF’s dependency solver.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKq5VMACgkQsoi1X/+c
IsHL1RAAvywr/lixMEVhGZSlP3h8GxTNXgjc1LPD9rmX03tavbVEvvoMiTyZ5TvI
2sD4XYeTSn74T0lUfxMJ1uhLpdv1Zb9R0AG2Y6XOZJOZLPyK/3JgblsjmXnlbCef
56y6YZ2f4GE8JScqa7zADwic96u33CaF8ySlD5bwzEza88oQlS94hnNiafa+bKwf
13DT62FpgvnRv1msgw82LuM/RVQzvbqR/QIk+ACG8tsuR8xmM2N83PcjIEJOjsmf
kAUzo4lkIYehBCj/VkjzV+82IPIexbcW50hFHS0+mBHW95uhGxFTM1s9XlpkVFwH
DpO4VqPrkFVEV9QGbd+thlE3me6aSL8GSMQHaOrsTyuao6aORDTr1hS1y07DSDXe
2r292iOWZ4C7KDFhM6ehFuyN07+eAdnJl9nU220BUSLg7dI9G8TaSZ7UEBpoI0CW
XaGvC/dvu843O6jax8mRpfXPYLruDQdweQFcrMpw7/ROAVJTBPVvqZOZjZ9IDWr9
L/lMGUZkBQr0s9R6b72FFjs95cvNPf08wWvKxskTqRT4G+NtrWse9UJmrleneLIe
u+Vb1qDnrdHQJbvgxsI3QDfMWmyEkfY3zbIBr2Yl3qaKY2cjRx34HMGHrTy6gD+y
8WTIVptZ+eOXWBABjwqYyxiiFmLMIE0U45D+pMHWd9UJcQxx7a0=
=PAcp
-----END PGP SIGNATURE-----

Demi Marie Obenour

unread,

Jun 16, 2022, 4:11:32 AM6/16/22

to Viktor Ransmayr, qubes-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Congratulations! I guess you can disregard my last email. Be sure to
update your new template :)

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKq5awACgkQsoi1X/+c
IsEBehAA2X7lWNyKq9mpHUzM6oM8QSl4cg/tTTO+S6Up7HuvmsmmZWwGPpnKkor/
OnQFxZwFo3CGTPvXH/KA1qkgiSHssvIbcRx+iQxI4a5ukHgpxHotUZlAbSn0Iv2R
d86I54vG2JDXrdEMid3WljnwLP5P90IXZ/tIRiqKJaqf4ZkT93bbr92ybZH3QqTv
83xIknqcOqj/P/u7TugRtlOEF8PeEf+44RH+49W+9VllUphfLknvrM+1rmv+yJ6q
1rhjjU3H2FJZeXvnwMujXxFRB303BZXsfYdaO5zfQTEs4IWZ8DMdALyn1Dad/t5B
Rv0mBPct7FNY4vCDMuRlo5pxN+98Q5ROGZF/NnEb9XSNWE4oGfCYykS8Iorvc1Iz
NO6t9uB4esH9t0MYRnhYv4/ngrbPR4IbG4VXLSdpDVje+wV53FG8hpGjuhkwx5ll
xlhr8VQOAzlObwYUUHiv4Zl//dPMecFyeZ2FNLhJCETpf0gO/95/uezvz6FZTsA/
KU/kM7WCi4tXXnCufCaect7VKD2XoDIOrNe5k7DyKorfqoPOzB4BGGAA/JhZTOxN
CbNXMEKx6+aqr5epjsI+0GI60q6+G0EdCyHCnxSjd6l6H0R5wYex75iNHy3FglCF
SeNZjcQviKCBxFHWy9wBwALkpdcm+wLWK0k1eQA+WFeW7OhIKvk=
=s4Nh
-----END PGP SIGNATURE-----

Viktor Ransmayr

unread,

Jun 16, 2022, 1:12:11 PM6/16/22

to Viktor Ransmayr, qubes-users

Hello Demi,

Am Do., 16. Juni 2022 um 10:11 Uhr schrieb Demi Marie Obenour <de...@invisiblethingslab.com>:

Congratulations! I guess you can disregard my last email. Be sure to
update your new template :)

Yes, I'm in the middle of consolidating all my App- & Template-VMs.

Thanks a lot for your great support!

With kind regards,

Viktor

Reply all

Reply to author

Forward