Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[solved] nvidia-drivers build failure, "permission denied"
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
LemurFromTheId
n00b
n00b


Joined: 22 Apr 2005
Posts: 64
Location: Finland

PostPosted: Sun Sep 29, 2019 3:04 am    Post subject: nvidia-drivers build failure, "permission denied" Reply with quote

I'm getting a strange build failure when trying to emerge nvidia-drivers-435.21, and I've no idea what's happening.

Background: I successfully built a kernel (gentoo-sources-4.19.72) and nvidia-drivers just a couple of days ago; there have been no version upgrades since then. Now I wanted to add user namespaces to the kernel (CONFIG_USER_NS). So, I did:
Code:
make clean
make menuconfig
make
make modules_install
make install

And then:
Code:
emerge @module_rebuild

...which led to failure:
Code:
[ebuild   R   ] x11-drivers/nvidia-drivers-435.21  USE="X acpi driver kms multilib tools -compat -gtk3 (-libglvnd) -static-libs -uvm -wayland" ABI_X86="(64) -32 (-x32)"

Code:
In file included from <command-line>:
././include/linux/kconfig.h:5:10: fatal error: ./include/generated/autoconf.h: Permission denied
 #include <generated/autoconf.h>
          ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.


I tried downgrading to nvidia-drivers-430.50, but the result was the same. Where's this "Permission denied" coming from? Is there something wrong with how Portage is sandboxing stuff, or...? Any idea what's going on in here?

emerge --info: https://controlc.com/45c8773f
build.log: https://controlc.com/b6d70bd3


Last edited by LemurFromTheId on Sun Sep 29, 2019 3:06 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44202
Location: 56N 3W

PostPosted: Sun Sep 29, 2019 9:48 am    Post subject: Reply with quote

trae,

nvidia-drivers builds against the kernel sources pointed to by /usr/src/linux is that pointing to the kernel you think it is?

The FEATURES section in
Code:
man make.conf
may be worth a read too.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
LemurFromTheId
n00b
n00b


Joined: 22 Apr 2005
Posts: 64
Location: Finland

PostPosted: Sun Sep 29, 2019 12:55 pm    Post subject: Reply with quote

NeddySeagoon wrote:
trae,

nvidia-drivers builds against the kernel sources pointed to by /usr/src/linux is that pointing to the kernel you think it is?

The FEATURES section in
Code:
man make.conf
may be worth a read too.


Thanks for the reply!

I only have one set of kernel sources, so that should not be an issue. I already built a kernel and nvidia-drivers from the exact versions I have available right now a few days ago. The nvidia module I have seems to work just fine, but I can't rebuild it, which is what emerge @module-rebuild would like to do.

Code:
~ ls -l /usr/src   
total 4.0K
lrwxrwxrwx  1 root root   20 Sep 25 06:36 linux -> linux-4.19.72-gentoo/
drwxr-xr-x 27 root root 4.0K Sep 29 12:22 linux-4.19.72-gentoo/


Thanks for the tip about FEATURES, but i'm not really seeing anything thank would be useful - but then again, I only understand about half of what I'm seeing. Is there something specific I should be looking at?

As a side note, I just did a full emerge --emptytree --keep-going @world overnight. Everything else compiled just fine, but even after a reboot nvidia-drivers fail to do so.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44202
Location: 56N 3W

PostPosted: Sun Sep 29, 2019 1:04 pm    Post subject: Reply with quote

trae,

When you launch portage as root, it tries to do as little as possible as root and drops to using the portage user wherever possible.
FEATURES can enable a whole list of assorted sandboxes to stop poor quality ebuilds doing things they are not supposed to.
The default settings should be good.

Please post the entire build log for nvidia-drivers and the output of
Code:
emerge --info

The build log will be too big for a post, so put it onto a pastebin site with wgetpaste and post the link.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
LemurFromTheId
n00b
n00b


Joined: 22 Apr 2005
Posts: 64
Location: Finland

PostPosted: Sun Sep 29, 2019 1:48 pm    Post subject: Reply with quote

NeddySeagoon wrote:
trae,

When you launch portage as root, it tries to do as little as possible as root and drops to using the portage user wherever possible.
FEATURES can enable a whole list of assorted sandboxes to stop poor quality ebuilds doing things they are not supposed to.
The default settings should be good.

Thanks, I'll try to look into that stuff more closely. I'm using the default settings, though.

NeddySeagoon wrote:
Please post the entire build log for nvidia-drivers and the output of
Code:
emerge --info

The build log will be too big for a post, so put it onto a pastebin site with wgetpaste and post the link.

