[qubes-users] HCL-Dell Precision 5520

['joe renotse' via qubes-users]

-- 
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/141877827.384049.1614445354101%40mail.yahoo.com.


Qubes-HCL-Dell_Inc_-Precision_5520-20210227-102502.yml
Description: application/yaml

[qubes-users] Re: VM won't start if Realtek PCI card reader is assigned to it (even if removing conflicting Ethernet controller)

[joe]

On Wednesday, October 23, 2019 at 2:15:45 AM UTC-4, Davide wrote:
> Qubes version
> 
> Qubes-R4.0.1-x86_64
> 
> 
> 
> 
> 
> Affected component(s) or functionality
> 
> 02.00.0: Realtek PCI Express Card Reader RTL8411B vs. 
> 
> 
> 
> 02.00.1: Realtek PCI Express Gigabit Ethernet controller
>   RTL8111/8168/8411

Having this exact same issue with my new System76 Darter Pro with coreboot.

Did you manage to resolve 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/054afa5e-dae0-431e-8085-dfbb351f3b35%40googlegroups.com.

[qubes-users] HCL - ASUSTek Q324UAK

[joe doe]

-- 
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/CAEB8c7V6K8SKbdKwF3qkPig8UoQXor6rFUKYr-OwZXA92X3pjw%40mail.gmail.com.


Qubes-HCL-ASUSTeK_COMPUTER_INC_-Q324UAK-20191110-104622.yml
Description: application/yaml

Re: [qubes-users] Issues after Installation

[Joe Ragno]

So after enabling Virtualization, I get a new error on the sys-net and
sys-firewall that reads:
Domain sys-net has failed to start: internal error: libxenlight failed to
create new domain 'sys-net'

*Regards,*
*Joseph Ragno *

*Marketing Technology Specialist*

*M:* (908) 217-1940
*F: *(954) 208-

1901 West Cypress Creek Road,
Fort Lauderdale, FL 33309

*Inspiring Wellness* at DelphiHealthGroup.com

*Addiction and Mental Health Treatment*
Connect: Facebook  | Twitter
 | LinkedIn





On Sat, Mar 9, 2019 at 8:32 PM unman  wrote:

> On Fri, Mar 08, 2019 at 10:59:11PM -0800, jra...@delphihealthgroup.com
> wrote:
> > I'm not quite sure why however after transferring qubes to my hp probook
> 11 it will not start any domains at all and every time I get an error
> message that says:
> >
> > "Qube Status: sys-net
> >
> >  Domain sys-net failed to start: invalid argument: could not find
> capabilities for arch=x86_64"
> >
> > Also, when clicking the Applications button in the top left corner of
> the screen and hovering over a domain or template my only option available
> is Qube Settings.
> >
> > Please help!
> > --
>
> The usual cause is that you dont have VT-x enabled: check the BIOS
> and make sure that you have all virtualisation options enabled.
>
> unman
>
> --
> 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/20190310013210.5tzbc53xqwj5i3sh%40thirdeyesecurity.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
This email and any files transmitted with it are confidential and are 
intended solely for the use of the individual or entity to which they are 
addressed. This communication may contain material protected by HIPAA 
legislation (45 CFR, Parts 160 & 164). If you are not the intended 
recipient or the person responsible for delivering this email to the 
intended recipient, be advised that you have received this email in error 
and that any use, dissemination, forwarding, printing or copying of this 
email is strictly prohibited. If you have received this email in error, 
please notify the sender by replying to this email and then delete the 
email from your computer.

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

Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

[Joe]

On Wednesday, 26 September 2018 03:28:21 UTC-4, simonda...@googlemail.com  
wrote:
> Is this module working on Qubes 4.0?

Yes, it is working for me on Qubes 4.0 and I have used it with LVM and Raid 
configurations.

-- 
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/64a82348-1c55-4c09-82cd-470a69a16d7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Luks with yubikey + aem

[Joe]

On Sunday, 17 January 2016 10:51:28 UTC-5, Marek Marczykowski-Górecki  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Thu, Jan 07, 2016 at 01:25:10PM +, Rusty Bird wrote:
> > Rusty Bird:
> > > - To protect the LUKS key with "something you have" -- the AEM
> > > stick -- we could add a secret.luks.encrypted file, which holds the
> > > actual LUKS passphrase (not usually typed in during boot, only when
> > > unsealing fails due to upgrades), symmetrically encrypted with
> > > another passphrase.
> > 
> > Ugh, this doesn't prevent a multi-stage attack:
> > 
> > 1. the attacker visually captures the disk passphrase during a
> > successful boot
> > 2. later, they take a copy of the encrypted disk and infect the system
> > 3. later, the user attaches the AEM stick and boots; the infected
> > system copies secret.luks.encrypted.sealed somewhere -- cue scary
> > music as STATEFULNESS reveals itself from the shadows yet again; now
> > the user notices the failed unseal
> 
> And this is great thing about YubiKey - you can't easily copy it.
> Otherwise yes, AEM stick could be "something you have" factor (not sure
> if exactly the way you've proposed, but something like this). 
> 
> > 4. the attacker quickly gets to the infected notebook; then reverts it
> > to the original state, and unseals + decrypts the LUKS passphrase
> > 
> > Portable Qubes installations limit the attacker to copying only a
> > couple of megabytes of the encrypted disk data during (3), instead of
> > taking a complete copy during (2); they also make the infection harder.
> > 
> > Or secret.luks.encrypted.sealed could be on a second-stage AEM stick,
> > which the user should connect *after* verifying the OTP... :\
> > 
> > > - To protect the secret from visibility, we could plug in Matthew 
> > > Garrett's TOTP concept via a secret.totp file containing the seed.
> > > And then add a non-default GRUB boot entry to unseal the regular
> > > static secret.{txt,png}, in case the user doesn't have their
> > > authenticator device with them.
> > 
> > The mobile device's TOTP generator would have to be working in a sort
> > of verifier (not prover) mode, simultaneously displaying OTPs for a
> > couple of preceding and following 30-second time steps. Is there
> > anything like that for Android?
> 
> I don't think so...
> 
> - -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJWm7h3AAoJENuP0xzK19csdugH/RV7m3yDqt2nopo1Q5F9X/mJ
> 5JO/IGGCAYjFm+vZChxP0NvU5pfGe1RJEu3UnuG/lQTGppMkT527EzUlzRAQTG23
> z1ioPwu+Y4+iTwdsE1FpeEPsqnZw/yHeBYo0Mo2XcuTuqobe2kEn9ufanovjmFdN
> jbqfTk8UfVdAe7jX7jiEeoU2Oae/btqO0gS8j7W7ktXOSfePeZpXo91eeoAP8bqb
> gR/oXrAtVECEz8QSqwIS4FEUN9Ns8IrcQtRfND/AuApE2JQ2Fs52IHBhMnhBYmCA
> qJtwFGqraarEOuGno8bHpHQ5n0eTP36GQRguAGzLOgwHH/lCAcJZhdTT3sEJaSQ=
> =Lm3q
> -END PGP SIGNATURE-

Any further discussion or thought about this?
I want to use AEM, but I am currently using yubikey Chal/Resp for LUKS at boot 
time (https://github.com/the2nd/ykluks).  
I am sure installing AEM would conflict in some way.  

I would like AEM and ykluks to work simultaneously if possible... or if AEM can 
use the yubikey instead of a USB drive, and still be used as 2nd factor to 
decrypt the multiple LUKS devices.

-- 
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/54516264-ed1a-412a-b22f-2d8cb9554609%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Yubikey, luks disk encryption password, and usb-vm ?

[Joe]

On Monday, 5 June 2017 00:33:44 UTC-4,   wrote:
> On Sun, 4 Jun 2017 22:29:57 +0200
> 
> > On 06/04/2017 10:03 PM, wrote:
> > > When using a usb-vm, my usb keyboard is not accessible at boot time,
> > > and thus my disk encryption password must be typed on the built-in
> > > keyboard. 
> > > 
> > > When not using a usb-vm, a usb keyboard can be used to enter the
> > > disk encryption password.
> > > 
> > > When using a simple static password at boot typed by the yubikey
> > > (which acts like a keyboard), it has the same limitations as the
> > > usb keyboard, wherein it can't type the disk password when a usb-vm
> > > is being used. 
> > > 
> > > I could not determine whether the documentation discussing
> > > challenge-response addresses this problem with boot-time disk
> > > passwords as some sub-component
> > > ( https://www.qubes-os.org/doc/yubi-key/ ). I only see the
> > > screensaver discussed, but not disk passwords at boot. 
> > > 
> > > While still using a usb-vm to manage all usb devices, is there any
> > > way to authorize the yubikey automatically at boot time so it can
> > > type in a password for me?
> > > 
> > > Also, here: ( https://github.com/adubois/qubes-app-linux-yubikey),
> > > am I missing the referenced qubes-yubikey-vm and qubes-yubikey-dom0
> > > in the repos, because they don't seem to exist?
> > > 
> > > Thanks!  
> > 
> > With USB VM enabled, all USB devices are hidden from dom0 even during
> > the Linux kernel boot (but not before). If you need to use USB devices
> > during Qubes OS boot (keyboard, yubikey, anti-evil-maid, ...) and
> > don't mind rigorously checking nobody has plugged any suspicious USB
> > devices into your machine before powering it on (as you should be
> > doing anyway), you can follow the steps outlined below.
> > 
> > There's a Linux kernel command line argument you need to remove from
> > /etc/default/grub -- find the line starting with "GRUB_CMDLINE_LINUX"
> > and drop the "rd.qubes.hide_all_usb" argument. Save the changes and
> > rebuild grub configuration using `sudo grub2-mkconfig -o
> > /boot/grub2/grub.cfg` and then reboot.
> > 
> > Please note that if you have anti-evil-maid installed, you also need
> > to re-run `anti-evil-maid-install` script on your AEM device.
> > Unsealing of your secrets will, as expected, fail during next boot.
> > 
> > Once you reboot without this option, you can use any USB device
> > normally.
> > 
> > 
> > Cheers,
> > Patrik
> > 
> 
> Thanks for the clear answer! It took some searching, but it looks like
> that for me, that flag was only present in /boot/efi/EFI/qubes/xen.cfg
> and it does not seem to require rebuilding grub to work. I didn't see
> that location discussed here https://www.qubes-os.org/doc/usb/ under
> "Removing a USB qube" either. 
> 
> Now, to see if I can get the luks challenge response working rather
> than just a static password ...

If you're still interested.
This solution works great with Yubikey (chal/resp mode), with sys-usb running 
as your USB Qube.
It temporarily allows USB devices during the boot up when it asks for a 
password (challenge) or the LUKS passphrase.  Once done, it then unbinds the 
USB PCI devices from Dom0, so the USB qubes can handle USB devices as it should.

https://github.com/the2nd/ykluks

-- 
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/a8a40cbd-5431-414a-8192-e27782a9cfc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: USB Printer

[Joe]

On Thursday, 23 August 2018 09:56:59 UTC-4, sm...@tutamail.com  wrote:
> I am not sure I have all the answers but here are some thoughts and hints 
> based on how I have my printer setup(wirelessly):
> 
> 1) I created a dedicated Template for printing, in that template I have my 
> CUPs installed (This way I keey my other templates clean). I am also able to 
> create a DVM and a AppVM based on that template
> 
> 2) I use a Debian template, in that Print Template I have GNOME installed
> 
> 3) During setup I need to allow connection access to test its working, once 
> tested I remove network access (You might need to allow USB access or in my 
> case I allow access to Sys-firewall" for testing only.
> 
> 4) I use "Print Settings" to set up my printer in the template, then when I 
> create an AppVM or -DVM the information is populated. My CUPs stuff gets 
> populated into the "print settings" GUI
> 
> 5) Make sure to shutdown template before creating the AppVM or DVM
> 
> I don't use a lot of USB devices with my setup but I suspect you need to 
> allow access to the USB via the "Device" tab in the AppVM.
> 
> Hope this helps and good luck!

