Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Feb 16, 2018 at 11:37:46AM -, 'awokd' via qubes-users wrote: > On Thu, February 15, 2018 2:24 am, pixel fairy wrote: > > > at first i thought it was just the > > performance hit from mitigating speculation vulnerabilities, but others > > were reporting better performance in rc4 than rc3. > > Maybe they are on AMD. :) > > To rule out mitigations, I know Linux has an option to turn it off. Does > Xen have something similar? Try that and see if it restores your > performance. Yes, there is "xpti=false" option for Xen command line (xen.gz option in grub, or options= line in xen.cfg for UEFI). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqHcg4ACgkQ24/THMrX 1ywm/gf/TBoqkz8zMaJS+oEvq3ezpydA9vc+NZVvxv+qYr4OKDq+BNIbhwRRV90Y kPrEsBTLPhBhjA39RB37gjv3tkLj1pUMg/mZRFENbS6/QU3zIuOgylBdwLIGdTQf sz56zdU9ypAYJfFGZhpj68c7PGyukG7pCdvG5c0kezwG30Xls1Cn221Nwxsc1zt1 kuIUehQuSKcv+v5upX6WS0rPii0Q6pUF734QtHaT41hLsFmdnXPc9bvMK9sEzwH7 EV4eiLzv3l3XiHlpB7y4I6THQnQSbjTdpU8eXN5LY7XLxrHqUUlfxQdXDgprKAFA Tu/KTSFt9B9GFbv+uz+sGE5MiUmY5A== =96W1 -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 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/20180217000646.GB8969%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R4 rc4 Whonix-ws-dvm. Requires repeated tor-browser downloads
Each time I run the disposable whonix vm [whonix-ws-dvm] I am forced to go thro' th long-winded procedure of downloading a new tor-browser instance. Is this by design? or is it a bug? -- 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/099cb8a9-3cf6-6465-17d0-f7d257a37485%40dasamy.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] Re: R4.0 rc4: Devices and VM tray icons disappeared
On Friday, February 16, 2018 at 6:48:22 PM UTC-5, Daniel Moerner wrote: > Hi all, > > After a recent reboot, the devices and VM tray icons no longer are appearing > on boot in Xfce. I have no idea what might have caused this. There were no > dom0 updates in the meantime. If I try to manually run them, e.g., python3 > -mqui.tray.devices, I get the following: > > ERROR:dbus.proxies.Introspect error on > org.qubes.DomainManager1:/org/qubes/DomainManager1: > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message > recipient disconnected from message bus without replying > > Followed by a backtrace, the relevant part appears to be: > File "/usr/lib/python3.5/site-packages/qui/tray/devices.py", line 22, in > >DOMAINS = qui.models.qubes.DomainManager() > > Any advice would be appreciated, since with no icons, I'm also not appearing > to get notifications for devices and VM actions. > > Best, > Daniel Interesting discovery: this problem arose as a result of setting qrexec_timeout on an arbitrary VM to a value larger than an INT32. So the moral of the story: Don't try to set qrexec_timeout too high! Daniel -- 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/1f5e2f2a-3c6f-4798-beb5-21e1d7e596d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start
On Sat, February 17, 2018 2:30 am, pixel fairy wrote: > On Friday, February 16, 2018 at 4:07:10 PM UTC-8, Marek > Marczykowski-Górecki wrote: > > >> Yes, there is "xpti=false" option for Xen command line (xen.gz option >> in grub, or options= line in xen.cfg for UEFI). > > tried that by editing the multiboot /xen-4.8.3.gz line while booting. no > change. maybe its a different change between rc3 and rc4. seems like a > stretch, but one that only affects supermicro c7z motherboards? Try the Linux equivalent to disable mitigations in your template kernel options too maybe? -- 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/404e1971d809f393d2cdb116de62cb08.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start
On Friday, February 16, 2018 at 4:07:10 PM UTC-8, Marek Marczykowski-Górecki wrote: > Yes, there is "xpti=false" option for Xen command line (xen.gz option in > grub, or options= line in xen.cfg for UEFI). tried that by editing the multiboot /xen-4.8.3.gz line while booting. no change. maybe its a different change between rc3 and rc4. seems like a stretch, but one that only affects supermicro c7z motherboards? -- 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/8f3f5438-a930-4abb-9435-06adf92359e3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start
Original Message On 2018年2月17日 10:30, pixel fairy wrote: On Friday, February 16, 2018 at 4:07:10 PM UTC-8, Marek Marczykowski-Górecki wrote: > Yes, there is "xpti=false" option for Xen command line (xen.gz option in > grub, or options= line in xen.cfg for UEFI). tried that by editing the multiboot /xen-4.8.3.gz line while booting. no change. maybe its a different change between rc3 and rc4. seems like a stretch, but one that only affects supermicro c7z motherboards? I did some timing, and for PVH, my Fedora 26 VMs take about 30s, while Debian 9 takes about 45s. For HVM, qrexec usually times out (did not bother to adjust the timeout). Just to clarify, my mobo is an ASRock Z170, not a Supermicro one. --WillyPillow -- https://blog.nerde.pw/ PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C8 -- -- 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/feIj1otJTWDwda2aJVKqIsscwlqCmyDknsPVwOrKhcRXKZidQ0J6gyKrycBdVTYxQuOOUTF4KzOO8PnhdStxTn9CEbAASNZtxOCETNOchV8%3D%40nerde.pw. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 3.2 trim problem
Hi! Followed the trim tutorial in https://www.qubes-os.org/doc/disk-trim/ My computer boots through efi, so I did: 1) set issue_discards = 1 in /etc/lvm/lvm.conf 2) added discard to the end of the luks entry in /etc/crypttab. Also tried with allow-discards 3) Added rd.luks.options=discard to both ke dracut -H -frnel entries on /boot/efi/EFI/qubes/xen.cfg. Also tried with rd.luks.allow-discards 4) Rebuild initrd in hostonly mode with dracut -H -f rebooted the system with each try and every time, the response to command: sudo fstrim -v / fstrim: /: the discard operation is not supported Is there anything wrong? -- 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/0bf39f43-a628-4ff2-aed6-55e604a08db4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] VM Android Sentio Desktop for the Threema Messanger?
Hello, for running Threema and to read on a big screen and to use the desktop tools like keyboard and mouse, I would like to use Android-x86 in a HVM. Sure you can also prefer the wiping on a smartphone or tablet, which has bad effects to your fingers, neck, back and eyes, so it seems to me nuts. Android-x86 has the goal to use Android OS/Apps on a desktop. https://liliputing.com/2018/02/android-x86-brings-android-nougat-desktop-laptop-pcs.html Sentio Desktop gives Android a more PC like look and feel. https://play.google.com/store/apps/details?id=com.sentio.desktop=en Does anyone have some experience how to setup the Threema Messanger via the Android-x86/Sentio Desktop as an HVM under Qubes? Kind Regards -- 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/ae82199c-bd12-467c-a946-a07d45f9bd8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote: > Hi! > Followed the trim tutorial in https://www.qubes-os.org/doc/disk-trim/ > My computer boots through efi, so I did: > > > 1) set issue_discards = 1 in /etc/lvm/lvm.conf > 2) added discard to the end of the luks entry in /etc/crypttab. Also tried > with allow-discards 3) Added rd.luks.options=discard to both ke dracut -H > -frnel entries on /boot/efi/EFI/qubes/xen.cfg. Also tried with > rd.luks.allow-discards 4) Rebuild initrd in hostonly mode with dracut -H > -f > > > rebooted the system with each try and every time, the response to > command: > sudo fstrim -v / fstrim: /: the discard operation is not supported > > > Is there anything wrong? First of all, is / on an SSD or hard drive? Try doing a "cryptsetup status /dev/mapper/luks-UUID#". Look for "flags: discards". 2) Should be just discard 3) Should be rd.luks.options=discard 4) Please try this longer version of initramfs generation. I think the short version is OK for GRUB boot but EFI might need the longer one: sudo /usr/bin/dracut -f /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img 4.9.56-21.pvops.qubes.x86_64 Let me know if that fixes it (or not) so I can update the doc. -- 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/57d44bd8e25ae41b1db54fdef3c50b8a.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] q4rc4 very slow. VMs take 23 - 33 seconds to start
On Thu, February 15, 2018 2:24 am, pixel fairy wrote: > at first i thought it was just the > performance hit from mitigating speculation vulnerabilities, but others > were reporting better performance in rc4 than rc3. Maybe they are on AMD. :) To rule out mitigations, I know Linux has an option to turn it off. Does Xen have something similar? Try that and see if it restores your performance. -- 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/1241acf8b534ca33ba68523ff5007247.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] 4.0 rc-4 Blank screen on Installation
On Fri, February 16, 2018 7:09 am, Michael MENG wrote: > Hi, > My hp laptop work perfectly on qubes 3.2, i want to install qubes 4rc4, > However, it is no display when boot on usb. Is there any idea to fix > this? Thanks. What model HP? What kind of video hardware? How far does it get? Try searching this mailing list for your model laptop and the HCL to see if anyone else has tips on how to get it working with R4.0. -- 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/707c3d59d7dc327dfca67bbefa86a61a.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: R4 rc4 - Whonix System Time Error
On Wed, February 14, 2018 5:36 pm, brendan.h...@gmail.com wrote: > On Wednesday, February 14, 2018 at 5:33:03 AM UTC-5, sebuq wrote: > >> The virgin whonix templates issue with official Qubes R4 rc4 downloads >> did not result in errors via whonixcheck. However after updating the >> whonix-gw template a get the following system time error: >> >> ERROR: Systemd Clock Check Result: >> Unexpected results by timedatectl. > > I have seen the same, but it the sys-whonix vm still manages to > connect... I noticed this too on a recent update. Looked like sdwdate was running- this often gives me spurious dates/times. There appears to be a systemd control option intended to disable it under Qubes but it didn't seem to be firing. Maybe check over on the Whonix forum/Github and see if someone has already reported it? Am planning to debug further when I get a bit of time. -- 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/81e810726ad82630ae3cc9985c0d6321.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] 4.0 rc-4 Blank screen on Installation
Hi I am having the same problem with my hp eny. Although installation was successful but after booting into qubes after installation I get the blank screen. I think there is some graphics tweak needed. Haven’t solved it yet. Hoping to get some help. 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 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/b4f82d4e-a5bf-473a-b444-8d134fdda60f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
On 02/16/2018 01:34 PM, 'awokd' via qubes-users wrote: On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote: Hi! Followed the trim tutorial in https://www.qubes-os.org/doc/disk-trim/ My computer boots through efi, so I did: 1) set issue_discards = 1 in /etc/lvm/lvm.conf 2) added discard to the end of the luks entry in /etc/crypttab. Also tried with allow-discards 3) Added rd.luks.options=discard to both ke dracut -H -frnel entries on /boot/efi/EFI/qubes/xen.cfg. Also tried with rd.luks.allow-discards 4) Rebuild initrd in hostonly mode with dracut -H -f rebooted the system with each try and every time, the response to command: sudo fstrim -v / fstrim: /: the discard operation is not supported Is there anything wrong? First of all, is / on an SSD or hard drive? Try doing a "cryptsetup status /dev/mapper/luks-UUID#". Look for "flags: discards". 2) Should be just discard 3) Should be rd.luks.options=discard 4) Please try this longer version of initramfs generation. I think the short version is OK for GRUB boot but EFI might need the longer one: sudo /usr/bin/dracut -f /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img 4.9.56-21.pvops.qubes.x86_64 Let me know if that fixes it (or not) so I can update the doc. In case you update the doc, you may add `systemctl enable fstrim.timer` for setting a periodic job in the configuration section [1]. However: - the timer is run daily, not weekly (fstrim runs very fast though, shouldn't be an issue). - it might be specific to R4.0 - I don't remember if util-linux provided the timer in R3.2 (FWIW the documentation's instructions worked for me on R4.0rc4, with grub boot). Ivan [1] https://www.qubes-os.org/doc/disk-trim/#configuration -- 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/55fe5b8c-5b26-af84-3424-ec51535f53f3%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
On Fri, February 16, 2018 3:22 pm, 'awokd' via qubes-users wrote: > On Fri, February 16, 2018 3:13 pm, nunotmalhe...@gmail.com wrote: > >> sexta-feira, 16 de Fevereiro de 2018 às 15:02:54 UTC, awokd escreveu: > > >>> dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r) >>> >>> works for a generic version at least. Will go with that unless >>> there's a better suggestion. >> >> Don't forget that the original doc had the host only option -H. >> > > I am intentionally forgetting that. :) Per the man page: > > > "If you want to create lighter, smaller initramfs images, you may want to > specify the --hostonly or -H option. Using this option, the resulting > image will contain only those dracut modules, kernel modules and > filesystems, which are needed to boot this specific machine. This has the > drawback, that you can’t put the disk on another controller or machine, > and that you can’t switch to another root filesystem, without recreating > the initramfs image. The usage of the --hostonly option is only for > experts and you will have to keep the broken pieces. At least keep a copy > of a general purpose image (and corresponding kernel) as a fallback to > rescue your system." > > For a generic recommendation, the tradeoffs don't seem worth saving a few > bytes. I figure if someone really needs those bytes they can add the -H > themselves. Submitted https://github.com/QubesOS/qubes-doc/pull/592 ; thank you both. And if I'm missing some other reason that dracut -H should be included, please let me know! Might make sense to remove it from the GRUB section as well. -- 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/96345a81acea560a2ecff143b1941f38.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
On Fri, February 16, 2018 2:03 pm, Ivan Mitev wrote: > In case you update the doc, you may add `systemctl enable fstrim.timer` > for setting a periodic job in the configuration section [1]. However: > - the timer is run daily, not weekly (fstrim runs very fast though, > shouldn't be an issue). - it might be specific to R4.0 - I don't remember > if util-linux provided the timer in R3.2 Looks like it works on R3.2 as well, but when I "systemctl status fstrim.timer" it is titled: fstrim.timer - Discard unused blocks once a week Are you sure R4.0 is daily? I can't really check right 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/680dc6e9b5f4f1a6fdcf5a0a400c9636.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Explain the error building 3.2?
On Fri, February 16, 2018 9:43 am, Tim W wrote: > The last two days I have been having issues building 3.2 have not tried > 4.0 yet. > I get the the following errors in the template-stretch.log file. The > Component fails on the stretch standard template build. All the Fedoras > are good has not gotten to whonix yet for that component. > Installing new version of config file /etc/fstab ... > chown: cannot access '/home_volatile/user': No such file or directory > dpkg: error processing package qubes-core-agent (--configure): > subprocess installed post-installation script returned error exit status 1 > dpkg: dependency problems prevent configuration of > qubes-input-proxy-sender: > qubes-input-proxy-sender depends on qubes-core-agent (>= 3.0.25); however: > Package qubes-core-agent is not configured yet. My build finally finished running; got the same fatal error you did. -- 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/ff735509eabc4f4b13d1a89b7978e9d0.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Q4rc4 :: Fedora AppVM Screenshot-Tool only generates black window
On Friday, February 16, 2018 at 1:38:32 AM UTC-5, [799] wrote: > Additional Info: > > I have tested the screenshot tool in an unchanged Fedora 26 template, no > content is shown after screenshoting. > Instead of my first post, the screenshot is only shown as a white (not black) > area. > > The screenshot tool is working in dom0. > > I have run lspci in dom0: > > 00:02:0 VGA compatible controller: Intel Corporation 4th Gen Core Processor > Integrated Graphics Controller (rev 06) > > 01:00.0 VGA compatible controller: NVIDIA Corporation GK106GLM [Quadro > K2100M] (rev all) > I have to admit that I'm fairly new to this OS, but it seems to me you don't really want a screen capture program to work out of one of the vms. That would break the compartmentalization badly, I think. As you note, it works in dom0 (as it does with me), and that's where it should work. I'm more used to VirtualBox than Xen, so the way I get my head around Qubes is to think of it simply as a very highly granular Virtualbox setup. In VirtualBox, if you open up a Windows desktop and use the screenshot program in that, you *only* expect it to work *on that desktop.* You can't open a screenshot program in the Windows desktop and get a shot of the Fedora desktop. The same thing would be true here, except the vms don't have desktops -- only windows. So... there's no desktop to take a screenshot of, except for dom0. It seems to me that if my fedora vm could take a shot of the entire screen, then the whole compartmentalization thing would be shot to hell. I may be wrong -- I'm not an expert here -- but I simply wouldn't expect it to work. There's this ironclad rule in life that usability and security are inversely related. You can mitigate it a little, or make it worse. The TSA for instance (for those of you outside the US, the TSA is our airport security service) maximizes inconvenience for a minimal to moderate increase in security. Qubes attempts to minimize inconvenience for a maximal increase in security. But the relationship still exists. Security is *always* inconvenient. billo -- 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/97a49eb7-cbca-49f6-b102-f75211602ee3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
sexta-feira, 16 de Fevereiro de 2018 às 11:34:10 UTC, awokd escreveu: > On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote: > > Hi! > > Followed the trim tutorial in https://www.qubes-os.org/doc/disk-trim/ > > My computer boots through efi, so I did: > > > > > > 1) set issue_discards = 1 in /etc/lvm/lvm.conf > > 2) added discard to the end of the luks entry in /etc/crypttab. Also tried > > with allow-discards 3) Added rd.luks.options=discard to both ke dracut -H > > -frnel entries on /boot/efi/EFI/qubes/xen.cfg. Also tried with > > rd.luks.allow-discards 4) Rebuild initrd in hostonly mode with dracut -H > > -f > > > > > > rebooted the system with each try and every time, the response to > > command: > > sudo fstrim -v / fstrim: /: the discard operation is not supported > > > > > > Is there anything wrong? > > First of all, is / on an SSD or hard drive? > Try doing a "cryptsetup status /dev/mapper/luks-UUID#". Look for "flags: > discards". > > 2) Should be just discard > 3) Should be rd.luks.options=discard > 4) Please try this longer version of initramfs generation. I think the > short version is OK for GRUB boot but EFI might need the longer one: > sudo /usr/bin/dracut -f > /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img > 4.9.56-21.pvops.qubes.x86_64 > > Let me know if that fixes it (or not) so I can update the doc. Hi! It fixed my problem! I never thought it could be a problem with dracut's arguments. You should update the doc. Thanks for the quick response!!! -- 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/02834b79-76f8-4f81-993a-1e036a3ab154%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
On Fri, February 16, 2018 2:49 pm, 'awokd' via qubes-users wrote: > On Fri, February 16, 2018 2:37 pm, nunotmalhe...@gmail.com wrote: > >> sexta-feira, 16 de Fevereiro de 2018 às 11:34:10 UTC, awokd escreveu: >>> On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote: >>> > >>> 4) Please try this longer version of initramfs generation. I think >>> the short version is OK for GRUB boot but EFI might need the longer >>> one: sudo >>> /usr/bin/dracut -f >>> /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img >>> 4.9.56-21.pvops.qubes.x86_64 >>> > > Anyone know if there is a shorter version of the above command that works > for EFI without having to specify the kernel version numbers? Looks like: dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r) works for a generic version at least. Will go with that unless there's a better suggestion. -- 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/6ce95ea1269a2854cddd87525b3baae6.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
sexta-feira, 16 de Fevereiro de 2018 às 15:02:54 UTC, awokd escreveu: > On Fri, February 16, 2018 2:49 pm, 'awokd' via qubes-users wrote: > > On Fri, February 16, 2018 2:37 pm, nunotmalhe...@gmail.com wrote: > > > >> sexta-feira, 16 de Fevereiro de 2018 às 11:34:10 UTC, awokd escreveu: > >>> On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote: > >>> > > > >>> 4) Please try this longer version of initramfs generation. I think > >>> the short version is OK for GRUB boot but EFI might need the longer > >>> one: sudo > >>> /usr/bin/dracut -f > >>> /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img > >>> 4.9.56-21.pvops.qubes.x86_64 > >>> > > > > > Anyone know if there is a shorter version of the above command that works > > for EFI without having to specify the kernel version numbers? > > Looks like: > > dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r) > > works for a generic version at least. Will go with that unless there's a > better suggestion. Don't forget that the original doc had the host only option -H. -- 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/b1c73c10-0931-4e13-a559-91ad6e934746%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
On 02/16/2018 05:15 PM, 'awokd' via qubes-users wrote: On Fri, February 16, 2018 2:03 pm, Ivan Mitev wrote: In case you update the doc, you may add `systemctl enable fstrim.timer` for setting a periodic job in the configuration section [1]. However: - the timer is run daily, not weekly (fstrim runs very fast though, shouldn't be an issue). - it might be specific to R4.0 - I don't remember if util-linux provided the timer in R3.2 Looks like it works on R3.2 as well, but when I "systemctl status fstrim.timer" it is titled: fstrim.timer - Discard unused blocks once a week Are you sure R4.0 is daily? I can't really check right now. I'm sorry, it's weekly, I've looked at the wrong timer. Also, `systemctl start fstrim.timer` will be required if one doesn't plan to reboot in the next days... -- 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/0920b2a5-ddba-4104-a2b3-20b7dc5cb340%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
On Fri, February 16, 2018 2:37 pm, nunotmalhe...@gmail.com wrote: > sexta-feira, 16 de Fevereiro de 2018 às 11:34:10 UTC, awokd escreveu: >> On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote: >> 4) Please try this longer version of initramfs generation. I think the >> short version is OK for GRUB boot but EFI might need the longer one: sudo >> /usr/bin/dracut -f >> /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img >> 4.9.56-21.pvops.qubes.x86_64 >> >> >> Let me know if that fixes it (or not) so I can update the doc. >> > > Hi! > It fixed my problem! I never thought it could be a problem with dracut's > arguments. You should update the doc. > > > Thanks for the quick response!!! Thanks for being a guinea pig! :) Will submit an update request (and include Ivan's suggestion too). Anyone know if there is a shorter version of the above command that works for EFI without having to specify the kernel version numbers? -- 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/016a552567d66cc6c3c3ad3cf37163c2.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 trim problem
On Fri, February 16, 2018 3:13 pm, nunotmalhe...@gmail.com wrote: > sexta-feira, 16 de Fevereiro de 2018 às 15:02:54 UTC, awokd escreveu: >> dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r) >> >> works for a generic version at least. Will go with that unless there's >> a better suggestion. > > Don't forget that the original doc had the host only option -H. I am intentionally forgetting that. :) Per the man page: "If you want to create lighter, smaller initramfs images, you may want to specify the --hostonly or -H option. Using this option, the resulting image will contain only those dracut modules, kernel modules and filesystems, which are needed to boot this specific machine. This has the drawback, that you can’t put the disk on another controller or machine, and that you can’t switch to another root filesystem, without recreating the initramfs image. The usage of the --hostonly option is only for experts and you will have to keep the broken pieces. At least keep a copy of a general purpose image (and corresponding kernel) as a fallback to rescue your system." For a generic recommendation, the tradeoffs don't seem worth saving a few bytes. I figure if someone really needs those bytes they can add the -H themselves. -- 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/803f3d71f8718924e8efaa43c0366902.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes on ssd may not be secure on encryption
On 02/16/2018 01:44 PM, ronwirr...@safe-mail.net wrote: Qubes should investigate if it is not secure to use a ssd because the software which runs the ssd may nullify any piece of encrypted data on the ssd. https://www.qubes-os.org/doc/system-requirements/#recommended http://www.deutschlandfunk.de/verschluesselungssoftware-veracrypt-unabhaengige.684.de.html?dram:article_id=369309 Its been discussed in the past... The risk behind this appears to be more theoretical than a current threat. But this isn't a Qubes-specific issue; every OS is (potentially) affected more or less the same. When provisioning hardware, an extremely careful person would use HDDs only. -- 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/3789d60c-52b9-10c3-b43f-ef6c02b33e72%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes on ssd may not be secure on encryption
On Fri, February 16, 2018 6:44 pm, ronwirr...@safe-mail.net wrote: > Qubes should investigate if it is not secure to > use a ssd because the software which runs the ssd may nullify any piece of > encrypted data on the ssd. > > https://www.qubes-os.org/doc/system-requirements/#recommended > > > http://www.deutschlandfunk.de/verschluesselungssoftware-veracrypt-unabhae > ngige.684.de.html?dram:article_id=369309 That's not what the (machine translated) article is saying. It's saying if you save something unencrypted to an SSD, it can not be reliably deleted. On the other hand, if you use full disk encryption (like Qubes does with LUKS), all the SSD will ever see is encrypted blocks. If the blocks have been encrypted correctly, the inability to reliably delete them is not a problem in most cases. (Exception being if you are concerned about the ability to see that a "linuxy" type operating system has allocated blocks on disk, but not what's in those blocks). -- 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/7d3bc71863a59ca1da32dcb72fe34c30.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Explain the error building 3.2?
On Fri, February 16, 2018 3:33 pm, 'awokd' via qubes-users wrote: > On Fri, February 16, 2018 9:43 am, Tim W wrote: > > >> The last two days I have been having issues building 3.2 have not tried >> 4.0 yet. >> > >> I get the the following errors in the template-stretch.log file. The >> Component fails on the stretch standard template build. All the Fedoras >> are good has not gotten to whonix yet for that component. > >> Installing new version of config file /etc/fstab ... >> chown: cannot access '/home_volatile/user': No such file or directory >> dpkg: error processing package qubes-core-agent (--configure): >> subprocess installed post-installation script returned error exit status >> 1 >> dpkg: dependency problems prevent configuration of >> qubes-input-proxy-sender: >> qubes-input-proxy-sender depends on qubes-core-agent (>= 3.0.25); >> however: >> Package qubes-core-agent is not configured yet. >> > > My build finally finished running; got the same fatal error you did. Might be some kind of interaction between https://github.com/QubesOS/qubes-core-agent-linux/pull/81/commits/41f568766f36e7f7588c14490196c906e57a2c22 (merged 4 days ago) and https://github.com/QubesOS/qubes-core-agent-linux/commit/00e846bbbe581aceeeaf4a8369748d4ff450b1b0. Want to open an issue on 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 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/6da18b67ae75529224903202bde8cfa8.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Launching KDE applications in VM
Hello, I am using the artful template. I installed kubuntu-deskptop package to get all needed packages. This looks to work correctly. When I launch a KDE applications, it runs without displaying any icons. I have found that if I start the KDE application from a shell, then I can add the env variables "export KDE_SESSION_VERSION=5" and "export KDE_FULL_SESSION=true" and it works better. Do you know how I could set those env variable for every launched application from the XFCS dom0 start menu? Thanks, Bertrand -- 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/fd0ef8a4-f41a-4eeb-bcfc-bbf0ca78f588%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qubes on ssd may not be secure on encryption
Qubes should investigate if it is not secure to use a ssd because the software which runs the ssd may nullify any piece of encrypted data on the ssd. https://www.qubes-os.org/doc/system-requirements/#recommended http://www.deutschlandfunk.de/verschluesselungssoftware-veracrypt-unabhaengige.684.de.html?dram:article_id=369309 -- 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/N1M-GmWIUqTAOi%40Safe-mail.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: HCL submission : Dell Precision 5510
Has anyone been able to get the USB-C Ethernet adapter working on the Precision 5510, either with the small dongle, or the Lightning Dock? Thanks Mike -- 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/d719dffe-7bb7-48fc-883f-b4eafed5b2b9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes on ssd may not be secure on encryption
On Friday, February 16, 2018 at 2:31:38 PM UTC-5, Chris Laprise wrote: > On 02/16/2018 01:44 PM, ron w wrote: > > Qubes should investigate if it is not secure to > > use a ssd because the software which runs > > the ssd may nullify any piece of encrypted > > data on the ssd. > > > > https://www.qubes-os.org/doc/system-requirements/#recommended > > > > http://www.deutschlandfunk.de/verschluesselungssoftware-veracrypt-unabhaengige.684.de.html?dram:article_id=369309 > > Its been discussed in the past... The risk behind this appears to be > more theoretical than a current threat. But this isn't a Qubes-specific > issue; every OS is (potentially) affected more or less the same. When > provisioning hardware, an extremely careful person would use HDDs only. Dang, sorry folks, my pet area...skip to point 4.5 for some fun paranoid procedures. In my opinion, using either HDDs or SSDs converge to the same risk: that the firmware could be compromised* and that some unused portion of the drive can be used to hide data for exfiltration. I have seen evidence of SSD manufacturers digitally signing and encrypting their firmware images (for governmental security certifications? protecting trade secrets? etc.?), which perhaps makes them more secure against tampering than traditional HDDs were. While much is made of SSD's lack of direct mapping of logical blocks to physical blocks (in a well-structured ordered array of cells across chips), compared to HDDs...HDDs really aren't as perfect in that regard as people assume. Even non-compromised HDD firmware is designed to take advantage of a cache of reserved replacement blocks spread across the disk surface which are designed to be used for drive-managed bad/weak-block remapping. The end user has no access or control over these via the ATA interface. HD recovery companies have designed some tools to work over the debug interfaces, but your computer is generally not wired up to those pins (usually taken advantage of via the jumper pins next to the ATA/SATA connectors). Presumably the HDDs' pseudo-over-provisioning of blocks is at least an order of magnitude smaller than what is used in contemporary flash-based SSDs...but it leads to a similar issue: modified firmware can hide stolen data in the slack area. My recommendation: 1. Embrace contemporary SSDs. 2. Only utilize SSDs with firmware that supports the following features: a. always-on SED below their own FFS layer (this is implied by c). b. ATA Password (this is made useful by a and is also implied by c, ATA Password is considered "Level 0" Opal support) c. TCG Opal v2.x (this supports drive-managed encrypted zones with different keys, etc.). d. Support for ATA SANITIZE CRYPTO SCRAMBLE 3. Re-flash the SSD with the (hopefully signed) manufacturer firmware image when you receive it to reduce the chance of pre-delivery tampering impacting you. 4. Re-key the drive using ATA SANITIZE CRYPTO SCRAMBLE. I have a bootable Lenovo Thinkpad disc image that performs this transaction in a few seconds. It re-keys the entire user data layer. Fun note: some drive models will show all 00s after executing this function, which makes it hard to verify - is it doing more or less than a ATA SECURITY ERASE** or full trim of the drive? Other drives will show what appears to be random data across the disk. With these drives, every time you run the command, the random data changes, which is awesome. It's not random data exactly, it's the original SED encrypted data, but with a different key randomly generated by the drive firmware and used going forward. [[4.5 When you really want to kill all the data with fire: a) TRIM the entire user area you have access to (can be limited if OPAL is active, otherwise should be full drive) b) clear the ATA password if ATA password is set, c) peform OPAL PSID revert if OPAL was set up, d) reflash the firmware, e) TRIM the entire drive again, f) perform ATA SANITIZE CRYPTO SCRAMBLE (and verify different data read if possible), g) perform ATA ENHANCE SECURITY ERASE, h) perform ATA SECURITY ERASE. i) finally, TRIM the entire drive again.***]] 5. HW encrypt the drive before production use: either take advantage of BIOS ATA password support for simplicity (Level 0 OPAL requires that your password be used to encrypt the key(s) for the entire user area) or, alternately, implement DTA's sedutil to set up a read-only linux-based PBA image (pre-boot authorization image) that performs the necessary TCG Opal authorization steps to unlock your read/write volume(s) with your password(s). And finally...also utilize --software-- disk encryption (either supplied with your OS or as an add-on to your OS). Intel AES instructions make even software encryption nearly transparent performance-wise. -brendan * a technique implied in various leaks here and there but also...this great example of installing linux onto the on-board *controller* of a HDD - the HDD
Re: [qubes-users] Explain the error building 3.2?
On Friday, February 16, 2018 at 3:02:44 PM UTC-5, awokd wrote: > On Fri, February 16, 2018 3:33 pm, 'awokd' via qubes-users wrote: > > On Fri, February 16, 2018 9:43 am, Tim W wrote: > > > > > >> The last two days I have been having issues building 3.2 have not tried > >> 4.0 yet. > >> > > > >> I get the the following errors in the template-stretch.log file. The > >> Component fails on the stretch standard template build. All the Fedoras > >> are good has not gotten to whonix yet for that component. > > > >> Installing new version of config file /etc/fstab ... > >> chown: cannot access '/home_volatile/user': No such file or directory > >> dpkg: error processing package qubes-core-agent (--configure): > >> subprocess installed post-installation script returned error exit status > >> 1 > >> dpkg: dependency problems prevent configuration of > >> qubes-input-proxy-sender: > >> qubes-input-proxy-sender depends on qubes-core-agent (>= 3.0.25); > >> however: > >> Package qubes-core-agent is not configured yet. > >> > > > > My build finally finished running; got the same fatal error you did. > > Might be some kind of interaction between > https://github.com/QubesOS/qubes-core-agent-linux/pull/81/commits/41f568766f36e7f7588c14490196c906e57a2c22 > (merged 4 days ago) and > https://github.com/QubesOS/qubes-core-agent-linux/commit/00e846bbbe581aceeeaf4a8369748d4ff450b1b0. > > Want to open an issue on it? Yes I think so or at least I will post it over on devel. Those update I think are likely the root of it. Maybe something small but the errors seem to fit. I will post it over on dev and git. -- 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/de336c94-89d9-4ffa-9a2f-972ea45832b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4.0 rc4 Back-up Bug
On Thursday, February 15, 2018 at 2:46:24 AM UTC-5, sebuq wrote: > Backups via the Control Panel fail with the message unable to find the > directory. However using qvm-backup via Dom0 CLI works fine. > > Is it me, or is this bug on a list to be fixed at some point in the future? https://github.com/QubesOS/qubes-issues/issues/3594 -- 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/17cf4ddb-6cef-4d86-bec9-503cc7591d2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.
On Tuesday, February 13, 2018 at 4:51:12 PM UTC-5, QUBE-A-LICIOUS wrote: > Hi there, > > I have a fresh install of Qubes 4r4. However, when I reboot and or login I > have to manually change dom0 time to UTC. > > Impact: Whonix/Tor does not work because of the incorrect time. > > Manual workaround: > 1. Get the correct UTC from a browser. > 2. Open Dom0 Terminal and update to UTC such as the following: > > sudo date --set "2018-02-13 21:30" > > 3. Shutdown Service:sys-whonix > 4. Restart a whonix domain such as Domain:anon-whonix(this restarts the > sys-whonix service that was just shutdown. > 5. Then run WhonixCheck to make sure it works. It usually does and > Whonix/Tor is functional. > > = > Qubes cannot be this bad, really. > > How can I have this Date and time correctly updated on boot up? Like it > should. > > Thanks for all your help. > NSJ Try adding the following flags to date: -s -u Best, Daniel -- 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/48e76268-ea52-445d-9d65-9598fd78dfe5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Explain the error building 3.2?
On Friday, February 16, 2018 at 6:10:32 PM UTC-5, Tim W wrote: > On Friday, February 16, 2018 at 3:02:44 PM UTC-5, awokd wrote: > > On Fri, February 16, 2018 3:33 pm, 'awokd' via qubes-users wrote: > > > On Fri, February 16, 2018 9:43 am, Tim W wrote: > > > > > > > > >> The last two days I have been having issues building 3.2 have not tried > > >> 4.0 yet. > > >> > > > > > >> I get the the following errors in the template-stretch.log file. The > > >> Component fails on the stretch standard template build. All the Fedoras > > >> are good has not gotten to whonix yet for that component. > > > > > >> Installing new version of config file /etc/fstab ... > > >> chown: cannot access '/home_volatile/user': No such file or directory > > >> dpkg: error processing package qubes-core-agent (--configure): > > >> subprocess installed post-installation script returned error exit status > > >> 1 > > >> dpkg: dependency problems prevent configuration of > > >> qubes-input-proxy-sender: > > >> qubes-input-proxy-sender depends on qubes-core-agent (>= 3.0.25); > > >> however: > > >> Package qubes-core-agent is not configured yet. > > >> > > > > > > My build finally finished running; got the same fatal error you did. > > > > Might be some kind of interaction between > > https://github.com/QubesOS/qubes-core-agent-linux/pull/81/commits/41f568766f36e7f7588c14490196c906e57a2c22 > > (merged 4 days ago) and > > https://github.com/QubesOS/qubes-core-agent-linux/commit/00e846bbbe581aceeeaf4a8369748d4ff450b1b0. > > > > Want to open an issue on it? > > Yes I think so or at least I will post it over on devel. Those update I > think are likely the root of it. Maybe something small but the errors seem > to fit. > > I will post it over on dev and git. Issue opened: Qube 3.2 iso build error 'linux-template-builder' Stretch+Standard #3596 https://github.com/QubesOS/qubes-issues/issues/3596 -- 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/664d27ff-19d1-494d-8546-29eda35597c4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R4.0 rc4: Devices and VM tray icons disappeared
Hi all, After a recent reboot, the devices and VM tray icons no longer are appearing on boot in Xfce. I have no idea what might have caused this. There were no dom0 updates in the meantime. If I try to manually run them, e.g., python3 -mqui.tray.devices, I get the following: ERROR:dbus.proxies.Introspect error on org.qubes.DomainManager1:/org/qubes/DomainManager1: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying Followed by a backtrace, the relevant part appears to be: File "/usr/lib/python3.5/site-packages/qui/tray/devices.py", line 22, in DOMAINS = qui.models.qubes.DomainManager() Any advice would be appreciated, since with no icons, I'm also not appearing to get notifications for devices and VM actions. Best, Daniel -- 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/309f6c30-7df8-4065-be50-60aa36ee79ae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
