Suspend and high load issues on AppVM shutdown

[John...@eclipso.email]

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

[awokd]

John...@eclipso.email:

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

Welcome.

> 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.

This is often a challenge. Search this mailing list and the Qubes HCL
for your laptop make & model. Maybe someone else has solved already.

> 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.

I have a AppVMs around that size on HDD (vs. SDD), but haven't seen
this. Maybe try switching to a different template (Debian vs. Fedora for
example) in case there's something in the one you're using.

--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

[Антон Чехов]

On Wednesday, August 19, 2020 at 12:04:49 PM UTC+2 John...@eclipso.email wrote:

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.

 Hi,

if you have the time and maybe a spare SSD/HDD available you could try the pre-release version of Qubes 4.1. It solved several issues for me but of course it isn't bug free and I don't know if it is regarded as safe to use securely already.

1. I had the same problem with each previous version until testing Qubes 4.1 solved this problem. I haven't shut down the laptop for a few days now but always resumed from suspend and it "just works". You could also try the latest kernel in 4.0 when updating dom0 but I don't know if a kernel option or the latest kernel solved the problem in Qubes 4.1. My problem was, that with the latest kernel my ethernet didn't work anymore in 4.0.

https://www.qubes-os.org/doc/software-update-dom0/

2. If you should decide to try out the latest 4.1 iso you could also try out btrfs during partitioning. There is an automated install with btrfs as well. Again, I don't know if everything is working as it should (looking at journalctl gives a few error messages but I get these in 4.0 as well) and I don't have these huge AppVM (why would you need 500GB in a vault app?) but I did notice an improvement when shutting down VM apps. It is rather fast. There is some minor bug in the Qube Manager: I sometimes have to close & reopen because the app has closed already but the Manager thinks it's still open. It usually takes less than 20 seconds and I think the warning comes when it takes more than 20 seconds.

The thing is, this might not have to do anything with brfs or ext4 or whatever but maybe with the lack of LVM. (?) I only know a few things about the differences between these file systems so I might be completely wrong. Maybe others could share their experiences.

[John...@eclipso.email]

Hi,
thanks for your replies.
I searched through HCL and the mailing list for similiar problems regarding suspend bugs but without luck. Tried several approaches from latest-kernel/-qubes-vm, shutting down all AppVMs first, upgrading/downgrading BIOS, echo 1 > /sys/power/pm_trace && suspend, etc.
There is one similar HCL entry for my B450 mainboard but without further info (all green except untested tpm).

Regarding high system load on AppVM shutdown:
My approach is to put as many (offline) data as possible in a networkless vault. Of course for security reasons: it has personal data, music files, iso files, work backup files and much more, but also for my backup strategy: instead of backing up +500GB each time, i just mount my external drive into the vault and copy only file changes with rsync. My backup time decreases from an hour down to a couple of minutes max.
Switching from fedora-30 to fedora32 and debian-10 template won't change system load on shutdown significantly. Whole system runs on a SSD with luks encryption. I didn't make deep changes into the system with which i could explain this strange behaviour. Used default settings during installation. The vault has 1TB private storage reserved using the qubes manager. Is that too much?
I'm gonna test Qubes 4.1 in the next few days.

[John...@eclipso.email]

Hi,
thank you for advice!
I tried 4.1 pre release with kernel-latest/-qubes-vm and acpi_sleep=old_ordering. This finally did the trick. Stock kernel gives me a green screen and system freeze after resuming and unlocking xscreensaver.

Btrfs also works great. I noticed that dom0 really hogs up the cpu after shutdown of huge appvms. For some reasons qubes still creates a <timestamp>-back revision just to delete it afterwards again, though revisions_to_keep is set to 0. Using btrfs i don't even need to set that config to 0, it shutdowns in like 1-2 seconds. This is one great step towards moving to qubes os.

Is there an ETA for 4.1 release date yet?

Thanks for both your help
I appreciate it

>Hi,
>if you have the time and maybe a spare SSD/HDD available you could try the pre-release version of Qubes 4.1.
>It solved several issues for me but of course it isn't bug free and I don't know if it is regarded as safe to use securely already.