Re: [qubes-users] UEFI boot problem

2018-10-20 Thread Stephan Marwedel

Thanks for the hint.

The commands I used to restore the entry were

efibootmgr -v -c -u -L Qubes -l /EFI/qubes/xen.efi -d /dev/sda1 -p 1

efibootmgr -o 0,1

Now I can boot Qubes using the UEFI boot manager again.


On 10/15/18 8:19 PM, 'awokd' via qubes-users wrote:



Stephan Marwedel:
I have a Thinkpad T470p which is equipped with two SSDs. Archlinux is 
installed on one drive and Qubes on the other. I use the UEFI Boot 
Menu to switch between operating systems without using multi-boot 
from a boot manager. Qubes 4.0 runs very well on this machine.


Since the T470p is now supported by the Linux Firmware Vendor Service 
I did the last BIOS update from Archlinux using fwupdmgr. Everything 
went smoothly. Unfortunately, after the update I was no longer able 
to boot Qubes because the UEFI boot configuration for the second 
drive was somehow deleted.


How can one recover the UEFI boot environment of Qubes 4.0? I tried 
using the Qubes installer but there is no shell access to run 
grub-install or efibootmgr. Can I do it from the Archlinux drive or a 
Fedora boot media?


Yes, Fedora boot media should work. Try searching this list for 
"efibootmgr"- should get the magic string for it in there somewhere.




--
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/36af74ab-9102-9aef-24c1-9548e44a0eba%40jucara.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] UEFI boot problem

2018-10-15 Thread Stephan Marwedel
I have a Thinkpad T470p which is equipped with two SSDs. Archlinux is 
installed on one drive and Qubes on the other. I use the UEFI Boot Menu 
to switch between operating systems without using multi-boot from a boot 
manager. Qubes 4.0 runs very well on this machine.


Since the T470p is now supported by the Linux Firmware Vendor Service I 
did the last BIOS update from Archlinux using fwupdmgr. Everything went 
smoothly. Unfortunately, after the update I was no longer able to boot 
Qubes because the UEFI boot configuration for the second drive was 
somehow deleted.


How can one recover the UEFI boot environment of Qubes 4.0? I tried 
using the Qubes installer but there is no shell access to run 
grub-install or efibootmgr. Can I do it from the Archlinux drive or a 
Fedora boot media?


Any hints are appreciated.

Regards,

Stephan

--
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/35e3ea4d-2f2a-fa8e-0d3d-2e6748002271%40jucara.org.
For more options, visit https://groups.google.com/d/optout.


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

2017-12-02 Thread Stephan Marwedel

Hi Joe,

thanks for the concise summary :-)

I actually forgot to mention the necessary changes to the xen.cfg that 
you correctly described.


Now we have a nice recipe to install Qubes on modern Thinkpads. This 
should become part of the official documentation.


Using this recipe will try to install Qubes on my recently acquired 
Anniversary Thinkpad 25 which is essentially a T470 with a different 
keyboard and a dedicated GPU.


Cheers,
Stephan

On 12/2/17 10:02 AM, Joe Hemmerlein wrote:

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 email

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

2017-12-01 Thread Stephan Marwedel
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.


On 11/30/17 11:07 AM, Joe Hemmerlein wrote:

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.


--
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/3fcaa73c-726e-3217-2875-6b64727712d6%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 UEFI install media

2017-07-11 Thread Stephan Marwedel
I was able to determine the cause of the problem. After having changed 
the label by editing xen.cfg as described the following needs to be done 
in addition before the media can be used on an UEFI system to install Qubes:


5. Unmount the USB media, but leave it connected to the machine. 
Assuming that the USB device is named /dev/xvdi, execute the following 
command:


dosfslabel /dev/xvdi1 BOOT

This creates a label name that the UEFI bootloader uses to identify the 
root image. Now the media can be used to install Qubes 3.2.


On 07/10/2017 06:46 PM, Stephan Marwedel wrote:

Thanks for this interesting hint. Following your detailed instructions I
was able to create a bootable media that correctly boots on my Thinkpad
in UEFI mode. However, when the kernel finished loading, an emergency
shell appears and the following messages are displayed:

