| View previous topic :: View next topic |
| Author |
Message |
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
 Posted: Sun Jun 23, 2013 8:45 am Post subject: [Solved] Yet another problems with GCC, GLIBC and SANDBOX |
 |
|
I have a problem with gcc, glibc and sandbox very similar to several other post in the forum, with the difference that this is in an openvz kernel virtual container. All 3 of these build errors points to something that have to with 32bits not being right on this AMD64 box (although it's an Intel Q9400 cpu). I have searched both forum and bugzilla high and low but nothing suggested works, and now I should of course post emerge info, logs and all that stuff, but before I do this there is possibly another solution, which in such case I need some help with.
I have 4 other virtual containers, where surprisingly this problem never have occured and all compiles just fine, and the base system is basically the same on all of them. So could it work with copying some of the binaries from one of the working containers to the misbehaving one and in such case exactly which files do I need to copy?
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year.
Last edited by MoonWalker on Tue Jun 25, 2013 10:24 am; edited 1 time in total |
|
| Back to top |
|
 |
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Jun 23, 2013 10:34 am Post subject: |
|
|
| `emerge gentoolkit` and then copy the files `equery f gcc`, `equery f glib` and `equery f sandbox` give; or, you could use binpkgs as documented on http://wiki.gentoo.org/wiki/Binary_package_guide to bring over the whole packages. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 10:51 am Post subject: |
|
|
Thanks Tom,
but don't you mean `equery f glibc`?
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Jun 23, 2013 11:14 am Post subject: |
|
|
| Yes, small typo. Oh, as a side node, while we're talking about glibc: Make sure you don't replace glibc by a lower version or you can break the entire system. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 11:39 am Post subject: |
|
|
| TomWij wrote: | | Yes, small typo. Oh, as a side node, while we're talking about glibc: Make sure you don't replace glibc by a lower version or you can break the entire system. |
Yes, I am aware of that  However, another side note. I just realized that my /usr/portage dir is mounted in inside all my virtuals, so they all use the same tree, which means the default package dir is there as well. I figure there might be a problem if I build the binaries from host node and then use them in a virtual, or the other way around, right? But if I create them from within one virtual, it should be ok to use in another - as long as I stay away from use them on the host node, is that a correct assumption?
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Jun 23, 2013 11:49 am Post subject: |
|
|
| MoonWalker wrote: | | TomWij wrote: | | Yes, small typo. Oh, as a side node, while we're talking about glibc: Make sure you don't replace glibc by a lower version or you can break the entire system. |
Yes, I am aware of that However, another side note. I just realized that my /usr/portage dir is mounted in inside all my virtuals, so they all use the same tree, which means the default package dir is there as well. I figure there might be a problem if I build the binaries from host node and then use them in a virtual, or the other way around, right? But if I create them from within one virtual, it should be ok to use in another - as long as I stay away from use them on the host node, is that a correct assumption? |
Yes, your host might differ so that would indeed not be a good idea; doing it in a virtual instead and copying it to the other virtual is indeed the correct approach. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 12:01 pm Post subject: |
|
|
So let's see if I got this right, before I start to wreck my system.
If change path for PKGDIR dir inside one virtual (make.conf) and build binaries there. I can then in the problematic virtual, set same PKGDIR value in make.conf, copy the package dir from one virtual to the other (which would have to be done via the host node) and then utilize/install the new binaries from package dir on the problematic one?
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Jun 23, 2013 12:12 pm Post subject: |
|
|
| Yes, that is correct; make sure you pass --usepkgonly to emerge to ensure it uses the binary package and does not try to emerge it. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 1:36 pm Post subject: |
|
|
Ok some success,
glibc-2.17.0 installed OK
sandbox-2.6-r1 installed, BUT
| Code: | <<< dir /usr/share/doc/sandbox-2.6
>>> Regenerating /etc/ld.so.cache...
>>> Original instance of package unmerged safely.
>>> sys-apps/sandbox-2.6-r1 merged.
>>> Regenerating /etc/ld.so.cache...
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
/usr/portage/profiles/base/profile.bashrc: line 5: /dev/null: Permission denied
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
sh: /dev/null: Permission denied
* --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
* LOG FILE: "/var/log/sandbox/sandbox-8721.log"
*
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash -rcfile /usr/share/sandbox/sandbox.bashrc -c "/usr/lib64/portage/bin/misc-functions.sh" success_hooks
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh success_hooks
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh success_hooks
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash /usr/lib64/portage/bin/ebuild-ipc exit 1
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: sh -c uname -p 2> /dev/null
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: sh -c uname -p 2> /dev/null
* --------------------------------------------------------------------------------
|
and gcc even worse, which appears to depend on sandbox errors
| Code: | >>> Installing (3 of 3) sys-devel/gcc-4.7.3
* checking 1104 files for package collisions
1000 files checked ...
>>> Merging sys-devel/gcc-4.7.3 to /
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
/usr/portage/profiles/base/profile.bashrc: line 5: /dev/null: Permission denied
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
sh: /dev/null: Permission denied
* --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
* LOG FILE: "/var/log/sandbox/sandbox-8839.log"
*
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash -rcfile /usr/share/sandbox/sandbox.bashrc -c "/usr/lib64/portage/bin/misc-functions.sh" preinst_sfperms preinst_selinux_labels preinst_suid_scan
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh preinst_sfperms preinst_selinux_labels preinst_suid_scan
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh preinst_sfperms preinst_selinux_labels preinst_suid_scan
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash /usr/lib64/portage/bin/ebuild-ipc exit 1
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: sh -c uname -p 2> /dev/null
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: sh -c uname -p 2> /dev/null
* --------------------------------------------------------------------------------
!!! post preinst failed; exiting.
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
/usr/portage/profiles/base/profile.bashrc: line 5: /dev/null: Permission denied
* ACCESS DENIED: open_wr: /dev/null
/var/tmp/portage/sys-devel/gcc-4.7.3/temp/environment: line 4796: /dev/null: Permission denied
tar: Cowardly refusing to create an empty archive
Try `tar --help' or `tar --usage' for more information.
*
* Please include /usr/lib64/portage/pym/gcc-build-logs.tar.bz2 in your bug report
*
* ACCESS DENIED: open_wr: /dev/null
/var/tmp/portage/sys-devel/gcc-4.7.3/temp/environment: line 4801: /dev/null: Permission denied
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
sh: /dev/null: Permission denied
* --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
* LOG FILE: "/var/log/sandbox/sandbox-8867.log"
*
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash -rcfile /usr/share/sandbox/sandbox.bashrc -c "/usr/lib64/portage/bin/misc-functions.sh" die_hooks
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh die_hooks
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh die_hooks
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh die_hooks
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh die_hooks
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash /usr/lib64/portage/bin/ebuild-ipc exit 1
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: sh -c uname -p 2> /dev/null
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: sh -c uname -p 2> /dev/null
* --------------------------------------------------------------------------------
!!! FAILED preinst: 1
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
/usr/portage/profiles/base/profile.bashrc: line 5: /dev/null: Permission denied
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
sh: /dev/null: Permission denied
* --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
* LOG FILE: "/var/log/sandbox/sandbox-8905.log"
*
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash -rcfile /usr/share/sandbox/sandbox.bashrc -c "/usr/lib64/portage/bin/misc-functions.sh" die_hooks
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh die_hooks
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: /bin/bash /usr/lib64/portage/bin/misc-functions.sh die_hooks
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: /bin/bash /usr/lib64/portage/bin/ebuild-ipc exit 1
F: open_wr
S: deny
P: /dev/tty
A: /dev/tty
R: /dev/tty
C: sh -c uname -p 2> /dev/null
F: open_wr
S: deny
P: /dev/null
A: /dev/null
R: /dev/null
C: sh -c uname -p 2> /dev/null
* --------------------------------------------------------------------------------
>>> Failed to install sys-devel/gcc-4.7.3, Log file:
>>> '/var/tmp/portage/sys-devel/gcc-4.7.3/temp/build.log' |
So not ready to set subject to [Solved] quite yet. Also, I don't quite dare to fiddle either as I don't feel like I know what I'm doing...?
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 1:52 pm Post subject: |
|
|
By the way, I didn't copy the package dir from ok server, but emerged lightthpd to serve the files and then
PORTAGE_BINHOST="http://ok-server.xy/"
to pull the packages. To do that though, I had to change file/dir permissions on the server package dir, from "root:root" to "root:lighttpd" or I got a 403 request error. It's ok security wise as that server is not accessible from outside firewall anyhow.
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Jun 23, 2013 5:57 pm Post subject: |
|
|
| Asked around and received a suggestion on IRC (thanks to Pinkbyte): Did you mount a filesystem with noexec? Can we see the mount output? |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 10:37 pm Post subject: |
|
|
| TomWij wrote: | | Asked around and received a suggestion on IRC (thanks to Pinkbyte): Did you mount a filesystem with noexec? Can we see the mount output? |
noexec? I don't think so, but this is an openvz virtual container, which may make it a bit tricky and frankly I don't know if something noexec equivalent is at play here.
Just in case it matter, here is fstab from host node:
| Code: | # /etc/fstab: static file system information.
# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/fstab,v 1.12 2003/03/11 02:50:53 azarah Exp $
# <fs> <mountpoint> <type> <opts> <dump/pass>
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
/dev/sda1 /boot ext3 noauto,noatime 1 1
/dev/sda3 / ext3 noatime 1 2
/dev/sda2 none swap sw 0 0
/dev/sda5 /vz ext3 noatime 1 2
/dev/sda6 /tmp ext2 noatime 1 2
/dev/sr0 /mnt/cdrom iso9660 noauto,ro 0 0
# NOTE: The next line is critical for boot!
none /proc proc defaults 0 0
|
in a container it looks like this:
| Code: | # cat /etc/fstab
proc /proc proc defaults 0 0 |
each container also have a mount file on the host node, which looks like this
| Code: | # cat /etc/vz/conf/101.mount
#!/bin/bash
mount -n --bind /usr/portage /vz/root/101/usr/portage
exit ${?} |
As far as I understand it that file contains extra mounts on top of the main root /vz/root/101 which actually is created dynamically from vz/private/101 and where 101 is the container id. But I don't know what all that comes down to in this situation.
I was able thoug to install both sandbox and gcc by using
| Code: | | FEATURES="-sandbox" emerge -1 gcc |
and
| Code: | | FEATURES="-sandbox" emerge -1 sandbox |
but if I then try to emerge anything, I get the same ACCESS DENIED and ACCESS VIOLATION error,
| Code: |
# emerge -uDalN system
...
Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild manifests
>>> Emerging (1 of 3) sys-devel/automake-wrapper-9
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/tty
* ACCESS DENIED: open_wr: /dev/null
* ACCESS DENIED: open_wr: /dev/null
* ACCESS DENIED: open_wr: /dev/null
* ACCESS DENIED: open_wr: /dev/null
* ACCESS DENIED: open_wr: /dev/null
/usr/lib64/portage/bin/phase-functions.sh: line 740: /dev/null: Permission denied
/usr/lib64/portage/bin/phase-functions.sh: line 740: /dev/null: Permission denied
/usr/lib64/portage/bin/phase-functions.sh: line 740: /dev/null: Permission denied
/usr/lib64/portage/bin/phase-functions.sh: line 748: /dev/null: Permission denied
/usr/portage/profiles/base/profile.bashrc: line 5: /dev/null: Permission denied
* ACCESS DENIED: open_wr: /dev/null
* ACCESS DENIED: open_wr: /dev/null
* ACCESS DENIED: open_wr: /dev/null
/usr/lib64/portage/bin/phase-functions.sh: line 197: /dev/null: Permission denied
>>> Unpacking source...
/usr/lib64/portage/bin/phase-functions.sh: line 197: /dev/null: Permission denied
>>> Source unpacked in /var/tmp/portage/sys-devel/automake-wrapper-9/work
/usr/lib64/portage/bin/phase-functions.sh: line 197: /dev/null: Permission denied
* --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
* LOG FILE: "/var/log/sandbox/sandbox-29880.log"
*
etc.
|
so right now that container is wrecked, but there must be a way around to fix this.
Btw | Code: | | FEATURES="-sandbox" emerge -uDalN system |
works.
Could it be an idea to rebuild the whole container with
| Code: | FEATURES="-sandbox" emerge -e system
FEATURES="-sandbox" emerge -e world |
or would that be a sure way to wreck it totally?
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Jun 23, 2013 10:59 pm Post subject: |
|
|
| Maybe you need to bind /dev (and less relevant, /sys) as well and not just /proc. Can we see the mount output inside the container to see what is present and what is not? |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 11:47 pm Post subject: |
|
|
Sure, but how would I do that? # mount ?
I do know what mount and a mount point is, but not sure I understand what you mean by "mount output"?
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 11:51 pm Post subject: |
|
|
Ok, this is from the ok container, where I created the packages
| Code: | # mount
/vz/private/101 on / type simfs (rw,relatime)
/dev/root on /usr/portage type ext3 (rw,noatime,relatime,errors=continue,barrier=1,data=ordered)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755) |
And this is on the container I installed them and give the access errors
| Code: | # mount
/vz/private/107 on / type simfs (rw,relatime)
/dev/root on /usr/portage type ext3 (rw,noatime,relatime,errors=continue,barrier=1,data=ordered)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755) |
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Sun Jun 23, 2013 11:57 pm Post subject: |
|
|
In case it matters, here is the host node
| Code: | # mount
/dev/sda3 on / type ext3 (rw,noatime,errors=continue,barrier=1,data=ordered)
devtmpfs on /dev type devtmpfs (rw,size=4084364k,nr_inodes=1021091,mode=755)
none on /proc type proc (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda5 on /vz type ext3 (rw,noatime)
/dev/sda6 on /tmp type ext2 (rw,noatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nodev,noexec,nosuid)
beancounter on /proc/vz/beancounter type cgroup (rw,name=beancounter)
container on /proc/vz/container type cgroup (rw,name=container)
fairsched on /proc/vz/fairsched type cgroup (rw,name=fairsched) |
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Mon Jun 24, 2013 12:06 am Post subject: |
|
|
| The mount outputs look okay to me, I am wondering whether you might need to --bind /dev to your containers like you do with /usr/portage. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Mon Jun 24, 2013 12:48 am Post subject: |
|
|
| TomWij wrote: | | The mount outputs look okay to me, I am wondering whether you might need to --bind /dev to your containers like you do with /usr/portage. |
But it doesn't make sense to me, it works on container 101, 102, 104 and 105 while 107 and 103 have the problem although haven't installed the binary packages on 103 yet, 106 is not in use.
They all origin from the same gentoo template, have the same basic configuration, but some have more resources than others and yes @world differs but the problem is on @system level which is the same. Host node is gentoo, it's all 100% Gentoo 
I don't get it though why these two containers have problems with sandbox, glibc and gcc in the first place. There is one thing though that maybe can have to do with it. Some time ago I migrated the system to new hardware, basically new mb, more RAM and went from a 2 core to a quad, all Intel. I am not sure but maybe the problem started to manifest after that. I still have the old box here intact. I use it to test on when it's time to update the kernel, so I always do it there first to see if there is a problem (as openvz can be a bit sensitive), but I haven't kept the virtuals up to date I think. I can update it and see if the problem is there or not, but maybe it could be of value to see the exact errors that sandbox, glibc and gcc generates, which I still should be able to produce from container 103? I'm turning in to get some sleep now though.
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Mon Jun 24, 2013 9:17 am Post subject: |
|
|
| Yeah, definitely doesn't sound like a difference in how it is set up but rather that some upgrade went wrong. If you think this could be a difference in the installed packages, you could do a diff between the output of `ls -1 /var/db/pkg/*` on a working and broking container; maybe there is some noticeable version difference for an important system package. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Mon Jun 24, 2013 10:44 am Post subject: |
|
|
I am updating the old box, but it takes some time as it's older and slower hardware, but apart from the hardware specific bits they should be identical as the new is spawn from the old one. So far I can at least confirm that sandbox build there, but the real test comes as all is up to date and I try to rebuild. Because I will remember that's sort of how it started, I wasn't able to rebuild the same version of gcc or if it was glibc, and then came the new sandbox that totally ruined it all. So once I have this done I will post my observations, and will make a package diff as well as suggested.
meanwhile, I just want to say tanks a lot for your assistance, and btw have you noticed whe actuall signed up to the fora on the same day, although with a few years difference - gotta be an omen
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Mon Jun 24, 2013 3:17 pm Post subject: |
|
|
Old system still updating so will take some time before I can use it for comparisons. But one thing hit my mind as I noticed that daemons like apache-httpd and proftpd no longer start up, the latter with a segmentation fault etc., that the tool-chain must be broken as I installed gcc-4.7.3 iof gcc-4.6.3 and glibc-2.7 iof glibc-2.16, so the sane thing would probably be to '#emerge -e system', and then '#emerge -e world', but as sandbox is broken as well I simply have to prefix it with 'FEATURE=-sandbox' and well who know, maybe it simply fix everything!
Luckily, while it's a live server, this container is mainly runs my private svn and apache for www development purposes. Bad thing though is that I can do all my work while it's wrecked. Also luckily, svn seem to work so I can dump my repos in case fs crashes as well on a full emerge update. Does it sound sane?
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Mon Jun 24, 2013 9:55 pm Post subject: |
|
|
| If the Portage related confuration is the same an empty tree emerge would normally bring the software state to be the same, but we don't know if the problem lies there. I think a package diff may be more efficient so you don't have to wait for the whole thing; unless the whole thing isn't that big, since these are containers. But well, you would have to start checking for differences somewhere and start excluding possible causes. Good luck. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Tue Jun 25, 2013 12:11 am Post subject: |
|
|
Well either way is time consuming, but as rebuilding keeps going by itself, it's the easy thing to try first. Also, as this 'access deny' problem really started with bringing in the binary packages, and as they leave the configs behind, my thought is that if they now build by them self from source they should use the already present configs. So I have now done '# FEATURES=-sandbox -e system' twice sucessfully building all 3 previous failing packages, and just started '# FEATURES=-sandbox -e world' which will do it's magic while I'm sleeping. So hopefully tomorrow all have (re)build by tomorrow and I will do the final test by removing FEATURES=-sandbox and hopefully all is well.
On the old box, both failing containers have rebuilt successfully as well, without any need for FEATURES=-sandbox
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
MoonWalker
Guru
Joined: 04 Jul 2002
Posts: 510
|
| Posted: Tue Jun 25, 2013 10:29 am Post subject: |
|
|
Bingo! All back to normal after twice
| Code: | | # FEATURES=-sandbox emerge -e system |
and once
| Code: | | # FEATURES=-sandbox emerge -e world |
and
| Code: | | # emerge -1 sandbox gcc glibc |
now build w/o any problems.
Thanks a lot for your assistance Tom.
_________________
/Joakim
Living on earth is expensive, but it includes a free trip around the sun
every year. |
|
| Back to top |
|
|
|
|
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
|
|
Portage & Programming
