| View previous topic :: View next topic |
| Author |
Message |
Dr. Frankenbox
Apprentice
Joined: 16 Jul 2005
Posts: 157
Location: Nebraska, USA
|
 Posted: Mon Apr 30, 2012 3:04 am Post subject: Error updating "sys-apps/file" [SOLVED] |
 |
|
I'm running an emerge -NuD world on one of my systems, and I run into a series of errors like this when updating sys-apps/file:
| Code: | make[2]: Entering directory `/var/tmp/portage/sys-apps/file-5.09/work/build-i686-pc-linux-gnu/magic'
../src/file -C -m magic
rm: cannot remove `magic/zyxel': Bad file descriptor
rm: cannot remove `magic/zilog': Bad file descriptor
rm: cannot remove `magic/xwindows': Bad file descriptor
rm: cannot remove `magic/xo65': Bad file descriptor
rm: cannot remove `magic/xilinx': Bad file descriptor
rm: cannot remove `magic/xenix': Bad file descriptor
. . .
|
Can anybody tell me what this means and how to fix it?
I'm not sure what "file" even is, but I'm sure it's some critical system component. Enlightenment on that wouldn't hurt, either.
Last edited by Dr. Frankenbox on Mon May 07, 2012 2:39 am; edited 1 time in total |
|
| Back to top |
|
 |
BillWho
Veteran
Joined: 03 Mar 2012
Posts: 1576
Location: US
|
| Posted: Mon Apr 30, 2012 4:13 am Post subject: |
|
|
Dr. Frankenbox,
sys-apps/file doesn't appear to be critical package. It's description is | Quote: | | identify a file's format by scanning binary data for patterns |
Try masking it for the time being to get through the update
| Code: | | echo "sys-apps/file" >> /etc/portage/package.mask |
You can unmask it after the upgrade with | Code: | | sed -i.bak 's/sys-apps\/file//' /etc/portage/package.mask |
and try the update again
Good luck 
_________________
Good luck
Since installing gentoo, my life has become one long emerge  |
|
| Back to top |
|
|
Dr. Frankenbox
Apprentice
Joined: 16 Jul 2005
Posts: 157
Location: Nebraska, USA
|
| Posted: Wed May 02, 2012 12:14 am Post subject: |
|
|
More of the same emerging sys-apps/sandbox. I'm going to post a more complete log and see if that helps.
| Code: | config.status: executing tests/atconfig commands
rm: cannot remove `./confS3Zmup/subs1.awk': Bad file descriptor
rm: cannot remove `./confS3Zmup/subs.awk': Bad file descriptor
rm: cannot remove `./confS3Zmup/defines.awk': Bad file descriptor
rm: cannot remove `conftest.dir/depcomp': Bad file descriptor
rm: cannot remove `conftest.dir/conftest.two': Bad file descriptor
rm: cannot remove `conftest.dir/conftest.err': Bad file descriptor
rm: cannot remove `conftest.dir/sub': Bad file descriptor
rm: cannot remove `conftest.dir/confmf': Bad file descriptor
rm: cannot remove `conftest.dir/conftest.one': Bad file descriptor
* Building sandbox for ABI=default...
make
make all-recursive
Making all in scripts
make[2]: Nothing to be done for `all'.
Making all in etc
Making all in sandbox.d
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
Making all in data
make[2]: Nothing to be done for `all'.
Making all in libsbutil
CC get_sandbox_conf.lo
CC get_sandbox_confd.lo
CC get_sandbox_lib.lo
CC get_sandbox_rc.lo
CC get_sandbox_log.lo
CC get_tmp_dir.lo
CC is_env_on.lo
CC is_env_off.lo
CC sb_open.lo
CC sb_read.lo
CC sb_write.lo
CC sb_close.lo
CC sb_printf.lo
CC sb_memory.lo
CC debug.lo
CC string.lo
CC file.lo
CC config.lo
CC dynbuf.lo
CCLD libsbutil.la
Making all in libsandbox
CC libsandbox_la-eqawarn.lo
GEN libsandbox.map
GEN symbols.h
GEN sb_nr.h
CC libsandbox_la-libsandbox.lo
../../sandbox-2.5/libsandbox/libsandbox.c:123:3: error: #error "how do i access a proc's fd/ tree ?"
../../sandbox-2.5/libsandbox/libsandbox.c: In function 'sb_get_fd_dir':
../../sandbox-2.5/libsandbox/libsandbox.c:125: warning: no return statement in function returning non-void
../../sandbox-2.5/libsandbox/libsandbox.c:130:3: error: #error "how do i access a proc's cmdline ?"
make[2]: *** [libsandbox_la-libsandbox.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
emake failed
|
I should admit; I'm doing something a bit unusual here. Because the box I'm upgrading has extremely limited CPU resources (233MHz), I'm mounting the filesystem to my own desktop (Athlon 64 x2), chrooting into it, and running the emerge there. This has worked for me in the past, but I can imagine it could lead to some unusual problems. I'm just looking for some insight as to what those errors mean.
Also, sys-apps/file may not be a critical system package, but it appears to be part of the base Gentoo system:
| Code: | frankenbox gateway # equery depends file
* These packages depend on file:
app-admin/eselect-1.2.18 (sys-apps/file)
|
|
|
| Back to top |
|
|
cach0rr0
Moderator
Joined: 13 Nov 2008
Posts: 4117
Location: Houston, Republic of Texas
|
| Posted: Wed May 02, 2012 3:59 am Post subject: |
|
|
| Dr. Frankenbox wrote: |
I should admit; I'm doing something a bit unusual here. Because the box I'm upgrading has extremely limited CPU resources (233MHz), I'm mounting the filesystem to my own desktop (Athlon 64 x2), chrooting into it, and running the emerge there. This has worked for me in the past, but I can imagine it could lead to some unusual problems. I'm just looking for some insight as to what those errors mean. |
did you mount /proc before you chrooted?
whatever the chroot, generally going to want to mount /proc (and bind mount /dev) before chrooting - same as you do when you do a gentoo install.
could also be youve run out of file descriptors. Check the former before I go too deep into the latter.
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
Dr. Frankenbox
Apprentice
Joined: 16 Jul 2005
Posts: 157
Location: Nebraska, USA
|
| Posted: Wed May 02, 2012 11:32 am Post subject: |
|
|
| I deliberately didn't mount /proc and /dev because they would have been the /proc and /dev from my computer, not the server. Is there some trick I can use to mount those with the correct contents? |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 7610
|
| Posted: Thu May 03, 2012 1:53 am Post subject: |
|
|
| The correct contents are the contents that correspond to the running system. Even if you could mount the remote /proc and get it consistent, it would not be useful, because compile jobs running locally could not use it to introspect themselves / their parents / their children. |
|
| Back to top |
|
|
Dr. Frankenbox
Apprentice
Joined: 16 Jul 2005
Posts: 157
Location: Nebraska, USA
|
| Posted: Sat May 05, 2012 2:13 pm Post subject: |
|
|
Obviously I have a lot to learn about what /proc is used for. I can get by without mounting /dev, though, right? I can definitely see some situations where mounting my /dev on that system could create problems.
It looks like this is going to work; with /proc mounted I've already gotten "sandbox" to emerge properly. |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 7610
|
| Posted: Sat May 05, 2012 3:40 pm Post subject: |
|
|
| You might get it to work without /dev, but I would not recommend it. /dev provides device nodes that are useful and safe for all users. The most commonly used are probably null, urandom, and zero, but there may be others that a build system will need. |
|
| Back to top |
|
|
Dr. Frankenbox
Apprentice
Joined: 16 Jul 2005
Posts: 157
Location: Nebraska, USA
|
| Posted: Mon May 07, 2012 2:39 am Post subject: |
|
|
| Thank you all for your help. All I needed was /proc (and to manually switch to the newer version of gcc, per this thread). Also, thank you for not making fun of my unusual setup or my old hardware. |
|
| Back to top |
|
|
cach0rr0
Moderator
Joined: 13 Nov 2008
Posts: 4117
Location: Houston, Republic of Texas
|
| Posted: Mon May 07, 2012 3:24 am Post subject: |
|
|
| Dr. Frankenbox wrote: | | Also, thank you for not making fun of my unusual setup or my old hardware. |
Gentoo thrives on old hardware. The compile always takes longer (which is why the way youre doing things, using another speedy system as a build host, is ideal), but especially with old hardware where resources are scarce, every little bit of bloat you can remove helps - i dare say the benefit is far more noticeable on your box than it would be on a modern speedy box.
One suggestion I don't know if you've considered looking at - an alternative to what you're doing now, simply set up a 32bit chroot on your Athlon 64 system, and use that to build binary packages for your old system. Similar to what tinderbox(.dev.gentoo.org) does. Slightly different twist from what you do now with the mounting of your actual filesystem, maybe saves you a step *and* some difficulty. Once done, copy binpkg over, emerge -K, and you're done.
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
|
Portage & Programming
