[qubes-users] Watching Netflix on QubesOS with a Windows AppVM
Hey, i'm looking to install QubesOS on a laptop. But I have a question: Does downloading and watching Netflix with the Windows UWP app work? What about latency and lags. What should be the perfect performance. Many threads says that I can use Chrome, but I also want to download movies, and this only works with the UWP app from the Microsoft Store. Thanks for your answers! fossdd -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CEWKO41080LD.1CMH382588MWI%40main.
[qubes-users] Qubes OS 4.1-rc1 has been released!
Dear Qubes Community, After many years of work, the team is pleased to announce the first release candidate for Qubes 4.1! Qubes 4.1 includes several major new features, each of which is explained in depth in its own article: - Qubes Architecture Next Steps: The GUI Domain [01] - Qubes Architecture Next Steps: The New Qrexec Policy System [02] - New Gentoo templates and maintenance infrastructure [03] - Reproducible builds for Debian: a big step forward [04] This release candidate also includes numerous other improvements and bug fixes, which are listed in the release notes [05] and in the issue tracker [06]. Finally, Qubes 4.1 features the following updated default components: - Xen 4.14 - Fedora 32 in dom0 - Fedora 34 template - Debian 11 template - Whonix 16 Gateway and Workstation templates - Linux kernel 5.10 Qubes 4.1-rc1 is available on the downloads [07] page. How to test Qubes 4.1-rc1 - If you're willing to test [08] this release candidate, you can help to improve the stable release by reporting any bugs you encounter [09]. Experienced users are strongly encouraged to join the testing team [10]! There are two ways to migrate to 4.1-rc1: - Back up [11] your current installation, perform a fresh install [12] of 4.1-rc1, then restore [13] from your backup. - Perform an in-place upgrade [14]. Release candidate planning -- As with any initial release candidate, it's likely that user testing will reveal important bugs that we'll want to fix before the stable release. Depending on the severity of the bugs discovered and how long it takes to fix them, we expect that it may be anywhere from a few weeks to a few months before we announce the second release candidate. [01] https://www.qubes-os.org/news/2020/03/18/gui-domain/ [02] https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/ [03] https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/ [04] https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/ [05] https://www.qubes-os.org/doc/releases/4.1/release-notes/ [06] https://github.com/QubesOS/qubes-issues/issues?q=milestone%3A%22Release+4.1%22+is%3Aclosed+-label%3A%22R%3A+duplicate%22+-label%3A%22R%3A+invalid%22+-label%3A%22R%3A+cannot+reproduce%22+-label%3A%22R%3A+not+an+issue%22+-label%3A%22R%3A+not+our+bug%22+-label%3A%22R%3A+won%27t+do%22+-label%3A%22R%3A+won%27t+fix%22+ [07] https://www.qubes-os.org/downloads/ [08] https://www.qubes-os.org/doc/testing/ [09] https://www.qubes-os.org/doc/issue-tracking/ [10] https://forum.qubes-os.org/t/joining-the-testing-team/5190 [11] https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#creating-a-backup [12] https://www.qubes-os.org/doc/installation-guide/ [13] https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup [14] https://www.qubes-os.org/doc/upgrade/4.1/ This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2021/10/11/qubes-4-1-rc1/ -- Andrew David Wong Community Manager The Qubes OS Project https://www.qubes-os.org -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1e90d5b4-a09a-db3f-92f7-3409c7701e8f%40qubes-os.org. OpenPGP_signature Description: OpenPGP digital signature
[qubes-users] [Berlin] monthly Qubes Users Berlin meeting - Tuesday October 12 @ 7pm
hi folks, for those in Berlin you are invited to the monthly Qubes Users Berlin meeting! the next one will be tomorrow Tuesday October 12 at 19h at xHain. more details here: https://qubesusersberlin.github.io Hope to see you there! Michael -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/78691168-3e07-1874-5aa2-c1f54015a627%40qubes-os.org. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-users] Systemd terminating qubesd during backup?
On 10/11/21 14:07, Rusty Bird wrote: Steve Coleman: > I seem to have an intermittent problem when my backup scripts are running > late at night. > My qubesd is apparently being shutdown (sent a sigterm signal) by systemd > during my long running backup sessions which then causes an eof pipe close > exception and qvm-backup then receives a socket exception and immediately > receives a second exception while still handling the first exception, thus > the qvm-backup process gets forcibly terminated mid stream. Just prior to > the qubesd shutdown I can clearly see that systemd had also > shutdown/restarted the qubes memory manager (qubes-qmemman) too. > Q: What kind of background maintenance processing would actually require > qubesd or the memory manager to be restarted? It's crond running logrotate. Fixed in R4.1 but not yet in R4.0: https://github.com/QubesOS/qubes-issues/issues/5004 > Q: Could this processing be put on hold during backups? I always sandwich backup runs between 'systemctl stop crond' and 'systemctl start crond'. Great! I was hoping for an answer like that. In my case the system will be shutting down after the unattended backup completes, so this is actually twice as easy! thanks! Rusty > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d1528316-5e0e-9052-2f43-952c91559fcb%40gmail.com.
Re: [qubes-users] Unable to install templates in Qubes OS 4.1beta
Hello Steve, thanks for the reply, can you provide more details what you mean by that: On Mon, 11 Oct 2021 at 18:12, Steve Coleman wrote: > [...] In any case you might try cleaning the cache with the --clean option > and > then rerunning the download/install. > do you mean 'sudo dnf clean all' in dom0 ? one7two99 > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/6a480f40-df36-42bc-d0c5-26bfa9c19176%40gmail.com > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2t6oyQsO%3DSLtRdyzyNKThmukcsXGQiWuhYgoXPmBGd%2BJA%40mail.gmail.com.
Re: [qubes-users] Systemd terminating qubesd during backup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Steve Coleman: > I seem to have an intermittent problem when my backup scripts are running > late at night. > > My qubesd is apparently being shutdown (sent a sigterm signal) by systemd > during my long running backup sessions which then causes an eof pipe close > exception and qvm-backup then receives a socket exception and immediately > receives a second exception while still handling the first exception, thus > the qvm-backup process gets forcibly terminated mid stream. Just prior to > the qubesd shutdown I can clearly see that systemd had also > shutdown/restarted the qubes memory manager (qubes-qmemman) too. > > Q: What kind of background maintenance processing would actually require > qubesd or the memory manager to be restarted? It's crond running logrotate. Fixed in R4.1 but not yet in R4.0: https://github.com/QubesOS/qubes-issues/issues/5004 > Q: Could this processing be put on hold during backups? I always sandwich backup runs between 'systemctl stop crond' and 'systemctl start crond'. Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmFkfVZfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt/dHQ/+LXkv+7GT64IgMXpwQjKMuDMswRPsEvXpGihJYohSioeGm6HvUNQ1uh99 zwih5PqT1OnJrIfgzRvqLPfTbTpO3YrkQZi32TY848M14rg1A5NtTHIzOthJP2+x puZy7hMcFvZR4awv3g/4WVLRsMrUVuQ5x3n/xzId5MAycWrsQtt8bRH+kc3VHgMn Jul0TPzD1jnmN36Ngpgr5UGe4LrNfR4IcRaG5mzoI/4tIA4mtkcmm1AwqBnR3KrQ 0Gclbk/F5ud/Nj4EwIQDFWnrBa70Hru7HZ+wj7V7shJD2fMuQVsBcys8EVJjpGQp qFzy6AfvdIHJ1BmtoJM+v8cqo2AU+kVdRx0n2cTXCkHM5eN1nCpc6EO81HoB6ypE 8773aw8l/Y5fCowT0p/y4c8jTUd3/YiNFpJSPiRfLJDAk4PunnynM9IPVY+GnJUX 6HB8tXDn6vx5Gq90f0UjNkcWonJ/bt5GMYGpWBtHGQyQ0dh+mxhmwnT5hYnfNMW+ +pAcBB4fRclebEroW1RcLqe7FVZ1dldNqZQIL6WlQgU8/I06/JNNZkhjmlpdBDX5 FwNGFw7b2ss+4A+LdC6Q4IJ1S2LyOeIQtCCX3UIffhcvOEMmJSxkHBb65e1kGAxe 5Lsfcjmq6rK1jCYMC5or177Mo9u+PPxWxvr5p4zocBu7VyUUCdM= =zaUv -END PGP SIGNATURE- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YWR9VrcVsYS/1FC8%40mutt.
[qubes-users] Systemd terminating qubesd during backup?
I seem to have an intermittent problem when my backup scripts are running late at night. My qubesd is apparently being shutdown (sent a sigterm signal) by systemd during my long running backup sessions which then causes an eof pipe close exception and qvm-backup then receives a socket exception and immediately receives a second exception while still handling the first exception, thus the qvm-backup process gets forcibly terminated mid stream. Just prior to the qubesd shutdown I can clearly see that systemd had also shutdown/restarted the qubes memory manager (qubes-qmemman) too. Q: What kind of background maintenance processing would actually require qubesd or the memory manager to be restarted? Q: Could this processing be put on hold during backups? Q: Or, how could I at least know when this maintenance is scheduled to happen so I could defer my own processing? My scripts can certainly trap this error, erase the incomplete backup file, then loop and check for qubesd to complete its restart, and then finally restart my own backup processing, but why should this even be necessary? When this happens its almost always during the backup of my largest VM which can take well over 90 minutes to complete. If I can somehow block/defer this kind of system maintenance until after my backups are complete that would be better than having to deal with trapping random restarts. thanks, Steve Sorry for the amount of text below but googlegroups would not let me send this as *.txt attachments: qvm-backup error: Making a backup... 56.28% Connection to qubesd terminated, reconnecting in 1.0 seconds Backup error: Got empty response from qubesd. See journalctl in dom0 for details. Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 580, in qubesd_call client_socket.connect(qubesadmin.config.QUBESD_SOCKET) FileNotFoundError: [Errno 2] No such file or directory During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/qvm-run", line 5, in sys.exit(main()) File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_run.py", line 199, in main args = parser.parse_args(args, app=app) File "/usr/lib/python3.5/site-packages/qubesadmin/tools/__init__.py", line 384, in parse_args action.parse_qubes_app(self, namespace) File "/usr/lib/python3.5/site-packages/qubesadmin/tools/__init__.py", line 170, in parse_qubes_app namespace.domains += [app.domains[vm_name]] File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 91, in __getitem__ if not self.app.blind_mode and item not in self: File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 114, in __contains__ self.refresh_cache() File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 63, in refresh_cache 'admin.vm.List' File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 583, in qubesd_call 'Failed to connect to qubesd service: %s', str(e)) qubesadmin.exc.QubesDaemonCommunicationError: Failed to connect to qubesd service: [Errno 2] No such file or directory journalctl output: Oct 11 03:15:02 dom0 systemd[1]: Stopping Qubes memory management daemon... Oct 11 03:15:02 dom0 systemd[1]: Stopped Qubes memory management daemon. Oct 11 03:15:02 dom0 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 11 03:15:02 dom0 kernel: audit: type=1131 audit(1633936502.556:250): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 11 03:15:02 dom0 systemd[1]: Starting Qubes memory management daemon... Oct 11 03:15:07 dom0 qmemman.daemon[18836]: MIN_PREFMEM=199229440 DOM0_MEM_BOOST=349175808 CACHE_FACTOR=1.3 Oct 11 03:15:07 dom0 systemd[1]: Started Qubes memory management daemon. Oct 11 03:15:07 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 11 03:15:07 dom0 kernel: audit: type=1130 audit(1633936507.784:251): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 11 03:15:07 dom0 qmemman.daemon.algo[18836]: balance_when_enough_memory(xen_free_memory=53353416961, total_mem_pref=0, total_available_memory=53353416961) Oct 11 03:15:07 dom0 qmemman.systemstate[18836]: stat: xenfree=53405845761 memset_reqs=[] Oct 11 03:15:07 dom0 qmemman.daemon.algo[18836]: balance_when_enough_memory(xen_free_memory=53353416961, total_mem_pref=0, total_available_memory=53353416961) Oct 11 03:15:07 dom0 qmemman.systemstate[18836]: stat: xenfree=53405845761 memset_reqs=[] Oct 11
Re: [qubes-users] Unable to install templates in Qubes OS 4.1beta
On 10/11/21 15:55, 799 wrote: ... but if I try install via: [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-33 ... I can see that it will download the package but I get: Using sys-net as UpdateVM to download updates for Dom0; this may take some time... Last metadata expiration check: -1 day, 21:47:12 ago on Mon 11 Oct 2021 05:49:33 PM CEST. No match for argument: qubes-template-fedora-33 Error: Unable to find a match: qubes-template-fedora-33 Any idea where I can look for the root cause as I am a bit desparate. Just a guess here. Is it possible that sys-net is running out of disk space from the download and has the matching problem because it wasn't physically downloaded? In any case you might try cleaning the cache with the --clean option and then rerunning the download/install. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6a480f40-df36-42bc-d0c5-26bfa9c19176%40gmail.com.
[qubes-users] Systemd terminating qubesd during backup?
I seem to have an intermittent problem when my backup scripts are running late at night. My qubesd is apparently being shutdown (sent a sigterm signal) by systemd during my long running backup sessions which then causes an eof pipe close exception and qvm-backup then receives a socket exception and immediately receives a second exception while still handling the first exception, thus the qvm-backup process gets forcibly terminated mid stream. Just prior to the qubesd shutdown I can clearly see that systemd had also shutdown/restarted the qubes memory manager (qubes-qmemman) too. Q: What kind of background maintenance processing would actually require qubesd or the memory manager to be restarted? Q: Could this processing be put on hold during backups? Q: Or, how could I at least know when this maintenance is scheduled to happen so I could defer my own processing? My scripts can certainly trap this error, erase the incomplete backup file, then loop and check for qubesd to complete its restart, and then finally restart my own backup processing, but why should this even be necessary? When this happens its almost always during the backup of my largest VM which can take well over 90 minutes to complete. If I can somehow block/defer this kind of system maintenance until after my backups are complete that would be better than having to deal with trapping random restarts. thanks, Steve -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4fb6c085-4491-c67a-a940-98cca1f89c7c%40gmail.com. Making a backup... 56.28% Connection to qubesd terminated, reconnecting in 1.0 seconds Backup error: Got empty response from qubesd. See journalctl in dom0 for details. Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 580, in qubesd_call client_socket.connect(qubesadmin.config.QUBESD_SOCKET) FileNotFoundError: [Errno 2] No such file or directory During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/qvm-run", line 5, in sys.exit(main()) File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_run.py", line 199, in main args = parser.parse_args(args, app=app) File "/usr/lib/python3.5/site-packages/qubesadmin/tools/__init__.py", line 384, in parse_args action.parse_qubes_app(self, namespace) File "/usr/lib/python3.5/site-packages/qubesadmin/tools/__init__.py", line 170, in parse_qubes_app namespace.domains += [app.domains[vm_name]] File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 91, in __getitem__ if not self.app.blind_mode and item not in self: File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 114, in __contains__ self.refresh_cache() File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 63, in refresh_cache 'admin.vm.List' File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 583, in qubesd_call 'Failed to connect to qubesd service: %s', str(e)) qubesadmin.exc.QubesDaemonCommunicationError: Failed to connect to qubesd service: [Errno 2] No such file or directory Oct 11 03:15:02 dom0 systemd[1]: Stopping Qubes memory management daemon... Oct 11 03:15:02 dom0 systemd[1]: Stopped Qubes memory management daemon. Oct 11 03:15:02 dom0 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 11 03:15:02 dom0 kernel: audit: type=1131 audit(1633936502.556:250): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 11 03:15:02 dom0 systemd[1]: Starting Qubes memory management daemon... Oct 11 03:15:07 dom0 qmemman.daemon[18836]: MIN_PREFMEM=199229440 DOM0_MEM_BOOST=349175808 CACHE_FACTOR=1.3 Oct 11 03:15:07 dom0 systemd[1]: Started Qubes memory management daemon. Oct 11 03:15:07 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 11 03:15:07 dom0 kernel: audit: type=1130 audit(1633936507.784:251): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-qmemman comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 11 03:15:07 dom0 qmemman.daemon.algo[18836]: balance_when_enough_memory(xen_free_memory=53353416961, total_mem_pref=0, total_available_memory=53353416961) Oct 11 03:15:07 dom0 qmemman.systemstate[18836]: stat: xenfree=53405845761 memset_reqs=[] Oct 11 03:15:07 dom0 qmemman.daemon.algo[18836]:
Re: [qubes-users] Unable to install templates in Qubes OS 4.1beta
On Mon, Oct 11, 2021 at 09:55:47PM +0200, 799 wrote: > Hello, > > I have setup Qubes 4.1 on my Surface and now I am running into issues > trying to install more templates. > sys-net is set as Dom0 Update VM and I am also able to search for packages > and they get listed correctly. > > [user@dom0 ~]$ sudo qubes-dom0-update --action=search qubes-template- > Using sys-net as UpdateVM to download updates for Dom0; this may take some > time... > > Strangely the output (listed packages) is not shown in dom0 but in the > sys-net in a windows with sh as shell. > The first line says: Converting database from bdb_ro to sqlite backend > Then I get a list of the templates. > > ... but if I try install via: > [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-33 > > ... I can see that it will download the package but I get: > > Using sys-net as UpdateVM to download updates for Dom0; this may take some > time... > Last metadata expiration check: -1 day, 21:47:12 ago on Mon 11 Oct 2021 > 05:49:33 PM CEST. > No match for argument: qubes-template-fedora-33 > Error: Unable to find a match: qubes-template-fedora-33 > > Any idea where I can look for the root cause as I am a bit desparate. > > One7two99 > The output appearing in sys-net is a new security feature in 4.1. The "converting database" line is to be expected (but annoying on each run with a disposable) I'm not sure why you see "Unable to find a match". The obvious reason would be that you already have a fedora-33 template installed. What do you mean by - "I can see that it will download the package"? -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YWRRx6SFupkR6cIB%40thirdeyesecurity.org.
[qubes-users] Unable to install templates in Qubes OS 4.1beta
Hello, I have setup Qubes 4.1 on my Surface and now I am running into issues trying to install more templates. sys-net is set as Dom0 Update VM and I am also able to search for packages and they get listed correctly. [user@dom0 ~]$ sudo qubes-dom0-update --action=search qubes-template- Using sys-net as UpdateVM to download updates for Dom0; this may take some time... Strangely the output (listed packages) is not shown in dom0 but in the sys-net in a windows with sh as shell. The first line says: Converting database from bdb_ro to sqlite backend Then I get a list of the templates. ... but if I try install via: [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-33 ... I can see that it will download the package but I get: Using sys-net as UpdateVM to download updates for Dom0; this may take some time... Last metadata expiration check: -1 day, 21:47:12 ago on Mon 11 Oct 2021 05:49:33 PM CEST. No match for argument: qubes-template-fedora-33 Error: Unable to find a match: qubes-template-fedora-33 Any idea where I can look for the root cause as I am a bit desparate. One7two99 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2tfAavmsuzJJ6bz3JV_kDjdxsXwB6Lt3UGvFiVUE%2B849w%40mail.gmail.com.
