if it is not arch specific it should surely also happen in qemu using the normal kvm image from edge …
The main issue is platform-api is unable to dlopen the mirclient module (“Unable to load selected module, using dummy.”)
At least in my rpi3 it happened after an update to core.
I will try to gather more information on the failure, but log does not contain any denials when opening the module which is strange.
Yes I get the same results with the KVM image
1 Like
In the mean time, you can switch to the core --candidate channel:
snap refresh core --candidate
That works on my Rpi3
Yes using core from edge channel
Knowing nothing about mir, can we get any extra information about why it cannot load that module?
Thank you, that has done the trick can continue with testing now. Works on both rPi and KVM
Cheers
Adam
Can someone please patch that snap to include a call to dlerror when dlopen fails?
Can someone collect all the security profiles from when this was NOT working?
I’m specifically interested in /var/lib/snapd/mount/ directory
Yep about to do that.
Curious, I recall when looking at kiosk policy that there was an issue with running the app snap a second time. Ie, I would use all the steps in my previous comment (and snap-discard-ns) but before starting the application, I would ‘rm -rf ~/snap/’ and it would work. If I didn’t remove the app snap’s user data directories, it didn’t work. I thought at the time this was something with the higher level bits, but perhaps it is mir-related.
If the interfaces are connected, can you run:
$ sudo service snap.mir-kiosk-apps.mir-kiosk-app-daemon stop
$ sudo /usr/lib/snapd/snap-discard-ns mir-kiosk-apps
$ sudo rm -rf /root/snap/mir-kiosk-apps
$ sudo service snap.mir-kiosk-apps.mir-kiosk-app-daemon start
and report back if it starts? Since you said that it used to work, I doubt this would be it, but it is easy enough to check and rule out.
So it seems that libubuntu_application_api_desktop_mirclient.so.3.0.0 depends on libjson-c.so.2.
dlerror: "libjson-c.so.2: cannot open shared object file: No such file or directory"
Indeed, libjson-c.so.2 does not exist in the mir-kiosk-apps snap.
However it used to exist in previous core snaps revisions, so the library used to resolve to “/snap/core/1804/lib/x86_64-linux-gnu/libjson-c.so.2” (for the current --candidate revision)
Maybe a mir-kiosk-apps rebuild is all that is needed?
@ogra ^^
If this is the case it’s an (unfortunate) ABI break that we should not do as a part of the core 16 series.
it is definitely a bug in the snap to not ship libjson-c2 on its own, we do not guarantee any availability of any libs beyond libc and /bin/sh in the core snap, so please fix mir-kiosk-apps to include this lib in the next upload.
here is a temporary fix that i plan to remove again once mir-kiosk-apps is fixed:
This is what snapcraft computed based on what was available in the core snap at the time the app snap was built. It is not a bug in the snap. We must not remove anything from the core snap if we allowed apps to use it in the past.
1 Like
$ apt-cache depends rsyslog
rsyslog
Depends: libc6
Depends: libestr0
Depends: libjson-c2
Depends: libsystemd0
Depends: libuuid1
Depends: zlib1g
Depends: init-system-helpers
Depends: lsb-base
Depends: adduser
Depends: ucf
i highly disagree, then it is a bug in snapcraft to rely on some random lib that was inside the core snap … we only guarantee libc and a working shell on the core side, snapcraft needs to take this into account.
I’m not sure where that is documented but I’ve not seen it officially anywhere. People are for example using ssl, system python, etc, etc, etc, etc.