Bootstrapping a new system, even bootstrap.sh gave sandbox errors. So did every package that I tried to merge while I used usersandbox. The example of emerging sandbox might work as a better example. The live cd gave me sandbox-1.2.11 and upgrading to sandbox-1.2.12 did not fix the problem. When I give FEATURES="- userpriv" and the non-usersandbox is used it works as expected. Reproducible: Always Steps to Reproduce: 1. FEATURES="-userpriv" emerge sandbox (to upgrade to latest version) 2. emerge sandbox Actual Results: 1. sandbox upgraded to sandbox-1.2.12, this works 2. emerge failed with ACCESS DENIED open_wr: /newroot/dev/vc/1 ACCESS DENIED open_wr: /newroot/dev/vc/1 >>> Unpacking source... >>> Unpacking sandbox-1.2.12.tar.bz2 to /var/tmp/portage/sandbox-1.2.12/work * Unpacking sandbox for ABI=default... >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-sys-apps_-_sandbox-1.2.12-27696.log" open_wr: /newroot/dev/vc/1 open_wr: /newroot/dev/vc/1 -------------------------------------------------------------------------------- Expected Results: Sandbox should have been re-emerged. Gentoo Base System version 1.6.13 Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r1, 2.6. 12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 Celeron (Coppermine) dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.59-r6 sys-devel/automake: 1.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: [Not Present] virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -mfpmath=sse -mmmx -msse -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -mfpmath=sse -mmmx -msse -O2 -pipe -fomit-frame- pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://mirror.gentoo.se http://distfiles.gentoo.org http://www. ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 apm arts avi bash-completion berkdb bitmap-fonts crypt cups eds emacs emboss encode foomaticdb gdbm gif gpm gstreamer gtk2 imlib jpeg libg++ libwww mad mikmod motif mp3 mpeg ncurses nls nptl nptlonly ogg oggvorbis pam pdflib perl png python quicktime readline sasl sdl spell ssl tcpd threads threadsonly truetype truetype-fonts type1-fonts unicode userlocales vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
*** Bug 105647 has been marked as a duplicate of this bug. ***
It is because /newroot/dev/ is not in the write allow list. Usually you bind mount /dev to the chroot before you chroot, so not sure what you are doing.
Could that be some part of the installation guide that I have missed? I don't remember reading anything about having to do it manually atleast.
Oh, well, they changed things a lot from when I last read it I guess. Any idea where the '/newroot/dev', especially the /newroot comes into the chroot ?
I found a forum post that seems relevant: <http://forums.gentoo.org/viewtopic-t- 370904.html>. Posts in that thread says unmounting /proc enables building. A link to wiki that talks about userpriv and ccache problems, bug #99120. Though, I did not have ccache installed when I bootstrapped.
*** Bug 105969 has been marked as a duplicate of this bug. ***
Sorry for the dup. Binding the /dev folder of the liveCD to the /dev folder of the croot environment 'mount -o bind /dev /mnt/gentoo/dev' solves the problem for me. Regards Ruben
Should this be assigned to the GDP for them to update the Handbook?
I think so, yes.
Created attachment 69749 [details] outside chroot /dev `ls -lR /dev` from outside the chroot on a system where this problem showed up
Created attachment 69750 [details] inside chroot And the same for inside the chroot
Not really showing anything. 'ls -lR /prog | grep newroot' before the bind mount maybe ?
GDP: It looks like we need to add the bind mount for /dev back into the Handbook.
What architectures? Does this apply for all methods or only bootstrap? Is this also true for installations made with Gentoo stages but unofficial installation CDs? What's the end result after the installation? No change or will we miss a few device files we need? When is the bind-mounting required? Just before the chrooting?
(In reply to comment #14) > What architectures? All. > Does this apply for all methods or only bootstrap? This would appear to only be necessary for stage1 installations. > Is this also true for installations made with Gentoo stages but unofficial installation CDs? I cannot answer this, as it would be dependent on the design of the CD. I would say it is likely. > What's the end result after the installation? > No change or will we miss a few device files we need? This is a good question. Would me miss the device creation in baselayout with this method? I honestly don't know the answer to that. Adding base-system to CC to see if they can give us an answer. > When is the bind-mounting required? > Just before the chrooting? Correct. I think we'll need to hold off on actually doing anything with this until we can determine the possible implications of adding this into the Handbook. Does anyone know why it was removed in the first place?
(In reply to comment #15) > > When is the bind-mounting required? > > Just before the chrooting? > > Correct. > > I think we'll need to hold off on actually doing anything with this until we can > determine the possible implications of adding this into the Handbook. Does > anyone know why it was removed in the first place? > Might be because not using devfs anymore ? It should not have any implications, just strange that it happens .. ie, what changed with the /newroot magic since it last worked ?
(In reply to comment #16) > (In reply to comment #15) > > > > When is the bind-mounting required? > > > Just before the chrooting? > > > > Correct. > > > > I think we'll need to hold off on actually doing anything with this until we can > > determine the possible implications of adding this into the Handbook. Does > > anyone know why it was removed in the first place? > > > > Might be because not using devfs anymore ? This bit is to the why we not doing it anymore question. > It should not have any implications, > just strange that it happens .. ie, what changed with the /newroot magic > since it last worked ? > The implications and possible why question ...
(In reply to comment #15) > This would appear to only be necessary for stage1 installations. I was doing a stage3 install when I ran into the bug and az had me post my /dev above.
I can't seem to find why it was removed or inserted (I can track it with annotate in CVS, but the bind-mounting has moved across various files so it would take some time). I do know that every time it was changed, we got a report about a situation where it didn't work. It mostly was regarding Knoppix usage though which is why we moved the Knoppix instructions to the alternative installation guide.
If I were to venture a guess, it would be because Knoppix uses a 2.4 kernel and we are using 2.6 kernels. We also are using udev versus Knoppix using devfs, which means the device nodes would all be named differently, causing failures for users using Knoppix.
(In reply to comment #20) > If I were to venture a guess, it would be because Knoppix uses a 2.4 kernel and > we are using 2.6 kernels. We also are using udev versus Knoppix using devfs, > which means the device nodes would all be named differently, causing failures > for users using Knoppix. Newer versions of knoppix use the 2.6 kernels by default. WORKSFORME?
I think the bind mount instructions need to be added back, then this should be resolvable.
mount -o bind /dev... is back
