Snap packages of KDE apps don't work on RHEL 7

[scx]

Snap package of cantor doesn't work on RHEL 7.
I believe that this issue may be related to snapd rather than the package itself.

SUMMARY

The snap package of cantor doesn't work at all on RHEL 7.7.
Fedora 30 is not affected.

STEPS TO REPRODUCE

1. Install the latest version of snapd from the EPEL7 testing repo (tried the latest stable version of snapd from EPEL7 as well): sudo yum --disableplugin='priorities' --enablerepo='epel*' install snap-confine snapd snapd-selinux
2. Create a symlink: sudo ln -s "/var/lib/snapd/snap" "/snap"
3. Install Snap Store: sudo snap install snap-store
4. Install cantor (any version: stable 19.08.0, candidate 19.08.3, beta 17.04.3, edge master+97ffb4e) on RHEL 7.7 via Snap Store.
5. Run "cantor" or "/var/lib/snapd/snap/bin/cantor"

OBSERVED RESULT

$ cantor
cantor: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

$ /var/lib/snapd/snap/bin/cantor
cantor: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

$ /snap/bin/cantor
cantor: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

Please note that the snap package of Qalculate works without any problem.

EXPECTED RESULT

Working application.

SOFTWARE/OS VERSIONS

Windows: N/A
macOS: N/A
Linux/KDE Plasma: RHEL 7.7/Linux 3.10.0-1062.9.1.el7.x86_64/snapd: 2.43.3/kde-frameworks-5-core18:kde-frameworks-5-core18-slot
(available in About System)
KDE Plasma Version: N/A
KDE Frameworks Version: N/A
Qt Version: N/A

ADDITIONAL INFORMATION

EL7

$ rpm -q --qf "%{NAME}: %{VERSION}\n" snap-confine snapd snapd-selinux
snap-confine: 2.43.3
snapd: 2.43.3
snapd-selinux: 2.43.3

$ which cantor
/var/lib/snapd/snap/bin/cantor

$ snap connections cantor
Interface Plug Slot Notes
content[kde-frameworks-5-core18-all] cantor:kde-frameworks-5-plug kde-frameworks-5-core18:kde-frameworks-5-core18-slot -
dbus - cantor:session-dbus-interface -
desktop cantor:desktop :desktop -
desktop-legacy cantor:desktop-legacy :desktop-legacy -
home cantor:home :home -
network cantor:network :network -
network-bind cantor:network-bind :network-bind -
opengl cantor:opengl :opengl -
pulseaudio cantor:pulseaudio :pulseaudio -
unity7 cantor:unity7 :unity7 -
x11 cantor:x11 :x11 -

$ find /var/lib/snapd/snap/kde-frameworks-5-core18 -xtype f -iname 'libQt5Core.so.5*' 2>/dev/null
/var/lib/snapd/snap/kde-frameworks-5-core18/30/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
/var/lib/snapd/snap/kde-frameworks-5-core18/30/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12
/var/lib/snapd/snap/kde-frameworks-5-core18/30/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3
/var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
/var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12
/var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3

$ snap info cantor
name: cantor
summary: KDE Frontend to Mathematical Software
publisher: KDE✓
store-url: https://snapcraft.io/cantor
contact: https://bugs.kde.org/enter_bug.cgi?product=neon&component=Snaps
license: unset
description: |
  Cantor is a front-end to powerful mathematics and statistics packages. Cantor integrates them into
  the KDE Platform and provides a nice, worksheet-based, graphical user interface. It supports
  environments for KAlgebra, Lua, Maxima, R, Sage, Octave, Python, Scilab, and Qalculate!
commands:
  - cantor
snap-id: VCjprGsSZiPuV3CmQViE4TvPMKTOlaiL
tracking: latest/stable
refresh-date: today at 12:37 CET
channels:
  stable: 19.08.0 2019-08-15 (48) 161MB -
  candidate: 19.08.3 2019-11-06 (55) 161MB -
  beta: 17.04.3 2017-08-17 (1) 16MB -
  edge: master+97ffb4e 2019-07-10 (47) 160MB -
