A Walk Through the Gentoo Linux Install Process

Anonymous American (Sherman Boyd) writes: "I was looking for a flexible, powerful distribution that makes it easy to build a 'custom' Linux box that meets my exacting specifications. I think I found it. Gentoo Linux has just released version 1.0 of their innovative meta-distribution and to celebrate I decided to throw it on my laptop and write this article based on my experiences." And good news for anyone interested in trying Gentoo: yesterday, Daniel Robbins announced the release of version 1.1a. Read on for AA's detailed look at putting Gentoo on his machine -- Gentoo has a different style than today's typical distributions, and it bears some explanation.

Gentoo solved many problems for me. Some distros install everything, whether you really need it or not. Not Gentoo; other than the base packages required for Linux to run, the only software installed on the system is the software you put there. Gentoo resolves dependencies automatically, eliminating RPM prerequisite hell. As an added bonus I got something I wasn't even expecting. Speed. Blinding, blazing, incredible speed.

The main advantage to the Gentoo distribution is Portage, a python-based ports system similar to BSD ports. For those of you unfamiliar with BSD ports, Portage is a package management tool that downloads and installs source instead of precompiled packages. When I need a program I download, install and compile it with one command:

emerge nmap

The above will download the nmap source code, compile and install it. Of course this method is slow, but it has its rewards. You can also opt to use prebuilt binaries if you are not extremely patient. It took me five hours to get the base Gentoo installed on my PIII with 128 megs of ram. It wasn't a big deal as I had other things to do, but I would like to see the installation process optimized so that it doesn't require any babysitting.

Gentoo is running two of my mission-critical servers right now, I consider it to be stable and mature. A warning, though: this is not a distribution for dummies. This is bare metal Linux, powerful and dangerous. If you do something without thinking you may fall into a bucket of pain.

Let's begin my story.

I download the iso from http://www.ibiblio.org/gentoo/releases/build /. There is a choice of install images here. My favorite way of installing Gentoo is to compile everything, a time consuming process. This method requires a slim 16-meg iso. You may want to grab an iso with pre-built binaries to speed things up, however. This fat iso weighs in at 103 meg. I download the big one with the prebuilt binaries even though I won't use them -- just in case.

I boot my laptop with my shiny new Gentoo CD. The Gentoo install uses isolinux by Peter Anvin. I like the fact that they don't obscure it, giving credit where it is due. It boots quickly and there is a PCI autodetection process, it shouldn't find much on my laptop. Interesting, it loads a SCSI module. Perhaps it has detected my IDE CD burner. Usually this will detect any PCI NIC cards that are installed, but it does not detect my PCMCIA device (of course). After the PCI detection I get a command prompt. I use nano (a small text editor) to open up install.txt, the excellent install doc. Usually these docs are sufficient but the latest ones can be found here:

http://www.gentoo.org/doc/build.html

Keeping the install doc open in this virtual terminal, I hit alt-f2 to open a new one. I begin by loading the pcmcia drivers and installing networking. This is all done at the command line ( insmod, ifconfig, route, dhcpcd, etc.). I use nano to add my DNS servers to /etc/resolv.conf. A word of caution; get in the habit of always using the -w switch with nano. If you do not use the -w switch nano's word wrap feature will jack up your config files. I ping a reliable site, networking is up!

Next I partition my system using fdisk. I choose a simple layout with a swap partition, a root partition and a small boot partition. The boot partition remains unmounted during use, a nice precaution. For filesystems you have a choice of ext2, ext3, ReiserFS and XFS. In my personal experience I've noticed that Reiser performance really rocks when combined with SCSI drives, but as this is an IDE system I think I'll go with XFS. Besides, the XFS tools seem to be a lot more mature than the offerings from Reiser. I format and mount the partitions from the command line creating a /mnt/gentoo directory. I then untar the root filesystem; here I have the choice of the small tarball that requires you to compile everything or a larger tarball that contains pre-built binaries. If you untar the big guy you are almost finished with your install at this point. Using chroot and some scripts you chroot the /mnt/gentoo directory. From this point on you are operating under your new gentoo system.

The first thing I do under my chrooted system is issue this command:

emerge rsync

This downloads the latest version of the portage tree. The portage tree is found under /usr/portage and contains the ebuild scripts used to compile/install programs. Currently there are over 1000 up to date emerge sripts. Next I edit /etc/make.conf, here I can choose compiler settings. I optimize everything for i686. Now it's time to build the GNU compiler and libraries. I run the bootstrap script and leave for lunch. On my PIII 500 the boostrap process takes 2 hours and 2 minutes.

The second emerge command I issue is:

emerge system

Now emerge downloads, compiles and installs my base system packages. I sit back, relax and take the time to fax my legislators a rant about the DMCA. One hour and 30 minutes later it is finished.

Now it is time to download and install the kernel. First I make a link updating my timezone, and then I issue another emerge command:

emerge linux-sources

