[qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
This is R4.1 build 20191013 It works pretty well, definitely better than 4.0, but there are some weird boot issues. If I let it boot with everything as default, it will boot loop before reaching the disk password screen. I found I can get it to boot successfully if I add to the Xen commandline noreboot=1 loglvl=all and remove from the linux commandline rhgb quiet rd.qubes.hide_all_usb Still working on narrowing down which of those is/are responsible for fixing the problem (I can't figure out why any of them would). Improvements since 4.0: Screen power management works - brightness controls, and screen poweroff after inactivity (in 4.0 it would just blank but not power off) Audio works, which it did not work in 4.0 even after many days of troubleshooting amdgpu works correctly - doesn't freeze when booting without nomodeset Multimedia keys - not sure if they worked in 4.0 or not Still working: UEFI mode wifi touchpad keyboard Still NOT working: Suspend/resume Not tested (yet): Legacy mode HDMI audio & video USB Qube SD card reader Microphone Webcam Wired networking I'll try to do some more testing and update this thread when I have a chance. Just putting this out there for now. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ae710f3839c46261d257d7d188da32b9%40disroot.org. Qubes-HCL-Dell_Inc_-Inspiron_5575-20191218-015203.yml Description: Binary data
Re: [qubes-users] AppVMs start but zero of the apps are starting? (with logs)
On 2019-12-19 01:16, Stumpy wrote: On 2019-12-18 19:08, Steve Coleman wrote: On 2019-12-18 07:57, Stumpy wrote: Last night I noticed that I was not able to start an appvm via dom0 (qvm-run appvm programname) so then tried to start another app in another appvm, nothing. I had a bunch of things open still from earlier in the afternoon so figured I needed to reboot, did, and still nothing, except I dont have any previous apps open up so my system is barely usable. When i try to run an app, say from the xfce menu (or directly from the dom0 terminal) I get the little pop up that the VM is starting, and it shows up in zentop and the qubes manager, but no app. I tried to start apps from the right click "run" option in the qubes manager but nothing, doesnt matter if the appvm is already running or not. The only thing i have done in dom0 in terms of "messing around" was to modify the sudo vi /etc/qubes/quid.conf so that one of my appvms would open w/o a border (which I since undid in attempts to get things working) i cant think of anything else i have done in dom0? This is killing me as I am not working on my work/win comp :( so any help would really really really be appreciated. Please let me know if there are any logs or something i should be posting? This sounds very similar to a problem I have been having (at home and at work), only your issue sounds like a much worse case of it. Ref: Qubes 4.0.1, Fedora-30 template When I come into work in the morning, or upon booting my workstation at home, if I launch an app in a non-running VM (sometimes subsequent re-launches of a VM) the app I used to initiate that VM does not come up. The pop-up message of the starting VM appears, then nothing. The VM gets started and the disk is whirring away, but the app never appears. If I launch the same app again sometimes both instances of that app appear one right after they other. Between those two invocations I might even wait until all the disk activity settles down and everything works fine. If for instance I use Qubes Manager to "update qube" the window almost never comes up the first time. The second time it will. If I start the template first and then select "update qube" it almost always comes up correctly, unless something is chewing up all the CPU or hitting the disk pretty hard. My issue seems to be related to too much activity of the AppVM's services creating enough lag to the system that the qrexec either times out or gets slowed down to the point of not completing the launching of the app. This is frustrating because after the first launch it seems to work better, so testing of why it isn't starting clearly needs to be planned in advance. Perhaps some resources get cached in memory the firt time so it starts that VM quicker, and thus the qrexec doesn't time out? I would suggest turning on the "Run in debug mode" option in the Qubes Manager's AppVM configuration so you can collect better logging information and see if that tells you anything. That is what I am planning to do tomorrow morning before launching anything. I had just turned it on for one VM this morning that sometimes acts up, and wouldn't you know it, it has not repeated that problem launching that VM the second time. Maybe tomorrow, or if I leave the machine alone for a while I might get it to repeat again. I think I will make a habit of turning on the debugging before launching any new VM's just in case I can catch it in the act of not acting properly. Thanks for pointing out where to turn the logging on. Questions though, I was attempting to look through the three logs of two different appvms but was not really sure where to start (was just shy of 6k lines). 1) Would posting the output to like a pastebin be useful/appropriate? 2) How sensitive is the info in the logs? (In looking through them it didnt seem like I was giving much info away but at the same time I am barely able to make sense of most of it). Thanks for the help, I of course want to get this figured out... I love my qubes box, all my friends live inside it :P Well as I have not been able to find (understand) anything wrote I thought I'd cross my fingers and post logs from two different appvms (debian and fedora). It occured to me though that if this is happening with all appvms, which it is, then perhaps its an issue with dom0 but anyway, am posting just in case. If there are dom0 logs that would be of use then please let me know. https://pastebin.com/LAXPSyBc -- 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/41680a113624af38566eb43d23a226bf%40posteo.net.
Re: [qubes-users] wipe released diskspace of a disposable VM's
On Wednesday, December 18, 2019 at 10:04:40 AM UTC-5, steve.coleman wrote: > > On 2019-12-15 22:04, brend...@gmail.com wrote: > My suggestion is, rather than the time consuming wiping of bits after > the fact would be to instead create an encrypted volume/partiton/pool > when launching a DispVM, and upon shutting it down you simply throw away > the key to that temporary volume. Without the key any data on that > encrypted volume would be unrecoverable, so then all you really need to > wipe is just the memory space that stored the runtime key's working > memory. If the key is generated before the volume is created then the > key would be only available to dom0 where the key's working memory space > can be managed properly and Qubes would be able to support any number of > guest OS's as a DispVM. > That is what I do via a bash script. LVM vg/pool on top of LUKS (as pv) on top of default LVM pool, and the luks layer uses /dev/urandom sourced key. However, due to some of the constraints of LVM (which, given the features it does provide, I *can* live with), I also need to move the templates to the temporary pool for the approach to work, so there's a time consuming (~4 minutes) setup time before the VMs are running. It's just a script, so execute, perform some other task for a bit and wait for windows to appear. When done with the sensitive task (or prepping for anti-forensics testing), user performs shutdown VMs, tell script you "done", and the script ensures all VMs are closed, then removes the above storage layers. -- There were some discussions in the qubes-issues ticket(s) about adding additional driver layers in the mix that might make utilizing a separate encrypted pool unnecessary. Other discussions involved performing the encryption inside the VMs, but as I mentioned earlier, if the content in the VM that is being manipulated is untrustworthy...then is the VM's internal encryption really trustworthy? > If the volume were intentionally stored on an Opal 2.0 SSD device you > could then use the built in SSD hardware capabilities of the 'encrypted > locking range' (up to four are possible if I remember correctly) for the > temporary workspace and when you destroy/reset the MEK (key) this will > instantly flip all the bits in the underlying hardware of that disk > region and make that range completely unrecoverable. OPAL ranges could be useful, but as they are also basically hardware managed partitions, I believe they would be difficult to utilize effectively, esp. if you want n (instead of a max 4 or 8) different secure areas (some permanent, some ephemeral). That being said, I do believe the opportunistic anti-forensics of trim/discard on a SED with DZAT might be useful (and hence my suggestion of utilizing trim through all layers and proposing to the qubes devs to blkdiscard before lvremove, which qubes now does). Also: some business use cases for permanent encrypted VMs have been given, e.g. keeping client A resources locked down while client B work is being performed or demo'd, etc. I would think LVM, esp. thin LVM, gives quite a bit of flexibility in sizing, adding/removing, etc. and would be applicable, perhaps with the additional encrypting driver layer discussed in the related qubes-issues items in github. Brendan -- 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/d77855e6-83d7-4b00-a451-d9c15d83d475%40googlegroups.com.
[qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide
So, I managed to get the instructions to work (albeit with a few modifications - I'll post them when/if I can figure out the GApps issue). However, I'm having issues whenever I try to include and compile GApps. I can confirm that Android-x86 will build successfully on its own, but when I include GApps in my device.mk, I get a lot of these after every GApps app build: End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. I then get these for each app before it all fails: Unable to open 'out/target/product/x86_64/obj/APPS/PixelLauncherIcons_intermediates/package.apk' for verification I've got the complete log, my device.mk, etc, but does anyone know what's up? On Thursday, December 12, 2019 at 9:20:54 PM UTC-6, arthur...@gmail.com wrote: > > Are the instructions in the first post edited and updated, or are there > more recent instructions which should be used? I'm personally interested in > an image with GApps (I downloaded the nogapps ISO and tried to somehow > install GApps, but to no avail - I wasn't sure if the image provided up > near the start of the thread was functional). If there are updated/verified > instructions that could be provided, that would be awesome! > > On Saturday, April 27, 2019 at 6:29:08 PM UTC-5, alex.j...@gmail.com > wrote: >> >> On Saturday, April 27, 2019 at 9:35:19 PM UTC, alex.j...@gmail.com wrote: >> > On Thursday, April 25, 2019 at 10:20:32 PM UTC, Daniil Travnikov wrote: >> > > I am stuck on this process already twice. >> > > >> > > When I put the command >> > > >> > > Download sources: >> > > repo sync --no-tags --no-clone-bundle --force-sync -j$( nproc --all ) >> > > >> > > >> > > and when it show this: >> > > >> > > >> > > From git://git.osdn.net/gitroot/android-x86/platform/frameworks/av >> > > * [new branch] nougat-x86 -> x86/nougat-x86 >> > > Fetching project platform/external/android-clat >> > > remote: Counting objects: 1, done >> > > remote: Finding sources: 100% (793/793) >> > > remote: Total 793 (delta 244), reused 793 (delta 244) >> > > Receiving objects: 100% (793/793), 517.38 KiB | 0 bytes/s, done. >> > > Resolving deltas: 100% (244/244), done. >> > > From https://android.googlesource.com/platform/external/android-clat >> > > * [new tag] android-7.1.2_r36 -> android-7.1.2_r36 >> > > >> > > >> > > I got nothing, I mean it's look like freeze. >> > >> > Did you try to remove downloaded repo and sync it again from scratch? >> The OpenGAPPS repo changed, see below, maybe it's somehow related. >> > >> > I'd recommend to build Android 8 release, the mouse works fine there. >> Also the Settings bug is fixed if you use userdebug build variant instead >> of eng. >> > The guide in the same as in first post except: >> > >> > Android 8 will take 211GB to build. I've build it with 32GB RAM without >> swap, maybe it'll work with less RAM. >> > >> > repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b >> oreo-x86 -m android-x86-8.1-r1.xml >> > instead of >> > repo init -u git://git.osdn.net/gitroot/android-x86/manifest -b >> android-x86-7.1-r2 >> > >> > https://github.com/opengapps/; /> >> > https://gitlab.nezorfla.me/opengapps/; /> >> > > revision="master" remote="opengapps" /> >> > > revision="master" remote="nezor" /> >> > > revision="master" remote="nezor" /> >> > > clone-depth="1" revision="master" remote="nezor" /> >> > instead of >> > https://github.com/opengapps/; /> >> > > revision="master" remote="opengapps" /> >> > > revision="master" remote="opengapps" /> >> > > revision="master" remote="opengapps" /> >> > > clone-depth="1" revision="master" remote="opengapps" /> >> > >> > lunch android_x86_64-userdebug >> > instead of >> > lunch android_x86_64-eng >> > >> > /usr/bin/make -C kernel O=$OUT/obj/kernel ARCH=x86_64 menuconfig >> > instead of >> > make -C kernel O=$OUT/obj/kernel ARCH=x86_64 menuconfig >> >> I've uploaded the working Android 8.1 iso for those who need it for a >> test, but I don't recommend to use it for security reasons and it's better >> to build the iso yourself: >> https://drive.google.com/open?id=1Y4P77mlPPlXBzYrJ5yHJ7XM6gLVsQQm0 >> >> md5sum android_x86_64-oreo-nogapps.iso >> b3af7a84820dd9fb32dd40c68f285993 android_x86_64-oreo-nogapps.iso >> >> sha1sum android_x86_64-oreo-nogapps.iso >> 16e9bcf0da44929b223fc2ab1df97de0df26d9fb android_x86_64-oreo-nogapps.iso >> sha256sum >> >> sha256sum android_x86_64-oreo-nogapps.iso >> b7d9aa5f9c401202ea24b63e95bb0f38d1f981381a719257c1a2f526e0cf636f >> android_x86_64-oreo-nogapps.iso >> >> sha512sum android_x86_64-oreo-nogapps.iso >> 16f2666a20499f31472fc933a670c47070e0db14686b605b69254d054dcc63893b564e5a35e84e1daf7b7fd80f955a2834956a1bb029e93563b7d8c44787666b >> >> android_x86_64-oreo-nogapps.iso >> >>
Re: [qubes-users] AppVMs start but zero of the apps are starting?
On 2019-12-18 19:08, Steve Coleman wrote: On 2019-12-18 07:57, Stumpy wrote: Last night I noticed that I was not able to start an appvm via dom0 (qvm-run appvm programname) so then tried to start another app in another appvm, nothing. I had a bunch of things open still from earlier in the afternoon so figured I needed to reboot, did, and still nothing, except I dont have any previous apps open up so my system is barely usable. When i try to run an app, say from the xfce menu (or directly from the dom0 terminal) I get the little pop up that the VM is starting, and it shows up in zentop and the qubes manager, but no app. I tried to start apps from the right click "run" option in the qubes manager but nothing, doesnt matter if the appvm is already running or not. The only thing i have done in dom0 in terms of "messing around" was to modify the sudo vi /etc/qubes/quid.conf so that one of my appvms would open w/o a border (which I since undid in attempts to get things working) i cant think of anything else i have done in dom0? This is killing me as I am not working on my work/win comp :( so any help would really really really be appreciated. Please let me know if there are any logs or something i should be posting? This sounds very similar to a problem I have been having (at home and at work), only your issue sounds like a much worse case of it. Ref: Qubes 4.0.1, Fedora-30 template When I come into work in the morning, or upon booting my workstation at home, if I launch an app in a non-running VM (sometimes subsequent re-launches of a VM) the app I used to initiate that VM does not come up. The pop-up message of the starting VM appears, then nothing. The VM gets started and the disk is whirring away, but the app never appears. If I launch the same app again sometimes both instances of that app appear one right after they other. Between those two invocations I might even wait until all the disk activity settles down and everything works fine. If for instance I use Qubes Manager to "update qube" the window almost never comes up the first time. The second time it will. If I start the template first and then select "update qube" it almost always comes up correctly, unless something is chewing up all the CPU or hitting the disk pretty hard. My issue seems to be related to too much activity of the AppVM's services creating enough lag to the system that the qrexec either times out or gets slowed down to the point of not completing the launching of the app. This is frustrating because after the first launch it seems to work better, so testing of why it isn't starting clearly needs to be planned in advance. Perhaps some resources get cached in memory the firt time so it starts that VM quicker, and thus the qrexec doesn't time out? I would suggest turning on the "Run in debug mode" option in the Qubes Manager's AppVM configuration so you can collect better logging information and see if that tells you anything. That is what I am planning to do tomorrow morning before launching anything. I had just turned it on for one VM this morning that sometimes acts up, and wouldn't you know it, it has not repeated that problem launching that VM the second time. Maybe tomorrow, or if I leave the machine alone for a while I might get it to repeat again. I think I will make a habit of turning on the debugging before launching any new VM's just in case I can catch it in the act of not acting properly. Thanks for pointing out where to turn the logging on. Questions though, I was attempting to look through the three logs of two different appvms but was not really sure where to start (was just shy of 6k lines). 1) Would posting the output to like a pastebin be useful/appropriate? 2) How sensitive is the info in the logs? (In looking through them it didnt seem like I was giving much info away but at the same time I am barely able to make sense of most of it). Thanks for the help, I of course want to get this figured out... I love my qubes box, all my friends live inside it :P -- 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/9946544e48235bcc37de33e5171120b4%40posteo.net.
Re: [qubes-users] Soundquality
Myros: Hi Claudia, thanks for your response aplay -l responds this: card 0: PCH HDA INTEL PCH device 0 ALC255 analog the other command does work, but i dont know how to export those from dom 0 and its like 2 pages long, i hope it works without these infos. If you just want to copy a few lines, select text with the mouse, right click, and choose "copy" (don't use Ctrl-C in terminal), then press Ctrl-Shift-C, switch your browser/email in another VM, and then Ctrl-Shift-V. For the whole file, run `lspci -k > ~/lspci.txt` then `qvm-copy-to-vm anon-whonix ~/lspci.txt` (replace anon-whonix with the name of the VM you want to copy to). Then it will appear in that VM under /home/user/QubesIncoming/dom0. gain was already 0 where do i set these model= ? I will look into kernel upgrades. That's what I would try first because it's simple to do. `qubes-dom0-update kernel-latest` should be fine. Although, I don't think your card is very new, so a kernel upgrade may not fix anything. Greez Myros Also, try modifying your alsa configuration as described here: https://askubuntu.com/questions/1108825/laptops-speakers-sound-bad-poor-sound-quality For specifying a model: `sudo nano /etc/modprobe.d/alsa-base.conf` add a line "options snd_hda_intel " followed by the parameters you want. Save and reboot. For example, options snd_hda_intel enable_msi=0 model=dell-spk-noise power_save=0 power_save_controller=N Here is a list of models. Look under the section for your card, "ALC22x", and see if any of them sound like your machine. There may be more than one and it will take some trial and error. https://www.kernel.org/doc/html/latest/sound/hd-audio/models.html#alc22x-23x-25x-269-27x-28x-29x-and-vendor-specific-alc3xxx-models Note you can also try the special parameter "model=generic", which can fix a wide range of different problems. Tip: go into the qubes manager -> VM settings, and make sure "start VM at boot" is unchecked for all VMs. This will make rebooting much faster. See also https://www.kernel.org/doc/html/latest/sound/hd-audio/index.html https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html https://www.alsa-project.org/wiki/Help_To_Debug_Intel_HDA#.27model.27_parameter - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- 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/96f271af-d018-4cab-4a66-6b72a6e3fa65%40vfemail.net.
Re: [qubes-users] How to access installer in rescue mode?
Robert M: I'm trying to install Qubes 4.0 on laptop that has UEFI firmware (without the Legacy option) But I cannot get to the blue boot screen. The official "Troubleshooting UEFI related problems", requires me to switch to tty2 (Ctrl+Alt+F2) . But seems that there is no combination of keys that stops the boot process before it goes to the black screen. Any hint or suggestion on how to get the installation to start would be much appreciated. You modified the BOOTX64.cfg file, right? And it's still freezing at a black screen? What kind of GPU do you have? Is the machine still responsive, other than the screen? E.g. does the caps lock key make the light come on? Or does ctrl-alt-delete reboot it? I had a kind of similar problem on 4.0.2-rc2 with amdgpu graphics. Adding "nomodeset" to the kernel command line fixed it. Before I figured that out, in the installer, I found I could press ctrl-alt-f2 repeatedly very early in the boot process, and about 50% of the time it would switch to TTY and not freeze. No idea if it'll work for you, but it's worth a try. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- 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/af4f0622-8802-5fe1-d5e2-05b690654db4%40vfemail.net.
Re: [qubes-users] AppVMs start but zero of the apps are starting?
On 2019-12-18 19:08, Steve Coleman wrote: On 2019-12-18 07:57, Stumpy wrote: Last night I noticed that I was not able to start an appvm via dom0 (qvm-run appvm programname) so then tried to start another app in another appvm, nothing. I had a bunch of things open still from earlier in the afternoon so figured I needed to reboot, did, and still nothing, except I dont have any previous apps open up so my system is barely usable. When i try to run an app, say from the xfce menu (or directly from the dom0 terminal) I get the little pop up that the VM is starting, and it shows up in zentop and the qubes manager, but no app. I tried to start apps from the right click "run" option in the qubes manager but nothing, doesnt matter if the appvm is already running or not. The only thing i have done in dom0 in terms of "messing around" was to modify the sudo vi /etc/qubes/quid.conf so that one of my appvms would open w/o a border (which I since undid in attempts to get things working) i cant think of anything else i have done in dom0? This is killing me as I am not working on my work/win comp :( so any help would really really really be appreciated. Please let me know if there are any logs or something i should be posting? This sounds very similar to a problem I have been having (at home and at work), only your issue sounds like a much worse case of it. Yeah, its killing me. I dont suppose you have figured out a fix? A detail that i forgot to mention is that, AKAIK all the dom0 apps are opening ok, so the terminal program, task manager, system settings etc... just *no* appVMs. Please, Qubes Gurus, any help would really be appreciated! Ref: Qubes 4.0.1, Fedora-30 template When I come into work in the morning, or upon booting my workstation at home, if I launch an app in a non-running VM (sometimes subsequent re-launches of a VM) the app I used to initiate that VM does not come up. The pop-up message of the starting VM appears, then nothing. The VM gets started and the disk is whirring away, but the app never appears. If I launch the same app again sometimes both instances of that app appear one right after they other. Between those two invocations I might even wait until all the disk activity settles down and everything works fine. If for instance I use Qubes Manager to "update qube" the window almost never comes up the first time. The second time it will. If I start the template first and then select "update qube" it almost always comes up correctly, unless something is chewing up all the CPU or hitting the disk pretty hard. My issue seems to be related to too much activity of the AppVM's services creating enough lag to the system that the qrexec either times out or gets slowed down to the point of not completing the launching of the app. This is frustrating because after the first launch it seems to work better, so testing of why it isn't starting clearly needs to be planned in advance. Perhaps some resources get cached in memory the firt time so it starts that VM quicker, and thus the qrexec doesn't time out? I would suggest turning on the "Run in debug mode" option in the Qubes Manager's AppVM configuration so you can collect better logging information and see if that tells you anything. That is what I am planning to do tomorrow morning before launching anything. I had just turned it on for one VM this morning that sometimes acts up, and wouldn't you know it, it has not repeated that problem launching that VM the second time. Maybe tomorrow, or if I leave the machine alone for a while I might get it to repeat again. I think I will make a habit of turning on the debugging before launching any new VM's just in case I can catch it in the act of not acting properly. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6f37c5e28b45651003fc1862ffc49722%40posteo.net.
[qubes-users] What is the proper firewall rule(s) to use dnscrypt-proxy?
Good day, I have dnscrypt-proxy working in sys-net only. But I am stuck on how to forward dns requests moving from sys firewall and the vms behind it so that sys-net can route them out via the proxy. I only have dnscrypt-proxy running, it is not combined with unbound or dnsmasq. The firewall rule in sys-firewall is Chain PR-QBS (1 references) pkts bytes target prot opt in out source destination 169 DNAT udp -- * * 0.0.0.0/0 10.139.1.1 udp dpt:53 to:10.139.1.1 0 0 DNATtcp -- * * 0.0.0.0/0 10.139.1.1 tcp dpt:53 to:10.139.1.1 0 0 DNATudp -- * * 0.0.0.0/0 10.139.1.2 udp dpt:53 to:10.139.1.2 0 0 DNATtcp -- * * 0.0.0.0/0 10.139.1.2 tcp dpt:53 to:10.139.1.2 and in sys-net it is Chain PR-QBS (1 references) pkts bytes target prot opt in out source destination 16 960 DNAT udp -- * * 0.0.0.0/0 10.139.1.1 udp dpt:53 to:127.0.0.1 00 DNAT tcp-- * * 0.0.0.0/0 10.139.1.1 tcp dpt:53 to:127.0.0.1 14 840 DNAT udp -- * * 0.0.0.0/0 10.139.1.2 udp dpt:53 to:127.0.0.1 00 DNAT tcp-- * * 0.0.0.0/0 10.139.1.2 tcp dpt:53 to:127.0.0.1 My firewall routing is self taught and not great but from the looks of it dns requests from sys-firewall are being forwared to sys-net on 10.139.1.1 which is receiving them and forwarding them to 127.0.0.1 which is what dnscrypt is using. Yet with it running I cannot resolve any dns outside of sys-net. thanks in advance -- 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/c8911f36-ad79-4275-8b07-52cbfb7da7f0%40googlegroups.com.
Re: [qubes-users] AppVMs start but zero of the apps are starting?
On 2019-12-18 07:57, Stumpy wrote: Last night I noticed that I was not able to start an appvm via dom0 (qvm-run appvm programname) so then tried to start another app in another appvm, nothing. I had a bunch of things open still from earlier in the afternoon so figured I needed to reboot, did, and still nothing, except I dont have any previous apps open up so my system is barely usable. When i try to run an app, say from the xfce menu (or directly from the dom0 terminal) I get the little pop up that the VM is starting, and it shows up in zentop and the qubes manager, but no app. I tried to start apps from the right click "run" option in the qubes manager but nothing, doesnt matter if the appvm is already running or not. The only thing i have done in dom0 in terms of "messing around" was to modify the sudo vi /etc/qubes/quid.conf so that one of my appvms would open w/o a border (which I since undid in attempts to get things working) i cant think of anything else i have done in dom0? This is killing me as I am not working on my work/win comp :( so any help would really really really be appreciated. Please let me know if there are any logs or something i should be posting? This sounds very similar to a problem I have been having (at home and at work), only your issue sounds like a much worse case of it. Ref: Qubes 4.0.1, Fedora-30 template When I come into work in the morning, or upon booting my workstation at home, if I launch an app in a non-running VM (sometimes subsequent re-launches of a VM) the app I used to initiate that VM does not come up. The pop-up message of the starting VM appears, then nothing. The VM gets started and the disk is whirring away, but the app never appears. If I launch the same app again sometimes both instances of that app appear one right after they other. Between those two invocations I might even wait until all the disk activity settles down and everything works fine. If for instance I use Qubes Manager to "update qube" the window almost never comes up the first time. The second time it will. If I start the template first and then select "update qube" it almost always comes up correctly, unless something is chewing up all the CPU or hitting the disk pretty hard. My issue seems to be related to too much activity of the AppVM's services creating enough lag to the system that the qrexec either times out or gets slowed down to the point of not completing the launching of the app. This is frustrating because after the first launch it seems to work better, so testing of why it isn't starting clearly needs to be planned in advance. Perhaps some resources get cached in memory the firt time so it starts that VM quicker, and thus the qrexec doesn't time out? I would suggest turning on the "Run in debug mode" option in the Qubes Manager's AppVM configuration so you can collect better logging information and see if that tells you anything. That is what I am planning to do tomorrow morning before launching anything. I had just turned it on for one VM this morning that sometimes acts up, and wouldn't you know it, it has not repeated that problem launching that VM the second time. Maybe tomorrow, or if I leave the machine alone for a while I might get it to repeat again. I think I will make a habit of turning on the debugging before launching any new VM's just in case I can catch it in the act of not acting properly. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4448b0a1-e5d6-ebf1-c5da-acab964c12fb%40jhuapl.edu.
[qubes-users] AppVMs start but zero of the apps are starting?
Last night I noticed that I was not able to start an appvm via dom0 (qvm-run appvm programname) so then tried to start another app in another appvm, nothing. I had a bunch of things open still from earlier in the afternoon so figured I needed to reboot, did, and still nothing, except I dont have any previous apps open up so my system is barely usable. When i try to run an app, say from the xfce menu (or directly from the dom0 terminal) I get the little pop up that the VM is starting, and it shows up in zentop and the qubes manager, but no app. I tried to start apps from the right click "run" option in the qubes manager but nothing, doesnt matter if the appvm is already running or not. The only thing i have done in dom0 in terms of "messing around" was to modify the sudo vi /etc/qubes/quid.conf so that one of my appvms would open w/o a border (which I since undid in attempts to get things working) i cant think of anything else i have done in dom0? This is killing me as I am not working on my work/win comp :( so any help would really really really be appreciated. Please let me know if there are any logs or something i should be 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/4687de94272f70a69e2741c54a722d05%40posteo.net.
