Creating a 64bit build-space

Synchronising the portage trees

Assuming that the virtual machine started correctly and all filesystems were mounted without errors we can now begin the task of configuring the build spaces. As all the build spaces will share a common copy of the portage tree the first task is to rsync the portage tree from a portage mirror to the live portage directory as shown below.

Installing the build-space

Now that all the required files are in place we can create the build space which will be used by the 64bit server configuration. The first stage in this process is to unpack the stage3 archive we used earlier into the new buildspace as shown below. We are still not going to delete this archive as it can be used again when we build the 64bit workstation build-space however once the last 64bit build-space has been created it can be removed.

Next we need to create some mount-points so that we can mount the common portage related files, the destination volume for the packages that this build space will produce as well as critical common configuration files and system directories from the main build server which will be bind mounted into the build space to ensure that configurations and capabilities always remain synchronised.

We can now add entries to the /etc/fstab file on the build-server to automatically bind mount the shared configuration objects and the portage related directories into the build-space. As you can see from the example below some directories are mounted using the rbind directive to enable recursive binding so that sub-mounts are also bound correctly.

#<source>                                              <destination>                                              <none/bind>

/dev                                                   /mnt/buildspaces/x86-64bit-server/dev                      none rbind
/proc                                                  /mnt/buildspaces/x86-64bit-server/proc                     none rbind
/sys                                                   /mnt/buildspaces/x86-64bit-server/sys                      none rbind
/etc/resolv.conf                                       /mnt/buildspaces/x86-64bit-server/etc/resolv.conf          none bind,ro

/mnt/repositories/distfiles                            /mnt/buildspaces/x86-64bit-server/mnt/portage/distfiles    none bind
/mnt/repositories/testing/x86-64bit-server/portage     /mnt/buildspaces/x86-64bit-server/mnt/portage/portage      none bind,ro
/mnt/repositories/testing/x86-64bit-server/overlays    /mnt/buildspaces/x86-64bit-server/mnt/portage/overlays     none bind,ro
/mnt/repositories/testing/x86-64bit-server/packages    /mnt/buildspaces/x86-64bit-server/mnt/portage/packages     none bind
/mnt/repositories/testing/x86-64bit-server/kernels     /mnt/buildspaces/x86-64bit-server/usr/src                  none bind

/var/tmp/portage                                       /mnt/buildspaces/x86-64bit-server/var/tmp/portage          none bind

As you can see in the above example we have bound the portage and overlays directories read-only in the build-space so that no emerge --sync or layman --sync actions can be accidentally performed. We have also mounted /etc/resolv.conf read-only to ensure that it cannot be accidentally modified from within the build-space.

 

With the corresponding entries in place in the /etc/fstab file we can mount the bind-mounts we have configured manually so that they are in place as they would be had the build-server just booted.

Configuring the build-space

So that we can more easily determine whether we are working with the build-server or one of its build-spaces when entering commands we shall add a prefix to the bash prompt of the build-space as shown below.

# Try to keep environment pollution down, EPA loves us.
unset use_color safe_term match_lhs

PS1="64bit-SRV ${PS1}"

This prefix will ensure that we always know which build-space we are working on when we enter it using the chroot application as shown in the example below.

Now that we are in the build-space we can update the environment and source the current profile so that we are using the correct environment settings from the build-space and not those inherited from the build-server.

We can now set the build properties which will be used by this build-space when creating binary packages. You can see in the example below we have used a very minimal set of configuration options at this stage. The first block configures the compiler flags which will be used and should be modified to reflect the architecture in use. The second block configures the location of portage related files. The next entry enables various features which are required for our configuration such as building binary packages. Finally we set some miscellaneous build options and the linguas we wish to use.

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CXXFLAGS="-O2 -pipe"

PORTDIR=/mnt/portage/portage
DISTDIR=/mnt/portage/distfiles
PKGDIR=/mnt/portage/packages

FEATURES="buildpkg sandbox collision-protect -preserve-libs"

PORTAGE_NICENESS=0
MAKEOPTS="-j4"

LINGUAS="en en_GB"

We also need to edit /etc/locale.gen to only generate the locale files which will be used on this installation. Here we have enabled ISO-8859-1 and UTF-8 locales for English as spoken in Great Britain.

en_GB ISO-8859-1
en_GB.UTF-8 UTF-8

Configuration of the build-space can be completed by selecting the correct system profile by using the eselect application as shown below. As this is a build-space for a server configuration we have selected profile 1 which is fairly minimal and thus suitable as the basis of a server configuration. If we were configuring a build-space for a workstation configuration profile 2, 3 or 4 would probably be a better choice as more of the recommended desktop use flags would be enabled by default.

Available profile symlink targets: 

  [1]   default/linux/amd64/10.0 

  [2]   default/linux/amd64/10.0/desktop 

  [3]   default/linux/amd64/10.0/desktop 

  [4]   default/linux/amd64/10.0/desktop 

  [5]   default/linux/amd64/10.0/developer 

  [6]   default/linux/amd64/10.0/no-multilib 

  [7]   default/linux/amd64/10.0/server 

  [8]   hardened/linux/amd64/10.0 

  [9]   hardened/linux/amd64/10.0/no-multilib 

  [10]  selinux/2007.0/amd64 

  [11]  selinux/2007.0/amd64/hardened 

  [12]  selinux/v2refpolicy/amd64 

  [13]  selinux/v2refpolicy/amd64/desktop 

  [14]  selinux/v2refpolicy/amd64/developer 

  [15]  selinux/v2refpolicy/amd64/hardened 

  [16]  selinux/v2refpolicy/amd64/server 

Building the binary packages

With the build-space configuration complete we can ensure that the build-space is up to date. The commands shown in the example below will ensure that the system is using the latest packages, that python and perl modules have been correctly updated, that any packages which are no longer required as dependencies have been removed and that dynamic linking consistency has been tested and, if necessary, packages have been reinstalled as required.

We can now build binary packages for everything in use by this build-space by issuing the commands below. The first will perform a pretend merge so that you can see which packages will be built.

We can also install a set of kernel sources which will be used by the clients of this build-space and any applications we install in the build-space which require access to kernel sources to build.

You will also need to configure and build a kernel image and modules inside each build-space before they are usable from any of the clients. Clearly kernel options which are compatible with all clients of the build-space should be chosen when configuring the kernel sources.

 

Once the binary packages for this build-space have been built we can exit the build-space as shown below.

You can now return to the beginning of this section and repeat the process for the workstation configuration and any other configurations which require their own build-space.