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

Do other KDE packages work such as kolourpaint?

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

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

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

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

Installing squashfuse didn't break snapd on Fedora.

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

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

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?

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

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