Thanks, but it sounds like your printer has networking capability.  I suspect 
that alone would solve the issue.  Being a USB printer, without a built in 
driver already part of the basic distro... it requires more.

-- 
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/66ba9507-f4b7-4ece-aecd-119d65f9b0db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] USB Printer

[Joe]

I cannot seem to get a USB Printer working on any qubes AppVM.

---

Printer does install without any problem, but print jobs immediately STOP.
I am not seeing any CUPS errors other than generic filter failed.

Printer is physically a Dell 1250c (but all Linux distros use a compatible 
Xerox Phaser 6010N driver).

The driver comes as an rpm and a deb package, and includes the PPD files.
I've tried both fedora-26 and debian-9 based VMs.
I've tried attaching the USB device, and assigning the entire PCI USB Host 
Controller to that AppVM.
I've tried reinstalling CUPS.

I have an bare-metal Lubuntu system, that works fine with just the deb install.
So I created an HVM via a Lubuntu 16.04.2 ISO, assigned the PCI USB Host 
Controller, and it works fine there too.



Current Workaround:
Dedicated USB Host Controller for the printer, assigned to a 'printer' HVM, 
running CUPS on Lubuntu, and shared.  sys-firewall iptables rule to ACCEPT port 
631 on the FORWARD chain.  Then install the printer pointing to the 'printer' 
vm.  

I figure this has to be a CUPS filter driver problem that is uniquely Qubes.
If anyone has any suggestions, please let me know.
Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/25908a28-daf2-47e4-adcc-d898e1a85823%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Dell Inspiron 7577 Laptop "New Inspiron 15 7000 Gaming"

[Joe Thielen]

Intel i7-7700HQ 2.8Ghz quad-core.  16GB RAM.  256GB SSD.  1TB HD.

Qubes 4.0-RC4 runs great.  Install was just a bit tricky.  Mouse/trackpad
did not work during install (worked fine after reboot), had to use keyboard
navigation.  Also used legacy mode in BIOS to get installed.

I had installed Qubes 4.0-RC3 first (before RC4 was out).  I seem to
remember going the UEFI boot route on that and it worked, but when doing
RC4 I either didn't do the same thing or just went with legacy mode and it
worked so I left it at that.

My machine has a 256GB SSD and a 1TB HD.  When I installed RC3 first I let
it use both drives during install.  However, while it ran OK, it was not
super speedy, and I could hear the 1TB HD when in use.  Not loud or
anything, but I was aware of it.  And some operations seemed to take more
time than I would have liked.  However, when I installed 4.0-RC4 I only
specified the 256GB SSD, and that really made a positive difference,
especially during boot time.  Very snappy now.  I have not yet tried to get
the 1TB partitioned and going for storage.

Wi-fi & ethernet work no problems, out-of-the-box.

I'm not able to use dual-screens via the HDMI just yet.  On 4.0-RC3 it
didn't recognize it at all (xrandr shows HDMI but shows "disconnected").
4.0-RC4 does recognize it, and I was able to get screen mirroring to work,
but not extended desktop just yet.  At one point I was able to get the
mouse pointer to seamlessly move from screen to screen, but the display
identifier function did not work, nor would anything but the mouse pointer
show up on the screen.So there is some hope here I'm thinking with
further tweaking.

When I loaded 4.0-RC3 I spent a bit of time playing with the nvidia drivers
(as explained in several articles).  I was able to get them compiled and
installed (very painful), but then the machine could not be used, ended up
having to blacklist both the nvidia and nouveau drivers.  That brought it
back to life.  With 4.0-RC4 I have not yet tried to mess with any of this.

Bootup takes about 90 seconds from the time I push the button to the time I
can use it fully.   This includes pushing the power button, entering a BIOS
user password, disk encryption password, and Qubes login password.  The USB
keyboard/mouse connect almost instantly after that (within the 90 seconds).

I was able to create and run a Centos 7.4 HVM with no issues.

I've had the one HVM, two F26 PVH AppVMs running simultaneously (plus
sys-usb, sys-net, & sys-firewall) with no issues.  Both running Firefox
(multiple tabs), GIMP, Libreoffice, and terminal simultaneously.

I only tested sleep mode once (closed the lid).  While it did go to sleep,
and was able to wake up, ethernet and attached USB keyboard/mouse never
came back.  I unplugged ethernet and re-attached and still no-go.  Same
with mouse/keyboard... even physically unplugged and plugged back in, did
not come back.  I did not pursue it further as I don't use that function
very often.  But if sleep/suspend is important to you, you may have to do
some tweaking, unless you don't use wired ethernet and USB devices.  Wifi
did come back by itself however.  Sound too.

All in all a very snappy machine so far.

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


Qubes-HCL-Dell_Inc_-Inspiron_7577-20180205-151442.yml
Description: application/yaml