This grabs the latest kernel, 2.4.19, and drops the source in /usr/src/linux. Ten minutes have elapsed. Now comes the fun, compiling your kernel. That's right, everyone who installs Gentoo compiles their own kernel as a matter of process. I like this. There are some distributions out there that actually say you should never compile your own kernel. Shame on them. I use make menuconfig and the standard commands to compile my kernel. Since Gentoo uses devfs I select /dev file system support and I am also careful to compile in support for XFS. I don't have the kernel mount devfs automatically at boot as the Gentoo startup scripts take care of this for me. Virtual Memory file system support is also enabled.

At this point in time I get to choose a logger. My choices are sysklogd, syslog-ng or metalog. I choose metalog, because it's got the coolest name. I download, compile and install it using a single command:

emerge metalog

XFS has some nice utilities, I better install those. I have some other essential programs to install, and I'm feeling a bit lazy so I chain them all in one big command.

emerge xfsprogs;emerge bitchx;emerge vim;emerge links

At this point I'm feeling pretty 7-Up. I edit my /etc/fstab file, my /etc/hostname file and /etc/hosts. The passwd command is run to set the root passwd. I add my NIC module to the file /etc/modules.autoload and edit /etc/conf.d/net. conf.d/net allows me to configure my IP address and settings, default gateway and alias. I take a look at /etc/init.d/net.eth0, even though I don't need to edit it. I can then add it to the startup script using this command:

rc-update add net.eth0 default

This adds the script to the default runlevel to be executed at startup. Startup scripts are another place Gentoo really shines. The startup scripts have a system of dependencies. For example net.eth0 can depend on pcmcia. The pcmcia drivers get loaded before net.eth0 - this is good.

Next I install grub. If you haven't used grub before, it's nice. You can boot to a kernel directly from the grub shell, without having to edit a config file. lilo is still available, for those of you who prefer it. Gentoo likes to let you make the decisions.

I exit my chrooted shell and unmount all directories. Reboot! Gentoo comes up and the install process is complete.

The Gentoo install process has taught me a lot about Linux, and I like the fact that the command line is embraced, instead of hidden behind gui or scripts. I also like the speed (which is debatable since all I can supply is anecdotal evidence). I wasn't too happy about waiting five hours for everything to compile, but I think it was worth it. I can tell you it compiles and greps noticeably faster than other distros I have run on the exact same machines. I really enjoy using portage, and the packages seem to stay up to date -- if not bleeding edge. This is not a conservative distribution like Debian, however I like the aggressive and intelligent direction gentoo is taking.

If you are considering trying out Gentoo I highly suggest #gentoo on irc.openprojects.net. Also subscribe to the mailing lists found at www.gentoo.org. The Gentoo community has helped me out of several jams in the past, I think they will treat you good too.

While writing this, I received help from a lot of people. However I would like to personally thank the people I ripped off word for word. Thanks notafurry of www.kuro5hin.org for your pointed help with the stilted second paragraph and thank you Ween from #gentoo on openprojects.net for your clean description of portage.

Comments

For you existing Gentoo'ers

[Xafloc]

I have created a site that will allow you to post your Compile Times for the different packages, relative to your hardware.

It's in alpha stage right now, but I'll add features as we go a long. Any suggestions would be appreciated. You must signup first in order to post your compile times.

Hopefully at some point, one willbe able to get a sense of how long it would take to install, say kde3.

How about some user testing on distro websites?

[Rorschach1]

The Gentoo site looks about like that of every other distro out there... just fine if you know exactly what you're looking for. How about grabbing a few average Linux users and watching them try to find what they need? I think people just don't realize how poor a lot of the websites and documentation are.

I think Debian, for example, is a fine installation. I've used it frequently. But the website really irritated me when I needed to find some specific floppy images and hardware support the other day. I got so frustrated that I finally gave up and went to FreeBSD. It's far from perfect, but I found what I was looking for in short order and quickly had the machine up and running.

Here's a question for anyone involved in the production of ANY distro out there: Is there ANY form of usability testing that goes into these sites? What's the process these people are using for designing the sites?

rock

[President Chimp Toe]

Rock Linux sounds pretty similar. Anyone know how they compare?

Hey, what the hell is this?

[Anonymous Coward]

A wellwritten article on slashdot. I'm buying a skitrip to hell.

Minor nit

[Mike Connell]

This is not a conservative distribution like Debian,

There are 3 debians, at varying degrees of 'conservativyosity'

Stable: Potato is dead stable and conservative. To put it another way: it's old, and you probably wouldn't want it on your desktop.

Testing: Woody is very stable (IME more stable than RH FWIW), and quite up to date (g++ 3 etc)

Unstable: Not sure of the name because I wouldn't use it. I don't know how stable it is, but I am thinking that it's quite up to date with the latest releases.

Anyway, the point I'm trying to make in a rather longwinded mannar, is that debian will be as conservative as you want it to be. There is always a tradeoff between "up to date" and "no nasty surprises" debian is very honest about letting you choose.

compiler

[brer_rabbit]

