View previous topic :: View next topic |
Author |
Message |
wykladowca n00b
Joined: 27 Mar 2010 Posts: 3
|
Posted: Sat Mar 27, 2010 9:21 pm Post subject: HOWTO: Back from an amd64 no-multilib to a multilib system. |
|
|
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: |
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: |
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: |
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: |
emerge --root=/target --root-deps=rdeps gcc glibc
|
And for testing branch, type:
Code: |
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: |
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 |
|
Back to top |
|
|
mimosinnet l33t
Joined: 10 Aug 2006 Posts: 713 Location: Barcelona, Spain
|
Posted: Thu Apr 01, 2010 3:00 pm Post subject: |
|
|
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! |
|
Back to top |
|
|
sera Retired Dev
Joined: 29 Feb 2008 Posts: 1017 Location: CET
|
Posted: Thu Apr 01, 2010 7:00 pm Post subject: |
|
|
Get glibc and gcc from tinderbox and "emerge -K" them is yet another possibility to get things going. |
|
Back to top |
|
|
sips n00b
Joined: 08 Apr 2008 Posts: 31
|
Posted: Tue Aug 10, 2010 1:29 pm Post subject: |
|
|
sera wrote: | 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. |
|
Back to top |
|
|
eyoung100 Veteran
Joined: 23 Jan 2004 Posts: 1428
|
Posted: Tue Jan 25, 2011 11:17 pm Post subject: |
|
|
sips wrote: | sera wrote: | 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:
Code: | eselect package-manger set portage | (in case you're a paludis guy) --pbin is not in the same binary format
Code: | rm -vR /etc/paludis |
Code: | ./portage2paludis.bash | get script
rebuild empty tree, a.)emerge -eav world, or b.)paludis -i --dl-reinstall always --continue-on-failure if independent installed-packages
Code: | eselect package-manager set paludis |
_________________ The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper |
|
Back to top |
|
|
hardly n00b
Joined: 30 Jan 2010 Posts: 26
|
Posted: Sun Aug 14, 2011 2:17 am Post subject: Thanks. |
|
|
This was a big help. :-) |
|
Back to top |
|
|
jkroon Tux's lil' helper
Joined: 15 Oct 2003 Posts: 110 Location: South Africa
|
Posted: Mon Jan 02, 2012 7:17 am Post subject: |
|
|
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: | gcc -E -v -march=native -</dev/null 2>&1 | grep cc1 |
This will output something like:
Code: | /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: | 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: | 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: | # rsync -rvP /usr/portage/packages/ root@remsystem:/usr/portage/packages/ |
Then on the broken system:
Code: | # 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. _________________ There are 10 kinds of people in the world,
those who understand binary and who don't |
|
Back to top |
|
|
Alakhai Apprentice
Joined: 16 Oct 2003 Posts: 151
|
Posted: Sat Mar 17, 2012 8:06 pm Post subject: |
|
|
Thanks it worked for me! _________________ Gentoo Linux 64Bit User |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|