[qubes-users] Re: HCL - Tuxedo BU1406
‐‐‐ Original Message ‐‐‐ On February 22, 2018 2:13 PM, Aaron Dough wrote: > Most things seem to work fine, but Ethernet is still problematic at this > moment with Qubes 4.0 RC4, but I'll refrain from posting this here until 4.0 > becomes stable and I've had more time for testing. (If you are interested > have a look at my other post "Qubes 4.0 on Tuxedo BU1406". In essence, for > now I don't have the Ethernet-controller attached.) Qubes 4.0 seems to run well, Ethernet, WiFi, Sound and standby work as expected. Webcam wasn't tested yet, but recognized by sys-usb, so it should work too. I installed it in BIOS-mode, and had to enable IOMMU (in the bios: Advanced -> Advanced Chipset Control -> VT-d). During the configuration phase there is a message saying "Unable to reset PCI device 000:03:00.1". Click OK and ignore it for the moment, then after the initial boot enable strict reset for the ethernet controller (03:00.1) in the Devices-settings of sys-net. -- 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/v8FmfbTNEL82iIx2l0N7BvSDvJM_CHqEiaKdc8fIG4IB0Q5MopBngbpH3Zst4piA6gAV4UkH09jbOkyJJicUqZ1B4DXC6n9D313ByLm-QDo%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
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 -- 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/cwxRyr9jPT4KP5tbQOd8VyT-Rou4-csJ8iXzwoss-s4Pz_A6ChLvJXZOcVyYpBgKlZbMXc8VFWJWDd4DRWBLBxz442SJds7aEsRSyPnW7zU%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
On February 22, 2018 5:01 PM, Aaron Dough wrote: >On February 22, 2018 1:57 PM, 'awokd' via qubes-users >qubes-users@googlegroups.com wrote: > >>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). >> > 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). > 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 -- 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/imNpaQvCnVnjD6igDetitlT_5m-C-Dmlm8i6gYBAN6C5Hk50u7zgSv2HkvuZkG5WuTpXQ5G5E0a8Bpgacapk8bEt90zpSHRp2a3Dj5noLUc%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
On February 22, 2018 1:57 PM, 'awokd' via qubes-users wrote: >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). > 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). -- 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/JJqOfvco5VlYyzgmAcLUxXo3TGhv_O2p3dKsLKGSgzt6vF2UmoGNRyYTj7qNd7bYe7iEzqOWI6ESs5FwoNw1bJrVZtQox2oa5s4I20CdF9Y%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
Original Message
On February 22, 2018 1:28 PM, 'awokd' via qubes-users
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-users@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-users@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 :-)
--
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/SP-uwJKRmI6yCTfeY8eqVypF5P4j79FCSPS89NcQed-HgletXZkokvuE55pk_rZcJRjl4jdDyHoA5d9FqNBbwuDjlxeQ2s2zN553W90ndGY%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
On February 22, 2018 1:06 PM, 'awokd' via qubes-users
wrote:
>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.
>
>
>
>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/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)"
--
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/X8KnEw9dqniXnVDKyGRd9Lr8BekeZTyFX9bgqqvmDMEjuPtk5qcoa6eKpH6G-EKr6LdGeDu8SSXaXcUgALbOZXZ6V4gNAB8Lv10nioreAQk%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Tuxedo BU1406
Most things seem to work fine, but Ethernet is still problematic at this moment with Qubes 4.0 RC4, but I'll refrain from posting this here until 4.0 becomes stable and I've had more time for testing. (If you are interested have a look at my other post "Qubes 4.0 on Tuxedo BU1406". In essence, for now I don't have the Ethernet-controller attached.) -- 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/TDUlxgFk-ERDO_UfoOwCOkyCIZd2rcECYm_kt5zTz3URvWcyVT9gTVi0mqiY1L1vwwz0q-OMAhtvzrUxfLRipHZZiArzNckX6F3M_aWEH0I%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-TUXEDO-N24_25BU-20180222-095713.yml Description: application/yaml
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
On February 22, 2018 12:52 PM, Aaron Dough wrote:
>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
>
>
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?
--
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/-sv5bMwemcSOisXDi61ve3mL8Zlf6WEtOY2wT4Er2GyUkrHGGaXg__4wWr3VSta8StQuHT77pfOwJW89wks7-Po5ctS6_lz2OwNQkDymtgI%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
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
--
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/BK7OVOw-K-_UOn4c7pmVSG1qRaX6kRa7owOe8o8XYMxEbg9J6BN07jGBbv1zAqDh3Fkv8okztzeZROOFYtuVJ2jwMug3Y8-WFVPOFKg0uXk%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
> Original Message
> Subject: Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
> Local Time: September 14, 2017 11:13 AM
> UTC Time: September 14, 2017 9:13 AM
> From: aaron_do...@protonmail.ch
> To: qubes-users@googlegroups.com
>
> 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.chodzi...@gmail.com
>> To: qubes-users
>>
>> 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 :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:
>
>
Re: [qubes-users] Acer Aspire E 15
> Hello. I am in the market for a laptop that works with Qubes. I am aware of > the Hardware compatibility list, however I did not see the Acer Aspire E 15 > there. It uses the Core i3-7100U, which according to the site show it has > VT-d and VT-x tech. Does this mean the main functions of Qubes will work > without error? Sadly it's not that easy. For example, a 7th gen Intel APU will most probably not work with Qubes 3.2, since the kernel of the underlying Fedora (23 i think) does not yet support it. And since the textual installer is broken (it doesn't prompt for the encryption password), and the GPU is not recognized, you may not be able to install Qubes in the first place. Though I have read about workarounds, like installing via VNC and later upgrading to the experimental newer kernel for example. So if you are set on Qubes and want to be sure, I'd suggest to just buy an older model that you find in the HCL, or maybe wait until Qubes 4 is stable. If you are not entirely set on Qubes, but on your model instead, you can of course take the risk and be the one trying the E15 and submitting the HCL for it ;) --Aaron -- 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/M5J0wdpg86fPC_EKuNJg9s96d_BkdfOQmrDF70sOujfV_-KiGCgtZMRDaNTxX33ErfKCYMUjIiD5Vg_Sa9-ad42bmbaO4gtOJkGNwwmfy28%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 on Tuxedo BU1406
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.chodzi...@gmail.com
> To: qubes-users
>
> 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 :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 somethin
[qubes-users] Qubes 4.0 on Tuxedo BU1406
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:
- 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
- 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](https://groups.google.com/forum/#!topic/qubes-users/Pf1Cd87KSsk)
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?)
- 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 :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](https://groups.google.com/forum/#!msg/qubes-users/rBRTvXryQ6k/ybFZHDxUFgAJ)
was not tried yet.
Unresolved issues:
- 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.
- Standby is not working properly. This is the last dealbreaking issue
remaining.
- 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:
- 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
--
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/lJqQSOe8gZac1CkxzG6cGxVsYB4FTcjXEh-ERrLvUVryBA1e7V61mjdU5o5fws05lDNhuC187LqHk73e4oB5_g32FSEGpqLwezGKV6-SdVM%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.