installed: 19.08.0 (48) 161MB -

See also:
https://bugs.kde.org/show_bug.cgi?id=417791

[Jonathan Riddell (jr)]

Do other KDE packages work such as kolourpaint?

[scx (the-scx)]

> Do other KDE packages work such as kolourpaint?

No, kolourpaint is affected as well.

$ /var/lib/snapd/snap/bin/kolourpaint
kolourpaint: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

$ /snap/bin/kolourpaint
kolourpaint: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

It seems to me that for some reasons snap's "connections" are broken on EL7. Or at least cantor:kde-frameworks-5-plug kde-frameworks-5-core18:kde-frameworks-5-core18-slot doesn't work as expected.

[scx (the-scx)]

At first I thought that snapd may be outdated. But I've tried snapd-2.42.2-1.el7 from epel, then snapd-2.43.3-1.el7 from epel-testing, and it is exactly the same version as in Fedora 30, which isn't affected by this bug.

# yum --quiet --disableplugin='priorities' --enablerepo='epel*' --showduplicates list snap-confine snapd snapd-selinux
Installed Packages
snap-confine.x86_64 2.43.3-1.el7 @epel-testing
snapd.x86_64 2.43.3-1.el7 @epel-testing
snapd-selinux.noarch 2.43.3-1.el7 @epel-testing
Available Packages
snap-confine.x86_64 2.42.2-1.el7 epel
snap-confine.x86_64 2.43.3-1.el7 epel-testing
snapd.x86_64 2.42.2-1.el7 epel
snapd.x86_64 2.43.3-1.el7 epel-testing
snapd-selinux.noarch 2.42.2-1.el7 epel
snapd-selinux.noarch 2.43.3-1.el7 epel-testing

https://koji.fedoraproject.org/koji/packageinfo?packageID=23242

[scx (the-scx)]

Is it possible that this bug may be related to squashfuse?
https://src.fedoraproject.org/rpms/snapd/blob/ebb6864d0a079930cfd014948ac7dbfc0b1eba2d/f/snapd.spec#_105-113

# yum --quiet --disableplugin='priorities' --enablerepo='epel*' --showduplicates list squashfuse
Installed Packages
squashfuse.x86_64 0.1.102-1.el7 @epel
Available Packages
squashfuse.x86_64 0.1.102-1.el7 epel

[scx (the-scx)]

Although it is the same version as in Fedora, it isn't installed by default on FC30.

# dnf --quiet --disableplugin='priorities' --enablerepo='fedora*' --showduplicates list squashfuse
Available Packages
squashfuse.src 0.1.102-3.fc30 fedora-source
squashfuse.x86_64 0.1.102-3.fc30 fedora

[scx (the-scx)]

Installing squashfuse didn't break snapd on Fedora.

[scx (the-scx)]

See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1803954

[scx (the-scx)]

After a deeper analysis, I came to the conclusion that KDE (kde-frameworks-5-core18:kde-frameworks-5-core18-slot) is the problem here. Qt5 (libQt5Core.so.5) was probably built with getentropy, so it requires Linux 3.17, and EL7 uses Linux 3.10 by default. This is why it doesn't work.
Anyway, rebuilding KDE without getentropy should solve this problem.
https://bugs.kde.org/show_bug.cgi?id=417791#c7

[Zygmunt Krynicki (zyga)]

I tried reproducing this bug on Fedora 31 x86_64 that I had handy. After a while (desktop helpers launch) I was presented with an application window.

This was on:

snap 2.42.2-1.fc31
snapd 2.42.2-1.fc31
series 16
fedora 31
kernel 5.4.17-200.fc31.x86_64

I suspect your hunch as for get entropy is right. Is that something that KDE can address internally by detecting ENOSYS and falling back to another option? Is there something we can improve on the snapd side?

[scx (the-scx)]

