as normal: # emerge system then md5 ;-) and at some point: installhtml /pod/xxx cannot resolve [xxx] then i get this: *********************************** Acces Violation Sumary open_wr: /usr/share/locate/locate.alias open_wr: /usr/share/locate/locate.alias *********************************** and i can't keep emerging system thanks Reproducible: Always Steps to Reproduce: 1.chroot 2.emerge system 3. Actual Results: allways the same result Expected Results: uhmmm...normal isntall?
Is this locate.alias or locale.alias? If it's locale, could you please include the locale-related parts of the output of "printenv"? Also, please indicate which version of the perl ebuild you are trying to install.
which base distro do you use ?
Robert: Sorry, it was locale: open_wr: /usr/share/locale/locale.alias open_wr: /usr/share/locale/locale.alias Martin: what do you mean with base distro? this is my "printenv": INFODIR=/usr/share/info MANPATH=/usr/share/man:/usr/local/share/man HOSTNAME=cdimage TERM=linux SHELL=/bin/bash USER=root PAGER=/usr/bin/less PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/opt/bin MAIL=/var/mail/root INPUTRC=/etc/inputrc PWD=/ EDITOR=/usr/bin/nano PS1=\[\033[01;31m\]\h \[\033[01;34m\]\W \$ \[\033[00m\] CXX=g++ HOME=/root SHLVL=2 LOGNAME=root CVS_RSH=ssh LESSOPEN=|lesspipe.sh %s CC=gcc _=/usr/bin/printenv
*** Bug 16340 has been marked as a duplicate of this bug. ***
I can't reproduce this on a clean stage 2 install. Can people affected by this problem give more information about their systems, such as USE variable settings, and any locale-specific customization they are doing? We need to find the common thread among people with the problem.
I am experiencing this as well, I used the gentoo-basic-x86-1.4_rc2.iso, build stage 1 no problems. I ran 'emerge sync' this morning after upgrading portage. I haven't set any locale specific settings as of yet. From make.conf USE="-march=pentium4 -O3 -pipe -mfpmath=sse -msse -msse2 -mmmx" MAKEOPTS="-j2" ACCEPT_KEYWORDS="~x86" Let me know if you need any more info.
Maybe the easiest way to get information from affected systems is "emerge info".
Created attachment 8724 [details] emerge info
Created attachment 8727 [details] emerge info Same happened to me during an emerge -e
Created attachment 8730 [details] emerge info Hate to me too, but... Any workarounds?
Has there been any progress on this? Kind of a show stopper for me right now :(
I'm not seeing any similarities among your CFLAGS. You all have USE="nls", but so do I and I can't reproduce the problem. Can you try upgrading portage first to 2.0.47-r6 (using emerge -u --nodeps portage, if necessary), and enabling the userpriv and usersandbox FEATURES in your make.conf, and seeing if the problem persists? Sorry, but until I can reproduce the problem I'm grasping at straws.
I am getting the same from a stage_1 from GRP CD 1.4_RC2 bootstrap fine then did export CONFIG_PROTECT="-*" export USE="-* bootstrap build" emerge portage unset USE all this goes fine then do emerge system and get this --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-perl-5.8.0-r9-18649.log" open_wr: /usr/share/locale/locale.alias open_wr: /usr/share/locale/locale.alias -------------------------------------------------------------------------------- my CFLAGS are march & mcpu ="athlon-xp pipe 03 -fomit-frame-pointer" ACCEPT_KEYWORDS="~x86" MAKEOPTS=j2 Sorry cant do printenv not at home pc at moment could this possibly be something to do with this post? http://forums.gentoo.org/viewtopic.php?t=15572 I have not tried from a stage2 yet only from stage 1 can anyone confirm that starting from a stage2 resolves this issue ?
The portage upgrade worked for me. I noticed that it started with gcc-3.2.2 before it went to perl on the emerge system, and I'm not sure if that had anything to do with it either. Thanks for the help. :)
Just a note the upgrade of portage borked my make.conf and I build everything with the default CFLAGS and ACCEPT_KEYWORDS.
i am getting the same error _____________________________________________________________________ t/pod/pod2usage......................ok t/pod/poderrs........................ok t/pod/podselect......................ok t/pod/special_seqs...................ok t/x2p/s2p............................ok All tests successful. u=1.21 s=0.38 cu=110.15 cs=42.34 scripts=667 tests=68503 make[2]: Leaving directory `/var/tmp/portage/perl-5.8.0-r10/work/perl-5.8.0' make[1]: Leaving directory `/var/tmp/portage/perl-5.8.0-r10/work/perl-5.8.0' --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-perl-5.8.0-r10-5307.log" open_wr: /usr/share/locale/locale.alias open_wr: /usr/share/locale/locale.alias --------------------------------------------------------------------------------
sorry forgot to give a few details this is basically a fresh install running "~x86" , i havent specified any USE variables and my CFLAGS are -march=athlon-xp -O3 -pipe , so doesnt get more boring than that i'm afraid. ciao
couple of things more, i had in the make.conf FEATURES="ccache userpriv usersandbox" .... with these the build fails with the access violation.... so i removed "usersandbox" and it compiles ... then to test it a bit further i removed "userpriv" also leaving only "ccache" and the build completes without the access violation. looks like compiles with the FEATURES= commented out with ti enabled and using "ccache" "ccache userpriv" but not when "usersandbox" is included ciao
I can confirm that. Had the same sandbox violation like everyone else --> commented out FEATURES="ccache usersandbox userpriv" in /etc/make.conf --> Perl compiled without problems.
I confirm that changing the FEATURES variable to remove "ccache","usersandbox" and userpriv" fixes the access violation problem. I had 1.4 RC_2 and did a emerge -up world and the perl build would fail with the access violation message, even though locale.alias had proper access rights. I used the following settings: #USE= (default) CHOST="i686-pc-linux-gnu" CFLAGS="-mcpu=athlon-xp -O3 -pipe"
*** Bug 16939 has been marked as a duplicate of this bug. ***
*** Bug 18622 has been marked as a duplicate of this bug. ***
*** Bug 16637 has been marked as a duplicate of this bug. ***
I'm also experiencing this, both on my normal system and on the system I'm doing QA builds with experimental stages on.
I should note that I upped the severity of this bug because this is a serious showstopper for 1.4.
Okay, with a little bit of strace goodness and some discussion with rac on IRC, it seems like this is potentially a sandbox breakage. strace reports it as opening the file as read-only: 7484386:25577 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 Sandbox appears to think it's opening it for writing: open_wr: /usr/share/locale/locale.alias open_wr: /usr/share/locale/locale.alias Carpaski?
Created attachment 10247 [details] strace output for locale -a
Azarah, you're listed in the credits for libsandbox.c, so I'm CC'ing you in the hopes that someone familiar with sandbox can look at this... rac managed to track this down to `locale -a` in sandbox. strace shows that locale -a opens locale.alias read-only: 14307 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 but sandbox thinks it's opening it for writing: open_wr: /usr/share/locale/locale.alias and claims an access violation occured. I've attached the full strace output for locale -a.
Err. It would've helped if I hadn't closed that tab previously and not forgotten to CC Azarah the second time around. For Az's sake: I'm CC'ing you because you're listed in the credits for libsandbox.c and this is starting to look like a sandbox bug.
Problem is that for some reason locale fopen's locale.alias with mode 'rm'. ------------------------------------------------------- nosferatu root # grep fopen locale.log fopen("/usr/share/locale/locale.alias", "rm"ACCESS DENIED open_wr: /usr/share/locale/locale.alias nosferatu root # -------------------------------------------------------- I checked the source of locale, but it have fopen with mode 'r', so not sure where this comes into. Anyhow, here is a quick fix that I have commited to the source: --------------------------------------------------------- Index: libsandbox.c =================================================================== RCS file: /home/cvsroot/gentoo-src/portage/src/sandbox-1.1/libsandbox.c,v retrieving revision 1.3 diff -u -r1.3 libsandbox.c --- libsandbox.c 4 Dec 2002 00:51:30 -0000 1.3 +++ libsandbox.c 6 Apr 2003 08:55:23 -0000 @@ -1176,7 +1176,7 @@ static int before_syscall_open_char(const char* func, const char* file, const char* mode) { - if ((strcmp(mode, "r") == 0) || (strcmp(mode, "rb") == 0)) { + if ((strcmp(mode, "r") == 0) || (strcmp(mode, "rb") == 0) || (strcmp(mode, "rm") == 0)) { return before_syscall("open_rd", file); } else { return before_syscall("open_wr", file); -----------------------------------------------------------------
Robert, adding you if you might have a chance to track this some more, but it should be 'working' in next portage release.
Azarah, thanks for helping out here - the last 10% is always the hardest. As I read the fopen man page, it looks like there can be arbitrary characters extending the open mode. I think it would be nice to have a solution that will work in the future if other letters are added later. For example, "rx" is now theoretically a possibility (putting aside the issue of whether it makes any sense). Therefore, how about: if( mode[0] == 'r' && strrchr( mode, '+' ) == NULL ) as a check for the open mode?
Ok, so you cannot for instance pass "ra" or "rw" as mode?
Both according to the man page and the actual code in glibc 2.3.2, "ra" and "rw" would both effectively be "r". There is a first check on the first character of the mode. After that, there is a loop that looks for other characters. Neither 'a' nor 'w' are processed by that loop (they are both ignored), although '+' is.
The sandbox still seems to choke on open mode "rm" in portage 2.0.48pre2.
this is interesting because it happens for me too in 2.0.48_pre5
Is this still an issue? Can we figure out what needs fixing?
I still think that the approach in comment #33 of if( mode[0] == 'r' && strrchr( mode, '+' ) == NULL ) is more flexible than the last code I saw in libsandbox as of 48pre5, which explicitly allows 'rm' as a read-only mode. However, the bug as it currently stands is fixed in the current libsandbox, as far as I can tell.
yes, i can confirm that the latest portage 2.0.48 has this fixed, i guess it should of been fixed with _pre5, don't know why it didn't for me. hmm.. thanks to all you guys who tracked it down.
Portage 2.0.48 is out, should this be marked as fixed?
Fixed and stable for a while.