[qubes-users] Known working USB to VGA or USB to HDMI adapters with Qubes?

[Joe Thielen]

Does anyone have direct knowledge of a USB to VGA or USB to HDMI adapter
that is known to work in Qubes?

I've installed Qubes 4.0-rc3 on my new Dell 7577 laptop (Nvidia Geforce
GTX).  Everything seems good except I can not get another monitor to work
on the HDMI port (HCL forthcoming).  I followed the Qubes NVIDIA
instructions and get about the same issue as others have reported... X does
not start.  After I blacklisted the nvidia and nouveau modules I was able
to get X to function again.  xrandr in dom0 shows HDMI and DisplayPort
ports as disconnected, even when I have an HDMI monitor connected.  One
weird thing, when I plug in an HDMI monitor, the Qubes Display app pops up
automatically... like it knows something was plugged in, but nothing I did
was able to make it available for use or say "connected" in xrandr.

Anyway, I'd really like to add another monitor (or two!!!) to the setup.
If I have to purchase an external adapter to bypass the issue I guess that
will work, but I want to know that it works specifically with Qubes before
I buy one.  I've done searches for Qubes and Fedora and didn't seem to come
up with anything specifically positive, only negative reports.

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

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

On Saturday, December 2, 2017 at 6:04:08 PM UTC-8, Marek Marczykowski-Górecki 
wrote:
> Does anyone have an idea what the difference livecd-iso-to-disk make,
> compared to isohybrid? If possible, we'd like to installation iso work
> out of the box on UEFI systems, including new ones...
> 
> I wonder if Fedora netinst iso (_not_ Live iso) boot on such new
> hardware, after directly dd-ing it to USB stick. Can you check that?
> Just see if installer starts. It's here:
> 
> https://alt.fedoraproject.org/
> 
> If that would work, I can try to find what is different about those
> images and fix Qubes iso.

Hi Marek,

I just tried the Fedora netinst image, dd'd it onto an USB stick, and it 
successfully booted.

One minor observation i made i the process: the Qubes ISO9660 volume label 
includes a dot/period; the netinst image doesn't.

This triggered a deja-vu from understanding why we need to update the volume 
label and edit xen.cfg after using livecd-iso-to-disk: this approach creates a 
FAT32 to hold everything, but the xen.cfg file uses the Qubes volume label 
"Qubes-R4.0-rc3-x86_64" to identify where to load inst.stage2 from, and FAT32 
volumes can't have labels that are this long and they also have trouble with 
periods in the label. Sure, FAT32 isn't ISO9660, but ISO9660 is also a bit 
troubled with a few different interpretations of the standard and restrictions.

Also, a Qubes dd'd USB stick contains an ISO9660 partition and a FAT16 
partition with a stub; I could validate that my T470 boots directly from 
ISO9660, ignoring the FAT16 partition.

Speaking of which... I found a way to make a USB install stick, much easier 
than using livecd-iso-to-disk tools:
- create a FAT32 partition (not too big) on the USB stick
- mark the partition as active (if MBR; not needed if GPT)
- mount the ISO image
- mirror the file system structure from the mounted ISO image to the FAT32 
volume
- give the FAT32 volume a meaningful label (not to exceed 11 chars)
- update EFI/BOOT/xen.cfg on the FAT32 volume to match that label

You can even do that on Windows without needing Rufus :) I'll update the doc 
one more time to include instructions for Windows users. Maybe even remove the 
livecd-iso-to-disk instructions again, I'm not sure.
-joe

-- 
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/7ca2e559-d1a6-4a75-a3a4-abb9eb3b3fe1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

On Saturday, December 2, 2017 at 3:41:26 AM UTC-8, Stephan Marwedel wrote:
> Now we have a nice recipe to install Qubes on modern Thinkpads. This 
> should become part of the official documentation.

Pull request: https://github.com/QubesOS/qubes-doc/pull/490

-- 
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/308d1a40-7bf9-453b-a696-c0c94eedd26a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

On Friday, December 1, 2017 at 2:01:47 PM UTC-8, Stephan Marwedel wrote:
> I have installed Qubes 3.2 successfully on my Thinkpad T470p
>   (20J6CTO1WW). This machine is pretty similar to the T470, except
>   that is has a quad-core i7 CPU.  It runs perfectly and all Qubes
>   functionality is available on that machine. The installation,
>   however, was not an easy task. 
> 
> 
> 
> 1. Booting: UEFI is not a problem for the Qubes installer, but
>   you must pay attention on how you created the bootable install
>   media. Just using dd is not sufficient. I had to use the
>   livecd-tools from Fedora to create the install media. After
>   creating the media I had to manually set the partition label to
>   BOOT using the dosfslabel utility. Otherwise, I was unable to boot
>   from the media. It was not necessary to fall back to legacy boot
>   or to mess around with the Grub configuration. 
> 
> 
> 2. Networking: The onboard ethernet  hardware is only supported by a
> 4.9 kernel or later, but the installer containts a 4.4 kernel. So
> you have no network in teh sys-net vm. You have to manually download
> the source of the Intel network driver, compile it and install it
> using a USB media in the template vm. As soon as you have network
> access, upgrade dom0 to using the testing or unstable repository.
> 
> 
> 
> 3. Graphics: The Kaby Lake Intel graphics works well with a newer
> kernel. 
> 
> 
> 
> Summary: Prepare the boot media with more care than for older
> machines. Compile the ethernet network driver manually to enable
> network access after the install. Upgrade to kernel 4.9 in dom0 as
> soon as possible to enable graphics and networking support of your
> Thinkpad.

Danke, Stephan, your pointers were very valuable!

At first, I decided to just borrow an external DVD drive and boot off a DVD 
burned from the ISO, in UEFI mode. The result however was the same as when 
booting from my previously-created USB stick: grub boots, but no matter what i 
select, the screen briefly flashes and takes me back to grub. So.. yeah, the 
ISO image does not appear to be usable out of the box on some UEFI devices, 
even when burning it to a DVD.

Your description of the livecd-tools helped make good progress, but still 
without ability to boot the installer completely, but they sent me in the right 
direction. I then found 
https://groups.google.com/forum/#!topic/qubes-users/4VsKdxnKHBk, which 
described a process very similar to yours (it omits the part about using 
dosfslabel, but has a part about also updating the xen.cfg file).

Altogether, this did the trick!

In condensed form, this is what i did to create a USB install stick that works 
with UEFI on the T470:
1. Use the "livecd-iso-to-disk" utility from fedora livecd-tools to put the ISO 
image onto an USB stick
2. rename the USB stick's partition label to BOOT
3. edit the /BOOT/EFI/xen.cfg file on the USB stick's partition to make sure 
all LABEL= instances are replaced with LABEL=BOOT

In a bit more detail:
- booted Fedora 26 live USB stick in UEFI mode
- installed livecd-tools: sudo dnf install livecd-tools
- attached a USB stick that contains the Qubes 4 RC3 x86-64 ISO image file
- verified digests and signatures for ISO image
- attached another USB stick to the fedora live instance to put the Qubes 
installer on (/dev/sdd)
- repartitioned /dev/sdd USB stick with a single (8GB) FAT32 partition and MBR, 
and marked bootable
- started imaging: sudo livecd-iso-to-disk 
/run/media/liveuser/qsrc/Qubes-R4.0-rc3-x86_64.iso /dev/sdd1
- waited for everything to complete (took quite a while)
- used dosfslabel to rename the qubes installer USB stick: sudo dosfslabel 
/dev/sdd1 BOOT
- manually edited the xen.cfg file on the install stick (located at 
/BOOT/EFI): replaced all instances of "LABEL=Qubes-R4.0-rc3-x86_64" 
with "LABEL=BOOT"

Success!

Now one thing that is different is that after installation, the 
correct/selected keyboard layout (in my case English-Dvorak) isn't active when 
prompted for the LUKS passphrase; but after entering it in QWERTY, Qubes OS 
boots and completes configuration. 

But the primary issue, not being able to boot in UEFI mode, is solved.

Thanks everyone for your input!

Cheers,
-joe

-- 
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/1e222b94-a3f7-4a54-bacd-fac7231fbc9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