Starting Dracut Emergency Shell...

Warning: /dev/root does not exist

Entering emergency mode

It seems that the kernels loads OK, but is unable to find a root
filesystem to mount. As I do not have Qubes currently installed on my
machine, I am unsure about how to specify a root filesystem. The only
valid root filesystem is the one on the installation media, but that
should be found automatically. Or is it necessary to specify it manually?

Regards,
Stephan

On 06/26/2017 08:29 AM, Dave C wrote:

I recently had some success install Qubes 3.2 on a lenovo p51, booting
UEFI.  I went through a lot of a trial and error in the process.  I'm
hoping this post can save others some time.  I've seen in other
threads some struggling to get Qubes working with UEFI firmware.

I intended to save my command history to disk so that I could post
step-by-step exactly what to do.  But I must have been in a dispvm at
the time, because now I can't find that history.  So the following is
from memory and not precise.

I tried every trick I could find related to Qubes UEFI installation,
and thinkpad troubleshooting.  What finally worked does not appear to
be documented in any of the Qubes documentation.  Qubes uses Fedora's
installer, Anaconda, and the following approach is documented on
Fedora's wiki.

1. Follow Qubes install guide up to the `dd` command.  Don't write to
usb with `dd`.
https://www.qubes-os.org/doc/installation-guide/

2. Instead, use Fedora's `livecd-iso-to-disk` tool.  You'll need the
`livecd-tools` package.  See
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Command_line_method:_Using_the_livecd-iso-to-disk_tool_.28Fedora_only.2C_non-graphical.2C_both_non-destructive_and_destructive_methods_available.29


I don't recall for certain exactly what I passed to
`livecd-iso-to-disk`.  Try this:

 sudo livecd-iso-to-disk --efi --format Qubes-R3.2-x86_64.iso
/dev/xvdi

The media as written will not quite boot, yet.  Qubes EFI boot is
configured to find a label "Qubes-R3.2-x86_64", but the media written
by the livecd tool is labelled "BOOT" (and the filesystem does not
support the longer label, so the --label option would not help).

3. Mount the usb media (/dev/xvdi in the example above)

4. Edit xen.cfg.  If I recall correctly, `/EFI/BOOT/xen.cfg`.

In this file, replace every occurrence of `LABEL=Qubes-R3.2-x86_64`
with `LABEL=BOOT`

You should now have install media that work on UEFI firmware!


After install, I recommend upgrading kernel version for recent
hardware.  I.e. with

 sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel
kernel-qubes-vm






--
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/76cb74a9-27f3-1694-a597-a09ed6ea48ca%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 UEFI install media

2017-07-10 Thread Stephan Marwedel
Thanks for this interesting hint. Following your detailed instructions I 
was able to create a bootable media that correctly boots on my Thinkpad 
in UEFI mode. However, when the kernel finished loading, an emergency 
shell appears and the following messages are displayed:


Starting Dracut Emergency Shell...

Warning: /dev/root does not exist

Entering emergency mode

It seems that the kernels loads OK, but is unable to find a root 
filesystem to mount. As I do not have Qubes currently installed on my 
machine, I am unsure about how to specify a root filesystem. The only 
valid root filesystem is the one on the installation media, but that 
should be found automatically. Or is it necessary to specify it manually?


Regards,
Stephan

On 06/26/2017 08:29 AM, Dave C wrote:

I recently had some success install Qubes 3.2 on a lenovo p51, booting UEFI.  I 
went through a lot of a trial and error in the process.  I'm hoping this post 
can save others some time.  I've seen in other threads some struggling to get 
Qubes working with UEFI firmware.

I intended to save my command history to disk so that I could post step-by-step 
exactly what to do.  But I must have been in a dispvm at the time, because now 
I can't find that history.  So the following is from memory and not precise.

I tried every trick I could find related to Qubes UEFI installation, and 
thinkpad troubleshooting.  What finally worked does not appear to be documented 
in any of the Qubes documentation.  Qubes uses Fedora's installer, Anaconda, 
and the following approach is documented on Fedora's wiki.

