So it’s the end of the KDE monolith for me. I’ve come to like KDE and use it as my primary desktop over the years, but everything must come to an end. Never fear, I’m not switching to GNOME or Xfce (which kicks ass), but just going with the split ebuilds.

So basically, if, like me, you installed the monolithic KDE in Gentoo, circa 2005 and are now looking to upgrade to KDE 4.2.x, here’s the easy way to do it. Be warned that all your KDE 3.5.x apps will disappear, but your data will remain. For example, the new Kmail 4.2.3 replaced Kmail 3.5.9 but left all my email intact.

A caveat, you might need to install KDE 3.5.10, which is the last KDE 3.x version out there, if you intend to run apps such as Kile or Krusader, which rely on KDE 3.5 libraries. Luckily, Gentoo works with slots, which allow you to have KDE 3.5.10 and 4.2.3 installed concurrently.

So, first unmerge that evil monolithic KDE (from a terminal, of course, not within KDE, I’m not responsible if you do so)

emerge -C kde

emerge --depclean -a

Clean out everything you don’t need, trim the list if you wish.

Now, check the availability of the KDE version  you require with eix:

eix -e kdebase-meta

You should see both 3.5.10 and 4.2.3, which is the latest one as of this writing. Now use autounmask to unmask them both, at least on the x86 platform:

autounmask kde-base/kdebase-meta-4.2.3

Let this run for a while, it takes around 20 minutes. Then emerge it and you should have a working kde 4.2.3:

emerge --newuse =kdebase-meta-4.2.3

Once you’re in your new KDE, you’ll see that many apps that worked before no longer do so, such as Kmplayer and Kile. Just unmerge the previous monolithic KDE 3.5.9 versions and emerge the KDE 3.5.10 equivalents

emerge -aC kdegraphics

autounmask kde-base/kdegraphics-meta-3.5.10

emerge =kdegraphics-meta-3.5.10

And there you have it, a seamless upgrade from monolithic KDE 3.5.9 to a split ebuild KDE 4.2.3 on Gentoo. Enjoy.

I ran into some troubles with Gentoo and glibc over the weekend. Here’s what fixed it, in case it helps anyone out in the future.

Why it broke:

Someone upgraded glibc from 2.6 to 2.9_p20081201. It’s masked, and what’s worse, installing it moves the old glibc libraries from /usr/lib to /usr/local/lib, which is a most un-Gentoo location.

Additionally, the famous e2fsprogs circular bug occurred, which can be fixed by following these steps:

quickpkg com_err ss e2fsprogs &&
emerge -uDNf world &&
emerge -C com_err ss e2fsprogs &&
emerge e2fsprogs &&
emerge -uDN world &&
revdep-rebuild #(if necessary)

However, having a new glibc breaks the e2fsprogs emerge with the following message:

1. /usr/local/lib/libdl.so.2: undefined reference to `_dl_tls_get_addr_soft@GLIBC_PRIVATE‘
2. The ebuild environment file is located at ‘/var/tmp/portage/sys-fs/e2fsprogs-1.41.3/temp/environment‘.
3. A complete build log is located at ‘/var/tmp/portage/sys-fs/e2fsprogs-1.41.3/temp/build.log‘.
4. collect2: ld returned 1 exit status
5. make[2]: *** [debugfs] Error 1
6. make[2]: Leaving directory `/var/tmp/portage/sys-fs/e2fsprogs-1.41.3/work/e2fsprogs-1.41.3/debugfs’
7. make[1]: *** [all-progs-recursive] Error 1
8. make[1]: Leaving directory `/var/tmp/portage/sys-fs/e2fsprogs-1.41.3/work/e2fsprogs-1.41.3‘
9. make: *** [all] Error 2
11. ERROR: sys-fs/e2fsprogs-1.41.3 failed.
12. Call stack:
13. ebuild.sh, line   49:  Called src_compile
14. environment, line 2449:  Called die
15. The specific snippet of code:
16. emake COMPILE_ET=compile_et MK_CMDS=mk_cmds || die;
17. The die message:
18. (no error message)
20. If you need support, post the topmost build error, and the call stack if relevant.

So, I asked on #gentoo but got no answer. Not because they didn’t help, but because it stumped them as well. So here’s my fix.

Symbolically link /usr/local/lib/libdl.so.2 to /lib64/libdl.so.2. Then emerge e2fsprogs. This will fix the problem.

ln -snf /lib64/libdl.so.2 /usr/local/lib/libdl.so.2

emerge e2fsprogs

Note that, after this, /usr/local/lib/libdl.so.2 will point to /usr/local/lib/libdl.so as before. Portage fixes this every time it runs, so emerge everything except for e2fsprogs before this fix, then emerge e2fsprogs and you can boot again. So to summarize:

If you upgrade glibc and this breaks the e2fsprogs compilation, temporarily make libdl.so.2 point to the new libdl.so.2 and e2fsprogs will compile. This will restore the core utilites such as  fsck and mount, thereby letting you boot again.

I’m a Gentoo user (but not a Gentoo ricer) and last week, I noticed all sorts of aberrations with the emerge command:

1. Emerge stalling at a random point during “emerge -uD world“. Processor usage went down to 0% and disk I/O shot up to 1011 MB/sec. This would continue for a few minutes and the system would eventually become unresponsive and required a hard reset
2. Emerge stopping at a random point with the error that the root partition was mounted read-only and thus /var/tmp/portage was unwriteable to.

So of course, I booted into a livecd and ran e2fsck on the root partition: / , /dev/sda2 in this case. There were no errors with the filesystem. After some investigation and asking in #gentoo, I realized that my disk had developed some faults and these weren’t filesystem faults, but actual physical drive problems. This left me with no choice but to migrate the / partition to my 2nd drive.

I fired up qtparted and made a 50 GB ext3 partition on my second hard drive, /dev/sdb6. I mounted it at /mnt/newroot and at this point I was still running off /dev/sda2 as root, but in a root shell I typed:
cp -ax / /mnt/newroot

This copied over all my files, with some errors about copying files from /proc and /sys which I ignored. This took around 30 minutes for the 12 GB on /.

Once this was done, I deleted the contents of /proc and /sys on the new root. Then I edited /etc/fstab to mount /dev/sdb6 as the new root. One last change was in /boot/grub/grub.conf, which needed the root to be changed from root=/dev/sda2/ to root=/dev/sdb6/.

With everything done, I rebooted into my new root and everything worked, right off the bat. However there was one slight bug, the /etc/fstab needed to be modified on the new root as well. You could modify /etc/fstab before copying it over to avoid this.

I realize that the best way to do this would have been to reboot into a livecd and then copy my / over, thereby avoiding the cp errors with the files in /proc and /sys, as well as having to delete them later. But this lazier approach saved me one reboot. I suppose you could have copied over all the folders explicitly and simply ignored /proc and /sys too.

One important caveat: my /boot partition is on a completely different partition, /dev/sda4. This helped me immensely, I’m not sure how this would affect bootability if my /boot folder actually contained my kernel. Maybe one would have to modify initrd? I’m not sure.

Anyway, it was painless and straightforward, hope it works out for you if you ever try it.