it'd be nice if one of these compile-it-yourself distributions worked with Intel's Linux C++ compiler (icc). Though Intel's compiler still doesn't support compiling the kernel and some other stuff, lots of software compiles just fine with icc. You can consistently obtain 10-20% improvements over gcc 2.9x in cpu intensive applications using icc (I haven't compared versus gcc 3.0 yet).

The icc license should be ok for home users to compile programs for their own use with it. I think you only have to buy the license if you plan on distributing binaries.

That "RPM dependency hell."

[Speare]

The leadin says that Gentoo eliminates all that RPM dependency hell. I agree, that's how most newcomers to the RPM scheme see it. A lack of higher tools and a lack of understanding has left many a new RPM user crying in frustration.

I haven't used Gentoo yet, and it may be the greatest thing since sliced bread. In the interests of helping newcomers who try RPM-based distros, however, a couple of points...

RPM is a package format, and rpm is the low-level tool that deals with those files. If you use rpm directly, you'll have to deal with the deluge of interconnecting dependencies yourself. However, it was not designed to be the sole front-line tool, it's the workhorse.

Unlike the Debian strains which all adopted the apt-get tool, each RPM-based distro has gone their own way with dependency management. Debian doesn't seem to focus so much on a distinction between dependency management and package management.

This dependency management is typically the commercialized aspect of the commercialized distro market: pay a value-added subscription fee for the ease of using a simplified network based package update/installer as a service, as well as some preferential bandwidth considerations. Faster downloads, push-down email notices, scheduled automatic installations, and other value-added services are attractive to corporate and casual users.

Service tools like up2date, redcarpet, and the like are the intended front-ends that use the rpm mechanisms to seek, download, validate, and install packages.

Much of the problem with package systems, rpm or deb, lies in the unorganized and untested packages produced haphazardly by small project folks, and the ad-hoc installations by casual users. The end users try rpm directly, or the weak gui equivalents, and at the first sign of dependency problems, they start using --nodeps or --force. Paraphrasing Asimov, "--force is the last refuge of the incompetent." The surest way to bollox an RPM machine is to --force a few packages or remove them with --nodeps, leaving a patchwork of unsatisfied dependencies. The surest way for a package maintainer to encourage such destruction is to blindly make packages that depend on too much, or too little.

Package management needs to grow up, and recognize the experimenter's needs: add tools at whim, try it a while, and remove it.

One: If you're not an expert, and want to play with a package for a bit, see if one is produced by your distribution first. Failing that, then see if someone's made a package intended for your version of your distribution. Unless you're going to spend the time reading the source code, it's usually a waste of time and energy to rebuild a package, and it'll be less compatible with your distro anyway.

Two: If you manage a package, and your program can use X or libaudio or whatever but doesn't absolutely require it, then consider making two packages or making your program smart enough to use what's present at runtime, rather than blindly depend on it being present at installation time.

Three: The key to user-interface design is that the interface needs to understand the user. Not the other way around. Focus on the needs of the expected types of user: neophyte through master. If you're new, --help and RTFM aren't enough. Don't just teach the user to fulfill the tool's needs, teach your tool to anticipate the user's goals. Don't just teach people to use RPM directly, but instead provide smooth tools that use RPM behind-the-scenes.

This has gotten longer than I expected; I'd appreciate constructive replies.

Re:That "RPM dependency hell."

[autechre]

Much of the dependency problems do stem from the way software is packaged. For many RPM-based distributions, they have 1 or 2 CDs worth of material where the packages are all designed to work well together, and then everything else is "contrib", and is not controlled as tightly (or at all). This is very bad.

The reason that tools like apt-get work very well with Debian is that all 8,000 packages are actually forced to follow guidelines before they are accepted. They also _are_ tested before they get into "testing" from "unstable", and tested even more thoroughly before "stable" is released. There is a policy that actually exists, and it is adhered to strictly.

In regards to your "multiple versions" suggestion, Debian does this quite frequently. If a package has a version with a Gnome GUI, but can be used without it, Debian will have a base package for that software, and another package you can install for the Gnome GUI. A similar thing is done with PHP and the various modules (PostgreSQL support, etc.).

To comment on another poster's reply: apt never automatically installs anything for you. If the package you requested to install has unmet dependencies, it will prompt you with the names of the packages which need to be installed/removed, and not continue unless you confirm.

tip for installs

[Raleel]

Portage figures out dependendies quite nicely, so take advantage of it. Pick a couple high level apps that you know you will use, and work on those first. For instance, I frequently do

emerge evolution galeon lynx nessus xmms

and it gets x, gnome, and all the bells and whistles that I need to run on my system, based on the USE variable set in my make.conf. Do the above and you can leave it go while you go to work or sleep and be assured that things went nicely.

I'll also mention that if you do

emerge evolution; emerge galeon;

It will have the advantage of compiling in series, and thus maybe catching some things that you don't have to redo later, but the disadvantage of failing multiple times on something that does not have a perfect build script, and you can't track down what caused it. I do it with

emerge evolution galeon

because you can see what died easier (the last thing on the screen.