emerge of nvidia-drivers-1.0.8762-r1 (probably also other versions) under kernel 2.6.18-mm1 resulted in a sandbox violation. ACCESS DENIED unlink: /usr/src/linux-2.6.18-mm1/astest11374.out rm: cannot remove `astest11374.out': Permission denied -------------------------- ACCESS VIOLATION SUMMARY -------------------------- LOG FILE = "/var/log/sandbox/sandbox-x11-drivers_-_nvidia-drivers-1.0.8762-r1-11140.log" open_wr: /usr/src/linux-2.6.18-mm1/astest11374.out unlink: /usr/src/linux-2.6.18-mm1/astest11374.out ------------------------------------------------------------------------------ main line kernel up to 2.6.18 is working. Reproduce: emerge nvidia-kernel under 2.6.18-mm1 Discussion & Solution: 2.6.18-mm1 introduces a certain test in scripts/Kbuild.include. This test ("as-instr") creates a temporary file in the kernel source directory. (see -mm patch x86_64-mm-detect-cfi.patch) Due to sandbox restrictions this is forbidden. 1. disable sandbox is okay in this case, as file is created by kernel and temporary. Or 2. comment out lines in containg the "as-instr" test in scripts/Kbuild.include. (Not sure about impact of this) NOTE: Probably other external built kernel modules are affected of this, because of using the KBuild system.
I can confirm that other kernel-modules are also affected by this. Been having the same problem with my wireless-drivers...
Created attachment 98519 [details, diff] Patch for fixing sandbox violations when compiling external modules for 2.6.18-mm1 This patch send the output of AS to /dev/null instead of a file which isn't used and later removed... Tested and working with nvidia-drivers
I can confirm this on -mm1, -mm2, and -mm3 as well. I created a similar patch for these kernels and the build is OK - however I have only actually tested running the -mm2, and haven't been any major problems with this kernel in 5 days of uptime.
Has anyone contacted upstream about this?
Yes I already did. The maintainer of Kbuild system is looking into it.
*** Bug 150985 has been marked as a duplicate of this bug. ***
Suggest changing topic, happens with anything newer than .18 - so, .19 prepatches are also affected sth like "with >= 2.6.18-mm1" ;-)
Any news from upstream on this? I noticed that 2.6.19-rc1 is affected :(
Indeed it is. No further response from upstream until now. I suggest waiting for -rc2 and possibly remind again. S.Ravnborg said there are other places in kernel similar to the described one. So maybe he's checking all of them.
2.6.19-rc2 is also affected, so i guess it was not fixed
*** Bug 151456 has been marked as a duplicate of this bug. ***
*** Bug 151750 has been marked as a duplicate of this bug. ***
*** Bug 151913 has been marked as a duplicate of this bug. ***
Created attachment 100051 [details, diff] as-instr-sandbox-fix-2.6.19_rc2-mm1.patch This is an updated patch that applies to 2.6.19_rc2-mm1; they changed the function to use mktemp (1) to make the temporary file now, instead of just not having one...
I tried the patch but it doesn't work with mm-sources-2.6.19_rc2-r1. vmware-modules denied to be compiled!!!
linux-2.6.19_rc2-mm2 still has the same bug
The patch for 2.6.18-mm1 works fine for mainline 2.6.19-rc2, too. The mktemp change didn't make it there yet. Unfortunately, there are no new comments in the LKML thread on this (http://groups.google.com/group/linux.kernel/browse_thread/thread/26c390ec5ee7c9e1/e27f33d4c2fd1f09); maybe the patch creators (Jan Peter den Heijer for 2.6.18-mm1 and 2.6.19-rc* mainline, Calvin Walton for 2.6.19-rc2-mm1) should post their patches directly there? Talking about a solution there is nice (dsd already did this), but submitting a ready-to-apply patch usually has a better chance to be included in the kernel.
The problem with submitting these patches is they do not actually solve the issue at hand - the code that was added was clearly specifically designed to be a failure log (it writes the output of a test to a file, then deletes the file if the test was successful). They are merely workarounds of the issue, specific to sandbox. This could probably be dealt with properly by modifying the patch to change output to somewhere in $PWD instead of /dev/null - (hopefully) writing the log to the work directory instead of the illegal (/usr/src/linux-version) directory. Though I admit I'm not familiar with the internals of the kbuild system, except as far as hacking together the /dev/null fix in the first place. I'll try this method out later, when I have more time.
*** Bug 152893 has been marked as a duplicate of this bug. ***
Nick, I disagree (comment #18). The astest*.out files are being deleted unconditionally, they cannot be examined later anyways. Up to now I have not seen a reasonable argument for not using -o /dev/null at all. Besides this, your idea (storing the tmp files in a better place than the kernel tree) has already been implemented [1], but this implementation is broken currently (see my LKML post on this [2]). Hopefully this makes it into the mainline tree before 2.6.19 gets released... [1]http://www.kernel.org/git/?p=linux/kernel/git/smurf/linux-trees.git;a=commit;h=51a4c9f79252752b82bc8cf6d4a856bbb81488c4 [2]http://groups.google.com/group/linux.kernel/browse_thread/thread/e55fd55506fbe840/2a7a69dbcc78232a
Okay, now I know the reason why they don't use -o /dev/null: "Because then when the compilation runs as root some as versions will delete /dev/null on a error. This has happened in the past." (Andi Kleen in http://groups.google.com/group/linux.kernel/browse_thread/thread/e55fd55506fbe840/2a7a69dbcc78232a?tvc=2#msg_96d24319838d3868)
Okay, so if neither /dev/null nor the current solution work, what about Nick Bowler suggestion in comment #18, $PWD that is. I think this solution would be relatively clean and expect it to be working.
Daniel, that's what's in the mainline githead ATM, it uses -o astest$$.out, ie. writes to the CWD (cf. http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=4f5ff19b992b1f8a8db6f28a96cbace409db3baa;hb=209ad53bc19667a128d9c51beba873a5c62bff6e;f=scripts/Kbuild.include). We rather need to get a path to the external module build tree ($(build-dir)? Unfortunately this isn't defined yet when scripts/Kbuild.include is being included in the main kernel Makefile, this would need to be changed, too...) -- or just do what the -mm implementation does: write to $TMPDIR (or /tmp if $TMPDIR is empty).
Is using $(M) practical?
No need to make unrelated bugs depend on this one.. we know that all external modules will fail with this problem until it is fixed
2.6.19-rc4-mm1 still fails. I tested with vmware-modules.
Hamlet, without getting details on how vmware-modules "fail" for you, I can just guess this is unrelated to this bug. There's a separate bug report on this (bug #152322).
Well, I tested also with rtl8187. Both failed same way as before, when I tested with 2.6.18-mm1. Already deleted the kernel. Next time, I will post the error message as well. Sorry.
I just successfully emerged nvidia-drivers-1.0.9626 against an unpatched 2.6.19-rc4-mm1 with no violations. Kernel boots and X starts. Portage 2.1.2_rc1-r2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.19-rc4-mm1 x86_64) ================================================================= System uname: 2.6.19-rc4-mm1 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.6 Last Sync: Thu, 02 Nov 2006 18:30:01 +0000 ccache version 2.4 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d/binutils /etc/env.d/gcc /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="ftp://mirror.datapipe.net/gentoo" LANG="en_CA.UTF-8" LINGUAS="en ja" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/xfce44rc1" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X a52 aac aalib acpi alsa audiofile bash-completion berkdb bitmap-fonts bzip2 cairo cdr cgi cjk cli cracklib cups curl dmx dri dts dvd dvdr dvdread elibc_glibc emboss encode exo expat fam fastcgi fbcon ffmpeg fifo flac fontconfig fortran gd gdbm gif glitz glut gmp gpm gstreamer gtk gtk2 gtkhtml guile howl icecast iconv idn imagemagick imlib input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg jpeg2k junit kernel_linux lcms libcaca libg++ linguas_en linguas_ja lua mad matroska mikmod mng mouse mozilla mp3 mpeg musepack mysql ncurses nls nptl nptlonly nvidia ogg openal opengl pam pcre perl php png posix pppd pulseaudio python quicktime readline reflection ruby samba sdl session speex spell spl ssl startup-notification svg sysfs tcpd tetex theora thunar-vfs tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_nvidia video_cards_tdfx video_cards_vesa vorbis x264 xine xinerama xml xml2 xorg xpm xscreensaver xv xvid xvmc zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
OK, then I will download mm patch again. Maybe I made a mistake, or both vmware-modules and rtl8187 have some issue. I will post the result later, maybe next week. Thank you Nick for the info.
*** Bug 154478 has been marked as a duplicate of this bug. ***
*** Bug 154820 has been marked as a duplicate of this bug. ***
*** Bug 155157 has been marked as a duplicate of this bug. ***
I guess this is still not solved with 2.6.19-rc6?
True.
*** Bug 155638 has been marked as a duplicate of this bug. ***
*** Bug 155863 has been marked as a duplicate of this bug. ***
*** Bug 156264 has been marked as a duplicate of this bug. ***
*** Bug 156412 has been marked as a duplicate of this bug. ***
(In reply to comment #34) > I guess this is still not solved with 2.6.19-rc6? > it's not
Fixed in gentoo-sources-2.6.19 (genpatches-2.6.19-1)
So vanilla sources are not going to work?
No, we don't patch that kernel, sorry. However (assuming no problems or objections appear) the patch will be merged upstream sometime soon.
So you did send the patch to the LKML already? Can you give me a hint, so i find that posting and the reactions?
(In reply to comment #44) > So you did send the patch to the LKML already? Can you give me a hint, so i > find that posting and the reactions? > http://lkml.org/lkml/2006/9/27/165
I didn't send the latest patch on yet, I am giving it a few days of testing in gentoo-sources first. You can find it in the genpatches-base tarball. http://dev.gentoo.org/~dsd/genpatches
*** Bug 156807 has been marked as a duplicate of this bug. ***
I have got the same problem (ACCESS VIOLATION ...) for app-misc/lirc-0.8.0-r7 after emerging sys-kernel/gentoo-sources-2.6.19. alsa-driver and nvidia-drivers were installed without problems. Must I report new lirc-related bug?
(In reply to comment #48) > Must I report new lirc-related bug? > I did that and it was marked a duplicate of this bug, comment 47.
*** Bug 156839 has been marked as a duplicate of this bug. ***
(In reply to comment #41) > Fixed in gentoo-sources-2.6.19 (genpatches-2.6.19-1) I'm still getting the same sandbox violation with lirc-0.8.0-r7 and gentoo-sources-2.6.19. I re-emerged gentoo-sources to make sure I had the latest patches but it's still the same.
*** Bug 156889 has been marked as a duplicate of this bug. ***
*** Bug 150548 has been marked as a duplicate of this bug. ***
*** Bug 156899 has been marked as a duplicate of this bug. ***
*** Bug 156991 has been marked as a duplicate of this bug. ***
*** Bug 156994 has been marked as a duplicate of this bug. ***
*** Bug 157120 has been marked as a duplicate of this bug. ***
(In reply to comment #49) > (In reply to comment #48) > > Must I report new lirc-related bug? > > > I did that and it was marked a duplicate of this bug, comment 47. As far i can see it's no longer a duplicate (but bugzilla doesn't remove the comments), see bug 156807, should be solved by now.
(In reply to comment #21) > Okay, now I know the reason why they don't use -o /dev/null: "Because then when > the compilation runs as root some as versions will delete /dev/null on a error. > This has happened in the past." in case it makes our patch simpler, the Gentoo toolchains have all been fixed to handle this properly (both binutils and gcc had this "feature")
*** Bug 157172 has been marked as a duplicate of this bug. ***
*** Bug 103100 has been marked as a duplicate of this bug. ***
This bug doesn't seem to be fixed, even with 2.6.19-r1 I am still getting sandbox violations with pcmcia-cs --------------------------- ACCESS VIOLATION SUMMARY ---------------------------LOG FILE = "/var/log/sandbox/sandbox-sys-apps_-_pcmcia-cs-3.2.9_pre20050614-27835.log" open_wr: /usr/src/linux-2.6.19-gentoo-r1/astest27936.out unlink: /usr/src/linux-2.6.19-gentoo-r1/astest27936.out open_wr: /usr/src/linux-2.6.19-gentoo-r1/astest27940.out unlink: /usr/src/linux-2.6.19-gentoo-r1/astest27940.out open_wr: /usr/src/linux-2.6.19-gentoo-r1/astest27947.out unlink: /usr/src/linux-2.6.19-gentoo-r1/astest27947.out open_wr: /usr/src/linux-2.6.19-gentoo-r1/astest27951.out unlink: /usr/src/linux-2.6.19-gentoo-r1/astest27951.out --------------------------------------------------------------------------------
Then file a bug for pcmcia-cs. Some packages such as lirc and linux-wlan-ng-modules have needed additional fixing
bugs do get filed for other packages -- and immediate closed as a dupe of this bug. someone please make up their mind.
In general the bugs are dupes, and only in exceptional cases is the package broken. If there is one for pcmcia-cs just reopen it.
Created attachment 103496 [details, diff] linux-info.eclass patch This patch against /usr/portage/eclass/linux-info.eclass is needed in some situations. I'd be really grateful for any testing here, including if things are currently working for you. Apply this patch, then compile a few of your favorite modules against gentoo-sources-2.6.19, and post success/failure reports here.
(In reply to comment #66) > Created an attachment (id=103496) [edit] > linux-info.eclass patch > > against gentoo-sources-2.6.19, and post success/failure reports here. > It worked for me: gentoo-sources-2.6.19-r1 with these modules: =media-tv/v4l-dvb-hg-0.1-r2 =app-emulation/kqemu-1.3.0_pre9 =app-misc/usbirboy-0.2.1-r1 =media-video/em84xx-modules-0.2.1 =x11-drivers/nvidia-drivers-1.0.9631 =media-sound/alsa-driver-1.0.14_pre20061130
added that patch to portage
*** Bug 157610 has been marked as a duplicate of this bug. ***
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=347a00fb4ad2200f8f8331f8b366b1d84eff577d should finally resolve the problem for vanilla kernels from 2.6.20 on.
*** Bug 157985 has been marked as a duplicate of this bug. ***
(In reply to comment #70) > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=347a00fb4ad2200f8f8331f8b366b1d84eff577d > should finally resolve the problem for vanilla kernels from 2.6.20 on. Downloaded patch, applied it to 2.6.19.1 and it works perfect! Hooray!
*** Bug 158225 has been marked as a duplicate of this bug. ***
(In reply to comment #72) > (In reply to comment #70) > > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=347a00fb4ad2200f8f8331f8b366b1d84eff577d > > should finally resolve the problem for vanilla kernels from 2.6.20 on. > > Downloaded patch, applied it to 2.6.19.1 and it works perfect! > Hooray! > can we merge this as a standard patch into the vanilla kernel, applied by portage?
(In reply to comment #74) > can we merge this as a standard patch into the vanilla kernel, applied by > portage? If you mean patching Gentoo's vanilla-sources then no, people expect it to be indentical to kernel.org's release. If you mean getting the patch into kernel.org's kernel then that's already done; the next version (2.6.20) will include it.
(In reply to comment #74) > can we merge this as a standard patch into the vanilla kernel, applied by > portage? It's _vanilla_, thats a codename for 'none of our patches, only what upstream provide' ;) If you don't like it, use gentoo-sources
Please note that vanilla-sources is an unsupported kernel, if there are non-ebuild bugs in it (of any kind) we will not fix it.
(In reply to comment #74) > can we merge this as a standard patch into the vanilla kernel, applied by > portage? Just be patient a few days, 2.6.19.2 will contain the patch, too (thanks to dsd). http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=blob;h=15afd3efc50a45689a8cb1160f9a0e66727d561f;hb=b0b06dc5239c4105d49c81291bd4d11e586384a3;f=queue-2.6.19/kbuild-don-t-put-temp-files-in-source.patch
*** Bug 158238 has been marked as a duplicate of this bug. ***
*** Bug 158532 has been marked as a duplicate of this bug. ***
*** Bug 159150 has been marked as a duplicate of this bug. ***
On amd64, I get with any 2.6.19 kernel I tried (including the most current hardened-sources-2.6.19-r3 which runs fine with x86) always the same sandbox violation. I guess the patch had "only" fixed the x86 variant, and amd64 uses another place to create the tempfile (apparently, the tempfile also has another name): With all ebuilds containing kernel modules, I get the error: --------------------------- ACCESS VIOLATION SUMMARY ---------------- LOG FILE = "/var/log/sandbox/[... snipped ...]" open_wr: /usr/src/linux-2.6.19-hardened-r3/-.gcda open_wr: /usr/src/linux-2.6.19-hardened-r3/-.gcda -------------------------------------------------------------------------------- Of course, FEATURES=-usersandbox avoids the problem. I am not sure whether I should open a new bug, because I am not able to reopen this one...
(In reply to comment #82) > On amd64, I get with any 2.6.19 kernel I tried (including the most current > hardened-sources-2.6.19-r3 which runs fine with x86) always the same sandbox > violation. >... I have exactly the same problem, every kernel >2.6.18.x still produces sandbox violations when emerging external modules. Well, i'm also on ~amd64.
Please file a new bug for the gcda violation. It's not related to the bug described here.
*** Bug 159714 has been marked as a duplicate of this bug. ***
*** Bug 159905 has been marked as a duplicate of this bug. ***
*** Bug 160078 has been marked as a duplicate of this bug. ***
*** Bug 160395 has been marked as a duplicate of this bug. ***
*** Bug 160511 has been marked as a duplicate of this bug. ***
Regarding Comment #70 , is there somewhere else I can get that file, I have tried for days to get it and am always told the server load is too high. Also, I'm curious, this bug is marked fix but from what I can tell it's not? Just a thought. Cheers!
Like ftp://ftp.muni.cz/pub/linux/kernel/v2.6/testing/linux-2.6.20-rc3.tar.bz2 dated Jan 1 2007?
(In reply to comment #90) > I'm curious, this bug is marked fix but from what I can tell it's not? Just a > thought. gentoo-sources-2.6.19 is fixed, hence the bug is closed.
(In reply to comment #90) > Regarding Comment #70 , is there somewhere else I can get that file, I have > tried for days to get it and am always told the server load is too high. http://overlays.gentoo.org/svn/dev/nelchael/sys-kernel/nelchael-sources/files/2.6.19-modules.patch
2.6.19.2 will be out Monday or Tuesday, and it'll contain the fix. Patience... ;-)
*** Bug 167785 has been marked as a duplicate of this bug. ***
vanilla 2.6.22.x is still failing for me. anyone has the same issue?
