Re: [qubes-users] KDE high dom0 CPU usage

2020-08-19 Thread Chris Laprise 

On 8/20/20 12:29 AM, 54th Parallel wrote:

On Thursday, 20 August 2020 at 06:58:35 UTC+8 Chris Laprise wrote:

Not an issue with dom0 KDE here. But I did have this problem with
k/ubuntu on my new AMD Ryzen Thinkpad... graphics driver was not
working
and defaulted to a non-accelerated framebuffer mode. In this case I had
to upgrade the kernel to resolve it.

Check output of 'sudo lspci -nnk' and look for the section with 'VGA'.
If it says 'unclaimed' then your graphics driver isn't working. The
'lshw' command can also be used for a different view; it will show the
VGA section with a line 'configuration:
driver=' if
its working or the 'driver' part will be absent if its not working.

-- 
Chris Laprise, tas...@posteo.net

https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886


lspci -nnk showed VGA working fine, but the output gave me other ideas 
(lshw not available on dom0). I modified xen.cfg so that 
i915.alpha_support=1 became i915.preliminary_hw_support=1 but that made 
things worse. I then switched to a newer kernel (5.6)  and saw a minor 
framerate improvement, but the high CPU usage remained. I removed 
iommu=no-igfx and saw a better framerate, but again, high CPU usage 
remained.


