This is basically the same thing as reported in bug 4615 and bug 5809 and it's obviously not fixed yet. I'm using a vanilla 2.4.18 from kernel.org and gcc 2.95.3, currently rp-pppoe-3.4 is installed and I had no problem installing that. I will post my kernel configuration, the log file and the output of lsmod as requested in the other two bugs. Below are the last lines of emerge -u rp-pppoe: strip: /var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe-wrapper /var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe /var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe-server /var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe-relay /var/tmp/portage/rp-pppoe-3.4-r1/image/usr/sbin/pppoe-sniff >>> Completed installing into /var/tmp/portage/rp-pppoe-3.4-r1/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-rp-pppoe-3.4-r1-11433.log" open_wr: /proc/sys/kernel/tainted open_wr: /proc/sys/kernel/tainted open_wr: /proc/sys/kernel/tainted --------------------------------------------------------------------------------
Created attachment 4552 [details] Output of lsmod
Created attachment 4553 [details] The log file generated by emerge -u rp-pppoe
Created attachment 4554 [details] Kernel configuration
Update: I did some experimenting and the access violations do not occur when I taint the kernel (either by loading a non-free module such as ppp_deflate or via echo 1 > /proc/sys/kernel/tainted) or modprobe pppoe before emerging. They do occur when I untaint the kernel (echo 0 > /proc/sys/kernel/tainted) or modprobe pppox (which is needed by pppoe) and make sure that pppoe is not loaded. In either case pppoe and pppox are loaded after the emerge.
attach this stuff too please: (1) `emerge -u rp-pppoe >& emergelog` (2) `strace -f -s 4096 emerge -u rp-pppoe >& stracelog`
Created attachment 4564 [details] Output of emerge -u rp-pppoe >& emergelog
The output of strace -f -s 4096 emerge -u rp-pppoe >& stracelog is 16MB and even gzip'ed it is too big for bugzilla, so I uploaded the compressed file to http://www.informatik.hu-berlin.de/~ploetz/misc/stracelog.gz (1.5MB)
OK The bug is easy to trace : it comes from the modprobing of modules being done during the configure process. (It might sound strange as the sandbox violation occurs at the end of the emerging, yet it does : stopping the emerging with ctrl-c just after the configuration make sandbox complain immediately of a sandbox violation...) These tests are stupid since : if the configure script detects that everything is present to use kernel mode pppoe, it won't build the necessary plugin anyway because it needs the sources for pppd under hand... (And if it fails, it won't prevent him from building the plugin anyway, he will just complain !) I don't know if kernel mode pppoe is needed (I suppose not, and the two user space modes of rp-pppoe, standard async, or sync are certainly enough, from what I read, kernel mode pppoe should be useful in a pppoe server, not a client...) Anyway, modifying rp-pppoe ebuild to enable the building of the rp-pppoe kernel mode plugin is a little painful, and not worth the trouble right now. The easiest fix would be to comment out the modprobe commands in the configure script. That's all... I'll attach a slightly modified ebuild. (No use to change the revision.)
Created attachment 4651 [details] The ebuild
Humm... There is something strange still... The modules do get loaded anyway (I guess I should have patched configure.in too) but then they do not create sandbox violation... Does it work for you, such as it is ? A bit weird IMO...
Yes, the corrected ebuild compiles successfully and the access violation is gone. Thanks for the fix! (I can't currently test the PPPoE-connection, but I can see no reason why it shouldn't work.)
nice work :)
Good news... My patch seems to work for everyone... According to bug 9089, the sandbox violation was seen too by those who built PPP, PPPoE in the kernel, not as modules. And indeed, I was able to reproduce the violation this way. (As in every other case, the second emerging of rp-pppoe has ALWAYS worked without a sandbox violation.) I absolutely have no idea why it does work in this second case (How could the modprobing of non-existent modules 'taint the kernel' ?) and was so surprised from the resolution of bug 9089 I wanted to test it myself... The fact is it worked just fine (the first time of course) Pierre-Henri Jondot (not a little proud of having solved a four months old bug :)
committed