# mini-HOWTO: Installing Gentoo on slow machines

## chrbecke

The Problem

I got a Compaq Armada 1750 Notebook and wanted to get it up and runnig Gentoo. As it is rather slow with it's Pentium II 366 Mhz mobile and 192 MB RAM, I wanted my desktop box (Athlon) to do the compiling for it, but I didn't want to do without optimization for the Pentium II.

I found 3 ways to go:

3 possible solutions

1) Chroot on desktop box

Emerge everything in a chroot on my desktop box, make a tarball and copy it over to the target box. To update it, build binary packages in the chroot 

```
emerge -b <package>
```

 and install them (they're located in /usr/portage/packages, btw.) with 

```
emerge -k <package>
```

.

Advantage:

* definitly the fastest way

Disadvantage:

* need to keep a copy of the whole target box' filesystem on my desktop box for later updates

2) distcc

Use distcc for emerging. (See distcc documentation)

Advantage:

* no need to keep a copy of the target box' filesystem

* compiling can be distributed between several machines

Disadvantage

* slower than 3) (at least in my test case [see below]. Will do more benchmarking soon...)

3) Mount target box' filesystem via NFS and chroot

Use 1) to get a NFS Server up and running on the target box, export / to the desktop box. On the desktop box, mount the NFS share

```
mount -t nfs -o nfsvers=3,wsize=8192,rsize=8192 <target box>:/ /mnt/target
```

a portage tree

```
mount --bind /usr/portage /mnt/target/usr/portage
```

proc file system

```
mount -t proc none /mnt/target/proc
```

and a reasonable big and fast local filesystem as portage temporary directory

```
mount -t xxx -o yyy /dev/zzz /mnt/target/var/tmp/portage
```

Then chroot into the target system

```
chroot /mnt/target /bin/bash
```

do

```
env-update && . /etc/profile
```

and start emerging for your target box, using your desktop box' CPU power!

Benchmarks

I benchmarked all 3 methods with emerging sys-libs/gpm-1.20.1-r4:

desktop box: AthlonXP 1600+, VIA KT600 Chipset, 512 MB RAM, portage tree and portage tmp on a Seagate Barracuda 7200.7 SATA drive, Broadcom BCM4401 onboard NIC

target box: Pentium II 366 MHz mobile, Intel 440BX/ZX/DX Chipset, 192 MB RAM, IBM DBCA-206480 hard disk, xircom cardbus NIC

both on a 100 Mbit switched LAN, running gentoo-sources 2.6.11-r11, NFS version 3, mounted with wsize and rsize options set to 8192, sources for gpm were available in /usr/portage/distfiles, of course.

Method 1): emerging gpm on the desktop box: ~ 59 s

Method 2): emerging gpm on the target box using distcc: ~ 2:08 min

Method 3): emerging gpm on desktop box in a NFS mount chroot: ~ 1:55 min

emerging gpm on the target box (without distcc): ~ 2:24 min

Conclusion

So I decided to choose method 3, as it gave best results without having to keep a copy of the entire target box' filesystem. I was disappointed by distcc as it gave almost no increase in performance, but this might be different for larger packages or if there are more hosts to distribute compilation tasks between.

You should note that both machines are of the same architecture, i686. I was able to build with -march=pentium2 on the Athlon. It might not work if architectures differ or with other -march settings - cross compiling might be necessary then.

Comments welcome! I'm particulary interested in other benchmarks regarding distcc vs. NFS-mount-chroot (method 3) compilation and experiences with cross compiling.

edited:

* added proc mount

* typoLast edited by chrbecke on Sun Jul 03, 2005 7:37 pm; edited 2 times in total

----------

## johntramp

 *chrbecke wrote:*   

> 
> 
> 3) Mount target box' filesystem via NFS and chroot
> 
> Use 1) to get a NFS Server up and running on the target box, export / to the desktop box. On the desktop box, mount the NFS share 
> ...

 

That is a very good idea, I had never considered doing that before.  When I have installed gentoo on an old pc I have always just taken the harddrive out and put it into my PC until the handbook + xorg or whatever had completed, then put the drive back in it's origional computer.

----------

## Sheepdogj15

Hmm... i haven't thought of doing #3... that's a good idea. 

