I had always resisted runing Linux on the PowerMac, thinking that the last thing I needed was yet another Linux box in the house. I had tried a couple of times, but it was in the early days of support for the liquid cooling system in the dual-2.5Ghz model and those attempts failed dismally. I figured that by now those issues would be resolved and I would have a much better time.

I assumed that Yellow Dog was still the ‘benchmark’ PPC Linux distro, so I went to their site. I saw a lot of data there about PS3 and Cell; it seems that YDL is transitioning to the cluster and/or research market by focussing on Cell.

The next thing I discovered is the lack of distributions that have a PPC version, even as a secondary platform. My old standby Gentoo still supports PPC, as does Fedora (I think: I saw a reference to downloading a PPC install disk, bit didn’t follow it), but every other major distro has dropped it — openSUSE, for example, with their very latest release (their download page still has a picture of a disc labelled “ppc”, but no such download exists, oops). I guess that since the major producer of desktop PPC systems stopped doing so, the distros saw their potential install base disappear. Unfortunately for those distros, I can see the reverse happening: now that Apple has fully left PPC behind, plenty of folks like me who have moderately recent G4 and G5 hardware and who still want to run a current OS will come to Linux looking for an alternative… I guess time will tell who is right on this one.

So I went to install Gentoo, and to cut a long story short I had exactly the same problem as before: critical temperature condition leading to emergency system power-off. I found that if I capped the CPU speed to 2Ghz I could stay up long enough to get things built, but then the system refused to boot because it couldn’t find the root filesystem. Probably something to do with yaboot, SATA drives and OpenFirmware. So again I’m putting it aside.

My next plan was to treat it as a file server. Surely a BSD would support my G5 hardware: after all, Mac OS X is BSD at heart… Well, no. FreeBSD has no support for SATA on ppc, OpenBSD specifically mentioned liquid-cooled G5s as having no support, and I don’t think I saw any ppc support on NetBSD more recent than G3 [1].

This is one of the things that annoys me about the computer industry: that somehow it’s okay to so completely disregard your older releases. What if the automotive industry worked that way?

So I may yet try Fedora, or give the game away for another year or so and see what the situation looks like then.

[1] I may have mixed up a couple of these details.

Edit: Gentoo’s yaboot has managed to make it so that I can’t boot Mac OS X on the machine any more.  Oh dear.

The first was an update to the spine resource poller, part of the Cacti project but installed separately (it used to be called cactid). Turns out that somewhere between 0.8.7a and 0.8.7b, bugs were introduced that made spine unreliable on 64-bit systems. The update brought in a SVN version of spine which, while still labelled 0.8.7a, must have been somewhere after one or more of the bugs came in. The symptom was that every data value obtained via SNMP was garbage and ignored.

The second issue was strange — graphs were getting generated (even those for which there was no data) but there was no text on them! Titles, margins, legend, axes, all were blank. Some posts pointed to a problem accessing the TTF font file provided with rrdtool, but the actual problem turned out to be the upgrade to rrdtool 1.2.28 which introduced different parameters for the configuration of text attributes in graphs — and a corresponding “feature” that suppressed any text output if the new parameters were missing.

So what does “~” have to do with this? The software on your system is built according to the architecture of your machine. In Gentoo, this is called your “arch” (for architecture) and is usually “x86″ or “amd64″. Gentoo implements a “testing branch” in an arch which starts with “~”; if a pre-release version of a package exists in portage you can bring it in with the “~x86″ keyword. The nice thing about this is that you don’t have to enable a testing repository across your whole system — you can enable the ~ keyword for specific packages on your system, and everything else stays stable.

Unfortunately, this flexibility has a cost. The “amd64″ arch seems to lag a bit behind “x86″ in terms of packages being marked stable or just simply having packages available. This means that just to get things installed, it’s necessary to flag packages with “x86″, “~amd64″ or even “~x86″. This flagging is easily done — almost too easy in fact, as it creates a problem later on when the package you actually set the keyword for eventually becomes stable and you don’t need the keyword set any more. It’s a manual process to revisit the keywords you’ve set and verify that they are still needed (and you know how well manual processes work).

Some time ago I started adding comments to the Portage config file where keywords are set, trying to explain why I set the flag: “to bring in version 1.2.34″ for example. That way, if I ever do get around to manually auditing the package.keywords file, I’ll be able to check if some of the keywords are still needed. Still a manual review though.

So in the case of rrdtool and spine, I had set the “~” keyword some time in the past for some reason, possibly to get early access to a bug-fix ebuild. With no established method to revisit the keywords, I continued to pull in unstable versions of packages long after the packages I really needed had been marked stable. Eventually, it bit me.

The pre- and post-upgrade chacklist grows some more…  :)

