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 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
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.
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 ~]$
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.
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
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’ …
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.
>
>>>
>>>>
>>>>>
>>>>> 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 ...
>>
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
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’ …
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:
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 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!
> > > 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.
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?
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
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.
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
