View previous topic :: View next topic |
Author |
Message |
chrbecke Guru
Joined: 12 Jul 2004 Posts: 598 Location: Berlin - Germany
|
Posted: Wed Jun 29, 2005 12:07 pm Post subject: mini-HOWTO: Installing Gentoo on slow machines |
|
|
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 |
|
|
johntramp Guru
Joined: 03 Feb 2004 Posts: 457 Location: New Zealand
|
Posted: Wed Jun 29, 2005 1:15 pm Post subject: Re: mini-HOWTO: Installing Gentoo on slow machines |
|
|
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 |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
|
Back to top |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Sat Jul 02, 2005 6:41 pm Post subject: |
|
|
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 |
|
|
chrbecke Guru
Joined: 12 Jul 2004 Posts: 598 Location: Berlin - Germany
|
Posted: Sun Jul 03, 2005 5:12 pm Post subject: |
|
|
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 |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Sun Jul 03, 2005 8:23 pm Post subject: |
|
|
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 |
|
|
kommissar Tux's lil' helper
Joined: 19 May 2005 Posts: 78
|
Posted: Thu Jul 07, 2005 5:50 am Post subject: Nice |
|
|
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 |
|
|
B.marc n00b
Joined: 16 Oct 2005 Posts: 40 Location: Braunschweig / Germany
|
Posted: Sun Oct 16, 2005 5:38 pm Post subject: Re: mini-HOWTO: Installing Gentoo on slow machines |
|
|
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 |
|
|
chrbecke Guru
Joined: 12 Jul 2004 Posts: 598 Location: Berlin - Germany
|
Posted: Sun Oct 16, 2005 6:32 pm Post subject: |
|
|
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 |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Mon Oct 17, 2005 1:19 am Post subject: |
|
|
[edit: nevermind] _________________ Sheepdog
Why Risk It? | Samba Howto |
|
Back to top |
|
|
B.marc n00b
Joined: 16 Oct 2005 Posts: 40 Location: Braunschweig / Germany
|
Posted: Mon Oct 17, 2005 8:53 pm Post subject: |
|
|
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 |
|
|
chrbecke Guru
Joined: 12 Jul 2004 Posts: 598 Location: Berlin - Germany
|
Posted: Mon Oct 17, 2005 9:19 pm Post subject: |
|
|
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 |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Tue Oct 18, 2005 1:52 am Post subject: |
|
|
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 |
|
|
timeBandit Bodhisattva
Joined: 31 Dec 2004 Posts: 2719 Location: here, there or in transit
|
Posted: Fri Oct 21, 2005 4:04 am Post subject: |
|
|
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 |
|
|
B.marc n00b
Joined: 16 Oct 2005 Posts: 40 Location: Braunschweig / Germany
|
Posted: Fri Oct 21, 2005 8:54 am Post subject: |
|
|
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 |
|
|
Ic3M4n Advocate
Joined: 02 Nov 2004 Posts: 3489 Location: Bergamo.
|
Posted: Fri Oct 21, 2005 4:22 pm Post subject: |
|
|
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 |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Fri Oct 21, 2005 6:06 pm Post subject: |
|
|
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 |
|
|
jetblack101 n00b
Joined: 17 Jan 2005 Posts: 16
|
Posted: Sat Oct 22, 2005 2:57 am Post subject: |
|
|
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 |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Sat Oct 22, 2005 4:15 am Post subject: |
|
|
yeah... you need root access to do the emerge anyways. _________________ Sheepdog
Why Risk It? | Samba Howto |
|
Back to top |
|
|
B.marc n00b
Joined: 16 Oct 2005 Posts: 40 Location: Braunschweig / Germany
|
Posted: Sat Oct 22, 2005 10:40 am Post subject: |
|
|
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 |
|
|
chrbecke Guru
Joined: 12 Jul 2004 Posts: 598 Location: Berlin - Germany
|
Posted: Sat Oct 22, 2005 12:10 pm Post subject: |
|
|
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 |
|
|
stripe n00b
Joined: 04 Jan 2004 Posts: 72 Location: Prague
|
Posted: Sat Oct 22, 2005 5:51 pm Post subject: |
|
|
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 |
|
|
chrbecke Guru
Joined: 12 Jul 2004 Posts: 598 Location: Berlin - Germany
|
Posted: Sat Oct 22, 2005 6:22 pm Post subject: |
|
|
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 |
|
|
Sheepdogj15 Guru
Joined: 07 Jan 2005 Posts: 430 Location: Backyard
|
Posted: Sun Oct 23, 2005 2:27 am Post subject: |
|
|
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 |
|
|
struhs n00b
Joined: 14 Jun 2005 Posts: 44
|
Posted: Thu Oct 27, 2005 9:25 am Post subject: Re: mini-HOWTO: Installing Gentoo on slow machines |
|
|
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 |
|
|
|
|
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
|
|