[qubes-users] HCL Dell Latitude 7400 (Core i5-8365U Whiskey Lake)

[Daniel Moerner]

I recently got a Latitude 7400 from my employer, a perfect replacement
for my 3rd gen X1 Carbon which died four days before the end of 2019.
Looking forward to finally using Qubes with more than 8 GB of RAM.

It works pretty flawlessly with Qubes R4.0.2 after making three
changes: (Still have a lot of fan usage with a pretty loud fan, but
that's Qubes for you.)

1. To boot the installer, you need to remove mapbs=1 and noexitboot=1
(https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-displaying-installer).

2. To get suspend to work, you need to add mem_sleep_default=deep to
the kernel= line in /boot/efi/EFI/qubes/xen.cfg. Otherwise it tries to
use s2idle which does not work with Xen. (cf.
https://groups.google.com/forum/#!topic/qubes-users/w6Jq4j79Eeo)

3. With the 4.19 kernel, it would not complete shutdown without
holding down the power button, and I also didn't get a bootsplash for
the encrypted hard drive. Both of these are fixed with the 5.3.11
kernel in kernel-latest.

Remember that for a machine like this there's some sort of Intel RAID
thing you need to disable in the BIOS for Qubes to find the NVMe disk.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAPSgt5n2j6RxiZnfi%2BRWX-3Ffy86v8Sm%2ByBc3opoka-VmAkpEA%40mail.gmail.com.


Qubes-HCL-Dell_Inc_-Latitude_7400-20200104-170122.yml
Description: application/yaml

Re: [qubes-users] KDE problems

[Daniel Moerner]

On 8/20/19 9:57 AM, Chris Laprise wrote:
>> I'm told that the "Settings" icon in qui-domains menu is oversized.
> I don't see any icons at all in qui-domains; just text.

I think this has something to do with how python gets the default Gtk 
icon set for use in Gtk.IconTheme.get_default().load_icon(). I haven't 
tested this on kde but I've noticed on i3 and awesome that running 
"xfsettingsd && pkill xfsettingsd" is sufficient to get the icons to 
show in qui-domains. But I haven't dug into it to figure out what 
xfsettingsd is doing that sets this, and how it sets it to be persistent 
after killing it. I haven't been able to set anything in 
~/.config/gtk-3.0/settings.ini that will get the icons to show up 
automatically.



This also affects the icons in qui-devices for me.


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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a690d46a-171a-f993-94b2-a697e3f4606b%40gmail.com.

Re: [qubes-users] request : add to dom0 FFmpeg libraries and codecs h264/h265/libavcodec/libfdk_aac/libmp3lame/libopus/libvpx

[Daniel Moerner]

On Sunday, August 11, 2019 at 7:14:12 AM UTC-4, john due wrote:
> How can multimedia libraries affect security?

There was a much-discussed exploit a few years ago, and there are several 
similar ones: 
https://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html

-- 
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/3f067002-2773-4362-bf19-0d4ed0f76446%40googlegroups.com.

[qubes-users] Re: Qubes i3 Tips & Tricks

[Daniel Moerner]

A quick follow-up on this:

First, I have a branch with i3 updated to 4.16.1 for testing: 
https://github.com/dmoerner/qubes-desktop-linux-i3/tree/4.16.1-colors. I 
believe it is now stable. (cf. 
https://github.com/QubesOS/qubes-issues/issues/5168)

Second, a nice, lightweight redshift program for dom0 is sct: 
https://www.umaxx.net/dl/sct-0.4.tar.gz. This is written by a few OpenBSD 
developers and is so simple you can audit the C code yourself before 
installing it in dom0. It isn't in Fedora yet, although I will get around 
to pushing it eventually 
(https://copr.fedorainfracloud.org/coprs/dmoerner/sct/).

Third, a question: Some of the icons in the domains.py and devices.py tray 
icons don't appear by default. They do appear if you run "xfce4-settingsd". 
It has something to do with populating the default icons. I haven't been 
able to figure out how to get it to show icons without running 
xfce4-settingsd. I tried some basic settings in ~/.gtkrc-2.0 and 
~/.config/gtk-3.0/settings.ini, without any luck. If anyone knows how to do 
this, that would be nice to hear. I prefer not to use "xfce4-settingsd" 
since it seems to mess up some of the i3 hotkeys.

By the way, if anyone is using awesome: You might want to install 
i3-settings-qubes. qubes-i3-xdg-autostart is a simpler alternative to 
dex-autostart, and qubes-i3-sensible-terminal works great with awesome.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/45e964a4-091f-4ea9-a01e-98c2cd74bbca%40googlegroups.com.

[qubes-users] Enabling a VM to move the cursor

[Daniel Moerner]

On other distributions I enjoy using the Acme text editor 
(http://acme.cat-v.org/). Part of using Acme efficiently involves allowing 
it to move the mouse for you, e.g., to search for a term you right-click on 
a word, and the cursor jumps to the next instance of the word in the open 
file.


Obviously this doesn't work on Qubes, since the gui agent doesn't let 
programs in VMs move the cursor.


I was thinking about the best way to selectively allow a VM to move the 
cursor, and I thought that the easiest and most secure way to do it would 
probably be to wrap Acme's cursor movements up into a dummy device, and use 
qubes-app-linux-input-proxy to treat the VM running Acme as if it has an 
input device attached.


Has anyone tried something like this before?


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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e181ea30-25d6-46a9-81dc-1e3a4205f40d%40googlegroups.com.

Re: [qubes-users] The PGP Encryption Problem

[Daniel Moerner]

I agree with everything that Chris said. A few more thoughts:

First, I think the article is probably right that PGP is not the right 
solution for most problems for most users, mainly because of inertia 
against integrating subkeys into your workflow. But qubes-gpg-split makes 
many features of PGP work very well for Qubes users.

Second, the issue of complexity. The "Answers" section seems to suggest 
using seven different tools to replace PGP. And consider some of the 
complaints about complexity in PGP:

 The actual system doesn’t get simpler. There are keys and subkeys. Key IDs 
> and key servers and key signatures. Sign-only and encrypt-only. Multiple 
> “key rings”. Revocation certificates. Three different compression formats. 
> This is all before we get to smartcard support.
>

This is complexity, but complexity I use. I use keys, subkeys, sign-only 
and encrypt-only keys, revocation certificates, etc. In fact, it is the 
very complexity that lets PGP get around some of the complaints in the 
article.

Third, the recommendation to use Signal. One complaint about encrypted PGP 
email is that the recipient can forward your unencrypted message to someone 
else. Exactly the same thing is possible in Signal! In fact, it's not 
trivial to construct a protocol that avoids this problem while still 
allowing ease of use.

Fourth, the recommendation to use signify. It's definitely a 
well-implemented tool. But I do miss the web of trust when it comes to 
verifying keys. Consider this quote from the original paper: 
(http://www.openbsd.org/papers/bsdcan-signify.html)

There are no key servers for signify. No web of trust. Just keys. The good 
> news is the keys are pretty small. As demonstrated. We can stick them just 
> about everywhere, and we do. They're on the web site, they're on twitter, 
> they're on the top side of CD. 56 base64 characters. You can read it out 
> loud over the phone in under a minute.
>

The newest keys are not on Twitter, as far as I can see. OpenBSD doesn't 
sell CDs anymore. I'd much rather read a fingerprint over the phone than 56 
base64 characters. The main keys are hosted on all the mirrors, but the 
firmware keys are, to my knowledge, only verifiable by going to the release 
page: https://www.openbsd.org/65.html, or by downloading base.tgz and 
extracting it yourself. 

Of course, you can use signify and provide more ways to verify keys. But 
note that the simplicity of signify means this requires each user to set up 
their own infrastructure to do so, rather than relying on the (admittedly 
flawed) way that PGP provides.

By the way, if people want to play with signify in Qubes, I've refreshed my 
copr packages of a Linux port: 
https://copr.fedorainfracloud.org/coprs/dmoerner/outils/

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c7aa95de-8cf1-4241-ba25-6e6b30dc7965%40googlegroups.com.

Re: [qubes-users] Re: ANN: Qubes-VM-hardening v0.8.5 released

[Daniel Moerner]

On Fri, Jul 19, 2019 at 1:21 PM Chris Laprise  wrote:
>
> On 7/19/19 10:13 AM, Daniel Moerner wrote:
> > Thank you, this is a great tool. Everything is working perfectly as far
> > as I can tell. It also works with fish shell by adding .config/fish to
> > $chdirs.
> >
> > I was thinking about what kinds of files, not present in the default
> > installation but possibly added to a user's system, might need to be
> > added to $chdirs and $chfiles manually. Perhaps such a list could go in
> > the documentation. Some examples:
> >
> > 1. Any files sourced by your shell startup scripts that are in the
> > persistent private volume, e.g., files that provide completion
> > information for your shell but that aren't in the template.
>
> If you could provide a specific example, that would be great. The usual
> shell sources are already included, at least the ones that get executed.

An example is the popular fuzzy finder fzf. Although this is packaged
in Fedora, I had a test VM where I followed the instructions to
install it as a vim plugin
(https://github.com/junegunn/fzf#as-vim-plugin), which creates
$HOME/.fzf.bash and appends [ -f ~/.fzf.bash ] && source ~/.fzf.bash
to your bashrc. If you then enable qubes-vm-hardening, although your
bashrc is protected with chattr, it is sourcing another file that
might be overwritten by a malicious user. (The contrast I'm drawing is
that the Fedora package's completion files in /usr/share/fzf/shell are
not user-writable.)

I don't think this is a case that you should expect to be able to
handle automatically, given that it relies on the user adding
something to their own bashrc. Once qubes-vm-hardening is installed,
the user will be forced to perform extra actions to edit bashrc and so
hopefully will think to also chattr +i ~/.fzf.bash, etc., if needed.
It would probably only be an issue when first enabling
qubes-vm-hardening in an older VM, which might have some of this stuff
left over.

>
> >
> > 2. Executables installed by other package managers that don't use the
> > normal paths. For example, go uses $HOME/go/bin by default; cabal uses
> > $HOME/.cabal/bin. Probably not worth trying to list all of these, but
> > rather just noting the risk. Of courses, users that make regular use of
> > these package managers might not want to enable this kind of hardening
> > for convenience reasons.
>
> That is interesting about language-specific environments; these appear
> to be examples that don't play nicely with the host OS or shell. My
> initial advice here would be to add protection for $PATH (such as
> Qubes-VM-hardening) to your template early, then add these other
> components afterward. In future, it may be possible to parse the $PATH
> for anything
> that references the private volume, then then automatically lock those
> paths down.

No, they really don't play nicely, and there are real worries here, as
with that recent issue with rubygems and strong_password a few weeks
ago. I think the user will have to handle it themselves by editing the
/usr/lib/qubes/init/vm-boot-protect.sh script, depending on their
workflow. (For example, go uses $GOPATH/bin, and I believe some people
keep a startup file in each project directory with a custom $GOPATH
for that project which they source when working on it, leading to bin
directories scattered all over and a constantly changing GOPATH and
PATH. I wouldn't expect any of that to be handled automatically.)

>
> BTW, thank you for the bug fix! I've already posted it with a note in
> the Readme. The current version is now 0.8.5.

No problem!

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAPSgt5%3DsQZo9k4iJpTtJqbTNbrx5kNtA1EXFNwr3q1i6HMJgHQ%40mail.gmail.com.

[qubes-users] Re: ANN: Qubes-VM-hardening v0.8.4 released

[Daniel Moerner]

Thank you, this is a great tool. Everything is working perfectly as far as 
I can tell. It also works with fish shell by adding .config/fish to $chdirs.

I was thinking about what kinds of files, not present in the default 
installation but possibly added to a user's system, might need to be added 
to $chdirs and $chfiles manually. Perhaps such a list could go in the 
documentation. Some examples:

1. Any files sourced by your shell startup scripts that are in the 
persistent private volume, e.g., files that provide completion information 
for your shell but that aren't in the template.

2. Executables installed by other package managers that don't use the 
normal paths. For example, go uses $HOME/go/bin by default; cabal uses 
$HOME/.cabal/bin. Probably not worth trying to list all of these, but 
rather just noting the risk. Of courses, users that make regular use of 
these package managers might not want to enable this kind of hardening for 
convenience reasons.

-- 
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/746d4255-ab3d-4a70-847b-690700bcbff3%40googlegroups.com.

[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present

[Daniel Moerner]

On Wednesday, June 12, 2019 at 2:29:12 PM UTC-4, Jon deps wrote:
> Hello, using the suspend function, when I awake the desktop, the usb 
> mouse non longer functions.
> 
> have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start 
> sys-usb  but it complained  couldn't connect  to qrexec  or so and failed.
> 
> so qvm-start sys-usb a 2nd time and then the mouse functions again

This is a long-standing issue for some, resolved for some but not for others at 
different times. See https://github.com/QubesOS/qubes-issues/issues/4042

The situation has improved for me by getting kernel 4.19.43-1 from 
qubes-dom0-security-testing. You could try the new kernel. (But note that our 
problems might be a bit different, I never had a qrexec problem when restarting 
sys-usb after resume.)

If you need to automate restarting of sys-usb because you can't avoid this 
problem, you can add commands in /usr/lib64/pm-utils/sleep.d/52qubes-pause-vms 
for suspend and resume, e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You 
might need to qvm-kill sys-usb before suspend to get this to work reliably.

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/9e6909ec-4055-416b-9db6-720f6c1363dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes4.0 on gen3 X1 looses disk on resume from suspend

[Daniel Moerner]

Hi Jon,

This is very strange. Not very helpful for you, I just want to confirm that I 
have run Qubes 4.0 on a gen 3 X1 without having ever run into this bug. The 
ACPI errors are present on almost all these Lenovo machines and don't mean 
anything.

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/dbc171d4-6ca1-4318-9489-179109803e6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Installing Win7 on a Dell

[Daniel Moerner]

On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote:
> Hi,
> 
> I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4.  I 
> have a Dell e7440 and it doesn't come with a Windows .iso.  Before I 
> installed Qubes I used the Dell recovery tool to create a recovery usb disk 
> for Win7 to re-install the OS but I'm not sure if this is usable to install 
> with Qubes.
> 
> I tried following the instructions on the Qubes website by creating a new 
> Qube without a template but I could not change it from PVM to HVM.  Then when 
> I tried booting from the USB recovery disk it would load up a terminal and 
> then exit after 10 seconds.
> 
> When I try to boot the recovery USB disk from the main BIOS it boots up fine. 
>  Does anyone have any tips for installing Win7 in Qubes 4?
> 
> Thanks,
> 
> Glen

Hi,

Check out these two issues:
Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592
Installing Qubes Windows Tools: 
https://github.com/QubesOS/qubes-issues/issues/3585

The two problems you describe in the post seem to be the following:
1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work.
2. Make sure you set the video-model to cirrus for install.

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/d9826928-1733-4ac4-ac8a-fdb6ab5fe490%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: R4.0 rc4: Devices and VM tray icons disappeared

[Daniel Moerner]

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.

[qubes-users] R4.0 rc4: Devices and VM tray icons disappeared

[Daniel Moerner]

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.

[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.

[Daniel Moerner]

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.

[qubes-users] Re: R4.0 rc4 Back-up Bug

[Daniel Moerner]

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: Can't login to VM after upgrade to fedora 26

[Daniel Moerner]

Hi,

qubes-gui-vm needs to be rebuilt against the newer version of pulseaudio. This 
should be fixed as of commit 4cf2d11 in qubes-gui-agent-linux, but it looks 
like it still needs to be built and pushed to the repositories. 

Fixing this is important because --allowerasing is needed for some updates from 
Fedora 25 to Fedora 26 because of this upstream bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=1467060.

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/2c624deb-e849-42ef-99c3-33139f42cf86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to attach a Yubikey as a normal, extra usb keyboard only to specific AppVMs?

[Daniel Moerner]

On Monday, August 7, 2017 at 1:06:27 PM UTC-4, miguel wrote:
> Did you manage to find a solution? I have the same exact problem. USBVM sees 
> usb fine and pass it to AppVM without a problem but the yubikey simply doesnt 
> do anything inside the Appvm even the yubico personalization tool does not 
> detect a yubikey connected even though qvm-usb shows that the Yubikey is 
> properly connected and lsusb inside the VM also shows Yubico connected.

Hi,

I have a Yubikey 4, and I have no problems using the Yubikey with appVMs on a 
fresh install of Qubes R3.2, no extra configuration required.

I use the following script to attach it to specific VMs, and then it works 
perfectly with Google Chrome:

#!/bin/bash
# Usage: yubi 

USB_DEVICE="$(qvm-usb | grep Yubikey | cut -f1)"

# If no device, just exit
if [ -z "$USB_DEVICE" ]; then
echo "No device attached"
exit
fi

# If no argument, then just detach.
if [ $# -eq 0 ]; then
echo "No argument, detaching device"
qvm-usb -d "$USB_DEVICE"
exit
fi

# If we have an argument, detach first as a precaution.
qvm-usb | grep "$USB_DEVICE" | grep -q "(attached to"
if [ $? -eq 0 ]; then
echo "Device already attached, detaching first"
qvm-usb -d "$USB_DEVICE"
sleep 1
fi

echo "Attaching device to $1"
qvm-usb -a "$1" "$USB_DEVICE"

-- 
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/84e8c214-5e11-459f-a555-78e803beb470%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Kicking the sudoers dead horse

[Daniel Moerner]

On Friday, March 10, 2017 at 9:55:08 PM UTC-5, Unman wrote:
> So yes, in a very real sense, it doesn't matter
> to me if the qube where I collect mail, (which isn't the qube where I
> read it) is compromised in some way.

Hi Unman,

Could you explain your setup for collecting mail in one Qube and reading it in 
another? I currently use Qubes for each mail account, running mutt and 
offlineimap, and opening links in disposable VMs. But collecting mail in one 
Qube and reading it in another is interesting to me.

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/21ad2eab-051e-43b2-afd6-5c3c0edcc34a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: SystemD sucks - qubes shouldn't use it

[Daniel Moerner]

On Wednesday, March 8, 2017 at 8:51:06 AM UTC-5, tai...@gmx.com wrote:
> I realize that it is an integral part of fedora and debian (gross), but 
> it is a serious security hole and qubes should consider migrating away 
> from it by maybe choosing another orgin distro.

It would be helpful for you to make clear what exactly in that pile of links is 
a threat to Qubes.

More generally, I think you significantly underestimate the benefits Qubes 
receives from integration with established distributions. These distributions 
have more users, more developers, better infrastructure, etc. All of this 
contributes to security, and the infrastructure is particularly important when 
it comes to trusting the distributions you use for your templates. The 
alternative distributions have much smaller userbases. The same holds true for 
systemd alternatives. How long will OpenRC, or sinit, or uinit, or the latest 
new proposed replacement be supported? Even if systemd has some problems, I 
think the benefits we get from Fedora and Debian outweigh the costs.

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/5dcbbd15-2974-4500-9c92-4997d9367d0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes i3 Tips & Tricks

[Daniel Moerner]

On Mon, Mar 6, 2017 at 11:02 PM, sm8ax1  wrote:
> Thanks for this. I've used i3 on other OSes and I like it a lot. I
> probably won't use it on Qubes however because of an issue that I'll
> note here since it may or may not affect other users.
>
> In i3 it is rather difficult to control the size of a window with fine
> granularity, and in particular it is very difficult to restore the exact
> size a window would have been created with. This is a problem for users
> of Tor Browser, because websites and exit nodes can query the browser
> window's size even when you have JavaScript disabled. This makes you an
> easy fingerprinting target.
>
> If anyone knows of any workarounds for this, perhaps forcing certain
> kinds of windows to be created in floating mode and keep their original
> size, please share them.

You'd have to experiment with whether it keeps the windows their original
size, but you can force windows to start in floating mode in .i3/config:
https://faq.i3wm.org/question/61/forcing-windows-as-always-floating.1.html

A line similar to:

for_window [class="anon-whonix:[.]*"] floating enable

Should make all windows from the anon-whonix VM float by default, although
I haven't tested this.

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/CAPSgt5nbAWaR0EXRQvNG_Z_4tDx4ULfifZHYyNzRzgMUeQn3VA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes i3 Tips & Tricks

[Daniel Moerner]

I've been using i3 in dom0 for about a month now, and I wanted to share a few 
tips and tricks (partly so I can have them in a centralized place for 
reference):

1. To lock the screen on suspend and resume, you need to add a systemd target 
in /etc/systemd/system. This has to use your username (or supposedly xss-lock, 
which I haven't bothered figuring out how to use). I use the following content, 
substituting for $USER:

[Unit]
Description=Lock screen on suspend

[Service]
User=$USER
Type=forking
Environment=DISPLAY=:0
ExecStart=/usr/bin/i3lock -d -c 00

[Install]
WantedBy=suspend.target

2. Volume keys: Install pulseaudio-utils. Then put the following in .i3/config:

bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume 1 +5%
bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume 1 -5%
bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute 1 toggle

I then customize the qubes-i3status command by adding: (I know this awk/sed 
mixture is awful, and it's hard-coded for my system, which has two pulseaudio 
sinks)

status_volume() {
   local muted=$(pactl list sinks | awk -F ' ' '/Mute/ {print $2}' | sed -s 's/ 
//g' -e '2q;d')
   if [[ $muted == 'yes' ]]; then
   json volume "Volume: 0%"
   else
   local volume=$(pactl list sinks | awk -F ' ' '/Volume/ {print $2}' | sed 
-s 's/ //g' -e '3q;d')
   json volume "Volume: $volume"
   fi
}

And then add a local volume variable to the main() call. I update every second.

3. A few minor tweaks to the config file: See this pull request, which has 
already been merged: https://github.com/QubesOS/qubes-desktop-linux-i3/pull/5 

A few more personal thoughts: Personally, I change the navigation to use vim 
keys, and then remap horizontal split to 'b'. I also remap 'focus child' to 
'c', since I find it to be a useful shortcut. Originally I disabled fullscreen, 
on the model of Xfce4, but I had to reenable it as part of a workaround for 
https://github.com/QubesOS/qubes-issues/issues/1502

I'm sure I'm missing a few things, but I wanted to share this, since I 
sometimes see people asking about i3, especially on IRC.

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/33922074-d6a3-46cb-b450-2b094122d53a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unsolicited feedback on qubes-issue #2455

[Daniel Moerner]

On Sunday, November 27, 2016 at 10:33:05 AM UTC-5, Alex wrote:
> On 11/26/2016 11:59 PM, Marek Marczykowski-Górecki wrote:
> >> - Qubes-GUID crashed in one AppVM as soon as I started monodevelop
> >> the first time. Cannot reproduce this problem either. Error in guid
> >> log was:
> > 
> >> ErrorHandler: BadAccess (attempt to access private resource
> >> denied) Major opcode: 130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach) 
> >> ResourceID:   0x254 Failed serial number:  3670 Current serial
> >> number: 3671
> > 
> >> may be related to the fact that monodevelop shows and hides many
> >> windows in rapid sequence when starting?
> > 
> > Yes, it may be. Very similar error (#2171) was already fixed some
> > time ago, but apparently not all the cases. Anyway it's rather
> > problem in gui-daemon, independent of Fedora version.
> Ok, this problem happened again, and always when starting monodevelop.
> Now I collected more logs, and tried to fiddle a bit with qubes-guid.
> 
> In dmesg there's nothing interesting apart from 238 repetitions of this
> line just before the crash manifested with all windows from that VM
> disappearing:
> [   77.469369] U2MFN_GET_MFN_FOR_PAGE: get_user_pages failed,
> ret=0xfff2

I just hit this bug in sys-net using a F25 template. nm-applet silently 
crashed, the VM state turned yellow in Qubes VM Manager, and the log was filled 
with this error.

-- 
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/2f6d47d7-7af2-4720-9781-41f3e7cd8906%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: debian-8 template problem

[Daniel Moerner]

On Monday, January 9, 2017 at 4:33:08 PM UTC-5, haaber wrote:
> Hello,
> I come back to my video-player problem. While I understand that qubes
> won't ship fedora software that fedore accepts only in rpmfusion, there
> seems an easy solution to my concrete problem: use the debian8 template
> since they ship mplayer2 for example without trouble ...
> 
> However, when I shut down the appVM and change its template to debian8,
> I can not even open a terminal. The appvm seems to run, qubes vm manager
> says, but no application is visible. When I revert it back all is
> normal. Since this is a fresh install (5 days old), I probably do some
> newbe error; so I appreciate some hint of yours. Thank you, Bernhard

Hi,

This is something that confused me at first too. When you switch the template 
of an appVM, the menus can't automatically update. Although Debian and Fedora 
both have gnome-terminal, they are actually invoked slightly differently from 
the menu (as you can see in ~/.local/share/applications in dom0).

What you need to do is open "Add more shortcuts" for the appVM after changing 
the template. It will then show the new applications, including the terminal, 
and let you add them.

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/834a78c3-bbdf-4d76-91cc-64d1f8f57ef1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: compose key

[Daniel Moerner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/08/2017 04:14 PM, haaber wrote:
> Thank you. Doing this, I have compose key in dom0, but not in any
> other domain. Do I miss something? Bernhard

Hi,

Please remember to reply to the list as well. For me, using Left Win,
this setting sets the compose key for all VMs and dom0. I'm confused
that you're seeing different behavior, and not sure why that would be
the case.

Daniel

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIwBAEBCAAaBQJYcsLBExxkbW9lcm5lckBnbWFpbC5jb20ACgkQyz0BTtfxsyqO
KhAAnAic/kT/cYiXoyPhPuNX7gBdYizElx7fKabax4SlcB1nr5ASBO8EheBz7ThM
AoSOYgQgbfgtJQsMfd44/b3NiI0PO8lWPKwLWEFvoU5osbPhg0EFvmqW+EAsZ/yz
aeWzbzpwovAj39bicUWa1XLyaZ2bEOY5MykzULJ2P9BVNq4C25ScKmJ5BfxGc+r5
noNTeVO8+xm4KSde3GghJPmkNSygmzgX6lqk97dZcJR/kjAd6vLiEiTWClr6jehQ
WvQw/7scDlJWefAEG8Hf29krxPb+Ckgy7C3uqI2igBxURWeXt4cU47Of0P6SgYGx
+iR1te3teDGeDEJTXU+/wq1v/x4ioXjSi6YIpQ3Paxs0BYLmnq8eagwh7AbLrrdU
iwo+L3p8QjRUjvPf9VyIGsnEdCCU+4y4Dql8WSeQbBF6xI2MxUJcI/ivHs8x+96t
reL6MKbpsW9ihkmUbbT1ZIMEPBfsHwuM2gdyBibr8xzwUySKqA3qzOPDAouFxo50
8cQcK3U5e+0zIZ+VpeqZWEQvbZL8enCaJZY0SUjEJbCm6ccpMAiesRd0Y0I6Vg7C
UMOix7QSENwKVpcFpY0g7GKFcCscU9TvViUvGOY1xdVgYa8yVDLqISyXCu1+rxOL
uYDKNNZJzYkYGXMpUBNxRnhLKLwBgn8YThPkdOrfAJV0z84=
=sUES
-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/900ba17c-892f-e355-72af-63d25abba231%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: compose key

[Daniel Moerner]

On Sunday, January 8, 2017 at 12:49:33 PM UTC-5, haaber wrote:
> Hello,
> 
> for foreign languages (accents, etc) I used to have a compose key
> configured. I have no idea how to do this within qubes. Has anyone
> had/solven this problem already? Thank you!   Bernhard

You just use the normal XFCE tools: Menu -> System Tools -> Keyboard. Then 
under "Layout" you can pick the compose key.

-- 
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/769e6fad-9e6f-4741-b9ee-08ac6ec7f613%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 3.2 Dom0 no longer updating.

[Daniel Moerner]

On Friday, January 6, 2017 at 7:15:14 AM UTC-5, Opal Raava wrote:
> Hi all,
> 
> Since about a week or so, I'm unable to update dom0 the way I used to. The VM 
> Manager will tell me there are updates available for Dom0, and when I click 
> 'Update VM' I see the familiar 'downloading updates' but after that the 
> window with the updates never appears.
> 
> If I run qubes-dom0-update it tells me 'No updates available'
> 
> Does this perhaps have to do with fedora23/fedora24 issues? I asked on IRC 
> and one person is having this issue as well. Is anybody else having this 
> issue?

Hi,

See https://github.com/QubesOS/qubes-issues/issues/2086. The packages in the 
testing repo fix this problem for me. Note that now that F23 EOL has occurred, 
updates will be much less common.

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/07e9e1e6-35c4-4c23-b28e-7272a36cd9f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Fedora 23 EOL December 20; Update Your Templates!

[Daniel Moerner]

Hi all,

Just a friendly reminder that Fedora 23 End of Life is December 20.[1] You may 
want to make sure you've updated your templates; there is a guide in the Qubes 
Documentation.[2]

I know I don't get to decide what people talk about, but I'd like to ask that 
people NOT use this thread to rehash the debate about the dom0 distribution. :)

Best,
Daniel

[1] https://fedoramagazine.org/fedora-23-end-of-life/
[2] https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/

-- 
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/ac8cfe18-866d-4611-9b75-bd038b671e20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: TemplateVM Best-Practices?

[Daniel Moerner]

On Wednesday, November 30, 2016 at 8:59:58 AM UTC-5, Loren Rogers wrote:
> Hi all,
> 
> Are there any recommended strategies for creating and managing 
> TemplateVMs for regular users?

Speaking personally, I use four templates: (based on Debian 9)

base: For sys-*, vault, gpg, shopping, banking, etc.
office: Libreoffice, thunderbird extensions, latex. For work and personal VMs.
dev: Developer tools, compilers, etc. For dev VMs.
untrusted: Media software (vlc, etc.) as well as Chrome.

This lets me keep the individual templates to a more manageable size and 
prevents me from accidentally mixing up my workflow across VMs.

I would be open to using a more stripped-down base template but I'm not 
convinced it's worth 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/0e38e8cb-2595-4eee-9222-2990c8b8aecd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enigmial and Splig GPG2 (previously Re: [qubes-users] Upgrading from Split GPG1 to Split GPG2?)

[Daniel Moerner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/19/2016 06:43 AM, Andrew David Wong wrote:
> Sorry, this is a known issue. Enigmail 1.9 is incompatible with
> Split GPG on Debian 8:
> 
> https://github.com/QubesOS/qubes-issues/issues/2170
> 
> Until this is resolved, I recommend using the Fedora template
> instead.

I added some comments to the issue tracker:
https://github.com/QubesOS/qubes-issues/issues/2170#issuecomment-2617233
58

I can confirm that this is fixed in Debian 9. I was unable to fix it
in Debian 8. It must be the case that gnome-keyring is hijacking
gpg-agent independently of the contents of
/etc/xdg/autostart/gnome-keyring-gpg.desktop.

Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIwBAEBCAAaBQJYMIZNExxkbW9lcm5lckBnbWFpbC5jb20ACgkQyz0BTtfxsyoU
yRAAi4wWlOuvW4YYQYgKe5PWhgm/66Lgc9sAnzdf57QHdKUMyLMNWEjZnWuuOsr2
LMYmd/xNtUv4+B8LZJLF0SCPNYNrFuX6utFJF/rIs7hf7mNb06P9XP4PCjpBcurh
7IH+083aVylapADJ5q8JegXullDH2tN2yKhXFKjPMGkBz/+V9T0Kg2kuVcvradf5
3VQ1jpOYnYnJfWeY74xvDTOrS/hT2zPbZma+i7vqmcL6+JHlHQny5HLqw0+a9duQ
dlrLoVwSe6zx6leqUo+3IewZmd9s+uSZfl5UrUh0UDysVewvQx9qlA/UvePtLD2p
ktDcmeNHyoGfW0FOXfkIwTgxiRPBYrGT3n6vpe1KDP1fp3C6ETzLseco3EidjHWh
itDCMrjFYmw2Z+xOyh17pmIJZuxrwmLiP8xd8Y65zgfcCWMKzkZ45AAl9TIGPvut
TJ4Fz3xZ2E5n1GxUMLal7ADgGsgDxvYaNzlKMpfVsk8ikd9+EQpUIAOrejFjyuE6
J1e0cv8Gu1QuW7/88gLt0YhdOymrgJE7L9ty8lDbgZqz7+SwRyZtCc6Vau1FmYrm
RKPf6m8MwImB34xyL6EX5Ocums/+IWZVmVBPPqYApCKx4UVuikNQMQC+CRqZrtz2
jz/AVeH+3YiVHssdddjQoXdB6FojbQZ6XaTNpMIsK8acJJ0=
=+FX1
-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/54d3813f-647b-8f23-b44c-2e71059e03f1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Fresh R3.2 install, no /etc/default/grub

[Daniel Moerner]

On Tue, Nov 15, 2016 at 3:48 PM, Marek Marczykowski-Górecki <
marma...@invisiblethingslab.com> wrote:
> I guess you have installed the system in UEFI mode. In that case, kernel
> parameters are in /boot/efi/EFI/qubes/xen.cfg.

Hi Marek,

Thank you for the quick response. That hint and a bit more searching helped
me find this earlier discussion on the mailing list:
https://groups.google.com/forum/#!msg/qubes-users/KTRlrc9vC1U/ajxXQtBPBAAJ

Editing xen.cfg and then relocating the initramfs produced by dracut solved
the problem. Perhaps someone with permission could add a link to that
discussion to the wiki page.

Thanks!
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/CAPSgt5n7GNcAC7-1LDWaJGVwtyhOL_zYxzNntvXmTFP%3D4Goxpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.