LWN.net Logo

Gentoo Linux on AMD64

December 17, 2004

This article was contributed by Ladislav Bodnar

After having installed (been sufficiently impressed by) the AMD64 ports of both Debian Sid and Fedora Core 3 (see Debian on AMD64 and Fedora Core 3 on AMD64), we expected the same from our third victim - Gentoo Linux. Not only is Gentoo a distribution designed to be compiled locally and optimized for the system it is being installed on, Gentoo's AMD64 port has had plenty of time to mature - version 2004.3 was, in fact, the distribution's third stable release for this architecture. And although the road to a complete AMD64 Gentoo system had a lot more potholes than its Debian or Fedora counterparts, further intercepted by frequent side trips to the Gentoo forums and mailing lists, the end result was equally good - a powerful and incredibly fast high-end workstation.

But let's start from the beginning. We installed the latest version of Gentoo on a system with the following specifications: AMD64 3500+ processor (2.2GHz), K8N Neo2 (Socket939) mainboard from Micro-Star International, 2 GB of DDR SDRAM, 2 x 120 GB Maxtor hard disks, Plextor PX-712A DVD/CD Rewritable Drive, and NVIDIA GeForce4 Ti 4600 graphics card. Those who are following the series might have noticed that the we have doubled the amount of RAM since the last time - that's because we noticed that even with 1 GB of RAM, the system was still making use of the swap partition, especially when compiling Gentoo packages in the background, while running a KDE desktop, several KDE and GNOME applications, and a web server.

We launched the Gentoo installation program from a 52.3 MB minimal live CD (version 2004.3-r1) and followed the instructions in the Gentoo Handbook. If you haven't installed any recent Gentoo release, you should know that, despite some talk about automating parts of the Gentoo installer, the installation is still as manual (read "tedious") as ever. This is of course due to Gentoo's policy of making sure that users installing the distribution learn the basics of a Linux-based operating system early, rather than flood the mailing lists and forums with elementary questions later. While this attitude is understandable, even commendable, those of us who frequently install various distributions for testing purposes or for large-scale deployment would certainly welcome a more automated installation procedure.

We decided to perform a full installation from "stage1". This would seem like a waste of time and effort on a AMD64 system - on traditional x86 architectures we could further optimize the build process to target our chip, whether that be a Pentium 4, an Athlon XP, or even a 486, but what do we optimize for on an AMD64 system? The Gentoo installation handbook doesn't deal with this issue either, but based on the information found in the GCC manual we decided to set CHOST to "x86_64-pc-linux-gnu" and CFLAGS to "-march=k8 -O2". We also defined some USE variables to indicate what type of system we are building before configuring the kernel and starting the long compilation process.

Unfortunately, things didn't go all that well. While the base system compiled and installed without a hitch, we ran into problems when trying to compile ttmkfdir (a utility to create a fonts.scale file from a set of TrueType fonts) xterm and ncurses. These were relatively easy to solve compared to a later problem with ScrollKeeper - for some reason all ScrollKeeper executable files had been pre-fixed with a name of the architecture, so other applications trying to execute "scrollkeeper" were unable to find it. A trip to Gentoo forums revealed that several other users had suffered from the same issue, until a helpful soul came along and offered a workable solution: unmask and upgrade gcc-config, then remove the CTARGET line from /etc/env.d/05gcc (despite a stern warning not to touch the file!).

The above is just an example of some of the potential setbacks facing users who attempt to compile hundreds of packages on Gentoo Linux. Since the version of Gentoo we attempted to install was a stable release (as opposed to a beta or development release), we expected things to go smoothly, but it wasn't the case. One of the solutions that we learned early to solve a compilation problem was to "unmask" a package (by placing its name in the /etc/portage/package.keywords file) and attempt to run emerge again. This often worked - for example, we weren't able to compile the "stable" mozilla-1.7.3 ebuild, but once we unmasked it, the emerge command went on to fetch and compile successfully a "testing" mozilla-1.7.3-r3 ebuild. On a positive note, we had no problems emerging KDE, and once we solved the Scrollkeeper and Mozilla issues, the remainder of the GNOME packages also compiled fine.

For those who are wondering about the speed of compiling applications on this AMD64 system, here is an indication of the processor's power: emerging the xorg-x11 package (in its default configuration) took about 25 minutes. In contrast, emerging the same package on a 1.4 GHz Pentium 4 system took about 40 minutes.