I have a couple of Howto's which are variations of the same idea as #1: 

https://forums.gentoo.org/viewtopic-p-2354360.html

and

https://forums.gentoo.org/viewtopic-t-319841.html

i currently use rsync to sync my old computer (Cyrix PR200 proc [188MHz, IIRC] with 64MB RAM), and so far it seems to work well. but i might try out #3, as that seems to be a more solid (and disk-space conservative) method to use.

----------

## Sheepdogj15

oh BTW, one way you could speed up #3 would be to bind in  directories portage uses for temporary files (/var/tmp, maybe /tmp?). kind of pointless to offload temporary information over the network, write it to the disk on the slow computer, only to grab it from over the network again. your local disk is probably faster anyways. 

i wouldn't recommend mixing portage temporary stuff for two different computers. but, what you could do is make an empty directory (maybe, /chroot/tmp) and bind it in:

[editted]

```
# mount --bind /chroot/tmp/portage /mnt/other-computer/var/tmp/portage

# mount --bind /chroot/tmp/portage-pkg /mnt/other-computer/var/tmp/portage-pkg
```

[end edit]

if you use ccache

```
# mount --bind /chroot/ccache /mnt/other-computer/root/.ccache
```

----------

## chrbecke

 *Sheepdogj15 wrote:*   

> oh BTW, one way you could speed up #3 would be to bind in  directories portage uses for temporary files (/var/tmp, maybe /tmp?).

 

That's what I suggested... But I assumed one has a spare filesystem to use as /var/tmp/portage  :Smile: 

 *chrbecke wrote:*   

> 
> 
> [...]
> 
> and a reasonable big and fast local filesystem as portage temporary directory
> ...

 

But you are right, maybe /tmp should be on a local file system as well?

I don't know wether temporary files of an emerge just go to /var/tmp/portage or to /tmp as well. But as building is done in /var/tmp/portage, I believe having this on a local file system will gain the most performance increase, whereas /tmp and /var/tmp will not be as important.

----------

## Sheepdogj15

 *chrbecke wrote:*   

>  *Sheepdogj15 wrote:*   oh BTW, one way you could speed up #3 would be to bind in  directories portage uses for temporary files (/var/tmp, maybe /tmp?). 
> 
> That's what I suggested... But I assumed one has a spare filesystem to use as /var/tmp/portage 

 

err woops. i must have read too fast through that area. 

 *Quote:*   

> But you are right, maybe /tmp should be on a local file system as well?
> 
> I don't know wether temporary files of an emerge just go to /var/tmp/portage or to /tmp as well. But as building is done in /var/tmp/portage, I believe having this on a local file system will gain the most performance increase, whereas /tmp and /var/tmp will not be as important.

 

yeah. 

it isn't obvious that /tmp is used by portage. last night out of curiosity, i looked up in the Gentoo docs what directories portage uses. this is the page i found:

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=1

Notable candidates are:

/usr/portage (i know, duh!)

/var/cache/edb

/var/db/pkg

/var/tmp/portage

/var/tmp/portage-pkg (this one isn't in the doc, but i found it while i was meandering my filesystem. i assume it's for if you use or make prebuilt packages.)

out of curiosity, how do you time build runs? i may do some benchmarking myself later on. (i have to rebuild the system for my router box, grumble grumble.) [edit] nevermind, i think i found it (the "time" command)

----------

## kommissar

Idea #3 is a great idea, i never thought of that.  I thought distccd was the holy grail of compiling but i was very disappointed with it after using it.  The manual says that the overhead of sending the jobs can outweigh the benefits of compiling on a local system.  It also mentioned that there are many things (which i cannot remember) that have to be done all locally before a job can be sent out to compile.  

In short, i don't think distccd would be too great unless you're running a true compiling farm AND you have a fast computer that can handle running portage with the -j10 makeopts (for all the extra jobs) or higher because of the overhead involved with it.

----------

## B.marc

Hi,

I'm quite new to Gentoo, so forgive me, if this is a stupid question. When I read method 3 of your howto, I was thinking, if it would be simpler to use the ROOT option of emerge instead of chroot. Would look like this:

 *chrbecke wrote:*   

