[qubes-users] How to check that an 'in-place upgrade' from Qubes R4.0 to R4.1 was successful?
Hello Qubes Community, I have reported problems installing the new Fedora 35 templates late last week [1] - and - also reported in the thread, that the 'in-place upgrade' of my system from 4.0 to 4.1 was only two weeks ago. One additional thing that I noticed today, is that a dom0 update does not install any new packages - but - for the second(?) time only deletes 14 (?) packages. Yesterday I was not able to collect the precise info from the Update VM, but today I succeeded. - Here's the output: [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... warning: Converting database from bdb_ro to sqlite backend 25 files removed Fedora 32 - x86_64 5.2 MB/s | 70 MB 00:13 Fedora 32 - x86_64 - Updates4.1 MB/s | 30 MB 00:07 Qubes Dom0 Repository (updates) 2.0 MB/s | 3.8 MB 00:01 Last metadata expiration check: 0:00:02 ago on Tue May 31 07:48:22 2022. Dependencies resolved. Package ArchVersion Repository Size Removing dependent packages: python2-backports_abc noarch 0.5-1.fc25 @System 30 k python2-futures noarch 3.1.1-1.fc25@System 91 k python2-lxmlx86_64 4.1.1-1.fc25@System 4.5 M python2-msgpack x86_64 0.4.8-1.fc25@System 276 k python2-nosenoarch 1.3.7-11.fc25 @System 1.1 M python2-pycurl x86_64 7.43.0-6.fc25 @System 891 k python2-pygpgme x86_64 0.3-18.fc25 @System 306 k python2-pysocks noarch 1.6.7-1.fc25@System 79 k python2-requestsnoarch 2.10.0-4.fc25 @System 369 k python2-singledispatch noarch 3.4.0.3-5.fc25 @System 46 k python2-systemd x86_64 234-5.1.fc25@System 263 k python2-tornado x86_64 4.4.2-1.fc25@System 3.9 M python2-urllib3 noarch 1.15.1-3.fc25 @System 443 k python2-zmq x86_64 15.3.0-2.fc25 @System 1.5 M Transaction Summary Remove 14 Packages Freed space: 14 M DNF will only download packages for the transaction. Complete! No packages downloaded No updates available [vr@dom0 ~]$ Now finally my question again: Is there a way to test that the upgrade from Qubes R4.0 to R4.1 was complete - and - successful? With kind regards, Viktor --- [1] https://groups.google.com/g/qubes-users/c/gpku3AoioLw -- 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/093a5516-564a-4757-b4ed-ebf9ef917ffdn%40googlegroups.com.
Re: [qubes-users] Force a flatpaked application to open attachments, links etc. in a dismVM?
On Sat, May 28, 2022 at 12:56:42PM +0200, Johannes Graumann wrote: > On Tue, 2022-05-24 at 12:35 -0400, Demi Marie Obenour wrote: > > On Tue, May 24, 2022 at 10:37:18AM +0200, Qubes OS Users Mailing List > > wrote: > > > https://www.qubes-os.org/doc/how-to-use-disposables/#making-a-particular-application-open-everything-in-a-disposable > > > states: > > > > To do this [make a particular application open everything in a > > > > disposable VM], enable a service named app-dispvm.X in that > > > > qube, > > > > where X is the application ID. > > > > > > and invokes `app-dispvm.thunderbird` as an example. > > > > > > How would you do that for an application installes and run through > > > flatpak? > > > > Flatpak-installed applications still have an application ID, which is > > what gets passed to qubes.StartApp to launch the application. > > Thank you for your answer. Lengthy googling has dug up no answer to > what an "application ID" actually is or how to look it up. Could you > please help with that? Given a running program, how do I identify it? It is the name of the .desktop file the application has within the VM. For Flatpak apps, I believe it will always be the ID of the flatpak (the reverse-DNS name). -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -- 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/YpUI0vyWFUt%2B6/o9%40itl-email. signature.asc Description: PGP signature
Re: [qubes-users] Problems with announced Fedora 35 templates
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 >> 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.PdfConvertqubes.SuspendPostAll qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre qubes.DetachPciDevicequbes.ResizeDiskqubes.SuspendPreAll qubes.Filecopy qubes.Restore qubes.USB qubes.GetAppmenusqubes.SaltLinuxVM qubes.USBAttach qubes.GetDatequbes.SelectDirectory qubes.USBDetach qubes.GetImageRGBA qubes.SelectFilequbes.UpdatesProxy qubes.Gpgqubes.SetDateTime qubes.VMRootShell qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell qubes.InstallUpdatesGUI qubes.ShowInTerminalqubes.WaitForSession qubes.OpenInVM qubes.StartApp qubes.OpenURLqubes.SuspendPost [user@sys-firewall qubes-rpc]$ With kind regards, Viktor -- 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/aa4bd9f5-8ec0-459a-8678-5ce12dc8f07an%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
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 > 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_644.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.noarch4.1.23-1.fc32 qubes-core-dom0.noarch4.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.noarch4.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.noarch4.1.12-1.fc32 qubes-mgmt-salt.noarch4.1.14-1.fc32 qubes-mgmt-salt-admin-tools.noarch4.1.14-1.fc32 qubes-mgmt-salt-base.noarch 4.1.4-1.fc32 qubes-mgmt-salt-base-config.noarch4.1.1-1.fc32 qubes-mgmt-salt-base-overrides-libs.noarch4.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.noarch4.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
