Unsolicited feedback on qubes-issue #2455

[Alex]

Hi,
I'm reporting some user experience tests for fedora 25 template (ref.
issue mentioned in subject).

I updated a fedora 24 template with many customizations on it, bringing
it to f25 via DNF and enabling qubes-vm-r3.2-current-testing repo.

Environment: Qubes R3.2 fully updated, i3WM as window manager.

Mindset: upgrading my AppVMs, and in the meanwhile helping with issue
#2455, with specific attention to graphical/GUI issues (because of
recent Fedora switch to Wayland, which Qubes does not support, as
mentioned by marmarek on said issue).

# dnf --releasever=25 --enablerepo=qubes-vm-r3.2-current-testing update

The upgrade process was smooth, took 4 hours overall (I was working
during the process, so this may have slowed it down) and template size
(after trim) increased slightly from 8.46GB to 8.57GB (not bad!). The
repos for torproject don't have fc25 as an available release yet...

As far as I am concerned, these were the measured facts:
- many AppVMs started just fine after changing the template in their
settings from fedora 24 to fedora 25.
- firefox, thunderbird and libreoffice work just fine. Firefox can play
youtube videos without delays, glitches nor jitter.
- pinta (graphic manipulation program) works ok
- Android studio works ok
- gnome-terminal, xterm and urxvt all work with their customizations
(themes)
- Android emulator (emulating ARM processor, so it's normally slow)
works exactly as before
- Monodevelop works ok
- window resizing works ok, both dragging corners (for floating windows)
and splitting monitors in various ways (i3wm is a tiling window manager).

Now for more unsolicited input, but trying to be as specific as I can be
- please note that I don't fully understand the working of Qubes-GUID (I
never studied it, until now :)
- One AppVM with a lot of installed software took a couple of tries to
correctly start. The first time the start failed with "qrexec daemon not
running", and in guid log I found a long list of "invalid PMaxSize for
0x2000001d (32767/32767)" and so on. Cannot reproduce this problem.
- Qubes-GUID crashed in one AppVM as soon as I started monodevelop the
first time. Cannot reproduce this problem either. Error in guid log was:

ErrorHandler: BadAccess (attempt to access private resource denied)
Major opcode: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)
ResourceID: 0x2000054
Failed serial number: 3670
Current serial number: 3671

may be related to the fact that monodevelop shows and hides many windows
in rapid sequence when starting?

Overall the switch was good. I'll report further problems should they
arise. Thank you for your work, let me know if I can help more.

--
Alex

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/26/16 07:13, Alex wrote:
> Hi,
> I'm reporting some user experience tests for fedora 25 template (ref.
> issue mentioned in subject).
>
> I updated a fedora 24 template with many customizations on it, bringing
> it to f25 via DNF and enabling qubes-vm-r3.2-current-testing repo.
>

> [...]

Thank you, Alex. This is very helpful. (Added as a comment on #2455.)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYObNsAAoJENtN07w5UDAwSA4P/1DFvS5LNR9XauU0zr2OemAz
HvUPb8xrvCUrPsUCFr5m3gTreD+XQphbw9WTWRSid1DEW7dNvF3a4gu5SEILPWpK
0EFNuYZW9hyNsVz8XVTneS+02hggFPrKn3DLF0Y/gtQf7//zHSKZHXLO6jlNgvDz
7IX32oq8H2h52YW/EiJ2hyHRla1aSaE0dCAVZM1x7tl2F/ibUa7OryU34/ZYzKHY
YFrBGYMIdqXSX6uF2qlrWDnRnuCUSHWQPM/kJX/CrFpvoOoYHYyfBMgs16AiGcll
iqq8YtuweTH8k+zwq1CRiOfZCEXJFGAgVxpN52ESDCW/NEjmZD2L4RSw4PDw+kjQ
7XfnYRFNVJ5eD5tSR5BXdL/uWIbi3xwTAjGjS9uTl4CcL05FgyzusAIEG5iFRCwQ
iK4V3AdNTchg7D9ZYbOgRYqg4mkXcxZZlDlhAGXNBqu89LnZQ6pjJle/PsueVTsJ
JlA/s1fVZwhCHUxA0ySMmMNe57jTQ1akEOGtDcJThrrxHsb6/ME00r1oyXXWKpWn
Nj9PinitfeMsCx39XyhuAXbW3+pX8CmAqs/8jea20l7FbDjvhwtQ5pXxpyaS63Id
sw/rfx3m5pRoL3ZUj1hBGeF6f5z5tVO92f9zMFaknX4vCD2JJ3LIPUiT9qJjj2Dr
S6vCrSq3OaiLxXBp42uw
=JUd9
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Sat, Nov 26, 2016 at 04:13:48PM +0100, Alex wrote:
> Hi,
> I'm reporting some user experience tests for fedora 25 template (ref.
> issue mentioned in subject).
>
> I updated a fedora 24 template with many customizations on it, bringing
> it to f25 via DNF and enabling qubes-vm-r3.2-current-testing repo.
>
> Environment: Qubes R3.2 fully updated, i3WM as window manager.
>
> Mindset: upgrading my AppVMs, and in the meanwhile helping with issue
> #2455, with specific attention to graphical/GUI issues (because of
> recent Fedora switch to Wayland, which Qubes does not support, as
> mentioned by marmarek on said issue).