> 
> 
> Use 1) to get a NFS Server up and running on the target box, export / to the desktop box. On the desktop box, mount the NFS share
> 
> ```
> ...

 

Then use ROOT option:

```
ROOT=/mnt/target emerge foo
```

Would this work? What possible problems would arise?

Regards,

Marc

----------

## chrbecke

If you use 

```
ROOT="/mnt/target" emerge foo
```

 you are running the emerge in the environment (i.e. CFLAGS, CXXFLAGS, CHOST, USE flags and all the portage related data like installed packages, profile, etc.) of your desktop box, not in the environment of your target box. You only modify the install path.

That's why you must chroot.

----------

## Sheepdogj15

[edit: nevermind]

----------

## B.marc

 *chrbecke wrote:*   

> If you use 
> 
> ```
> ROOT="/mnt/target" emerge foo
> ```
> ...

 

Uhm, OK, got it. Why do you bind the portage tree? Shouldn't there be one on the slow machine? Or is this as with the temp directory, that you do not have to copy to many files over lan? Or do you just want to use one tree, which you sinc regularly?

Marc

----------

## chrbecke

 *B.marc wrote:*   

> Why do you bind the portage tree? Shouldn't there be one on the slow machine? Or is this as with the temp directory, that you do not have to copy to many files over lan? Or do you just want to use one tree, which you sinc regularly?

 

All of that. I only use portage on the slow machine as described here, so it was just wasted disk space if it had it's own portage tree.

----------

## Sheepdogj15

yeah. portage can accumulate up to around a gig of crap. on older systems where disk space is at a premium, it is really good to save that space by not keeping a redundant portage tree.

also, you save time by accessing portage cache and such on the local machine, rather than going over the network, accessing it there on a slower disk, and then pulling it back over the line.

----------

## timeBandit

Way to go, chrbecke! I had the same idea (#3) about a year ago, and used it to cram Gentoo into a tiny old box too small for a stage2 tarball (48Mb RAM, 1.2Gb HD). Hosted builds were vital due to the cramped target space, let alone the speed benefit.

One problem I had was, portage would quit after each ebuild of a multi-step emerge, due to file locking problems over NFS. Next time I update the target, I'll try the nfsvers=3 mount option and see if that helps. Thanks.

PS: I kept transcripts of that exercise, on both the host and target, from Stage 1 to finished install. I'd intended to post it here but never made time to write it up. I'd happily share my transcripts, scripts and notes with anyone who plans to attempt this and thinks they might be useful.

----------

## B.marc

 *timeBandit wrote:*   

> PS: I kept transcripts of that exercise, on both the host and target, from Stage 1 to finished install. I'd intended to post it here but never made time to write it up. I'd happily share my transcripts, scripts and notes with anyone who plans to attempt this and thinks they might be useful.

 

Since I'm trying to do this, I would happily check your stuff and see, if it helps me.

Marc

----------

## Ic3M4n

well, I also think the 3rd method is better than the other, but you can optimize the transfer of compiling file with this tip.

from the italian forum:

this tip show how use tmpfs for increasing compiling performance. a little transation:

modify in /etc/make.conf:

```

PORTAGE_MEMSIZE=xxx
```

 and pay attention: tmpfs use ram and also swap, ramfs only ram, for compiling I use a slow pentium3 with 512M of ram and 2G of swap setting a 1,5G of tmpfs. there's some case, for example openoffice need more space, around 3G for tmp. in this case you can disable the 

```
tmpfs with PORTAGE_MEMSIZE="" emerge openoffice
```

note: you must have the ramfs/tmpfs in the kernel.

```
wget -O /etc/portage/bashrc http://gechi.fonderiadigitale.it/bashrc

chown portage:portage /etc/portage/bashrc

chmod ug+x /etc/portage/bashrc 

