[qubes-users] [MailServer Notification]Attachment Blocking Notification
The dracut.zip has been blocked, and Replace with text/file has been taken on 30/07/2019 00:27:58. Message details: Server: WANCYEXCHT04 Found in: SMTP Sender: qubes-users@googlegroups.com; Recipient: qubes-users@googlegroups.com; Subject: [qubes-users] Qubes installer gives dracut-pre-udev error. Attachment name: dracut.zip -- 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/10052_1564446003_5D3F8D33_10052_4248_1_0AC3BC624DE3B33862A0F7C5B1E6%40ancy.fr.sopra.
Re: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes
On 7/29/19 12:17 PM, Thomas Kerin wrote: Sorry, I mean, lvs does show them, I'm just wondering what it'll take to show them as active again. Normally, the following command should force a volume to become active: lvchange -kn -ay qubes_dom0/volume That directory seems to just have files from today! Avoid them unless the date-time was from when the system was (recently) still working. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5d1e0473-634f-8f1e-5ed8-a01dff9ffc06%40posteo.net.
Re: [qubes-users] Does anyone managed to have wireguard working on Fedora 29?
>1) don't "top post" > >2) in dom0 do uname -a does it say kernel 4.19 , if so you don't > need "the wg package" > >3) do a little search for "tasket vpn qubes github" and try his > script per instructions > > then report back I'm using kernel 4.19.43-1 so where can I find the wg module? The search for tasket vpn qubes github results is wg being used with debian as a PVH AppVM, I guess you overlooked the initial part on the thread where I said that I want this to work in fedora and not in debian on PVH. -- 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/50a8ebf49827f569fe7463cd64393f59%40disroot.org.
[qubes-users] Re: ANN: Qubes-VM-hardening v0.8.4 released
On 7/29/19 1:54 PM, Chris Laprise wrote: On 7/28/19 10:23 PM, Jon deps wrote: On 7/29/19 12:02 AM, Chris Laprise wrote: On 7/28/19 4:55 PM, Jon deps wrote: On 7/28/19 7:52 PM, Jon deps wrote: On 7/28/19 1:36 AM, Chris Laprise wrote: On 7/27/19 8:27 PM, Jon deps wrote: pardon my non-sysadmin query : any chance of some real world examples? quite a few new terms there . so install into Debian-9 but step 2 am already lost eg how and where amd I "activating" vm-boot-protect in the templatevm ? or during install there is going to appear a choice of which service to start , then when one opens a TBAVM based on the specified Deb-9 template the protection work at that point ? Go to the VM's Settings / Services tab, and add "vm-boot-protect" as a service. Can I install it in a fresh Deb-9 , and if its breaking things, just delete the fresh Deb-9 template, or is it touching dom0 ? It has a second-stage installation step that changes sudo/root access inside the template. And for that new root config to work, you have to add a couple dom0 config lines (it shows you the dom0 lines at the end of the install process). If you remove the altered Deb-9, the dom0 config lines will stay unless you change them back. However, in practice there is really no impact on your unmodified templates, so whether or not to remove the dom0 lines is a question of tidiness. As an alternative, per the Readme step 3, you can sidestep the whole sudo auth reconfiguration. I guess once installed there is no un-installing ? Currently there is no "purge everything" function or uninstall. You can remove the service manually by deleting the following: /lib/systemd/system/vm-boot-protect.service /usr/lib/qubes/init/vm-boot-protect.sh /etc/default/vms I just ended up using vm-boot-protect-root for the sys-net and sys-usb in qube settings services per the "Where to use basic examples" and vm-boot-protect for regular appVMs think I'll skip it for anything else sys-net is working (I am using fedora-30: because of the past clock sync issue) otherwise Deb-9 but just curious what the "additional networks VMs would be here" proxyVPNVMs ? "The sys-net VM should work 'out of the box' with the vm-boot-protect-root service via the included whitelist file. Additional network VMs may require configuration, such as cp sys-net.whitelist sys-net2.whitelist." PS: the appVMs seem a bit slower to boot, but could be my imagination ? :) as expected, since my sys-net was not based on the template I installed the script to I installed it to a deb-9-clone and the disp-qubes-manager method seems to be failing to update so typically when that happens I go to a terminal in the template and do it manually usually it seems to want -dist-upgrade , which presumably the disp-update has issues with but after installing the script * in the deb-9 template $sudo apt-get update fails with what looks like a script of having entered it incorrectly 3 times so sorry, but am I supposed to add vm-protect-root to the template services as well or how to fix this ? 'vm-protect-root' doesn't match any service created by Qubes-VM-hardening. Adding vm-boot-protect or vm-boot-protect-root to the services of the template is optional. You can use either one, but it will always behave like plain vm-boot-protect in the template (the -root functions don't make sense in templates). I'm not clear on when/where you're using fedora-30. Note that install step 3 is different for fedora. With debian-9, if you're getting immediate errors from every 'sudo' command, this would be expected if you chose to uninstall 'qubes-core-agent-passwordless-root' in install step 3 (this means no more sudo!). But if you chose to auto-configure sudo, you will still need to add the config lines to dom0 for sudo to work correctly (otherwise, sudo will just give you errors); these lines are printed in the shell at the end of the install process. hence, my original query about 'examples' thanks in advance Not sure what example you're looking for. In debian, the installer asks you one question: 'Configure sudo authentication prompt now? (y/n)'. After installing Qubes-VM-hardening with sudo auth configured, running a command like 'sudo apt-get update' will cause a dom0 auth prompt window to appear, at which point you can hit 'Enter' or click 'OK'. Then the command will run normally. At the vm-boot-protect level, you should see 'bin' automatically added to your home dir, and doing an 'lsattr -a' will show a number of files/dirs in home with the 'i' flag set. At vm-boot-protect-root level, you should see a new dir '/rw/vm-boot-protect' and it should contain 'BAK' and/or 'ORIG' versions of config, bind-dirs and usrlocal. 1) So, I chose 'yes' at the end of the script, for 'configure sudo authentication prompt. a) somehow I
Re: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes
My current problem is this error (triggerable by running `lvm lvchange -ay -v qubes_dom0/vm-vault-personal-docs-private`) It happens with some other affected vms. Activating logical volume qubes_dom0/vm-vault-personal-docs-private exclusively. activation/volume_list configuration setting not defined: Checking only host tags for qubes_dom0/vm-vault-personal-docs-private. Loading qubes_dom0-pool00_tdata table (253:2) Suppressed qubes_dom0-pool00_tdata (253:2) identical table reload. Loading qubes_dom0-pool00_tmeta table (253:1) Suppressed qubes_dom0-pool00_tmeta (253:1) identical table reload. Loading qubes_dom0-pool00-tpool table (253:3) Suppressed qubes_dom0-pool00-tpool (253:3) identical table reload. Creating qubes_dom0-vm--vault--personal--docs--private Loading qubes_dom0-vm--vault--personal--docs--private table (253:52) device-mapper: reload ioctl on (253:52) failed: No data available Removing qubes_dom0-vm--vault--personal--docs--private (253:52) Btw, I've scanned through the files in /etc/lvm/archive. I wasn't sure if I should follow your advice there as that command requires --force to work with thin provisioning and I've seen warnings about this online. I see the files contain references to the volumes that lvs doesnt show. I tested thin_check on qubes_dom0/pool00_meta0 volume (created by lvmodify --recover qubes_dom0), and get the following: examining superblock examining devices tree missing devices: [1, 747] too few entries in btree_node: 41, expected at least 42(max entries=126) Running thin_check on meta1 and meta2 (created by running lvchange --recover qubes_dom0 a further 2 times) doesn't yield anything major: examining superblock examining devices tree examining mapping tree checking space map counts I've followed a procedure to get a metadata snapshot (I couldn't directly access _tmeta using normal tools): https://serverfault.com/a/971620 and used thin_dump on the _meta0, _meta1, and _meta2 volumes created by `lvchange --recover`. I diff'd the tmeta file against the others, and it seems only the first line is different? 1c1 < --- > so the pools tmeta has nr_data_blocks = 0. Maybe my data is still there but the metadata is wrong? On Monday, 29 July 2019 16:37:26 UTC, thoma...@gmail.com wrote: > Oh, forgive me, no not all vms are present in lvs. -- 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/ac1978a4-68da-4960-bd69-8c4fdadd27ce%40googlegroups.com.
Re: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes
Oh, forgive me, no not all vms are present in lvs. -- 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/1a8a95a3-25a9-42c4-8051-60d5342245b4%40googlegroups.com.
Re: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes
Thanks Chris for your response! On Mon, 29 Jul 2019, 4:25 pm Chris Laprise, wrote: > On 7/29/19 10:19 AM, thomas.ke...@gmail.com wrote: > > Thanks for your response. > > > > I have some which don't show as active - it's looking like some data > loss.. > > > > Something I am getting when I run > > Lvconvert --repair qubes_dom0/pool00 > > > > > > WARNING: Sum of all thin volume sizes (2.67TiB) exceeds the size of thin > pools and the size of whole volume group (931.02GiB) > > > > Is this something I can fix perhaps? > > This is normal. Thin provisioning usually involves over-provisioning, > and that's what you're seeing. Most of our Qubes systems display this > warning when using lvm commands. > > Understood. Thanks! > > > > Also, I have some large volumes which are present. I've considered > trying to remove them, but I might hold off until I get data off the active > volumes first.. > > > > I've run across the thin_dump / thin_check / thin_repair commands. It > seems they're used under the hood by lvconvert --repair to check thin > volumes. > > > > Is there a way to relate those dev_ids back to the thin volumes lvm > can't seem to find? > > If 'lvs' won't show them, then I don't know precisely how. A long time > ago, I think I used 'vgcfgrestore /etc/lvm/archive/' to > resolve this kind of issue. > > > Sorry, I mean, lvs does show them, I'm just wondering what it'll take to show them as active again. That directory seems to just have files from today! I also recommend seeking help from the wider Linux community, since this > is a basic Linux storage issue. > > I have spent the morning researching, and found a few posts on redhat.com and some other sites describing how to repair the metadata. The most common reason seems to be overflowing the metadata partition, though mine is currently around 37% Others (one qubes user) encountered this after power failure. I shut down cleanly as far as I can tell this was a routine reboot.. And of course, a reminder there mishaps are a good reason to do the > following: > > 1. After installation, at least double the size of your pool00 tmeta > volume. > > 2. Perform regular backups (I'm working on a tool that can backup lvs > much quicker than the Qubes backup tool). > I definitely agree with both, although seems unlikely to have been point one in this case. I'm fairly sure the main disk has about 50% free also Backups are evidently a must.. I've screwed up qubes installs before, but never lost data until maybe now. I know lvm was only adopted in R4.0, everything else has been going so well with this install, but I had only just recovered and organized several old disks worth of data so I'll be gutted if I lost it and won't know why :/ I see a few people posting on the GitHub qubes-issues repo, one guy says 3 people in the past month have had this issue (or at least the same symptoms) > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAHv%2Btb7994bBVc-XZWBADke6r0znUC2b5sGaLfs%2BoVFOy0A_yA%40mail.gmail.com.
Re: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes
On 7/29/19 10:19 AM, thomas.ke...@gmail.com wrote: Thanks for your response. I have some which don't show as active - it's looking like some data loss.. Something I am getting when I run Lvconvert --repair qubes_dom0/pool00 WARNING: Sum of all thin volume sizes (2.67TiB) exceeds the size of thin pools and the size of whole volume group (931.02GiB) Is this something I can fix perhaps? This is normal. Thin provisioning usually involves over-provisioning, and that's what you're seeing. Most of our Qubes systems display this warning when using lvm commands. Also, I have some large volumes which are present. I've considered trying to remove them, but I might hold off until I get data off the active volumes first.. I've run across the thin_dump / thin_check / thin_repair commands. It seems they're used under the hood by lvconvert --repair to check thin volumes. Is there a way to relate those dev_ids back to the thin volumes lvm can't seem to find? If 'lvs' won't show them, then I don't know precisely how. A long time ago, I think I used 'vgcfgrestore /etc/lvm/archive/' to resolve this kind of issue. I also recommend seeking help from the wider Linux community, since this is a basic Linux storage issue. And of course, a reminder there mishaps are a good reason to do the following: 1. After installation, at least double the size of your pool00 tmeta volume. 2. Perform regular backups (I'm working on a tool that can backup lvs much quicker than the Qubes backup tool). -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11508ea4-fed4-e09c-875c-37026e6197a4%40posteo.net.
Fwd: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes
Sorry, didn't send to list. See my response to Chris. -- Forwarded message - From: Thomas Kerin Date: Mon, 29 Jul 2019, 3:40 pm Subject: Re: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes To: Chris Laprise Hi Chris, Yes, I think I tried that once last night. I notice it creates a qubes_dom0/pool_meta$N volume each time. Note my earlier post (before I saw yours!) had a weird error about 2.6 tb thin volume sizes exceeds size of pools and volume group Output this time was: WARNING: recovery of pools without pool metadata spare LV is not automated WARNING: if everything works, remove qubes_dom0/pool00_meta2 volumWARNING: Use pvmove command to move qubes_dom0/pool00_meta2 on the best fitting PV Currently I have qubes_dom0/pool_meta0, 1, and 2. On Mon, 29 Jul 2019, 3:18 pm Chris Laprise, wrote: > On 7/28/19 9:47 PM, 'awokd' via qubes-users wrote: > > 'awokd' via qubes-users: > >> thomas.ke...@gmail.com: > >>> I've just encountered this issue, and I thought my problems were over > >>> once I found this post.. > >>> > >>> Fyi, previously lvscan on my system shown root, pool00, and every > >>> volume but swap as inactive > >>> > >>> I followed your instructions, but the system still fails to boot. > >>> I've run 'vgchange -ay' and o saw the following printed a number of > >>> times. > >>> > >>> device-mapper: table 253:6: thin: Couldn't open thin internal device > >>>device-mapper: reload ioctl on (253:6) failed: no data available > >>> > >>> > >>> I ran 'lvscan' again, and this time some VMS were marked active, but > >>> a number (root,various -back volumes, several -root volumes, etc) > >>> > >>> Really terrified everything is gone as I had just recovered from a > >>> backup while my hardware got fixed, but I don't have the backup > anymore. > >>> > >> Can't tell which post you're replying to, but I get the idea. The > >> volumes you are most concerned about all end in --private. If you've > >> gotten them to the point where they show as active, you can make a > >> subdir and "sudo mount /dev/mapper/qubes_dom0-vm--work--private > >> subdir" for example, copy out the contents, umount subdir and move on > >> to the next. You can ignore --root volumes, since installing default > >> templates will recreate. If you can't get the --private volumes you > >> want to show as active, I'm afraid recovering those is beyond me. > >> > > Also, if you can't get a --private volume active, try its > > --private--##--back equivalent. > > Did you run "lvm lvconvert --repair qubes_dom0/pool00"? I think that > would be one of the first things you do when the underlying thin device > fails. > > If it needs additional space, you could delete the swap lv, then re-add > it later. > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAHv%2Btb6-PxnOuLzzEaPPFdfYx3aBJT77fuXgzfkpw6K2m3nzLw%40mail.gmail.com.
Re: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes
Thanks for your response. I have some which don't show as active - it's looking like some data loss.. Something I am getting when I run Lvconvert --repair qubes_dom0/pool00 WARNING: Sum of all thin volume sizes (2.67TiB) exceeds the size of thin pools and the size of whole volume group (931.02GiB) Is this something I can fix perhaps? Also, I have some large volumes which are present. I've considered trying to remove them, but I might hold off until I get data off the active volumes first.. I've run across the thin_dump / thin_check / thin_repair commands. It seems they're used under the hood by lvconvert --repair to check thin volumes. Is there a way to relate those dev_ids back to the thin volumes lvm can't seem to find? -- 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/1e4c4985-d981-4fc8-b701-0b2636f52134%40googlegroups.com.
Re: [qubes-users] fixing LVM corruption, question about LVM locking type in Qubes
On 7/28/19 9:47 PM, 'awokd' via qubes-users wrote: 'awokd' via qubes-users: thomas.ke...@gmail.com: I've just encountered this issue, and I thought my problems were over once I found this post.. Fyi, previously lvscan on my system shown root, pool00, and every volume but swap as inactive I followed your instructions, but the system still fails to boot. I've run 'vgchange -ay' and o saw the following printed a number of times. device-mapper: table 253:6: thin: Couldn't open thin internal device device-mapper: reload ioctl on (253:6) failed: no data available I ran 'lvscan' again, and this time some VMS were marked active, but a number (root,various -back volumes, several -root volumes, etc) Really terrified everything is gone as I had just recovered from a backup while my hardware got fixed, but I don't have the backup anymore. Can't tell which post you're replying to, but I get the idea. The volumes you are most concerned about all end in --private. If you've gotten them to the point where they show as active, you can make a subdir and "sudo mount /dev/mapper/qubes_dom0-vm--work--private subdir" for example, copy out the contents, umount subdir and move on to the next. You can ignore --root volumes, since installing default templates will recreate. If you can't get the --private volumes you want to show as active, I'm afraid recovering those is beyond me. Also, if you can't get a --private volume active, try its --private--##--back equivalent. Did you run "lvm lvconvert --repair qubes_dom0/pool00"? I think that would be one of the first things you do when the underlying thin device fails. If it needs additional space, you could delete the swap lv, then re-add it later. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cb4a0b84-3b9f-7439-b807-d1c56bc11680%40posteo.net.
[qubes-users] Re: Qubes 3.0 rc1 Error reset PCI network card in notebook
I had identical problem with Qubes 4.0.1 - and the solution was the same. Many thanks ;) On Wednesday, June 3, 2015 at 12:20:30 AM UTC+3, jeremia...@web.de wrote: > > Hello, > > I can not start the sys-net VM with my PCI network card attached. > > Internel error: > Unable to reset PCI device :04:00.2: > internal error: Active :04:00.0 devices on bus with :04:00.2 > not doing bus reset > > This happens only in Qubes 3.0 rc1 and not in Qubes 2.0 > > Network card: > Ethernet controller: Realtek RTL 8111/8168/8411 PCI Express Gigabit > > Best regards > J. Eppler > -- 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/c1cef19a-08f1-4c3f-911e-d515d09dd944%40googlegroups.com.
Re: [qubes-users] Re: ANN: Qubes-VM-hardening v0.8.4 released
On 7/28/19 10:23 PM, Jon deps wrote: On 7/29/19 12:02 AM, Chris Laprise wrote: On 7/28/19 4:55 PM, Jon deps wrote: On 7/28/19 7:52 PM, Jon deps wrote: On 7/28/19 1:36 AM, Chris Laprise wrote: On 7/27/19 8:27 PM, Jon deps wrote: pardon my non-sysadmin query : any chance of some real world examples? quite a few new terms there . so install into Debian-9 but step 2 am already lost eg how and where amd I "activating" vm-boot-protect in the templatevm ? or during install there is going to appear a choice of which service to start , then when one opens a TBAVM based on the specified Deb-9 template the protection work at that point ? Go to the VM's Settings / Services tab, and add "vm-boot-protect" as a service. Can I install it in a fresh Deb-9 , and if its breaking things, just delete the fresh Deb-9 template, or is it touching dom0 ? It has a second-stage installation step that changes sudo/root access inside the template. And for that new root config to work, you have to add a couple dom0 config lines (it shows you the dom0 lines at the end of the install process). If you remove the altered Deb-9, the dom0 config lines will stay unless you change them back. However, in practice there is really no impact on your unmodified templates, so whether or not to remove the dom0 lines is a question of tidiness. As an alternative, per the Readme step 3, you can sidestep the whole sudo auth reconfiguration. I guess once installed there is no un-installing ? Currently there is no "purge everything" function or uninstall. You can remove the service manually by deleting the following: /lib/systemd/system/vm-boot-protect.service /usr/lib/qubes/init/vm-boot-protect.sh /etc/default/vms I just ended up using vm-boot-protect-root for the sys-net and sys-usb in qube settings services per the "Where to use basic examples" and vm-boot-protect for regular appVMs think I'll skip it for anything else sys-net is working (I am using fedora-30: because of the past clock sync issue) otherwise Deb-9 but just curious what the "additional networks VMs would be here" proxyVPNVMs ? "The sys-net VM should work 'out of the box' with the vm-boot-protect-root service via the included whitelist file. Additional network VMs may require configuration, such as cp sys-net.whitelist sys-net2.whitelist." PS: the appVMs seem a bit slower to boot, but could be my imagination ? :) as expected, since my sys-net was not based on the template I installed the script to I installed it to a deb-9-clone and the disp-qubes-manager method seems to be failing to update so typically when that happens I go to a terminal in the template and do it manually usually it seems to want -dist-upgrade , which presumably the disp-update has issues with but after installing the script * in the deb-9 template $sudo apt-get update fails with what looks like a script of having entered it incorrectly 3 times so sorry, but am I supposed to add vm-protect-root to the template services as well or how to fix this ? 'vm-protect-root' doesn't match any service created by Qubes-VM-hardening. Adding vm-boot-protect or vm-boot-protect-root to the services of the template is optional. You can use either one, but it will always behave like plain vm-boot-protect in the template (the -root functions don't make sense in templates). I'm not clear on when/where you're using fedora-30. Note that install step 3 is different for fedora. With debian-9, if you're getting immediate errors from every 'sudo' command, this would be expected if you chose to uninstall 'qubes-core-agent-passwordless-root' in install step 3 (this means no more sudo!). But if you chose to auto-configure sudo, you will still need to add the config lines to dom0 for sudo to work correctly (otherwise, sudo will just give you errors); these lines are printed in the shell at the end of the install process. hence, my original query about 'examples' thanks in advance Not sure what example you're looking for. In debian, the installer asks you one question: 'Configure sudo authentication prompt now? (y/n)'. After installing Qubes-VM-hardening with sudo auth configured, running a command like 'sudo apt-get update' will cause a dom0 auth prompt window to appear, at which point you can hit 'Enter' or click 'OK'. Then the command will run normally. At the vm-boot-protect level, you should see 'bin' automatically added to your home dir, and doing an 'lsattr -a' will show a number of files/dirs in home with the 'i' flag set. At vm-boot-protect-root level, you should see a new dir '/rw/vm-boot-protect' and it should contain 'BAK' and/or 'ORIG' versions of config, bind-dirs and usrlocal. 1) So, I chose 'yes' at the end of the script, for 'configure sudo authentication prompt. a) somehow I missed the 'several commands' to manually
Re: [qubes-users] Re: ERROR: VM name contains illegal characters
On Mon, Jul 29, 2019 at 02:55:15AM -0700, qube5...@gmail.com wrote: > This error has appeared after uninstalling and reinstalling the debian-10 > template. When trying to remove the initial debian-10 install I also > searched dom0 for any debian-10 related files and deleted them. > > On Monday, 29 July 2019 02:49:58 UTC+2, qube...@gmail.com wrote: > > > > When creating an AppVM it will not let me use numbers in the beginning of > > the VM name: > > > > ERROR: VM name contains illegal characters > > You're right. Qubes wont let you use numbers in the beginning of the name. It isnt related to reinstalling any templates. It's baked in the system. Please remember that the convention here is to avoid top-posting. -- 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/20190729134551.n7pcjoffednhhskt%40thirdeyesecurity.org.
Re: [qubes-users] Re: Any appetite for tiny tweaks to make initial usability better?
On Wednesday, 24 July 2019 14:27:34 UTC+1, unman wrote: > > On Wed, Jul 24, 2019 at 12:47:12AM -0700, Martin Gladdish wrote: > > > > > > On Wednesday, 24 July 2019 01:23:55 UTC+1, qtpie wrote: > > > > > > Martin Gladdish: > > > > New Qubes user here, with less than a week's experience. > > > > > > > > Having fumbled my way through the initial install I'm now > encountering a > > > > few tiny niggles that should be simple to fix. > > > > > > > > The first one that springs to mind is the default keyboard shortcuts > in > > > > Terminal for Copy and Paste, which are Ctrl-Shift-C and > Ctrl-Shift-V. > > > But > > > > these clash with the inter-qube copy and paste shortcuts. > > > > > > > > Changing the default modifier in the Terminal app to use Alt instead > of > > > > Ctrl would seem to make sense? So Alt-Shift-C and Alt-Shift-V. > > > > > > > > Smoothing these wrinkles, although each of them is tiny, could make > a > > > big > > > > difference IMHO. > > > > > > > > Thoughts? > > > > > > > > > > > Hi Martin, > > > > > > In terminal you can use Ctrl+Insert as an alternative to Ctrl+Shift+C, > > > and Shift+Insert as an alternative to Ctrl+Shift+V. Maybe make a list > of > > > all you annoyances and their solutions, and submit it to Qubes for > > > inclusion in the manual? > > > > > > > Whilst I'm more than happy to contribute to the manual, I think this > should > > be changed in the app settings too. > > > > The labels on the menu items are where I'd look to see which shortcuts > to > > use, and out of the box they say Ctrl-Shift-C, etc. I didn't know about > > those alternate shortcuts, and don't think I would have gone looking on > the > > manual for them (but dead useful, thanks!). > > > > But yes, happy to put a niggle list together and see what we can do > about > > them. What's a good place for sharing such a doc online? I'd normally > use > > GDocs, but after google shafted my production service the other week by > > mistakenly flagging it on its spam databases I'm loathe to touch > anything > > of theirs again. > > > > Hi Martin > > Thanks for the input - keep the niggles coming. I'd suggest just posting > in this thread for the moment. > > The Ctrl+Shift+C combination in gnome-terminal is a gnome shortcut, > which can be configured as normal in gnome. There's an alternative > (Ctrl+Insert) as qtpie pointed out. > The use of Ctrl+Shift+C in Qubes is Qubes specific, and can be configured > by editing /etc/qubes/guid.conf > > This question has been raised before, and there are open issues at > github.com/qubesos/qubes-issues/issues > The greatest problem with proposed replacements is that they will almost > always conflict with shortcuts used by other users in specific programs. > There's been some discussion about this before and it doesn't seem > possible to find combinations that wont conflict *somewhere*. > For example your proposed use of Alt+Shift+C is used in i3 to reload > configuration. > > So it's left to users to configure as suits them. (In general Qubes > policy is not to change stuff that ships with distro defaults.) > > unman > Thanks. I agree completely that keeping as close to stock config as possible is the way to go, and I also think there are few things as tedious as favourite shortcut wars. I think where I'm coming at this differently though is in the default experience of installing and using Qubes. I accepted all the defaults when installing, which uses the regular window manager and provides a set of applications installed and configured in the menus for each qube by default. I think it would be better, and smoother, if we could make the default installation not have conflicts with itself. So, sure, if you want to use a different window manager than the default, then go ahead, and any keyboard shortcut conflicts are a possible byproduct of that. But the default shortcuts on the default apps, in the default window manager, should all play nicely together. -- 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/b068373e-c4cf-4d62-b0a4-26f55eb09e2d%40googlegroups.com.
[qubes-users] Re: About Wasabi
dosent anyone 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/35903ac6-808f-4015-964b-291d2dbe9855%40googlegroups.com.
[qubes-users] Re: About Wasabi
dosent anyone 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5f9f69e9-0e7e-47b3-99d2-97c08e418921%40googlegroups.com.
[qubes-users] Re: ERROR: VM name contains illegal characters
This error has appeared after uninstalling and reinstalling the debian-10 template. When trying to remove the initial debian-10 install I also searched dom0 for any debian-10 related files and deleted them. On Monday, 29 July 2019 02:49:58 UTC+2, qube...@gmail.com wrote: > > When creating an AppVM it will not let me use numbers in the beginning of > the VM name: > > ERROR: VM name contains illegal characters > > -- 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/f7a153a4-79e3-497a-a664-38aae12a128e%40googlegroups.com.
