Re: [qubes-users] Problems with announced Fedora 35 templates
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 -- 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/6cc83641-b7e3-4da0-8194-bb90ee06162cn%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
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_64959 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_643.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 -- 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 we
Re: [qubes-users] appvm crashing whole computer?
On 6/15/22 10:47, Andrew David Wong wrote: On 6/15/22 3:35 AM, Stumpy wrote: My computer started freezing up recently and I had origonally thought (as it is pretty old) that it was dying. I then realized that it *seems* to be an appvm, or something within this appvm that is crashing the computer as, so far, the computer has not crashed if i dont have the appvm open. My question(s) are, I thought appvms or apps in them where "contained" so couldnt crash a whole system? and, are there some logs that can help figure out what is happening? Thanks! It is possible that running a resource-intensive process inside of an app qube could cause an old or poorly-ventilated computer to crash. (For example, it's common for dust to accumulate on CPU heat sinks after years of operation, causing thermal limits to be reached even under normal workloads.) If this is the case, everything could still be properly "contained" from a security perspective and nothing malicious need be afoot. It could just be that the underlying hardware is failing under load, which often manifests as spontaneous hard reboots. This is just one possibility to consider. Thanks. If a cpu intensive task can do that then that might be the problem. My setup is old, but i keep it pretty clean so dust/overheating seems less likely. It is my "multimedia" appvm that I have sshfs'd to a network drive playing music on a win app via wine, which doesnt seem super intensive but xentop tells me otherwise. The thing is, I have had this setup for years and it hasnt been a problem until now? -- 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/b5b60874-8e53-1b0d-c4c2-04ef40b6dc26%40posteo.co.
Re: [qubes-users] Problems with announced Fedora 35 templates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jun 14, 2022 at 08:34:51PM -0700, Viktor Ransmayr wrote: > 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_641.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-runt
Re: [qubes-users] appvm crashing whole computer?
On 6/15/22 3:35 AM, Stumpy wrote: My computer started freezing up recently and I had origonally thought (as it is pretty old) that it was dying. I then realized that it *seems* to be an appvm, or something within this appvm that is crashing the computer as, so far, the computer has not crashed if i dont have the appvm open. My question(s) are, I thought appvms or apps in them where "contained" so couldnt crash a whole system? and, are there some logs that can help figure out what is happening? Thanks! It is possible that running a resource-intensive process inside of an app qube could cause an old or poorly-ventilated computer to crash. (For example, it's common for dust to accumulate on CPU heat sinks after years of operation, causing thermal limits to be reached even under normal workloads.) If this is the case, everything could still be properly "contained" from a security perspective and nothing malicious need be afoot. It could just be that the underlying hardware is failing under load, which often manifests as spontaneous hard reboots. This is just one possibility to consider. -- 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/1cc98f96-696d-98bd-03a5-65fe7e2d269b%40qubes-os.org.
[qubes-users] appvm crashing whole computer?
My computer started freezing up recently and I had origonally thought (as it is pretty old) that it was dying. I then realized that it *seems* to be an appvm, or something within this appvm that is crashing the computer as, so far, the computer has not crashed if i dont have the appvm open. My question(s) are, I thought appvms or apps in them where "contained" so couldnt crash a whole system? and, are there some logs that can help figure out what is happening? Thanks! -- 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/402460f0-556b-88b9-9308-27d4066a9e14%40posteo.co.
