Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
mini-HOWTO: Installing Gentoo on slow machines
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
chrbecke
Guru
Guru


Joined: 12 Jul 2004
Posts: 598
Location: Berlin - Germany

PostPosted: Wed Jun 29, 2005 12:07 pm    Post subject: mini-HOWTO: Installing Gentoo on slow machines Reply with quote

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
Code:
emerge -b <package>
and install them (they're located in /usr/portage/packages, btw.) with
Code:
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
Code:
mount -t nfs -o nfsvers=3,wsize=8192,rsize=8192 <target box>:/ /mnt/target

a portage tree
Code:
mount --bind /usr/portage /mnt/target/usr/portage

proc file system
Code:
mount -t proc none /mnt/target/proc

and a reasonable big and fast local filesystem as portage temporary directory
Code:
mount -t xxx -o yyy /dev/zzz /mnt/target/var/tmp/portage

Then chroot into the target system
Code:
chroot /mnt/target /bin/bash

do
Code:
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
* typo


Last edited by chrbecke on Sun Jul 03, 2005 7:37 pm; edited 2 times in total
Back to top
View user's profile Send private message
johntramp
Guru
Guru


Joined: 03 Feb 2004
Posts: 457
Location: New Zealand

PostPosted: Wed Jun 29, 2005 1:15 pm    Post subject: Re: mini-HOWTO: Installing Gentoo on slow machines Reply with quote

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
Code:
mount -t nfs -o nfsvers=3,wsize=8192,rsize=8192 <target box>:/ /mnt/target
a portage tree
Code:
mount --bind /usr/portage /mnt/target/usr/portage
and a reasonable big and fast local filesystem as portage temporary directory
Code:
mount -t xxx -o yyy /dev/zzz /mnt/target/var/tmp/portage

Then chroot into the target system
Code:
chroot /mnt/target /bin/bash
, do
Code:
env-update && . /etc/profile
and start emerging for your target box, using your desktop box' CPU power!

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.
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Sat Jul 02, 2005 6:30 pm    Post subject: Reply with quote

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.
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Sat Jul 02, 2005 6:41 pm    Post subject: Reply with quote

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]
Code:
# 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
Code:
# mount --bind /chroot/ccache /mnt/other-computer/root/.ccache

_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
chrbecke
Guru
Guru


Joined: 12 Jul 2004
Posts: 598
Location: Berlin - Germany

PostPosted: Sun Jul 03, 2005 5:12 pm    Post subject: Reply with quote

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 :)

chrbecke wrote:

[...]
and a reasonable big and fast local filesystem as portage temporary directory
Code:
mount -t xxx -o yyy /dev/zzz /mnt/target/var/tmp/portage

[...]


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.
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Sun Jul 03, 2005 8:23 pm    Post subject: Reply with quote

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)
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
kommissar
Tux's lil' helper
Tux's lil' helper


Joined: 19 May 2005
Posts: 78

PostPosted: Thu Jul 07, 2005 5:50 am    Post subject: Nice Reply with quote

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.
Back to top
View user's profile Send private message
B.marc
n00b
n00b


Joined: 16 Oct 2005
Posts: 40
Location: Braunschweig / Germany

PostPosted: Sun Oct 16, 2005 5:38 pm    Post subject: Re: mini-HOWTO: Installing Gentoo on slow machines Reply with quote

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
Code:
mount -t nfs -o nfsvers=3,wsize=8192,rsize=8192 <target box>:/ /mnt/target


Then use ROOT option:
Code:
ROOT=/mnt/target emerge foo


Would this work? What possible problems would arise?

Regards,
Marc
Back to top
View user's profile Send private message
chrbecke
Guru
Guru


Joined: 12 Jul 2004
Posts: 598
Location: Berlin - Germany

PostPosted: Sun Oct 16, 2005 6:32 pm    Post subject: Reply with quote

If you use
Code:
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.
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Mon Oct 17, 2005 1:19 am    Post subject: Reply with quote

[edit: nevermind]
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
B.marc
n00b
n00b


Joined: 16 Oct 2005
Posts: 40
Location: Braunschweig / Germany

PostPosted: Mon Oct 17, 2005 8:53 pm    Post subject: Reply with quote

chrbecke wrote:
If you use
Code:
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.


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
Back to top
View user's profile Send private message
chrbecke
Guru
Guru


Joined: 12 Jul 2004
Posts: 598
Location: Berlin - Germany

PostPosted: Mon Oct 17, 2005 9:19 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Tue Oct 18, 2005 1:52 am    Post subject: Reply with quote

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.
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
timeBandit
Bodhisattva
Bodhisattva


Joined: 31 Dec 2004
Posts: 2674
Location: here, there or in transit

PostPosted: Fri Oct 21, 2005 4:04 am    Post subject: Reply with quote

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.
_________________
Plants are pithy, brooks tend to babble--I'm content to lie between them.
Super-short f.g.o checklist: Search first, strip comments, mark solved, help others.
Back to top
View user's profile Send private message
B.marc
n00b
n00b


Joined: 16 Oct 2005
Posts: 40
Location: Braunschweig / Germany

PostPosted: Fri Oct 21, 2005 8:54 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Ic3M4n
Advocate
Advocate


Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.

PostPosted: Fri Oct 21, 2005 4:22 pm    Post subject: Reply with quote

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:
Code:

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
Code:
tmpfs with PORTAGE_MEMSIZE="" emerge openoffice

note: you must have the ramfs/tmpfs in the kernel.
Code:
wget -O /etc/portage/bashrc http://gechi.fonderiadigitale.it/bashrc
chown portage:portage /etc/portage/bashrc
chmod ug+x /etc/portage/bashrc
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Fri Oct 21, 2005 6:06 pm    Post subject: Reply with quote

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.
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
jetblack101
n00b
n00b


Joined: 17 Jan 2005
Posts: 16

PostPosted: Sat Oct 22, 2005 2:57 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Sat Oct 22, 2005 4:15 am    Post subject: Reply with quote

yeah... you need root access to do the emerge anyways.
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
B.marc
n00b
n00b


Joined: 16 Oct 2005
Posts: 40
Location: Braunschweig / Germany

PostPosted: Sat Oct 22, 2005 10:40 am    Post subject: Reply with quote

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
Code:
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.

Marc
Back to top
View user's profile Send private message
chrbecke
Guru
Guru


Joined: 12 Jul 2004
Posts: 598
Location: Berlin - Germany

PostPosted: Sat Oct 22, 2005 12:10 pm    Post subject: Reply with quote

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. :(
Back to top
View user's profile Send private message
stripe
n00b
n00b


Joined: 04 Jan 2004
Posts: 72
Location: Prague

PostPosted: Sat Oct 22, 2005 5:51 pm    Post subject: Reply with quote

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....
_________________
Sick of computers? Well, Czech girls and beer solve it! Trust me :-)
Back to top
View user's profile Send private message
chrbecke
Guru
Guru


Joined: 12 Jul 2004
Posts: 598
Location: Berlin - Germany

PostPosted: Sat Oct 22, 2005 6:22 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Sun Oct 23, 2005 2:27 am    Post subject: Reply with quote

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! :) ). 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.
_________________
Sheepdog
Why Risk It? | Samba Howto
Back to top
View user's profile Send private message
struhs
n00b
n00b


Joined: 14 Jun 2005
Posts: 44

PostPosted: Thu Oct 27, 2005 9:25 am    Post subject: Re: mini-HOWTO: Installing Gentoo on slow machines Reply with quote

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?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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