Allow Ctrl-Alt-Del in Windows VM in Qubes 3.2

Allow Control-Alt-Delete in windows VM:

Passing Ctrl+Alt+Delete to the Windows HVM:
Qubes menu → System Tools → Keyboard → “Application Shortcuts” tab → Select the line “xflock4” – “Ctrl+Alt+Delete” → Click the “Remove” button

Select Qubes menu → Qubes VM Manager → Right click on Windows VM → VM Settings → On the “Basic” tab, tick the “Run in debug mode” checkbox → Click the “OK” button → Start Windows VM

When starting windows, 2 windows are present – press ctrl-alt-del in the 1st one and the other (with the desktop) responds to it. log in with your local account, start VPN, switch user, log in with your domain account.

Add USB network adapter to a specific Qube to configure router in Qubes 3.2

Pre-requisites: sys-usb VM

If your router needs a locally attached cable in port 1 or something similar, and you only have a USB RJ45 adapter, then you need to have a net-vm with the adaptor attached and a VM who uses this net-VM as network:

[Max@dom0 ~]$ qvm-usb 
sys-usb:3-8 5986:0535 Generic_Lenovo_EasyCamera_200901010001
sys-usb:3-2 0b95:7720 ASIX_Elec._Corp._AX88x72A_10FD4D
sys-usb:3-1 046d:c52f Logitech_USB_Receiver
sys-usb:3-7 04f3:016f ELAN_Touchscreen
sys-usb:3-6 2047:0855 Invensense_Lenovo_Yoga_31F3806F24001100
sys-usb:3-4 8087:07dc 8087_07dc
[Max@dom0 ~]$ 

The above command shows the USB network adapter (in Bold). If you are uncertain, unplug device and try again…. the difference is  key :))

Attach the device to the net-VM which will use it with the following command:

[Max@dom0 ~]$ qvm-usb -a lokal-belkin sys-usb:3-2
[Max@dom0 ~]$ 

The above 3rd listing is the network card. Also in dom0, you have 2 network interfaces up in the right corner:

The above will setup as default and try to get ipv4/ipv6 dhcp.

The above shows successful address with dhcp.

The network is now working, and the x is gone. Happy times.

Qubes OS 3.2 on Purism Librem13v2

 

So, my Purism Librem13v2 finally arrived. Ordered in November and delivered in February, 2 months later than first promised(mid december), due to high demand and TPM. Missing the USB stick with Qubes OS, but I was promised they will send it in a few weeks time.

Long anticipated, I looked forward to run Qubes 4.0rc4, but the installed Coreboot 4.6 version does not support Qubes OS version 4 yet, and we still await the official 4.7 release, so I was forced(and recommended) to run Qubes 3.2, with the issues it presented.

I now run Qubes 3.2, restored my VMs from my older Lenovo Yoga 2 Pro, and most stuff seems to work, except my Kali VM. A reinstall did not help :(, so I might jump to forums, if the issue persists.

Workaround:

After installing qubes 3.2, the system hangs during boot up. The solution is somewhat provided here: https://forums.puri.sm/t/librem-13v2-qubes-stuck-at-booting-from-hard-disk-after-install/1072/10

Boot Qubes installer into recovery:

Select Troubleshooting:

Select Rescue a Qubes system:

After booting to anaconda installer choose

1) Continue

(and enter your Qubes partition password if you chose to encrypt it during install)

In the prompt:

chroot /mnt/sysimage

lsblk (To identify the whereabouts of your Qubes installation.)

GRUB_CMDLINE_XEN_DEFAULT="console=none dom0_mem=min:1024M dom0_mem=max:1024M"  (Fixed size, following recommendations: https://wiki.xen.org/wiki/Xen_Project_Best_Practices but looking at another qubes installation it says 1024/4096 as min/max. So feel free to pick)

grub2-install /dev/nvme0n (or where your Qubes installation lies.)

grub2-mkconfig

I managed to do without the GRUB_XEN thingy, but don’t know if there is a hidden effect of it somewhere.

exit (leave the chroot environment)

reboot

Reboot and voila. The system starts, but has a cluttered text interface for the disk encryption password, instead of the graphical part.

Here the normal graphical question:

I can live with that, but not ideal. Hopefully the coreboot 4.7 and Qubes 4 will work better together.

Initial setup after reboot:

Qubes needs to finish up the installation, asking some relevant questions about sys-usb, whonix, tor, etc.

First an opening window of no interest, but a button to click….

Then we have to select if updates should go through tor and if we need usb, and I recommend the usage of a separate qubes for USB. sys-usb might say experimental, but updates seem to fix what issues there has been.

The login window comes up and the user created during install can be used to login.

Notice the lack of wifi support for the machine.

This is purely a one time only thing and will come up after reboot:

You will be asked how you wan’t, if you wan’t, to use tor. That should be a no brainer, if you wan’t to run qubes, but I will recommend some machines configured without tor, since cloudflare and others just hate tor and blocks you terribly with captchas, etc.

Then you should update all the machines, so your sys-usb won’t hang during startup, etc.

commands like :

sudo qubes-dom0-update (updates the current dom0 qube)

sudo qubes-dom0-update qubes-template-fedora-26 (installs the newer fedora 26 template, to replace fedora-23 as default in VM Manager and the rest of the pre-configured machines is a first.

Then you can select “Update VM” on the rest of the templates and begin to either restore images from a previous qubes installation or configure email clients or other settings on your new machines.

I have problems creating kali images on the Purism Librem13v2, that works fine on other qubes-machines running Lenovo and HP, so I guess that there is something about Purism Librem13v2 and Qubes that is just not fun at all.

Hopefully CoreBoot 4.7 and Qubes 4.x will run better.