Mixing 32-bit and 64-bit applications on a Gentoo installation is achieved in a similar fashion as on Debian. The relevant libraries are stored in separate directories - /lib64 is a symbolic link to /lib and /lib32 is a symbolic link to /emul/linux/x86/lib. OpenOffice.org is only available in a 32-bit binary format and so are Opera, Flash Player, Acrobat Reader, and other binary-only applications. One nice thing about Gentoo (compared to Fedora Core) is that most of these applications are available from within the portage infrastructure (e.g. a simple "emerge corefonts" downloads and installs Microsoft TrueType fonts, "emerge nvidia-kernel" downloads and installs the NVIDIA binary driver), so there is no need to configure a third-party repository to be able to take advantage of some of the popular, but non-free software.

Despite some bugs in the installation setup and the necessity to peruse Gentoo's community resources to solve several problems, the overall experience of installing and using Gentoo Linux on the AMD64 system wasn't overly negative. Sure, we cursed profusely every time the compile process came to a sudden halt with a loud error message, but luckily, none of the problems were showstoppers. Thanks to them, we had the opportunity to appreciate the quality of Gentoo's documentation and the helpfulness of users on the distribution's forums. When all was said and done, we ended up with a a complete, fast and powerful graphical workstation, just as we did with Debian or Fedora. And while the effort required to achieve that goal was far greater than with the other two distributions, there is little doubt that Gentoo Linux is an elegant operating system with powerful package management and truly superb documentation.


(Log in to post comments)

Installer

Posted Dec 20, 2004 2:11 UTC (Mon) by dberkholz (subscriber, #23346) [Link]

"While this attitude is understandable, even commendable, those of us who frequently install various distributions for testing purposes or for large-scale deployment would certainly welcome a more automated installation procedure."

See http://www.gentoo.org/proj/en/releng/installer/ -- it's a WIP. You can find real-time collaboration on the Freenode IRC network at #gentoo-installer, for any Python gurus interested in helping out. We're not in need of testers at this point, however, just coders.

Compile times, swapping

Posted Dec 26, 2004 20:31 UTC (Sun) by ringerc (subscriber, #3071) [Link]

I'm _very_ susprised you only saw a 40 minute compile time on a 1.4GHz P4. The 1.4GHz P4 was an astonishingly gutless CPU, and it's more than a little elderly too. Are you sure you don't mean the 1.4GHz Pentium M ("Mobile Pentium" - NOT the Pentium 4 or Pentium 4 Mobile, which are very different CPUs)? That would make a lot more sense.

Also, Linux will generally touch the swap even if you have obscene amounts of RAM. There have been endless arguments about the merits of that, arguments I don't care to repeat here. Nonetheless, I'd argue that light swapping in Linux does not actually suggest memory pressure, only the VM making room for a potential surge in activity later. Upgrading the RAM is probably nuking a fly, though the extra RAM will serve as absolutely fantastic disk cache.

Other than those little issues, thanks for the interesting review. I'm still steering well clear of Gentoo, but perhaps in a while...

Gentoo Linux on AMD64

Posted Jan 16, 2005 21:52 UTC (Sun) by jhuebel (guest, #27305) [Link]

Thank you for a fair and informational article. As the Strategic Lead Developer of the Gentoo/amd64, I'm always interested in finding out the real-world experiences of our users.

I'll be sending an email to all the amd64 developers so they will see this article. Feedback is always appreciated (even critical feedback). With more thoughtful criticism such as this, I'm sure Gentoo/amd64 will continue to grow, mature and provide a great platform for Linux enthusiasts, high-end workstation users and SMP-servers.

For those users who do take the plunge into 64-bit bliss, here are some useful links to information and support on the Gentoo/amd64 port.

Gentoo/amd64 Technotes: http://amd64.gentoo.org/technotes.xml
Gentoo/amd64 IRC Channel: #gentoo-amd64 on irc.freenode.net
Gentoo/amd64 Forum: http://forums.gentoo.org/viewforum.php?f=46
Gentoo/amd64 Mailing List: gentoo-amd64-subscribe@gentoo.org

In particular, we encourage users to visit the IRC channel. There are always AMD64 developers in the channel ready to help you with any issues you may experience. Our development team in particular prides itself on being friendly, helpful and active with the user community.

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds