| 1 |
Sure, you'll have a Portage tree, but it will be in you build root. |
| 2 |
here is the way I would set it up |
| 3 |
|
| 4 |
the build root would be under /build, you could also share this over |
| 5 |
nfs too |
| 6 |
|
| 7 |
# cd build |
| 8 |
# tar jxvf ~/stage3*.tar.bz2 |
| 9 |
# cd usr |
| 10 |
# tar jxvf ~/portage-latest.tar.bz2 |
| 11 |
# cd /build |
| 12 |
|
| 13 |
-mounting all the needed directories, binding the root to /build/ |
| 14 |
chroot is only if you want to build packages into it. |
| 15 |
|
| 16 |
# for x in "/sys:/sys" "/dev:/dev/" "/:/chroot" |
| 17 |
> do |
| 18 |
> mount -o bind $(echo $x|cut -d':' -f1) /build/$(echo $x|cut -d':' |
| 19 |
-f2) |
| 20 |
> done |
| 21 |
# mount -t proc none /build/proc |
| 22 |
# cat /etc/resolv.conf > /build/etc/resolv.conf |
| 23 |
# chroot /build /bin/bash |
| 24 |
|
| 25 |
now you can set your profile, edit your /etc/mack.conf |
| 26 |
|
| 27 |
(chroot) # env-update; source /etc/profile |
| 28 |
(chroot) # ROOT="/chroot" emerge <pkg> |
| 29 |
|
| 30 |
for updating you system image use |
| 31 |
|
| 32 |
(chroot) # ROOT="/chroot" emerge <pkg> -uD |
| 33 |
|
| 34 |
you could use world, but it will install the things you may not want. |
| 35 |
you can update the world of the build root /build |
| 36 |
|
| 37 |
(chroot) # emerge --sync ; emerge world -uD |
| 38 |
|
| 39 |
This can all be scripted too, you just neet to make 2 scripts; one to |
| 40 |
start the job and one to work inside the chroot, just change |
| 41 |
|
| 42 |
# chroot /build /bin/bash |
| 43 |
|
| 44 |
to |
| 45 |
|
| 46 |
# chroot /build /start.sh |
| 47 |
|
| 48 |
__________________ |
| 49 |
Karl Gustav B. Holz |
| 50 |
---------- |
| 51 |
karl@××××××××.com |
| 52 |
---------- |
| 53 |
http://www.new-aeon.com |
| 54 |
|
| 55 |
|
| 56 |
On 21-May-07, at 12:27 PM, Ryan Gibbons wrote: |
| 57 |
|
| 58 |
> I believe you will still need a tree either way. |
| 59 |
> |
| 60 |
> I would just have the master server share it's portage tree over |
| 61 |
> nfs, and then when you update the nodes of the cluster, just mount |
| 62 |
> the nfs share, run your emerge system or world or whatever, and |
| 63 |
> then when you are finished umount the nfs share. |
| 64 |
> |
| 65 |
> I imagine this could be done easily via scripts, complete with |
| 66 |
> error checking for bad mounts bad emerges etc. |
| 67 |
> |
| 68 |
> Ronan Mullally wrote: |
| 69 |
>> Hi Karl, |
| 70 |
>> |
| 71 |
>> On Mon, 21 May 2007, Karl Holz wrote: |
| 72 |
>> |
| 73 |
>> |
| 74 |
>>>> Is there a way to run gentoo without a portage tree on each box? |
| 75 |
>>>> |
| 76 |
>>> yes, if you setup a build system, using a stage3 tarball, and |
| 77 |
>>> build your |
| 78 |
>>> system into a directory. Portage will only be under your /usr/ |
| 79 |
>>> portage and not |
| 80 |
>>> into the system image you're building. the good thing about using |
| 81 |
>>> a Stage3 |
| 82 |
>>> tarball is you can build you system on any linux system, build |
| 83 |
>>> your system |
| 84 |
>>> image, tarball the image, deploy and install grub on x86, yaboot |
| 85 |
>>> on Mac PPC, |
| 86 |
>>> silo on Sparc64. |
| 87 |
>>> |
| 88 |
>> How are updates handled? "emerge -uD <pkg|world>" isn't going to |
| 89 |
>> work |
| 90 |
>> without a portage tree, so I presume I'd need to tell each server |
| 91 |
>> which |
| 92 |
>> packages need to be updated with "emerge <pkg1> <pkg2> ... <pkgn>" |
| 93 |
>> to have |
| 94 |
>> it download them from the binhost? |
| 95 |
>> |
| 96 |
>> |
| 97 |
>> -Ronan |
| 98 |
>> |
Archives