```

----------

## Sheepdogj15

well, i was thinking another way to optimize the process, at the expense of some disk space on the local machine. basically, make a new directory in your filesystem (e.g., /chroot) and unpack a stage3 tarball there. and then in the new folder, add another directory where you will mount the NFS share.

set up your make.conf as you wish in /chroot. make sure you add ROOT="/foo" to it, where foo is where you will be mounting the nfs stuff, relative to /chroot. 

what this will do is make it so you use a local gcc, portage, and related libraries and apps, rather than pulling it over the network everytime. you may also benefit if you have a faster hard drive on the local machine. 

my old computer is on the fritz again, so i haven't tested it out yet.

----------

## jetblack101

for those that get hung up on this...  When I tried to mount the slow machine share on my desktop I consistently go errors about permissions when doing env-update. It was very frustrating(words dont do it justice] but luckly I found a solution, probably an obvious one to everyone but myself

just add no_root_squash to the /etc/exports file on the server

----------

## Sheepdogj15

yeah... you need root access to do the emerge anyways.

----------

## B.marc

 *Sheepdogj15 wrote:*   

> well, i was thinking another way to optimize the process, at the expense of some disk space on the local machine. basically, make a new directory in your filesystem (e.g., /chroot) and unpack a stage3 tarball there. and then in the new folder, add another directory where you will mount the NFS share.
> 
> set up your make.conf as you wish in /chroot. make sure you add ROOT="/foo" to it, where foo is where you will be mounting the nfs stuff, relative to /chroot. 
> 
> what this will do is make it so you use a local gcc, portage, and related libraries and apps, rather than pulling it over the network everytime. you may also benefit if you have a faster hard drive on the local machine.

 

I d'ont quite get your idea. You use the stage3 tarball to create an environment, where you can set the make.conf for your old machine, set the profile, etc. Then mount the NFS share and emerge stuff in the share, using the ROOT option in make.conf.

Well, using the ROOT option, I had this idea, too (see above). While I see the difference in your approach, what about the problems chrbecke stated (bold quoting by me):

 *chrbecke wrote:*   

> If you use 
> 
> ```
> ROOT="/mnt/target" emerge foo
> ```
> ...

 

Marc

----------

## chrbecke

The way Sheepdogj15 describes won't run into the issues I was talking about.

As I understand, Sheepdogj15 suggests to mix what I called "method 1" and "method 3" in my initial post. You do a pretty basic Gentoo installation in a chroot on your desktop box and use this to get a minimal system running on your target box. But instead of deleting it on your desktop box, you keep it for further updates. So far, it's simply what I calles "method 1", with the disadvantage of wasting diskspace by keeping a copy of the target box' system on your desktop box.

Now comes "method 3": You mount your target box filesystem via NFS somewhere in the copy on your desktop box, chroot into this copy and emerge with ROOT set to the mountpoint of your target box' filesystem. You also bind mount portage tmp dirs and a portage tree etc, as described in "method 3". So, all packages you emerge get installed on your target box, but should be built using the local copy of the toolchain and portage stuff on your desktop box.

This is an interesting idea, but if it will work depends on how portage actually handles the ROOT setting:

If portage simply adds ROOT to the install path, but doesn't take ROOT into account when building, it won't work, because emerge won't find the libraries and tools needed if they are only available on the target box. So you will have to keep a full copy of your target box' system, and the advantages of "method 3" are lost completely.

If emerge takes the ROOT setting into account when looking for tools and libraries needed, the advantages Sheepdogj15 intended will be lost, because emerge will use the toolchain found in ROOT and not the local one.

The Gentoo Handbook and man pages don't provide much information on how ROOT is actually handled.  :Sad: 

----------

## stripe

Well after reading through this topic, I can only propose two solutions, which are from my experience very quick, easy, and less painful.

using backward compatibility of the new processors if you are in time pressure or just frustrated about emerge process.

- puting the harddrive which is thought to be in older pc to a faster machine, mounting, chrooting and running emerge there with -march="destination-cpu"

- if you cannot move the harddrive by hand, just copy all the root by rsync to some directory on faster machine, chroot, and running emerge by the same way there, and move the root by the same manner back.

and you are where you wanted to be. And trust me, that it is kinda difference, among run emerge 3 hours on AMD XP, time you spend on getting NFS filesystem work and let´s say 24 hours you run emerge on the old pc....

----------

## chrbecke

 *stripe wrote:*   

> 
> 
> - puting the harddrive which is thought to be in older pc to a faster machine, mounting, chrooting and running emerge there with -march="destination-cpu"
> 
> - if you cannot move the harddrive by hand, just copy all the root by rsync to some directory on faster machine, chroot, and running emerge by the same way there, and move the root by the same manner back.

 

That's definitely a possible solution. I just wanted to find a reasonably fast way to do it without using a screwdriver and without having a copy of the whole target box' filesystem on the faster machine.

----------

## Sheepdogj15

yeah you can do that too, if the procs us the same basic architecture (e.g. x86). and if this is an initial install, i'd say go grab the Ultimate Boot Disc (http://www.ultimatebootcd.com/) and us the Linux on that (you could use the Live CD, but it doesn't have rsync and i don't recall if it has NFS). that way you don't have to do the hard drive shuffle.

I have some experience with ROOT=/foo. i use amd64 as my base arch, and sometimes i need 32bit binaries as the some only install in x86. i was experimenting with setting up a 32bit environment through which i could build applications at 32 bit, copy the finished work into my filesystem and let x86 emulation do it's thang. 

i eventually found it is just easier to just grab rpm's, convert them to .tar.gz, and *carefully* extract them (carefully, since you don't want 32bit libs clobbering your 64bit ones of the same name). but the principle seemed to work. 

my basic setup was this: /chroot was where i extracted a stage3-athlon-* tarball, which essentially worked as my 32bit environment. i could be mistaken, but stage3 comes with everything you need to emerge pretty much everything... you might have to install python and perl5 and all that, but i could have sworn it all comes in the tarball. 

in the /chroot directory, i setup another folder called g32. so of course, in /chroot/etc/make.conf, i had ROOT set to /g32. configured all my settings, copied over resolv.conf and all that. you chroot in, call env-update and source /etc/profile... for amd64 you have a special command called linux32 (or else the chroot will expect a 64bit env instead of a 32bit one). 

when i went to emerge something, it would start by installing all the portage stuff in /g32/var, and i can't remember what else... it might have been /g32/tmp. i always had to do --nodep emerges since nothing is installed in /g32, and so portage wanted to install the whole system as it's a dependancy to everything else. however, the emerges always went well, even without the tool chain installed in g32, as long as it was installed properly in chroot. 

i figured this is out it breaks down: where ROOT=/g32,

A. portage uses /etc/make.conf in / (which in the chroot env for me, so actually it was /chroot, relative to my main system environment)

B. portage uses the toochain (gcc, glibc, etc.) in /

C. portage uses /usr/portage in / unless you specify differently.

D. portage uses /var and cache crap in /g32, including portage cache and the world file. some of this you could use a binding (mount --bind ...) to force it into the local filesystem. 

E. portage installs stuff into /g32.

so, my thought is that it should work, though it'd leave a bit of a convoluted mess. meaning, i wouldn't recommend a bastardized method 1-3 unless you know what you are doing. (BTW, i'm copyrighting that term!  :Smile:  ). You'd also have to maintain that toolchain, so it means a bit more administrative time. it may or may not be worth it. and, an unpacked stage3 takes up something like 300MB... no thanks if you're already hurting for disk space.

----------

## struhs

Your solution is what I was looking for. Great!

But, ...

 *chrbecke wrote:*   

> The Problem
> 
> 3) Mount target box' filesystem via NFS and chroot
> 
> Use 1) to get a NFS Server up and running on the target box, export / to the desktop box. 
> ...

 

Unfortunately in "1)" there is no information on howto to get a NFS Server up and running on the target box.

I am able to start Gentoo 2005.1-Minimal-CD with network and partitioning,formating and mounting everything but what then?

Is that enough?

----------

## Sheepdogj15

for a general NFS howto, i recommend this: http://gentoo-wiki.com/HOWTO_Share_Directories_via_NFS

also, my old proxy method used NFS... the general principle is the same:

https://forums.gentoo.org/viewtopic-t-319841.html

the LiveCD comes with NFS and needed kernel modules, you just have to make sure you configure /etc/exports and start the daemons before you chroot in (i figure it should go without saying, but some people just don't know better  :Confused:  )

make sure you start portmap on the client computer, as it's a prerequisite to mounting nfs shares.

----------

## struhs

 *Sheepdogj15 wrote:*   

> for a general NFS howto, i recommend this: http://gentoo-wiki.com/HOWTO_Share_Directories_via_NFS
> 
> the LiveCD comes with NFS and needed kernel modules, 
> 
> 

 

So, I don't have to install a base system on the notebook and can do e.g. "emerge -e system" from my (powerful) desktop PC? Everything I have to do is to chroot from desktop PC to notebook?

 *Sheepdogj15 wrote:*   

> for a general NFS howto, i recommend this: http://gentoo-wiki.com/HOWTO_Share_Directories_via_NFS
> 
> you just have to make sure you configure /etc/exports and start the daemons before you chroot in (i figure it should go without saying, but some people just don't know better  )
> 
> 

 

Is /etc/exports located on a ramfs (because I can't change a CD-file)? Or are you talking about /mnt/gentoo/etc/exports (but this would not help with the live CD - NFS, right?)?

----------

## Sheepdogj15

 *struhs wrote:*   

> So, I don't have to install a base system on the notebook and can do e.g. "emerge -e system" from my (powerful) desktop PC? Everything I have to do is to chroot from desktop PC to notebook?

 

if i understand what you mean, it depends on what method you use. 

 *Quote:*   

> Is /etc/exports located on a ramfs (because I can't change a CD-file)? Or are you talking about /mnt/gentoo/etc/exports (but this would not help with the live CD - NFS, right?)?

 

hmmm. i could have sworn the version in RAM was writable. (fyi, it's ramdisk, not ramfs)

what you may have to do is install a basic (stage3?) install of Gentoo, chroot in, emerge nfs-utils, then setup the nfs exports. 

i could have sworn that last time i did this, it wasn't so convolutied  :Confused: 

----------

## struhs

I have managed the connection, but I always get errors if I am using emerge (some read error). Will post error messages on saturday if possible.

----------

## Sheepdogj15

not to preempt you, but root will need write access to the remote computer. in your /etc/exports, make sure you have no_root_squash and rw as options for the share(s)

and just a general comment to the thread, if you have different parts of your filesystem on different partitions, you will want to share them individually. NFS doesn't seem to share beyond the partition that the directory is on that you want to share (it's possible there is just a setting that i missed, but i wouldn't know what one)

for instance, i have to share /, /usr, /var, and /tmp individually in /etc/exports

----------

## struhs

 *Sheepdogj15 wrote:*   

> not to preempt you, but root will need write access to the remote computer. in your /etc/exports, make sure you have no_root_squash and rw as options for the share(s)
> 
> 

 

I have done that.

 *Sheepdogj15 wrote:*   

> 
> 
> and just a general comment to the thread, if you have different parts of your filesystem on different partitions, you will want to share them individually. NFS doesn't seem to share beyond the partition that the directory is on that you want to share (it's possible there is just a setting that i missed, but i wouldn't know what one)
> 
> for instance, i have to share /, /usr, /var, and /tmp individually in /etc/exports

 

I'll check/test this as soon as I am back at my desktop PC (this weekend). But I had just one root-partition (/) and the boot-partition (/boot) and I don't think that emerge is accessing the boot-partition.

----------

## Sheepdogj15

yeah. portage would only need access to /boot if you were installing grub or another bootloader. you can also compile kernels over NFS so there may be an advantage to making /boot a share. 

like i said, that was just a general comment. 

hmm, not sure what else could be wrong. what's your local fstab entry look like for the remote share? when you mount it, can you write to it as root? (e.g., make a text file in /mnt/[nfs-share]/root/)

----------

## struhs

Here are the errors I get if I try to emerge gnome-light:

```