I run Gentoo on both my “servers” at home. At the time I got my dual-Opteron, Gentoo was the only “free” distro around that had a x86_64 version ready to roll. When it came time to build my phone-and-TV server, it got Gentoo as well because it was the only way I could get the right combination of all the versions of code (Apache, PHP, Asterisk, MySQL, MythTV, ccxstream, etc) that I needed and have them all maintained in the distribution’s package management system (Debian has no ccxstream package, for instance). I don’t run Gentoo because I’m a ricer. Portage has the right package mix for me, and its ability to control the configuration of packages through USE flags gives me an opportunity to control the options that are enabled in the packages I install.

I have blogged previously about some hardware I bought that I haven’t been able to put to good use. I decided to give it another try by building a Gentoo system on it, because an ebuild for the bleeding-edge ATI driver that is supposed to support the graphics chipset in this clunker is in Portage.

Let me say, it’s been a while since I built a Gentoo system from scratch. You don’t even do it truly from scratch anymore either — the days of starting with a stage-1 tarball are over apparently, and stage-3 is always the way to go. Even so, this system took a whole weekend to get to the stage where I could log on and get a KDE desktop (to be fair though, there was a lot of kicking off an emerge, coming back to it a couple of hours later to find it had died ten minutes in, fixing the issue and restarting… so it wasn’t 48 hours solid time spent).

Unfortunately the ATI driver still doesn’t support XVideo on this chipset, so I still can’t use this board for its intended use as a MythTV frontend (I do have an old PCI nVidia 5200 card that, even though it’s at least three years old, I’m sure will run rings around this stinking ATI 1250). So the point of the whole exercise was, unfortunately, lost. But I did get a refresher in the amount of effort a Gentoo build would take.

After that weekend’s effort, I was a bit put off by the thought of building up an entire desktop system from scratch. When I thought about it though, my concerns were for nothing. The compiling? The kind of systems I’m building on (modern dual-core chips) will chew through compiling most software in a snap — heck, for simple packages I can install on a Gentoo system quicker than yumex can initialise its repositories. I’ve got running systems I can use as a model to get USE flags right, and my NFS-shared Portage tree means that I sync once and use everywhere (even downloading source packages happens only once).

Plus, now, I know Gentoo. Sure, APT on a Debian-based distro is nice, but I still am lost when it comes to the right dpkg command to locate what package provides a certain file, for instance. I get frustrated when something fails to build on Gentoo because some other package wasn’t built with the right USE flag, but I know how to fix that, and its fixed in a flash. Likewise for rebuilding some system library that causes a bunch of other packages to fail without warning, and likewise for the strange b0rkedness that happens in Portage sometimes when packages change versions (gnupg is a recent example). I know how to fix Gentoo when it breaks — I can’t say that with much confidence for other distros.

Some might say “use a distro that doesn’t break in the first place”, which is a fair comment. But if I have to choose between an occasional hiccup and missing functionality, then hand me the Eno (Pepto-Bismol, Tums, etc)…

Which brings me to my dilemma — apart from the fact that I have crappy unaccelerated non-video graphics and I haven’t been able to run Compiz for ages (a problem that Gentoo wouldn’t solve for me anyway), Ubuntu isn’t really broken for me. There’s not a compelling reason for me to throw Gutsy out, and with Hardy around the corner there’s even less reason to switch right now.

So, I’ll wait. And watch. Having to work on more Red Hat systems at work is reacquainting me with their particular mojo, perhaps even enough to try Fedora. Also, I’ve just scraped together some parts to make an openSUSE 10.3 build for something work-related so I’ll catch up with things there (since I haven’t really seen a SUSE system as a desktop since SuSE Linux 7).

I love this about Linux — freedom to choose!

Nothing was being logged either, as I was trying to find out what was going on and why the processes weren’t starting. It was as if it was suddenly ignoring all my configuration files!

Careful inspection of some output from eix showed the problem: Jabberd 2 has been moved to its own ebuild (jabberd2), and the highest version in the jabberd ebuild is now a 1.4.4-something. Not only that, they’ve hard-masked jabberd2:

# Krzysiek Pawlik  (08 Oct 2007)
# Masked untill the split from net-im/jabberd is complete.
# See bug #178055 and bug #195091
net-im/jabberd2

Looks like the last time I emerged I downgraded my Jabberd 2 to 1.4. No wonder the thing was not responding to me.

This is the kind of thing that happens on Gentoo from time-to-time. It’s why I started a regular sync of portage and email-output-of-emerge-pretend-world process: so that I didn’t get too far behind and have a heap of these things to sort out. This one got me off guard though.

Note to self: pay closer attention to emerge output in future!

Knowing that generic error can apply to a missing file that the program is trying to execute, I checked what type of file I was looking at: file reported a dynamically linked program.  Great, run ldd to find out what it wants: ldd reports “not a dynamic executable”.  Oh dear.  It was starting to look like a long night was ahead.

I jumped on the Googleweb and discovered that others had encountered the problem I was seeing, but the hits were all a couple of years old.  Their problems seemed to be caused by missing 32-bit libraries on a 64-bit system.  How could this happen?  In older Gentoo releases you had to choose multilib, but according to most of the doco all profiles are multilib unless you choose a “non-multilib” profile (this explained the fact there were few-to-no recent hits for the issue).