I looked around and found that KDE and NVidia don't mix--at least for 
the older versions of KDE 
(https://www.phoronix.com/scan.php?page=news_item=NVIDIA-KDE-High-CPU-Fix). 
The KDE Plasma version of dom0 current is 5.10, but the NVidia GPU in my 
laptop (which is weaker than my iGPU's) needs 5.16. But the thing is--I 
don't remember installing an NVidia propietary driver at all. Anyways, I 
installed the recommended fix ('export __GL_MaxFramesAllowed=1' in an 
executable script in /etc/profile.d) but that didn't work as well, so I 
gave up and uninstalled KDE.


I switch off any nvidia gpus before installation. The company is 
anti-open source and I'm not interested in running drivers that are the 
result of a cat-and-mouse obfuscation game.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/1075b47e-c3be-f78c-d62e-78b2f0d96600%40posteo.net.

Re: [qubes-users] KDE high dom0 CPU usage

2020-08-19 Thread 54th Parallel 
On Thursday, 20 August 2020 at 06:58:35 UTC+8 Chris Laprise wrote:

> Not an issue with dom0 KDE here. But I did have this problem with 
> k/ubuntu on my new AMD Ryzen Thinkpad... graphics driver was not working 
> and defaulted to a non-accelerated framebuffer mode. In this case I had 
> to upgrade the kernel to resolve it. 
>
> Check output of 'sudo lspci -nnk' and look for the section with 'VGA'. 
> If it says 'unclaimed' then your graphics driver isn't working. The 
> 'lshw' command can also be used for a different view; it will show the 
> VGA section with a line 'configuration: driver=' if 
> its working or the 'driver' part will be absent if its not working. 
>
> -- 
> Chris Laprise, tas...@posteo.net 
> https://github.com/tasket 
> https://twitter.com/ttaskett 
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 
>

lspci -nnk showed VGA working fine, but the output gave me other ideas 
(lshw not available on dom0). I modified xen.cfg so that 
i915.alpha_support=1 became i915.preliminary_hw_support=1 but that made 
things worse. I then switched to a newer kernel (5.6)  and saw a minor 
framerate improvement, but the high CPU usage remained. I removed 
iommu=no-igfx and saw a better framerate, but again, high CPU usage 
remained. 

I looked around and found that KDE and NVidia don't mix--at least for the 
older versions of KDE 
(https://www.phoronix.com/scan.php?page=news_item=NVIDIA-KDE-High-CPU-Fix). 
The KDE Plasma version of dom0 current is 5.10, but the NVidia GPU in my 
laptop (which is weaker than my iGPU's) needs 5.16. But the thing is--I 
don't remember installing an NVidia propietary driver at all. Anyways, I 
installed the recommended fix ('export __GL_MaxFramesAllowed=1' in an 
executable script in /etc/profile.d) but that didn't work as well, so I 
gave up and uninstalled KDE. 




-- 
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/9e674a51-43d4-4a5d-9e3d-e2024a784c9dn%40googlegroups.com.

[qubes-users] Re: Where is disk space?

2020-08-19 Thread Eva Star 
Thanks for your reply. Unfortunately, not :(
I still have the problem when df -h /rw report one size and du other 
size... :(

[user@host rw]$ df -h /rw 
Filesystem  Size  Used Avail Use% Mounted on
/dev/xvdb   2.0G  1.6G  341M  83% /rw

[user@host rw]$ mount|grep xvdb 
/dev/xvdb on /rw type ext4 (rw,relatime,discard)
/dev/xvdb on /home type ext4 (rw,relatime,discard)
/dev/xvdb on /usr/local type ext4 (rw,relatime,discard)
/dev/xvdb on /var/spool/cron type ext4 (rw,relatime,discard)

[user@host rw]$ lsblk /dev/xvdb -f 
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% 
MOUNTPOINT
xvdb ext4   1.0 c1ace105-12ee-495e-a340-***  340.2M82% 
/rw

[user@host rw]$ sudo du --max-depth=1 -h /rw | sort -h
16K/rw/bind-dirs
16K/rw/lost+found
20K/rw/config
136K/rw/usrlocal
736M/rw
736M/rw/home

As you can see df still report that 1.6G USED, but last command du 
--max-depth=1 with sorting show that only 736 MB used. Lose 800MB 
somewhere... :-(

-- 
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/daedf9e0-89e8-45a2-82ae-c9e6ceadec16o%40googlegroups.com.

Re: [qubes-users] KDE high dom0 CPU usage

2020-08-19 Thread Chris Laprise 

On 8/19/20 2:08 PM, 54th Parallel wrote:

Quick question:

I decided to try out KDE on 4.0 and was liking it until I noticed the 
low overall framerate and the high CPU usage of dom0 shown in xentop 
whenever there's motion (like dragging windows around). Since I'm using 
an i7-1065G7, power shouldn't be an issue, so I was surprised.


Is there any way I can fix this? Has anyone here experienced this?


Not an issue with dom0 KDE here. But I did have this problem with 
k/ubuntu on my new AMD Ryzen Thinkpad... graphics driver was not working 
and defaulted to a non-accelerated framebuffer mode. In this case I had 
to upgrade the kernel to resolve it.


Check output of 'sudo lspci -nnk' and look for the section with 'VGA'. 
If it says 'unclaimed' then your graphics driver isn't working. The 
'lshw' command can also be used for a different view; it will show the 
VGA section with a line 'configuration: driver=' if 
its working or the 'driver' part will be absent if its not working.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/66a407d5-6847-9798-3005-acbadc5bc0f9%40posteo.net.

Re: [qubes-users] Where is disk space?

2020-08-19 Thread Ludovic Bellier 

Le 19/08/2020 à 09:30, Eva Star a écrit :

Hello,

ncdu /rw  - show that actually used less then 1G of data
df -h show: /dev/xvdb   2.0G  1.8G(used)  171M  92% /rw (show that 
used 1.8G)

qvm-ls --format disk is also show that used 1900 MB and 92% of disk space.

So, where is 1G of free space?

I don't think it's the source of your problem, but remember that /rw 
isn't the only mounting point to /dev/xvdb, so check the space usage of 
these others.


Example:

user@mail:~$ df -h /rw
Filesystem  Size  Used Avail Use% Mounted on
/dev/xvdb   9.8G  3.8G  6.1G  39% /rw
user@mail:~$ mount|grep xvdb
/dev/xvdb on /rw type ext4 (rw,relatime,discard)
/dev/xvdb on /home type ext4 (rw,relatime,discard)
/dev/xvdb on /usr/local type ext4 (rw,relatime,discard)
/dev/xvdb on /var/spool/cron type ext4 (rw,relatime,discard)

user@mail:~$ lsblk /dev/xvdb -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% 
MOUNTPOINT

xvdb ext4 1f6f89a1-be13-4ec9-b151-8115e7a96b14    5.9G 40% /rw

In your case, I think ncdu failed in computing the space usage, me, I 
trust df, du and lsblk.


You should check /rw with 'du --max-depth=1' for finding where the du 
command find a big disk usage:


Example:

user@mail:~$ sudo du --max-depth=1 -h /rw | sort -h
16K    /rw/config
16K    /rw/lost+found
20K    /rw/bind-dirs
80K    /rw/usrlocal
3.9G    /rw
3.9G    /rw/home

In my case, it's /rw/home the guilty, but what in /rw/home? I continue 
recursively and find that it's the Thunderbird IMAP directory:


user@mail:~$ du --max-depth=1 -h 
/rw/home/user/.thunderbird/v3bbe2wh.default-default/ | sort -h

4.0K /rw/home/user/.thunderbird/v3bbe2wh.default-default/extensions
4.0K /rw/home/user/.thunderbird/v3bbe2wh.default-default/minidumps
8.0K /rw/home/user/.thunderbird/v3bbe2wh.default-default/datareporting
12K    /rw/home/user/.thunderbird/v3bbe2wh.default-default/crashes
32K    /rw/home/user/.thunderbird/v3bbe2wh.default-default/Mail
740K /rw/home/user/.thunderbird/v3bbe2wh.default-default/calendar-data
1.5M /rw/home/user/.thunderbird/v3bbe2wh.default-default/storage
3.6G /rw/home/user/.thunderbird/v3bbe2wh.default-default/ImapMail
3.8G    /rw/home/user/.thunderbird/v3bbe2wh.default-default/

I hope 'du --max-depth=1' will help you.

--

Ludovic

--
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/17a1aa2d-34bf-2205-b4e1-9849a18d93d9%40zyrianes.net.

[qubes-users] bind-dirs configuration not persisting to dvm

2020-08-19 Thread Qubes 
I have an appVM that I changed into a dvm template, but I need to 
increase the size of tmpfs /run/user/1000 from the default 10% of memory 
size to e.g. 40% when an application in the dvm is opened (and the 
disp gets created).


To do this I edited /etc/systemd/logind.conf in the appVM and changed 
RuntimeDirectorySize=40%.


To make this stick between reboots, I used bind-dirs.

If I reboot the appVM and look at 'df -h' and 'cat 
/etc/systemd/logind.conf' I can see that my changes have persisted.


The problem is after I change my appVM into a dvm template, 'qvm-prefs 
 template_for_dispvms True' in my dvm 'tmpfs /run/user/1000' is 
at default 10%, 'df -h' confirms. And my customization to 
'/etc/systemd/logind.conf' is not there.


However, 'cat /rw/bind-dirs/etc/systemd/logind.conf' still shows

user@disp9640:~$ cat /rw/bind-dirs/etc/systemd/logind.conf
RuntimeDirectorySize=40%

Is that a bug or does that have something to do with how and when 
'/rw/config/qubes-bind-dirs.d/50_user.conf' is parsed? because this is 
where '/etc/systemd/logind.conf' is binded.


--
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/d651ef98-0003-72b1-3440-0bda5114c202%40ak47.co.za.

[qubes-users] KDE high dom0 CPU usage

2020-08-19 Thread 54th Parallel 
Quick question:

I decided to try out KDE on 4.0 and was liking it until I noticed the low 
overall framerate and the high CPU usage of dom0 shown in xentop whenever 
there's motion (like dragging windows around). Since I'm using an 
i7-1065G7, power shouldn't be an issue, so I was surprised. 

Is there any way I can fix this? Has anyone here experienced this?

-- 
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/a43f10a9-7704-476f-8483-576fd9c1a80fn%40googlegroups.com.

Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U

2020-08-19 Thread Chris Laprise 

On 8/19/20 8:52 AM, Dylanger Daly wrote:
So I managed to wrestle with Qube's build system and compile 
kernel-latest 5.8.1 after installing the resulting rpm I'm still 
observing the same black screen bug.


/Linux dom0 5.8.1-1.qubes.x86_64 #1 SMP Wed Aug 19 11:21:32 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux/


Thanks for trying this.



This bug must be something IOMMU / Memory Management related.

 > Yes, better support for new Ryzen CPU's would be nice.

I'm sure this issue will be fixed within a few weeks, AMD's new Laptop 
CPUs are all the rage right now, support shouldn't be too far behind, in 
the meantime I'll monitor the master branch for Xen 
and watch for any AMD 
specific commits.


I am thinking of ways to make a standard Linux KVM environment more 
Qubes-like just in case this takes months or forever. My short list is:


1. Secure copy+paste

2. Auto snap-back (like read-only) for guest root

3. Isolated NICs via passthrough

4. Split GPG

Probably a good place to get tips for these would be Whonix forum, since 
they also use non-Qubes virtualization.


--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/a34eb0aa-cf9b-0f23-5290-75e41df0c829%40posteo.net.

Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U

2020-08-19 Thread Dylanger Daly 
So I managed to wrestle with Qube's build system and compile kernel-latest 
5.8.1 after installing the resulting rpm I'm still observing the same black 
screen bug.

*Linux dom0 5.8.1-1.qubes.x86_64 #1 SMP Wed Aug 19 11:21:32 UTC 2020 x86_64 
x86_64 x86_64 GNU/Linux*

This bug must be something IOMMU / Memory Management related.

> Yes, better support for new Ryzen CPU's would be nice.

I'm sure this issue will be fixed within a few weeks, AMD's new Laptop CPUs 
are all the rage right now, support shouldn't be too far behind, in the 
meantime I'll monitor the master branch for Xen 
and watch for any AMD 
specific commits.

Fedora 32 USB boots just fine, that ISO is on 5.6 or something, so I'm 
fairly sure it's Xen related.
On Wednesday, August 19, 2020 at 5:41:23 PM UTC+10 lama...@gmail.com wrote:

> On Thursday, August 6, 2020 at 1:29:49 AM UTC+2 Dylanger Daly wrote:
>
>> > You have good taste in laptops. :)
>>
>> Haha thank you, as do you, the T14 was second on my list, yeah I suspect 
>> there will be plenty of Qubes users on these devices they tick a lot of 
>> boxes, I've never used Qubes with >4 Cores so it'll be a nice experience.
>>
>> Yes, better support for new Ryzen CPU's would be nice. I would like an 
> 4800H in my next machine, they're so fast.
> Maybe newer kernel versions like the kernel-latest package can be included 
> as optional kernel versions in the Qubes ISO. That would make it a lot more 
> user friendly to install Qubes on newer hardware without having to manually 
> create an ISO with a newer kernel.
>

-- 
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/fb559c4a-7c1d-44b8-8d46-53f3ba9be3e0n%40googlegroups.com.

[qubes-users] Suspend and high load issues on AppVM shutdown

2020-08-19 Thread Johnboy3 
Hello,

i'm new to qubes and i like the security aspect it provides. During testing i 
noticed 2 problems i couldn't solve.

1. The resume from suspend function doesn't work for me. The Computer powers on 
again, but the screen stays black. Keyboard and mouse don't work either. Using 
other linux distributions force me to use acpi_sleep=old_ordering to make 
suspend work. Trying to boot qubes with that kernel option @multiboot and 
@module in grub doesn't help.

2. Having AppVMs with several hundred GB, e.g. 500GB in vault leaves the system 
crippled and often completly unresponsive for 1-2 minutes. Some kworkerd 
process in dom0 eats up 100% of a single core. This happens every time, even 
when i boot up the AppVM in question and shut it down immediately again. The 
more GB the AppVM uses the longer the shutdown takes. Seeing the HDD Led 
flashing nonstop during the shutdown made me curious about the snapshot 
feature. Unfortunately, setting the qvm-volume revert snapshot config from 1 to 
0 didnt help. Neither with existing AppVMs nor with newly created AppVMs.

Any help is appreciated
Good day


---


Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte 
E-Mail-Adresse mitnehmen! https://www.eclipso.de


-- 
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/b7f507949d7d6476165841eb016ce7ea%40mail.eclipso.de.

[qubes-users] Re: open app in a specified workspace

2020-08-19 Thread Eva Star 
You can use devilspie2. It's easy to install it in dom0.

-- 
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/e0cf05c6-e3cd-41f5-baac-9f2ab3aec5fao%40googlegroups.com.

Re: [qubes-users] Re: Black Screen when installing 4.0.3 & 4.1 on AMD Ryzen 4750U

2020-08-19 Thread lama...@gmail.com 
On Thursday, August 6, 2020 at 1:29:49 AM UTC+2 Dylanger Daly wrote:

> > You have good taste in laptops. :)
>
> Haha thank you, as do you, the T14 was second on my list, yeah I suspect 
> there will be plenty of Qubes users on these devices they tick a lot of 
> boxes, I've never used Qubes with >4 Cores so it'll be a nice experience.
>
> Yes, better support for new Ryzen CPU's would be nice. I would like an 
4800H in my next machine, they're so fast.
Maybe newer kernel versions like the kernel-latest package can be included 
as optional kernel versions in the Qubes ISO. That would make it a lot more 
user friendly to install Qubes on newer hardware without having to manually 
create an ISO with a newer kernel.

-- 
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/79deb305-a97e-41f5-b829-01a597b32e3cn%40googlegroups.com.

[qubes-users] Where is disk space?

2020-08-19 Thread Eva Star 
Hello,

ncdu /rw  - show that actually used less then 1G of data
df -h show: /dev/xvdb   2.0G  1.8G(used)  171M  92% /rw (show that used 
1.8G) 
qvm-ls --format disk is also show that used 1900 MB and 92% of disk space.

So, where is 1G of free space?

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/615401ab-739b-4dad-9bbe-d37af1fe0442o%40googlegroups.com.

Re: [qubes-users] How would you remotely infiltrate a default Qubes OS?

2020-08-19 Thread Qubes 

On 8/19/20 6:45 AM, 54th Parallel wrote:

On Wednesday, 19 August 2020 at 00:15:08 UTC+8 Robert Spigler wrote:


This is the real solution for the Intel problem :)

https://github.com/QubesOS/qubes-issues/issues/4318

I believe IBM stated they also have protections against the Rowhammer
attacks



  I'm all for having Qubes on ppc64 but I think the problem is how rare the
hardware seems to be. With ARM, at least they're common; ppc laptops aren't
even a thing.

My view is that you can get ppc-PCs from places like Raptor Computing, but
A) they almost always have to be shipped (opening it up to targeted
interdiction) 


Is this really a problem? EVERYTHING gets shipped. Unless you always go 
and collect your laptop/PC/server/WiFi router/keyboard/mouse/you-name-it 
right off the production line., there is no way else of mitigating such 
risk. And do you then trust the staff on the production floor to not 
compromise the specific device they are building for you. And and and...



and B) there are so few places with them available that the
risk of vendor/retailer compromise is massive. This doesn't seem likely to
change anytime soon (or ever).

But I'm probably missing something, since someone who is almost certainly
more knowledgeable than I am (I'm not technical) found it worth paying a
2btc bounty for



--
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/31029915-03c2-6053-cc8e-b4b4fef0157c%40ak47.co.za.