-
Notifications
You must be signed in to change notification settings - Fork 584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
snap-confine/nvidia: Support legacy biarch trees for GLVND systems #4559
Conversation
GLVND systems are well catered for on biarch configurations, however the older 304 + 340 series will rely on ld.so.conf tricks to mask the system libGL.so with one in the private `libdir/nvidia*/` files. This is seen consistently across Arch, Fedora and Solus. As such we allow these fallback paths to work so that users of snapd on glvnd enabled distros with the older legacy drivers can still enjoy snapd + NVIDIA together. Signed-off-by: Ikey Doherty <[email protected]>
Sample |
Codecov Report
@@ Coverage Diff @@
## master #4559 +/- ##
==========================================
+ Coverage 78.18% 78.19% +<.01%
==========================================
Files 456 456
Lines 32529 32690 +161
==========================================
+ Hits 25434 25563 +129
- Misses 4979 5011 +32
Partials 2116 2116
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Oh goodie, this should fix some of the reported issues in Fedora with NVIDIA, too. |
@mvo5 Could you please cherry pick this into 2.31 for me? This will resolve RH#1442051 for me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, CC @jdstrand
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm approving the apparmor changes, but please consider checking if it is actually a symlink since all the comments and die() are reporting this is the case.
|
||
// Make sure we don't have some link already (merged GLVND systems) | ||
if (lstat(symlink_name, &stat_buf) == 0) { | ||
if (unlink(symlink_name) != 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't you also be testing if S_IFLNK? lstat() will happily return 0 if regular file or symlink.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The path is inside our hostfs symlink farm that we create, and we only create symlinks, the code doesn't copy files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, the naming here is confusing, but symlink_name
is not the source name, it is the target name for the symlink, i.e. the new inode. Confused the hell out of me going through it the first time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll probably do a small update here to use consistent terminology (oldname vs whatever the other one was).
@ikeydoherty I think I might be confusing myself again, but will the snap-confine mount-support code actually work with legacy nvidia driver stuff installed in c.f.: http://koji.rpmfusion.org/koji/rpminfo?rpmID=171143 |
Uh it looks like you guys have even more stuff in that directory than I suspected. You have files in there that shouldn't and don't need to be.. Only the libGL needs to be there :/ In that case we'd have to effectively double the copy list to include all of those (frankly incredibly silly) paths. |
And TBH @Conan-Kudo it looks like Fedora should be using bind mounts for those nvidia drivers, but my guess is the use of glvnd makes that unfeasible. What we can do: Remove 32 vs 64 logic in the "mount" farm. Make the function accept a common ancestor, i.e. That should simplify the code and cover all of the uses, right? And keep the copy list simpler by implicitly allowing skipping over elements. |
Instead of our two hard-coded path lists, we'll form relative paths for all optional elements in the list against common ancestors known for biarch distributions. This builds upon the previous work and allows us to replace or grab files from the subdirectories, and also allows the private NVIDIA libraries to exist either within the toplevel libdir or within a private directory, as seen on Fedora. The flow is changed slightly so that our first primary call for each libdir is the only mount, and then we follow up with a simple populate call for the libdir. Signed-off-by: Ikey Doherty <[email protected]>
OK I added a follow up commit which should just make stuff work for Everyone ™ |
The only pain point I see (because I don't know how it works on Fedora) is this reliance on |
@ikeydoherty They are distinct directories. We could make this a compile-time option if you want, then we can feed in the correct base libdir as a configure option (we already do, it just does nothing with it...). |
This will allow each distro to provide the native arch and the alternative lib32 directory without us trying to guess where they go. With this change, we'll only try to mount the alternative 32-bit biarch space if we're a 64-bit build of snapd, otherwise we'd only have the native 32-bit arch to worry about in the first place. Signed-off-by: Ikey Doherty <[email protected]>
Signed-off-by: Neal Gompa <[email protected]>
3701eb7
to
7f8bc25
Compare
Yay! Danke ^_^ |
GLVND systems are well catered for on biarch configurations, however the
older 304 + 340 series will rely on ld.so.conf tricks to mask the system
libGL.so with one in the private
libdir/nvidia*/
files. This is seenconsistently across Arch, Fedora and Solus. As such we allow these fallback
paths to work so that users of snapd on glvnd enabled distros with the older
legacy drivers can still enjoy snapd + NVIDIA together.
Signed-off-by: Ikey Doherty [email protected]