> Is that something that KDE can address internally by detecting ENOSYS and falling back to another option?
Yes, it should be possible for them to force disable renameat2 (requires Linux 3.16), getentropy (requires Linux 3.17), and statx (requires Linux 4.11).
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/minimum-linux_p.h?id=7148dfc67ff20c1c625d203aa47b574b3aaa5db1#n77
https://phabricator.kde.org/R257:a029f2957e947f6e32fe8a595edb0ac553654e90

Then it would require Linux 2.6.28 [1] or rather Linux 3.2 [2a][2b][2c], since you use glibc 2.27, which is still fine, because both EL7 and Ubuntu 14.04 LTS have newer kernels:
- RHEL 7: Linux 3.10
- Ubuntu 14.04 LTS: Linux 3.13
Snaps support RHEL since version 7.6, Ubuntu since version 14.04, and Debian since version 9.

[1]
https://github.com/flathub/flathub/issues/805#issuecomment-453004369
https://bugs.kde.org/show_bug.cgi?id=403042#c2

[2a]
https://www.sourceware.org/ml/libc-alpha/2016-08/msg00212.html
Originally posted by Adhemerval Zanella:
> The GNU C Library version 2.24 is now available
> (...)
> The minimum Linux kernel version that this version of the GNU C Library can be used with is 3.2, except on i[4567]86 and x86_64, where Linux kernel version 2.6.32 or later suffices (on architectures that already required kernel versions more recent than 3.2, those requirements remain unchanged).

[2b]
https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html
Originally posted by Siddhesh Poyarekar:
> The GNU C Library version 2.26 is now available
> (...)
> Linux kernel 3.2 or later is required at runtime, on all architectures supported by that kernel. (This is a change from version 2.25 only for x86-32 and x86-64.)

[2c]
https://paste.ubuntu.com/p/mYn78gPGGf/

Fortunately, glibc 2.30 from Ubuntu 19.10 still requires Linux 3.2.
http://mirrors.kernel.org/ubuntu/pool/main/g/glibc/libc6_2.30-0ubuntu3_amd64.deb
```
$ find lib/x86_64-linux-gnu/ -print0 2>/dev/null | xargs -0 -I{} file '{}' | grep -Z 'for GNU/Linux ' | sort -z -fuV
lib/x86_64-linux-gnu/libnss_nisplus-2.30.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=d559cd4fecb3e9ec6034929433232fe9cf9bf2df, for GNU/Linux 3.2.0, stripped
lib/x86_64-linux-gnu/libcrypt-2.30.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=74cd3b111e7f7dccd596228a37b5ae1d3e6a794a, for GNU/Linux 3.2.0, stripped
lib/x86_64-linux-gnu/libresolv-2.30.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ff5d93702a4017d41249ce54a6c14f813a8db423, for GNU/Linux 3.2.0, stripped
lib/x86_64-linux-gnu/libpcprofile.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ed69d66144b257737a64127896e95180f6815e72, for GNU/Linux 3.2.0, stripped
lib/x86_64-linux-gnu/libmemusage.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=23d60bb0613a7cb0563f64807166a54c554de0b6, for GNU/Linux 3.2.0, stripped
lib/x86_64-linux-gnu/libc-2.30.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=75e3e2d9596aae251330ae...

[scx (the-scx)]

> Is there something we can improve on the snapd side?
When we hit a similar problem last year in flatpak, I proposed to add an option to determine kernel requirements.
https://github.com/flatpak/flatpak/issues/2551#issue-397366787

The flatpak creator pointed out that we should check rather for symbols/features, because some kernels may be highly modified, as it is in EL.
https://github.com/flatpak/flatpak/issues/2551#issuecomment-456002791
> Kernel requirements are tricky things. Generally the dependency is not on a specific version but on some feature/behaviour, and those are often backported to enterprise kernel without bumping the kernel version.

You can also perform some additional verification for runtimes and apps, to make sure that they won't require Linux > 3.2. Maybe CI that runs apps (and runtimes) on old kernels would help us to prevent problems like this in the future. This was originally proposed by Matthias Clasen from Fedora Silverblue.

Anyway, without additional checks, we can hit this problem again in the future (e.g. core20, core22, core24, etc).