On Thursday, November 30, 2017 at 1:37:59 PM UTC-8, Mike Keehan wrote:
> Hi Joe,
> 
> This is the content of my EFI/qubes directory after installing
> Qubes 4.0-rc3 in EFI mode :-
> 
> -rwxr-xr-x 1 root root 22231327 Nov 28 17:29 
> initramfs-4.9.56-21.pvops.qubes.x86_64.img
> -rwxr-xr-x 1 root root  5316864 Nov 28 17:29 
> vmlinuz-4.9.56-21.pvops.qubes.x86_64
> -rwxr-xr-x 1 root root  902 Nov 28 17:36 xen.cfg
> -rwxr-xr-x 1 root root  2056349 Nov 28 17:29 xen.efi
> 
> I then selected which EFI directory to boot from using the bios.
> 
> I think the EFI/Boot directory is just a default.
> 
> Mike.

Thanks, Mike. In my case I can't even install Qubes in EFI mode because the 
installer won't run; and installing Qubes in Legacy mode will lead to an empty 
.cfg file. I'll take another stab at it tonight.
-joe

-- 
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/38be37d1-796e-436d-a9c2-1ca045755d63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

On Thursday, November 30, 2017 at 11:12:34 AM UTC-8, Tom Zander wrote:
> I think its a known issue that Qubes doesn't support EFI.

Do you have a reference for that? I don't think that's true.

I can run Qubes OS without problems with UEFI on other hardware, and there is 
even UEFI troubleshooting guidance at 
https://www.qubes-os.org/doc/uefi-troubleshooting/ - which doesn't mention lack 
of support for EFI...

-joe

-- 
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/50c1b764-46b8-4275-bd71-df7e3d7d0ca6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

On Thursday, November 30, 2017 at 2:07:59 AM UTC-8, Joe Hemmerlein wrote:
> Any hints about troubleshooting the UEFI boot option are appreciated; i can 
> also provide more exact details about what i already tried. Given the specs 
> of this machine, I'm really determined to not give up easily.
> 

Here is a detailed log of what I tried.

ThinkPad T470 (20HD-CT01WW)
UEFI/BIOS configuration
===
Setup – Main
- UEFI BIOS Version: N1QET68W (1.43)
- UEFI BIOS Date: 2017-11-10
- Installed Memory: 32768 MB
- UEFI Secure Boot: Off

Setup – Config – USB
- USB UEFI BIOS Support: Enabled

Setup – Security – Security Chip
- Security Chip Type: TPM 2.0
- Security Chip: Enabled
- Intel TXT Feature: Enabled

Setup – Security – Memory Protection
- Execution Prevention: Enabled

Setup – Security – Virtualization
- Intel Virtualization Technology: Enabled
- Intel VT-d Feature: Enabled

Setup – Security – Secure Boot
- Secure Boot: Disabled

Setup – Security – Intel SGX
- Intel SGX Control: Software 
- Current State: Enabled

Setup – Security – Device Guard
- Device Guard: Disabled

Setup – Startup
- Boot (Priority Order) includes "USB HDD" and "NVMe0 Intel SSDPEKKF256G7L"
- UEFI/Legacy Boot: UEFI Only
- CSM Support: Yes


Initial Setup Experience

- Created USB stick using Rufus with dd method from 4.0R3 ISO image
- Able to boot USB stick by invoking UEFI Boot Menu with F12, then selecting 
USB HDD
- This results in a text mode grub menu with the four options
- Option 1 (Test media and install Qubes R4.0-rc3) is default and will start 
automatically
- Option 1 then fails: "XEN 4.8.2 (c/s ) EFI loader // Failed to boot both 
default and fallback entries"
Only way I found to install Qubes OS:
- Change BIOS/UEFI setup configuration item "UEFI/Legacy Boot" to "Legacy Only"
- Boot from USB and install. GUI install works fine with default options (all I 
change is my keyboard layout to Dvorak)
- Reboot, and configure Qubes OS with default options
- Qubes OS starts and is usable as long as BIOS/UEFI setup configuration is 
using "Legacy Only", but...
--- Problem: no TPM available. According to Lenovo, the TPM2.0 will not be 
exposed in legacy boot scenario; in order for TPM to be exposed, it seems like 
we need UEFI boot.
Trying to switch to UEFI

- As described at 
https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-finished-but-qubes-boot-option-is-missing-and-xencfg-is-empty,
 we have an empty (0 bytes) xen.efi file in /boot/efi/EFI/qubes. Followed steps 
in guide, essentially:
- Booted into Qubes with legacy boot
- Renamed xen-4.8.2.efi to xen.efi
- Copied contents from xen.cfg I troubleshooting guide to xen.cfg in dom0
- Edited xen.cfg to adjust for current kernel number in four places
- Rebooted
- Booted with legacy boot from USB install stick
- Selected Advanced – Rescue a Qubes installation
- Selected option 1 to continue
- Found installation on device nvme0n1p2 and entered LUKS passphrase
- Got Shell
- Changes made to files still visible in /mnt/sysimage/boot/efi/EFI/qubes
- Ran the efibootmgr command as shown in the guide, but adjusted devicename. I 
didn’t know whether I should add nvme0n1 or nvme0, or maybe even nvme0n1p1 – so 
I ran the command three times with different labels.
--- Problem: Can't run efibootmgr. Error: "EFI variables are not supported on 
this system"
- Rebooted, but also changing BIOS/UEFI setup boot options again
--- Boot option "Both" with "UEFI First" failed to boot from USB (went back to 
UEFI boot menu)
--- Boot option "Both" with "Legacy First" allowed me to boot from USB to 
rescue a Qubes installation. 
--- Problem: efibootmgr command still fails with "EFI variables are not 
supported on this system".
- It looks like I may need to somehow boot with UEFI enabled I order to run 
efibootmgr.
- Trying a Fedora Live CD (Fedora-Workstation-Live-x86_64-26-1.5.iso)
- Created USB stick with Rufus dd method
- Booted USB stick with boot option set to "UEFI Only" and "CSM Support" 
enabled.
- Fedora stick boots successfully into Fedora 26 Live
- Efibootmr command generally works
- Tried it:
--- efibootmgr -v -c -u -L Qubes431 -l /EFI/qubes/xen.efi -d /dev/nvme0n1 -p 1 
"placeholder /mapbs /noexitboot"
--- efibootmgr -v -c -u -L Qubes431 -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1 -p 
1 "placeholder /mapbs /noexitboot"
--- efibootmgr -v -c -u -L Qubes433 -l /EFI/qubes/xen.efi -d /dev/nvme0n1p1 
"placeholder /mapbs /noexitboot"

- Rebooted (still with "UEFI Only" and "CSM" boot options enabled)
- Selected F12 again for UEFI boot menu, and I could see both new added 
entries. I tried both of them, but...
--- Problem: selecting ay of those entries just gets us back to the UEFI boot 
menu. They’re failing visually the same way as the standa

[qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)

[Joe Hemmerlein]

Hi,

so far it was easy to install and run Qubes OS 4.0 RC3 (and RC2) on this
hardware - as long as I keep boot mode on "Legacy Only".

However, the TPM chip on this hardware works in UEFI boot mode only; and
even with secureboot disabled and CSM support enabled, I can't get Qubes OS
to boot in UEFI mode:
- The installer doesn't run in UEFI mode (I get text mode grub, but
whatever i select simply does nothing and returns to grub)
- If I turn UEFI mode on after installing Qubes OS, I don't even get grub.
- I tried the UEFI troubleshooting guide to no avail, although I was unable
to run efibootmgr directly while in legacy boot mode ("EFI variables are
not supported on this system") so in order to run efibootmgr, i booted a
separate Fedora 26 Live image which does boot in UEFI mode. However, even
with updated records, the result is the same: selecting those options from
the UEFI boot menu simply makes the screen flicker once and then i'm back
in the UEFI boot menu.
- I tried copying the EFI and CFG file to /EFU/BOOT and renaming them to
BOOTX64.EFI and .CFG, and also created new entries with efibootmgr for
this, again without success.


I also tried installing Qubes OS 3.2 on this system which didn't work and
initial troubleshooting failed; but I'd like to concentrate my efforts on
making this work for Qubes 4.0 so i didn't spend too much time on getting
Qubes OS 3.2 on the T470.

Any hints about troubleshooting the UEFI boot option are appreciated; i can
also provide more exact details about what i already tried. Given the specs
of this machine, I'm really determined to not give up easily.

For now, I'll test other functionality in legacy mode only.

Cheers,
-joe

-- 
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/CAJmbC%3DEVMcAMKEXLGPooXa-kQt7_vuUDigozex%2Bq4iUSARykoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-LENOVO-20HDCTO1WW-20171129-163138.yml
Description: application/yaml


Qubes-HCL-LENOVO-20HDCTO1WW-20171129-163138.cpio.gz
Description: GNU Zip compressed data

[qubes-users] HCL - Gigabyte B150 Mobo / Intel i7-6700k CPU / WD Blue M.2 1TB SSD

[Joe Thielen]

Machine seems to work well, having run overnight.  16GB RAM currently but
will be upgrading to 32GB.  No TPM.

Updated BIOS before installing Qubes using mobo built-in installer.

Had some issues getting the Qubes installer to work (USB).  Playing with
the boot settings convinced it to work.  I seem to recall choosing to boot
from the USB partition #1, not from the drive itself as playing a factor.
The BIOS "compatibility module" settings did not help, I recall turning
those off.  Also had to turn on the items for VT-d & VT-x (in separate
places on the menus).  The first time the install actually ran is crashed
after language selection.  I rebooted and it ran fine the second time.

Video works - using VGA.  Mobo also has HDMI & DVI, have not tried those
(no plans on it).

Networking works.

No use for sound, have not tried it.

M.2 SSD seems to work great.  Copying VMs takes a little longer than I
would expect, but still faster than a traditional HD.

I've had several CentOS 7 HVMs (CLI, no GUI - Although the installer was
GUI and ran fine) running concurrently as well as a work VM with multiple
terminals and Firefox running, all speedy.

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


