I have successfully reached my goal. I am effectively using zram in dom0 and in templates.
While hoping @marmarek will consider to include SwapOnZRAM by default in the next releases of Qubes based on >= fedora-33, so far I’d be happy to find a solution for annoyance caused by using zram.
Namely, whenever I start any VM, its virtual block device zram0 is also populated to device widget.
For various reasons ranging from cosmetics to security I’d like to hide zram device to be populated/shown in the device widget.
For example, even gnome-disk-utility devs recognzed this and hid zram from the interface since January 9 2021, > versions 3.38.2 and up
Is there a way to achieve this, zram not to be shown in the device widget interface?
What is maybe important is that dom0’s zram isn’t listed in device widget and I can’t remember if I did it somehow, but after researching bash history, couldn’t find any trace of such an action done by me…
Bump in case someone with an idea/solution missed it. Something related to mounting with nodev? How to do that for zram devices in templates and other qubes?
A udev(7) rule in your AppVM('s template) that matches zram devices, sets ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}="1", and is in a file ordered before 99-qubes-block.rules should work.
You want to prevent zram devices inside a VM from showing up in the device widget - like OP - right? I just tried it and the solution still works for me.
Check the output of sudo cat /run/udev/data/b252:0 inside the VM to see if your e.g. /etc/udev/rules.d/30-zram.rules file successfully applied the DM_UDEV_DISABLE_DISK_RULES_FLAG property to the zram0 device (whose major:minor numbers are 252:0).
Does the rules file have the same name and location for both groups of VMs? It should probably be in /etc/udev/rules.d/ or /usr/lib/udev/rules.d/, and without involving bind-dirs. IOW, stored on the TemplateVM’s ‘root’ volume.
If the rules file is on the AppVM’s ‘private’ volume - in /usr/local/lib/udev/rules.d/ or by involving bind-dirs - I could imagine that resulting in the wrong ordering during VM startup.