1. Follow Qubes install guide up to the `dd` command.  Don't write to usb with 
`dd`.
https://www.qubes-os.org/doc/installation-guide/

2. Instead, use Fedora's `livecd-iso-to-disk` tool.  You'll need the 
`livecd-tools` package.  See 
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Command_line_method:_Using_the_livecd-iso-to-disk_tool_.28Fedora_only.2C_non-graphical.2C_both_non-destructive_and_destructive_methods_available.29

I don't recall for certain exactly what I passed to `livecd-iso-to-disk`.  Try 
this:

 sudo livecd-iso-to-disk --efi --format Qubes-R3.2-x86_64.iso /dev/xvdi

The media as written will not quite boot, yet.  Qubes EFI boot is configured to find a label 
"Qubes-R3.2-x86_64", but the media written by the livecd tool is labelled 
"BOOT" (and the filesystem does not support the longer label, so the --label option would 
not help).

3. Mount the usb media (/dev/xvdi in the example above)

4. Edit xen.cfg.  If I recall correctly, `/EFI/BOOT/xen.cfg`.

In this file, replace every occurrence of `LABEL=Qubes-R3.2-x86_64` with 
`LABEL=BOOT`

You should now have install media that work on UEFI firmware!


After install, I recommend upgrading kernel version for recent hardware.  I.e. 
with

 sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel 
kernel-qubes-vm




--
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/181c454b-acb3-f535-f470-c989d08e1d6c%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Thinkpad T470p install problem

2017-06-02 Thread Stephan Marwedel



On 6/2/17 7:11 AM, cooloutac wrote:

On Thursday, June 1, 2017 at 2:31:10 PM UTC-4, Stephan Marwedel wrote:

I have trouble booting the installer. Using the standard UEFI setup of
the T470p does not work at all. Switching to legacy boot settings boots
into the GRUB menu. However, when I tried to actually boot into the
Qubes installer it immediately performs a reboot. This means that I
never get to the point to actually install Qubes on the machine.

I tried to boot the vanilla Fedora 23 live system. It boots without any
problem using both the standard UEFI setup and legacy boot. What is the
difference between Qubes and Fedora 23 that prevents Qubes from being
booted on that machine? May it be related to Secure Boot or TPM settings?

On 05/20/2017 03:28 AM, cooloutac wrote:

On Friday, May 19, 2017 at 5:23:58 PM UTC-4, Stephan Marwedel wrote:

I recently got a new Kaby Lake Thinkpad. It runs fine with Archlinux.

However, I wanted to install Qubes on it and installed a second SSD for
that purpose. Even following the hints from the official Qubes
documentation I was unable to install Qubes 3.2 from the original
installer. It seems that this machine is simply too new for Qubes 3.2.
How can I try it out with newer kernels? May alpha or beta versions of
upcoming release be worth a try??

Any hints appreciated.

what about baremetal fedora23?, if it work with that should be able to get it 
working in qubes maybe you need later kernel version from testing repo.


secure boot has to be off.
I turned secure boot off and tried various combinations of boot 
settings, like UEFI with CSM and pure legacy boot to no avail. Using 
legacy boot, the GRUB menu appears. When I select the menu item "Install 
Qubes" I see a message in text mode about the kernel being loaded. 
Shortly after, I the screen goes blank and the system performs a reboot. 
Nop error message is displayed. Something seems to be fundamentally 
wrong with either my setup or the combination of Qubes 3.2 with this 
particular machine. Does anybody else have similar experience with a 
machine of this type?


--
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/bccf35a0-b6f9-716b-5125-0bd07e6a391c%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Thinkpad T470p install problem

2017-06-01 Thread Stephan Marwedel
I have trouble booting the installer. Using the standard UEFI setup of 
the T470p does not work at all. Switching to legacy boot settings boots 
into the GRUB menu. However, when I tried to actually boot into the 
Qubes installer it immediately performs a reboot. This means that I 
never get to the point to actually install Qubes on the machine.


I tried to boot the vanilla Fedora 23 live system. It boots without any 
problem using both the standard UEFI setup and legacy boot. What is the 
difference between Qubes and Fedora 23 that prevents Qubes from being 
booted on that machine? May it be related to Secure Boot or TPM settings?