close failed: [Errno 9] Bad file descriptor

close failed: [Errno 9] Bad file descriptor

Calculating dependencies ...done!

>>> emerge (1 of 49) media-libs/libid3tag-0.15.1b to /

close failed: [Errno 9] Bad file descriptor

close failed: [Errno 9] Bad file descriptor

close failed: [Errno 9] Bad file descriptor

```

... then it compiles and then it stops...

```

>>> Completed installing libid3tag-0.15.1b into /var/tmp/portage/libid3tag-0.15.1b/image/

>>> Merging media-libs/libid3tag-0.15.1b to /

--- /usr/

--- /usr/lib/

>>> /usr/lib/libid3tag.la

--- /usr/lib/pkgconfig/

>>> /usr/lib/pkgconfig/id3tag.pc

>>> /usr/lib/libid3tag.a

>>> /usr/lib/libid3tag.so.0.3.0

>>> /usr/lib/libid3tag.so.0 -> libid3tag.so.0.3.0

--- /usr/share/

--- /usr/share/doc/

>>> /usr/share/doc/libid3tag-0.15.1b/

>>> /usr/share/doc/libid3tag-0.15.1b/VERSION.gz

>>> /usr/share/doc/libid3tag-0.15.1b/README.gz

>>> /usr/share/doc/libid3tag-0.15.1b/TODO.gz

