[qubes-users] Onion site down for maintenance
I'm back online to find that the server hosting the Onion site is down for maintenance. Apologies for the lack of notice - I had notification but did not see it until today. -- 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 visit https://groups.google.com/d/msgid/qubes-users/Zy9q9zYgyVRYQMjF%40thirdeyesecurity.org.
Re: [qubes-users] [Q4.2] [default DVM]
On 11/2/24 15:47, David Hobach wrote: Hi, could someone kindly explain me how to change the template of the default dvm (or similarly, add a second one). I tried several explanations online, but none worked. I prefer to understand the procedure via dom0 terminal commands, but if you have a "click you through" solution, I take it as well. Cheers, Bernhard Hi, you can use qvm-prefs [vm] template [new template]. It's probably the other way around: qvm-prefs debian-12-dvm template debian-12 alright, this works (after shutting down all instances of the dvm) qvm-prefs default-dvm template debian-12 thank you. Bernhard -- 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 visit https://groups.google.com/d/msgid/qubes-users/cee04622-9813-42d1-bb2f-af34551de776%40web.de.
Re: [qubes-users] [Q4.2] [default DVM]
Hi On 11/2/24 14:35, David Hobach wrote: Hi, could someone kindly explain me how to change the template of the default dvm (or similarly, add a second one). I tried several explanations online, but none worked. I prefer to understand the procedure via dom0 terminal commands, but if you have a "click you through" solution, I take it as well. Cheers, Bernhard Hi, you can use qvm-prefs [vm] template [new template]. Say that I have a template called debian-12 and I run qvm-prefs denian-12 template debian-12-dvm That gives usage: qvm-prefs [--verbose] [--quiet] [--help] [--help-properties] [--hide-default] [--get] [--set] [--default] VMNAME [PROPERTY] [VALUE] qvm-prefs: error: no such property: 'template' That is where I was stuck with the manual best, Bernhard -- 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 visit https://groups.google.com/d/msgid/qubes-users/02fe371f-89d5-4b88-8937-ee103bb20f91%40web.de.
[qubes-users] [Q4.2] [default DVM]
Hi, could someone kindly explain me how to change the template of the default dvm (or similarly, add a second one). I tried several explanations online, but none worked. I prefer to understand the procedure via dom0 terminal commands, but if you have a "click you through" solution, I take it as well. Cheers, Bernhard -- 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 visit https://groups.google.com/d/msgid/qubes-users/57f198e2-4f7b-4a0c-9d74-84d79f4103fb%40web.de.
[qubes-users] Qubes OS users' monthly Berlin meetup
Hello dear Qubes OS users and especially those in Berlin! :) Qubes Users Berlin have been back on track for some time now! It was in silent mode due to time and resource constraints, but the monthly topic/discussion meetup is now officially resuming with this announcement: We will meet every last Friday of each month at [xHain](https://x-hain.de), a hack+makerspace at Grünberger Str. 16 in Friedrichshain. The Qubes OS meetup is also scheduled in the x-hain's calendar. A small presentation and/or discussion on different topics will be held at each meeting and will be announced in advance on the [home page](https://qubesusersberlin.github.io), as well as through social media channels, the mailing list, and the forum. The meeting for this month is scheduled for Friday, the 25. 10. 2024 from 6 till 8 p.m. at x-hain and the topics are: 1. 'Qubes OS from a beginner's perspective' 2. 'Salting Qubes' At each meeting, we will offer a hands-on installation session and/or an opportunity to try out Qubes OS using a provided laptop. There will be tasks available as exercises for both beginners and intermediate users, which you can choose to complete or skip. Snacks will also be provided :) If you wish, you can connect with us on [bluesky](https://bsky.app/profile/qubes-users-berlin.bsky.social) and [mastodon](https://mastodon.social/@qubes_users_berlin), and are welcome to join our [mailing list](https://www.autistici.org/mailman/listinfo/qub), where we announce meetings and discuss items. And of course if you're interested in presenting something related to Qubes OS yourself, please don't hesitate to reach out to us via email, forum and/or social media. We abide by xHain’s [hygiene concept](https://wiki.x-hain.de/de/xHain/hygiene-konzept), the meeting is covered by [Qubes OS Code of Conduct](https://qubes-os.org/code-of-conduct) and [Berlin Code of Conduct](https://berlincodeofconduct.org/). All creatures welcome! We look forward to discussing topics related to Qubes OS with you! -- 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/JnK5GibYqJ9VFdbE3APO6xYFKJQCNdazt5PCWyGiN3hizgtaj-bbC-7i_BiXqIwLVpqV50077zkqvsQI8DBOivlDn0Wls2CUeDrEB4WTcBg%3D%40protonmail.com.
Re: [qubes-users] fedora-40-minimal install - message about fstrim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ulrich Windl: > Of course if fstrim fails, it has the same amount of block to trim > on the next run. But if 'fstrim --verbose' prints a number of trimmed bytes at all and not an error, then apparently the trimming didn't fail (this time). To test the different behavior of filesystems like ext4 that keep track of already discarded blocks, and filesystems like XFS and Btrfs that don't (or not fully), here's a little script: https://gist.github.com/rustybird/750a5b28e7b285669fe90851e6f48b32 It creates a filesystem on a 5 GiB loop device, writes three 1 GiB files inside the mountpoint, deletes two of them; and runs fstrim three times while looking at the disk usage of the backing file after each fstrim run. Results: # ./fstrimtest ext4 3139M img mnt: 3.8 GiB (4122611712 bytes) trimmed 1091M img mnt: 0 B (0 bytes) trimmed 1091M img mnt: 0 B (0 bytes) trimmed 1091M img # ./fstrimtest xfs 3137M img mnt: 3.9 GiB (4227661824 bytes) trimmed 1089M img mnt: 3.9 GiB (4227661824 bytes) trimmed 1089M img mnt: 3.9 GiB (4227661824 bytes) trimmed 1089M img # ./fstrimtest btrfs 3084M img mnt: 3.5 GiB (3766091776 bytes) trimmed 1028M img mnt: 3 GiB (3255435264 bytes) trimmed 1028M img mnt: 3 GiB (3255435264 bytes) trimmed 1028M img Rusty -BEGIN PGP SIGNATURE- iQKSBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcRQLJfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt8Cxg/4weCl+CT4wjGYyeooSQTAdwmKT3XzsAR+U5Ht6fHqxhCxX/agEoWs42h1 ymQH2iYgxoddf+zQ07A2p20x0ZYmHHt43IXlpohcUkipYwAkxfvSP8LFyj0nLziZ sdksxKG/sZbN0o/vrlZrul4Ze0SSNqO7itE+YVgim47vsL537k78WAkEtSOqRvQX 8ES1CHmQh2qBysbIla9w7hyQUmDht2fIkmfFvy29OFCzGf4U7R3i4Agokjh797q4 8Azs9RyK7OIH7+U93+7u/BmBRm0IxkeKqeNiZlf2negZ2I9uFfiHIVqhFx0qyEWD M9PtpvlhcVfljKoNbmwrL5cTFMFBwlrXdRlqAN6808uzGmp/PVn1L2vUmLBfql/o 0czNbqcbTGNSwgoG5RD+iSvnqS2glxbrQugw8nlViPjlnlq5PCZtT51uKpj3hZgE OBpUL4vFe+nI62pKu7Taulpm9mt+hxXEnMQkzOx+j9dIrpdsx3wNuGN2hjAuWTgv FOgWaFNd1MJ6+QKyBAcw4lANBgy2NUhw6smAy1qwColQ4P64eP0CJAgPCjwHHHym jkOl+H+D/lbld0RjpHe6L2RkwvZ8l0Dvxjggtzjrd/O4DIqrplm3Cyo+yJKjZkhO zL+txZb6HSfVjupwcRJgocarwnanSGqdN+cPcD6cgvyqdkayww== =vCPI -END PGP SIGNATURE- -- 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/ZxFAso9yGp_cKc_v%40mutt.
Re: [qubes-users] fedora-40-minimal install - message about fstrim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 'Rusty Bird' via qubes-users: > Marek Marczykowski-Górecki: > > On Wed, Oct 16, 2024 at 04:28:14PM +, Rusty Bird wrote: > > > Also, on file-reflink > > > systems, where the dom0 root filesystem is storing (possibly many > > > terabytes worth of) VM volumes, fstrim can take really long. E.g. > > > here on my main Btrfs system, which is otherwise quite fast: > > > > > > # time fstrim /var/tmp/ > > > real 4m29.240s > > > > But that takes long only if there is really a lot of data to discard, > > no? > > # for i in 1 2 3; do time fstrim /var/tmp/; done 2>&1 | grep real > real 4m24.308s > real 4m34.060s > real 4m29.806s > > I don't see anything in Btrfs tracking which unused blocks it has > already issued discards for. Or in ext4, but it doesn't matter with > the small ext4 dom0 root fs in an LVM Thin installation. Actually ext4 does keep track: https://serverfault.com/questions/1113127/fstrim-is-very-slow-on-xfs-and-always-return-same-value-unlike-ext4 > So a large fs > that's neither almost empty nor almost full has to at least generate a > gigantic list of (due to fragmentation) probably rather small ranges > of blocks to be discarded in response to every fstrim and forward it > through the block subsystem (which I don't think is keeping track > either?) to the drive. Only after all of that overhead, I guess the > drive might respond faster if it had already done most of the work > last time. Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcQHAJfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt//lQ/9GtwhYOxlQCr1FMVt8jf6VSdogeZzWnErQO7ldaujc730hZcHgmbtincl 1Eo81cLy5gQ8fKzBoZ7qNhNd6VjvFJirnhHs6zqQKFCTbOs+FAM2pGViAEGLtT8r BST11UoTcrN+RBBgnd5o1wP99G/8ZWPOkB/bTAYPb6ZmYlq+oikl7fG/GbeXXFZh keHdjdiS1uutwA2Ip9pZTkCGuyUd4xy3Y9aHQm2OuuQeYln+ZUUMMeo1LqESWLl1 S1m4CRLLkN8l8StNkz3jf7605+hiyY+NPdbYMXlRl9HhxKugORMAsrzFFVkk+80h rFrxz49JLp8Cg55X0cShZNYpfaH3eOGw7PS932B+6q0qrHkb7yhCATj2VxBVdCD+ JOzaflxC32XyXDVcJrrhhfwrwoqySBVo/HSZ3O9hhvWEV9CLe+KgivsR72Ryy+eF n1d0CxjYHEN4qWRN0qTG/YatEJqkZ1bWdtG6rAQrRvkNOomPo3ikGpqw9WKnkhAN xfCGnoxjNOkCDYyrqIBhRfVKjMldIlkNRnwGGKjLARJJ08Wjmt+fiGeNeOn4qXOK jwElSeaui2nHOnje1nSxrIsIotwUIK/msFjbJ/lt7xjvna/CgftMPysztHhLrjZU I6OuIun83nkQnGTy3aAU5ohEWGVhUCB6w3RxqzTv+bWdaucBfmA= =PCuB -END PGP SIGNATURE- -- 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/ZxAcAga7JycORHlJ%40mutt.
Re: [qubes-users] fedora-40-minimal install - message about fstrim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Marek Marczykowski-Górecki: > On Wed, Oct 16, 2024 at 04:28:14PM +, Rusty Bird wrote: > > Also, on file-reflink > > systems, where the dom0 root filesystem is storing (possibly many > > terabytes worth of) VM volumes, fstrim can take really long. E.g. > > here on my main Btrfs system, which is otherwise quite fast: > > > > # time fstrim /var/tmp/ > > real4m29.240s > > But that takes long only if there is really a lot of data to discard, > no? # for i in 1 2 3; do time fstrim /var/tmp/; done 2>&1 | grep real real4m24.308s real4m34.060s real4m29.806s I don't see anything in Btrfs tracking which unused blocks it has already issued discards for. Or in ext4, but it doesn't matter with the small ext4 dom0 root fs in an LVM Thin installation. So a large fs that's neither almost empty nor almost full has to at least generate a gigantic list of (due to fragmentation) probably rather small ranges of blocks to be discarded in response to every fstrim and forward it through the block subsystem (which I don't think is keeping track either?) to the drive. Only after all of that overhead, I guess the drive might respond faster if it had already done most of the work last time. Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcQFxxfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt9SAg/9H9nFGZ2+3y4caIBouczAoNhWEavYHVeo0tbhOvbIdrbr1qPghbl/fJlV 6DyCbbn39cp9XIEqGCYI0GGS1h+X+RWu8ufCX6TZXUMcMzx+3Ye+WYOoZ3MAUCKv qUh9hxQkmAe4YD5O9hBWTY/L6Uf+wrIWVp1rmunz1sHTccy1RorAKxHF44Zohuq1 rWBUfAaiROl8CSBzuBC0Qx+VvRfA4YiIS/5+bmY0eZjIDg5SUMVNvj8aXAWBljTB eXHIZs97BmIeS+VDeKl/8jzDFEF4a4whA9U9n1POfSum1SdiuVgF7McKwz3tDgv+ 1qqu8pWsI85vdNPjTWcecjN5ju7jMA4nwYOr30TND7qi0wA3elMEWRQGjxcobAmM fN8++xA44XD8gpSr4fCUDfIb4E60vcUpTSc6NrQSfTWLK/W+OMow+9rOUyS0oO85 FTeZTcvuF54Wz1d38aGNc2YKmS8r8EVOCytzu5yEFFOFrm4E4lCYUM6A0rBgywaN yQYI46s4LVX+bcV80p6glQXHUpB40nFJ1xTmk6Y6sWMbdf4DdrIwPRKLkGVSCcwU 6IAvrZnpx5NIH/6nXR9MgY9aSKpgT6ZFZj7BNAMj9V2S/2l+OoJ8JvZsuqNJ/+uf 3UWaA9mlrGoso+as76dK0I+KUqR9/Gm2vyX1IJQCfwRNcOQVltY= =mp6H -END PGP SIGNATURE- -- 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/ZxAXHJ-AoLXvD0Jf%40mutt.
Re: [qubes-users] fedora-40-minimal install - message about fstrim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Marek Marczykowski-Górecki: > Maybe? You do need root for calling fstrim. And not calling it isn't > really huge deal, as you explain below. And it failing shouldn't > interrupt install anyway (subprocess.call, not subprocess.check_call). > But the error message indeed may be confusing. > Theoretically, sudo could be used for this call and that would be fine > in dom0, but possibly less so in a qube (yes, you can install templates > via Admin API from a qube), especially is passwordless-root package is > not installed... Ah okay, that answers why not 'sudo fstrim'. Also, on file-reflink systems, where the dom0 root filesystem is storing (possibly many terabytes worth of) VM volumes, fstrim can take really long. E.g. here on my main Btrfs system, which is otherwise quite fast: # time fstrim /var/tmp/ real4m29.240s So now I'm thinking fstrim is overkill just to install a template. Instead, maybe Salt or something could ensure that everyone (including people who installed via qubes-dist-upgrade) has the 'discard' mount option (or 'discard=async' for Btrfs, where that would be the default on modern kernels if not overridden by 'discard[=sync]') unless a user has explicitly added 'nodiscard'. > > Then qvm-template was created (which like other qvm- tools usually > > runs as a regular user) and now fstrim is skipped unless someone > > happens to invoke qvm-template as root. Skipping seems like a bug, > > but on R4.2 systems it's mitigated by the installer adding the > > 'discard' mount option for the dom0 root filesystem, making fstrim > > redundant. Except for people who installed via qubes-dist-upgrade > > or removed the mount option. For those, there's still the systemd > > fstrim.timer that should release the space to LVM, hopefully soon > > enough (weekly). Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcP6Z5fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt9Xhw/8C+Z2O/1cINMgc3mQFDCNQSKDNhXAlgCVixNUrvMm9m+mdr/NMvL1euRd ndD6KH+ud5u04qLHHghXvzRZVnHtyRiGgKQOpM8/1Q/7ifG843brS+ataUWh7+Z8 e7oNt5Y1FQrFeLQGCLU1r/OqTVPrUXDzEOCatnZMX2AgnJSf2JS6pEh3o3S27x3y ZZFeGsWiII6mGaHq38TWxwpu7WSM2K2ldSBRQKAF4UaDrWhzD+AtpyK1UYXzDlpz FWNAPd7ELpx/kFoIOatum2LkUncCMsK+3kgUW9cXUnD/fquG4YUJpTamO00rBp2W 2s2PIFHVZkkf26sytq2xFV/NwjkvQHyj+TT/LnWtPTdy6v3NmLxpWAlYnFy4Rz17 d0qViaXn26EctkYimXPaM5gvnmrLlDOlhvsDEf0ZMnLlCXlvXf9+N2c2FXjifkNZ TVjOQmiMJj5/aNFw+S02rDQxAHydra5RiaK+G/XCQ0xSuhKEVm72UWJILutyFeic MUYyf0KKJFKxSPI8O11MmJNzOYCKGQu2p4XkvwLtmuRqQZcPG+eGYHSh+qgpLjiB 4sSbqj7tnmMoIcNn9Ckh+04F/kYN/TJ5pjWvC6U9Cf0NRE0YVbv/K8mT5hrZqYFC 2WHqBBd2Sa5CTKsiZ3yrS7TPmyqco+fuDpQhSWYa+88W0BD175o= =wetx -END PGP SIGNATURE- -- 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/Zw_pnubyDzme6VOR%40mutt.
Re: [qubes-users] fedora-40-minimal install - message about fstrim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Boryeu Mao: > On Tue, Oct 15, 2024 at 3:59 AM Rusty Bird wrote: > > Boryeu Mao: > > > For the template install command on Qubes release 4.2.3 > > > > > >sudo qubes-dom0-update qubes-template-fedora-40-minimal > > > > > > I received a message that > > > > > >fstrim: /var/tmp/tmpsd1ns61v/var/lib/qubes/vm-template: the discard > > > operation is not supported > > > > Did you maybe mount a tmpfs at /var/tmp? > [...] no manual tmpfs mount. I assume you're seeing the same "not supported" message if you run: $ sudo fstrim /var/tmp/ The only thing I can think of is that you have custom partitioning, and the storage layer immediately underneath the filesystem hosting /var/tmp/ is dm-crypt (unusual for an LVM Thin installation), and dm-crypt has been mapped with discard disabled. Your storage tree (showing discard support) can be printed with: $ lsblk --output +DISC-MAX > > https://github.com/QubesOS/qubes-core-admin-client/commit/4a9b57f91fdf3a2b35a5cf707970d05bf9cadba7 > In the qvm_template_postprocess.py (which the above link points to), fstrim > is called only if the root user does the template install. To me this looks like something that was missed in the move to qvm-template: Previously, qubes-dom0-update (which had to be run as root) would install templates as normal RPM packages. I guess the logic to skip fstrim for non-root users might have been put there to ease testing the qvm-template-postprocess tool? CCing Marek Then qvm-template was created (which like other qvm- tools usually runs as a regular user) and now fstrim is skipped unless someone happens to invoke qvm-template as root. Skipping seems like a bug, but on R4.2 systems it's mitigated by the installer adding the 'discard' mount option for the dom0 root filesystem, making fstrim redundant. Except for people who installed via qubes-dist-upgrade or removed the mount option. For those, there's still the systemd fstrim.timer that should release the space to LVM, hopefully soon enough (weekly). Finally, you've used qubes-dom0-update, which nowadays calls qvm-template for template related stuff. For this, qubes-dom0-update can actually be run as non-root, but you ran it with sudo, so fstrim was *not* skipped. (Which then failed on on your system.) > Thank you very much for helping. Happy to. It's interesting :) Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcP1btfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt/L3xAAjs5MdAVStMB33Dzahh6/oinggSp5fT4f+FFLSb3gKPrzLApi3OxKNnIp 0AX/lGjFftbRcVCrwvFV5vZxMp3wAAKn68htEmvqZ3QA0hSr3aHrnu0gnVCnyGUG f0KEFmv1pluSB4Af0s5euJOq5Rocd2HxnfNNIDG+8rOZ6KRLBVpaQXzRP4ejTAsS H8XVCeB182n7RveSheyrXXr+Z980WM/xz7Qg88Wsmgi47fkulJ4ZbI2GI4z9MVHl q76pVvdKxotMCtNad3ii/tbJCGDHxacRsQhDPE36a6x+Mvgq/OlMJqbJWIBaD7VP Pxzj33Nspy8CFf585w6l3INCHz+qV9YV6/Hb674HyGHsn4O/nHF+IecdqZb19O8P XjsFK3FrW1kqxj3/5nMurZ6NrlWC2qFqCQcr9ALCodJQDFHfdComnnFu25krDmBd vl/nSEwcLpMtrtl4AUrekbHTrlDDW/096+FJlE+TNmYbD7YEK7qBxipulGwCg6Jf NBL47gbIAYISKY1L+YDY7jGhEYMMaUZy8T5P4uTHQ4Zhqa5oXRts4dtkuuvuWmBS wDfKzSGrmr694C1HnSGuTWP/a5psi5YhrGcHWILct2Ix6oUn5Q80rMbttjNnpmWT DgLjPdlAXrDvQErn09TLE/YJ4BW5ORcZSfeNBboff1AUKfRqvG4= =+Iy5 -END PGP SIGNATURE- -- 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/Zw_Vuw1gVARa8DtR%40mutt.
Re: [qubes-users] fedora-40-minimal install - message about fstrim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Boryeu Mao: > For the template install command on Qubes release 4.2.3 > >sudo qubes-dom0-update qubes-template-fedora-40-minimal > > I received a message that > >fstrim: /var/tmp/tmpsd1ns61v/var/lib/qubes/vm-template: the discard > operation is not supported Did you maybe mount a tmpfs at /var/tmp? That would explain fstrim not working. It also wouldn't matter then. > The template appears to be running normally, so perhaps this is a warning > message. Pretty much. The fstrim invocation was added to inform the underlying storage (LVM Thin by default) of the filesystem hosting /var/tmp that the space previously used for temporary image files extracted during the installation process can be freed: https://github.com/QubesOS/qubes-core-admin-client/commit/4a9b57f91fdf3a2b35a5cf707970d05bf9cadba7 But it doesn't affect the installed template. Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcOSxFfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt/oVg/8CBMUFKZf9qgpJF90En3S9SFOq5B3pr32MZptzeVaN0FjyQzObQgx0ctK vN0kPrUzwe8Djrp7CzT/eiC1eOGEcEGTHxkd1SrgcL0vFg+/SFs4QuXKZSjNwz/v u6eW5x0Q+eMVRpIIfuR+2ctJnsrmIRp/rheRj68kmGq13H+m3NkWL3Tpb6WJayDl sSOHtAW73UvQoAAOgfLAI/SB3RGlyD10E3AcUWQalJ4p3OwV0j9V0HPWZ+7QkAja s+miDY/bTqsXkDyDr6Jz8VPBoOtyy1cDVAS3DLCSN7rLT/Scn1zSYRiCZMEc6JdN McUEMjK4Cr3MoikrMPhWoDzpdgtPCHnnt+hJKC4Bsvp0PLYXGdcqn0Gm3AT5RJ6r qzWGu6Q5rHIy7V6c9TMt6I+Yg4vp2w+Y5dG4uZ2d9xBJmOLZCUBDaJD48/6MTFnX Z6h19+HzNlZHkby3+0u9DKoAYXV96dOhsC2DK9oNqskmwbiKHlsaQMnjVtYq2LTl OKcEl3Xo9hjNBBgaWgvfZBbqzyvTBXDr+fmYX0hEjpCcsdG5f2iiEoYdtE0B9Dzc cx0ylY9rkK8alRUmxg/v+DsJ/yTWhDhud1GKdORWCWB/TxdIoNGkmdwcTNHJ0cHK Mdfi2xR4ULDxdjvPbyJMwakn1yEvftIGS8/BuVeFuAzb4+7rJOU= =9zLR -END PGP SIGNATURE- -- 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/Zw5LEWwR3bf7UXRt%40mutt.
Re: [qubes-users] unable to verify unman's ubuntu templates
On Sat, Oct 05, 2024 at 08:21:24PM +0200, roger paranoia wrote: > Hello > > I am trying to verify the templates downloaded from: > > https://qubes.3isec.org/rpm/r4.2/templates/qubes-template-jammy-minimal-4.2.0-202405182317.noarch.rpm > https://qubes.3isec.org/rpm/r4.2/templates/qubes-template-noble-minimal-4.2.0-202405211137.noarch.rpm > > On a fedora-40 based template I use the following procedure: > > [aaa@bbb ~]$ gpg2 --keyserver keyserver.ubuntu.com --recv-keys > 8B3F30F9C8C0C2EF > [aaa@bbb ~]$ gpg2 --export --armor 8B3F30F9C8C0C2EF > unman.asc > [aaa@bbb ~]$ sudo mv unman.asc /etc/pki/rpm-gpg/unman.asc > [aaa@bbb Downloads]$ rpm -K > qubes-template-jammy-minimal-4.2.0-202405182317.noarch.rpm > > and I get: > > qubes-template-jammy-minimal-4.2.0-202405182317.noarch.rpm: digests > SIGNATURES NOT OK > > So that means it doesn't pass the verification check. I've used the same > procedure many times and it worked so I don't understand what happens. Does > anybody know what is the problem? > > Thank you in advance > Hello Mr Paranoia You need to import the key in to the rpm keyring: rpmkeys --import unman.asc Then the verification with `rpm -K` will work. unman -- I never presume to speak for the Qubes team. When I comment in the mailing lists I speak for myself. -- 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/ZwKeRuAeqJlTfROk%40thirdeyesecurity.org.
[qubes-users] sys-usb && flashing (arduino and others)
Dear all, on a standard linux distro, flashing microcontrollers like arduino, esp32, and many others is quite straightforward. Of course I may mimick this on qubes: create a "flash" qube, give it acces rights to USB controller, run alternatively sys-usb or "flash" and flash as I would on any other linux distro. However I wonder what would be the best "qubes way" to do it. I imagine leaving sys-usb as it is (only qubes with HW access) and "forwarding" data stream from a "flash" qube to sys-usb. One point here is that in contrast with harddrives, mouses, keyboards etc these chips are usually "silent": when you plug them on usb they do not communicate (they only take power). Therfore the "attach XXX" to qube YYY menu will not be click-able, so I might need to do all "by hand" in a dom0 terminal? Maybe some of you have already solved this question before me? best, Bernhard -- 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/a5ed1ca6-135c-413b-916d-48274265a62d%40web.de.
[qubes-users] GNOME extension: Qubes Window Borders
https://github.com/apebl/gnome-ext-qubes-window-borders I’ve created a GNOME Shell extension for Qubes OS that adds colored borders to windows. I hope this is useful for you. -- 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/c89558c2-595c-4beb-a3aa-0df252c2d130%40pebl.cc.
[qubes-users] Standalone Debian 11 -> 12 Upgrade Question
Hello! I'm trying to upgrade a standalone Debian 11 qube from Qubes OS 4.1 to Debian 12 on Qubes OS 4.2. I started by making a backup from the standalone on Qubes OS 4.1. Then I restored it on a fresh Qubes OS 4.2 installation. Inside that restored standalone I run the upgrade script: https://github.com/QubesOS/qubes-dist-upgrade/blob/release4.1/scripts/upgrade-template-standalone.sh which worked fine, but upgrading Debian 11 -> 12 failed - see below. The documentation does not yet contain steps for Debian 11 -> 12 yet: https://www.qubes-os.org/doc/templates/debian/in-place-upgrade/#debian-11-bullseye Are there Debian 12 specific issues to consider during the upgrade? Any idea on how to work around the issue shown below? thanks! sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list.d/qubes-r4.list apt update apt upgrade --no-install-recommends ... Setting up polkitd (122-3) ... Failed to check if group polkitd already exists: Connection refused id: ‘polkitd’: no such user chown: invalid user: ‘polkitd:root’ dpkg: error processing package polkitd (--configure): installed polkitd package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of pkexec: pkexec depends on polkitd (= 122-3); however: Package polkitd is not configured yet. dpkg: error processing package pkexec (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of packagekit: packagekit depends on polkitd; however: Package polkitd is not configured yet. dpkg: error processing package packagekit (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of policykit-1: policykit-1 depends on pkexec (= 122-3); however: Package pkexec is not configured yet. policykit-1 depends on polkitd (= 122-3); however: Package polkitd is not configured yet. dpkg: error processing package policykit-1 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of policykit-1-gnome: policykit-1-gnome depends on polkitd | policykit-1; however: Package polkitd is not configured yet. Package policykit-1 is not configured yet. dpkg: error processing package policykit-1-gnome (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of packagekit-tools: packagekit-tools depends on packagekit (= 1.2.6-5); however: Package packagekit is not configured yet. dpkg: error processing package packagekit-tools (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of rtkit: rtkit depends on polkitd | policykit-1; however: Package polkitd is not configured yet. Package policykit-1 is not configured yet. dpkg: error processing package rtkit (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of network-manager-gnome: network-manager-gnome depends on policykit-1-gnome | polkit-1-auth-agent; however: Package policykit-1-gnome is not configured yet. Package polkit-1-auth-agent is not installed. Package policykit-1-gnome which provides polkit-1-auth-agent is not configured yet. dpkg: error processing package network-manager-gnome (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of colord: colord depends on polkitd | policykit-1 (>= 0.103); however: Package polkitd is not configured yet. Package policykit-1 is not configured yet. dpkg: error processing package colord (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of modemmanager: modemmanager depends on polkitd | policykit-1; however: Package polkitd is not configured yet. Package policykit-1 is not configured yet. dpkg: error processing package modemmanager (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of qubes-core-agent-network-manager: qubes-core-agent-network-manager depends on network-manager-gnome; however: Package network-manager-gnome is not configured yet. qubes-core-agent-network-manager depends on policykit-1; however: Package policykit-1 is not configured yet. dpkg: error processing package qubes-core-agent-network-manager (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: polkitd pkexec packagekit policykit-1 policykit-1-gnome packagekit-tools rtkit network-manager-gnome colord modemmanager qubes-core-agent-network-manager E: Sub-process /usr/bin/dpkg returned an error code (1) -- 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
[qubes-users] UNSUBSCRIBE
On Monday, July 29th, 2024 at 08:28, colony.three via qubes-users wrote: > > > > My recommendation is: > > > 1. Create a trusted VM to run WireGuard or a key-protected onion > > service. > > 2. Allow that VM (and only that VM) to connect to sshd in dom0 via > > qubes.ConnectTCP. > > 3. Forward anything you need over the SSH tunnel. > > -- > > Sincerely, > > Demi Marie Obenour (she/her/hers) > > Invisible Things Lab > > > Well, here's a question: I'd cloned the firewall qube for my wireguard > server, but that's clearly not what you said. > > Apparently there's some distinction between a VM, a template, and a qube, > which I haven't found in the docs. Maybe making a VM would allow me to make > wireguard settings persistent? How is a VM beneficial over making a qube? A > template? Are there drawbacks to a VM? > > I still don't get how you set up a daemon by basing a qube on a template. > Settings can't be persistent in a qube, but a template is in effect a whole > OS. On one machine I don't want to install all my server software in template > debian, just to spin off qubes from it. Do I have to clone template debian > for each individual service? So it is clear now, from asking in IRC, the forum, and mailing list, that no one knows what I am talking about. Qubes users just lack the technical scope to understand, much less respond to, my questions. Unless... this is all reserved for a very small Priesthood, in which case I am ever more not interested. I have actual work that must be done which is not getting done, and recordings and backups to be made which are not getting made, and there is a limit to one's willingness to try something that appears shiny and new, but is just a bucket of wet, tepid bollocks. Qubes does not apply to enterprise infosec. Nobody knows. Enough now. I am confident that you will not miss me, but Bye. UNSUBSCRIBE -- 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/7Zq-tjsnTmYfXYMy4-SdjhUThmEz_g-pWQRzAhWzRl358XYc1x9s_b1-u2oX_rW5vFsH3UJvgITp8frWQmcjLfvwHQDzTP4Wfd1TRzXoHiM%3D%40pm.me.
Re: [qubes-users] What's Next? (Connecting VNC to dom0)
> My recommendation is: > > 1. Create a trusted VM to run WireGuard or a key-protected onion > service. > 2. Allow that VM (and only that VM) to connect to sshd in dom0 via > qubes.ConnectTCP. > 3. Forward anything you need over the SSH tunnel. > -- > Sincerely, > Demi Marie Obenour (she/her/hers) > Invisible Things Lab Well, here's a question: I'd cloned the firewall qube for my wireguard server, but that's clearly not what you said. Apparently there's some distinction between a VM, a template, and a qube, which I haven't found in the docs. Maybe making a VM would allow me to make wireguard settings persistent? How is a VM beneficial over making a qube? A template? Are there drawbacks to a VM? I still don't get how you set up a daemon by basing a qube on a template. Settings can't be persistent in a qube, but a template is in effect a whole OS. On one machine I don't want to install all my server software in template debian, just to spin off qubes from it. Do I have to clone template debian for each individual service? I've tried to understand this but it doesn't address my questions: https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-vm/index.html -- 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/kh0sYyvmtMZ1fJlTL_G4oe-jcogznyCfi6-xg9ocqhbmzcobxhBH4-pFqEZMi4cp8mxeiECKQLTA4-dDsE0j6NaymQbSSIBNSyyLVQyhvzo%3D%40pm.me.
Re: [qubes-users] What's Next? (Connecting VNC to dom0)
On Saturday, July 27th, 2024 at 12:53, Demi Marie Obenour wrote: > > > On Thu, Jul 25, 2024 at 02:09:02PM +0000, Qubes OS Users Mailing List wrote: > > > The server is a headless lights-out deal, and actually what I'd like to do > > is connect x2go to dom0. But I do not know enough yet so tried to connect > > VNC. > > > > https://www.qubes-os.org/doc/gui-domain/#vnc-gui-domain-sys-gui-vnc > > > > A VNC server session is running on localhost:5900 in sys-gui-vnc. > > > > This is clear enough, although I have to take its word for it since a > > terminal in sys-gui-vnc will not accept my username for unknown reasons. > > > > I really want to set its port to 5904 in this instance though, and I > > presume this would be done in the template, although that would mean it’s > > set that way globally which is undesirable. > > > > In order to reach the VNC server, we encourage to not connect sys-gui-vnc > > to a NetVM but rather to use another qube for remote access, say > > sys-remote. First, you need to bind port 5900 of sys-gui-vnc into a > > sys-remote local port (you may want to use another port than 5900 to reach > > sys-remote from the outside). For that, use qubes.ConnectTCP RPC service > > (see Firewall. Then, you can use any VNC client to connect to you > > sys-remote on the chosen local port (5900 if you kept the default one). For > > the first connection, you will reach lightdm for which you can log as user > > where user refers to the first dom0 user in qubes group and with > > corresponding dom0 password > > > > This is indecipherable. > > > > Running sudo qubesctl --all state.highstate took a long time, until the > > first stage timed out as unable to reach the network. No wonder, > > /etc/resolv.conf symlinks to a non-existant file under /run. Have no idea > > why. > > > > The remaining stages completed though and for some reason it chose the > > Fedora40 template even though I’ve set Debian as the system default. > > No idea what to do now. > > > My recommendation is: > > 1. Create a trusted VM to run WireGuard or a key-protected onion > service. > 2. Allow that VM (and only that VM) to connect to sshd in dom0 via > qubes.ConnectTCP. > 3. Forward anything you need over the SSH tunnel. > -- > Sincerely, > Demi Marie Obenour (she/her/hers) > Invisible Things Lab Ty. I'll try but do not know the basics of making such connections, since the Qubes machine is in a basement and I have to haul down a monitor, keyboard, and mouse to do anything, standing up. Not the best conditions for exploring and learning, but it's what I have. -- 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/s6NwEFUjgnI4NWsDSM0G5tEI9thxg7trhB98FOS69Goq6tYViHI5oaD2pWqLv9SBkFOTbEi1RnvpHVglkN5aNhOAfpl-OIWngRkIa0XrMuE%3D%40pm.me.
[qubes-users] What's Next? (Connecting VNC to dom0)
The server is a headless lights-out deal, and actually what I'd like to do is connect x2go to dom0. But I do not know enough yet so tried to connect VNC. https://www.qubes-os.org/doc/gui-domain/#vnc-gui-domain-sys-gui-vnc A VNC server session is running on localhost:5900 in sys-gui-vnc. This is clear enough, although I have to take its word for it since a terminal in sys-gui-vnc will not accept my username for unknown reasons. I really want to set its port to 5904 in this instance though, and I presume this would be done in the template, although that would mean it’s set that way globally which is undesirable. In order to reach the VNC server, we encourage to not connect sys-gui-vnc to a NetVM but rather to use another qube for remote access, say sys-remote. First, you need to bind port 5900 of sys-gui-vnc into a sys-remote local port (you may want to use another port than 5900 to reach sys-remote from the outside). For that, use qubes.ConnectTCP RPC service (see Firewall. Then, you can use any VNC client to connect to you sys-remote on the chosen local port (5900 if you kept the default one). For the first connection, you will reach lightdm for which you can log as user where user refers to the first dom0 user in qubes group and with corresponding dom0 password This is indecipherable. Running sudo qubesctl --all state.highstate took a long time, until the first stage timed out as unable to reach the network. No wonder, /etc/resolv.conf symlinks to a non-existant file under /run. Have no idea why. The remaining stages completed though and for some reason it chose the Fedora40 template even though I’ve set Debian as the system default. No idea what to do 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/GfSyxzf8ZJSXTrtv0nLj86opvWniMff-j8NTM0Z155NakDA9hh6k4tk-Jucya7MMUW8LpMRVk9dkt38OdoREzM9KrHRbLEkQymlqk8GwS7g%3D%40pm.me.
Re: [qubes-users] Unable to boot appvm due to qubes-relabel-rw
On Mon, Jun 17, 2024 at 12:02:25PM +0200, 'Rune Philosof' via qubes-users wrote: > Also, if this was a rarely used appvm, then I might not have noticed that > the problem started due to a template vm upgrade. > I also might not have the old template vm present on my system to switch > back to for cleaning up the bind dir. > > So it would be nice with another solution for this. > > The simplest to implement is probably to remove the time out, and have the > user kill the vm if it takes too long. > But that might be problematic in the case of service vms that start at > boot? If so, the time out could be conditional. > > On Mon, Jun 17, 2024 at 11:23???AM 'Rune Philosof' via qubes-users < > qubes-users@googlegroups.com> wrote: > > > After updating from `fedora-38` to `fedora-39`, I have some AppVMs that I > > am unable to boot because `qubes-relabel-rw` takes more than 60s. > > > > The VMs have large `/rw/bind-dirs/var/lib/docker`. > > > > I can clean my docker state before making the template switch, but it > > would be nice to avoid having to recreate the state. > > > > It would be good with a more user friendly process for this, both for > > explaining the problem and the solution. > > Rune Thanks for suggesting this - I'll have a think, and see what might be best suggestion for most users. unman -- 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/ZnwiFJ9ISnPeFEcu%40thirdeyesecurity.org.
Re: [qubes-users] Unable to boot appvm due to qubes-relabel-rw
Also, if this was a rarely used appvm, then I might not have noticed that the problem started due to a template vm upgrade. I also might not have the old template vm present on my system to switch back to for cleaning up the bind dir. So it would be nice with another solution for this. The simplest to implement is probably to remove the time out, and have the user kill the vm if it takes too long. But that might be problematic in the case of service vms that start at boot? If so, the time out could be conditional. On Mon, Jun 17, 2024 at 11:23 AM 'Rune Philosof' via qubes-users < qubes-users@googlegroups.com> wrote: > After updating from `fedora-38` to `fedora-39`, I have some AppVMs that I > am unable to boot because `qubes-relabel-rw` takes more than 60s. > > The VMs have large `/rw/bind-dirs/var/lib/docker`. > > I can clean my docker state before making the template switch, but it > would be nice to avoid having to recreate the state. > > It would be good with a more user friendly process for this, both for > explaining the problem and the solution. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "qubes-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/qubes-users/HejWPZX102Q/unsubscribe. > To unsubscribe from this group and all its topics, 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/8c63b924-605f-4bbe-8ead-7236abc7764en%40googlegroups.com > <https://groups.google.com/d/msgid/qubes-users/8c63b924-605f-4bbe-8ead-7236abc7764en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Med venlig hilsen / Best regards Rune Philosof Software developer +45 28 45 64 08 r...@abtion.com Vesterbrogade 15, 3 1620 København V Sverigesgade 18 5000 Odense C https://abtion.com -- 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/CAL8J5gbRb-LhKJpP9GXgko1N-KoHbzEeSXFHFxrq7kqY2nMPFA%40mail.gmail.com.
[qubes-users] Unable to boot appvm due to qubes-relabel-rw
After updating from `fedora-38` to `fedora-39`, I have some AppVMs that I am unable to boot because `qubes-relabel-rw` takes more than 60s. The VMs have large `/rw/bind-dirs/var/lib/docker`. I can clean my docker state before making the template switch, but it would be nice to avoid having to recreate the state. It would be good with a more user friendly process for this, both for explaining the problem and the solution. -- 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/8c63b924-605f-4bbe-8ead-7236abc7764en%40googlegroups.com.
Re: [qubes-users] Digest for qubes-users@googlegroups.com - 2 updates in 1 topic
So with the script replace-iptables-with-nftables I get LINK UP. Works nicely. The only issue is that if I set the NetVM to the mullvad-vpn proxy for the anon-whonix AppVM, in Tor Browser or in terminal, I don't get a connection. But if I set a NetVM mullvad-vpn proxy for normal debian AppVM Firefox, it works like a breeze. It seems that it could be an issue with the Whonix. Are there any limitations in the Whonix design that prevent the beast from connecting to the VPN over Tor? I remember that the 1.4.4 in the Qubes 4.1 it was working. Any workarounds? 'taran1s' via qubes-users: That seems promising. Does it mean that the whole procedure is still the same just instead of unzipping the 1.4.4 one downloads the replace-iptables-with-nftables and it should work as the original 1.4.4 on Qubes 4.1. Will it work as a VPN over Tor including the Tor browser? Chris Bensch: This works on the 4.2.1 release, this person made updates to switch from iptables to nftables. https://github.com/1cho1ce/Qubes-vpn-support/tree/replace-iptables-with-nftables Chris On Sat, Jun 8, 2024 at 2:47 AM wrote: qubes-users@googlegroups.com <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/qubes-users/topics> Google Groups <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> [image: Google Groups Logo] <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> Topic digest View all topics <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/qubes-users/topics> - VPN tasket on Qubes 4.2 <#m_6432881804810979594_group_thread_0> - 2 Updates VPN tasket on Qubes 4.2 <http://groups.google.com/group/qubes-users/t/e11a521d47ffb2e9?utm_source=digest&utm_medium=email> taran1s : Jun 07 03:32PM Does anyone have the VPN running through the srcipt from tasket? Were there any changes in the 4.2 that can prevent it to run? https://github.com/tasket/Qubes-vpn-support/tree/v1.4.4 I can get the VPN running from within the vpn proxy (I know it is not recommended) and firefox shows it exits from the proper IP address. But the AppVM connected to the VPN proxy cannot get any internet connection. Yes the VPN proxy has the Provides Network ticked. Also the VPN starts only if I execute sudo openvpn --cd /rw/config/vpn --config vpn-client.conf --auth-user-pass mullvad_userpass.txt Otherwise I get just the normal direct connection without the VPN. Do you have any recommendation how to solve that? Thanks a lot in advance guys. rss+qu...@armor-mail.com: Jun 08 04:14PM +0800 Do you have any recommendation how to solve that? I just use a simplified version of https://privsec.dev/posts/qubes/using-mullvad-vpn-on-qubes-os/ to run the Mullvad GUI directly. Going by the time stamp on my note file, it has been working very reliably for most of a year now, at least. RSS Back to top <#m_6432881804810979594_digest_top> You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/qubes-users/join> . To unsubscribe from this group and stop receiving emails from it send an email to qubes-users+unsubscr...@googlegroups.com. -- 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/9139e4fd-c01e-4f5b-b086-4e1e61483451%40mailbox.org.
Re: [qubes-users] Digest for qubes-users@googlegroups.com - 2 updates in 1 topic
That seems promising. Does it mean that the whole procedure is still the same just instead of unzipping the 1.4.4 one downloads the replace-iptables-with-nftables and it should work as the original 1.4.4 on Qubes 4.1. Will it work as a VPN over Tor including the Tor browser? Chris Bensch: This works on the 4.2.1 release, this person made updates to switch from iptables to nftables. https://github.com/1cho1ce/Qubes-vpn-support/tree/replace-iptables-with-nftables Chris On Sat, Jun 8, 2024 at 2:47 AM wrote: qubes-users@googlegroups.com <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/qubes-users/topics> Google Groups <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> [image: Google Groups Logo] <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> Topic digest View all topics <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/qubes-users/topics> - VPN tasket on Qubes 4.2 <#m_6432881804810979594_group_thread_0> - 2 Updates VPN tasket on Qubes 4.2 <http://groups.google.com/group/qubes-users/t/e11a521d47ffb2e9?utm_source=digest&utm_medium=email> taran1s : Jun 07 03:32PM Does anyone have the VPN running through the srcipt from tasket? Were there any changes in the 4.2 that can prevent it to run? https://github.com/tasket/Qubes-vpn-support/tree/v1.4.4 I can get the VPN running from within the vpn proxy (I know it is not recommended) and firefox shows it exits from the proper IP address. But the AppVM connected to the VPN proxy cannot get any internet connection. Yes the VPN proxy has the Provides Network ticked. Also the VPN starts only if I execute sudo openvpn --cd /rw/config/vpn --config vpn-client.conf --auth-user-pass mullvad_userpass.txt Otherwise I get just the normal direct connection without the VPN. Do you have any recommendation how to solve that? Thanks a lot in advance guys. rss+qu...@armor-mail.com: Jun 08 04:14PM +0800 Do you have any recommendation how to solve that? I just use a simplified version of https://privsec.dev/posts/qubes/using-mullvad-vpn-on-qubes-os/ to run the Mullvad GUI directly. Going by the time stamp on my note file, it has been working very reliably for most of a year now, at least. RSS Back to top <#m_6432881804810979594_digest_top> You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/qubes-users/join> . To unsubscribe from this group and stop receiving emails from it send an email to qubes-users+unsubscr...@googlegroups.com. -- Kind regards taran1s gpg: 12DDA1FE5FB39C110F3D1FD5A664B90BD3BE59B3 -- 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/5429f975-d68b-403b-822c-dcbd4ed1efd0%40mailbox.org.
Re: [qubes-users] VPN tasket on Qubes 4.2
> Do you have any recommendation how to solve that? I just use a simplified version of https://privsec.dev/posts/qubes/using-mullvad-vpn-on-qubes-os/ to run the Mullvad GUI directly. Going by the time stamp on my note file, it has been working very reliably for most of a year now, at least. RSS -- 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/20240608161432.0d8a618e%40x270nix.
[qubes-users] VPN tasket on Qubes 4.2
Does anyone have the VPN running through the srcipt from tasket? Were there any changes in the 4.2 that can prevent it to run? https://github.com/tasket/Qubes-vpn-support/tree/v1.4.4 I can get the VPN running from within the vpn proxy (I know it is not recommended) and firefox shows it exits from the proper IP address. But the AppVM connected to the VPN proxy cannot get any internet connection. Yes the VPN proxy has the Provides Network ticked. Also the VPN starts only if I execute sudo openvpn --cd /rw/config/vpn --config vpn-client.conf --auth-user-pass mullvad_userpass.txt Otherwise I get just the normal direct connection without the VPN. Do you have any recommendation how to solve that? Thanks a lot in advance guys. -- 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/54ff12e7-e73a-47e7-93d1-bb93cbfd1888%40mailbox.org.
Re: [qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not
On Thu, May 02, 2024 at 02:44:09PM -, qubist wrote: > That's secondary, but in case you are interested, mpv gives better playback: > > https://forum.qubes-os.org/t/improving-video-playback-speed/21906/8 It does not seem to play back better to me, as well at most, especially not with the aggressive frame-dropping that is turned on by default. It's even more aggressive than setting framedropping to hard on mplayer. I decided to use --framedrop=no to have it get more out of sync instead. Thank you for the suggestion though, I might decide to switch to mpv. -- 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/20240502163707.GC1058%40mail2-dvm.
Re: [qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not
I also tried an untouched version of debian 12 minimal with updates and only mplayer added from apt. There was no mimeapps.list file in /usr/share/applications, /etc/xdg/, $HOME/.config or $HOME/.local/share/applications. I tried xdg-mime default mplayer.desktop video/x-matroska as the non-root user. Still didn't work. Maybe because there wasn't a mplayer.desktop file in /usr/share/applications like in fedora. I copy over mplayer.desktop without a MimeType field from the original debian 12 miminal media qube and move it to $HOME/.local/share/applications. This gives the same error as the original media qube. I add MimeType=video/x-matroska to the desktop file and re-run the xdg-mime command. I still get the same error. -- 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/20240502144133.GB1058%40mail2-dvm.
Re: [qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not
> Trying to copy the file first and then 'xdg-open TEST.pdf' in the > target VM, I get the same series of errors: > > $ xdg-open TEST.pdf > xdg-mime: mimetype argument missing > Try 'xdg-mime --help' for more information. > /usr/bin/xdg-open: 882: x-www-browser: not found > /usr/bin/xdg-open: 882: firefox: not found > /usr/bin/xdg-open: 882: iceweasel: not found > /usr/bin/xdg-open: 882: seamonkey: not found > /usr/bin/xdg-open: 882: mozilla: not found > /usr/bin/xdg-open: 882: epiphany: not found > /usr/bin/xdg-open: 882: konqueror: not found > /usr/bin/xdg-open: 882: chromium: not found > /usr/bin/xdg-open: 882: chromium-browser: not found > /usr/bin/xdg-open: 882: google-chrome: not found > /usr/bin/xdg-open: 882: www-browser: not found > /usr/bin/xdg-open: 882: links2: not found > /usr/bin/xdg-open: 882: elinks: not found > /usr/bin/xdg-open: 882: links: not found > /usr/bin/xdg-open: 882: lynx: not found > /usr/bin/xdg-open: 882: w3m: not found > xdg-open: no method available for opening 'TEST.pdf' > > Then I tried this: > > https://unix.stackexchange.com/a/59088 > > but it changed nothing. Tested with an mp4 file - same result. > I did get xdg-open itself to work. Although all the different files and tools confused me a lot. I added the lines to mimeapps.list directly, although I think xdg-mime default alone worked for me too. I added a [Added Associations] line with the same entries as [Default Applications]. Not really sure what this does though. The mimeapps.list file I use is in /etc/xdg/ (global), so I set it from the template. Sometimes I've had to add a MimeType field (something like MimeType=video/mp4;video/x-matroska;video/webm) to the .desktop file being used, before running xdg-mime, to get it to work. > And there it is: xdg-open wrongly detects gnome3 which is not > installed. Then I checked: > > $ printenv | grep XDG_CURRENT_DESKTOP > XDG_CURRENT_DESKTOP=X-QUBES ## NOT XFCE, which is the correct value XDG_CURRENT_DESKTOP isn't even set for me, I use i3 though > > After: > > $ export XDG_CURRENT_DESKTOP=XFCE I added export XDG_CURRENT_DESKTOP=XFCE to my template, shut it down and ran qvm-open-in-dvm to open a file in it. > > xdg-open works as expected in the current session. > It started and shut down. I get the same error in journalctl on qvm-open-in-dvm. > To have "Open in VM" work as well, obviously the above must be set > persistently. > > Speculation 1 (needs checking and confirmation): > > Since I see in a fedora-xfce-template-based qubes the > XDG_CURRENT_DESKTOP=XFCE, I suppose it is somehow set when XFCE itself > is installed (and not just thunar), so perhaps the fact of the Debian > template being "-minimal" (and not "-xfce") is related to this issue > and one needs to set this thing manually to make it work properly. > > Speculation 2 (if the above is wrong): > > It might be Debian specific. I downloaded Fedora 39 minimal, it didn't have mplayer, so I tried updating and installing only kmplayer. It seems to install a lot of plasma, Qt stuff, about 200MB in total. After installing kmplayer it qvm-open-in-dvm didn't work. With journalctl in the fedora based vm it shows the same failed to connect to bus error as debian started with. After that it seems to just give an mime error, like the one you showed earlier. cat /usr/share/applications/mimeapps.list shows org.gnome.Totem as the default application. XDG_CURRENT_DESKTOP was set to X-QUBES, as with you. I copied mimeapps.list to /etc/xdg/ in the template and replaced -- 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/20240502143625.GA1058%40mail2-dvm.
[qubes-users] xdg-open works in dvm, but qvm-open-in-dvm from other qube does not
Hi, I've been trying to get a dvm to open media files in mplayer in a disposable qube. Starting the disposable media qube from dom0 with qvm-run --dispvm media-dvm --service -- qubes.StartApp+st works. Copying files(same as the ones used to test qvm-open-in-vm/qvm-open-in-dvm) to the vm with qvm-copy works. Opening the copied files with xdg-open or qubes-open works in the dvm. Opening media files in mplayer in the disposable qube with qvm-open-in-dvm used to work. It stopped working after I switched the media qube's template from debian-11-minimal to debian-12-minimal. I used qubesctl with state.highstate to get the new template to be in the same state as the previous template. I checked journalctl -f in the media dvm while running qvm-open-in-vm from the vm that usually calls qvm-open-in-dvm. The media dvm consistently gives the same errors: May 01 10:04:54 disp7040 systemctl[914]: Failed to connect to bus: No medium found May 01 10:04:56 disp7040 qubes.OpenInVM+-browse-disp[925]: cat: write error: Bad file descriptor May 01 10:04:56 disp7040 qubes.OpenInVM+-browse-disp[925]: May 01 10:04:56 disp7040 qubes.OpenInVM+-browse-disp[925]: May 01 10:04:56 disp7040 qubes.OpenInVM+-browse-disp[925]: MPlayer interrupted by signal 13 in module: unknown This is was using a mplayer binary I built myself. If I use remove that and let it use a version from apt I get a sligthly different set of errors: May 01 10:26:46 disp7040 systemctl[1234]: Failed to connect to bus: No medium found May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: cat: write error: Bad file descriptor May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: do_connect: could not connect to socket May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: connect: No such file or directory May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: Failed to open LIRC support. You will not be able to use your remote control. May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: May 01 10:26:48 disp7040 qubes.OpenInVM+-browse-disp[1246]: MPlayer interrupted by signal 13 in module: unknown The vm that calls qvm-open-in-dvm can successfully open media files in other vms. Thanks in advance for any ideas you might have. -- 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/20240501090352.GA930%40mail2-dvm.
[qubes-users] NFC and other creative communications with your qubes-os
I have a simple question, around "things that you have" (like sec. tokens, etc). Many "fido tokens" (yubi, nitro, google) allow NFC communication, most computers as well, but i do not find anything in my qubes (maybe the chips acts as USB client and my USB is down by default?) => Is there a solution to that? I am pretty sure I am not the first one to meditate that question ... Another, more creative idea could be to use the build-in fingerprint scanner but feed it artificial "precalculated random fingerprints". They could work as a second password that you have printed put on a plastic card (using standard, "fingerprint forgery" ideas, i.e. via a laser printer in a positive way) and carry it with you; They might even use as one-time-tokens, if you precalulate a bunch of them :) => did someone ever hear of such ideas? thanks, Bernhard -- 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/044ed16e-67cc-4b1c-a4bc-9ab2b4641082%40web.de.
Re: [qubes-users] 'locking' a vm possible? (to prevent accidental shutdown)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rusty Bird: > Boryeu Mao: > > An attempt to shutdown `sys-firewall` in `Qube Manager` receive a warning > > about running processes in the qube; similarly on command line > > `qvm-shutdown sys-firewall` fails with an error. Is it possible to > > designate an appVM to behave similarly so it won't get shutdown > > accidentally? > > Not as a user-facing feature AFAIK. But you could use the qubes.ext > Python entry point > > https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/__init__.py#L57-L59 > > to add another "domain-pre-shutdown" event handler like this one > (yours could e.g. check if the VM has a certain tag): > > https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/audio.py#L65-L75 Sorry, that second link should have been: https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/audio.py#L31-L38 Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmYdQPRfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt9fGw/+JHmmCw+Ly/YXJ5uYJknlH/Z8hpViEwPnIGuuz7dkiHYa53BeKg+ub035 EOt0Z2ir8NuhHGXdN77A4j1PA6gXypEBme3sxDoP0uHv1Tc3GSAgbR4NzF0qucxy EQisGL7LAw05raT5vFv8eWsHwfR1OHAupXZKJzHfjX3CBUce51K2N/eyPiuoX4es m/1lpLmLWJgXAk2MgvwNop4coRiexLuXGWYpeG+64SrDmB0oJhFZ+8rhUig5UZ41 ImpkZl+cbFIxVL+j0tcWLlaDt8yTIJzR2lw0afOvHZcqNHlNo2OPSm4HiMfrThVP 9oAAU5fvTLQtnVJ0Qw49/wm6nr2IFuR3J3Zkz4PA0jVzxuXL6OGzjLuJuFlj01Sj qxK3oU9dsN2cXCkp0k8gq39UAyHZwaeViFnAxKNm/U/ykRlFhLiloTF3ZvJYl7Vv 1N54BKKY5RjjtVsBgbDfKVcfSR4UwNt6v2PECfp+l7SpJb4XFiCNb9AoU2UoPQjj icOPXw8r7AAMZdm+ANuMhTivGIi+7HR4MQ4xKRmD1bJ1qhQPGyuq+6loYJQQX+r4 1evr5+hCbQjapWN5IA7mRSgzaUEPC0Yrc5Ttirw81dbuCIPyv+B2c8LwQDvcorIR A5EhArjwq1nY1N1ArMUKVf5+ONcIu7K56fjnMxyZXer3zExcYyA= =mP8j -END PGP SIGNATURE- -- 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/Zh1A9DYFnKTnQt_z%40mutt.
Re: [qubes-users] 'locking' a vm possible? (to prevent accidental shutdown)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Boryeu Mao: > An attempt to shutdown `sys-firewall` in `Qube Manager` receive a warning > about running processes in the qube; similarly on command line > `qvm-shutdown sys-firewall` fails with an error. Is it possible to > designate an appVM to behave similarly so it won't get shutdown > accidentally? Not as a user-facing feature AFAIK. But you could use the qubes.ext Python entry point https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/__init__.py#L57-L59 to add another "domain-pre-shutdown" event handler like this one (yours could e.g. check if the VM has a certain tag): https://github.com/QubesOS/qubes-core-admin/blob/v4.2.21/qubes/ext/audio.py#L65-L75 Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmYdP79fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt/s0A//d0ks6I+il3Y/rnG5IINmEUMC8yKdTQM9E/xQQZlqSZOUHh4OSkdZB6ON N/Iv1skUvVRuUxF8kFJ9M88FYH8X+fZsWr9ZQ18xPk+oQuQBarWTgT+TeprGj8CX WSG1dfzyFs/m5DuE4M0xvzV9efIyfA80hRl/5VwLYLscMas2Dkvfcc8yWcdDkoY7 zKcI9jZzkUPfA5gAp92NWH10kYBdWlMYiqRLW22OT+Xe/dkohs/a80B1smKRZf7D K9sF4CXauJxqxV8m+wMO8yma1jBEBoijkPZxf3m/z4SNl+cfcvLRvy+zV41dsTca nkfvP2LflDWCpJFsdK77GQPGvx7ojX09ExAXu56kZJiQAn+rWFcX8edI+E+RQ0Z/ UMZ9a8Juj3s/myNEGr+MrhrdQ5qvUEafCOVBpLJG65xAw0B7eAAqG/vbboucaaVy pQMFcYCyPxMzlMZQz82JHpzGiVscislC8naMYFneM9jsSL2K9D+P99tlHIziKt9w dwUwvbuUOJtaZm94YMIbJkUaSK9BDInx49LAlzA5pAtRX4CMHY2YzYkLEUis2oAe Ynj620eSnEwmPPa4sS97T+dnuO94S32UZrDLzYu7FZn4Rm5Gp6vq5pgbxXqkp8id BdRn5dzQI6l4fijl+6FgfMTSZzVBNr7svjuGY8D0v3OfbywnT9Y= =3CXB -END PGP SIGNATURE- -- 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/Zh0_v3dVrNYbjzcT%40mutt.
Re: [qubes-users] Star Labs StarBook certified with intel only?
On 2024-03-26 23:05, 'జిందం వాఐి' via qubes-users wrote: On 2024-03-26 22:18, Andrew David Wong wrote: On 3/25/24 11:25 AM, 'జిందం వాఐి' via qubes-users wrote: As you can see, only Intel processors are listed. I'm not personally aware of any changes since then, but when it comes to Qubes-certified hardware, you should always consult the vendor's website for the latest information. thanks for headsup, i will contact them * contacted vendor * hardware is certified for intel only * my query and vendor reply_ https://support.starlabs.systems/conversations/starbook-qubesos-certification-intel-amd-or-both/perma?token=06aab71bb3930 * hope this helps -- regards, జిందం వాఐి [ jindam, vani ] web_ jindam.neocities.org [matrix]_ @jindam:oikei.net -- regards, జిందం వాఐి [ jindam, vani ] web_ jindam.neocities.org [matrix]_ @jindam:oikei.net -- 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/9c4341b68c14f0f9822a12cab904743e%40disroot.org.
Re: [qubes-users] Star Labs StarBook certified with intel only?
On 2024-03-26 22:18, Andrew David Wong wrote: On 3/25/24 11:25 AM, 'జిందం వాఐి' via qubes-users wrote: As you can see, only Intel processors are listed. I'm not personally aware of any changes since then, but when it comes to Qubes-certified hardware, you should always consult the vendor's website for the latest information. thanks for headsup, i will contact them -- regards, జిందం వాఐి [ jindam, vani ] web_ jindam.neocities.org [matrix]_ @jindam:oikei.net -- 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/ef689eaffdd99ccdb995f9847ee4db9a%40disroot.org.
[qubes-users] Star Labs StarBook certified with intel only?
* i see an option to purchase laptop for amd also on their website * is this certified with only intel? -- regards, జిందం వాఐి [ jindam, vani ] web_ jindam.neocities.org [matrix]_ @jindam:oikei.net -- 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/ccfaea3acfd69873fb339ebf90d74178%40disroot.org.
Re: [qubes-users] Configure Network Qubes 4.2
Sorry, i discuss in the Qubes Communityfaster responses, better systemthen google groups Bapak Ireng schrieb am Montag, 25. März 2024 um 16:32:33 UTC+1: > i tried sudo /usr/libexec/initial-setup/initial-setup-graphical > > and the following is the output / result: > > > > > i tried to sent pictures, but google did not let me sent them. Sh > > > > > > > -- 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/2f09b820-5a8d-4ba3-804a-142aa513f828n%40googlegroups.com.
Re: [qubes-users] Configure Network Qubes 4.2
i tried sudo /usr/libexec/initial-setup/initial-setup-graphical and the following is the output / result: i tried to sent pictures, but google did not let me sent them. Sh -- 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/af6316e9-b3a7-461a-9fac-2ff5bd66f324n%40googlegroups.com.
Re: [qubes-users] Configure Network Qubes 4.2
Hi, after successfully installing Qubes 4.2 i am left all alone to configure network (internet) Access. I appreciate it very much if somebody could guide me to the right options. The question is so vague, no one can reasonably answer it. Does sys-net start on boot? Does it have access to the hardware (qubes settings -> devices tab)? Do we talk about ethernet / wireless? If wireless, are the needed drivers in your sys-net linux distri? and so forth -- 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/358c320a-15dd-4fd4-8486-b1c5c973d5a0%40web.de.
[qubes-users] Configure Network Qubes 4.2
Hi, after successfully installing Qubes 4.2 i am left all alone to configure network (internet) Access. I appreciate it very much if somebody could guide me to the right options. Best regards, Bapak Hitam -- 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/7e187f48-3bc5-4153-9703-fdb84bc38f1bn%40googlegroups.com.
Re: [qubes-users] Re: Qubes 4.2: Attach usb audio device to appvm
It was not fixed... Apparently just an example of how random it is. It was working for an hour or so. Now it is back to mic not working, just sending out that beep beep sound. On Wed, Mar 20, 2024 at 9:16 AM 'Rune Philosof' via qubes-users < qubes-users@googlegroups.com> wrote: > Installing a new template fixed it. > I installed fedora-39 and switched to it. > > The old template had been upgraded in-place several times, back from > fedora-36, I think. > Maybe something is missing in the upgrade from 4.1 to 4.2, or in the > instructions on how to upgrade existing templates to 4.2. > > > On Wednesday, March 20, 2024 at 8:17:25 AM UTC+1 Rune Philosof wrote: > >> Now it is more consistent in how it is not working. >> Audio output is connected properly. >> But microphone is still not working. It does not capture any sound from >> the microphone, but it does repeat a ticking sound. I have attached a 3 >> second recording of the ticking sound. >> >> I have not changed any audio settings. >> I have tested with two different usb soundcards. >> It worked in Qubes 4.1. >> >> I wonder what has changed in the audio setup from Qubes 4.1 to 4.2. >> >> On Thursday, February 29, 2024 at 12:23:30 PM UTC+1 Rune Philosof wrote: >> >>> After upgrading to 4.2 my audio device does not work. >>> >>> I plug in a usb audio device, then attach that usb device to an appvm >>> and try to use it in e.g. meet.google.com. >>> For some reason it only works for the audio microphone or the speaker, >>> not both. >>> Example: >>> 1. I attach the usb device to the appvm. >>> 2. meet.google.com automatically switches to the new microphone, but I >>> cannot hear anything and the speaker list does not show the usb device. >>> 3. I then detach from the appvm and reattach the usb device to the same >>> appvm. >>> 4. meet.google.com does not show the usb device in the list of >>> microphones. but somehow the "default" speaker now outputs through the usb >>> device. >>> >>> In 4.1 it would either work for both mic and speaker or for none. >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "qubes-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/qubes-users/NDRrrYrLkpQ/unsubscribe. > To unsubscribe from this group and all its topics, 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/f66bbd6a-ad20-4c30-a005-32bad82c8282n%40googlegroups.com > <https://groups.google.com/d/msgid/qubes-users/f66bbd6a-ad20-4c30-a005-32bad82c8282n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Med venlig hilsen / Best regards Rune Philosof Software developer +45 28 45 64 08 r...@abtion.com Vesterbrogade 15, 3 1620 København V Sverigesgade 18 5000 Odense C https://abtion.com -- 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/CAL8J5gaHuuvugFkwSEOTc6n2VnfzE0U-1yngaFu3zxqBAn2aZg%40mail.gmail.com.
Re: [qubes-users] Inconsistency between `qvm-template list` and `qvm-template-gui`
Without seeing the screenshot, I think I know the issue. They are from the same repository. qvm-template lists *all* the template in the repo, whereas qvm-template-gui filters to only show the most recent supported versions. -- I never presume to speak for the Qubes team. When I comment in the mailing lists I speak for myself. -- 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/Zfq6MxZ7JMd5HZqM%40thirdeyesecurity.org.
[qubes-users] Re: Qubes 4.2: Attach usb audio device to appvm
Installing a new template fixed it. I installed fedora-39 and switched to it. The old template had been upgraded in-place several times, back from fedora-36, I think. Maybe something is missing in the upgrade from 4.1 to 4.2, or in the instructions on how to upgrade existing templates to 4.2. On Wednesday, March 20, 2024 at 8:17:25 AM UTC+1 Rune Philosof wrote: > Now it is more consistent in how it is not working. > Audio output is connected properly. > But microphone is still not working. It does not capture any sound from > the microphone, but it does repeat a ticking sound. I have attached a 3 > second recording of the ticking sound. > > I have not changed any audio settings. > I have tested with two different usb soundcards. > It worked in Qubes 4.1. > > I wonder what has changed in the audio setup from Qubes 4.1 to 4.2. > > On Thursday, February 29, 2024 at 12:23:30 PM UTC+1 Rune Philosof wrote: > >> After upgrading to 4.2 my audio device does not work. >> >> I plug in a usb audio device, then attach that usb device to an appvm and >> try to use it in e.g. meet.google.com. >> For some reason it only works for the audio microphone or the speaker, >> not both. >> Example: >> 1. I attach the usb device to the appvm. >> 2. meet.google.com automatically switches to the new microphone, but I >> cannot hear anything and the speaker list does not show the usb device. >> 3. I then detach from the appvm and reattach the usb device to the same >> appvm. >> 4. meet.google.com does not show the usb device in the list of >> microphones. but somehow the "default" speaker now outputs through the usb >> device. >> >> In 4.1 it would either work for both mic and speaker or for none. >> > -- 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/f66bbd6a-ad20-4c30-a005-32bad82c8282n%40googlegroups.com.
Re: [qubes-users] Windows 10 and Qubes OS Dualboot
Hi one7two99, I have Qubes and Linux already installed in different partitions in legacy mode and both work fine. Now I need to install windows 10 (to run Fusion 360 for personal use). I don't want to install it as a qube as my hardware is not very powerful. I don't need Bitlocker. Could you please help? All info I've found is for installing qubes after windows. Thanks Regards Marcelo On Monday 27 January 2020 at 18:38:02 UTC-3 one7two99 wrote: > Hello Maria, > > Yes it is perfectly possible to run Windows 10 and Qubes in a dual boot > environment. > > I have spent several hours when I was researching how to put everything > together but mainly because I wanted to have the following setup: > > - CoreBoot > > - Dualboot with Windows 10 and Qubes > > - Bitlocker Encryption (to be compliant to my corporate standards) > > > As I often spent some time to get everything working like I want it to > be, I keep notes and those might also be a good starting point for you: > > > https://github.com/one7two99/my-qubes/blob/master/docs/coreboot/howto-dualboot-qubes-win-coreboot-bitlocker.md > > If you need further help, do not hesitate to contact, I can also > translate my notes to english, if it will help you. > > > Regarding a Laptop for Qubes I can and will always suggest the Lenovo > Thinkpad X230 with 16 GB RAM and a SSD. It is working perfect with > Qubes, can be Coreboot'ed and you can also plugin a LTE-card which will > also work great with Qubes. > > - one7two99 > > > -- 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/2f816b64-3140-43b4-bd80-8f7cb71e2d75n%40googlegroups.com.
Re: [qubes-users] HCL - Beelink SER5 Ryzen 7 5800H AMD Integrated Graphics (RX Vega 8)
Suspend works On Monday, March 4th, 2024 at 2:33 PM, 'bozoslivehere' via qubes-users wrote: > ---layout: > 'hcl' > type: > 'Mini PC' > hvm: > 'yes' > iommu: > 'yes' > slat: > 'yes' > tpm: > '2.0' > remap: > 'yes' > brand: | > AZW > model: | > SER > bios: | > 5800H603 > cpu: | > AMD Ryzen 7 5800H with Radeon Graphics > cpu-short: | > FIXME > chipset: | > Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630] > chipset-short: | > FIXME > gpu: | > Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon > Vega Mobile Series] [1002:1638] (rev c5) (prog-if 00 [VGA controller]) > gpu-short: | > FIXME > network: | > Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit > Ethernet Controller [10ec:8168] (rev 15) > Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a) > memory: | > 29618 > scsi: | > > usb: | > 4 > certified: > 'no' > versions: > - works: > 'FIXME:yes|no|partial' > qubes: | > R4.2.0 > xen: | > 4.17.2 > kernel: | > 6.1.62-1 > remark: | > FIXME > credit: | > FIXAUTHOR > link: | > FIXLINK > > > -- > 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/gbc92TxqDjODOV7Paes3zsLMjLiaQ1rTcC9qg6bK8k8PKyQ3bxOJLrli4QgnVJ6mOzSAoUHRRgCGgNXlqzVtn0QP_FRvRUY0SWZMPhM78i4%3D%40protonmail.com. -- 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/EGB9Fy7Bx8dUd9xqNv11QMV4_1IZ0NgwuH5bxjWQJcyhD3ANVb1h-sTcc71pImk-bFxiVeEzsc53_bwRYcys2wW79tI-MdkY96T-M4p1YhE%3D%40protonmail.com. publickey - bozoslivehere@protonmail.com - 0x25C30629.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[qubes-users] HCL - Beelink SER5 Ryzen 7 5800H AMD Integrated Graphics (RX Vega 8)
---layout: 'hcl' type: 'Mini PC' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: '2.0' remap: 'yes' brand: | AZW model: | SER bios: | 5800H603 cpu: | AMD Ryzen 7 5800H with Radeon Graphics cpu-short: | FIXME chipset: | Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630] chipset-short: | FIXME gpu: | Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] [1002:1638] (rev c5) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15) Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a) memory: | 29618 scsi: | usb: | 4 certified: 'no' versions: - works: 'FIXME:yes|no|partial' qubes: | R4.2.0 xen: | 4.17.2 kernel: | 6.1.62-1 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK -- 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/gbc92TxqDjODOV7Paes3zsLMjLiaQ1rTcC9qg6bK8k8PKyQ3bxOJLrli4QgnVJ6mOzSAoUHRRgCGgNXlqzVtn0QP_FRvRUY0SWZMPhM78i4%3D%40protonmail.com. Qubes-HCL-AZW-SER-20240302-173628.yml Description: application/yaml publickey - bozoslivehere@protonmail.com - 0x25C30629.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Ethernet socket device not available in Network Connections
[quote] my sys-net is also sys-usb because I used the USB ethernet adapter so I think this is the problem but I don't know how to fix. [/quote] I doubt that this is the problem. Have you assigned the device to sys-net in the "devices" tab of sys-net settings. When sys-net boots up, can you run `sudo journalctl -b ` in sys-net and look for any entries relating to networking devices. It may be that you need specific drivers for the NIC, so knowing what it is would be a help. -- I never presume to speak for the Qubes team. When I comment in the mailing lists I speak for myself. -- 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/ZeO5oqfRsyO49pVY%40thirdeyesecurity.org.
[qubes-users] Qubes 4.2: Attach usb audio device to appvm
After upgrading to 4.2 my audio device does not work. I plug in a usb audio device, then attach that usb device to an appvm and try to use it in e.g. meet.google.com. For some reason it only works for the audio microphone or the speaker, not both. Example: 1. I attach the usb device to the appvm. 2. meet.google.com automatically switches to the new microphone, but I cannot hear anything and the speaker list does not show the usb device. 3. I then detach from the appvm and reattach the usb device to the same appvm. 4. meet.google.com does not show the usb device in the list of microphones. but somehow the "default" speaker now outputs through the usb device. In 4.1 it would either work for both mic and speaker or for none. -- 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/bff4746d-a10d-482a-a913-dc82cf5e1ab6n%40googlegroups.com.
[qubes-users] [Qubes 4.1] issue with thunderbird after recent debian update
Hi, since a recent update, thunderbird throws artefacts on xfce screen (parts of its menu), that spawn virtual screen, survive log off & on again, but disappear if VM is closed. And re-appear when thunderbird is restarted. Very annoying! Am I alone with this type of glitch? Thanks, best, Bernhard -- 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/2fd0bfee-864c-4c14-a6d6-7200144fe994%40web.de.
Re: [qubes-users] issue with URL handler in Thunderbird: started VM receives truncated URL
[quote="Ulrich_Windl1, post:8, topic:24602"]
I kind of disagree: When passing the URL as "$1", it is passed as one
single parameter. The user cannot be expected to know to how much more
levels of shell script the parameter will be passed to, so any deeper
layers have to keep the single parameter. That is: Every layer of shell
script may not remove one level of quotes. Anything else is just an
unreliable mess IMHO.
[/quote]
I want to make sure we're on the same page about exactly why the quotes
are removed, because it sounds like you're attributing this to
`qvm-run-vm`, when in fact it is the bash invocation in the script itself.
When bash (as in, the instance of bash spawned by the `#!/bin/bash` at
the top of the `run-vm-firefox` script) reads the line `qvm-run-vm
'$dispvm' /bin/firefox "$1"`, it interprets the quotes to mean "this is
one single argument and the quotations are not a part of that argument".
So the script does not send the quotation marks to `qvm-run-vm`. It
could quote all arguments automatically and there are good
justifications for doing so but it would not be a strict improvement.
For example, even with double quotes globbing is disabled and some
callers might want to use this feature.
[quote="Demi, post:7, topic:24602"]
I suggest escaping single quotes in the $1 and adding a "--" before it.
This prevents command injection attacks via a malicious URL.
So the result might be
```bash
#!/bin/bash --
exec qvm-run-vm @dispvm /bin/firefox -- "'${1//\'/\'\\\'\'}'"
```
[/quote]
I believe this is a script improvement. The URL is not trusted data and
these safeguards do not have an impact on valid inputs.
--
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/ed25f83c-7ca3-410a-84f0-e42baba56544%40protonmail.com.
Re: [qubes-users] issue with URL handler in Thunderbird: started VM receives truncated URL
Just realized I sent this as "reply" instead of "reply all". Sorry for the spam, Ulrich, but I want to make sure this is visible to others who might have a similar problem. I think the problem is that the URL doesn't end up getting quoted on the other end. When this is sent: [quote="Ulrich_Windl1, post:3, topic:24602"] #!/bin/bash qvm-run-vm '$dispvm' /bin/firefox "$1" [/quote] The VM will end up getting the URL value with no quotes, because the quotes in that script are only for the local bash interpreter, not sent to `qvm-run-vm`. The whole expression is quoted in the exec line, but bash will interpret the line so the ampersand causes a background process to start instead of being incorporated in the URL. I'm not sure if this is a problem in `qvm-run-vm`. Some people might want to take advantage of the shell interpretation. And since the caller is able to run any arbitrary shell command anyway, problems like leaking environment variables aren't particularly relevant (they have permission to see that if they have permission to run arbitrary commands, and output is returned to the caller by design). I would guess that updating the `run-vm-firefox` command to quote the URL within the double-quotes will fix it. [Also note that the `$` is deprecated, as described in this article](https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/#security-in-symbols). The new symbol is `@`; I have only used in in policy files, but I assume that it will work here too so long as you are running 4.1 or newer. So the new file would look like this: ```bash #!/bin/bash qvm-run-vm '@dispvm' /bin/firefox "'$1'" ``` -- 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/9bbcc208-8883-46c9-befe-788ed663553c%40protonmail.com.
Re: [qubes-users] issue with URL handler in Thunderbird: started VM receives truncated URL
On Thu, 22 Feb 2024 22:19:21 +0100
Ulrich Windl wrote:
>On 2/22/24 22:15, Ulrich Windl wrote:
>> On 2/22/24 21:54, 'Stuart Perkins' via qubes-users wrote:
>>>
>>> On Thu, 22 Feb 2024 21:25:18 +0100
>>> Ulrich Windl wrote:
>>>
>>>> Hi!
>>>>
>>>>
>>>> I managed to configure Thunderbird to run any links via a DVM. However
>>>> today I realized that URLs with parameters are truncated (Qubes-OS 4.2)
>>>> after the first parameter it seem.
>>>>
>>>> For example I have the URL
>>>> ../viewtopic.php?f=21&t=196913&p=1023049&e=1023049
>>>>
>>>> When I view it in Firefox, the URL bar has only .../viewtopic.php?f=21
>>>>
>>>> Unfortunately I have no idea how to debug or fix that.
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Ulrich
>>>>
>>> Easy work around. Setup your "default browser" to be "open in vm".
>>>
>> I'm confused: The URL _is_ opened in a VM; the issue is that the URL
>> being passed in truncated after the first parameter it seems.
>>
>> https and https content type is redirected to a "run-vm-firefox" that
>> contains:
>>
>> #!/bin/bash
>> qvm-run-vm '$dispvm' /bin/firefox "$1"
>>
>> I would guess that qvm-run-vm has a quoting problem.
>>
>>
>> I see that qvm-run-vm passes the parameter correctly to
>> /usr/lib/qubes/qrun-in-vm.
>>
>> I don't know python, but these lines seems to have a problem:
>>
>> cmd = ' '.join(sys.argv[1:])
>> sys.stdout.write("exec bash -c '%s' || exit 127\n" % cmd.replace("'",
>> "'\\''"))
>>
>
>Here's my test result:
>
>$ sh -x /usr/bin/qvm-run-vm @dispvm
>"../viewtopic.php?f=21&t=196913&p=1023049&e=1023049"
>+ getopt -o htd --long help,no-gui,dispvm -n /usr/bin/qvm-run-vm --
>@dispvm ../viewtopic.php?f=21&t=196913&p=1023049&e=1023049
>+ OPTS= -- '@dispvm' '../viewtopic.php?f=21&t=196913&p=1023049&e=1023049'
>+ eval set -- -- '@dispvm'
>'../viewtopic.php?f=21&t=196913&p=1023049&e=1023049'
>+ set -- -- @dispvm ../viewtopic.php?f=21&t=196913&p=1023049&e=1023049
>+ [ 3 -gt 0 ]
>+ shift
>+ break
>+ [ != 1 ]
>+ [ 2 -lt 2 ]
>+ [ = 1 ]
>+ [ != 1 ]
>+ VMNAME=@dispvm
>+ shift
>+ service=qubes.VMShell
>+ [ != 1 ]
>+ service=qubes.VMShell+WaitForSession
>+ exec /usr/lib/qubes/qrexec-client-vm @dispvm
>qubes.VMShell+WaitForSession /usr/lib/qubes/qrun-in-vm
>./viewtopic.php?f=21&t=196913&p=1023049&e=1023049
>bash: line 1: ../viewtopic.php?f=21: No such file or directory
>
Presuming xfce4...
bash-5.2# pwd
/home/user/.config
bash-5.2# cat mimeapps.list
[Default Applications]
text/html=qvm-open-in-dvm.desktop
x-scheme-handler/http=qvm-open-in-dvm.desktop
x-scheme-handler/https=qvm-open-in-dvm.desktop
x-scheme-handler/about=qvm-open-in-dvm.desktop
x-scheme-handler/unknown=qvm-open-in-dvm.desktop
application/pdf=org.gnome.Evince.desktop
application/sql=org.gnome.TextEditor.desktop
[Added Associations]
text/plain=org.gnome.gedit.desktop;
application/pdf=gimp.desktop;pdfmod.desktop;org.gnome.Evince.desktop;
image/jpeg=gimp.desktop;display-im6.q16.desktop;
image/png=gimp.desktop;
application/sql=org.gnome.TextEditor.desktop;
bash-5.2#
--
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/20240222174150.235b3f21%40yahoo.com.
Re: [qubes-users] issue with URL handler in Thunderbird: started VM receives truncated URL
On Thu, 22 Feb 2024 21:25:18 +0100 Ulrich Windl wrote: >Hi! > > >I managed to configure Thunderbird to run any links via a DVM. However >today I realized that URLs with parameters are truncated (Qubes-OS 4.2) >after the first parameter it seem. > >For example I have the URL >../viewtopic.php?f=21&t=196913&p=1023049&e=1023049 > >When I view it in Firefox, the URL bar has only .../viewtopic.php?f=21 > >Unfortunately I have no idea how to debug or fix that. > > >Kind regards, > >Ulrich > Easy work around. Setup your "default browser" to be "open in 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/20240222155458.67e22852%40yahoo.com.
[qubes-users] Qubes OS 4.2: no more access to local ports?
I have for years done my development work using dedicated AppVMs that run podman (https://podman.io/) containers based on images from bioconductor (https://bioconductor.org/help/docker/) for project isolation and reproducibility - images are pushed on a per project basis into the registry of the gitlab instance I use. The containers run a server instance of posit's RStudio IDE (https://posit.co/products/open-source/rstudio-server) and are started mapping a local (AppVM) port to the corresponding container port (8787, both). In the AppVM, a browser is then pointed at localhost:8787 to access the IDE and work in the container. After upgrading to QubesOS 4.2 I appear no longer able to operate like that. Containers start just fine, but the browser cannot connect to the IDE. Is this a result of the new firewall engine? How to fix it? How to debug? Thank you for any pointers? -- 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/CEFA1A9C-2A3A-4580-98C2-801DEDB93A52%40graumannschaft.org.
Re: [qubes-users] Need help after a failed in-place upgrade attempt
Hi
Am Sa., 17. Feb. 2024 um 08:10 Uhr schrieb 'haaber' via
qubes-users :
Hi
> I tried to upgrade my Qubes OS system from 4.1.2 to 4.2.0
using the
> "qubes-dist-upgrade" script.
...
>
OK, I am not an expert on THIS question. Some general remarks: the
network card seems to work, right? So you need to check where
the chain
breaks.
- go to sys-net (open terminal via widget) type ping 8.8.8.8
and see if
you come out
Working.
- go to sys-firewall (terminal via widget) and do the same.
Working as well.
if these two work, and an app-vm has no network, its config
got lost.
Look at network settings of the corresponding appVM. It should be
sys-firewall in std setting, apart anon-whonix, of corse which
uses
sys-whonix.
Not working. - I changed the settings from "default
(sys-firewall) (current)" to "sys-firewall" in one App-VM ...
An additional / new info is, that an update check for 'dom0' does
no longer work !
all updates go via tor network (sys-whonix) by default. You could click
on the blue qube widget -> sys-wonix -> run terminal and see if
sys-whonix has network. But I guess not. Here is why:
https://www.qubes-os.org/doc/firewall/
I wild-guess that you are in a "half-state" where one part of the system
expects iptables, another one nftables ...
Did you download / start to download new (debian/fedora) Templates or
are they the "old" ones?
I did not see any other user jump to your help, and I am not good enough
to fix that alone for you. So honestly, at your place I would
(1) backup data (again)
(2) extract the list of manually installed packages in each of your
templates and stock them on your backup drive
("apt-mark showmanual > manual.packages.list" in a terminal is your
friend, no root priv needed)
(3) re-install a clean 4.2
(4) replay your manual installs of packages in your templates:
"cat manual.packages.list | apt-get install " or something of
this type should work (run as root)
(5) restore your data.
It's a pain and takes half a day, but I fear that it is, at the end of
the day, faster than any other solution...
good luck!
--
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/a7ff17d0-029c-4c48-a0d2-7dc271c32b7c%40web.de.
Re: [qubes-users] Need help after a failed in-place upgrade attempt
Hi I tried to upgrade my Qubes OS system from 4.1.2 to 4.2.0 using the "qubes-dist-upgrade" script. The upgrade failed - and - now the system is in a 'weird' state. None of the Fedora- or Debian-based VM have 'external / public' network access anymore. The 'anon-whonix' VM however still does have 'external / public' network access - and - the update of templates through the Qubes Updater is also still working ... OK, I am not an expert on THIS question. Some general remarks: the network card seems to work, right? So you need to check where the chain breaks. - go to sys-net (open terminal via widget) type ping 8.8.8.8 and see if you come out - go to sys-firewall (terminal via widget) and do the same. if these two work, and an app-vm has no network, its config got lost. Look at network settings of the corresponding appVM. It should be sys-firewall in std setting, apart anon-whonix, of corse which uses sys-whonix. -- 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/42cd7c79-7c3c-41b1-bc8c-cf504952201a%40web.de.
Re: [qubes-users] Updating fedora-38: "b'warning: runaway fork() in Lua script\n'"
On Friday, February 16th, 2024 at 6:32 PM, Ulrich Windl wrote: > > > Hi! > > > I saw these messages when upading fedora-38 today. I didn't run QuebesOS > for a while, so there were a lot of updates, but "runaway fork()" > worries me a bit... I've seen these messages too, during updates, for what it's worth - I also don't know what they're about. - mov > > > Kind regards, > > Ulrich > > --- > > Updating fedora-38 > b'warning: runaway fork() in Lua script\n' > b'warning: runaway fork() in Lua script\n' > b'warning: runaway fork() in Lua script\n' > b'warning: runaway fork() in Lua script\n' > b'warning: runaway fork() in Lua script\n' > b'Generating grub configuration file ...\nFound linux image: > /boot/vmlinuz-6.6.11-100.fc38.x86_64\nFound initrd image: > /boot/initramfs-6.6.11-100.fc38.x86_64.img\nfgrep: warning: fgrep is > obsolescent; using grep -F\nFound linux image: > /boot/vmlinuz-6.6.9-100.fc38.x86_64\nFound initrd image: > /boot/initramfs-6.6.9-100.fc38.x86_64.img\nfgrep: warning: fgrep is > obsolescent; using grep -F\nFound linux image: > /boot/vmlinuz-6.6.11-100.fc38.x86_64\nFound initrd image: > /boot/initramfs-6.6.11-100.fc38.x86_64.img\nfgrep: warning: fgrep is > obsolescent; using grep -F\nFound linux image: > /boot/vmlinuz-6.6.9-100.fc38.x86_64\nFound initrd image: > /boot/initramfs-6.6.9-100.fc38.x86_64.img\nfgrep: warning: fgrep is > obsolescent; using grep -F\nfgrep: warning: fgrep is obsolescent; using > grep -F\nAdding boot menu entry for UEFI Firmware Settings ...\ndone\n' > b'warning: runaway fork() in Lua script\n' > b'warning: runaway fork() in Lua script\n' > b'warning: runaway fork() in Lua script\n' > b'warning: runaway fork() in Lua script\n' > > Installed packages: > cirrus-audio-firmware ['202401152.fc38'] > intel-audio-firmware ['202401152.fc38'] > nxpwireless-firmware ['202401152.fc38'] > tiwilink-firmware ['202401152.fc38'] > Updated packages: > kernel-modules-core 6.6.8100.fc38', '6.6.9100.fc38', '6.6.11100.fc38 -> > > 6.6.9100.fc38', '6.6.11100.fc38', '6.7.4100.fc38 > kernel-core 6.6.8100.fc38', '6.6.9100.fc38', '6.6.11100.fc38 -> > > 6.6.9100.fc38', '6.6.11100.fc38', '6.7.4100.fc38 > kernel-modules 6.6.8100.fc38', '6.6.9100.fc38', '6.6.11100.fc38 -> > > 6.6.9100.fc38', '6.6.11100.fc38', '6.7.4100.fc38 > kernel 6.6.8100.fc38', '6.6.9100.fc38', '6.6.11100.fc38 -> > > 6.6.9100.fc38', '6.6.11100.fc38', '6.7.4100.fc38 > linux-firmware-whence 202312111.fc38 -> 202401152.fc38 > > xorg-x11-server-common 1.20.1428.fc38 -> 1.20.1429.fc38 > > xen-licenses 4.17.25.fc38 -> 4.17.26.fc38 > > amd-gpu-firmware 202312111.fc38 -> 202401152.fc38 > > amd-ucode-firmware 202312111.fc38 -> 202401152.fc38 > > atheros-firmware 202312111.fc38 -> 202401152.fc38 > > brcmfmac-firmware 202312111.fc38 -> 202401152.fc38 > > intel-gpu-firmware 202312111.fc38 -> 202401152.fc38 > > mt7xxx-firmware 202312111.fc38 -> 202401152.fc38 > > nvidia-gpu-firmware 202312111.fc38 -> 202401152.fc38 > > realtek-firmware 202312111.fc38 -> 202401152.fc38 > > linux-firmware 202312111.fc38 -> 202401152.fc38 > > python3-dnf-plugins-qubes-hooks 4.2.271.fc38 -> 4.2.281.fc38 > > vim-filesystem 9.1.0311.fc38 -> 9.1.0762.fc38 > > vim-data 9.1.0311.fc38 -> 9.1.0762.fc38 > > tzdata 2023d1.fc38 -> 2024a1.fc38 > > perl-Module-CoreList 5.202312301.fc38 -> 5.202401291.fc38 > > ncurses-base 6.43.20230114.fc38 -> 6.47.20230520.fc38 > > glibc-gconv-extra 2.3716.fc38 -> 2.3718.fc38 > > ncurses-libs 6.43.20230114.fc38 -> 6.47.20230520.fc38 > > glibc 2.3716.fc38 -> 2.3718.fc38 > > bash 5.2.211.fc38 -> 5.2.261.fc38 > > glibc-common 2.3716.fc38 -> 2.3718.fc38 > > glibc-langpack-en 2.3716.fc38 -> 2.3718.fc38 > > systemd-libs 253.141.fc38 -> 253.152.fc38 > > gstreamer1 1.22.81.fc38 -> 1.22.91.fc38 > > alsa-lib 1.2.102.fc38 -> 1.2.112.fc38 > > grub2-common 2.06108.fc38 -> 2.06114.fc38 > > libdrm 2.4.1171.fc38 -> 2.4.1201.fc38 > > gstreamer1-plugins-base 1.22.81.fc38 -> 1.22.91.fc38 > > gstreamer1-plugins-good 1.22.81.fc38 -> 1.22.91.fc38 > > gstreamer1-plugins-good-qt 1.22.81.fc38 -> 1.22.91.fc38 > > gstreamer1-plugins-bad-free-libs 1.22.83.fc38 -> 1.22.91.fc38 > > audit-libs
Re: [qubes-users] time sync dysfunctional
Dear unman & qubes -community, I am still on Q4.1 (no time to do a full install now). Since a few days, my time ran large out of sync, despite the swdate displaying normal functioning. I rebooted, I restarted swdate. Its log says: [INFO] date output: 10:44:44 (which is London time, but otherwise correct), my set-to-Berlin-time clock displays 10:42 which is 1h and 3min wrong. If it was 1h exactly, I'd guess a user-malconfig, but 3min ?? do you have some hints on that? Thank you, Bernhard Hi Bernhard My first thought was that this is a Whonix issue, but the fact that `date` has the same 3 min offset speaks against that. Let me get to a 4.1 box and I will see if I can help. Do you have locales set differently in qube from in dom0? What timezone is set in dom0? What in the qube? What in your Whonix gateway? things are even more funny (or not) since sys-whonix itself displays the correct time! The widget & other app-VM's are off by 3-4 minutes constantly. that is very confusing ... best, Bernhard -- 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/f3a00d4f-0c24-49ee-853c-5c9cf6df5a45%40web.de.
Re: [qubes-users] Re: question on 'service-name' for the new (R4.2) qrexec policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Boryeu Mao: > > For R4.1.2 I had some RPC calls with + and - characters in the file > > name. These are considered as invalid characters to be part of service > > names in the new qrexec policy format (e.g. in > > /etc/qubes/policy.d/30-user.policy). Using wild card * works, but I > > wonder if there is any way to keep these characters in explicitly > > specifying the calls. > Correction - only + is considered as invalid character. Already in the old format, a file /etc/qubes-rpc/policy/foo+bar+baz actually specified the policy for a qrexec service named 'foo' called with one argument 'bar+baz'. (Invoking qrexec-client-vm for 'foo+bar+baz' will attempt to execute a specialized implementation at /etc/qubes-rpc/foo+bar+baz first, or if that doesn't exist /etc/qubes-rpc/foo for a general implementation. That is still the same in R4.2.) In the new policy format this would be written as a line starting with foo +bar+baz Note the whitespace before the first '+' character, which makes it a little bit clearer what's going on. Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmXLaSlfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt+a5g/+OirPpQTa3qsPULMrXFMNqyuuKkohAvFuCoOpBRlJK5KazFju9C9Nnu5b 377A5z/x2SIQldHgTKxDpHhymohr9d63CxCM9iKGMSJECaBWSJA3iSLTjBzp8KUZ JZ3bTNdbztG6Pd06xNNCj3qpIUEDSV3cxkE4hPf3wpAqrhG3RRtpaJZ0CJ9QTxxX Cg+IHMo/jalItP5dDCOizF8XZwNxO6sYfXGdVS7PsRIVsoaAJyN+b1/EG0HWfwh4 kqqG5ZMX3vYRkTFOfveWkEKKc4OPOAQ1RvD+CclceneUvPVDn39tUONeL5ptD6cK Np+T/fMbrrW/0k280RJbaNj8H73SCRzMBG0zl1WrFKzYVAUL8kJi/0tJqJkqRArv Dg2pT6GqUG0agzLf6tLeVyGYHpJ6OwJAIBJTo54k7+IXpUZltYxPKJbTEXKPfcri jKCjNIWcMC44xKIFAxrqcdYcPWOBjPAxHFYiMJEq6Go4ufXU8atBdzD/4nzZOZPD rUUM6NDDyiigcUUw13v9ccERXjwdPE575eUMhXO923Ce7TsUsFrSbA6pASa+BRyJ 4yeb36HMR0opkqhftxjN9QPPMLBGSNmQ+DTq7TZYT75jz8WoAvykBFsQ+FkoFCxN 7fKAbCAdVdRA6329PM/sO2YRKH+r6t7uVpjtJJcR5NFkN/J4mQ0= =hsTB -END PGP SIGNATURE----- -- 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/ZctpKVnrYXENkrU3%40mutt.
Re: [qubes-users] time sync dysfunctional
Hi Unman I reply inline below. On 2/6/24 11:45, 'haaber' via qubes-users wrote: Hi, I am still on Q4.1 (no time to do a full install now). Since a few days, my time ran large out of sync, despite the swdate displaying normal functioning. I rebooted, I restarted swdate. Its log says: [INFO] date output: 10:44:44 (which is London time, but otherwise correct), my set-to-Berlin-time clock displays 10:42 which is 1h and 3min wrong. If it was 1h exactly, I'd guess a user-malconfig, but 3min ?? do you have some hints on that? Thank you, Bernhard Hi Bernhard My first thought was that this is a Whonix issue, but the fact that `date` has the same 3 min offset speaks against that. Let me get to a 4.1 box and I will see if I can help. Do you have locales set differently in qube from in dom0? What timezone is set in dom0? CET (UTC +1:00) according to timedatectl What in the qube? same, CET (UTC + 1:00) What in your Whonix gateway? the whonix netvm- is sys-whonix who connects to sys-firewall and finally sys-net (classic setup). Was that your question? Whonix is still whonix-16 (I know ..) thank you, Bernhard -- 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/ac592d47-fe37-4e4e-a47e-bc627bf694ab%40web.de.
Re: [qubes-users] time sync dysfunctional
On Tue, Feb 06, 2024 at 01:08:09PM +0100, 'haaber' via qubes-users wrote: > addendum: if I run "date" in a client VM it will give the right > timezone, but still has 3min of delay.. > > On 2/6/24 11:45, 'haaber' via qubes-users wrote: > > Hi, > > > > I am still on Q4.1 (no time to do a full install now). Since a few days, > > my time ran large out of sync, despite the swdate displaying normal > > functioning. I rebooted, I restarted swdate. Its log says: > > > > [INFO] date output: 10:44:44 > > > > (which is London time, but otherwise correct), my set-to-Berlin-time > > clock displays 10:42 which is 1h and 3min wrong. If it was 1h exactly, > > I'd guess a user-malconfig, but 3min ?? > > > > do you have some hints on that? > > > > Thank you, Bernhard > > Hi Bernhard My first thought was that this is a Whonix issue, but the fact that `date` has the same 3 min offset speaks against that. Let me get to a 4.1 box and I will see if I can help. Do you have locales set differently in qube from in dom0? What timezone is set in dom0? What in the qube? What in your Whonix gateway? -- I never presume to speak for the Qubes team. When I comment in the mailing lists I speak for myself. -- 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/ZcJOtWudrPFmk8qe%40thirdeyesecurity.org.
Re: [qubes-users] time sync dysfunctional
addendum: if I run "date" in a client VM it will give the right timezone, but still has 3min of delay.. On 2/6/24 11:45, 'haaber' via qubes-users wrote: Hi, I am still on Q4.1 (no time to do a full install now). Since a few days, my time ran large out of sync, despite the swdate displaying normal functioning. I rebooted, I restarted swdate. Its log says: [INFO] date output: 10:44:44 (which is London time, but otherwise correct), my set-to-Berlin-time clock displays 10:42 which is 1h and 3min wrong. If it was 1h exactly, I'd guess a user-malconfig, but 3min ?? do you have some hints on that? Thank you, Bernhard -- 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/b7ad40dc-ff67-49e1-b4aa-5b1fecd92f1d%40web.de.
[qubes-users] time sync dysfunctional
Hi, I am still on Q4.1 (no time to do a full install now). Since a few days, my time ran large out of sync, despite the swdate displaying normal functioning. I rebooted, I restarted swdate. Its log says: [INFO] date output: 10:44:44 (which is London time, but otherwise correct), my set-to-Berlin-time clock displays 10:42 which is 1h and 3min wrong. If it was 1h exactly, I'd guess a user-malconfig, but 3min ?? do you have some hints on that? Thank you, Bernhard -- 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/85ce7c94-89e6-4d0e-af73-47538a29523b%40web.de.
[qubes-users] HCL Purism Librem mini V2 with Qubes 4.2
Hi, HCL: --- layout: 'hcl' type: 'Desktop' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'no' remap: 'yes' brand: | Purism model: | librem_mini_v2 bios: | PureBoot-Release-20 cpu: | Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz cpu-short: | FIXME chipset: | Intel Corporation Comet Lake-U v1 4c Host Bridge/DRAM Controller [8086:9b61] (rev 0c) chipset-short: | FIXME gpu: | Intel Corporation CometLake-U GT2 [UHD Graphics] [8086:9b41] (rev 02) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 07) memory: | 65410 scsi: | Samsung SSD 870 Rev: 1B6Q usb: | 1 certified: 'no' versions: - works: 'yes' qubes: | R4.2.0 xen: | 4.17.2 kernel: | 6.1.62-1 remark: | Everything seems fine credit: | code9n link: | FIXLINK .cpio attached. Thanks for 4.2 On Sunday, January 21st, 2024 at 09:45, qubes-users@googlegroups.com wrote: > [qubes-users@googlegroups.com](https://groups.google.com/forum/#!forum/qubes-users/topics) > [Google Groups](https://groups.google.com/forum/#!overview) > https://groups.google.com/forum/#!overview > [Today's topic summary] > [View all topics](https://groups.google.com/forum/#!forum/qubes-users/topics) > > - [problem with 4.2 rc5 installation source](#group_thread_0) - 1 Update > [] > [problem with 4.2 rc5 installation > source](http://groups.google.com/group/qubes-users/t/2d918d15d2aebc4e) > Kai : Jan 20 02:26PM -0800 > > Thank you to everyone who has helped me in the last mails. > > I have finally decided to buy a NovaCustomes Laptop that is Qubes certified > and as expected, that works very well with Qubes 4.2. > [...more](http://groups.google.com/group/qubes-users/msg/1949463a81fdf) > > [Back to top](#digest_top) > > You received this digest because you're subscribed to updates for this group. > You can change your settings on the [group membership > page](https://groups.google.com/forum/#!forum/qubes-users/join). > To unsubscribe from this group and stop receiving emails from it send an > email to qubes-users+unsubscr...@googlegroups.com. -- 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/fD3uWIfDS2n70LKl7Fs9ECBCdjM1bf2gFtuqgn6TjFXN9jCajii2IL0iL4Qiw0qU9DYlHJoxp1j1wG2REIGn4PCumbrxgDriDBnjm8vHJHQ%3D%40protonmail.com. Qubes-HCL-Purism-librem_mini_v2-20240121-180500.cpio.gz Description: application/gzip
[qubes-users] LUKS and Yubikey in 4.2?
Can a librem key or yubikey be used to unlock a LUKS filesystem at boot in 4.2? Wasn’t the issue previously related to dom0 being too old? 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/b67011fa-b4e1-4490-9e2c-88a4f3e9d550%40Canary. signature.asc Description: PGP signature
[qubes-users] HCL - ASUS Expertbook B9400CEA
--- layout: 'hcl' type: 'Notebook' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: '2.0' remap: 'yes' brand: | ASUSTeK COMPUTER INC. model: | ASUS EXPERTBOOK B9400CEA_B9400CEA bios: | B9400CEA.311 cpu: | 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz cpu-short: | FIXME chipset: | Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01) chipset-short: | FIXME gpu: | Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Wi-Fi 6 AX201 [8086:a0f0] (rev 20) memory: | 16073 scsi: | usb: | 3 certified: 'no' versions: - works: 'FIXME:yes|no|partial' qubes: | R4.2.0 xen: | 4.17.2 kernel: | 6.1.62-1 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK -- 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/23095980-a277-4c7d-ae18-30ad97068448%40unixos.org.
Re: [qubes-users] Re: Qubes 4.2: qubes-tunnel not working after upgrade (cannot resolve hostname)
Hi, Part of the answer may be that Q4.2 switched from iptables to nftables and qubes-tunnel has not been adapted for this (However I am not sure whether this holds for fedora38 templates that were in-place upgrades from 4.1 to 4.2 or only for "native" 4.2 templates obtained from the server.): https://forum.qubes-os.org/t/can-t-get-the-qubesos-contrib-qubes-tunnel-to-work-in-4-2/22054 Anyways, using the openvpn command directly results in the same "cannot resolve" issue, even if qubes-tunnel service is not started. So I created a new AppVM (as ProxyVMs and NetVMs cannot be selected in Q4.2 "create Qube") that provides networking and followed Readme.md of https://github.com/1cho1ce/Qubes-vpn-support/tree/replace-iptables-with-nftables - I was asked for the credentials during install step and again during the setup step openvpn command and ping are successful now. After following the steps, no "LINK IS UP" popup appears. There is no service for any of the two names involved. Somewhere near the bottom of readme.md I find that confusingly the service name is qubes-vpn-handler. In its status I get: ExecStartPre=/usr/lib/qubes/qubes-vpn-setup --check-firewall (code=exited, status=1/FAILURE) If I run /usr/lib/qubes/qubes-vpn-setup --check-firewall manually, no output is shown. VPN troubleshooting still references iptables, which seems to not apply for Q 4.2 anymore https://www.qubes-os.org/doc/vpn-troubleshooting/ So what is wrong here? how can I make vpn leak-proof again with Qubes 4.2? On 1/7/24 22:49, r.wiesbach via qubes-users wrote: Hi, The forum post does not use qubes-tunnel and I do not use wireguard (but openVPN) - so I do not see how this post solves my issue?! On 1/6/24 12:06, code9n wrote: Hi, This is on the Forum: https://forum.qubes-os.org/t/wireguard-vpn-setup/19141 cheers, On Saturday 6 January 2024 at 00:16:40 UTC r.wie...@web.de wrote: Hi there, vpnVM and netVM both in-place upgrades from Q4.1 (and worked fine there). Template is fedora 38. NetVM is online, ping of vpn server hostname is fine within netVM. Ping and dig do not work within vpnVM, but afair that is intended (leak prevention of qubes-tunnel) I tried to restart qubes-tunnel servcie, tried to restart vpnVM. tried to disconnect and reconnect. I tried to reboot QubesOS. Did something change between 4.1 and 4.2 regarding DNS handling? Do I need to configure a policy file or something? 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/d4f11ed1-dcfe-45ef-b318-49b7416a6801n%40googlegroups.com <https://groups.google.com/d/msgid/qubes-users/d4f11ed1-dcfe-45ef-b318-49b7416a6801n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/e75483d0-c5bf-49c9-98e3-e1933d4fb320%40web.de <https://groups.google.com/d/msgid/qubes-users/e75483d0-c5bf-49c9-98e3-e1933d4fb320%40web.de?utm_medium=email&utm_source=footer>. -- 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/585fcc3c-c02a-4b71-b46b-f468a6c70517%40web.de.
Re: [qubes-users] Re: Qubes 4.2: qubes-tunnel not working after upgrade (cannot resolve hostname)
Hi, The forum post does not use qubes-tunnel and I do not use wireguard (but openVPN) - so I do not see how this post solves my issue?! On 1/6/24 12:06, code9n wrote: Hi, This is on the Forum: https://forum.qubes-os.org/t/wireguard-vpn-setup/19141 cheers, On Saturday 6 January 2024 at 00:16:40 UTC r.wie...@web.de wrote: Hi there, vpnVM and netVM both in-place upgrades from Q4.1 (and worked fine there). Template is fedora 38. NetVM is online, ping of vpn server hostname is fine within netVM. Ping and dig do not work within vpnVM, but afair that is intended (leak prevention of qubes-tunnel) I tried to restart qubes-tunnel servcie, tried to restart vpnVM. tried to disconnect and reconnect. I tried to reboot QubesOS. Did something change between 4.1 and 4.2 regarding DNS handling? Do I need to configure a policy file or something? 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/d4f11ed1-dcfe-45ef-b318-49b7416a6801n%40googlegroups.com <https://groups.google.com/d/msgid/qubes-users/d4f11ed1-dcfe-45ef-b318-49b7416a6801n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/e75483d0-c5bf-49c9-98e3-e1933d4fb320%40web.de.
[qubes-users] Qubes 4.2: qubes-tunnel not working after upgrade (cannot resolve hostname)
Hi there, vpnVM and netVM both in-place upgrades from Q4.1 (and worked fine there). Template is fedora 38. NetVM is online, ping of vpn server hostname is fine within netVM. Ping and dig do not work within vpnVM, but afair that is intended (leak prevention of qubes-tunnel) I tried to restart qubes-tunnel servcie, tried to restart vpnVM. tried to disconnect and reconnect. I tried to reboot QubesOS. Did something change between 4.1 and 4.2 regarding DNS handling? Do I need to configure a policy file or something? 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/4d75ac64-7f10-4744-a5a4-39e80172793a%40web.de.
[qubes-users] HCL - Framework 13 AMD Ryzen 7840U
Major issue is that the touchpad does not work.Suspend/wake does work fine.Have not tested much beyond the above.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/3A7D27BC-14B4-4CF4-916D-EF6E2B0BF009%40lamb.org. Qubes-HCL-Framework-Laptop_13__AMD_Ryzen_7040Series_-20231108-213610.yml Description: application/yaml Shigeru KAWAGUCHI LambEmail shig...@lamb.orgPhone +1-202-250-3811Mobile +1-202-949-0110Fax +1-202-380-3696Callsign KC3JNIGpg 6A28 3807 A60B FDB9 C67A FCDC 8B50 753B 28C6 4719 Address 12927 Kitchen House Way, Germantown, MD 20874 USAWebsite https://www.lamb.orgDeus vult ergo sumus If my people, among whome my Name is called vpon, do humble them felues, & praye, and feke my prefence, and turne from their wicked wayes, then wil I heare in heauen, and be merciful to their finne, and wil heale their land. – 2 Chronicles 7:14 [Geneva Bible 1560] The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. -- 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/3A7D27BC-14B4-4CF4-916D-EF6E2B0BF009%40lamb.org.
[qubes-users] HCL - Lenovo ThinkPad T480
Most features works flawlessly. I did not test suspend / sleep. -- 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/ZTTv5cvsscEXj1AC%40localhost. --- layout: 'hcl' type: 'Notebook' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: '2.0' remap: 'yes' brand: | LENOVO model: | 20L5CTO1WW bios: | N24ET44W (1.19 ) cpu: | Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz cpu-short: | FIXME chipset: | Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5914] (rev 08) chipset-short: | FIXME gpu: | Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Ethernet Connection (4) I219-LM [8086:15d7] (rev 21) Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78) memory: | 32647 scsi: | CT1000MX500SSD1 Rev: 043 usb: | 1 certified: 'no' versions: - works: 'FIXME:yes|no|partial' qubes: | R4.2.0-rc4 xen: | 4.17.2 kernel: | 6.1.57-1 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK
Re: [qubes-users] Re: Issue with "Qubes release 4.2.0-rc3" | USB Installation Media not detected in UEFI BIOS
I actually had a similar issue. It ended up being a BIOS that refused to detect rc3 is ISO format. Mounting the ISO and copying the files over to a FAT formatted USB got around the boot issue but the qubes installer doesn't see it's root partition then. The working solution was to insert both the FAT formatted USB and the ISO one (just burned using DD). That way there's an EFI partition for the UEFI to boot and a proper Qubes USB for the installer to use. Not pretty, but it worked. -- 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/acc6bbef-47be-4eb7-1d4c-5a2a93d77c25%40undef.tools.
[qubes-users] HCL - ThinkPad X1 Carbon Gen 10
Works out of the box: - networking (usb2lan) - keyboard backlight - build-in bluetooth - sound Works after tweaking: - sceen is flickering unless adding "i915.enable_psr=0" in /boot/efi/EFI/qubes/xen.cfg, more details: https://wiki.archlinux.org/title/intel_graphics#Screen_flickering - build-in wifi isn't working unless installing drivers in sys-net e.g. from here: github.com/q3aql/drivers-linux-firmware Haven't managed to get it working: - sleep / suspend - build-in camera -- 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/Nfl1cEf--B-9%40tuta.io. Qubes-HCL-LENOVO-21CB00B9GE-20231002-163736.yml Description: application/yaml
[qubes-users] slock issue
Hi guys, I recently tried to switch from i3lock to slock, but when I run 'sudo ./slock' (it needs suid/sgid) I get this error: slock: crypt: Invalid argument I installed libxcrypt-compat, which slock needed. It's supposed to be compatible with libcrypt(not found). journalctl -f only shows successes while running the command. I tried to remove i3lock in case of conflict, but i3-settings-qubes depends on it. I tried to compile slock without any patches, same error when running that. I managed to get it to run with the PAM_auth patch, which replaces the use of shadow, but I couldn't unlock slock with my password, so that doesn't really help me. Is there a trick to it or does it simply not work on Qubes/Fedora? Thanks in advance for any replies. -- 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/20230918110633.GA1188%40mail2-dvm.
[qubes-users] HCL - HP ZBook 17 G4
--- layout: 'hcl' type: 'notebook' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'unknown' remap: 'yes' brand: | HP model: | HP ZBook 17 G4 bios: | P70 Ver. 01.44 cpu: | Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz cpu-short: | FIXME chipset: | Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5910] (rev 05) chipset-short: | FIXME gpu: | Intel Corporation HD Graphics 630 [8086:591b] (rev 04) (prog-if 00 [VGA controller]) NVIDIA Corporation GM206GLM [Quadro M2200 Mobile] [10de:1436] (rev a1) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Ethernet Connection (2) I219-LM (rev 31) Intel Corporation Wireless 8265 / 8275 (rev 78) memory: | 16035 scsi: | SAMSUNG MZ7LN256 Rev: 1H3Q usb: | 1 versions: - works: 'FIXME:yes|no|partial' qubes: | R4.1 xen: | 4.14.6 kernel: | 6.4.7-1 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK --- I don't install driver of the graphic's card NVIDIA GM206GLM (Quadro M2200 Mobile) in Dom0 but it work fine in sys-gui-gpu with generic/proprietary drivers. Envoyé avec la messagerie sécurisée [Proton Mail.](https://proton.me/) -- 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/a72zLyL_11hF4aBQI7Db0VMECj06M8ZasHANUTAEj-YyHTFLf7fL63IvTCDODMe3xCew-0goy6F-DKXaZbZBmm_hI_UlhRBasUBikBXUcSI%3D%40protonmail.com.
Re: [qubes-users] split-ssh question
On Fri, Sep 08, 2023 at 08:10:44AM +0200, haaber wrote: > I tried to configure split-ssh according to the tutorial on qubes pages, > in its simple version (just agent, but no keepass integration). But now > ssh offers *all* my private keys to *all* servers, which is odd, but > more annoying, it usually breaks connections after 3 "false" public keys > ... > > Clearly, I did something wrong, but I do not understand well-enough what > I should change. Did some have/solve this problem already or have a > hint for me, please? Thank you! > I dont think you did anything wrong. I think what you are looking for is something like my split-ssh-agent - This allows you to have multiple keys, allocated as you will between different agents on the ssh back-end. >From each calling qube, you specify (in policy) what agent should be called, and this is passed through to the ssh back-end to serve up the appropriate keys. You can find it at https://github.com/unman/qubes-ssh-agent or a packaged version for easy installation at https://qubes.3isec.org/tasks.html If you dont use it, it should give you one idea of how you might go on. -- 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/ZP3nIme3BRQK%2BktD%40thirdeyesecurity.org.
Re: [qubes-users] Error installing Debian-12 template
+1 Same problem 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/d44e2700-5ba2-0cec-6725-3aad2ee3433d%40riseup.net.
Re: [qubes-users] saltstack: detect the os within a running target/state.sls
On Thu, Aug 24, 2023 at 11:26:30AM +0200, lik...@gmx.de wrote:
> Hi!
>
> Running grains['os'] in a target returns always "Fedora" and grains['id']
> returns "dom0". For this reason I cannot branch in my state files for
> different os templates.
> Executing this test in such a targeted state.sls:
>
> test-grains-for-choosing-the-right-template:
> test.configurable_test_state:
> - name: "grains test"
> - changes: True
> - result: True
> - comment: {{ grains['os'] ~ ", " ~ grains['id'] ~ ", " ~
> grains['osfullname'] ~ ", " ~ grains['os_family'] }}
>
> returns
> grains['os']=Fedora, grains['os']=dom0, grains['osfullname']=Qubes,
> grains['osfamily']=RedHat
>
> Any ideas why this happens? How to branch correctly in a state file depending
> on the os of the template?
>
> Best, P!
>
When you use qubesctl it acts in the following order - dom0, templates,
template based qube. Unless you specifically exclude dom0, the state
will be applied to dom0.
You havent said what command you entered, which would have been useful,
but my guess is that you used `qubesctl state.apply ...`
If you want to target a template, then you should use:
`qubesctl --skip-dom0 --targets=LIST_OF_TARGETS .`
If you want a state file to be used BOTH for dom0 and templates, you can
use a "defensive" approach - there are examples of this at
http://github.com/unman/shaker
Use a jinja block like - {% if grains['nodename'] != 'dom0' %}
This will ensure that non-dom0 stuff gets correctly applied, while
making sure that those parts of the state dont get applied to 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/ZOh%2Bxvf2ReSaLmeP%40thirdeyesecurity.org.
Re: [qubes-users] HCL - ASUS Vivobook X1503ZA
I had to disable both intel VDM and secure boot via UEFI/BIOS to make the installation start. Everything seems to work fine But: 1- wake from suspend is not working even after i followed the documentation's potential fix (screen stays blank until hard reset/shutdown) 2- TPM status is not found in the .yml, not sure if it's due to lack of TPM 2.0 support as i didn't test the TPM manually. I apologize as I have not included the .yml file in the first post so here it's in this post If any further information is needed please inform me Original Message On Aug 21, 2023, 2:02 PM, 'Gandalfen' via qubes-users - qubes-users at googlegroups.com wrote: > --- > layout: > 'hcl' > type: > 'notebook' > hvm: > 'yes' > iommu: > 'yes' > slat: > 'yes' > tpm: > 'unknown' > remap: > 'yes' > brand: | > ASUSTeK COMPUTER INC. > model: | > Vivobook_ASUSLaptop X1503ZA_X1503ZA > bios: | > X1503ZA.305 > cpu: | > 12th Gen Intel(R) Core(TM) i7-12700H > cpu-short: | > Intel i7-12700H > chipset: | > Intel Corporation Device [8086:4641] (rev 02) > chipset-short: | > Intel [8086:4641] (rev 02) > gpu: | > Intel Corporation Device [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) > > gpu-short: | > Intel Iris Xe Graphics > network: | > MEDIATEK Corp. Device 7961 > memory: | > 16076 > scsi: | > > usb: | > 1 > versions: > > - works: > 'partial' > qubes: | > R4.1 > xen: | > 4.14.5 > kernel: | > 6.4.7-1 > remark: | > Disabled secure boot and VMD in UEFI, Works but does not wake from suspend > credit: | > Gandalfin > link: | > FIXLINK > > --- > > -- > 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/169261574502.6.9546733988854435634.168624131%40simplelogin.com](https://groups.google.com/d/msgid/qubes-users/169261574502.6.9546733988854435634.168624131%40simplelogin.com?utm_medium=email&utm_source=footer). -- 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/169269292982.7.2257225405946807838.169076547%40simplelogin.com. Qubes-HCL-ASUSTeK_COMPUTER_INC_-Vivobook_ASUSLaptop_X1503ZA_X1503ZA-20230821-105329.yml Description: Binary data
[qubes-users] HCL - ASUS Vivobook X1503ZA
--- layout: 'hcl' type: 'notebook' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'unknown' remap: 'yes' brand: | ASUSTeK COMPUTER INC. model: | Vivobook_ASUSLaptop X1503ZA_X1503ZA bios: | X1503ZA.305 cpu: | 12th Gen Intel(R) Core(TM) i7-12700H cpu-short: | Intel i7-12700H chipset: | Intel Corporation Device [8086:4641] (rev 02) chipset-short: | Intel [8086:4641] (rev 02) gpu: | Intel Corporation Device [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) gpu-short: | Intel Iris Xe Graphics network: | MEDIATEK Corp. Device 7961 memory: | 16076 scsi: | usb: | 1 versions: - works: 'partial' qubes: | R4.1 xen: | 4.14.5 kernel: | 6.4.7-1 remark: | Disabled secure boot and VMD in UEFI, Works but does not wake from suspend credit: | Gandalfin link: | FIXLINK --- -- 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/169261574502.6.9546733988854435634.168624131%40simplelogin.com. Qubes-HCL-ASUSTeK_COMPUTER_INC_-Vivobook_ASUSLaptop_X1503ZA_X1503ZA-20230821-105329.cpio.gz Description: application/gzip
Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
On Thu, 2023-08-10 at 21:36 +, 51li...@ileg.al wrote: > Its interesting, since my amd legion is testing machine, i never use > sys-usb, and yeah i found that usb passthrough lead system to reboot. > can you provide a more detail about step by step what have you done ? > At install time untick the 'sysusb' creation, and then create sysusb by hand and attach just 1 USB controller at a time (following the instructions here https://www.qubes-os.org/doc/usb-qubes/#how-to-create-a-usb-qube-for-use-with-a-usb-keyboard) Another way to find out which device is causing the system to poweroff is to use any other VM (e.g. 'personal'), change it to HVM, and go to the devices tab in settings and try passing through one controller at a time, and make a note which one worked and which one didn't. If it works, power off the VM, remove the device from it and try the other ones in turn. If the machine gets instantly powered off instead then make a note about the broken device. I'll write some step-by-step examples once I got it working a bit more reliably, but for now the next device that is misbehaving sometimes is the network card: 0e:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter Sometimes it just keeps printing messages that it is waiting after FLR, and the boot doesn't actually finish (or maybe I didn't wait long enough, I gave up after half a minute after it has printed a few retry messages about FLR). Other times it works reliably (it seems to misbehave if I boot into Qubes directly after the machine has been powered off, but seems to work if I first boot into native Fedora and then reboot into Qubes). Best regards, --Edwin -- 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/bc0382033f36b0bc7ed70d6cd3bc17cb7d6383de.camel%40etorok.net.
Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
On Wed, 2023-08-09 at 20:53 +0100, Edwin Török wrote: > On Mon, 2023-08-07 at 21:45 +0100, 'Edwin Török' via qubes-users > wrote: > > > > Must NOT use a USB qube. Using a USB qube results in an > > instant > > host reboot as soon as the USB qube is booted (same issue happen on > > KVM > > when attempting to pass through any USB controller, even if the > > controller is in an IOMMU group of its own). There is a newer BIOS > > with > > newer AGESA available, I'll have to retry using that. Using > > permissive > > mode or non-strict PCI reset doesn't help: > > New BIOS doesn't help, but I found one source of the host reboot: bus > reset of the USB3 controller PCI device. > > /sys/bus/pci/devices/:13:00.0/reset_method has 'bus', > and its parent /sys/bus/pci/devices/:00:08.3/reset_method has > 'pm'. > No FLR on these (which is confirmed by 'lspci' it says FLReset-). > > Changing 'bus' to 'pm', and performing an unbind from > /sys/bus/pci/drivers/xhci_hcd, and then echoing '1' to 'reset' seems > to > survive and it no longer causes the system to power off. > (now I don't know whether the problem is with reseting the device, or > resetting the parent's secondary bus, IIUC even if parent device's > reset method is pm, secondary bus will still be reset if that is what > the child does). > > Note that all the other USB controller's reset_method is already > 'pm'. > > All but one USB controller is in D3hot (which is expected), the other > is D0. Is a bus reset of a device in D3hot even valid? I tried plugging a USB device in the controller so it went to D0 and changes reset method to pm on its own, but that didn't help. However I found out that I *can* pass-through 2/4 USB controllers, these ones are safe to pass through: ``` +-02.1-[06-10]00.0-[07-10]--+-00.0-[08]-- | +-0c.0-[0f]00.0 Advanced Micro Devices, Inc. [AMD] Device [1022:43f7] +-08.1-[12]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] |+-00.3 Advanced Micro Devices, Inc. [AMD] Device [1022:15b6] ``` These ones are NOT safe to pass through, they result in instant power off of the host, followed by a poweron couple of seconds later: ``` +-08.1-[12]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] |+-00.4 Advanced Micro Devices, Inc. [AMD] Device [1022:15b7] +-08.3-[13]00.0 Advanced Micro Devices, Inc. [AMD] Device [1022:15b8] ``` This is very weird because 12.03 and 12.04 are quite similar from a topology point of view. I'm not sure what Qubes could do to detect or avoid this situation, but perhaps just hiding the USB controllers that are in D3hot instead of passing them through is the safer option? But even that becomes unsafe if I plug a USB device into 12.04. Anyway I have a workaround now to at least pass some of my USB devices through, and I have my Yubikey working in my 'vault' VM. Best regards, --Edwin > > Although changing the 'reset_method' still doesn't make device pass- > through work: attempting to pass it through still causes a host > reboot > (although more like a poweroff followed by a powerup than a warm > reboot, I tried disabling various options in the BIOS but it still > powers off directly, e.g. the PSP/SMU debug mode appeared promising > but > didn't help). > > Best regards, > --Edwin -- 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/f88f1793125271923f2b884139d3a336a608599b.camel%40etorok.net.
Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
On Mon, 2023-08-07 at 21:45 +0100, 'Edwin Török' via qubes-users wrote: > > Must NOT use a USB qube. Using a USB qube results in an instant > host reboot as soon as the USB qube is booted (same issue happen on > KVM > when attempting to pass through any USB controller, even if the > controller is in an IOMMU group of its own). There is a newer BIOS > with > newer AGESA available, I'll have to retry using that. Using > permissive > mode or non-strict PCI reset doesn't help: New BIOS doesn't help, but I found one source of the host reboot: bus reset of the USB3 controller PCI device. /sys/bus/pci/devices/:13:00.0/reset_method has 'bus', and its parent /sys/bus/pci/devices/:00:08.3/reset_method has 'pm'. No FLR on these (which is confirmed by 'lspci' it says FLReset-). Changing 'bus' to 'pm', and performing an unbind from /sys/bus/pci/drivers/xhci_hcd, and then echoing '1' to 'reset' seems to survive and it no longer causes the system to power off. (now I don't know whether the problem is with reseting the device, or resetting the parent's secondary bus, IIUC even if parent device's reset method is pm, secondary bus will still be reset if that is what the child does). Note that all the other USB controller's reset_method is already 'pm'. All but one USB controller is in D3hot (which is expected), the other is D0. Is a bus reset of a device in D3hot even valid? Although changing the 'reset_method' still doesn't make device pass- through work: attempting to pass it through still causes a host reboot (although more like a poweroff followed by a powerup than a warm reboot, I tried disabling various options in the BIOS but it still powers off directly, e.g. the PSP/SMU debug mode appeared promising but didn't help). Best regards, --Edwin -- 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/f7cc0221505a19385893017a4d04800607e02802.camel%40etorok.net.
[qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 48 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Vendor ID: AuthenticAMD Model name: AMD Ryzen 9 7950X 16-Core Processor CPU family: 25 Model: 97 Thread(s) per core: 2 Core(s) per socket: 16 Socket(s): 1 Stepping: 2 Frequency boost: enabled CPU(s) scaling MHz: 52% CPU max MHz: 5879.8818 CPU min MHz: 3000. BogoMIPS: 8999.60 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext f xsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmul qdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr 8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc m waitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xs aveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local avx512_bf16 clzero irperf xsaveerptr rdpr u wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnn i avx512_bitalg avx512_vpopcntdq rdpid overflow_recov succor smca fsrm flush_l1d Virtualization features: Virtualization: AMD-V Caches (sum of all): L1d: 512 KiB (16 instances) L1i: 512 KiB (16 instances) L2: 16 MiB (16 instances) L3: 64 MiB (2 instances) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-31 Vulnerabilities: Itlb multihit: Not affected L1tf: Not affected Mds: Not affected Meltdown: Not affected Mmio stale data: Not affected Retbleed: Not affected Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Spectre v2: Mitigation; Enhanced / Automatic IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS Not affected Srbds: Not affected Tsx async abort: Not affected edwin ~ [4.14.1] ❯ cat /mnt/home/edwin/Qubes-HCL- Gigabyte_Technology_Co___Ltd_-B650E_AORUS_MASTER-20230807-162029.yml --- layout: 'hcl' type: 'Desktop' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: '2.0' remap: 'yes' brand: | Gigabyte Technology Co., Ltd. model: | B650E AORUS MASTER bios: | F3c cpu: | AMD Ryzen 9 7950X 16-Core Processor cpu-short: | FIXME chipset: | Advanced Micro Devices, Inc. [AMD] Device [1022:14d8] chipset-short: | FIXME gpu: | Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c0) (prog-if 00 [VGA controller]) Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c1) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 01) MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:0616] 0616] memory: | 64663 scsi: | SanDisk SDSSDXPS Rev: 00RL TOSHIBA MG09ACA1 Rev: 0104 TOSHIBA HDWD130 Rev: ACF0 usb: | 4 certified: 'no' versions: - works: 'partial' qubes: | 4.2.0-alpha xen: | 4.17.1 kernel: | 6.1.35-1 remark: | Must create a GPT partition table on the boot media with 'gdisk', see https://github.com/QubesOS/qubes-issues/issues/8395 Must ensure that installation target is NOT 4Kn, had to reformat NVME namespace to 512 byte, see https://github.com/QubesOS/qubes-issues/issues/7398#issuecomment-1668545707 Must enable IOMMU in BIOS (default is Auto which doesn't work. Enable it under 'Misc settings and AMD CBS -> NBIO settings'). Must NOT use a USB qube. Using a USB qube results in an instant host reboot as soon as the USB qube is booted (same issue happen on KVM when attempting to pass through any USB controller, e
[qubes-users] How to use lvms from a disk with a valid Qubes installation as qubes in another Qubes pc?
In my desktop Qubes system the mainboard died. So I bought a new one. Unfortunately I didn't make a backup for some days. After building the new hardware system my Qubes installation from the old ssd doesn't start there. (Somehow the system freezes or at least the keyboard is being switched off just before I have to input the disk password.) So I created a new Qubes installation on an USB stick, which works quite well in the new system (both are Qubes 4.1.) Running this new installation I can still access my old ssd. I see all the lvms from my old installation (I have around 100 qubes, so about 250 lvms). I can rename the vg, activate and mount each lvm and access all data. But I cannot use the lvms as qubes. They don't appear with qvm-ls. How can I make use of these lvms? I want to have them recognized as qubes. Then I want to make a full Qubes backup off all my cubes. And after a new Qubes installation I want to restore them. I could backup the lvms in a non Qubes way. But then again I would have the problem to make them known as qubes to my new system. I read all the documentation, especially "How to back up, restore, and migrate", "How to mount a Qubes partition from another OS" and "Secondary storage". But this didn't answer my questions. I can access the data but I cannot use the old qubes as qubes in a new system. How can this be accomplished? Any help is highly appreciated. - Qru -- 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/L4jvIaUKh4b4L-Jz8fii1D1PAfMri9aqTOBCwTdg5AMscbTZd_k3d-3VeLWVwegpSiD4np5-8IwsyME3E_ceCAX3gUBcBG3bbpbCrYVPScY%3D%40proton.me.
Re: [qubes-users] QubesIncoming folder in /tmp ??
On Fri, Jun 30, 2023 at 12:27:41PM +0200, haaber wrote: > Hi I was wondering if it would not me preferable (at least in some VM's) > to delocalise the QubesIncoming folder in /tmp to have it "cleaned up" > regularly. It's a pain to do so manually. Is there a problem doing so ? > What would be the cleanest way to do it? A symlink ?? thank you, Bernhard > I use this in rc.local: ``` mkdir /home/user/QubesIncoming chown user:user /home/user/QubesIncoming mkdir /tmp/QubesIncoming chown user:user /tmp/QubesIncoming mount --bind /tmp/QubesIncoming /home/user/QubesIncoming ``` I dont think the chown calls are needed, but I put them in , and have not removed them. Works as you would expect. -- 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/ZJ9%2B%2BrugSSu6AW6W%40thirdeyesecurity.org.
Re: [qubes-users] Re: ssh-split issue
On 21/06/2023 11:49, haaber wrote: >> We observe that the file /run/user/1000/openssh_agent is different >> from/home/user/.SSH_AGENT_sshkeys. That may be a problem. Running the following command in the work qube should work: SSH_AUTH_SOCK=/home/user/.SSH_AGENT_vault ssh-add -L You seem to be running the "ssh-agent.service" in your work qube. This is not part of the linked setup guide. There only one agent is running and that is in the vault qube. The "clients" (e.g. work qube) only redirect the communication via socat, qubes RPC and the /home/user/.SSH_AGENT_vault file to the ssh-agent in the vault qube. See: https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/split-ssh.md#in-the-appvm-ssh-client -- 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/6ac70fb1-8854-7d38-a9ca-1f13c487736a%40xafy.de.
Re: [qubes-users] How to make sys-firewall broadcast a local qube as the system-wide DNS server?
On Tue, Jun 06, 2023 at 01:24:18PM -0500, Leo28C wrote: > I managed to set up a pi-hole qube and make it my network's DNS > filtering/caching server. Ironically, it works flawlessly across my network > EXCEPT it completely breaks DNS for all other qubes in the same system. On > Debian-based qubes I figured out I can simply edit /etc/resolv.conf, while > making sure sys-firewall lets the two qubes talk to each other, as a > workaround. However this is a hacky per-qube solution and doesn't persist > across qube restarts. It would be nice to simply have sys-firewall relay > the information to all of its client qubes automatically. Any idea how to > do this? > > Thanks in advance! > You dont need to change the settings per qube at all. You haven't said *where* the pi-hole qube is located in your qubes network, or what the nature of the breakage is. I assume from what you say it is attached to sys-firewall. You can do this by editing the PR-QBS chain in nat table in sys-firewall. By default, this forwards all DNS traffic to 10.139.1.1 and 10.139.1.2 using dnat. Flush that chain and replace it with dnat rules to the IP address of your Pi-hole qube. You could do this in /rw/config/qubes-firewall-user-script or by script in /rw/config/qubes-firewall.d -- 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/ZIHekYeyI0BY5uUa%40thirdeyesecurity.org.
[qubes-users] Re: HCL - cirrus7 nimbini v3 (NUC12WSHv5)
After more than a week of intensive use, I haven't noticed any problems so far. The "cirrus7 nimbini v3" (or presumably all NUC12WSHv5) seemed to be suitable hardware for anyone who wants to use QubesOS as a desktop system. Do I still have to submit something to be included in the HCl or do I just need some more patience ;-) Kind regards from an enthusiastic QubesOS fan :) --- Original Message --- On Wednesday, May 24th, 2023 at 11:51 PM, sonnenfinsternis wrote: > Here's my review of the cirrus7 nimbini v3, which is largely based on the > Intel NUC 12 (NUC12WSHv5). QubesOS with the "kernel latest" option runs > great. Most importantly, it is a dream to work on a fanless computer that > still runs completely silent under heavy load despite various Qubes running > in parallel including several standalone machines. > > Best regards :-) > Eichennarr > > --- > layout: > 'hcl' > type: > 'mini pc' > hvm: > 'yes' > iommu: > 'yes' > slat: > 'yes' > tpm: > 'unknown' > remap: > 'yes' > brand: | > cirrus7 > model: | > nimbini v3 (NUC12WSHv5) > bios: | > WSADLV57.0087.2023.0306.1817 > cpu: | > 12th Gen Intel(R) Core(TM) i5-1250P > cpu-short: | > i5-1250P > chipset: | > Intel Corporation Device [8086:4621] (rev 02) > chipset-short: | > FIXME > gpu: | > Intel Iris Xe 80U > gpu-short: | > FIXME > network: | > Intel Wi-Fi 6E AX211 > memory: | > 65092 > scsi: | > > usb: | > 4 > versions: > > - works: > yes > qubes: | > R4.1 > xen: | > 4.14.5 > kernel: | > 6.1.12-1 > remark: | > works with kernel latest > credit: | > Eichennarr > link: | > FIXLINK > > --- -- 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/jdzlEY6whbd2mfjTslSTwrq9NFcuQe5iweTJ11-aXUIhbawrYTef9-HKmubZfhh9V235fPH_gfc4u1zBHeCuTOTL1W1ZfVs1-sNuD_qRdZs%3D%40protonmail.ch.
[qubes-users] HCL report motherboard MSI MEG x670e ACE
Here is my HCL report for the motherboard MSI MEG x670e ACE. Booting even the installer works only with the x2apic=false flag set in both xen and linux lines in grub. Automatic creation of networking related qubes (sys-firewall and sys-net) during first configuration after install crashes the pc. Displayport is working, video seems to be working at least from an initial test. Usb devices work and attach successfully to qubes. Creation of new qubes works. Will have to attempt to manually create networking qubes and report back. I should also note that the motherboard is running a beta bios version due to a problem with vsoc voltage being set too high and not properly capped leading sometimes to frying 7000 series cpus with expo profiles enabled. Best regards, rickyjumb -- 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/168569294942.7.16578028694072641953.136828018%40simplelogin.com. Qubes-HCL-Micro_Star_International_Co___Ltd_-MS_7D69-20230602-065754.yml Description: application/yaml
Re: [qubes-users] Trying my luck
Ulrich Windl (Google) wrote: Just wondering: Is the remote end Windows, and could some virus scanner block the rename request? You know Windows has kind of strange locking rules. No the SMB server is running on OmniOS which is Illumos 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/c50703f7-a6ae-b659-a618-cbb5ccdf905e%40ak47.co.za.
Re: [qubes-users] Trying my luck
Qubes wrote:
Qubes wrote:
I am just trying my luck here with an issue that i have been unable to
resolve on my Qubes system for a long time now. I have been looking
into this problem quite a bit but i cannot seem to find a solution
anywhere. Perhaps someone on this list has experienced the same and
has found a solution.
When i open a text file that is located on a network share with gedit,
gedit is unable to save the file. When I click the save button, or
`Ctrl + s`, i can see gedit creates a temporary file named
".goutputstream-AO9U51" on the network share and in gedit i get a
message "Could not create a backup file while saving
"/home/user/data/test/file-name.txt"". If i launch gedit from cli i
see a message on cli when saving the file "Hit unhandled case 27
(Error renaming temporary file: Resource temporarily unavailable) in
parse_error."
I definitely have permissions on the network share as i can copy files
to it, delete, create directories, etc. I can also open a LibreOffice
document and save it. The problem appears to be specific to gedit.
Also, it happens with both a Fedora and Debian based VM.
In addition that i forgot to mention is, i can open edit and save the
same txt files with vi and it works.
I have read reports [1][2][3][4][6] dating as far back as 12 years with
the sshfs protocol (an abandoned project) being implicated as well.
On issue 438 [3] that was reported on Gitlab it is reported that "As far
as I can tell, the problem is in the way glib saves a file by writing to
a temporary file and renaming to the final name." and "I'll take a more
serious look later but I'd start with gio/glocalfileoutputstream.c and
particularly the function _g_local_file_output_stream_really_close which
contains the error string "Error renaming temporary file".".
A duplicate issue 565 [5] to issue 438 [3] was opened and there a patch
is provided that is said to fix this issue although i have not tried it
because i don't know how to.
**Question:** Would anybody perhaps know how and where to do the patch,
attached for reference, on Fedora/Debian. As far as I can tell the patch
needs to be done on the client since the problem originates from the client.
[1]:
https://askubuntu.com/questions/13843/gedit-sshfs-wont-save-vi-saves-fine
[2]:
https://unix.stackexchange.com/questions/52951/gedit-wont-save-a-file-on-a-virtualbox-share-text-file-busy
[3]: https://gitlab.gnome.org/GNOME/glib/-/issues/438
[4]: https://github.com/rclone/rclone/issues/2130
[5]: https://gitlab.gnome.org/GNOME/glib/-/issues/565
[6]:
https://illumos.topicbox.com/groups/omnios-discuss/Tc4c6b72d6386f9fb/resource-temporarily-unavailable-when-saving-to-cifs-share-on-r151038
--
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/41c6de8b-c200-0178-9cd9-c06809f94bfa%40ak47.co.za.
From 179812d0847af191e709539041a57d5779d847ed Mon Sep 17 00:00:00 2001
From: TW
Date: Wed, 27 Jun 2012 19:35:33 +0200
Subject: [PATCH] gio: workaround for renaming files on filesystems not
supporting it
This is a workaround for samba and "Virtual Box shared" filesystem which does not support renaming opened files and react on such attempt with ETXTBSY. It is also a solution proposal for:
Bug 678994 - Unable to overwrite files on vbox shared mounted filesystems
---
gio/glocalfileoutputstream.c | 90 +++-
1 file changed, 63 insertions(+), 27 deletions(-)
diff --git a/gio/glocalfileoutputstream.c b/gio/glocalfileoutputstream.c
index a310fcd..60e5f43 100644
--- a/gio/glocalfileoutputstream.c
+++ b/gio/glocalfileoutputstream.c
@@ -223,6 +223,7 @@ _g_local_file_output_stream_really_close (GLocalFileOutputStream *file,
{
GLocalFileStat final_stat;
int res;
+ int smb_cifs_rename_workaround = 0;
#ifdef HAVE_FSYNC
if (file->priv->sync_on_close &&
@@ -318,17 +319,44 @@ _g_local_file_output_stream_really_close (GLocalFileOutputStream *file,
if (g_cancellable_set_error_if_cancelled (cancellable, error))
goto err_out;
- /* tmp -> original */
- if (g_rename (file->priv->tmp_filename, file->priv->original_filename) != 0)
- {
- int errsv = errno;
- g_set_error (error, G_IO_ERROR,
- g_io_error_from_errno (errsv),
- _("Error renaming temporary file: %s"),
- g_strerror (errsv));
- goto err_out;
- }
+ res = g_rename (file->priv->tmp_filename, file->priv->original_filename);
+
+ /* tmp -> original */
+ if (res != 0 && errno == ETXTBSY)
+ {
+ // try to close the fd firs
Re: [qubes-users] Trying my luck
Qubes wrote: I am just trying my luck here with an issue that i have been unable to resolve on my Qubes system for a long time now. I have been looking into this problem quite a bit but i cannot seem to find a solution anywhere. Perhaps someone on this list has experienced the same and has found a solution. When i open a text file that is located on a network share with gedit, gedit is unable to save the file. When I click the save button, or `Ctrl + s`, i can see gedit creates a temporary file named ".goutputstream-AO9U51" on the network share and in gedit i get a message "Could not create a backup file while saving "/home/user/data/test/file-name.txt"". If i launch gedit from cli i see a message on cli when saving the file "Hit unhandled case 27 (Error renaming temporary file: Resource temporarily unavailable) in parse_error." I definitely have permissions on the network share as i can copy files to it, delete, create directories, etc. I can also open a LibreOffice document and save it. The problem appears to be specific to gedit. Also, it happens with both a Fedora and Debian based VM. In addition that i forgot to mention is, i can open edit and save the same txt files with vi and it works. -- 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/55f71abc-061c-b3a5-c94a-f909aeaa3416%40ak47.co.za.
[qubes-users] Trying my luck
I am just trying my luck here with an issue that i have been unable to resolve on my Qubes system for a long time now. I have been looking into this problem quite a bit but i cannot seem to find a solution anywhere. Perhaps someone on this list has experienced the same and has found a solution. When i open a text file that is located on a network share with gedit, gedit is unable to save the file. When I click the save button, or `Ctrl + s`, i can see gedit creates a temporary file named ".goutputstream-AO9U51" on the network share and in gedit i get a message "Could not create a backup file while saving "/home/user/data/test/file-name.txt"". If i launch gedit from cli i see a message on cli when saving the file "Hit unhandled case 27 (Error renaming temporary file: Resource temporarily unavailable) in parse_error." I definitely have permissions on the network share as i can copy files to it, delete, create directories, etc. I can also open a LibreOffice document and save it. The problem appears to be specific to gedit. Also, it happens with both a Fedora and Debian based 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/768240c6-a0f9-387c-3d4d-67847e4dec4e%40ak47.co.za.
Re: [qubes-users] Re: Beginner questions
--- Original Message --- On Friday, May 26th, 2023 at 4:24 AM, 'Stuart Perkins' via qubes-users wrote: > Bottom post is the standard on this list. See my response at the bottom... :) > > On Thu, 25 May 2023 19:02:23 + > "'sonnenfinsternis' via qubes-users" qubes-users@googlegroups.com wrote: > > > Sounds helpful, I'll try it when I get a chance, thanks :) After reading > > this [1], I can now even use my USB mouse directly after booting, without > > having to assign it to dom0 first. So slowly but surely I'm warming up to > > QubesOS. A wonderful system :) Now if I can just find a way to see how much > > processor load and memory is currently being used globally, I'll have all > > the pressing open construction sites taken care of for the time being. Over > > the weekend I will switch to a QubesOS installation as my new device for > > daily use. I am excited and glad that this project exists with this great > > community :) > > > > 1: https://www.qubes-os.org/doc/usb-qubes/#usb-mice > > > > --- Original Message --- > > On Thursday, May 25th, 2023 at 8:39 AM, haaber haa...@web.de wrote: > > > > > Hi > > > > > > > 5) The question about autocomplete in the terminal has been resolved. > > > > This was indeed not due to QubesOS but to the fact that > > > > > > the bash-completion package is not pre-installed by default in Debian. > > > But this can be easily fixed: > > > https://unix.stackexchange.com/questions/312456/debian-apt-not-apt-get-autocompletion-not-working > > > > > > I have a nice working auto-complete for dom0. It allows usual > > > qvm-commands (qvm-start, qvm-stop, etc) in dom0 terminal and > > > distinguishes between running and non-running VM's according to what the > > > command expects. Like: qvm-shutdown [TAB] proposes only running VM's to > > > be shut down. etc. > > > > > > Works like charm since qubes 3.2. You find the code attached. > > > > > > Bernhard > > > > > > -- > > > 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/023ce574-96ab-7f94-21d6-4726c1801ce1%40web.de. > > > Welcome to Qubes OS. Personally, I love it. Even with the occasional awkward > way of doing something which is "point and click" on other OS's. The added > security of separation of programs and data plus template based VM's is > great. I've been a Qubes OS fan since 3.2. Add in a coreboot'd platform and > it is about the most secure PC available on the planet. A friend of mine who > built me such a laptop...2 actually (Lenovo T520 and a T420) was asked by the > country of Spain to build them 40. He has since dropped off the radar for > some reason. My current platform is marginally Qubes compatible...a Lenovo > W540...with no SSD it is very slow to come up, but works well once running. I > don't believe it can be coreboot'd though, so I will be creating another T420 > for daily use. I am limited to pre "blob" architectures if I want coreboot > with no "blobs"...encrypted microcode "black box" portions of the BIOS, but > that is really separate from Qubes OS. I actually wore out the T520 and > previous T420 I had...but mine is "on" 16 hours a day or more...sometimes I > just leave it on when I go to bed...that is not really a surprise. > > I found myself synthesizing the basic concept of template VM's manually with > VirtualBox before I discovered Qubes. > > In a Dom0 terminal, the command "xentop" will list running qubes and the > resources they are consuming. It is a faster refresh than the GUI Qube > Manager. > > Stuart > 42 years in IT. > > -- > 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/20230525222440.694ef12c%40yahoo.com. Oh, I overlooked that. I will from now on also always answer below 0:-) I did not know "xentop" yet, thanks. I had given up looking in the dom0
Re: [qubes-users] Re: Beginner questions
Bottom post is the standard on this list. See my response at the bottom... :) On Thu, 25 May 2023 19:02:23 + "'sonnenfinsternis' via qubes-users" wrote: >Sounds helpful, I'll try it when I get a chance, thanks :) After reading this >[1], I can now even use my USB mouse directly after booting, without having to >assign it to dom0 first. So slowly but surely I'm warming up to QubesOS. A >wonderful system :) Now if I can just find a way to see how much processor >load and memory is currently being used globally, I'll have all the pressing >open construction sites taken care of for the time being. Over the weekend I >will switch to a QubesOS installation as my new device for daily use. I am >excited and glad that this project exists with this great community :) > >1: https://www.qubes-os.org/doc/usb-qubes/#usb-mice > >--- Original Message --- >On Thursday, May 25th, 2023 at 8:39 AM, haaber wrote: > > >> Hi >> >> > 5) The question about autocomplete in the terminal has been resolved. This >> > was indeed not due to QubesOS but to the fact that >> >> the bash-completion package is not pre-installed by default in Debian. >> But this can be easily fixed: >> https://unix.stackexchange.com/questions/312456/debian-apt-not-apt-get-autocompletion-not-working >> >> I have a nice working auto-complete for dom0. It allows usual >> qvm-commands (qvm-start, qvm-stop, etc) in dom0 terminal and >> distinguishes between running and non-running VM's according to what the >> command expects. Like: qvm-shutdown [TAB] proposes only running VM's to >> be shut down. etc. >> >> Works like charm since qubes 3.2. You find the code attached. >> >> Bernhard >> >> -- >> 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/023ce574-96ab-7f94-21d6-4726c1801ce1%40web.de. >> > Welcome to Qubes OS. Personally, I love it. Even with the occasional awkward way of doing something which is "point and click" on other OS's. The added security of separation of programs and data plus template based VM's is great. I've been a Qubes OS fan since 3.2. Add in a coreboot'd platform and it is about the most secure PC available on the planet. A friend of mine who built me such a laptop...2 actually (Lenovo T520 and a T420) was asked by the country of Spain to build them 40. He has since dropped off the radar for some reason. My current platform is marginally Qubes compatible...a Lenovo W540...with no SSD it is very slow to come up, but works well once running. I don't believe it can be coreboot'd though, so I will be creating another T420 for daily use. I am limited to pre "blob" architectures if I want coreboot with no "blobs"...encrypted microcode "black box" portions of the BIOS, but that is really separate from Qubes OS. I actually wore out the T520 and previous T420 I had...but mine is "on" 16 hours a day or more...sometimes I just leave it on when I go to bed...that is not really a surprise. I found myself synthesizing the basic concept of template VM's manually with VirtualBox before I discovered Qubes. In a Dom0 terminal, the command "xentop" will list running qubes and the resources they are consuming. It is a faster refresh than the GUI Qube Manager. Stuart 42 years in IT. -- 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/20230525222440.694ef12c%40yahoo.com.
Re: [qubes-users] Re: Beginner questions
Sounds helpful, I'll try it when I get a chance, thanks :) After reading this [1], I can now even use my USB mouse directly after booting, without having to assign it to dom0 first. So slowly but surely I'm warming up to QubesOS. A wonderful system :) Now if I can just find a way to see how much processor load and memory is currently being used globally, I'll have all the pressing open construction sites taken care of for the time being. Over the weekend I will switch to a QubesOS installation as my new device for daily use. I am excited and glad that this project exists with this great community :) 1: https://www.qubes-os.org/doc/usb-qubes/#usb-mice --- Original Message --- On Thursday, May 25th, 2023 at 8:39 AM, haaber wrote: > Hi > > > 5) The question about autocomplete in the terminal has been resolved. This > > was indeed not due to QubesOS but to the fact that > > the bash-completion package is not pre-installed by default in Debian. > But this can be easily fixed: > https://unix.stackexchange.com/questions/312456/debian-apt-not-apt-get-autocompletion-not-working > > I have a nice working auto-complete for dom0. It allows usual > qvm-commands (qvm-start, qvm-stop, etc) in dom0 terminal and > distinguishes between running and non-running VM's according to what the > command expects. Like: qvm-shutdown [TAB] proposes only running VM's to > be shut down. etc. > > Works like charm since qubes 3.2. You find the code attached. > > Bernhard > > -- > 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/023ce574-96ab-7f94-21d6-4726c1801ce1%40web.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/ghDIY56OTqypK0u10MIiEMqaI9sDzcAVb7In4BOJ2wboKq5kLQ0P8ityQD6dRGulKYEpDWCIM_75cIoF5GHhPdqeWCrSJd5mcE1rbYcGuzc%3D%40protonmail.ch.
[qubes-users] Re: HCL - cirrus7 nimbini v3 (NUC12WSHv5)
I forgot to attach the yml file. Sorry! --- Original Message --- On Wednesday, May 24th, 2023 at 11:51 PM, sonnenfinsternis wrote: > Here's my review of the cirrus7 nimbini v3, which is largely based on the > Intel NUC 12 (NUC12WSHv5). QubesOS with the "kernel latest" option runs > great. Most importantly, it is a dream to work on a fanless computer that > still runs completely silent under heavy load despite various Qubes running > in parallel including several standalone machines. > > Best regards :-) > Eichennarr > > --- > layout: > 'hcl' > type: > 'mini pc' > hvm: > 'yes' > iommu: > 'yes' > slat: > 'yes' > tpm: > 'unknown' > remap: > 'yes' > brand: | > cirrus7 > model: | > nimbini v3 (NUC12WSHv5) > bios: | > WSADLV57.0087.2023.0306.1817 > cpu: | > 12th Gen Intel(R) Core(TM) i5-1250P > cpu-short: | > i5-1250P > chipset: | > Intel Corporation Device [8086:4621] (rev 02) > chipset-short: | > FIXME > gpu: | > Intel Iris Xe 80U > gpu-short: | > FIXME > network: | > Intel Wi-Fi 6E AX211 > memory: | > 65092 > scsi: | > > usb: | > 4 > versions: > > - works: > yes > qubes: | > R4.1 > xen: | > 4.14.5 > kernel: | > 6.1.12-1 > remark: | > works with kernel latest > credit: | > Eichennarr > link: | > FIXLINK > > --- -- 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/oGEvIb__nU8T7im80hRH0HyuAK5o-E7gxP6Ex0LnkhL0NaK2u16YAxlts8SdTbDGpKSXFkH3l8BFpybf3hCT6g7N29iLgFZX81pK33-qnBc%3D%40protonmail.ch. Qubes-HCL-Intel_R__Client_Systems-NUC12WSHv5-20230524-223156.yml Description: application/yaml
[qubes-users] HCL - cirrus7 nimbini v3 (NUC12WSHv5)
Here's my review of the cirrus7 nimbini v3, which is largely based on the Intel NUC 12 (NUC12WSHv5). QubesOS with the "kernel latest" option runs great. Most importantly, it is a dream to work on a fanless computer that still runs completely silent under heavy load despite various Qubes running in parallel including several standalone machines. Best regards :-) Eichennarr --- layout: 'hcl' type: 'mini pc' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'unknown' remap: 'yes' brand: | cirrus7 model: | nimbini v3 (NUC12WSHv5) bios: | WSADLV57.0087.2023.0306.1817 cpu: | 12th Gen Intel(R) Core(TM) i5-1250P cpu-short: | i5-1250P chipset: | Intel Corporation Device [8086:4621] (rev 02) chipset-short: | FIXME gpu: | Intel Iris Xe 80U gpu-short: | FIXME network: | Intel Wi-Fi 6E AX211 memory: | 65092 scsi: | usb: | 4 versions: - works: yes qubes: | R4.1 xen: | 4.14.5 kernel: | 6.1.12-1 remark: | works with kernel latest credit: | Eichennarr link: | FIXLINK --- -- 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/Q_i_As0bHmEZamFHxeUPHXSib7W3-W1TNAmwfB98J79p1NznD73wi27Q9bFxOhLI_6ougZkvC3YkNJgA5O2A0NaJrV7aaEr48JLN_1Gu8g4%3D%40protonmail.ch.
Re: [qubes-users] HCL - TUXEDO InfinityBook S 15 Gen7
Thanks for quickly adding my data to the list :-) --- Original Message --- On Thursday, May 11th, 2023 at 2:32 AM, Sven Semmler wrote: > Thank you Eichennarr for your HCL report, which is online now! > > /Sven > > -- > https://keys.openpgp.org/vks/v1/by-fingerprint/DA5975C9ABC40C833B2F620B2A632C537D744BC7 > > -- > 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/c9d56257-3daf-7656-2e0c-325c94f9ff26%40SvenSemmler.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/8UJOjuL2wsgemPxZnojoDE-C0eNb9XGXXLPRC3EugUV0uJ78PppNs9QAhUPnNvbnXE__l20Wwj5h8Dkd_JRGLQGIFccfAxdEwn_ST-BCbAo%3D%40protonmail.ch.