On 05/20/2017 03:28 AM, cooloutac wrote:

On Friday, May 19, 2017 at 5:23:58 PM UTC-4, Stephan Marwedel wrote:

I recently got a new Kaby Lake Thinkpad. It runs fine with Archlinux.

However, I wanted to install Qubes on it and installed a second SSD for
that purpose. Even following the hints from the official Qubes
documentation I was unable to install Qubes 3.2 from the original
installer. It seems that this machine is simply too new for Qubes 3.2.
How can I try it out with newer kernels? May alpha or beta versions of
upcoming release be worth a try??

Any hints appreciated.


what about baremetal fedora23?, if it work with that should be able to get it 
working in qubes maybe you need later kernel version from testing repo.



--
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/45aa5617-0e50-d85a-0f96-ee7fefbc1730%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Thinkpad T470p install problem

2017-05-19 Thread Stephan Marwedel

 I recently got a new Kaby Lake Thinkpad. It runs fine with Archlinux.

However, I wanted to install Qubes on it and installed a second SSD for 
that purpose. Even following the hints from the official Qubes 
documentation I was unable to install Qubes 3.2 from the original 
installer. It seems that this machine is simply too new for Qubes 3.2. 
How can I try it out with newer kernels? May alpha or beta versions of 
upcoming release be worth a try??


Any hints appreciated.

--
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/9200c074-ced0-20ff-cbb1-5aaed1c25265%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: USB Headset

2017-04-11 Thread Stephan Marwedel
Thank you for the hints. When assigning the USB controller to the 
Windows HVM not error messages are displayed anymore. BTW, it is 
difficult to figure out which USB controller to assign to the Windows HVM.


However, the USB headset does not appear as a device in Windows, so the 
appropriate driver is not installed and I cannot assign it as 
input/output device in my conferencing software. Do I need anything on 
the Windows side as well? Is it necessary to install the Qubes Windows 
Tools to have USB audio functionalty? I do not have them installed 
currently.



On 03.04.17 20:46, Grzesiek Chodzicki wrote:

W dniu poniedziałek, 3 kwietnia 2017 20:45:19 UTC+2 użytkownik Stephan Marwedel 
napisał:

I tried to configure my system like described below. I stopped the
sys-usb VM and assigned the USB controller to which the headset is
connected to the Windows HVM. When trying to start it the following
error appears:

   --> Loading the VM (type = HVM)...
Traceback (most recent call last):
File "/usr/bin/qvm-start", line 136, in 
  main()
File "/usr/bin/qvm-start", line 120, in main
  xid = vm.start(verbose=options.verbose,
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
notify_function=tray_notify_generic if options.tray else None)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line
335, in start
  return super(QubesHVm, self).start(*args, **kwargs)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line
1966, in start
  self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in
createWithFlags
  if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
failed', dom=self)
libvirt.libvirtError: internal error: Unable to reset PCI device
:00:14.0: no FLR, PM reset or bus reset available

I tried to connect the headet to a different USB controller and assign
that to the Windows HVM to no avail:

--> Loading the VM (type = HVM)...
Traceback (most recent call last):
File "/usr/bin/qvm-start", line 136, in 
  main()
File "/usr/bin/qvm-start", line 120, in main
  xid = vm.start(verbose=options.verbose,
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
notify_function=tray_notify_generic if options.tray else None)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line
335, in start
  return super(QubesHVm, self).start(*args, **kwargs)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line
1958, in start
  nd.dettach()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5249, in
dettach
  if ret == -1: raise libvirtError ('virNodeDeviceDettach() failed')
libvirt.libvirtError: Requested operation is not valid: PCI device
:00:1d.0 is in use by driver xenlight, domain AIB

What did I miss in my configration? I have VT-d and VT-x enabled (I'm on
a i7-3520M CPU).

On 04/02/2017 12:19 AM, Grzesiek Chodzicki wrote:

W dniu sobota, 1 kwietnia 2017 18:20:40 UTC+2 użytkownik Stephan Marwedel 
napisał:

Dear Qubes user community,

