Re: [qubes-users] Qubes Manager not honoring colour scheme selection
This is quite easy to fix by installing qt5-qtsyleplugins in dom0 and exporting QT_QPA_PLATFORMTHEME=gtk2 in /etc/environment --> https://github.com/QubesOS/qubes-issues/issues/7389 -- 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/662b4662-24a6-ee5e-fefb-706634a3f6fd%40SvenSemmler.org.
[qubes-users] Qubes Manager not honoring colour scheme selection
I have gone back and checked my 4.0 installation and on there Qubes Manager definitely changes its colour scheme according to the "Style" selected in Qubes Menu -> System Tools -> Appearance I like to use "Adwaita-dark". This changes everything to the dark theme except Qubes Manager. This is definitely a 4.1 and 4.11 specific problem. Is it a configuration file that i can edit manually that will fix this annoyance? The bright Qubes Manager kills my eyes at knight. -- 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/18a71d23-4169-3eda-c764-6277349b8172%40ak47.co.za.
Re: [qubes-users] Re: dvm considerably slower on R4.1
It might be the speed in which to generate a new random number for this disposableVM and taking the file for a long time due to the size of that one file. On Thursday, July 21, 2022 at 2:13:37 PM UTC-7 Qubes wrote: > Howard Chen wrote: > > The problem lies within your computer processing speed and the numbers of > > qubes you has opened and active in one minute; This will significantly > > increases the opening time. As a result, it doubles the time of opening > and > > activating the qubes to be online. > > I didn't spell that out down to the letter but to make matters worse > when i tested the creation time of the dvm on 4.0 the system was in fact > far more busy compared to my test on 4.1. on 4.1 only the bare minimum > was booted, sys-net, sys-firewall, sys-usb, sys-whonix, and that is it. > On any regular day there are about 18 VMs running at any given time. So > definitely the measured time was not influenced by how busy, or lack of, > my system was. > > > On Thursday, July 21, 2022 at 2:02:12 PM UTC-7 Qubes wrote: > > > >> Howard Chen wrote: > >>> I have the similar as yours, but the time of one of my qubes cannot be > >> open > >>> because of light VM error that I got, which is error 135. The time > >> doubling > >>> effect is just to place for the computer took way too long on some > >>> occasional reasons to go for it. Anyways, it's just the distro issue > from > >>> Debian. > >> > >> How can it be a distro problem from Debian? Or Fedora? The same version > >> of either on either 4.0 or 4.1 should be the same. Or not? > >> > >>> On Thursday, July 21, 2022 at 1:53:56 PM UTC-7 Qubes wrote: > >>> > Has the 4.1 as well as 4.1.1, because I did test on both, release > added > additional overhead to the creation of a dvm? > > I have identical dvm's for Firefox on 4.0 and 4.1 and on 4.1 it takes > almost, in the region of 0.5 - 0.75 seconds almost, **double** the > time > for a new dvm to be ready for usage, 18 seconds vs 36 (both rounded > for > convenience). > > That is quite a hefty difference. Is there any explanation for this > behavior? > > >>> > >> > >> > > > > -- 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/aa7bd87c-8c49-4ef1-94c2-3e41dc05cfd4n%40googlegroups.com.
Re: [qubes-users] Re: dvm considerably slower on R4.1
Howard Chen wrote: The problem lies within your computer processing speed and the numbers of qubes you has opened and active in one minute; This will significantly increases the opening time. As a result, it doubles the time of opening and activating the qubes to be online. I didn't spell that out down to the letter but to make matters worse when i tested the creation time of the dvm on 4.0 the system was in fact far more busy compared to my test on 4.1. on 4.1 only the bare minimum was booted, sys-net, sys-firewall, sys-usb, sys-whonix, and that is it. On any regular day there are about 18 VMs running at any given time. So definitely the measured time was not influenced by how busy, or lack of, my system was. On Thursday, July 21, 2022 at 2:02:12 PM UTC-7 Qubes wrote: Howard Chen wrote: I have the similar as yours, but the time of one of my qubes cannot be open because of light VM error that I got, which is error 135. The time doubling effect is just to place for the computer took way too long on some occasional reasons to go for it. Anyways, it's just the distro issue from Debian. How can it be a distro problem from Debian? Or Fedora? The same version of either on either 4.0 or 4.1 should be the same. Or not? On Thursday, July 21, 2022 at 1:53:56 PM UTC-7 Qubes wrote: Has the 4.1 as well as 4.1.1, because I did test on both, release added additional overhead to the creation of a dvm? I have identical dvm's for Firefox on 4.0 and 4.1 and on 4.1 it takes almost, in the region of 0.5 - 0.75 seconds almost, **double** the time for a new dvm to be ready for usage, 18 seconds vs 36 (both rounded for convenience). That is quite a hefty difference. Is there any explanation for this behavior? -- 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/463b8fe0-d1fe-5a17-4b0c-2788edfb1454%40ak47.co.za.
Re: [qubes-users] Re: dvm considerably slower on R4.1
The problem lies within your computer processing speed and the numbers of qubes you has opened and active in one minute; This will significantly increases the opening time. As a result, it doubles the time of opening and activating the qubes to be online. On Thursday, July 21, 2022 at 2:02:12 PM UTC-7 Qubes wrote: > Howard Chen wrote: > > I have the similar as yours, but the time of one of my qubes cannot be > open > > because of light VM error that I got, which is error 135. The time > doubling > > effect is just to place for the computer took way too long on some > > occasional reasons to go for it. Anyways, it's just the distro issue from > > Debian. > > How can it be a distro problem from Debian? Or Fedora? The same version > of either on either 4.0 or 4.1 should be the same. Or not? > > > On Thursday, July 21, 2022 at 1:53:56 PM UTC-7 Qubes wrote: > > > >> Has the 4.1 as well as 4.1.1, because I did test on both, release added > >> additional overhead to the creation of a dvm? > >> > >> I have identical dvm's for Firefox on 4.0 and 4.1 and on 4.1 it takes > >> almost, in the region of 0.5 - 0.75 seconds almost, **double** the time > >> for a new dvm to be ready for usage, 18 seconds vs 36 (both rounded for > >> convenience). > >> > >> That is quite a hefty difference. Is there any explanation for this > >> behavior? > >> > > > > -- 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/a668211b-5026-40c0-8aa8-538f2854bc52n%40googlegroups.com.
Re: [qubes-users] Re: dvm considerably slower on R4.1
Howard Chen wrote: I have the similar as yours, but the time of one of my qubes cannot be open because of light VM error that I got, which is error 135. The time doubling effect is just to place for the computer took way too long on some occasional reasons to go for it. Anyways, it's just the distro issue from Debian. How can it be a distro problem from Debian? Or Fedora? The same version of either on either 4.0 or 4.1 should be the same. Or not? On Thursday, July 21, 2022 at 1:53:56 PM UTC-7 Qubes wrote: Has the 4.1 as well as 4.1.1, because I did test on both, release added additional overhead to the creation of a dvm? I have identical dvm's for Firefox on 4.0 and 4.1 and on 4.1 it takes almost, in the region of 0.5 - 0.75 seconds almost, **double** the time for a new dvm to be ready for usage, 18 seconds vs 36 (both rounded for convenience). That is quite a hefty difference. Is there any explanation for this behavior? -- 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/918faf0c-bf08-21d5-1d0e-3d51e4a3ad26%40ak47.co.za.
Re: [qubes-users] User used to write to network share
In dom0 terminal: > qvm-prefs [domain qubes name] qrexec_timeout 3600 On Thursday, July 21, 2022 at 1:56:35 PM UTC-7 Qubes wrote: > Howard Chen wrote: > > I have no ideas that are you talk about, but the R4.1 can be compatible > > with R4.0's accessibility for your servers. However, it might be another > > distro version problem(s) that R4.0 using Fedora 29 while R4.1 using > Fedora > > The version of Fedora you are referring to here is the version of Fedora > used for dom0, not the Templates. Debian-11 template is the same version > on both 4.0 and 4.1. > > > 32. @Unman will figure it out for you because I don't have the right > tools > > to do this type of troubleshoot similar as yours. > > On Thursday, July 21, 2022 at 12:52:42 PM UTC-7 Qubes wrote: > > > >> Qubes wrote: > >>> How does one overcome the problem of the user used to write to a > network > >>> share? > >>> > >>> In broader explanation. Say for example i connect to a network share > >>> > >>> sudo mount -o username=testuser //my-server/dir /home/user/testmount > >>> > >>> the share mounts and i can browse the file system but i cannot write to > >>> it because the write is made with the user "user" that logs onto the > >>> booted VM automatically with an unknown possibly empty password. This > >>> causes the write fail because the user "testuser" must make the write. > >>> > >>> Now on R4.0 i could make the mount with the noperm option > >>> > >>> sudo mount -o username=testuser,noperm //my-server/dir > >> /home/user/testmount > >>> > >>> Doing it like this worked 100%. When i wrote a file to the share it > >>> applied the ACLs on the share to the file being written to the share. > >>> Something in 4.1 is causing this to fail. > >>> > >>> Can anybody give me any pointers? > >>> > >>> Is it perhaps possible in 4.1 to specify the user that is used to > >>> automatically log into a VM? > >>> > >> > >> To add to this, perhaps a hint in the right direction. If i create a > >> file from cli on the network share, mounted with the "noperm" option, > >> and i edit and save it with vi it works as expected. > >> > >> sudo mount -o username=testuser,noperm //my-server/dir > /home/user/testmount > >> cd /home/user/testmount/ > >> touch testperm2.txt > >> vi testperm2.txt > >> i can edit and save the file and when i check the network share ACLs are > >> correct. > >> > >> Which means the problem is with Gnome Text Editor that i use for all of > >> my note taking. > >> > >> Is there someone that can help me understand this problem? I know gedit > >> creates a temporary file that it does the edits it and then writes that > >> to disk. I suspect the problem lies here but i have no idea how to > >> address it. Specifically it wasn't a problem on R4.0. > >> > >> Is it possible that something in R4.1 has changed the behavior here? > >> > > > > -- 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/18bb84bf-f8ec-4e2c-a045-f08f915f9ca3n%40googlegroups.com.
[qubes-users] Re: dvm considerably slower on R4.1
I have the similar as yours, but the time of one of my qubes cannot be open because of light VM error that I got, which is error 135. The time doubling effect is just to place for the computer took way too long on some occasional reasons to go for it. Anyways, it's just the distro issue from Debian. On Thursday, July 21, 2022 at 1:53:56 PM UTC-7 Qubes wrote: > Has the 4.1 as well as 4.1.1, because I did test on both, release added > additional overhead to the creation of a dvm? > > I have identical dvm's for Firefox on 4.0 and 4.1 and on 4.1 it takes > almost, in the region of 0.5 - 0.75 seconds almost, **double** the time > for a new dvm to be ready for usage, 18 seconds vs 36 (both rounded for > convenience). > > That is quite a hefty difference. Is there any explanation for this > behavior? > -- 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/17ad7b47-1ecb-4d57-80d5-9da6e39137cdn%40googlegroups.com.
Re: [qubes-users] User used to write to network share
Howard Chen wrote: I have no ideas that are you talk about, but the R4.1 can be compatible with R4.0's accessibility for your servers. However, it might be another distro version problem(s) that R4.0 using Fedora 29 while R4.1 using Fedora The version of Fedora you are referring to here is the version of Fedora used for dom0, not the Templates. Debian-11 template is the same version on both 4.0 and 4.1. 32. @Unman will figure it out for you because I don't have the right tools to do this type of troubleshoot similar as yours. On Thursday, July 21, 2022 at 12:52:42 PM UTC-7 Qubes wrote: Qubes wrote: How does one overcome the problem of the user used to write to a network share? In broader explanation. Say for example i connect to a network share sudo mount -o username=testuser //my-server/dir /home/user/testmount the share mounts and i can browse the file system but i cannot write to it because the write is made with the user "user" that logs onto the booted VM automatically with an unknown possibly empty password. This causes the write fail because the user "testuser" must make the write. Now on R4.0 i could make the mount with the noperm option sudo mount -o username=testuser,noperm //my-server/dir /home/user/testmount Doing it like this worked 100%. When i wrote a file to the share it applied the ACLs on the share to the file being written to the share. Something in 4.1 is causing this to fail. Can anybody give me any pointers? Is it perhaps possible in 4.1 to specify the user that is used to automatically log into a VM? To add to this, perhaps a hint in the right direction. If i create a file from cli on the network share, mounted with the "noperm" option, and i edit and save it with vi it works as expected. sudo mount -o username=testuser,noperm //my-server/dir /home/user/testmount cd /home/user/testmount/ touch testperm2.txt vi testperm2.txt i can edit and save the file and when i check the network share ACLs are correct. Which means the problem is with Gnome Text Editor that i use for all of my note taking. Is there someone that can help me understand this problem? I know gedit creates a temporary file that it does the edits it and then writes that to disk. I suspect the problem lies here but i have no idea how to address it. Specifically it wasn't a problem on R4.0. Is it possible that something in R4.1 has changed the behavior here? -- 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/2b58d999-950e-41c2-ab86-81c370721d35%40ak47.co.za.
[qubes-users] dvm considerably slower on R4.1
Has the 4.1 as well as 4.1.1, because I did test on both, release added additional overhead to the creation of a dvm? I have identical dvm's for Firefox on 4.0 and 4.1 and on 4.1 it takes almost, in the region of 0.5 - 0.75 seconds almost, **double** the time for a new dvm to be ready for usage, 18 seconds vs 36 (both rounded for convenience). That is quite a hefty difference. Is there any explanation for this behavior? -- 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/d82ace62-b4ec-c211-7029-3e8a7a22c8ed%40ak47.co.za.
Re: [qubes-users] User used to write to network share
I have no ideas that are you talk about, but the R4.1 can be compatible with R4.0's accessibility for your servers. However, it might be another distro version problem(s) that R4.0 using Fedora 29 while R4.1 using Fedora 32. @Unman will figure it out for you because I don't have the right tools to do this type of troubleshoot similar as yours. On Thursday, July 21, 2022 at 12:52:42 PM UTC-7 Qubes wrote: > Qubes wrote: > > How does one overcome the problem of the user used to write to a network > > share? > > > > In broader explanation. Say for example i connect to a network share > > > > sudo mount -o username=testuser //my-server/dir /home/user/testmount > > > > the share mounts and i can browse the file system but i cannot write to > > it because the write is made with the user "user" that logs onto the > > booted VM automatically with an unknown possibly empty password. This > > causes the write fail because the user "testuser" must make the write. > > > > Now on R4.0 i could make the mount with the noperm option > > > > sudo mount -o username=testuser,noperm //my-server/dir > /home/user/testmount > > > > Doing it like this worked 100%. When i wrote a file to the share it > > applied the ACLs on the share to the file being written to the share. > > Something in 4.1 is causing this to fail. > > > > Can anybody give me any pointers? > > > > Is it perhaps possible in 4.1 to specify the user that is used to > > automatically log into a VM? > > > > To add to this, perhaps a hint in the right direction. If i create a > file from cli on the network share, mounted with the "noperm" option, > and i edit and save it with vi it works as expected. > > sudo mount -o username=testuser,noperm //my-server/dir /home/user/testmount > cd /home/user/testmount/ > touch testperm2.txt > vi testperm2.txt > i can edit and save the file and when i check the network share ACLs are > correct. > > Which means the problem is with Gnome Text Editor that i use for all of > my note taking. > > Is there someone that can help me understand this problem? I know gedit > creates a temporary file that it does the edits it and then writes that > to disk. I suspect the problem lies here but i have no idea how to > address it. Specifically it wasn't a problem on R4.0. > > Is it possible that something in R4.1 has changed the behavior here? > -- 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/9f5a6ede-aa39-44ea-869e-78d5be002825n%40googlegroups.com.
Re: [qubes-users] User used to write to network share
Qubes wrote: How does one overcome the problem of the user used to write to a network share? In broader explanation. Say for example i connect to a network share sudo mount -o username=testuser //my-server/dir /home/user/testmount the share mounts and i can browse the file system but i cannot write to it because the write is made with the user "user" that logs onto the booted VM automatically with an unknown possibly empty password. This causes the write fail because the user "testuser" must make the write. Now on R4.0 i could make the mount with the noperm option sudo mount -o username=testuser,noperm //my-server/dir /home/user/testmount Doing it like this worked 100%. When i wrote a file to the share it applied the ACLs on the share to the file being written to the share. Something in 4.1 is causing this to fail. Can anybody give me any pointers? Is it perhaps possible in 4.1 to specify the user that is used to automatically log into a VM? To add to this, perhaps a hint in the right direction. If i create a file from cli on the network share, mounted with the "noperm" option, and i edit and save it with vi it works as expected. sudo mount -o username=testuser,noperm //my-server/dir /home/user/testmount cd /home/user/testmount/ touch testperm2.txt vi testperm2.txt i can edit and save the file and when i check the network share ACLs are correct. Which means the problem is with Gnome Text Editor that i use for all of my note taking. Is there someone that can help me understand this problem? I know gedit creates a temporary file that it does the edits it and then writes that to disk. I suspect the problem lies here but i have no idea how to address it. Specifically it wasn't a problem on R4.0. Is it possible that something in R4.1 has changed the behavior here? -- 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/c480353e-1ac2-54c3-b688-9c39777c9b64%40ak47.co.za.
[qubes-users] User used to write to network share
How does one overcome the problem of the user used to write to a network share? In broader explanation. Say for example i connect to a network share sudo mount -o username=testuser //my-server/dir /home/user/testmount the share mounts and i can browse the file system but i cannot write to it because the write is made with the user "user" that logs onto the booted VM automatically with an unknown possibly empty password. This causes the write fail because the user "testuser" must make the write. Now on R4.0 i could make the mount with the noperm option sudo mount -o username=testuser,noperm //my-server/dir /home/user/testmount Doing it like this worked 100%. When i wrote a file to the share it applied the ACLs on the share to the file being written to the share. Something in 4.1 is causing this to fail. Can anybody give me any pointers? Is it perhaps possible in 4.1 to specify the user that is used to automatically log into a VM? -- 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/6a6bec65-51ff-e453-fa5f-1a3575beacc7%40ak47.co.za.