Recently I had switched to the hardened profile…  I had a look, and there is a separate “multilib” profile in hardened.  So is the doco wrong: are all profiles multilib except ones called “non-multilib” AND except hardened because they have a different rule?

I had two choices then, try out the hardened multilib profile, or switch back to the previous profile I used.  Considering I hadn’t enabled any Hardened features and don’t really have time to figure it all out at the moment any (I only did it to get rid of the “unsupported profile” warning I get every time I merge a package), I copped out and switched back to the old profile.

Then I had the next issue: I couldn’t use the non-multilib gcc and glibc to build multilib versions of gcc and glibc.  The gcc build complained about a missing 32-bit header (should have been part of glibc) and the glibc build complained that cpp failed sanity test.  Again the Googleweb came to the rescue, pointing me to a Gentoo repository containing binary packages of gcc and glibc that I could apply.  They allowed me to rebuild my own gcc and glibc.

At this point I found that the vmware-config.pl script could run again.  I was BACK!  I started VMware services, ran the managment console, and started my VMs.

I think I get a bit complacent with my home gear sometimes; switching profile to hardened was something I almost did on a whim, and it’s bitten me fairly badly.  Lesson learned.

I still have the Gentoo bug, so the idea of a Gentoo system where someone else has done the work of gluing all the packages together is very appealing.  It installs nicely — like many distros they use the “Live CD” approach (where you boot from a CD or DVD into a running system that you can try-before you buy, so to speak, before deciding if you want to commit it to your hard drive), and use Red Hat’s Anaconda installer to do the work of getting the system onto your disk.

It is very much a gamers system.  Some popular Linux games are pre-installed, including Battle of Wesnoth, which has already cost me a decent amount of leisure time.   They include things like the NVidia and ATI binary drivers, AIGLX or XGL for desktop effects thanks to Beryl, and other things like Google Earth and Kerry Beagle preinstalled.  They also have support for Xen and KVM/QEMU virtualisation, and the virt-manager tool for managing virtual machines.

I started to wonder though: do they maintain a separate Portage infrastructure for their own stuff, or is it vanilla Gentoo?  The answer is that for the most part it’s vanilla Gentoo.  They use Layman to track their own Portage overlay, but behind it is vanilla Gentoo, which means that at a time like this, where a new release of Sabayon is just around the corner, doing an emerge world is much more likely to get stuff from Gentoo Portage than the Sabayon overlay — especially since the testing “~” keyword is set by default.

I really like what they’ve done, but to me having it backed by Gentoo Portage means that you’re back to riding the knife edge that is the Gentoo “rolling release” strategy.  And after a couple of updates, you’re running Sabayon Linux in name only.

This is all based on very early experiences mind you.  I haven’t had a proper chance yet to settle in and see how some of this stuff works in real life.  I think I might sit tight until the 3.4 release goes out (should be soon), and get stuck into the doco then.

First a bit of history: this machine is a dual-processor Opteron system, and as far as free (as-in beer) Linux distros Gentoo was about the only one that had a x64_64 port available at the time.  Over time it’s grown to have a lot of stuff on it (applications, not just the data), so changing to a different distro will be FAR from trivial.  I know that Gentoo isn’t really a server distro, but this install has a lot of momentum behind it now…

Where was I?  That’s right: VNC.  Something else I really like is VNC.  I had a neat setup on my box that worked like a terminal server: you connect using your VNC client, get a login window from X, do some work, then log out when you’re done.  No having to set up a permanently-running X desktop for every user that might want to connect!  This was set up and working really well, until I just went to use it (after having not used it for a while) and found it broken.  Seems that some other change I’d made since last using it caused the Xvnc process to start segfaulting.  Rebuilding it made no difference.

This led me on a wild ride through Google searches, fora and mailing list archives (with a detour throug the LKML, which I’ll meniton later) to discover that in current versions TightVNC doesn’t play well on 64-bit distributions and that it’s been a known problem for months with no real end in sight.  On someone’s recommendation I removed TightVNC and switched to the RealVNC package, and things started working again (once I fixed a different problem in KDM caused by Gentoo’s configuration file management).

I’m finding more and more that I have less and less time to frig around with this stuff.  I need this kit to JUST WORK, and a bleeding edge distro like Gentoo isn’t helping me.  Perhaps I need to change to using the Gentoo Reference Platform (GRP), which is a pre-built-binary version of Gentoo.  But with the GRP, much of the advantage of Gentoo (custom-built packages, flexibility) is lost.

I guess I’ve been wanting to have my cake and eat it too — I want nicely-tuned custom-built packages, but I want stability and proven integration as well!  I’m going to have to give something up, and I think that stability is going to win.

I’m attracted to CentOS, the respin of Red Hat Enterprise Linux.  I guess I could have a play with that on some other kit and see how it goes…