I want to use a USB headset (Jabra Evolve) for the purpose of using my
laptop as a replacement for a desktop phone. Is that possible with
Qubes? If so, what are the settings I need to tweak for that?

Can I use it also inside a Windows HVM to enable the use of proprietary
conferencing software from Cisco? I have tried it using a Windows VM
with VirtualBox on CentOS 7. That worked, although the audio quality is
pretty bad. Do I need special settings for my Windows HVM in order to
use the headset?

Regards,
Stephan

I did a similar thing with my sound card that requires proprietary Windows only 
drivers to operate.
First, check whether VT-d is available and enabled on your laptop with xl 
dmesg|grep VT-d
Second, identify the number of available USB controllers with sudo lspci|grep 
USB. If you have more than one controller, assign it to Windows HVM.
Within Windows HVM install USB controller driver (if it's a USB 3.0 or later) 
and then install drivers for the headset (if required).
I am able to use the soundcard in the Windows HVM with no problems so you 
should too. Remember to enable VT-d in BIOS/UEFI first.


run qvm-pci -s sys-usb pci_strictreset false then reboot the physical machine 
and try again


--
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/9d993bd1-5af5-2a36-02e8-b4b4b013cdbd%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: USB Headset

2017-04-03 Thread Stephan Marwedel
I tried to configure my system like described below. I stopped the 
sys-usb VM and assigned the USB controller to which the headset is 
connected to the Windows HVM. When trying to start it the following 
error appears:


 --> Loading the VM (type = HVM)...
Traceback (most recent call last):
  File "/usr/bin/qvm-start", line 136, in 
main()
  File "/usr/bin/qvm-start", line 120, in main
xid = vm.start(verbose=options.verbose, 
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid, 
notify_function=tray_notify_generic if options.tray else None)
  File 
"/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line 
335, in start

return super(QubesHVm, self).start(*args, **kwargs)
  File 
"/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 
1966, in start

self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in 
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags() 
failed', dom=self)
libvirt.libvirtError: internal error: Unable to reset PCI device 
:00:14.0: no FLR, PM reset or bus reset available


I tried to connect the headet to a different USB controller and assign 
that to the Windows HVM to no avail:


--> Loading the VM (type = HVM)...
Traceback (most recent call last):
  File "/usr/bin/qvm-start", line 136, in 
main()
  File "/usr/bin/qvm-start", line 120, in main
xid = vm.start(verbose=options.verbose, 
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid, 
notify_function=tray_notify_generic if options.tray else None)
  File 
"/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line 
335, in start

return super(QubesHVm, self).start(*args, **kwargs)
  File 
"/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 
1958, in start

nd.dettach()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5249, in 
dettach

if ret == -1: raise libvirtError ('virNodeDeviceDettach() failed')
libvirt.libvirtError: Requested operation is not valid: PCI device 
:00:1d.0 is in use by driver xenlight, domain AIB


What did I miss in my configration? I have VT-d and VT-x enabled (I'm on 
a i7-3520M CPU).


On 04/02/2017 12:19 AM, Grzesiek Chodzicki wrote:

W dniu sobota, 1 kwietnia 2017 18:20:40 UTC+2 użytkownik Stephan Marwedel 
napisał:

Dear Qubes user community,

I want to use a USB headset (Jabra Evolve) for the purpose of using my
laptop as a replacement for a desktop phone. Is that possible with
Qubes? If so, what are the settings I need to tweak for that?

Can I use it also inside a Windows HVM to enable the use of proprietary
conferencing software from Cisco? I have tried it using a Windows VM
with VirtualBox on CentOS 7. That worked, although the audio quality is
pretty bad. Do I need special settings for my Windows HVM in order to
use the headset?

Regards,
Stephan


I did a similar thing with my sound card that requires proprietary Windows only 
drivers to operate.
First, check whether VT-d is available and enabled on your laptop with xl 
dmesg|grep VT-d
Second, identify the number of available USB controllers with sudo lspci|grep 
USB. If you have more than one controller, assign it to Windows HVM.
Within Windows HVM install USB controller driver (if it's a USB 3.0 or later) 
and then install drivers for the headset (if required).
I am able to use the soundcard in the Windows HVM with no problems so you 
should too. Remember to enable VT-d in BIOS/UEFI first.



--
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/c6c70cb2-132a-ccd7-1801-fd7f0dbe69f8%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] USB Headset

2017-04-01 Thread Stephan Marwedel

Dear Qubes user community,

I want to use a USB headset (Jabra Evolve) for the purpose of using my 
laptop as a replacement for a desktop phone. Is that possible with 
Qubes? If so, what are the settings I need to tweak for that?


Can I use it also inside a Windows HVM to enable the use of proprietary 
conferencing software from Cisco? I have tried it using a Windows VM 
with VirtualBox on CentOS 7. That worked, although the audio quality is 
pretty bad. Do I need special settings for my Windows HVM in order to 
use the headset?


Regards,
Stephan

--
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/07677e8d-b6cd-fb94-68f3-de8eae613022%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] flexlm license manager in AppVM

