| 1 |
On Saturday 18 December 2010 10:18:43 Neil Bothwick wrote: |
| 2 |
> On Fri, 17 Dec 2010 22:56:29 +0000, Peter Humphrey wrote: |
| 3 |
> > I've bought (against my better judgement) an Atom N270 box to be a LAN |
| 4 |
> > server, but it's a bit slow compared with the other boxes on the |
| 5 |
> > network. A big bit, actually - 69 minutes to compile a kernel compared |
| 6 |
> > with less than 9 minutes on this workstation. |
| 7 |
> > |
| 8 |
> > I thought I'd give distcc a go, but after reading the Gentoo distcc and |
| 9 |
> > crossdev guides and doing what they say I get no result. I might just |
| 10 |
> > as well not have made the effort. The Atom box just labours with the |
| 11 |
> > emerge without trying to send anything to the server box I've set up |
| 12 |
> > for the purpose. |
| 13 |
> |
| 14 |
> I've found there's just too much overhead with distcc, plus much of the |
| 15 |
> work is still done locally. I have a couple of Atom boxes, a server and a |
| 16 |
> netbook, and I've set up a chroot for each on my workstation. In the |
| 17 |
> chroot I have FEATURES=buildpkg, using an NFS mounted PKGDIR available to |
| 18 |
> both computers, then I emerge -k on the Atom box. |
| 19 |
|
| 20 |
I've been experimenting with nfs-mounting the whole Atom file system to /target |
| 21 |
in a chroot on my workstation, then setting --root=/target and --config- |
| 22 |
root=/target on every portage command. I can't recommend it. |
| 23 |
|
| 24 |
Numerous packages require to be installed into both the chroot and the target. I |
| 25 |
suppose that's not too onerous, even though I haven't found a way to predict |
| 26 |
which packages will be affected, but I've found that, when I go back to the Atom |
| 27 |
box and emerge -pkuv world, a lot of the packages that should already have been |
| 28 |
upgraded haven't been, and I have to emerge them on the Atom box directly. |
| 29 |
|
| 30 |
The states of the target and the native chroot are neither consistent nor |
| 31 |
independent - it's a mess. |
| 32 |
|
| 33 |
It was a nice idea to enable portage to work in this way, but it's still full of |
| 34 |
holes. Maybe all packages need some extra configuring; I don't know. A lot more |
| 35 |
work is definitely needed by someone, at any rate. |
| 36 |
|
| 37 |
I've decided to revert to Neil's method (once I've shaken this infection off). |
| 38 |
|
| 39 |
-- |
| 40 |
Rgds |
| 41 |
Peter |
Archives