Re: [qubes-users] Help with qubes-vpn-support
l...@firemail.cc:
> I'm setting up wireguard, but encountered an issue with
> qubes-vpn-support (https://github.com/tasket/Qubes-vpn-support).
>
> Traffic from my vpn proxyvm ('sys-mullvad') is getting through. Apt
> updates and installations, wget, ping, etc all work from within
> sys-mullvad. I don't think this is expected behavior.
What do you mean "getting through"? Is it going through the vpn or going
over your local network?
If it is the former, then there is no issue. Traffic originating from
the vpn proxy vm should go out over the vpn.
~abel
--
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/ae33b113-5729-e3d9-0682-070908a32c19%40guardianproject.info.
Re: [qubes-users] Can split-pgp work with my yubikey?
Guerlan: > I want to use my yubikey to ssh from all my Qube VMs to my server. To do > that I need pgp to interact with my yubikey. It's almost like > https://www.qubes-os.org/doc/split-gpg/ but with the yubikey inside a > 'trusted' AppVM instead of a private key inside a 'trusted' AppVM > > Is it possible? > Yes, it works fine. Just attach your yubikey device to the gpg vm and it will work out of the box. ~abel -- 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/c5051d91-bc37-4da9-7d77-a5a5dc0b4393%40guardianproject.info.
Re: [qubes-users] Wireguard on Debian 10 from Qubes-vpn-support
Chris Laprise: > On 2/17/20 6:09 PM, Daniil Travnikov wrote: >> I am looking right now on this guide: >> https://github.com/tasket/Qubes-vpn-support/wiki/Wireguard-VPN-connections-in-Qubes-OS >> >> >> So have a question: is it possible to do this on Debian 10 ? > > Debian 10 now has wireguard packages in 'testing', not just 'unstable'. > So that is different. > > TBH the one time I remember testing this on Debian 10, I did something > like this: > > 1. Install the 'kernel-latest-qubes-vm' package in dom0. This will > provide a 5.x kernel with wireguard module built-in. Set your VPN VM to > use this kernel. > > 2. Install only the 'wireguard-tools' package (from testing) in Debian > 10. Otherwise, there may be a conflict between the built-in and DKMS > modules. > > 3. Given the above, it may now be possible to skip using HVM mode > altogether. The way Chris describes is probably the proper way to do it now. However I can confirm that the OP's linked instructions work fine on debian 10: * debian-10-wireguard HVM template * install wireguard from testing/unstable ~abel -- 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/0eac37d2-59d0-90e9-77f4-30386dfb9329%40guardianproject.info.
Re: [qubes-users] I am experiencing various problems with my OS
'Rock Francis' via qubes-users: > I've always had trouble with any Linux Beast OS from my original PC to my > original laptop. > > But the biggest problem that I'm facing right now is unlocking my ability to > connect through my ethernet cable, I keep running into the problem know as > "libexlight" or something. > This is not near enough information to enable someone on this list to help troubleshoot your issue. Please provide the following, and perhaps someone will be able to respond: * details of the hardware you're running * details of the OS you're running * specific error message * context of the error message (what you're doing when it appears) ~abel -- 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/a2e14866-48eb-8f00-21be-35f16c7cbe2b%40guardianproject.info.
Re: [qubes-users] Fedora kernel for VM
'awokd' via qubes-users: > Asad Manzur: >> Hi >> I've been searching around but I can't find any documentation on how to >> install fedora vanilla kernel for a VM. Can anyone guide me in the correct >> direction please. I am wanting to use vanilla Fedora kernel so that I can >> run my Intel AX200 WiFi card on my Clevo laptop. >> Thanks for your help >> > https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm > I've tried this against debian-10-minimal template vm, and it doesn't seem to work. Any idea if there's something special needed to turn a debian-10-minimal into an HVM vm that can boot its own kernel? ~abel -- 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/c26322d3-7850-6029-f135-245765d46c5d%40guardianproject.info.
Re: [qubes-users] Debugging a sleep/suspend problem on Razer Blade Stealth 2016 - Qubes
Abel Luck: > Hi there, > > I'm debugging similar resume issues, though on different hardware. > Hopefully you don't mind if we share tips in this thread. > > >>> I couldn't find anything related to those acpi devices. I thougth first >> that there was a driver for >>> them, so I should just rmmod those drivers before sleep and insmod when >> wakeup, but couldn't find >>> anything. There's this issue >> https://ubuntuforums.org/archive/index.php/t-2393029.html which have >>> those exact hash matches, but no answer. >> >> I don't know a lot about pm_trace, but it seems like there might be a >> problem decoding the hash. >> Normally it should show you a PCI address, /sys device name, driver name, >> or something more >> specific (see example in link below). >> >> According to s2ram kernel documentation: >> >> If no device matches the hash (or any matches appear to be false >> positives), the culprit may be a >> device from a loadable kernel module that is not loaded until after the >> hash is checked. You can >> check the hash against the current devices again after more modules are >> loaded using sysfs: >> >> cat /sys/power/pm_trace_dev_match >> >> https://www.kernel.org/doc/html/latest/power/s2ram.html#using-trace-resume >> >> However, in qubes we may also have the opposite problem. Qubes takes over >> your network cards and >> sometimes USB controllers in early userspace, so the drivers are not >> available anytime. To disable >> this behavior for USB controllers, remove rd.qubes.hide_all_usb from the >> kernel cmdline. For >> network cards it's a little more complicated. >> >> You can try modifying the qubes initramfs hook. First, make sure there are >> no VMs configured to >> start automatically at boot. Move >> /usr/lib/dracut/modules.d/90qubes-pciback/ to your home >> directory, or open the qubes-pciback.sh file and comment out the last 9 or >> so lines (from "for dev >> in $HIDEPCI"). Rebuild the initramfs. Then, do the pm_trace again as you >> did before. Then, try >> pm_trace_dev_match as described in the link above. >> >> It might give you better information about the problem device, or it might >> just give you the same >> info as before, but it's something to try. >> >> If it doesn't work, don't forget to put that file back how it was, and >> rebuild initramfs again. >> > > Thanks for this tip. Using this method I was able to get a "hash matches" > line in my dmesg whereas before I didn't get one. > > I am also debugging a suspend resume issue but with a Asus z390 I Aorus Pro > Wifi motherboard on a desktop (and an nvidia gpu unfortunately). > > Some interesting facts: > > 1) the pci device that matched was "INT34B9:00". I can't really find > much info about what this device is, it doesn't correspond to anything > under lspci. /sys/bus/acpi/devices/INT34B9:00/uid contains the value > "SerialIoUart1" > > 2) suspend and resume works when I execute "echo mem > /sys/power/state". > However when I execute the suspend from xfce or run systemctl suspend, the > resume fails (with a black screen but the keyboard lights up). > >> Just some general tips: try kernel-latest, and Qubes R4.1, if you haven't >> yet. Some interesting news, TL;DR is that I got suspend/resume working! Here's how: I updated dom0 to kernel-latest, booted again and with all vms off tested suspend with this script: ``` #!/bin/sh sync echo 1 > /sys/power/pm_trace echo mem > /sys/power/state ``` Resume worked. However as soon as I turned on sys-usb it failed to resume again, with the monitor staying off but the keyboard lights turning on. At this point I went into my bios and disabled all the devices I could: wlan adapter, ethernet adapter, graphics, etc. Throughout this point I was constantly checking for the "hash matches" devices in dmesg and looking at /sys/power/pm_trace_dev_match. Also I had edited qubes-pciback.sh as described by Claudia. There was never a clear smoking gun that revealed some particular device, and the values seemed to change with every reboot or configuration. However at one point I noticed 'drm' in pm_trace_dev_match, and this would prove useful later. My motherboard has integrated intel graphics (igfx) but also a PCIe nvidia card. Eventually I happened upon the bios configuration where I enabled integrated graphics (I had no option to disable the nvidias card aside from physically removing it). Booting into Qubes using the igfx output, I noticed 'drm' in the pm_trace_dev_match, whic
Re: [qubes-users] Debugging a sleep/suspend problem on Razer Blade Stealth 2016 - Qubes
Hi there,
I'm debugging similar resume issues, though on different hardware.
Hopefully you don't mind if we share tips in this thread.
> > I couldn't find anything related to those acpi devices. I thougth first
> that there was a driver for
> > them, so I should just rmmod those drivers before sleep and insmod when
> wakeup, but couldn't find
> > anything. There's this issue
> https://ubuntuforums.org/archive/index.php/t-2393029.html which have
> > those exact hash matches, but no answer.
>
> I don't know a lot about pm_trace, but it seems like there might be a
> problem decoding the hash.
> Normally it should show you a PCI address, /sys device name, driver name,
> or something more
> specific (see example in link below).
>
> According to s2ram kernel documentation:
>
> If no device matches the hash (or any matches appear to be false
> positives), the culprit may be a
> device from a loadable kernel module that is not loaded until after the
> hash is checked. You can
> check the hash against the current devices again after more modules are
> loaded using sysfs:
>
> cat /sys/power/pm_trace_dev_match
>
> https://www.kernel.org/doc/html/latest/power/s2ram.html#using-trace-resume
>
> However, in qubes we may also have the opposite problem. Qubes takes over
> your network cards and
> sometimes USB controllers in early userspace, so the drivers are not
> available anytime. To disable
> this behavior for USB controllers, remove rd.qubes.hide_all_usb from the
> kernel cmdline. For
> network cards it's a little more complicated.
>
> You can try modifying the qubes initramfs hook. First, make sure there are
> no VMs configured to
> start automatically at boot. Move
> /usr/lib/dracut/modules.d/90qubes-pciback/ to your home
> directory, or open the qubes-pciback.sh file and comment out the last 9 or
> so lines (from "for dev
> in $HIDEPCI"). Rebuild the initramfs. Then, do the pm_trace again as you
> did before. Then, try
> pm_trace_dev_match as described in the link above.
>
> It might give you better information about the problem device, or it might
> just give you the same
> info as before, but it's something to try.
>
> If it doesn't work, don't forget to put that file back how it was, and
> rebuild initramfs again.
>
Thanks for this tip. Using this method I was able to get a "hash matches"
line in my dmesg whereas before I didn't get one.
I am also debugging a suspend resume issue but with a Asus z390 I Aorus Pro
Wifi motherboard on a desktop (and an nvidia gpu unfortunately).
Some interesting facts:
1) the pci device that matched was "INT34B9:00". I can't really find
much info about what this device is, it doesn't correspond to anything
under lspci. /sys/bus/acpi/devices/INT34B9:00/uid contains the value
"SerialIoUart1"
2) suspend and resume works when I execute "echo mem > /sys/power/state".
However when I execute the suspend from xfce or run systemctl suspend, the
resume fails (with a black screen but the keyboard lights up).
> > I also tried `pcie_aspm=force` on `/boot/efi/EFI/qubes/xen.cfg` (is this
> where I put kernel
> > parameters?) like this:
>
> Yes on R4.0 you use xen.cfg. On other releases, you use /etc/default/grub.
> Unfortunately I don't
> know anything about ASPM so you probably know more than I do.
>
I also don't know much about ASPM, but I noticed my bios had a section for
"Active State Power Management" which was disabled, I enabled it (and the
sub-options that appeared) but still haven't had luck.
> If anyone has other debug ideas, I'm very thankful!
>
> Just some general tips: try kernel-latest, and Qubes R4.1, if you haven't
> yet.
>
I'm still on 4.0, how does one try 4.1 without a full re-install?
> Also make sure your
> firmware is up to date. If your machine has a dGPU, disable it in BIOS.
>
> It doesn't sound like the CPUID Xen panic I had on my machine, but you
> could try the Xen patch
> anyway, if nothing else works. In my case, only the fan came back on, but
> not the screen backlight
> or anything else.
>
> I also had to pin dom0 to CPU 0 to fix a different problem (my SATA
> controller was broken after
> resume). Add the following to your Xen cmdline ("options=", not
> "kernel="!): "dom0_max_vcpus=1
> dom0_vcpus_pin"
>
>
Will give these a try.
I have both iwlifi and nouveau, which are definitely top suspects however
they haven't given me any issues and so far no evidence points to them
being responsible.
~abel
--
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/47fbbab7-4fff-41fd-b5ea-21ca1ede668b%40googlegroups.com.
Re: [qubes-users] Autostart on login in minimal templates
Claudia: > Try putting `systemctl daemon-reload` in rc.local. I haven't tried it, but > this should work, as rc.local itself resides on /rw, so /rw has to be > available by that time. (Arguably the stock rc.local in Qubes templates > should be preinstalled with this line. But then, arguably, systemd should > always automatically reload units any time it mounts something.) I've tried this, and unfortunately it doesn't work IF the goal is to get the units in /usr/local to participate in the boot process. This is because by the time qubes-misc-post.service executes /rw/config/rc.local, the boot process is already well in progress. See my other reply for more details. If the goal is simply to make the /usr/local units available to systemd, for later start/stopping, then it will work. But you cannot enable them to be started at boot. I suppose one could add `systemctl daemon-reload` to rc.local and then a series of `systemctl start your-thing.service` statements, but you still miss out on the benefits of systemd's 'enable' (After,Before, etc). ~abel -- 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/ad4e8e45-d644-ba33-06a0-2801160bcf7c%40guardianproject.info.
Re: [qubes-users] Autostart on login in minimal templates
Abel Luck: > The systemd route does seem promising. Thanks. > > If I edited the template vm, I could just put my unit file in > /etc/systemd/system and it would work fine. > > However I'd like to do this for a specific AppVm, so I dropped the unit > file in /usr/local/lib/systemd/system. This file persists across boots > as expected, however systemd doesn't load units from it until I > daemon-reload after boot. > > I suppose this is because /usr/local is symlinked from /rw/usrlocal > sometime after systemd has loaded its units. > > Is there anyway to get systemd to load units from > /usr/local/lib/systemd/system as part of appvm boot? > > ~abel > > Claudia: >> January 11, 2020 2:06 PM, "Abel Luck" wrote: >> >>> Hi there, >>> >>> Using the fedora and debian minimal templates, how can I execute a >>> script on *login*? I'm aware of /rw/config/rc.local, but that runs on >>> system boot. >>> >>> Rather, I want to run something after X11 has initialized and my user is >>> logged in. >>> >>> Since no DE is installed, .desktop files in ~/.config/autostart are not >>> executed in the minimal templates >>> >>> ~abel >> >> Would .xinitrc work? >> >> Systemd units with After=graphical.target and properly configured User=, >> Display=, Session=, Seat=, and/or whatever else might be necessary. Or maybe >> user-mode systemd units. https://wiki.archlinux.org/index.php/Systemd/User >> >> Or maybe rc.local with `systemctl is-system-running --wait` before your >> commands - I often have to use this with qvm-run. Running from rc.local >> though, commands might not be running as the right >> user/session/seat/slice/scope/whatever, I don't know. Oops, sorry for the top post D: I did some more research and this appears to be a systemd limitation: https://github.com/systemd/systemd/issues/8307 /rw/usrlocal is mounted to /usr/local as part of qubes-mount-dirs.service when a vm is booting. This means the unit files in /usr/local are not visible to systemd. As poettering state in that issue: "unit files have to reside on a partition that is mounted at the moment the host PID 1 is invoked. i.e. either on the root partition or some other partition that the initrd premounts." This is quite sad. I have several use cases for app-vm specific systemd units: * Automount network drive on boot (for backupvm) * Run some special daemons on boot * Execute scripts on user login I guess I'll just need to revist the use of rc scripts :/ (ala https://entropux.net/article/systemd-rc-local-service-with-qubes/) ~abel -- 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/2740ac28-eb6d-c43b-2bf9-67a7ca13601b%40guardianproject.info.
Re: [qubes-users] Autostart on login in minimal templates
The systemd route does seem promising. Thanks. If I edited the template vm, I could just put my unit file in /etc/systemd/system and it would work fine. However I'd like to do this for a specific AppVm, so I dropped the unit file in /usr/local/lib/systemd/system. This file persists across boots as expected, however systemd doesn't load units from it until I daemon-reload after boot. I suppose this is because /usr/local is symlinked from /rw/usrlocal sometime after systemd has loaded its units. Is there anyway to get systemd to load units from /usr/local/lib/systemd/system as part of appvm boot? ~abel Claudia: > January 11, 2020 2:06 PM, "Abel Luck" wrote: > >> Hi there, >> >> Using the fedora and debian minimal templates, how can I execute a >> script on *login*? I'm aware of /rw/config/rc.local, but that runs on >> system boot. >> >> Rather, I want to run something after X11 has initialized and my user is >> logged in. >> >> Since no DE is installed, .desktop files in ~/.config/autostart are not >> executed in the minimal templates >> >> ~abel > > Would .xinitrc work? > > Systemd units with After=graphical.target and properly configured User=, > Display=, Session=, Seat=, and/or whatever else might be necessary. Or maybe > user-mode systemd units. https://wiki.archlinux.org/index.php/Systemd/User > > Or maybe rc.local with `systemctl is-system-running --wait` before your > commands - I often have to use this with qvm-run. Running from rc.local > though, commands might not be running as the right > user/session/seat/slice/scope/whatever, I don't know. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8cbe83a5-0b2f-b23f-8f41-7221804f2b44%40guardianproject.info.
[qubes-users] Autostart on login in minimal templates
Hi there, Using the fedora and debian minimal templates, how can I execute a script on *login*? I'm aware of /rw/config/rc.local, but that runs on system boot. Rather, I want to run something after X11 has initialized and my user is logged in. Since no DE is installed, .desktop files in ~/.config/autostart are not executed in the minimal templates ~abel -- 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/e17927d0-d99e-deb9-ee31-4c655eddca2d%40guardianproject.info.