2017-03-04 Thread Stephan Marwedel

On 04/03/2017 16:05, Unman wrote:

On Fri, Mar 03, 2017 at 05:30:30PM +0100, Stephan Marwedel wrote:

Hi Steve,

thank you for the information.

Your approach probably won't work in my case, as the license served by
flexlm software is tied to MAC address and hostname. If I install it in the
TemplateVM the license will be created with MAC address and hostname of that
TemplateVM. If I later start the software from the AppVM like you suggested,
it will provide a different MAC address and hostname which will invalidate
the license. So there seems to be no alternative other than to create a
standalone VM and install the commercial package in that VM.

Regards,
Stephan

On 02/28/2017 04:15 PM, Steve Coleman wrote:

On 02/25/2017 04:07 PM, Stephan Marwedel wrote:

Hi,
I use a commercial simulation environment running on Debian. I installed
the software in the Debian TemplateVM and it is running fine. However,
when starting an AppVM based on that template I cannot use the
simulation software because of the flexlm license manager failing. This
is most likely caused by the AppVM getting both a hostname and MAC
address being different from those of the corresponding TemplateVM.

What options do I have, if any, to work with such a commercial software
in an AppVM, as I don't want to work in the TemplateVM?


What I have done is install the COTS software base in the template VM. I
generally choose /opt for COTS products to keep them separate.

Then I install a service to start the license manager in the one client
VM and create a desktop file pointing to that installed application
location. Install the desktop file in the template
/usr/share/applications but assign it in the start menu of just that one
VM. Look at qvm-service for how to assign the license manager service to
just that one VM instance.

Any VM may see the software on disk, but as long as you don't actually
run from the software template or other VMs then you should be good with
the license server seeing only the one install instance.

Things can get a bit trickier if the service/software demands to be able
to write to the system area of the template provided ro file system.
Then you may need some fixups performed prior to starting the license
service.

Other options might be to install in /usr/local in the client VM itself,

t> or even in your home directory if that is possible. The service is

likely required as before unless you write a script to launch the
license manager, wait for it, and then launch the application when the
license manager is ready.

My worst case situation would be a standalone VM, but I haven't found
anything quite that stubborn just yet.

Steve


Stephen,

You can use macchanger to change your MAC address to match the flexlm
expectation. Similarly, changing the hostname is straightforward,
Depending on what the software is, you may be able to choose the
installation point: if so, you can install in a TemplateBasedVM in /home
or /usr/local, rather than in a Template.

I did have one issue where I was able to show the vendor that the
license issued with appropriate MAC/hostname/user details didn't work on
the qube. They provided me with effectively an open license, so it's
definitely worth talking to them if you have issues.

You haven't said what the software is - knowing that may help.

unman


Hi Unman,

I intend to use the simulation software package MLDesigner 
(http://www.mldesigner.com) which is supported on RHEL/CentOS and 
Debian. I already tried macchanger and that works. As I did not install 
the software in /usr/local, but in /opt, it didn't help. I will try to 
reinstall in in the AppVM in /usr/local and then use macchanger to 
adjust MAC address and hostname.


Regards,

Stephan

--
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/b8e2e531-7c63-ded0-d945-3ef2d101e58d%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] flexlm license manager in AppVM