>>> /usr/share/doc/libid3tag-0.15.1b/CREDITS.gz

>>> /usr/share/doc/libid3tag-0.15.1b/CHANGES.gz

--- /usr/include/

>>> /usr/include/id3tag.h

>>> /usr/lib/libid3tag.so -> libid3tag.so.0.3.0

Traceback (most recent call last):

  File "/usr/bin/emerge", line 3200, in ?

    mydepgraph.merge(mydepgraph.altlist())

  File "/usr/bin/emerge", line 1912, in merge

    retval=portage.doebuild(y,"merge",myroot,self.pkgsettings,edebug)

  File "/usr/lib/portage/pym/portage.py", line 2724, in doebuild

    return merge(mysettings["CATEGORY"],mysettings["PF"],mysettings["D"],mysettings["BUILDDIR"]+"/build-info",myroot,mysettings,myebuild=mysettings["EBUILD"])

  File "/usr/lib/portage/pym/portage.py", line 2896, in merge

    return mylink.merge(pkgloc,infloc,myroot,myebuild)

  File "/usr/lib/portage/pym/portage.py", line 6893, in merge

    return self.treewalk(mergeroot,myroot,inforoot,myebuild,cleanup=cleanup)

  File "/usr/lib/portage/pym/portage.py", line 6567, in treewalk

    mylock = portage_locks.lockfile(destroot+CONFIG_MEMORY_FILE)

  File "/usr/lib/portage/pym/portage_locks.py", line 93, in lockfile

    fcntl.lockf(myfd,fcntl.LOCK_EX|fcntl.LOCK_NB)

