> -------- 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 <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 <qubes-users@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.
As embarrassing as this is, 2.1 (Touchpad issues) were just an option in the
preferences, and is thus resolved...
--
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/gEUqojO2RPkf6OOzdZEKHCivy9vRvoQZ9GQkvEBdOuLVmAH7VXivRcnw0JShKIzm_6jTJyZ2iLaj4oVDMCYBHwT4psfgBZo4xZQlotYFsBQ%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.
