I performed some updates on a server I manage which runs Gentoo today. There were a couple of hitches:

* Messages for package net-misc/neon-0.26.3:
* There are new features in this version; please beware that
* upstream considers the socks support experimental.  If you
* experience test failures (eg, bug 135863) then try rebuilding
* glibc. *
* Neon has a policy of breaking API across versions, this means
* that any packages that link against neon will be broken after
* updating. They will remain broken until they are ported to the
* new API. You can downgrade neon to the previous version by doing...

The first one, neon, doesn’t seem to pose a problem, because I also updated subversion. The second isn’t a big deal, because I mostly access the server remote. I also haven’t had any problems with kbd though, I just think its odd if failed to emerge.

Also updated an even older gentoo machine, but had some problems with mysql:

[ERROR] Fatal error: mysql.user table is damaged or in unsupported 3.20 format.

http://www.john-hunt.com/linux/2006/05/12/mysql-upgrade-breaking-things/

http://dev.mysql.com/doc/refman/5.0/en/mysql-upgrade.html

The MySQL bit was actually quite a pain, but eventually it worked out. I pretty much had to rebuild the user db, but thankfully I only had a few users - root and an average user. I used:

mysqld_safe --skip-grant-tables --user=root &

as suggested by John Hunt, but I’m posting it above because his Wordpress is doing funky things to the characters making it hard to cut and paste into a terminal.

It sure is an odd experience managing both gentoo and debian machines, they are so different! Again one of these machines is really old - running a Gentoo install from several years back. The biggest problem with that upgrade is that the machine lost track of the HD ids. No longer able to find /dev/sdaX, I had to rebuild /etc/fstab with the likes of this:

/dev/scsi/host0/bus0/target1/lun0/part1

I did run into some more minor issues too though:

* This package will overwrite one or more files that may belong to other
* packages (see list below). Add "collision-protect" to FEATURES in
* make.conf if you would like the merge to abort in cases like this. You
* can use a command such as `portageq owners / ` to identify
* the installed package that owns a file. If portageq reports that only
* one package owns a file then do NOT file a bug report. A bug report is
* only useful if it identifies at least two or more packages that are
* known to install the same file(s). If a collision occurs and you can
* not explain where the file came from then you should simply ignore the
* collision since there is not enough information to determine if a real
* problem exists. Please do NOT file a bug report at
* http://bugs.gentoo.org unless you report exactly which two packages
* install the same file(s). Once again, please do NOT file a bug report
* unless you have completely understood the above message.
*  * Detected file collision(s): *  *      /usr/sbin/python-updater
revdep-rebuild -X --library libexpat.so.0
* Any package that linked against the previous version
* of gettext will have to be rebuilt.
* Please 'emerge gentoolkit' and run:
* revdep-rebuild --library libintl.so.7
* PLEASE PLEASE take note of this
* Please make *sure* to run revdep-rebuild now
* Certain things on your system may have linked against a
* different version of com_err -- those things need to be
* recompiled.  Sorry for the inconvenience
* You have had multiple versions of perl. It is recommended
* that you run perl-cleaner now. perl-cleaner will
* assist with this transition. This script is capable
* of cleaning out old .ph files, rebuilding modules for
* your new version of perl, as well as re-emerging
* applications that compiled against your old libperl.so *
* PLEASE DO NOT INTERRUPT THE RUNNING OF THIS SCRIPT.
* Part of the rebuilding of applications compiled against
* your old libperl involves temporarily unmerging
* them - interruptions could leave you with unmerged
* packages before they can be remerged. *
* If you have run perl-cleaner and a package still gives
* you trouble, and re-emerging it fails to correct
* the problem, please check http://bugs.gentoo.org/
* for more information or to report a bug. *  *

This one reminds me of the pam / shadow dual-block:

*
* Your current setup is using the pam_stack module.
* This module is deprecated and no longer supported, and since version
* 0.99 is no longer installed, nor provided by any other package.
* The package will be built (to allow binary package builds), but will
* not be installed.
* Please replace pam_stack usage with proper include directive usage,
* following the PAM Upgrade guide at the following URL
*   http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml

What I did:

auth    include      system-auth
account    include      system-auth
password        include      system-auth
session         include      system-auth

And this is fine:

*  * If you have just upgraded from an older version of python you * will need to run:
*  * /usr/sbin/python-updater
*  * This will automatically rebuild all the python dependent modules * to run with python-2.4.
*  * Your original Python is still installed and can be accessed via * /usr/bin/python2.x. *

But I didn’t have python-updater, it was blocked by my current version: 2.3.5. This forum thread helped me figure out what to do:

emerge --nodeps -v =dev-lang/python-2.4.4-r5

Only after that could I emerge -C =dev-land/python-2.3.5 and emerge python-updater.

Running Gentoo is definitely more stressful for me than running debian from time to time, but at the same point, I also find it a bit more satisfying as well, as I fell like I’m more in control and able to make more precise decisions. Its a trade off I guess.

Upgrading linux from 2.4 to 2.6

Told you one of my gentoo machines was old:

* You need a kernel of at least version 2.6.9 * for NPTL support! *
* ERROR: sys-libs/glibc-2.6.1 failed.
* Call stack:
*            ebuild.sh, line 1701:  Called dyn_unpack
*            ebuild.sh, line  817:  Called qa_call 'src_unpack'
*            ebuild.sh, line   44:  Called src_unpack
*   glibc-2.6.1.ebuild, line  154:  Called eblit-run 'src_unpack'
*   glibc-2.6.1.ebuild, line  150:  Called eblit-glibc-src_unpack
*     src_unpack.eblit, line  117:  Called toolchain-glibc_src_unpack
*     src_unpack.eblit, line   55:  Called check_nptl_support
*     src_unpack.eblit, line   32:  Called die
* The specific snippet of code:
*                      die "Kernel version too low!"
*  The die message:
*   Kernel version too low! *
* If you need support, post the topmost build error, and the call stack if relevant.
* A complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.6.1/temp/build.log'. *
* GNU info directory index is up-to-date.

Its running 2.4.28-grsec-2.1.0. I’m now updating to a non-grsec kernel : sys-kernel/gentoo-sources-2.6.22-r9. I’ve already switched to a standard profile, and am already using a standard gcc profile, so I hope it will be OK. I’m not sure exactly what kernel configuration I’ll need though, so I’m very thankful that I have this machine hooked up to a KVM over IP box so I can easily choose the original kernel. :-)

I’ll probably check to see if I have a config for my 2.4 kernel, but I’m doubtful that it would be friendly to the 2.6 menuconfig. Since I compiled the 2.4 kernel, I’ve learned a lot about how its done. Gentoo was the platform I really learned how to compile a kernel on my own, but I’ve since done it many many times on my various debian boxes, to enable /dev/crypto via ocf-linux as well as trying to enable better via C7 acpi cpufreq capabilities . Thankfully, they do have a Gentoo migration to 2.6 guide . Most of it doesn’t relate to me, but I was glad to read it anyway, at least to learn that make oldconfig won’t work.

AWESOME! It worked, I’m now running Gentoo’s 2.6.22 kernel. :-)