Qubes-HCL-System_manufacturer-System_Product_Name-20170329-173008.cpio.gz
Description: GNU Zip compressed data


Qubes-HCL-System_manufacturer-System_Product_Name-20170329-173008.yml
Description: application/yaml

[qubes-users] no tpm, what now

[joe . m]

hi.
since my laptop seems to have no tpm i can't install aem.
how con i try to protect my laptop now?
there is an option im my efi to require a password on each boot (instead of
only requiring it when i access my efi).
does this offer any real protection?
is there something else i can do?

with best regards.
joe mitchell


-

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 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/20170219154959.Horde.EuwApaZw_ArgOBD1dUqUAQ1%40www.vfemail.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: boot problem after switching bios from uefi to legacy to uefi

[joe . m]

 Quoting jo...@vfemail.net:


hi.
since i saw multiple people posting things about aem, i thought i would
also setup aem.

i looked at


https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README

and saw i need to use legacy.
i installed my system while booting uefi and then switched to legacy.
i was not sure whether the system could boot again, but if it did not
boot, i would switch back again.

after switching to legacy, the system did not boot (i am not sure wheter
it should boot normally after switchin, of if that does not work).
after switching back to uefi, it still does not boot
is there a way to fix this?

also when looking at the bios, i did not find an option for TPM or TXT.
but there is some stuff like secure boot mode/control with pks (could
this be it?)
or does my laptop mybe not have this feature?

some system info:
msigp60
bios version E16GDIMS.30B (build date: 23/08/2013)

should i update the bios? (maybe the old bios version does not display
the tpm option)

i am grateful for any ideas.
wit best regards.
joe mitchell


managed to fix this!

the problem seems to be:
efi forgot the entry

i found a guide via:
https://forums.linuxmint.com/viewtopic.php?t=204585#p1063821
-> http://www.rodsbooks.com/efi-bootloaders/installation.html#register

here my guide for perople as stupid as me. (maybe you can add this to
your doc)
1) create a qubes install media (have fun verifying the master key again)
2) boot it and select the recovery entry (last entry)
3) select continue (oprion 1)
4) enter your key
5) hit enter (to get a shell)
6) chroot /mnt/sysimage
7) fdisk -l to find your efi dev (we assume it is /dev/sda1)
8) use efibootmgrt to fix your efi.
efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\qubes\\xen.efi -L qubes
9) reboot

on lenovo you may have to use a different name.
according to  
http://www.rodsbooks.com/efi-bootloaders/installation.html#register :
'Also note that at least one manufacturer (Lenovo) ships products with  
a known bug that causes the system to refuse to boot unless the boot  
loader's name (NewLoader in this example) is either Windows Boot  
Manager or Red Hat Enterprise Linux.'


with best regards.
joe mitchell

ps.: does someone know a good mail-provider where you can create an  
anonymous free account (via tor and no phone number etc required).
openmailbox has currently disabled new accounts and vfemail delays my  
last mail by 11h (currently the delay is only 6717 seconds, so this  
seemed to be a temp problem)



-

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 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/20170219023552.Horde.WZB9k2CzXiZKhWBofZ4KUQ1%40www.vfemail.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] boot problem after switching bios from uefi to legacy to uefi

[joe . m]

hi.
since i saw multiple people posting things about aem, i thought i would
also setup aem.

i looked at
https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README
and saw i need to use legacy.
i installed my system while booting uefi and then switched to legacy.
i was not sure whether the system could boot again, but if it did not boot,
i would switch back again.

after switching to legacy, the system did not boot (i am not sure wheter it
should boot normally after switchin, of if that does not work).
after switching back to uefi, it still does not boot
is there a way to fix this?

also when looking at the bios, i did not find an option for TPM or TXT.
but there is some stuff like secure boot mode/control with pks (could this
be it?)
or does my laptop mybe not have this feature?

some system info:
msigp60
bios version E16GDIMS.30B (build date: 23/08/2013)

should i update the bios? (maybe the old bios version does not display the
tpm option)

i am grateful for any ideas.
wit best regards.
joe mitchell


-

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 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/20170218035148.Horde.5vsGnlMVjJZ9SuAwC2e0ZQ1%40www.vfemail.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Ad-blocking ProxyVM?

[Joe Ruether]

On Monday, February 13, 2017 at 9:35:52 PM UTC-5, Joe Ruether wrote:
> Ok, I need to simplify this. I need help, I don't know what I am missing. Is 
> anyone able to recreate the following netcat test?
> 
> I cannot seem to get the DNAT portion of the iptables to work at all. Here is 
> a very simple test:
> 
> On the proxyvm, I use the following rules to redirect port 5353 to localhost, 
> and allow the connection:
> 
> iptables -t nat -I PR-QBS 1 -d 10.137.4.1 -p tcp --dport 5353 -j DNAT 
> --to-destination 127.0.0.1
> iptables -I INPUT 1 -p tcp --dport 5353 -j ACCEPT
> 
> Then, on the proxyvm, I run the following command to listen on that port (no 
> other service is running on that port):
> 
> nc -l -p 5353
> 
> Finally, on the AppVM, I run the following command:
> 
> nc 10.137.4.1 5353
> 
> My expectation is that the two netcats will connect, however they don't. What 
> do I need to do to get my AppVM to talk to my ProxyVM? Thanks

Well, I feel like a fool, I finally figured it out. I realized the DNAT rules 
aren't necessary at all, so all I needed was this:

iptables -I INPUT 1 -p tcp --dport 5353 -j ACCEPT

Of course I overcomplicated such a simple problem... I learned a bunch about 
iptables though.

I also have the PiHole adblocker working now. In case anyone stumbles onto this 
thread trying to do the same thing, the final trick was to add the Qubes vif 
interfaces to a dnsmasq config file to it would listen on them.

-- 
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/fb192195-af69-4793-b4a2-1f787af2ddbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Ad-blocking ProxyVM?

[Joe Ruether]

Ok, I need to simplify this. I need help, I don't know what I am missing. Is 
anyone able to recreate the following netcat test?

I cannot seem to get the DNAT portion of the iptables to work at all. Here is a 
very simple test:

On the proxyvm, I use the following rules to redirect port 5353 to localhost, 
and allow the connection:

iptables -t nat -I PR-QBS 1 -d 10.137.4.1 -p tcp --dport 5353 -j DNAT 
--to-destination 127.0.0.1
iptables -I INPUT 1 -p tcp --dport 5353 -j ACCEPT

Then, on the proxyvm, I run the following command to listen on that port (no 
other service is running on that port):

nc -l -p 5353

Finally, on the AppVM, I run the following command:

nc 10.137.4.1 5353

My expectation is that the two netcats will connect, however they don't. What 
do I need to do to get my AppVM to talk to my ProxyVM? Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c23efb9f-f344-4523-b24d-ed8d7406723e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Ad-blocking ProxyVM?

[Joe Ruether]

