Migrating from no-multilib profile to multilib one

Published on

An outline of a migration of a Gentoo installation from no-multilib profile to a multilib one without a full reinstall.

Background #

I have two non-server machines with Gentoo installed. They were set up at different times and had different profiles, but have been helping each other out through binhost and distcc.

The profiles were:

I wanted to use Wine while maintaining the ability to use binhost to share some packages, plus I wanted to try out certain systemd features and migrate the laptop(and later desktop, once NVidia drivers support it) to Wayland.

Wine requires multilib, so a no-multilib to multilib migration would be required, something which is explicitly not supported as per the FAQ. In addition to that, desktop would need to be migrated to a systemd profile. For the sake of it, I decided to move to a hardened profile as well, but that is not required in the general case.

Typically posts on Gentoo forums recommend a reinstall instead of migrating. I had quite a few configurations that I wanted to keep and wanted to try my hand at this procedure, so I opted for something a little less invasive for the rest of the system.

This procedure took about a day of occasionally checking the status of emerge, so consider if the alternative approach of:

Would be faster in your case.

Note: at the time of writing, the Gentoo profiles are on version 17.1. This may not apply to future or past profiles.

Warning #

This procedure worked for me, but it may not work for you and produce a variety of disastrous results. Proceed at your own risk. And please make backups.

Procedure outline #

Working on the desktop(aka “host”) first:

  1. Set up a chroot location
  2. Unpack the tarball with the profile you want to end up on in that chroot location
  3. Plant the host’s /etc/portage/ directory inside chroot
  4. Ensure that buildpkg feature (wiki) is on inside chroot
  5. Update @world inside chroot to apply your portage settings
  6. Grab the built binary packages from chroot and place them somewhere where host can install them
  7. Switch profile on host to the target one
  8. On host install the built bootstrap packages (ones mentioned in scripts/bootstrap.sh inside Gentoo repo)
  9. Update the rest of the host’s packages using binary packages from chroot

On laptop, depending on the differences in hardware, only the last three steps may be needed.

Systemd migration (if required) can be done without chroot and after the host migration by changing the USE flags on host:

USE="${USE} -elogind systemd"

And updating the @world.

Some more details about the steps below

Chroot setup #

To set up a chrooted environment for Gentoo installation - refer to the installation handbook. Mount all needed locations inside chroot as if installing Gentoo and unpack the tarball inside chroot location.

Copy all files from host’s /etc/portage to /etc/portage inside chroot. This may overwrite the make.profile link. To set it back up, use eselect profile to point it at the proper profile.

Working inside chroot #

The first step is to enable buildpkg feature of portage inside chroot (if not enabled already). Add FEATURES="buildpkg" to chroot’s portage make.conf file. Now, whenever portage installs a package, a copy of the built package will be created as an archive in directory specified as PKGDIR in make.conf.

Those binary packages may be distributed to other machines, on which emerge can be run with:

To update the @world inside chroot and apply host’s portage settings, run emerge --ask --update --deep --changed-use @world

Moving packages from chroot to the host #

Copy all files from PKGDIR inside chroot’s make.conf to:

Continuing the work on host #

Note: this step is where the host’s packages are affected. Before continuing – ensure that you have backups

First, switch profile through eselect profile to the one you want to end up on.

Before continuing, read through bootstrap.sh script located in scripts/ directory in Gentoo’s main repo. This script may be used to create a bootstrapped installation from ground up (i.e. stage 1 > stage 2 > stage 3, see stage tarball article).

On host, install the binpkgs corresponding to the packages mentioned in the bootstrap script without recording them in the @world set. For packages like gcc, libc, binutils, run:

~# emerge --ask --oneshot --deep --newuse --verbose --getbinpkg sys-devel/gcc

Depending on the binhost presence, use either --getbinpkg or --usepkg, see man emerge. It is crucial at this stage that portage will install the binary packages built inside chroot.

Run eselect gcc list and make sure portage is using your newly installed gcc.

After the bootstrap packages are installed, you can test if your system can now build multilib packages by trying to build sys-apps/sandbox. If it fails to build with

configure:3707: error: C compiler cannot create executables

Then the system is still using non-multilib gcc, and probably the gcc from chroot was not installed on host.

After the bootstrap part is done, proceed to update the packages on host:

~# emerge --update --deep --newuse --ask --verbose --getbinpkg --with-bdeps=y @world

As above, --getbinpkg part depends on whether a binhost is used.

Migrating laptop #

After rebuilding packages on the first machine, you can switch the second machine to the new profile and use emerge with -k/-g to update it using the newly built binpkgs. Depending on the hardware differences between the two machines, some packages will need to be rebuilt on the second machine, which is where distcc can help.

Post-migration change: systemd #

To start using systemd, either switch the profile, or change the host’s USE flags to

USE="${USE} -elogind systemd"

And update the @world. Follow the rest of systemd article to configure the system.

If using genkernel – make sure you are using a newer(>=4.0.10) version of it, otherwise mounts could fail when booting.