IOError: [Errno 37] No locks available

close failed: [Errno 9] Bad file descriptor

```

I have write access to the root directory on the notebook.

I think that something is wrong. Googled for that error, but was unable to find something about it.

Regards,

Stefan

----------

## struhs

Solved the problem:

"nolock" in the mount - command for each share solves the problem.

----------

## Sheepdogj15

yup... i had that problem too. it seems to be a problem (not sure if it's a bug or intentional) in NFS.  :Confused: 

----------

## Iron_DragonLord

Hi, I found a solution to the "close failed: [Errno 9] Bad file descriptor" and other problems is to start /etc/init.d/nfsmount (emerge -av nfs-utils)

Hope that helps.

----------

## aries

Maybe a slight off topic, but at least it has something todo with it.

How can one pass commands from the old root into the new one after chroot?

I want to build a script that:

1 chroots 

2 update portage

3 emerge -buqD world

4 sync's builded packages with a server

But already at point 2 i run iinto problems after chroot nothin happens.

This is the script:

```
mount -o bind /mnt/S3_packs  /mnt/ix86/i586_S3/usr/portage/packages

mount -o bind /usr/portage/distfiles   /mnt/ix86/i586_S3/usr/portage/distfiles

mount -o bind /var/tmp/portageP3  /mnt/ix86/i586_S3/var/tmp/portage

mount -t proc none /mnt/ix86/i586_S3/proc

mount -o bind /dev /mnt/ix86/i586_S3/dev

chroot /mnt/ix86/i586_S3 /bin/bash

env-update && source /etc/profile

#2

emerge --sync
```

emerge sync happens only if I exit out of the new root.

How can I execute this in the new root environment?

----------

## chrbecke

aries,

you have to use two scripts: one that does the chroot, and another one that does the "emerge --sync" and so on in the chrooted environment.

chroot.sh - script that chroot's like in your example:

```
#!/bin/bash

