[gentoo-amd64] Re: upgrade an old system

[Duncan]

Raffaele BELARDI <raffaele.belardi@××.com> posted 49FEAA27.1040708@××.com,
excerpted below, on  Mon, 04 May 2009 10:41:11 +0200:

> I need to bring up-to-date a Sempron gentoo box (march=k8) which was not
> updated for more than one year. At first I was hoping to use the binpkg
> generated on my main system (Athlon64 X2, march=athlon64) to do a quick
> update, but the arch's are not compatible.

march=k8 (aka opteron, aka athlon64, aka athlon-fx) is supposed to be a 
synonym, that is, identical to march=athlon64 (and the other akas 
above).  However, newer gcc versions also have march=k8-sse3, which will 
NOT be compatible with the older K8s.  Then there's amdfam10 (aka 
barcelona), which is newer still, including SSE4A, which won't be 
compatible with the older k8 or k8-sse3.

So march=k8 should be just fine with march=athlon64, provided of course 
that you didn't use other CFLAGS which might be incompatible, including 
-sse3.

But what what's much more likely to be happening is that your portage is 
too old to work with a newer tree and/or the newer profile the new 
machine is on.  That's particularly true if you were on stable, not 
~arch, as stable portage is already somewhat behind the latest features, 
in addition to that year.  In particular, if you have an old pre-
cascading profiles portage, it's stale indeed.  If the old profile is 
still around, perhaps you can update just portage, first.

It's also possible that the linked glibc or other (libstdc++ for C++ 
apps, ABI affecting CFLAGS such as -mregparm=X) is too different.

FWIW for the future, I'd suggest updating at least every six months or 
so, just to keep from getting in such binds.  But six-month updates are 
already likely to be more difficult than necessary.  Three-month updates 
are the most I'd want to go on a routine basis.  By a year out, indeed, 
grabbing the latest stage tarball and going from there, as you discuss 
below, is getting to be the most viable option.

> So I started an emerge -uDv system, it complained about linux-utils
> blocking coreutils, I unmerged the first one but had to interrupt the
> emerge with a shutdown, then the system failed to boot due to missing
> 'mount' executable...
>
> What I'll do now is boot from CD, save the old /etc, reinstall the
> system from a recent stage3, then use distcc to do a quicker emerge
> world. But while the main system has gcc-4.3.2, the stage3 contains
> gcc-4.2.1. According to distcc instructions, gcc should be the same
> version on all systems. So I probably need to update the gcc on the old
> system before starting the distcc. This will be LONG.
>
> Any other options I have?

As discussed above, it's likely your archs aren't incompatible after 
all.  Even the -sse3 versions might be compatible on many basic packages, 
those relatively unlikely to use floating point.  That binpkg idea might 
just work after all, at least for coreutils and the like, once you're 
using a reasonably modern portage, as you should be from a liveCD and/or 
stage tarball.

Also, I haven't used a stage tarball in some time and don't believe I 
ever used the Gentoo LiveCD (I did the install from Mandrake Linux, 
chrooting into the stage after unpack).  Thus I'm not sure of the precise 
details, but it may well be possible to do a quickpkg of the basic 
coreutils on the CD or from the stage, then set ROOT= appropriately and 
use the stage's or CD's portage to install that coreutils binpkg to the 
main system.

Also note that the binpkgs are tar.bz2 tarballs, with some extra metadata 
glued on the end.  Thus, in a recovery scenario such as this, once you 
have a compatible binpkg, you can simply untar it directly over the 
existing filesystem (taking care not to destroy config files, if any, 
back them up, etc, or extract only part of the archive, excluding say 
/etc and /usr/share).

Another alternative, if you trust a specific Gentoo/amd64 user, is to ask 
them to create a binpkg for you, specifying USE and CFLAGS as needed.  
The newer machines should be able to build the older stuff, once the 
CFLAGS, etc are set correctly.  Of course, you need to trust said user to 
give you a "good" binary, not some sort of malware.  Then they can email 
it to you, or stick it somewhere you can FTP it, or whatever.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman