Qubes 4.0 on Tuxedo BU1406

[Aaron Dough]

These are my experiences with Qubes 4.0rc1 on a Tuxedo BU1406-notebook with an i5-7200U-CPU and a NVMe-SSD. Some issues could be resolved (mostly using this mailing list, thanks to anyone contributing!), others remain:

Resolved issues:

1. Unable to install Qubes in UEFI-Mode. Selecting "Install Qubes R4.0-rc1" just loops back to the same menu.
   
   Solution: creating an MBR and installing in Bios-Mode worked fine
   
2. After the installation, the notebook kept rebooting. I got into the GRUB Boot Menu, but after selecting Qubes, it briefly showed the "Loading Xen..., Loading Linux... Loading ramdisk..."-message, and then rebootet the PC. (Much like this guy describes. Maybe someone link him here? I can't respond to him, since I just subscribed...)
   
   Solution: editing the menu-item and removing "iommu=no-igfx" in the multiboot-line allowed my to start the system and update dom0. This update then generated a new grub configuration file, which resolved the issue for good. I did this three times now, the first two times it worked at once, the last time I had to restart the update until I saw the "Generating grub configuration file ..."-message (maybe the dom0-update-server could not be reached at first?)
   
3. Sys-net could not be started. At first boot it showed me the error-message "['/usr/bin/qvm-start', 'sys-firewall'] failed: Start failed: internal error: Unable to reset PCI device 0000:03:00.1: internal error: Active 000:03:00.0 devices on bus with 000:03:00.1, not doing bus reset". This was really about Sys-net, to which 03:00.1 was attached.
   
   Workaround: Removing the 03:00.1 ethernet controller in the sys-net vm settings worked, which means however that I don't have Ethernet. I can live with that for now. Blocklisting the card-reader as suggested here was not tried yet.
   

Unresolved issues:

1. Touch-pad does not register taps as clicks. The physical buttons work however, as does multitouch scrolling, so this is not critical. It is strange though, as Fedora 25 is the base of dom0, and Fedora 25 itself has no problems with the touchpad.
   
2. Standby is not working properly. This is the last dealbreaking issue remaining.
   
1. With Sys-usb enabled, can't unlock after Standby. I can go into standby, but waking the notebook results in a blank screen. The led-backlight comes up though.
   
   Dirty Workaround: It looked like the keyboard and touch-pad did not reconnect. I reinstalled with sys-usb disabled, which allowed me to unlock, but lead to 2.2:
   
2. With Sys-usb disabled, Standby results in strange behavior when sys-net is running. The first "Suspend to RAM" after starting sys-net (or booting the machine) works perfectly fine, but kills my networking-capabilities ("NetworkManager is not running" when I click the red networking-icon). After that, Standby will lock the screen and nothing else happens at first. I can unlock the screen and go back to the Desktop. Then, after a minute or so the computer will go into standby. Waking will go directly to the Desktop, without the lock-screen. Restarting sys-net and sys-firewall will also reset this issue. Some rare times, the first standby will not result in the described problem, so this is only 90-95% reproducible. It maybe unrelated, but it seems sys-net is always at the minimum of 400MB, and sys-firewall at the maximum of 4000MB of used memory.
   What did not work: Removing the WiFi-controller. However, without any attached networking-devices the NetworkManager keeps running after the first Standby.
   

If you have any idea about one of the remaining issues, please let me know. Since the HCL-tool is missing in rc1, I will provide the report (and an update) once rc2 comes out.

--Aaron

[Yethal]

3. Try running sys-usb with pci_strictreset set to false. If that doesn't help attach both 03:00.0 and 03:00.1 devices to sys-usb and try again.

[Aaron Dough]

-------- Original Message --------

Subject: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406

Local Time: September 13, 2017 11:53 PM

UTC Time: September 13, 2017 9:53 PM

From: grzegorz....@gmail.com

To: qubes-users <qubes...@googlegroups.com>

W dniu środa, 13 września 2017 12:39:13 UTC+2 użytkownik Aaron Dough napisał:

> These are my experiences with Qubes 4.0rc1 on a Tuxedo BU1406-notebook with an i5-7200U-CPU and a NVMe-SSD. Some issues could be resolved (mostly using this mailing list, thanks to anyone contributing!), others remain:

>

>

> 1. Resolved issues:

>

> 1.1 Unable to install Qubes in UEFI-Mode. Selecting "Install Qubes R4.0-rc1" just loops back to the same menu.

> Solution: creating an MBR and installing in Bios-Mode worked fine

>

> 1.2 After the installation, the notebook kept rebooting. I got into the GRUB Boot Menu, but after selecting Qubes, it briefly showed the "Loading Xen..., Loading Linux... Loading ramdisk..."-message, and then rebootet the PC. (Much like this guy describes. Maybe someone link him here? I can"t respond to him, since I just subscribed...)

> Solution: editing the menu-item and removing "iommu=no-igfx" in the multiboot-line allowed my to start the system and update dom0. This update then generated a new grub configuration file, which resolved the issue for good. I did this three times now, the first two times it worked at once, the last time I had to restart the update until I saw the "Generating grub configuration file ..."-message (maybe the dom0-update-server could not be reached at first?)

>

> 1.3 Sys-net could not be started. At first boot it showed me the error-message "["/usr/bin/qvm-start", "sys-firewall"] failed: Start failed: internal error: Unable to reset PCI device 0000:03:00.1: internal error: Active 000:03:00.0 devices on bus with 000:03:00.1, not doing bus reset". This was really about Sys-net, to which 03:00.1 was attached.

> Workaround: Removing the 03:00.1 ethernet controller in the sys-net vm settings worked, which means however that I don"t have Ethernet. I can live with that for now. Blocklisting the card-reader as suggested here was not tried yet.

>

> 2. Unresolved issues:

>

> 2.1 Touch-pad does not register taps as clicks. The physical buttons work however, as does multitouch scrolling, so this is not critical. It is strange though, as Fedora 25 is the base of dom0, and Fedora 25 itself has no problems with the touchpad.

>

> 2.2 Standby is not working properly. This is the last dealbreaking issue remaining.

>

> 2.2.1 With Sys-usb enabled, can"t unlock after Standby. I can go into standby, but waking the notebook results in a blank screen. The led-backlight comes up though.

> Dirty Workaround: It looked like the keyboard and touch-pad did not reconnect. I reinstalled with sys-usb disabled, which allowed me to unlock, but lead to 2.2:

>

> 2.2.2 With Sys-usb disabled, Standby results in strange behavior when sys-net is running. The first "Suspend to RAM" after starting sys-net (or booting the machine) works perfectly fine, but kills my networking-capabilities ("NetworkManager is not running" when I click the red networking-icon). After that, Standby will lock the screen and nothing else happens at first. I can unlock the screen and go back to the Desktop. Then, after a minute or so the computer will go into standby. Waking will go directly to the Desktop, without the lock-screen. Restarting sys-net and sys-firewall will also reset this issue. Some rare times, the first standby will not result in the described problem, so this is only 90-95% reproducible. It maybe unrelated, but it seems sys-net is always at the minimum of 400MB, and sys-firewall at the maximum of 4000MB of used memory.

> What did not work: Removing the WiFi-controller. However, without any attached networking-devices the NetworkManager keeps running after the first Standby.

>

> If you have any idea about one of the remaining issues, please let me know. Since the HCL-tool is missing in rc1, I will provide the report (and an update) once rc2 comes out.

>

> --Aaron

3. Try running sys-usb with pci_strictreset set to false. If that doesn"t help attach both 03:00.0 and 03:00.1 devices to sys-usb and try again.

Thanks Yethal, but there doesn't seem to bee a pci_strictreset-property in Qubes 4.0. Or am I mistaken somehow?

Another error that happened before, but only a few times now more often, so I have to include it in the list of unresolved issues:

2.3 Most Qubes-commands don't work sometimes. Sometimes (more often than not recently) Qubes boots into xfce, but the Qubes-specific trayicons don't come up, vms don't start, selecting a Qubes-specific item in the menu doesn't do anything, and when executing a Qubes-command in the command line an error is displayed, that always looks something like this (example is qvm-ls):

"File "/usr/bin/qvm-ls", line 9, in <module>

load_entry_point('quhesadmin==4.0.4', 'console_scripts', 'qvm-ls')()

...

File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 460, in qubesd_call

client_socket.connect(qubesadmin.config.QUBESD_SOCKET)

FileNotFoundError: [Errno 2] No such file or directory"

This last part is always the same, so probably there's the problem. Again, this doesn't happen everytime, and because of that I think this might resolve itself in a later, more stable version of Qubes 4.

[Aaron Dough]

As embarrassing as this is, 2.1 (Touchpad issues) were just an option in the preferences, and is thus resolved...

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Sep 14, 2017 at 05:13:27AM -0400, 'Aaron Dough' via qubes-users wrote:
> -------- Original Message --------
>
> > Subject: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
> > Local Time: September 13, 2017 11:53 PM
> > UTC Time: September 13, 2017 9:53 PM
> > From: grzegorz....@gmail.com
> > To: qubes-users <qubes...@googlegroups.com>
> >
> > W dniu środa, 13 września 2017 12:39:13 UTC+2 użytkownik Aaron Dough napisał:
> >> These are my experiences with Qubes 4.0rc1 on a Tuxedo BU1406-notebook with an i5-7200U-CPU and a NVMe-SSD. Some issues could be resolved (mostly using this mailing list, thanks to anyone contributing!), others remain:
> >>
> >>
> >> 1. Resolved issues:
> >>
> >> 1.1 Unable to install Qubes in UEFI-Mode. Selecting "Install Qubes R4.0-rc1" just loops back to the same menu.
> >> Solution: creating an MBR and installing in Bios-Mode worked fine
> >>
> >> 1.2 After the installation, the notebook kept rebooting. I got into the GRUB Boot Menu, but after selecting Qubes, it briefly showed the "Loading Xen..., Loading Linux... Loading ramdisk..."-message, and then rebootet the PC. (Much like this guy describes. Maybe someone link him here? I can"t respond to him, since I just subscribed...)
> >> Solution: editing the menu-item and removing "iommu=no-igfx" in the multiboot-line allowed my to start the system and update dom0. This update then generated a new grub configuration file, which resolved the issue for good. I did this three times now, the first two times it worked at once, the last time I had to restart the update until I saw the "Generating grub configuration file ..."-message (maybe the dom0-update-server could not be reached at first?)

In 4.0rc2+ iommu=no-igfx will be removed by default.

(...)

> >> 2.2 Standby is not working properly. This is the last dealbreaking issue remaining.
> >>
> >> 2.2.1 With Sys-usb enabled, can"t unlock after Standby. I can go into standby, but waking the notebook results in a blank screen. The led-backlight comes up though.
> >> Dirty Workaround: It looked like the keyboard and touch-pad did not reconnect. I reinstalled with sys-usb disabled, which allowed me to unlock, but lead to 2.2:
> >>
> >> 2.2.2 With Sys-usb disabled, Standby results in strange behavior when sys-net is running. The first "Suspend to RAM" after starting sys-net (or booting the machine) works perfectly fine, but kills my networking-capabilities ("NetworkManager is not running" when I click the red networking-icon). After that, Standby will lock the screen and nothing else happens at first. I can unlock the screen and go back to the Desktop. Then, after a minute or so the computer will go into standby. Waking will go directly to the Desktop, without the lock-screen. Restarting sys-net and sys-firewall will also reset this issue. Some rare times, the first standby will not result in the described problem, so this is only 90-95% reproducible. It maybe unrelated, but it seems sys-net is always at the minimum of 400MB, and sys-firewall at the maximum of 4000MB of used memory.
> >> What did not work: Removing the WiFi-controller. However, without any attached networking-devices the NetworkManager keeps running after the first Standby.

I also have sys-usb related problems (it's frozen after suspend,
otherwise system works). Not resolved yet...

> >> If you have any idea about one of the remaining issues, please let me know. Since the HCL-tool is missing in rc1, I will provide the report (and an update) once rc2 comes out.
> >>
> >> --Aaron
> >
> > 3. Try running sys-usb with pci_strictreset set to false. If that doesn"t help attach both 03:00.0 and 03:00.1 devices to sys-usb and try again.
>
> Thanks Yethal, but there doesn't seem to bee a pci_strictreset-property in Qubes 4.0. Or am I mistaken somehow?

It is moved to per-device option. See qvm-pci output. You can't change
the options on the fly, you need to detach+attach the device.
Anyway, this alone will probably not help, attaching both 03:00.0 and
03:00.1 should.

> Another error that happened before, but only a few times now more often, so I have to include it in the list of unresolved issues:
>
> 2.3 Most Qubes-commands don't work sometimes. Sometimes (more often than not recently) Qubes boots into xfce, but the Qubes-specific trayicons don't come up, vms don't start, selecting a Qubes-specific item in the menu doesn't do anything, and when executing a Qubes-command in the command line an error is displayed, that always looks something like this (example is qvm-ls):
> "File "/usr/bin/qvm-ls", line 9, in <module>
> load_entry_point('quhesadmin==4.0.4', 'console_scripts', 'qvm-ls')()
> ...
> File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 460, in qubesd_call
> client_socket.connect(qubesadmin.config.QUBESD_SOCKET)
> FileNotFoundError: [Errno 2] No such file or directory"

This means qubesd service crashed. See journalctl in dom0...

> This last part is always the same, so probably there's the problem. Again, this doesn't happen everytime, and because of that I think this might resolve itself in a later, more stable version of Qubes 4.
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZvE4rAAoJENuP0xzK19csuxYIAJhPAElAH/3bvEo//pzwcBg0
3ZhxtD1BpDm+Sg2ixV6d1Z2CedG3nBO/eq40D0XXbcEwhOs2V/Fqqpu6apHq1rq0
2/w/pG6mn9BeWIdJQXRm/OAj18LYFQ6KJ0IKmrTlsNDkCnSj2wfjORiZNTotMvTT
uQFRwCx7zo7X6vgq6Z7jsXtUzUczAu29mKg9/FjCloefWtOsbWhq+qCgapJOAUtT
R2ALkDbe8CDRPyjVq5mMhmhW+HGYw1620qx/hWJ4AuW5wU0d7GIxjNG0jsFm4H4F
RXgsxncgZEHBAd5DZYVQRzP/A8HpqfoLG9YosLwSvmPabBl1r4RE6tb+cCK2Zag=
=mknD
-----END PGP SIGNATURE-----

[Aaron Dough]

Hello again, my long overdue update on the matter, now with RC4:

1. Installing Qubes 4.0 RC4 in UEFI-Mode works fine now :)
2. No manual adjustment of GRUB needed any more :)
3. Standby seems to work almost perfectly now. It does need about a minute to kick in, and if I unlock my screen in this time frame I'm able to resume from standby without any lockscreen, but I can live with that :)
4. qubesd service doesn't crash anymore :)

New issue:

During installation, before the first reboot and basic configuration, the system stops with
[terminated]
[ 1513.579240] reboot: Restarting system
and doesn't react any more. Cold shutdown and reboot resumes the installation-process.

Remaining issues:

Sys-net still causes trouble. The error-message ("Unable to reset PCI device 000:03:00.1") still occurs during installation, and later keeps sys-net from starting. Setting pci_strictreset to false mitigates the problem, but doesn't make sys-net stable. Particularly the behavior after standby is kind of strange, for example it tells me a connection is gone several times, although there never was a connection. Also it will not halt properly with qvm-shutdown, a qvm-kill is needed. One time a new wired connection appeared under a new wired controller, but I've not seen it since.

Attaching 3:00.0 to sys-net also did not help, instead sys-net would not start up any more ("Cannot execute qrexec-daemon").

So I'm back to disabling ethernet altogether by not attaching 3:00.1 to sys-net. This is not a problem at the moment.

I'll upload the HCL-report in a new post and will try to use RC4 over the next weeks.

Best regards,

Aaron

[Aaron Dough]

Oh, I almost forgot: I was supposed to attach 3:00.0 and 3:00.1 to sys-usb, and I did that by doing a complete reinstall using the corresponding options. The results were still the same. Unless of course I made some mistake in the process. Is it correct that by doing so I'll end up with only one sys-net qube which is also my usb-qube?

[awokd]

On Thu, February 22, 2018 12:52 pm, 'Aaron Dough' via qubes-users wrote:

> Attaching 3:00.0 to sys-net also did not help, instead sys-net would not
> start up any more ("Cannot execute qrexec-daemon").
>
> So I'm back to disabling ethernet altogether by not attaching 3:00.1 to
> sys-net. This is not a problem at the moment.

What device is 03:00.0? If you do an lspci, is there anything else on bus
3 besides 03:00.1?

I'm wondering if sys-net and suspending will be more stable if you attach
everything on bus 3 to sys-net while leaving strict_reset to default to
required.

[Aaron Dough]

>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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b2d14fc757f2f50ed643212a2053c8fd.squirrel%40tt3j2x4k5ycaa5zt.onion.
> For more options, visit https://groups.google.com/d/optout.
>

lspci only gives me 03:00.0 and .1, with 03:00.0 being "Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01)"

[awokd]

On Thu, February 22, 2018 1:18 pm, 'Aaron Dough' via qubes-users wrote:
> On February 22, 2018 1:06 PM, 'awokd' via qubes-users
> <qubes...@googlegroups.com> wrote:

>> I'm wondering if sys-net and suspending will be more stable if you
>> attach everything on bus 3 to sys-net while leaving strict_reset to
>> default to required.

Have you tried this already?

> lspci only gives me 03:00.0 and .1, with 03:00.0 being "Unassigned class
> [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader
> (rev 01)"

Someone else recently had a similar problem with those Realteks too
(https://mail-archive.com/qubes...@googlegroups.com/msg18953.html). I
don't know what they were thinking when they designed that setup or why
any manufacturers would use it...

[Aaron Dough]

-------- Original Message --------

On February 22, 2018 1:28 PM, 'awokd' via qubes-users <qubes...@googlegroups.com> wrote:

>On Thu, February 22, 2018 1:18 pm, 'Aaron Dough' via qubes-users wrote:
>>On February 22, 2018 1:06 PM, 'awokd' via qubes-users
>>qubes...@googlegroups.com wrote:
>>
>>
>>>I'm wondering if sys-net and suspending will be more stable if you
>>> attach everything on bus 3 to sys-net while leaving strict_reset to
>>> default to required.
>>>
>>
> Have you tried this already?

Yes, when I do this sys-net won't even start up ("Cannot execute qrexec-daemon!")

>
>>lspci only gives me 03:00.0 and .1, with 03:00.0 being "Unassigned class
>> [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader
>> (rev 01)"
>>
>
> Someone else recently had a similar problem with those Realteks too
> (https://mail-archive.com/qubes...@googlegroups.com/msg18953.html). I
> don't know what they were thinking when they designed that setup or why
> any manufacturers would use it...

Good to know. Since Tuxedo especially advertises it's native Linux-support, I think I'll ask their support directly regarding this issue. It may be far fetched, but if this is really solvable with updated firmware, it's worth a shot :-)

[awokd]

On Thu, February 22, 2018 1:49 pm, Aaron Dough wrote:

> Good to know. Since Tuxedo especially advertises it's native
> Linux-support, I think I'll ask their support directly regarding this
> issue. It may be far fetched, but if this is really solvable with updated
> firmware, it's worth a shot :-)

His case was a little different because he wanted to use them across
separate VMs. In theory that can be done if you set both devices to not
require strict reset. In your case, maybe try to assign them both to
sys-net without strict reset (but you might have already tried that too).

[Aaron Dough]

Yes, I've tried that too. Although I noticed that the Qubes Manager currently doesn't seem to set no-strict-reset property properly, so I tried again via command line.
As soon as both devices (3:00.1 and 3:00.0) are attached, sys-net will not start, no matter the no-strict-reset flag(s).
If only .1 (Ethernet) is attached, it will result in unstable behavior. With no-strict-reset=true sys-net will freeze after a standby (no reaction when I click the networking-icon, no qvm-shutdown possible, only qvm-kill).

[Aaron Dough]

Sorry for the avalanche of messages, I just had sys-net freeze on me even though the Ethernet controller was detached. As it turns out, the Wireless controller needs no-strict-reset=true too. Now it seems much more stable.

However, still
- 3:00.0 can not be attached, or sys-net won't start
- whenever Ethernet (3:00.1) is attached, no matter the strict-reset flag, standby will mess with sys-net: The network-icon will show the "trying to connect"-animation, and it thinks it's connected to "Wired connection 1", although there is no cable attached. That's the bug I couldn't quite remember before, and it is now reproducable.

I also wrote Tuxedo-computers, maybe they will be able to help.

Big thanks to awokd for all the helpful replies :-)

Kind regards,
Aaron

[awokd]

On Thu, February 22, 2018 6:19 pm, 'Aaron Dough' via qubes-users wrote:

> Sorry for the avalanche of messages, I just had sys-net freeze on me even
> though the Ethernet controller was detached. As it turns out, the
> Wireless controller needs no-strict-reset=true too. Now it seems much
> more stable.

No problem, it's also helpful for others who might encounter the same
problem as you some day and search this mailing list.

> However, still
> - 3:00.0 can not be attached, or sys-net won't start
> - whenever Ethernet (3:00.1) is attached, no matter the strict-reset flag,
> standby will mess with sys-net: The network-icon will show the "trying to
> connect"-animation, and it thinks it's connected to "Wired connection 1",
> although there is no cable attached. That's the bug I couldn't quite
> remember before, and it is now reproducable.

That might be something else. Check out this article and try looking for
your Ethernet driver instead of the wireless one.
https://www.qubes-os.org/doc/wireless-troubleshooting/

> I also wrote Tuxedo-computers, maybe they will be able to help.

Please let us know what you hear back! Unfortunately, they might not be
able to do anything about it if it's inside the Realtek hardware. At least
if they are aware it's causing people problems, maybe they'll look for a
better chip next time.

> Big thanks to awokd for all the helpful replies :-)

Any time.

[Aaron Dough]

A quick update:

Qubes 4.0 seems to run _much_ more stable than the last RCs. Even the last RC I tried froze sometimes in the end, but up to now in 4.0 this didn't happen again. Strict reset is only needed for the ethernet controller (03:00:1). Suspend works like a charm, as does wifi, ethernet and sound. Cam wasn't tested yet. Please update the HCL to state that ethernet works :)

Unfortunately I never heard back from Tuxedo after my last mail. My impression after talking to them on the phone is that their claim of great linux-compatibility is limited to a handful of distros they offer an optimization-script for, which is basically Ubuntu and a few Ubuntu-based ones. All other distros (including fedora) are not officially supported, even if they seem to run well. From my POV this is not honestly communicated on their website.

So I don't think the BU1406 was too bad of a choice for Qubes, as there are not too many notebooks out there which offer this kind of customization: You can reach (and upgrade) most important components like the two hard drives and both ram slots, you can clean the cooling fan, buy a second battery as it is external etc. I am disappointed however of Tuxedos understanding of "linux", with which they really mean "ubuntu", and if you are looking for the best compatibility with Qubes, it's probably not the best choice out there.

Thanks again for all the help,
Aaron