HOWTO: Back from an amd64 no-multilib to a multilib system.

[wykladowca]

I was recently forced to recompile some 32-bit libs, since my new processor supports the hardware accelerated virtual machines technology, which I would like to use. Reinstalling the system from scratch would be painful, so I came up with a different solution, which I would like to share with you.

What we need for building a multilib system is gcc and glib able to compile 32-bit executables, but to compile those apps in this configuration we need gcc and glib able to compile 32-bit executables. Because of this recursion, a simple changing of the profile and recompiling will not work. However, we can use an another gentoo installation to give the things a little push.

Login as root, and obtain the most recent stage3 tarball (wget it from the favorite mirror). Next type few commands, that will set up an environment to which you will later chroot:

Code: Select all

mkdir /helper
tar -xapf stage3-amd64-*.tar.bz2 -C /helper
mkdir /helper/usr/portage
mount --bind /usr/portage /helper/usr/portage
mount --bind /dev /helper/dev
mount -t proc none /helper/proc
mkdir /helper/target
mount --bind / /helper/target

Before chrooting to the newly untared system, adjust profile of your main system

Code: Select all

eselect profile list
eselect profile set [number_of_selected_profile]

If you use paludis, remember that it stores the profile for repositories in its own configuration files.

Back to chrooting

Code: Select all

chroot /helper
mount -t devpts devpts /dev/pts

And now emerging of gcc and glibc. If you want, at this point you may check the sub-system portage profile or adjust its make.conf (and set makeopts), but skipping those points rather won't be fatal.
If you use stable branch type:

Code: Select all

emerge --root=/target --root-deps=rdeps gcc glibc

And for testing branch, type:

Code: Select all

ACCPET_KEYWORDS="~amd64" emerge --root=/target --root-deps=rdeps gcc glibc

After emerge finished, type "logout" to get out of the chrooted environmet.

Although the described process will not provide you with a complete multilib system, the rest of needed steps (e.g. emerging libraries) can be made from the main system, since the basic tools are available from this point.*

The clean up code is

Code: Select all

umount /helper/dev/pts /helper/dev /helper/proc /helper/usr/portage /helper/target
rm -R --one-file-system /helper
unlink stage3-amd64-*.tar.bz2

Remember, it is always good idea to backup things! (I have been running altered system for few hours now, so I am not 100% sure if I did not brake down anything)

*-in order to compile virtualbox-ose I needed also emul-linux-x86-baselibs and emul-linux-x86-xlibs

[mimosinnet]

I have been recently been in a similar situation. I had a no-multilib amd64 and I needed a multilib system. I successfully followed the Howto switch to multilib in the HOWTO_AMD_64 article in the old gentoo wiki.

Cheers!

[sera]

Get glibc and gcc from tinderbox and "emerge -K" them is yet another possibility to get things going.

[sips]

Get glibc and gcc from tinderbox and "emerge -K" them is yet another possibility to get things going.

Yep, that seems the easiest way.
I just did it yesterday (also included sandbox from tinderbox) and after some rebuilds, everything working as expected.

[eyoung100]

Get glibc and gcc from tinderbox and "emerge -K" them is yet another possibility to get things going.

Yep, that seems the easiest way.
I just did it yesterday (also included sandbox from tinderbox) and after some rebuilds, everything working as expected.

That was the easiest changeover I've ever had:

1. Code: Select all

   eselect package-manger set portage

   (in case you're a paludis guy) --pbin is not in the same binary format

2. Code: Select all

   rm -vR /etc/paludis

3. Code: Select all

   emerge -K glibc

4. Code: Select all

   emerge -K gcc

5. Code: Select all

   emerge sandbox

6. Code: Select all

   ./portage2paludis.bash

   get script
7. rebuild empty tree, a.)emerge -eav world, or b.)paludis -i --dl-reinstall always --continue-on-failure if independent installed-packages

8. Code: Select all

   eselect package-manager set paludis

[hardly]

This was a big help. :-)

[jkroon]

Another mechanism, which I used yesterday before someone pointed this out was to use my laptop (which is of similar arch) to build binary packages for the server I had which had a broken gcc (reason unknown). Firstly use gcc to figure out what -march=native would actually set:

Code: Select all

gcc -E -v -march=native -</dev/null 2>&1 | grep cc1

This will output something like:

Code: Select all

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2

Then use emerge -pv to figure out what exactly will be required to "upgrade" the specific broken package, eg:

Code: Select all

morpheus ~ # emerge -pv sys-devel/gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-devel/gcc-4.5.3-r1  USE="cxx mudflap nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj* -graphite -gtk* (-hardened) (-libffi) (-libssp) -lto (-multilib*) -multislot -nls -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

 * IMPORTANT: 6 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

Before I started there were some additional packages, so I you need to try and match CFLAGS, as well as USE actually (which I did not, which is why the gcj and gtk flags above is wrong now, also laptop is multilib which the server is not. So on the laptop I then executed:

Code: Select all

CFLAGS="-O2 -mcpu=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -march=core2" emerge -1avB =dev-libs/mpc-0.8.2 =sys-devel/gcc-4.5.3-r1 ...

From there you can copy the binary packages (now residing in /usr/portage/packages probably) over to the other system using whatever mechanism you prefer, I like rsync:

Code: Select all

# rsync -rvP /usr/portage/packages/ root@remsystem:/usr/portage/packages/

Then on the broken system:

Code: Select all

# emerge -Kav sys-devel/gcc

Which should now insist it wants to install a bunch of BINARY packages. If so, proceed, and you should now have a fully functional system again. Obviously this assumes your python is still OK. If not, well, good luck, I believe there are some recovery tarballs you can use in those cases, but generally it's a harder problem to solve.

[Alakhai]

Thanks it worked for me!