Edward Tjörnhammar

Migrating from Gentoo to Funtoo

Published on 2011-08-16

I recent decided to switch from Gentoo to Funtoo, you know, just for fun. Breaking my systems without downtime is what I consider a good weekend night activity, whiskey included of course.

In order to switch you need to both get all the new build instructions and then rebuild everything already installed according to these. Generally speaking, managing to swtich glibc, gcc, init and baselayout is all of the userland stuff which is really needed in order to constitute a switch. Should you manage to swtich glibc and gcc then you are most likely in the green. So anyway you first set out to get all of the ebuilds and then reinstall portage, making sure it understands it all. I was using portage version 2.1.10.3 but still managed to do the switch. Then we install glibc, gcc, sysvinit, baselayout and then the rest of your packages.

Migration

So.. first we fetch the current funtoo tree.

cd /usr
wget http://ftp.osuosl.org/pub/funtoo/funtoo-current/snapshots/portage-current.tar.xz
mv /usr/portage /usr/portage_gentoo
tar xvJf portage-current.tar.xz
cd portage
git checkout funtoo.org
emerge portage

You’ve just changed all the ebuilds and made the manifests incompatible with Gentoo’s version of portage. Funtoo portage manifests¹ doesn’t contain hash values for internal resources, this means no AUX, MISC or EBUILD entries in the manifests. So you will be getting a bunch of manifest errors. Like so:

Calculating dependencies
  ...
 * Missing digest for '/usr/portage/media-libs/libmpeg2/libmpeg2-0.5.1.ebuild'
  ...

These are, of course, solved by regenerating the manifest and then emerging portage. So lets dump all error messages, i.e. the manifest errors to a temporary file and regenerate the manifest using the ebuild command:

emerge portage -pv 2> /tmp/digests
for ebuild in `awk '{print $6}' /tmp/digests | tr -d \'`;do ebuild $ebuild digest;done

You might have to rerun these commands two or three times. When this is done you might still get errors like:

!!! All ebuilds that could satisfy "virtual/yacc" have been masked.
!!! One of the following masked packages is required to complete your request:
- virtual/yacc-0::gentoo (masked by: corruption)
          ...

Which is really just the same kind of manifest error, so lets fix that

ebuild /usr/portage/virtual/yacc/yacc-0.ebuild digest

You might need to alternate between the two methods untill all manifest errors are cleared. After clearing all manifest errors we can install funtoo’s version of portage.

echo "check_certificate=off >> /etc/wgetrc"
emerge portage

Now that we have funtoo’s portage installed it means we can scrap the generated manifest files and then sync up the local tree.

git checkout -f
emerge --sync

And now we have back the minified manifest ebuild tree.

Before we continue with the base system installation make sure you update all system configs.

dispatch-conf

Reinstall base system

Lets do the classical gentoo stage1 pre install (kinda..)

emerge glibc && \\
emerge gcc && \\
emerge baselayout coreutils binutils sysvinit && \\
locale-gen && \\
emerge system

I prefer to do things the paranoid way.. So now you’ve got a compiled base system which should be funtoo specific. In order to continue we need to reinstall all other packages, since these are likely to depend on the old base system.

You can do this two ways, using

revdep-rebuild && emerge -D world

Or using the more volatile and insane way:

emerge --emptytree world

When this completes the migration is complete.

>>> Emerging (25 of 1010) dev-libs/kpathsea-6.0.1_p20110705

Glibc Downgrade (Probably not relevant for you)

I had to downgrade glibc! Going from 2.2.something to 2.1.bleh which is not a good thing and likely to really ruin your day. Portage will not even let you do this so you must make portage lose all data about the previously installed glibc package.

rm -Rf /var/db/pkg/sys-libs/glibc

Trying to emerge gcc fails since cc1 is missing a vital library, checking with ldd reveals:

ldd /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.5/cc1
	linux-vdso.so.1 =>  (0x00007fff3f3ff000)
	libmpfr.so.4 => /usr/lib64/libmpfr.so.4 (0x00007f3fc66a0000)
	libgmp.so.3 => not found
	libc.so.6 => /lib64/libc.so.6 (0x00007f3fc633a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3fc68f5000)
	libgmp.so.3 => not found

The linker doesn’t know about libgmp.so.3 anymore! Lets fix that, the quickhack way.

ln -s /usr/lib64/libgmp.so.10.0.2 /usr/lib64/libgmp.so.3

and we recheck with ldd to confirm that everything is dandy

ldd /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.5/cc1
	linux-vdso.so.1 =>  (0x00007fff2a392000)
	libmpfr.so.4 => /usr/lib64/libmpfr.so.4 (0x00007f9161a35000)
	libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00007f91617c5000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f916145f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9161c8a000)

Seems pleasant enough, just cross your fingers that gcc doesn’t make a call there.. before continiung be sure to set MAKEOPTS=“-j1” and CFLAGS=“-O2 -pipe” specific to gcc since gcc has a tendency to bug out doing parallell, and/or march:ed, builds.

mkdir -p /etc/portage/env/sys-devel
cat > /etc/portage/env/sys-devel/gcc <<__GCCENV__
CFLAGS="-O2 -pipe"
MAKEOPTS="-j1"
CXXFLAGS=\$CFLAGS
__GCCENV__

you can probably get away with a higher makeopts but I’ve never really cared enough to dive deeper into this. All I know is that gcc builds have broken on me to many times for me to change this.

Comments