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

[johntramp]

[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.
_________________
Sheepdog
Why Risk It? | Samba Howto

[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]

[chrbecke]

[Sheepdogj15]

[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]

If you use

[Sheepdogj15]

[edit: nevermind]
_________________
Sheepdog
Why Risk It? | Samba Howto

[B.marc]

[chrbecke]

[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.
_________________
Sheepdog
Why Risk It? | Samba Howto

[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.
_________________
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.

[B.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:

[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.
_________________
Sheepdog
Why Risk It? | Samba Howto

[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.
_________________
Sheepdog
Why Risk It? | Samba Howto

[B.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.

[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....
_________________
Sick of computers? Well, Czech girls and beer solve it! Trust me

[chrbecke]

[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! ). 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

[struhs]

Your solution is what I was looking for. Great!

But, ...