mount -o bind /mnt/S3_packs  /mnt/ix86/i586_S3/usr/portage/packages

mount -o bind /usr/portage/distfiles   /mnt/ix86/i586_S3/usr/portage/distfiles

mount -o bind /var/tmp/portageP3  /mnt/ix86/i586_S3/var/tmp/portage

mount -t proc none /mnt/ix86/i586_S3/proc

mount -o bind /dev /mnt/ix86/i586_S3/dev

# Note: path to sync_and_stuff.sh must be relative to your new root,

# i.e. with /mnt/ix86/i586_S3/ as your new root and your script

# at /mnt/ix86/i586_S3/sync_and_stuff.sh, use /sync_and_stuff.sh

chroot /mnt/ix86/i586_S3 /bin/bash /sync_and_stuff.sh

```

sync_and_stuff.sh - script that does things in the chroot environment:

(place this script as /mnt/ix86/i586_S3/sync_and_stuff.sh)

```
#!/bin/bash

env-update && source /etc/profile

emerge --sync

echo "Done with syncing, spawning an interactive shell"

echo "Note that you have to \"env-update && source /etc/profile\" again in this shell!"

/bin/bash -i

```

This should do what you want.

HTH,

Christian

edit: fixed script path

----------

## aries

It did help!

Excactly what I was looking for. 

Thanks for your help Christian (and for polishing the script).

Aries

----------

## slycordinator

 *chrbecke wrote:*   

> 1) Chroot on desktop box
> 
> Emerge everything in a chroot on my desktop box, make a tarball and copy it over to the target box. To update it, build binary packages in the chroot 
> 
> ```
> ...

 

I do a similar thing.

In the chroot, emerge all the packages I want. Then, outside the chroot, I use rsync to update the slow box.

----------

## slycordinator

 *aries wrote:*   

> emerge sync happens only if I exit out of the new root.
> 
> How can I execute this in the new root environment?

 

Well you gotta be more descriptive than that. What actually happens when you do "emerge --sync"?

Any particular errors?

----------

## aries

It is solved for me!

My script was simply wrong no particular errors.

The two scripts given by chrbecke were the solution:

```
#!/bin/bash 

 mount -o bind /mnt/S3_packs  /mnt/ix86/i586_S3/usr/portage/packages 

 mount -o bind /usr/portage/distfiles   /mnt/ix86/i586_S3/usr/portage/distfiles 

 mount -o bind /var/tmp/portageP3  /mnt/ix86/i586_S3/var/tmp/portage 

 

 mount -t proc none /mnt/ix86/i586_S3/proc 

 mount -o bind /dev /mnt/ix86/i586_S3/dev 

 

 # Note: path to sync_and_stuff.sh must be relative to your new root, 

 # i.e. with /mnt/ix86/i586_S3/ as your new root and your script 

 # at /mnt/ix86/i586_S3/sync_and_stuff.sh, use /sync_and_stuff.sh 

 

 chroot /mnt/ix86/i586_S3 /bin/bash /sync_and_stuff.sh 
```

```
#!/bin/bash 

 env-update && source /etc/profile 

 emerge --sync 

 echo "Done with syncing, spawning an interactive shell" 

 echo "Note that you have to \"env-update && source /etc/profile\" again in this shell!" 

 /bin/bash -i 
```

This was my problem:

With my own script:

```
mount -o bind /mnt/S3_packs  /mnt/ix86/i586_S3/usr/portage/packages 

 mount -o bind /usr/portage/distfiles   /mnt/ix86/i586_S3/usr/portage/distfiles 

 mount -o bind /var/tmp/portageP3  /mnt/ix86/i586_S3/var/tmp/portage 

 

 mount -t proc none /mnt/ix86/i586_S3/proc 

 mount -o bind /dev /mnt/ix86/i586_S3/dev 

 chroot /mnt/ix86/i586_S3 /bin/bash 

 env-update && source /etc/profile 

 

 #2 

 emerge --sync
```

This happened:

1. chroot into new enveronment

2. nothing happened!

3. exit out of the 'new' environment

4.... and now the emerge --sync etc. started, but I wanted it to run under 2

----------

## vanten

*Bookmarked*

----------