Thanks! I was planning to send a little announcement asking for testing
today/tomorrow, but I guess you read my mind ;) I've uploaded packages
to repository just today...

> # dnf --releasever=25 --enablerepo=qubes-vm-r3.2-current-testing update
>
> The upgrade process was smooth, took 4 hours overall (I was working
> during the process, so this may have slowed it down) and template size
> (after trim) increased slightly from 8.46GB to 8.57GB (not bad!). The
> repos for torproject don't have fc25 as an available release yet...

In my case upgrade was somehow faster - like 1h or so. But I wasn't
using the machine in the meantime.

> As far as I am concerned, these were the measured facts:
> - many AppVMs started just fine after changing the template in their
> settings from fedora 24 to fedora 25.
> - firefox, thunderbird and libreoffice work just fine. Firefox can play
> youtube videos without delays, glitches nor jitter.
> - pinta (graphic manipulation program) works ok
> - Android studio works ok
> - gnome-terminal, xterm and urxvt all work with their customizations
> (themes)
> - Android emulator (emulating ARM processor, so it's normally slow)
> works exactly as before
> - Monodevelop works ok
> - window resizing works ok, both dragging corners (for floating windows)
> and splitting monitors in various ways (i3wm is a tiling window manager).

In addition to this, all automatic tests also passes, so basic things
like DispVM, NetVM etc should work.

> Now for more unsolicited input, but trying to be as specific as I can be
> - please note that I don't fully understand the working of Qubes-GUID (I
> never studied it, until now :)
> - One AppVM with a lot of installed software took a couple of tries to
> correctly start. The first time the start failed with "qrexec daemon not
> running", and in guid log I found a long list of "invalid PMaxSize for
> 0x2000001d (32767/32767)" and so on. Cannot reproduce this problem.

This particular message shouldn't be a problem, probably the reason is
somewhere else. Do you still have the last message of the log?

> - Qubes-GUID crashed in one AppVM as soon as I started monodevelop the
> first time. Cannot reproduce this problem either. Error in guid log was:
>
> ErrorHandler: BadAccess (attempt to access private resource denied)
> Major opcode: 130 (MIT-SHM)
> Minor opcode: 1 (X_ShmAttach)
> ResourceID: 0x2000054
> Failed serial number: 3670
> Current serial number: 3671
>
> may be related to the fact that monodevelop shows and hides many windows
> in rapid sequence when starting?

Yes, it may be. Very similar error (#2171) was already fixed some time
ago, but apparently not all the cases. Anyway it's rather problem in
gui-daemon, independent of Fedora version.

> Overall the switch was good. I'll report further problems should they
> arise. Thank you for your work, let me know if I can help more.

- --
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

iQEcBAEBCAAGBQJYOhO2AAoJENuP0xzK19cs/8EH/2DjYZVaLLh0RiYY4OmESN/Q
17Wb9B7fst6S74NAE2jwMv6H46QtaT3PvAZj/DFVOUDcpJpqEQ8yebwgwaAC7k/1
ZXTCBX7igAP081QdMUzUyIBjQlH3iD69cwstJ563TBlSwniyp1xDayV1vvwl/x3H
ZgPOca5JmtaT8gWtDC9hPGkSL+EUCarAu6nV1Ws/5D3D27lxexBfQkr7VDLrAoHG
ib/OdvuJg6TLLw8xVoGcRJByc62MkpvgLmHMwSGfiI1fkOJDv5iU4uLKvVEWNRub
g7AbelyuFEX4rG6BhB/q1usdwiSmU087ia8w+QIEcxsLi9iIANOfoqJ1We6LXIs=
=gR7B
-----END PGP SIGNATURE-----

[Alex]

On 11/26/2016 11:59 PM, Marek Marczykowski-Górecki wrote:
> In addition to this, all automatic tests also passes, so basic
> things like DispVM, NetVM etc should work.

They do, for me too :) I just forgot to mention them :D