On Friday, February 10, 2017 at 6:21:49 PM UTC-5, Unman wrote:
> On Fri, Feb 10, 2017 at 04:10:06AM -0800, Joe Ruether wrote:
> > On Thursday, February 9, 2017 at 10:21:26 AM UTC-5, Unman wrote:
> > > On Thu, Feb 09, 2017 at 04:32:12AM -0800, Joe Ruether wrote:
> > > > Hello!
> > > > 
> > > > I am trying to set up a proxy vm that will redirect DNS requests to a 
> > > > local DNS server, for the purposes of adblocking.
> > > > 
> > > > Here is the setup:
> > > > 
> > > > internet <-> sys-net <-> sys-firewall <-> MY_PROXYVM <-> 
> > > > appvm_with_firefox
> > > > 
> > > > I have created a proxyvm based on a debian-8 template, and have 
> > > > installed PiHole (https://pi-hole.net/) as an adblocker. PiHole works 
> > > > by starting a DNS server (dnsmasq) and rejecting any dns queries to 
> > > > domains that serve ads.
> > > > 
> > > > If (in the proxyvm) I set the contents of /etc/resolv.conf to 127.0.0.1 
> > > > and open firefox (in the proxyvm), I can verify that the adblocker is 
> > > > working correctly.
> > > > 
> > > > The issue I am having is when I used the proxyvm as the netvm for 
> > > > another appvm. Without any other changes, my appvm's firefox has 
> > > > internet access, but the adblocker has no effect. Of course, some 
> > > > additional setup is needed, but I'm not exactly sure how to do that.
> > > > 
> > > > I'm not very good with iptables, and every attempt I have made to 
> > > > redirect DNS to 127.0.0.1 in the proxyvm has failed (and caused both 
> > > > the proxyvm and the appvm to lose the ability to browse). Here are the 
> > > > commands I ran (in the proxyvm):
> > > > 
> > > > #!/bin/bash
> > > > DNS=127.0.0.1
> > > > NS1=10.137.4.1
> > > > NS2=10.137.4.254
> > > > iptables -t nat -A PR-QBS -d $NS1 -p udp --dport 53 -j DNAT --to $DNS
> > > > iptables -t nat -A PR-QBS -d $NS1 -p tcp --dport 53 -j DNAT --to $DNS
> > > > iptables -t nat -A PR-QBS -d $NS2 -p udp --dport 53 -j DNAT --to $DNS
> > > > iptables -t nat -A PR-QBS -d $NS2 -p tcp --dport 53 -j DNAT --to $DNS
> > > > 
> > > > ---
> > > > 
> > > > I pieced this together from what I could find from the VPN 
> > > > documentation on the qubes website as well as the contents of 
> > > > /usr/lib/qubes/qubes-setup-dnat-to-ns
> > > > 
> > > > Running the qubes-setup-dnat-to-dns script by itself after changing 
> > > > /etc/resolv.conf (all this on the proxyvm) didn't seem to have any 
> > > > impact.
> > > > 
> > > > So! My question is, am I going about this correctly? I think I need to 
> > > > modify the iptables in the proxyvm to redirect any incoming (from the 
> > > > appvm) DNS queries to 127.0.0.1, while still allowing outgoing (to the 
> > > > internet, from the proxyvm) DNS queries to get out. Along with this, I 
> > > > think I need to ensure that there are rules that allow all other 
> > > > traffic to pass through unhindered.
> > > > 
> > > > Or is there a different, qubes-specific way of handling DNS that I 
> > > > should be using? After inspecting the sys-firewall ipconfig and 
> > > > iptables, it is clear that something behind-the-scenes is happening 
> > > > where an additional NIC is created for each attached appvm, and the 
> > > > iptables are being populated automatically somehow. I'm not sure how 
> > > > the proxyvm is supposed to get the addresses of the appvm and 
> > > > sys-firewall (my script above had addresses hardcoded).
> > > > 
> > > > Thank you for any help! If I get all this working, I'm planning on 
> > > > making a Salt file that can create the adblocking proxyvm.
> > > > 
> > > 
> > > I don't see any reason why this shouldn't work.
> > > I wouldn't be so specific in the nat rules but that's your call. Just
> > > protocol and post would suffice.
> > > 
> > > One obvious point is that you are ADDING those rules to the end of the
> > > PR-QBS chain without flushing it first. If you already have redirect
> > > rules there they will trigger first.
> > > What does your nat table look like after you run that script?
> > > 
> >

Re: [qubes-users] Ad-blocking ProxyVM?

[Joe Ruether]

On Thursday, February 9, 2017 at 10:21:26 AM UTC-5, Unman wrote:
> On Thu, Feb 09, 2017 at 04:32:12AM -0800, Joe Ruether wrote:
> > Hello!
> > 
> > I am trying to set up a proxy vm that will redirect DNS requests to a local 
> > DNS server, for the purposes of adblocking.
> > 
> > Here is the setup:
> > 
> > internet <-> sys-net <-> sys-firewall <-> MY_PROXYVM <-> appvm_with_firefox
> > 
> > I have created a proxyvm based on a debian-8 template, and have installed 
> > PiHole (https://pi-hole.net/) as an adblocker. PiHole works by starting a 
> > DNS server (dnsmasq) and rejecting any dns queries to domains that serve 
> > ads.
> > 
> > If (in the proxyvm) I set the contents of /etc/resolv.conf to 127.0.0.1 and 
> > open firefox (in the proxyvm), I can verify that the adblocker is working 
> > correctly.
> > 
> > The issue I am having is when I used the proxyvm as the netvm for another 
> > appvm. Without any other changes, my appvm's firefox has internet access, 
> > but the adblocker has no effect. Of course, some additional setup is 
> > needed, but I'm not exactly sure how to do that.
> > 
> > I'm not very good with iptables, and every attempt I have made to redirect 
> > DNS to 127.0.0.1 in the proxyvm has failed (and caused both the proxyvm and 
> > the appvm to lose the ability to browse). Here are the commands I ran (in 
> > the proxyvm):
> > 
> > #!/bin/bash
> > DNS=127.0.0.1
> > NS1=10.137.4.1
> > NS2=10.137.4.254
> > iptables -t nat -A PR-QBS -d $NS1 -p udp --dport 53 -j DNAT --to $DNS
> > iptables -t nat -A PR-QBS -d $NS1 -p tcp --dport 53 -j DNAT --to $DNS
> > iptables -t nat -A PR-QBS -d $NS2 -p udp --dport 53 -j DNAT --to $DNS
> > iptables -t nat -A PR-QBS -d $NS2 -p tcp --dport 53 -j DNAT --to $DNS
> > 
> > ---
> > 
> > I pieced this together from what I could find from the VPN documentation on 
> > the qubes website as well as the contents of 
> > /usr/lib/qubes/qubes-setup-dnat-to-ns
> > 
> > Running the qubes-setup-dnat-to-dns script by itself after changing 
> > /etc/resolv.conf (all this on the proxyvm) didn't seem to have any impact.
> > 
> > So! My question is, am I going about this correctly? I think I need to 
> > modify the iptables in the proxyvm to redirect any incoming (from the 
> > appvm) DNS queries to 127.0.0.1, while still allowing outgoing (to the 
> > internet, from the proxyvm) DNS queries to get out. Along with this, I 
> > think I need to ensure that there are rules that allow all other traffic to 
> > pass through unhindered.
> > 
> > Or is there a different, qubes-specific way of handling DNS that I should 
> > be using? After inspecting the sys-firewall ipconfig and iptables, it is 
> > clear that something behind-the-scenes is happening where an additional NIC 
> > is created for each attached appvm, and the iptables are being populated 
> > automatically somehow. I'm not sure how the proxyvm is supposed to get the 
> > addresses of the appvm and sys-firewall (my script above had addresses 
> > hardcoded).
> > 
> > Thank you for any help! If I get all this working, I'm planning on making a 
> > Salt file that can create the adblocking proxyvm.
> > 
> 
> I don't see any reason why this shouldn't work.
> I wouldn't be so specific in the nat rules but that's your call. Just
> protocol and post would suffice.
> 
> One obvious point is that you are ADDING those rules to the end of the
> PR-QBS chain without flushing it first. If you already have redirect
> rules there they will trigger first.
> What does your nat table look like after you run that script?
> 
> Another point may be that you don't have an incoming rule in the INPUT
> chain allowing inbound traffic to the DNS ports. Unless you've changed
> this the default rule will block inbound traffic from any vif interface.
> So you need to ensure you are allowing that traffic with an:
> iptables -I INPUT -i vif+ -p udp --dport 53 -j ALLOW
> 
> Finally, you need to consider the effects of the qubes-firewall and
> qubes-netwatcher services.
> If you want to retain these you can use
> /rw/config/qubes-firewall-user-script to override the automatic Qubes
> configuration and insert your own iptables rules.
> You can also use rc.local to set initial iptables rules.
> Remember to make those files executable if you want to use them.
> 
> Most of this is in the docs, although not easy to find.
> 
> Hope this helps
> 
> unman

Thank you for your help, I have more information 

[qubes-users] Ad-blocking ProxyVM?

[Joe Ruether]

Hello!

I am trying to set up a proxy vm that will redirect DNS requests to a local DNS 
server, for the purposes of adblocking.

Here is the setup:

internet <-> sys-net <-> sys-firewall <-> MY_PROXYVM <-> appvm_with_firefox

I have created a proxyvm based on a debian-8 template, and have installed 
PiHole (https://pi-hole.net/) as an adblocker. PiHole works by starting a DNS 
server (dnsmasq) and rejecting any dns queries to domains that serve ads.

If (in the proxyvm) I set the contents of /etc/resolv.conf to 127.0.0.1 and 
open firefox (in the proxyvm), I can verify that the adblocker is working 
correctly.

The issue I am having is when I used the proxyvm as the netvm for another 
appvm. Without any other changes, my appvm's firefox has internet access, but 
the adblocker has no effect. Of course, some additional setup is needed, but 
I'm not exactly sure how to do that.

I'm not very good with iptables, and every attempt I have made to redirect DNS 
to 127.0.0.1 in the proxyvm has failed (and caused both the proxyvm and the 
appvm to lose the ability to browse). Here are the commands I ran (in the 
proxyvm):

#!/bin/bash
DNS=127.0.0.1
NS1=10.137.4.1
NS2=10.137.4.254
iptables -t nat -A PR-QBS -d $NS1 -p udp --dport 53 -j DNAT --to $DNS
iptables -t nat -A PR-QBS -d $NS1 -p tcp --dport 53 -j DNAT --to $DNS
iptables -t nat -A PR-QBS -d $NS2 -p udp --dport 53 -j DNAT --to $DNS
iptables -t nat -A PR-QBS -d $NS2 -p tcp --dport 53 -j DNAT --to $DNS

---

I pieced this together from what I could find from the VPN documentation on the 
qubes website as well as the contents of /usr/lib/qubes/qubes-setup-dnat-to-ns

Running the qubes-setup-dnat-to-dns script by itself after changing 
/etc/resolv.conf (all this on the proxyvm) didn't seem to have any impact.

So! My question is, am I going about this correctly? I think I need to modify 
the iptables in the proxyvm to redirect any incoming (from the appvm) DNS 
queries to 127.0.0.1, while still allowing outgoing (to the internet, from the 
proxyvm) DNS queries to get out. Along with this, I think I need to ensure that 
there are rules that allow all other traffic to pass through unhindered.

Or is there a different, qubes-specific way of handling DNS that I should be 
using? After inspecting the sys-firewall ipconfig and iptables, it is clear 
that something behind-the-scenes is happening where an additional NIC is 
created for each attached appvm, and the iptables are being populated 
automatically somehow. I'm not sure how the proxyvm is supposed to get the 
addresses of the appvm and sys-firewall (my script above had addresses 
hardcoded).

Thank you for any help! If I get all this working, I'm planning on making a 
Salt file that can create the adblocking proxyvm.

-- 
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/7df5d8c4-e52f-4eec-bbea-6c9646c9d3a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Having trouble configuring VMs with Salt / qubesctl

[Joe Ruether]

On Monday, February 6, 2017 at 6:08:09 PM UTC-5, john.david.r.smith wrote:
> On 07/02/17 00:01, Joe Ruether wrote:
> > Hello! I am using Qubes 3.2 and I am attempting to automate the 
> > configuration of my VMs using the Salt / qubesctl management stack.
> >
> > I am very new to salt, but I have been experimenting and I think I 
> > understand how it works. I have written some state files to configure dom0 
> > and I haven't had any problems with those.
> >
> > The problem I am running into is that whenever I try to do anything at all 
> > with a VM, it seems that the qubesctl process just hangs. I've let it run 
> > overnight just to see, and it definitely isn't doing anything. I also don't 
> > know how to make it more verbose so I can debug the issue.
> >
> > Here are the contents of my top file, /srv/salt/custom/setup.top:
> >
> > base:
> >   dom0:
> > - custom.template.fedora-24
> >
> >   fedora-24:
> > - custom.up-to-date
> >
> > ---
> >
> > The goal I am trying to accomplish is to install the fedora-24 template, 
> > then update the packages on it. Here is my custom.template.fedora-24.sls:
> >
> > #!pyobjects
> > Pkg.installed("qubes-template-fedora-24")
> > Qvm.prefs("fedora-24", label="black", netvm="sys-firewall")
> >
> > ---
> >
> > And here is my custom.up-to-date.sls:
> >
> > #!pyobjects
> >
> > system = grains("id")
> > #Pkg.uptodate(system, refresh=True)
> > Test.nop(system)
> >
> > ---
> >
> > Notice how I commented out the uptodate function and replaced it with a 
> > nop, with the intention of just getting it to return true.
> > When I run the following command, dom0 successfully installs and configures 
> > the fedora-24 template, and the fedora-24 template is started, but after 
> > that, it freezes:
> >
> > qubesctl --all state.highstate
> >
> > CTRL-C doesn't give me back a prompt, instead I get errors regarding pool 
> > workers. I end up using CTRL-Z and issuing a "killall -9 qubesctl" to make 
> > it stop.
> >
> > I don't know how to get more information on the VM to discover what is 
> > going wrong. I have (manually) fully updated dom0 and restarted the 
> > physical computer. Any tips would be much appreciated. Thank you!
> >
> i never had this kind of problem and can't really help you with your 
> sls-files, since i am only used to the yaml + jinja form.
> but you could take a look at the documentation for debugging salt:
> https://www.qubes-os.org/doc/salt/#debugging

I figured out my issue, at some point during my experiments I switched the 
default template to debian-8. It took me a while to find the disp-mgmt-* VMs, 
they were hidden and it wasn't clear that they were being used. Apparently, I 
was hitting this bug because I haven't updated my debian-8 template yet (I was 
going to update it with salt! chicken-and-egg problem...)
https://github.com/QubesOS/qubes-issues/issues/

Anyway, it looks like I am good to go for now, thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ab51c88f-f065-4dbc-8c4b-cfbbc36d4a9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Having trouble configuring VMs with Salt / qubesctl

[Joe Ruether]

Hello! I am using Qubes 3.2 and I am attempting to automate the configuration 
of my VMs using the Salt / qubesctl management stack.

I am very new to salt, but I have been experimenting and I think I understand 
how it works. I have written some state files to configure dom0 and I haven't 
had any problems with those.

The problem I am running into is that whenever I try to do anything at all with 
a VM, it seems that the qubesctl process just hangs. I've let it run overnight 
just to see, and it definitely isn't doing anything. I also don't know how to 
make it more verbose so I can debug the issue.

Here are the contents of my top file, /srv/salt/custom/setup.top:

base:
  dom0:
- custom.template.fedora-24

  fedora-24:
- custom.up-to-date

---

The goal I am trying to accomplish is to install the fedora-24 template, then 
update the packages on it. Here is my custom.template.fedora-24.sls:

#!pyobjects
Pkg.installed("qubes-template-fedora-24")
Qvm.prefs("fedora-24", label="black", netvm="sys-firewall")

---

And here is my custom.up-to-date.sls:

#!pyobjects

system = grains("id")
#Pkg.uptodate(system, refresh=True)
Test.nop(system)

---

Notice how I commented out the uptodate function and replaced it with a nop, 
with the intention of just getting it to return true.
When I run the following command, dom0 successfully installs and configures the 
fedora-24 template, and the fedora-24 template is started, but after that, it 
freezes:

qubesctl --all state.highstate

CTRL-C doesn't give me back a prompt, instead I get errors regarding pool 
workers. I end up using CTRL-Z and issuing a "killall -9 qubesctl" to make it 
stop.

I don't know how to get more information on the VM to discover what is going 
wrong. I have (manually) fully updated dom0 and restarted the physical 
computer. Any tips would be much appreciated. Thank you!

-- 
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/81866bb4-7d1c-4edc-89a2-52a172a17164%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to enable permanent full screen mode in appvm ?

[joe bobby]

nothing really works mentioned here about enabling
full screen mode in my  fedora appvm.

all I want is watch youtube videos in full screen.
it does not matter if I still have a colored bar on the top of my screen.

just whenever I press full screen on youtube videos, the appvm freezes...



how to enable youtube fullscreen permanently without having to type in a 
command every time?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6eff5bab-114a-4c1a-9fad-f9b7e884f434%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Adding shortcuts to desktop for commonly used apps like untrusted firefox

[joe yuser]

On Friday, September 23, 2016 at 8:52:04 PM UTC-5, joe yuser wrote:
> Hi,
> 
> I'm a qubes-os newbie, so I'm probably missing something obvious, but am 
> asking to be sure.
> 
> I can add additional icons in the xfce vm menus with no issues, but I can't 
> find a way to send a copy to the desktop. I don't know if I'm having a menu 
> or touchpad click issue, but I can only launch the app with a left click, or 
> straight into edit mode of the launcher with a right click. 
> 
> If I create a new launcher, put in the same values under edit, I can launch 
> the app in the vm I want, but the icon isn't available, only generic ones 
> without coloring.
> 
> This is on an HP Envy 360.

update: I am successful with icon & color if I copy launcher from 
/var/lib/qubes/appvms/untrusted/apps/ , just wondering if I'm missing a better 
way.

-- 
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/21ae17b2-20fe-43cd-80e0-697deb9cf706%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Adding shortcuts to desktop for commonly used apps like untrusted firefox

[joe yuser]

Hi,

I'm a qubes-os newbie, so I'm probably missing something obvious, but am asking 
to be sure.

I can add additional icons in the xfce vm menus with no issues, but I can't 
find a way to send a copy to the desktop. I don't know if I'm having a menu or 
touchpad click issue, but I can only launch the app with a left click, or 
straight into edit mode of the launcher with a right click. 

If I create a new launcher, put in the same values under edit, I can launch the 
app in the vm I want, but the icon isn't available, only generic ones without 
coloring.

This is on an HP Envy 360. 

-- 
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/92d2bc40-c27d-4908-ac49-bc530f33dbe7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HVMs auto-resizing, causing positioning issues.

[Joe Thielen]

On Fri, Aug 19, 2016 at 3:15 PM, Andrew David Wong  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-08-19 09:00, Joe Thielen wrote:
> > I have a minor GUI usability issue.
> >
> > I'm using a smaller monitor, and my CentOS 7 HVMs seem to always want to
> > take up the entire height of the screen.  The problem is the HVM window
> > title bar will show at the top cutting off a little at the bottom of the
> > window.  When using text-mode/CLI, this means once I get to the bottom of
> > the screen I can't see what I'm typing.
> >
> > I've tried right-clicking on the title bar, going to More Actions, then
> > Special Window Settings.  If I set Position to Force 0,-25, this seems to
> > work when I do it manually.
> >
> > When the HVM boots again it works... for the first bootloader screen.
> > However, after that, the HVM re-sizes itself, and I'm in the same boat
> > again.  Now, when I go back to look at the settings, it still says Force
> > 0,-25, and if I hit OK, it will resize.
> >
> > The problem is it doesn't do this automatically upon resizing.
> >
> > I could force position to 0,0 then remove the header and frame.  But then
> > I can't figure out how to get the header back, in order to get to the
> > "Special Windows Settings" menu section again... in case I want to make
> > further changes.  If I right-click on the HVM in the taskbar there is a
> > "More Actions" section, but no "Special Windows Settings".  I can only
> > seem to find it when right-clicking the title bar.  But I've removed the
> > title bar for this HVM now...!
> >
> > Any ideas?
> >
>
> I think you're normally supposed to set the desired resolution from within
> the
> HVM OS's internal settings. In this case, try to set the desired resolution
> within CentOS.
>
> I think it's to be expected that attempting to force window properties in
> KDE's window settings wouldn't work, since CentOS doesn't "know" about
> dom0's
> window manager.
>
> A tip for moving unwieldy windows around: Since you're using KDE, you can
> simply hold alt, then drag anywhere on the window. This should work even if
> the title bar is completely offscreen.
>
> - --
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCgAGBQJXt1rIAAoJENtN07w5UDAwyEAP/izU8N2q5os1A4ewj13Czl4c
> JDa08VekcmQJRVVT2ZTmMeyqblZiuGI6xah9zBIc9gk1cryUNI588zBkGlmjlMvK
> IbEKnkZbHRTYZIdA1sjlvjhkuiJhRcl+W+rIfRtjMTz/JYeG7zIFG1XgP98g9B05
> zhCzeQPzmRYUxGZoIK1s3S0Hz470YM/dGdSy/6snfSXoCHpMY5s2z1q7Eoy7aN+q
> MabH/9lVfT/xbJceuo9ydlsKHhOcD+dmL+woJ9WJFHVr4qmKVh5XvnG+bM9Bex5B
> bYDFq7f2+E1/U35wLwLoVw7eNVGkILEF1vQmr74oFkxilZyyzlM4inLdBmWCEwRu
> J4lRNMR1Ne7KPXQ4eINZxf88f5xl8D/kPgAnEJHmI3s/+V1GDo9ljp1DR+kVxFls
> Vx/6veKJRnxOnwqCfBrl2ayO75MCywIBujPLfghrqHX18/yRoHeHMgOEBB0/jsJi
> npU8uO64cfMz9ljlfApdN/sTFj6/EmLsFuuZoQfHk5v5EwkVEsFD1aLS2pgQ9Tiw
> fgcyi8cBs5ff2fTQyOsBU9eRRHYDTWtsnTufA0AyW6V0ab823e+a/3ZrThMPKJvJ
> 5Wdg/DBFAbk+ZrzdgzaoRng0Zywt7t0+SFhQGGufbZFWSts46miWPub0V7SE0xkT
> fswhU9KPeg8ihG45AtoF
> =4oQx
> -END PGP SIGNATURE-
>
>
Thank you Andrew.  I'm not sure that I know how to set the resolution for
CentOS in non-GUI mode.  I will have to look at that.

Holding alt and draging does not work for the windows.  It does for windows
with a header/frame, but not for the ones where I've removed the
header/frame and/or forced to position 0,0.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAM9FSFxGoHA1ShX5ZY8D7vwkGfehhOF__c2QOSOckWd%3DdVGmtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HVMs auto-resizing, causing positioning issues.

[Joe Thielen]

I have a minor GUI usability issue.

I'm using a smaller monitor, and my CentOS 7 HVMs seem to always want to
take up the entire height of the screen.  The problem is the HVM window
title bar will show at the top cutting off a little at the bottom of the
window.  When using text-mode/CLI, this means once I get to the bottom of
the screen I can't see what I'm typing.

I've tried right-clicking on the title bar, going to More Actions, then
Special Window Settings.  If I set Position to Force 0,-25, this seems to
work when I do it manually.

When the HVM boots again it works... for the first bootloader screen.
However, after that, the HVM re-sizes itself, and I'm in the same boat
again.  Now, when I go back to look at the settings, it still says Force
0,-25, and if I hit OK, it will resize.

The problem is it doesn't do this automatically upon resizing.

I could force position to 0,0 then remove the header and frame.  But then I
can't figure out how to get the header back, in order to get to the
"Special Windows Settings" menu section again... in case I want to make
further changes.  If I right-click on the HVM in the taskbar there is a
"More Actions" section, but no "Special Windows Settings".  I can only seem
to find it when right-clicking the title bar.  But I've removed the title
bar for this HVM now...!

Any ideas?

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

[qubes-users] HCL - Hewlett-Packard-500-223w

[Joe Thielen]

I have successfully created and used several CentOS 7 (1511/Minimal) HVMs.
Intel i3 so no IOMMU.  No TPM installed.  Seems to work decent so far.
16GB RAM, I can have 3 CentOS HVMs open simultaneously, the work VM (with 4
terminals and Firefox), the Fedora 23 VM open (while doing an update on the
Fedora 23 VM) and everything was still fairly responsive, very nice.  I've
had this machine loaded for about three months now.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAM9FSFy-uzCFgMOyRYW_E7aCxwRNw-XOhwJ3KynY6e0bKHCKew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Hewlett-Packard-500-223w-20160729-124134.cpio.gz
Description: GNU Zip compressed data


Qubes-HCL-Hewlett-Packard-500-223w-20160729-124134.yml
Description: application/yaml