Re: [qubes-users] UEFI boot problem
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
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)
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
Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)
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
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
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
On 6/5/17 1:10 AM, cooloutac wrote: On Friday, June 2, 2017 at 3:59:09 PM UTC-4, Stephan Marwedel wrote: 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? try legacy boot again, and and test with vt-d off maybe. only difference I can think of. disable secondary gpu and network card too. make sure gpu has enough memory. double check bios options maybe usb settings too. I tried all the options you have mentioned to no avail. I even tried to installed using the textmode installer of Qubes. While it starts to show the initial Xen boot messages, the screen suddenly goes black and a reboot is performed. This happens so quickly that I cannot see whether an error message indicating the source of the problem is displayed. The discrete Nvidia GPU cannot be disabled on this machine as there are no BIOS options for this. The machine has 32 GB of RAM with 512 MB assigned to the internal GPU. Memory it should not be a problem. Maybe the combination of discrete and internal GPU is the source of the problem. When booting Fedora 23, the Nvidia GPU is detected and the Nouveau driver is configured. I could not find an option for the Qubes installer to do the same thing. Can Qubes be installed using the Nouveau driver? -- 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/a47ec55b-41c8-b07d-083d-10245de04add%40tu-ilmenau.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Thinkpad T470p install problem
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
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
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
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
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
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
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
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
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
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