2017-03-03 Thread Stephan Marwedel

Hi Steve,

thank you for the information.

Your approach probably won't work in my case, as the license served by 
flexlm software is tied to MAC address and hostname. If I install it in 
the TemplateVM the license will be created with MAC address and hostname 
of that TemplateVM. If I later start the software from the AppVM like 
you suggested, it will provide a different MAC address and hostname 
which will invalidate the license. So there seems to be no alternative 
other than to create a standalone VM and install the commercial package 
in that VM.


Regards,
Stephan

On 02/28/2017 04:15 PM, Steve Coleman wrote:

On 02/25/2017 04:07 PM, Stephan Marwedel wrote:

Hi,
I use a commercial simulation environment running on Debian. I installed
the software in the Debian TemplateVM and it is running fine. However,
when starting an AppVM based on that template I cannot use the
simulation software because of the flexlm license manager failing. This
is most likely caused by the AppVM getting both a hostname and MAC
address being different from those of the corresponding TemplateVM.

What options do I have, if any, to work with such a commercial software
in an AppVM, as I don't want to work in the TemplateVM?



What I have done is install the COTS software base in the template VM. I
generally choose /opt for COTS products to keep them separate.

Then I install a service to start the license manager in the one client
VM and create a desktop file pointing to that installed application
location. Install the desktop file in the template
/usr/share/applications but assign it in the start menu of just that one
VM. Look at qvm-service for how to assign the license manager service to
just that one VM instance.

Any VM may see the software on disk, but as long as you don't actually
run from the software template or other VMs then you should be good with
the license server seeing only the one install instance.

Things can get a bit trickier if the service/software demands to be able
to write to the system area of the template provided ro file system.
Then you may need some fixups performed prior to starting the license
service.

Other options might be to install in /usr/local in the client VM itself,

t> or even in your home directory if that is possible. The service is

likely required as before unless you write a script to launch the
license manager, wait for it, and then launch the application when the
license manager is ready.

My worst case situation would be a standalone VM, but I haven't found
anything quite that stubborn just yet.

Steve



--
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/fefe2e6e-9f24-f943-8ec0-4137586229ea%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] flexlm license manager in AppVM

2017-02-25 Thread Stephan Marwedel

Hi,
I use a commercial simulation environment running on Debian. I installed 
the software in the Debian TemplateVM and it is running fine. However, 
when starting an AppVM based on that template I cannot use the 
simulation software because of the flexlm license manager failing. This 
is most likely caused by the AppVM getting both a hostname and MAC 
address being different from those of the corresponding TemplateVM.


What options do I have, if any, to work with such a commercial software 
in an AppVM, as I don't want to work in the TemplateVM?


--
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/d7bb524f-5520-7983-f86a-45274c873e3b%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - HP EliteBook 2570p

2017-02-21 Thread Stephan Marwedel
I use Qubes successfully for my daily work and it works perfectly for me 
on this machine. Thanks to the Qubes Team for making it possible, 
especially providing i3 support in dom0. Although I cannot tweak the i3 
configuration, as Qubes simply ignores the changes I made to the i3 key 
bindings. But I can live with the standard configuration for the time being.


The only trouble I sometimes have is to correctly suspend and resume the 
machine. This only works when I do not have an HVM Qube running. As soon 
as I start my Windows 7 HVM Qube and try to suspend the machine, it 
completely stalls and can only be recovered by a hardware reset. 
According to the documentation, it should work, but I didn't yet manage 
to get around this issue. Maybe it is a configuration issue with this 
particular machine?


One question concerning hardware support: I must use a smartcard for 
authentication at work. However, currently Qubes does not support the 
built-in smartcard reader. Thus, it cannot be passed to a Qube. Using a 
USB reader instead doesn't work either as a USB device cannot be passed 
to the Windows 7 HVM. So I need to use a different machine for 
authentication. Will there be any solution in the future?


In summary, Qubes is a reliable and secure solution for the mobile 
desktop covering 99% of my daily tasks.


--
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/f8790d87-5f93-8390-1553-80320200d4a5%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Hewlett_Packard-HP_EliteBook_2570p-20170221-185259.yml
Description: application/yaml