I already posted them, at the bottom of the first post :) Thanks for the "wgetpaste" tip though, i was not aware of that!

trae wrote:
emerge --info: https://controlc.com/45c8773f
build.log: https://controlc.com/b6d70bd3
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44202
Location: 56N 3W

PostPosted: Sun Sep 29, 2019 2:04 pm    Post subject: Reply with quote

trae,

emerge --info:
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"


Anything with sandbox in its name is a candidate for turninc off, as is userpriv.
Only do it on a per package package basis as they are all good safety measures.

Portage can remember per package settings, so you don't have to.

The build log says
Code:
 * Package:    x11-drivers/nvidia-drivers-435.21
 * Repository: gentoo
 * Maintainer: jer@gentoo.org
 * USE:        X abi_x86_64 acpi amd64 driver elibc_glibc kernel_linux kms multilib tools userland_GNU
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
...
so that's the FEATURES to poke at first.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
LemurFromTheId
n00b
n00b


Joined: 22 Apr 2005
Posts: 64
Location: Finland

PostPosted: Sun Sep 29, 2019 3:05 pm    Post subject: Reply with quote

NeddySeagoon,

you are a hero and your place will be where heroes have their final resting place! :D

I tried removing those sandboxes from the picture, but what did the trick was:
Code:
FEATURES="-userpriv"

(And yes, I already commented it out - I'll only use it if I have to.)

In hindsight, I should've realised this sooner from reading man make.conf, but I was confused on how FEATURES actually works, and as I said, I only really understood half of what I was reading. Been away from Gentoo for way too long.

The important part here is that the problem has been circumvented. While i still don't know why the problem exists in the first place (and why now, when it didn't just a few days ago), at least I now have a way to rebuild the module when I need to. Thank you!
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14394

PostPosted: Sun Sep 29, 2019 4:17 pm    Post subject: Reply with quote

Most likely, you built the kernel as root (which you shouldn't do), and root has a restrictive umask (which is good for security, but can get in the way). The umask would have caused the files generated by the build not to be world readable, so when Portage drops to the unprivileged user, it cannot open them. The quick fix is to make the generated files world-readable. The easy solution going forward is to set a permissive umask (such as 022) when building the kernel as root. The good fix is not to build the kernel as root, and to ensure that the user who does build it makes it readable to Portage. In the final case, you must also configure Portage so that ebuilds can find the out-of-tree built files, since they often want to inspect your kernel configuration and other generated files.
Back to top
View user's profile Send private message
LemurFromTheId
n00b
n00b


Joined: 22 Apr 2005
Posts: 64
Location: Finland

PostPosted: Sun Sep 29, 2019 4:54 pm    Post subject: Reply with quote

Hu wrote:
Most likely, you built the kernel as root (which you shouldn't do), and root has a restrictive umask (which is good for security, but can get in the way). The umask would have caused the files generated by the build not to be world readable, so when Portage drops to the unprivileged user, it cannot open them. The quick fix is to make the generated files world-readable. The easy solution going forward is to set a permissive umask (such as 022) when building the kernel as root. The good fix is not to build the kernel as root, and to ensure that the user who does build it makes it readable to Portage. In the final case, you must also configure Portage so that ebuilds can find the out-of-tree built files, since they often want to inspect your kernel configuration and other generated files.

I may have had 077 umask earlier when I was copying config files (.zshrc and such) from older Linux installations, but I'm now using 022, and I believe that's how I built the kernel as well. Not absolutely sure, though, I ran a chmod -R on it at some point while trying to find a solution (didn't help).

In any case, why is building the kernel as root a bad thing? That's what the Handbook suggests, and also the wiki pages dealing with kernel and its configuration. Is there a guide or a discussion thread somewhere on how to setup Portage for user kernel compilation? As you said, a lot of ebuilds seem to need access to kernel configuration.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14394

PostPosted: Sun Sep 29, 2019 6:36 pm    Post subject: Reply with quote

The kernel does not need root to compile successfully. The kernel is a large and complex project, with a correspondingly complicated build system. Root is very powerful, and dangerous if wielded improperly. Thus, wherever you can avoid root without substantial inconvenience, you should. I don't use any packages that expect to inspect the kernel configuration, but if I remember correctly, it is sufficient to set in the Portage environment the same variables you set in the kernel build. I think $KBUILD_OUTPUT is required to match between the two.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44202
Location: 56N 3W

PostPosted: Sun Sep 29, 2019 7:28 pm    Post subject: Reply with quote

LemurFromTheId,

One kernel release had a bug that wiped a large chunk of the filesystem.
It might even have tried to remove everything.

You really don't want to take the risk of being root unless you really have to.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum