On 2025-02-09 11:55, Zygmunt Krynicki wrote:
Thanks, Zygmunt, for elaborating and providing some background. That completely makes sense.Wiadomość napisana przez Ralf Bergs <[email protected]> w dniu 9 lut 2025, o godz. 11:12:It seems that snapd needs some kernel features that are not present in the currently running kernel. However, if that is the case, then it should depend on a kernel that *has* these features.Those are kernel-level apparmor features that depend on the evolution of apparmor in the upstream kernel. Snapd can detect all such features and actively looks for several, mostly related to UNIX sockets that allow DBus message mediation. The process of landing those features in the upstream kernel has been long and complicated and is AFAIK still ongoing. Snapd detects absence of those features and gracefully degrades functionality.
Would it not be possible to compile a kernel with all the required features enabled, give the package a name following a specific scheme (e.g. "linux-image-snap", you get the idea...), and then depend on or "recommend" such kernels?There is no way to depend on any kernel that would have all the features in Debian. At some point the upstream kernel release should have all of them so the messages will go away.
Or is it simply that the features may not even be available in a kernel that has been approved for "stable?"
Thanks again.
smime.p7s
Description: S/MIME Cryptographic Signature

