Mir graphics platform determined based on host server outside of snap

Bug #1665123 reported by Michał Sawicz
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Mir
New
High
Unassigned
Unity8 Session Snap
Triaged
High
Unassigned
mir (Ubuntu)
New
High
Unassigned

Bug Description

People have reported the unity8 session snap to fail to start, with a log excerpt (http://pastebin.ubuntu.com/24000769/):

ERROR: /build/mir-Hd65rv/mir-0.26.0+16.04.20170126.3/src/common/sharedlibrary/shared_library.cpp(33): Throw in function mir::SharedLibrary::SharedLibrary(const char*)
Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
std::exception::what: /snap/unity8-session/439/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.12: cannot open shared object file: No such file or directory

Mir 0.26 is trying to load the mesa graphics v12, which only came in Mir 0.26.1. It seems Mir is somehow expecting for the system-installed graphics v12 to be there in the snap.

Tags: nested snap
Michał Sawicz (saviq)
affects: unity8 (Ubuntu) → unity8-session-snap
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

That's correct. We only noticed (a bit late) that Mir 0.26.0 had broken the graphics platform ABI but failed to bump the soname. This has happened before, and leaving it is worse than fixing it late (in Mir 0.26.1). So we have corrected the ABI level in Mir 0.26.1 to be 12 rather than 11.

However this does not fully explain the above error. It looks like your snap contains confused binaries. Your build path is "mir-0.26.0+16.04.20170126.3" yet it is actually trying to load "graphics-mesa-kms.so.12" which only exists in Mir 0.26.1. So you seem to have mismatch of binaries in your snap, if not just an incorrect build identifier.

Although that still doesn't fully explain the above error. AFAIK, Mir will load all modules in the drivers directory (server-platform), so if it knows the name is 'graphics-mesa-kms.so.12' then that's probably not the missing file. Perhaps it found 'graphics-mesa-kms.so.12' but that depends on some other library that is missing.

I can't yet see anything Mir is doing wrong but it looks very likely your snap contains incorrect binaries. I can't tell how they are incorrect though.

Changed in mir:
status: New → Incomplete
importance: Undecided → High
Revision history for this message
Michał Sawicz (saviq) wrote :

The snap contains binaries from .debs, we're not (re)building anything there.

The problem seems to be that Mir is looking in / to determine which graphics platform to load. If you have a "compatible" Mir between / and the snap, all's fine. But when you install a different version in /, the snap version is trying to find the system-installed one somehow.

Changed in mir:
status: Incomplete → New
Revision history for this message
Michał Sawicz (saviq) wrote :

So the state yesterday was:

snap r439 had Mir 0.26.0
xenial overlay had Mir 0.26.1
snapped Mir was loading graphics-mesa-kms.so.12 (and failed)

snap r439 had Mir 0.26.0
zesty had Mir 0.26.0
snapped Mir was loading graphics-mesa-kms.so.11 (and worked fine)

After rebuiling the snap:

snap r442 has Mir 0.26.1
xenial overlay has Mir 0.26.1
snapped Mir loads graphics-mesa-kms.so.12 (and works)

snap r44 has Mir 0.26.1
zesty has Mir 0.26.0
snapped Mir loads graphics-mesa-kms.so.11 (and fails)

After installing Mir from zesty-proposed:

snap r44 has Mir 0.26.1
zesty-proposed has Mir 0.26.1
snapped Mir loads graphics-mesa-kms.so.12 (and works)

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

Where Mir gets looks for libraries is entirely configurable. If you want it from the snap...

Command line: --platform-path $SNAP/usr/lib/x86_64-linux-gnu/mir/server-platform
Environment.: MIR_SERVER_PLATFORM_PATH=$SNAP/usr/lib/x86_64-linux-gnu/mir/server-platform
Config file.: platform-path=$SNAP/usr/lib/x86_64-linux-gnu/mir/server-platform

Revision history for this message
Michał Sawicz (saviq) wrote :

We already set:

MIR_SERVER_PLATFORM_PATH=$SNAP/usr/lib/$ARCH/mir/server-platform

 sudo cat /proc/`pidof unity8`/environ | tr '\0' '\n' | grep SERVER_PLATFORM
MIR_SERVER_PLATFORM_PATH=/snap/unity8-session/442/usr/lib/x86_64-linux-gnu/mir/server-platform

And that is where Mir is *loading* them from. How does it detect what to load, in the first place? It seems as if it gets that information from /?

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

Now that's weird. The "probing" and "loading" are the same codepath.

Two things:

/1/ If unity8 is running under a host server, then it "inherits" the graphics driver that is using. So, are you using USC in the snap?

/2/ Could you grep for MIR_SERVER_? The --platform-graphics-lib/MIR_SERVER_PLATFORM_GRAPHICS_LIB override which would bypass MIR_SERVER_PLATFORM_PATH but a full list of the server env variables would be good.

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

Unity8 is running under a unity-system-compositor sourced from the host image.

In "hosted" mode, Mir attempts to use the graphics driver reported by the server. (This is something we have plans to change by creating a generic "nested platform".)

Because unity-system-compositor and Unity8 are built with incompatible versions[1] of Mir this doesn't work.

[1] Surprisingly Mir 0.26.0 and Mir 0.26.1 are incompatible because of a .soname change in the graphics platform.

summary: - Mir graphics platform determined based on host system instead of snap
+ Mir graphics platform determined based on host server outside of snap
Revision history for this message
Michael Terry (mterry) wrote :

This doesn't seem to be version-related at all. Even when trying to switch unity8-session to use the mir-libs 0.26.1 snap on an up to date xenial+overlay system, I hit this bug.

It seems the host Mir server (USC) is telling unity8 to directly load /usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.12. This can't be seen from the snap (since Ubuntu Core is mounted at /usr/lib -- unless we used classic mode...).

This has worked in our snap because we have an LD_PRELOAD trick that rewrites such dlopens into our snap space.

Even MIR_SERVER_PLATFORM_PATH doesn't help, it gets ignored in favor of host server's location. Which is probably the right thing to do if the drivers must match. Just ends up biting us here.

I'll avoid using mir-libs in our snap for now, instead bundling the libraries in. Apparently the Mir team is working on making this coupling less painful.

tags: added: ne
tags: added: nested
removed: ne
tags: added: snaps
tags: added: snap
removed: snaps
Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.