Re: [qubes-users] Will AEM work with UEFI boot (A.K.A. GPT)?
GRUB or GRUB2? Probably seems trivial but avoiding ambiguity makes things simpler. :-) A question I have to go along with this is what boot loader will the OS installer give me with CSM disabled? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0QPFXz8scCBo9EReAzZ2GL1k9Zxq8guoed_1jIN3u0T2a0MC4iafQc62bJQuNd51sSoGC3lzV7roDXcNFc4YzsECVy6v982Xd1htV7jsneQ%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] An app's dialogs are not displayed properly
Has anyone experienced this kind of problem with any of your apps: https://github.com/bisq-network/bisq/issues/2855 -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/gaJBgvOop_QXSucD0f3KcO7PFn82Q_7npOJjm7amPP_JO38H_HlogVpoNMDrauHDEXzYbPuLCPDaue9aAU3AboUyKP4k4K0vo7qvSPYzJ8E%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout. publickey - cryptocarabao@protonmail.ch - 0x3F7D5EFD.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[qubes-users] Re: dispvm issues
On 6/12/19 12:34 AM, Jon deps wrote: On 6/12/19 12:24 AM, unman wrote: On Tue, Jun 11, 2019 at 10:26:59PM +, Jon deps wrote: Hello, for my Foo1 appVM in the Qube Manager I see default disp_vm as printqube (another AppVM) but in the Qubes Settings (accessed via the QM) for that Foo1 AppVM on the Advanced Tab it shows Default DispVM as default(none) and in the pull down menu there is no option for printqube as the dispvm I had it working using a Fedora Template with printer drivers installed, then using a that same printer-template based appvm as the default dispvm so I could use DispVMs to print but somehow I've broken the setup and dispVMs will only open if I use the fedora-28-dvm or whonix-ws-dvm-14 any suggestions please ? I cant account for the Qube Manager entry, but the most obvious explanation is that you have somehow removed the "template for dispvms" setting from printqube. Either set that again (using qvm-prefs) or create another qube, set the "template_for_dispvms", and then use that for Foo1. unman OK thanks for making me look again qvm-prefs printqube template_for_dispvms True was the trick for now :) when I use printqube as the basis for the dispVM to open a PDF file it is using libreoffice, I have evince aka "document viewer" but apparently it is not the default app for pdf I don't see where in printqube to make my default app choices forthe file types , I would assume it's possible? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20bb88a9-47e4-7883-d4dd-f418b665f6ef%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Will AEM work with UEFI boot (A.K.A. GPT)?
'interested_in_QubesOS' via qubes-users: The ReadMe on github says it is somewhat outdated, however it does not tell me what information it gives me is outdated. The bit about AEM not being compatible with (U)EFI boot is what concerns me. Here is the link: https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README You can also get there from the Qubes documentation page. <(not very specific I know) AFAIK, AEM still requires GRUB. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/35252491-921b-3ead-d652-fb1d00d5f861%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Sys-firewall error
Philip Pians: Sorry I was unable to reply sooner, Google wouldn't let me sign in for the past few days. Upon going back into BIOS and having a look around, I did find a section under Security called Virtualization, which had two disabled options. Intel ® Virtualization Technology which said something about VMM and, Intel ® Vt-d Feature. The Vt-d seemed familiar, perhaps is a system requirement for running Qubes, and of course “virtualization”, so I enabled these, rebooted, and am now being presented with Anon Connection Wizard. Is there a way I can confirm the sys-firewall problem has been rectified? I don’t want to assume the Wizard is any indication that it is fine. That's odd, I thought you had an AMD CPU. You're right, those need to be enabled for Intel. If you're seeing the connection wizard and no more errors, it's a good sign everything is working. Try browsing anything and if it works, you should be all set. Thanks heaps for the suggestions and advice. I’m really looking forward to trying Qubes out properly. Enjoy! -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e3c03267-2e52-02e7-0afa-338503e393b3%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Sys-firewall error
On Monday, June 10, 2019 at 5:15:07 AM UTC, awokd wrote: > Philip Pians: > > Thank you for the reply. I am not seeing any “SVM Mode” options in BIOS. > > The computer is brand new and was listed as being able to run QubesOS. FWIW > > > Keep looking and check your motherboard manual; it might also be called > Secure Virtual Machine. If you provide the type of motherboard, someone > might be able to direct you more specifically. Sorry I was unable to reply sooner, Google wouldn't let me sign in for the past few days. Upon going back into BIOS and having a look around, I did find a section under Security called Virtualization, which had two disabled options. Intel ® Virtualization Technology which said something about VMM and, Intel ® Vt-d Feature. The Vt-d seemed familiar, perhaps is a system requirement for running Qubes, and of course “virtualization”, so I enabled these, rebooted, and am now being presented with Anon Connection Wizard. Is there a way I can confirm the sys-firewall problem has been rectified? I don’t want to assume the Wizard is any indication that it is fine. Thanks heaps for the suggestions and advice. I’m really looking forward to trying Qubes out properly. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/de4d7b40-9105-411e-ba7d-d25a208deb12%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: dispvm issues
On 6/12/19 12:24 AM, unman wrote: On Tue, Jun 11, 2019 at 10:26:59PM +, Jon deps wrote: Hello, for my Foo1 appVM in the Qube Manager I see default disp_vm as printqube (another AppVM) but in the Qubes Settings (accessed via the QM) for that Foo1 AppVM on the Advanced Tab it shows Default DispVM as default(none) and in the pull down menu there is no option for printqube as the dispvm I had it working using a Fedora Template with printer drivers installed, then using a that same printer-template based appvm as the default dispvm so I could use DispVMs to print but somehow I've broken the setup and dispVMs will only open if I use the fedora-28-dvm or whonix-ws-dvm-14 any suggestions please ? I cant account for the Qube Manager entry, but the most obvious explanation is that you have somehow removed the "template for dispvms" setting from printqube. Either set that again (using qvm-prefs) or create another qube, set the "template_for_dispvms", and then use that for Foo1. unman OK thanks for making me look again qvm-prefs printqube template_for_dispvms Truewas the trick for 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a3081726-f2fd-00fd-cd5a-0639ed7aadf6%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] dispvm issues
On Tue, Jun 11, 2019 at 10:26:59PM +, Jon deps wrote: > Hello, > > for my Foo1 appVM in the Qube Manager I see default disp_vm as printqube > (another AppVM) > > but in the Qubes Settings (accessed via the QM) for that Foo1 AppVM on the > Advanced Tab it shows Default DispVM as default(none) and in the pull > down menu there is no option for printqube as the dispvm > > > I had it working using a Fedora Template with printer drivers installed, > then using a that same printer-template based appvm as the default dispvm > so I could use DispVMs to print > > but somehow I've broken the setup and dispVMs will only open if I use the > fedora-28-dvm or whonix-ws-dvm-14 > > > any suggestions please ? I cant account for the Qube Manager entry, but the most obvious explanation is that you have somehow removed the "template for dispvms" setting from printqube. Either set that again (using qvm-prefs) or create another qube, set the "template_for_dispvms", and then use that for Foo1. 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190612002414.xwfffarj6vvm3c3x%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Will AEM work with UEFI boot (A.K.A. GPT)?
The ReadMe on github says it is somewhat outdated, however it does not tell me what information it gives me is outdated. The bit about AEM not being compatible with (U)EFI boot is what concerns me. Here is the link: https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README You can also get there from the Qubes documentation page. <(not very specific I know) -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/yjI0R_gA5Neay45u9cE9YooEYF2xiuLVEGgxIfLBGeDO6aanwI4xpclLUl26S_u-NC8YqZSNiEZgKukFIFUNu9O7UQYkYr6r5FAFlI_iu0E%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Full proper backup of Dom0 possible?
On 6/11/19 1:12 PM, Steve Coleman wrote: To save myself from having to go through this fiasco even one more time I am now saving off the dom0 configuration information using a specific list of those things that I have to hand modify. I then I push that copy to a dedicated AppVM where it will be backed up just as any normal AppVM would be. The hardest part is remembering to add any changed configuration file to my configuration save list, though I am sure this too can be automated. The super simple command I am using to save this set of configuration files is: sudo tar cf - --derefrence --files-from=$FILELIST | \ qvm-run -a -p $DOCVM "cd /home/user/dom0-config ; tar xvf -" Here I am deliberately expanding the directory tree on the other side, but you might want instead to simply create an archive and label it with a date time-stamp before moving the archive over. I use this tree to diff and document my system within that dedicated AppVM. If any dom0 configuration files have changed it will be obvious. When recovering, by simply moving this configuration tree back to dom0, it will put me back to where I was before. Apart from that there may be some rpm packages to install and scripts to run, but that is Ok with me because I have all that documented and scripted. I don't need to backup everything in dom0. Just the important stuff in /etc, /usr/local/*, software archives, special rpm's, etc. If I didn't have to edit it, run, or install it, then I really don't need to back it up. Its simply a minimalist recovery capsule. suggestion - If the standard dom0 command line backup tool could be extended to allow a dom0 include-list argument, then it might mitigate this whole problem. If the user could simply add and remove file references to this include-list, then a full backup of dom0 might not be necessary. The user then decides what is important to add to this list. When restoring, the user would still have to move the individual recovered files back into place, but at least the user would *have* all the pieces needed to get up and running again. Hi Steve, There is still a consistency problem with this kind of live-system backup: the files could be in flux while they're being copied. Its also fussy to configure, as you mentioned, and leaves out packages and anything else the user forgot to plan. I think the best solution for a safe and comprehensive dom0 backup is to have Qubes simply snapshot the root lv at boot time, before its mounted as read-write. It shouldn't take more than a few script lines in the dom0 startup. Then dom0 can be backed up like any other vm. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7f4f563a-289e-0bf1-60dd-2cc2cc659406%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] dispvm issues
Hello, for my Foo1 appVM in the Qube Manager I see default disp_vm as printqube (another AppVM) but in the Qubes Settings (accessed via the QM) for that Foo1 AppVM on the Advanced Tab it shows Default DispVM as default(none) and in the pull down menu there is no option for printqube as the dispvm I had it working using a Fedora Template with printer drivers installed, then using a that same printer-template based appvm as the default dispvm so I could use DispVMs to print but somehow I've broken the setup and dispVMs will only open if I use the fedora-28-dvm or whonix-ws-dvm-14 any suggestions please ? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4ea685e8-b903-a1ce-6c71-ade22b3dcafe%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Full proper backup of Dom0 possible?
On 6/10/19 4:04 PM, Otto Kratik wrote: For both Template and AppVM's it's easy enough to backup and restore the entire thing as needed using the built-in tools from Qubes Manager, Qmenu or command line. Anything goes wrong, just restore a backup. But for dom0, all that seems to get backed up is the /home directory, meaning that any changes to other system areas such as /etc/qubes-rpc/policy/ for example would not get restored in the event of a reversion to a previously made backup after a fresh system install. Is there any way to make a full proper backup of Dom0 that would include absolutely everything outside of the other VM's on the system, obviously? So that after performing a fresh system install and then restoring all backups (dom0, templates, appvms) you would end up with a complete byte-for-byte replica of the previous system that existed? This could be done with external tools like DD of course, but that produces a gigantic image of the entire hard drive rather than just the needed parts, and also doesn't allow one to fully restore *just* dome0 while leaving the other templates/VMs alone, if desired. Does such a versatile option exist I have a lightweight solution that may be good-enough for some people out there, and a simple suggestion at the bottom. I have been bitten by this dom0 backup omission more times that I can remember. The problem is that the standard dom0 backup system does not save any of my dom0 highly tweaked system configuration files. Thus whenever restoring from backup is required, I am forced to manually reconfigure everything manually from scratch. In order to have 'the privilege' of running Qubes-OS here as my desktop system I am forced to configure my machine according to "the standard" configuration. I need to install specific software, 2FA, install cron jobs, run compliance reports, just to maintain access to network resources. Example: I just got back from short term disability, and found I was locked out and I needed to breach my own systems numerous security controls, rebuild, and reconfigure from the ground up. I'm still picking up the pieces and am trying to get everything back together for the inspections starting next week. To save myself from having to go through this fiasco even one more time I am now saving off the dom0 configuration information using a specific list of those things that I have to hand modify. I then I push that copy to a dedicated AppVM where it will be backed up just as any normal AppVM would be. The hardest part is remembering to add any changed configuration file to my configuration save list, though I am sure this too can be automated. The super simple command I am using to save this set of configuration files is: sudo tar cf - --derefrence --files-from=$FILELIST | \ qvm-run -a -p $DOCVM "cd /home/user/dom0-config ; tar xvf -" Here I am deliberately expanding the directory tree on the other side, but you might want instead to simply create an archive and label it with a date time-stamp before moving the archive over. I use this tree to diff and document my system within that dedicated AppVM. If any dom0 configuration files have changed it will be obvious. When recovering, by simply moving this configuration tree back to dom0, it will put me back to where I was before. Apart from that there may be some rpm packages to install and scripts to run, but that is Ok with me because I have all that documented and scripted. I don't need to backup everything in dom0. Just the important stuff in /etc, /usr/local/*, software archives, special rpm's, etc. If I didn't have to edit it, run, or install it, then I really don't need to back it up. Its simply a minimalist recovery capsule. suggestion - If the standard dom0 command line backup tool could be extended to allow a dom0 include-list argument, then it might mitigate this whole problem. If the user could simply add and remove file references to this include-list, then a full backup of dom0 might not be necessary. The user then decides what is important to add to this list. When restoring, the user would still have to move the individual recovered files back into place, but at least the user would *have* all the pieces needed to get up and running again. steve -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0a41d757-d134-ca15-9f23-246707cc008c%40jhuapl.edu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Full proper backup of Dom0 possible?
Hello Otto, ‐‐‐ Original Message ‐‐‐ On Monday, June 10, 2019 8:04 PM, Otto Kratik wrote: > But for dom0, all that seems to get backed up is the /home directory, meaning > that any changes to other system areas such as /etc/qubes-rpc/policy/ for > example would not get restored in the event of a reversion to a previously > made backup after a fresh system install. I use image for Linux (https://www.terabyteunlimited.com/image-for-linux.htm) to make an image of the entire system. I boot from USB/CD and save it directly to my NAS but you can save to external disk. I have the BootIt collection which is great and have used it for years - highly recommended. Regards, Chris - Chris Willard ch...@meliser.co.uk Sent with ProtonMail Secure Email. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/UrsfVqMqvInO51TJvUhBLk08dQW8egNqF7K5_mLdd-oMRy7twXL7jTvHAuyNv1t4maM0zYqA46V7UK4_4dk44LOiVblVDBUzzuQUU7nttP4%3D%40meliser.co.uk. For more options, visit https://groups.google.com/d/optout.