>
>> Now for more unsolicited input, but trying to be as specific as I
>> can be - please note that I don't fully understand the working of
>> Qubes-GUID (I never studied it, until now :) - One AppVM with a lot
>> of installed software took a couple of tries to correctly start.
>> The first time the start failed with "qrexec daemon not running",
>> and in guid log I found a long list of "invalid PMaxSize for
>> 0x2000001d (32767/32767)" and so on. Cannot reproduce this
>> problem.
>
> This particular message shouldn't be a problem, probably the reason
> is somewhere else. Do you still have the last message of the log?

I'm sorry, but I was in a semi-hurry and did not keep the logs. My
plan-B was to restore everything from a backup in case the upgrade
produced some catastrophic situation, and since a mere VM reboot fixed
the situation, I did not keep the logs but only some fragments I deemed
important. My bad.

>> - Qubes-GUID crashed in one AppVM as soon as I started monodevelop
>> the first time. Cannot reproduce this problem either. Error in guid
>> log was:
>
>> ErrorHandler: BadAccess (attempt to access private resource
>> denied) Major opcode: 130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach)
>> ResourceID: 0x2000054 Failed serial number: 3670 Current serial
>> number: 3671
>
>> may be related to the fact that monodevelop shows and hides many
>> windows in rapid sequence when starting?
>
> Yes, it may be. Very similar error (#2171) was already fixed some
> time ago, but apparently not all the cases. Anyway it's rather
> problem in gui-daemon, independent of Fedora version.

It may be nice to have a fallback handler for qubes-guid crashes, if the
X architecture permits, that restarts the daemon and restores windows
redirection to dom0. After the crash I could check programs were running
inside the VM (via qvm-run) but no window could be seen in dom0. It was
not a pleasant situation :/ A simple recovery-by-restart may help a lot
with the user experience in such cases...

--
Alex

[Alex]

On 11/26/2016 11:59 PM, Marek Marczykowski-Górecki wrote:

>> - Qubes-GUID crashed in one AppVM as soon as I started monodevelop
>> the first time. Cannot reproduce this problem either. Error in guid
>> log was:
>
>> ErrorHandler: BadAccess (attempt to access private resource
>> denied) Major opcode: 130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach)
>> ResourceID: 0x2000054 Failed serial number: 3670 Current serial
>> number: 3671
>
>> may be related to the fact that monodevelop shows and hides many
>> windows in rapid sequence when starting?
>
> Yes, it may be. Very similar error (#2171) was already fixed some
> time ago, but apparently not all the cases. Anyway it's rather
> problem in gui-daemon, independent of Fedora version.

Ok, this problem happened again, and always when starting monodevelop.
Now I collected more logs, and tried to fiddle a bit with qubes-guid.

In dmesg there's nothing interesting apart from 238 repetitions of this
line just before the crash manifested with all windows from that VM
disappearing:
[ 77.469369] U2MFN_GET_MFN_FOR_PAGE: get_user_pages failed,
ret=0xfffffffffffffff2

Before this repetition of lines there is only the Fedora 25 (Workstation
Edition) login prompt.

The full content of guid log is short:

---------snip---------
Icon size: 128x128
invalid PMaxSize for 0x340001c (32767/32767)
invalid PMaxSize for 0x340001c (32767/32767)
invalid PMaxSize for 0x3400025 (32767/32767)
invalid PMaxSize for 0x3400025 (32767/32767)
invalid PMaxSize for 0x3400025 (32767/32767)

ErrorHandler: BadAccess (attempt to access private resource denied)
Major opcode: 130 (MIT-SHM)
Minor opcode: 1 (X_ShmAttach)

ResourceID: 0x340003b
Failed serial number: 1294
Current serial number: 1295
---------snip---------

And that's all of it. This run was from a freshly started VM, where only
Firefox and Thunderbird were started before monodevelop. I'm starting to
get convinced that windows that appear and suddently disappear after a
very short amount of time can be a problem for gui-daemon.

After the crash I tried to open a shell to restart the daemon (later I
tried to just restart the daemon from dom0) but without luck:

dom0$ qvm-run --pass-io work /bin/bash
[here the windows from the work appVM briefly returned on screen, a
terminal appeared too, then everything from that vm disappeared again in
a couple of seconds. No output in dom0 terminal, so I killed this
qvm-run instance]

dom0$ qvm-run --pass-io work /usr/bin/qubes-gui
Running command on VM: 'work'...
--> Starting Qubes GUId...
Connecting to VM's GUI agent: .exiting
ERROR(work): Cannot start qubes-guid!

dom0$ qvm-run --pass-io work "/usr/bin/systemctl restart qubes-gui-agent"
Running command on VM: 'work'...
--> Starting Qubes GUId...
Connecting to VM's GUI agent: .exiting
ERROR(work): Cannot start qubes-guid!

And that's when I gave up... The way out is to restart the VM. I guess I
should study the Qubes project deeper as a developer to help both me and
the project more :/ If only I had the time...

--
Alex

[Marek Marczykowski-Górecki]

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

Actually this should be the case - restarting gui daemon should be
enough. And qvm-run (without --nogui) should automatically start gui
daemon if not running currently. What happened when you've tried? Any
error regarding gui daemon startup?

- --
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

iQEcBAEBCAAGBQJYOv0RAAoJENuP0xzK19csKrYH/3hBLL7t3Soy/mWh7NehdUDs
Wdweh7QIEjx7x2eF6JGxHTbfeBpj6tCqCjYebhfTfBAqblevsVBepyWqYLB/4W/F
CDK6qTWTiV6aqn22PX69rdpVT0eljT2MgMzzJDwApie8n+qzw1JYkkoLAU2I2ICn
jbXGXHIK60Pgd//YJKbk9/T0Uy6lRO3C00Imn3rj3ekQC2mmglSOivA9rkPwECQx
IvKao/RuRiV0AFNja6pOGL157GoA3hvKhMVj1MX18R5d9jMXKIKbIfA75d3ol+lD
bbJi5LsQkPMLLUM0ooZxbFQA1kN3jBYGWAjBlCKMBTnZGW0VsX6LVLQMuNlf3ac=
=pg11
-----END PGP SIGNATURE-----

[Foppe de Haan]

I ran into a weird (and not consistently reproducible) issue with my 2-monitor setup (UHD main screen + FHD secondary) adjusting the 'display' settings (changing the alignment of the 2 monitors).
When I 'moved' the FHD screen from right of the upper right quad of my UHD screen, to 'below' the lower left quad, and then left of the upper left quadrant, but not aligned with the top border (about 300px lower), then to roughly vertically 'centered' of the right, I could no longer click on any of the buttons / tabs at the top of my firefox instance (which is snapped to use the left half of my UHD monitor), and the mouse 'clicked' in different spots than where the cursor was located. I had to restart the VM to 'fix' this. Happened twice, but not since.

[Alex]

This used to happen to me too, when the VM was started with a screen
geometry and then I changed attaching a new monitor. This could be
caused by old versions of qubes, which had an arbitrary fixed monitor size.

But this is a thread on the upgrade of templates to fedora 25 and
related feedback; please report the version of Qubes you are using, and
the template. Also, if your problem does not belong to the topic, please
open another (write at the e-mail address a new mail with a specific
subject, don't just reply to other e-mails).

--
Alex

[Foppe de Haan]

I see; I'll make some further attempts to reproduce it that way then, haven't disconnected that monitor again since running into the issue this morning.
The reason I mentioned this in this thread is that I've only encountered this issue since I upgraded that VM's template to fc25; I don't recall running into it before. Running qubes r3.2 with all updates from current-testing and security-testing (so with xen 4.6.3), both on dom0 and domU side.

[Daniel Moerner]

On Sunday, November 27, 2016 at 10:33:05 AM UTC-5, Alex wrote:
> On 11/26/2016 11:59 PM, Marek Marczykowski-Górecki wrote:
> >> - Qubes-GUID crashed in one AppVM as soon as I started monodevelop
> >> the first time. Cannot reproduce this problem either. Error in guid
> >> log was:
> >
> >> ErrorHandler: BadAccess (attempt to access private resource
> >> denied) Major opcode: 130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach)
> >> ResourceID: 0x2000054 Failed serial number: 3670 Current serial
> >> number: 3671
> >
> >> may be related to the fact that monodevelop shows and hides many
> >> windows in rapid sequence when starting?
> >
> > Yes, it may be. Very similar error (#2171) was already fixed some
> > time ago, but apparently not all the cases. Anyway it's rather
> > problem in gui-daemon, independent of Fedora version.
> Ok, this problem happened again, and always when starting monodevelop.
> Now I collected more logs, and tried to fiddle a bit with qubes-guid.
>
> In dmesg there's nothing interesting apart from 238 repetitions of this
> line just before the crash manifested with all windows from that VM
> disappearing:
> [ 77.469369] U2MFN_GET_MFN_FOR_PAGE: get_user_pages failed,
> ret=0xfffffffffffffff2

I just hit this bug in sys-net using a F25 template. nm-applet silently crashed, the VM state turned yellow in Qubes VM Manager, and the log was filled with this error.