--
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.
--
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.
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.
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 ...
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.Which explains itself.
> >> 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.
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 ?
> 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.
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.
What is the contents of /etc/yum.repos.d in your fedora-34 template?
You might have repositories pointing at the R4.0 repos.
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:
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.
> 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
> >> > 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.
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.
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?
Congratulations! I guess you can disregard my last email. Be sure to
update your new template :)