[qubes-users] Re: Starting Win10 HVM install crashes Qubes, and other bugs
On 4/1/19 2:15 AM, Mindus Amitiel Debsin wrote: On Sunday, March 31, 2019 at 2:22:21 PM UTC-7, awokd wrote: Try finding the BDF of that SATA controller with lspci in dom0, then making Xen/Qubes ignore it by adding xen-pciback.hide=(0x:0y.z) to the boot options (where xyz=BDF). It might not like having it surprise removed when the VM grabs it. Then reboot, assign it to your HVM, and attempt your custom ISO again. I will get to this good advice as soon as I'm done with my current problem. I was doing a lot of reading on the Qubes-users group and also through the Qubes docs site, and I decided to update my kernel in dom0 using the sudo qubes-dom0-update kernel-latest console command. I did this for several reasons, including the fact that I have no sound. While the update was successful, when I restarted the computer, there were several problems. 1) The HDD decrypt password is invisible. It's just a blank screen until you type something, and then it shows a text based prompt for the password. 2) There are huge graphical artifacts in the user password prompt screen. 3) After a successful password entry in the user password prompt screen, it briefly boots into the Qubes desktop and then immediately goes back to the password prompt. It does this repeatedly, with no escape. If you enter the wrong password, it functions correctly and tells you that it is the incorrect password. I am hoping there is troubleshooting that I can do to change my boot options, or that somebody else has faced this problem as well. Otherwise I will want to roll back the kernel, but I hope that I don't have to. Here are my computer specifications: Mobo: Asus Sabertooth x79 CPU: Intel i7 3930k 6 core @ 3.2ghz RAM: G-skill Ripjaws 4gb x 8 sticks in quad-channel, XMP profile @ 3.2 ghz (I believe) GPU1: AMD RX 580 8gb [XFX brand] GPU2: AMD RX 460 4gb [XFX brand] Boot HDD: Seagate 2TB Firecuda hybrid drive. Other HDDs: 1TB Toshiba OCZ SATA SSD. 3TB Toshiba Sata HDD. Thanks! it's great your enthusiastic , but in my years of using qubes, I'm never done anything but the sudo qubes-dom0-update initially I tried to get win7 working in 3.2 , and it did breifly , till I did something wrong, then it never was the same, I believe the windows tools is more like a semi supported feature no one seems to use of talk about. qubes is qubes , you can dual boot on a separate HD, otherwise there is enough to learn without trying to get fancy unless you got the time and "skillz" IMO if you don't have sound there are various other reasons have nothing to do with dom0 welcome -- 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/5c5d1454-1de3-4476-e5ad-8f36f64a5186%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: dom0 environment lost on restore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/04/2019 8.04 AM, Ryan Tate wrote: >> On Apr 1, 2019, at 10:01 PM, Andrew David Wong >> wrote: On 01/04/2019 2.54 PM, Ryan Tate >> wrote: >>> >>> If the wish is not “restore” but rather to copy some files — >>> “some files and scripts that I need” — then it is up to the >>> user to transfer these files by the usual mechanism. >>> >> >> What is "the usual mechanism"? The main problem with the old >> behavior was that there was no reasonable way to get the dom0 >> home files out of the backup without clobbering the current dom0 >> home files that you want to keep. > > The usual mechanism would be however you would normally move files > from one machine to another. Not the backup/restore mechanism, > since he scenario of wanting to move some files and scripts to a > new machine is not backup/restore. > In Qubes OS, qvm-backup[-restore] *is* the usual mechanism for moving dom0's home and VMs from one machine to another. This is because it is a violation of the Qubes security model to move files from a less trusted VM to dom0, and every other VM is, by definition, less trusted than dom0. Therefore, qvm-backup[-restore] is the only official, secure way to move files into dom0. Sure, maybe this doesn't fit some narrow, technical definition of "restore," but so what? For practical purposes, how does that affect users in the real world who are trying to get things done securely? If it really mattered, we could generalize the name to avoid using the word "restore," but the name doesn't really matter to that degree. For what it's worth, a lot of dedicated backup software also doesn't abide by this narrow definition of "restore." For example, a lot of backup software will deliver your restored files to you as a download, via email, or in a location other than the original location or computer from which they were backed up. "Backup and restore" doesn't have to mean restoring an entire machine state. In Qubes, it's about user-data-level backup. Using qvm-backup on dom0 is not intended to duplicate the functionality of lvm snapshot. > Why is file transport being shoehorned into the backup mechanism? > In order for some people to use restore for something other than > restore, I had to spend a bunch of time navigating through obscure > folders, copying with globs and mv and shunting aside old dirs, > restarting (multiple times), and crossing my fingers it would > work. Shouldn’t it be users who are doing strange, non > backup/restore things who have to jump through hoops, and people > who simply want to restore dom0 who get helpful default behavior? > All you had to do was move everything out of the restored subdirectory: $ mv home-restore-2019-04-01-etc/* . # move all normal files out $ mv home-restore-2019-04-01-etc/.* . # move all hidden files out Simple, quick, and easy, with no weird hoops to jump through. Now, don't get me wrong. I understand perfectly well that it's only "simple, quick, and easy" _if you know what to do_ and that this will _not_ be obvious to many users. But that's precisely why I suggested that it should be an option via qvm-backup-restore and the GUI tool. Make it discoverable so that users can understand that there are two possible outcomes and choose the one they want, then do it for them. > If people seem open to a change I’ll file an enhancement request. > Since I was already writing all this, I just went ahead and opened an issue for it: https://github.com/QubesOS/qubes-issues/issues/4946 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlykPh0ACgkQ203TvDlQ MDBe0w/+MdEEYakxVkGf1fA9lWl0gRM2wByzik0qR6yAjadA0JjdFB6zYNmSoW+7 Y0m2DLQ3N9CtA4dW/hcphJu0ujyNiV4HC0MVdbHPhsOSQSLckJ1wCrXR1zUPYDL2 egsB1cseT7n101y/zZt78DD9iCImurtkQZuF1wRHlYl8iVTgS+nE6BOPOxFd4rns htX939BJrzhPWPh0etra2c6SupNxBBJgtOieEMkHcFY+BiE9rH36bbia6JWJXDYk 1sVGggUM6LgteqCwKHr9bRB40rpllMLG9/k/uisPvEP9wBj2Z1eMJ8Vro0zcIexF 2aoRy1vMSNZuT49C3T6+ABvdcr+eqN9ahssMSDP5zitqTPZwgncAoPubTRaKmUth ST/50Cps3Hy7d5aYv8T/h1rClfwlw0c8tctYwFzjaeN45Vqjc7cAZzwv6IKOGPhE WLcIs46JDHpYbbxi1Tdb1FUYiFVShSUacVzHI+G6tQBVJ3n0Lh3r65ByYhiAexHJ HksFGMjDaJYF9dYeBwAtXgofCeOgYrIb1MR0Km7SnlRj9Acts/RrmGUS3ep8wm5/ MsLB+ykdujVFKahMi7mtCM717jMaahNCPxnU3gMCIUy8LqUo70vKFDR+xWG6AB6B piCB6wFYibkJPJjf4DagJJERnj7p6ej53+ZntZ9ZPohI/wfswKE= =+k1V -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/2908866c-d372-ba40-602d-394c58a44199%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Can't Start Network, V4
awokd, > You do have to do it with sudo. In dom0, you are trying "sudo ls > /var/log/libvirt/libxl"? Thank you. I tried that and it did not work. You brought me back and now its working. -- 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/1881d85b-3da8-42a2-b919-593685d29ecd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] how to connect an external USB keyboard to a Linux HVM
Claudio Chinicz: Hi Folks, I'm willing to use my Qubes notebook as my main notebook in a corporate environment. One of the things I use daily is an external keyboard, which cannot be hooked to my Linux Mint 19.1 Cinnamon 64 bits HVM because qurexec is not present. Anyone has done it before? I'm looking for how to install qurexec on Linux Mint, hoping that it will let me attach the USB keyboard to the HVM. I might be missing a requirement, but why not connect your USB keyboard to your notebook as a "Qubes" keyboard (https://www.qubes-os.org/doc/usb-qubes/#automatic-setup)? Then you could use it for everything, including the HVM. -- 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/702b7c43-0f30-f03b-5af7-5894ca9e290f%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] debian 10 minimal ... issue with update proxy
You need to enable the qubes-update-proxy service - this creates the necessary file at /var/run/qubes-service/qubes-updates-proxy There's another issue in that the service file refers to /usr/sbin/tinyproxy but the exec is in /usr/bin Fix this by editing /lib/systemd/system/qubes-updates-proxy.service to refer to the correct path. Dear qubes-users, dear Unman, I tried to follow these instructions, but I am stuck. There is an odd spelling issue, sometimes I read *updates* (plural), sometimes *update* (singular). I presume the service name is meant to be in plural: qubes-updates-proxy ? I have actually tried both, singular and plural, but it won't work I rebooted each time): the plural version generates the file /var/run/qubes-service/qubes-updates-proxy but it has zero size. Is this normal? And this file /lib/systemd/system/qubes-updates-proxy.service you mention does simply not exist.Any hints? -- 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/a32ef3e6-3e23-e497-3182-5640f841291b%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] how to connect an external USB keyboard to a Linux HVM
Hi Folks, I'm willing to use my Qubes notebook as my main notebook in a corporate environment. One of the things I use daily is an external keyboard, which cannot be hooked to my Linux Mint 19.1 Cinnamon 64 bits HVM because qurexec is not present. Anyone has done it before? I'm looking for how to install qurexec on Linux Mint, hoping that it will let me attach the USB keyboard to the HVM. Thank you all in advance, Claudio -- 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/q7s6h4%2438v9%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Update checking over clearnet instead of Tor?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 02, 2019 at 01:20:54PM +1100, haaber wrote: > > On Tue, Apr 02, 2019 at 07:19:46AM +1100, haaber wrote: > > > > > > So do I understand that correctly: if I have, say, a debian-XYZ AppVM on > > > clearnet it will check if the corresponding template needs an update, > > > unless I de-activate the qubes-update-check service? Thank you > > > > Yes > > > > Oups ! To me, one of the points of using tor as upgrade-transport-layer > seems to me to render "aimed attacks" on *my* machine much harder. Is > that a misconception? > Assuming that 'yes', an attacker would typically see clearnet apt-update > preceding a tor-based upgrade -- and could be made a reasonable guess > *who* is upgrading (I don't think there are millions of qubes copies > running, right?). This opens a (admittedly) small, probability-based > attack surface, that comes only with small gain, if ever. Do you agree? The updates _check_ only needs to download repository metadata, not actual packages. Qubes based on a template do that from time to time, using own network connection and report if there are any updates available. When you actually download and install those updates (over Tor) in the template is up to you, it isn't immediately after checking if something is available, so time based correlation isn't really an issue here. - -- 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/THMrX1ywFAlyjhOoACgkQ24/THMrX 1yzrVgf/cpAa8ZF7aw1UUkMVW3L+YndBFVOmH0vG1XZ1ppQ3RqG/5OpZnG+eSaQV l2iyMMWpSDKY6niHEEhXIHBGO17ABmZcybvMe8jGtovm6e+kwRa1ef1yarSI3aLL W2IcAFoo2XYRVpO+/sGWFD0WHNdIzqcVVNK5o45MKnJPgb+ZQ3+Wg7h9nbU3NCMh zTlUHjW59gGgx1IKtylc69IM/zgBxKysfrC6SuTRTid2YGpUNfqyMR+oj+FEa2W9 VMoySbjOUnAxrOydvFyUL8vTZ/w1rDNpGAoWyUBcCoUmpDW9ZdfCCYuO1l2fWbE6 SZexjBIGsEzKbDfm2dD9HQT4VPicbQ== =bswd -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/20190402155106.GA22235%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Windows 10 and 7 X64 installation in UEFI mode
I could accomplish Windows 10 and 7 X64 installation by following the steps given in the link below: https://www.qubes-os.org/doc/windows-vm/ I have followed steps given under Qubes 4.0 - Windows VM installation. I have not installed QWT in Windows 10 and 7 X64. I notice that both installations are under legacy BIOS. I would like to install them under UEFI BIOS for faster loading speed. I have also installed windows10 under virtualbox in UEFI mode and I can see the difference in loading speed. Is there a way to install windows 10/7 under UEFI mode in Qubes 4.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/dd857c18-b094-4ad8-872e-89677b760e32%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Only 4 CPUs are brought up. Remaining 4 are parked.
On Wednesday, March 27, 2019 at 2:45:12 PM UTC+5:30, Lorenzo Lamas wrote: > Afaik the specific attack only worked on Intel CPU's, OpenBSD disables SMT on > other manufacturers as well as they believe other CPU's have similar issues. > I run Qubes on an Intel machine, so I have SMT disabled, but haven't noticed > any performance hit. Thanks for your input. However I have gone ahead and enabled all 8 CPUs. I am ready to take some risk. -- 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/1cd14c11-b840-4868-a55d-d15390ea80c2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: dom0 environment lost on restore
> On Apr 1, 2019, at 10:01 PM, Andrew David Wong wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 01/04/2019 2.54 PM, Ryan Tate wrote: >> >> If the wish is not “restore” but rather to copy some files — “some >> files and scripts that I need” — then it is up to the user to >> transfer these files by the usual mechanism. >> > > What is "the usual mechanism"? The main problem with the old behavior > was that there was no reasonable way to get the dom0 home files out of > the backup without clobbering the current dom0 home files that you > want to keep. The usual mechanism would be however you would normally move files from one machine to another. Not the backup/restore mechanism, since he scenario of wanting to move some files and scripts to a new machine is not backup/restore. Why is file transport being shoehorned into the backup mechanism? In order for some people to use restore for something other than restore, I had to spend a bunch of time navigating through obscure folders, copying with globs and mv and shunting aside old dirs, restarting (multiple times), and crossing my fingers it would work. Shouldn’t it be users who are doing strange, non backup/restore things who have to jump through hoops, and people who simply want to restore dom0 who get helpful default behavior? If people seem open to a change I’ll file an enhancement request. > -- 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/5ABDF147-BDAD-4F02-93DA-0FB5594669D2%40ryantate.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: dom0 environment lost on restore
On 4/1/19 6:36 PM, 'awokd' via qubes-users wrote: Ryan Tate wrote on 4/1/19 7:54 PM: On Apr 1, 2019, at 2:33 PM, Ryan Tate wrote: Now I see there is a folder in my dom0 home dir called ‘home-restore-2019-04-01-etcetc’. But what do I do with this? I just have to manually figure out what files are important? :-\ I just sort of methodically copied over anything that seemed important and rebooted which seems to get me most of the way there. I would like to say, I really think the wrong decision was made here: https://github.com/QubesOS/qubes-issues/issues/2271 https://github.com/QubesOS/qubes-issues/issues/1106 The rationale for not actually restoring dom0 when dom0 is requested to be restored seems to be: 1.User may be restoring to a different machine from the original, which could obviate e.g. monitor settings. User can’t simply avoid restoring dom0 in this situation "because it contains some files and scripts that I need” (quote from issue 2271). OR 2. user may only restore some VMs and then the dom0 restore will create false menus (issue 1106) I would argue, if you ask to restore dom0, then dom0 should be restored (truly, not by copying over a directory, which is not a “restore”). Any glitches due to, for example, restoring dom0 to a different machine, are the responsibility of the user. User may also need to handle restoring dom0 with only partial vm restore, for example by purging appmenus (although ideally the restore process or architecture of Qubes would make partial restores happen more smoothly). If the wish is not “restore” but rather to copy some files — “some files and scripts that I need” — then it is up to the user to transfer these files by the usual mechanism. IMO Qubes has allowed the definition of “restore” to become a bit corrupted. To restore is not just to copy a directory and let the user fend for themselves. When I “restore”, the original state should largely come back. e.g. app menus in vms, xfce panel particulars, desktop particulars, etc. If I want something different, for example only to copy some settings over, it should be up to me as a user to make that happen. If the restore is imperfect, that is OK — it would be better to have an imperfect restore (with, for example, some phantom menus) than to have no restore at all, from the standpoint of user expectations, judging purely from myself. These seem like reasonable points though for visibility & tracking, it might be better to paste them directly into one of those issues. The current method prevents an unsafe restore in the event that the system was reinstalled due to a compromise (or suspicion thereof). This change was made shortly after Qubes project started promoting the idea of "paranoid mode" restore, with which it fits very well. In any case, the object for qvm-backup* isn't to save/restore everything about dom0 since it only stores /home. And moving these files out of the restore folder is relatively easy, if the user chooses. -- 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/3ab58309-e8c4-0576-9fd8-3f2c42a3f0da%40posteo.net. For more options, visit https://groups.google.com/d/optout.
