The Reputation Is Earned

Here is something nobody in the Linux community wants to say out loud. Every major distribution today is designed to make sure you never have to understand what is actually running on your computer. Ubuntu, Fedora, Debian. Click next. Click next. Click finish. And look, your system boots. Congratulations. You have no idea what just happened. They did that on purpose. Because a user who understands their machine is a user who does not need them. Think about that. Gentoo is the one distribution that refuses to do that to you. Gentoo hands you the source code, the compiler, and a handbook, and it says: build it yourself. Figure it out. Understand every single choice. And people lose their minds over this. They call it difficult. They call it impractical. Of course they do. Understanding your own computer is apparently radical now. It takes eight to twenty-four hours the first time. Every minute of that is earned knowledge that nobody can take from you.


The History

Daniel Robbins started Gentoo Linux in 2002, but the lineage goes back further. In 1999 he was working on a distribution called Stampede Linux. He moved from that to a project called Enoch Linux, which was designed to be compiled from source and optimized for the host machine. When Enoch was renamed Gentoo, it kept that philosophy at its core.

The name comes from the Gentoo penguin, the fastest swimming penguin, capable of speeds up to 36 kilometers per hour. The name reflects the optimization focus of the distribution.

Portage, Gentoo's package manager, was directly inspired by the BSD ports system. In BSD, you install software by navigating to a directory representing a package and running make. Portage does the same thing with ebuilds, which are shell scripts that describe how to download, patch, configure, and compile a piece of software. When you install a package with emerge, Portage runs the ebuild for that package and compiles it on your machine.

The key innovation was the USE flag system. A USE flag is a boolean that controls whether a feature is compiled into a package. If you set USE="-gtk" you are saying "do not compile GTK support into anything." If a package would normally build a GTK frontend, it will not. The compiled binaries on your system contain only the features you actually use. On a server, this is meaningful. On a desktop, it matters less, but the control is there.


What You Are Actually Doing

A Gentoo install is not running an installer. It is manually constructing a Linux system from scratch, with full awareness of each step.

Here is the sequence. Keep this in your head the entire time.

01Boot a live environment (Gentoo minimal install CD, or any live Linux)
02Partition and format your target disk with fdisk, then mkfs
03Download a stage3 tarball: a minimal Gentoo root filesystem (~268 MB compressed)
04Mount the target partition and extract the stage3 into it
05Chroot into the new root, mount the virtual filesystems
06Write /etc/portage/make.conf: compiler flags, CPU target, USE flags
07Sync the Portage tree: the full database of every ebuild in existence
08Run `emerge --ask --update --deep --newuse @world` and wait
09Configure and compile the Linux kernel with make menuconfig
10Install and configure GRUB, write /etc/fstab
11Reboot and either it works or you find out what you missed

Each of those steps has sub-steps. The kernel configuration alone exposes over four thousand options.


Partitioning, The Part Everyone Gets Wrong First

Nobody tells you this, but the disk layout decision you make in the next twenty minutes will determine how much pain you are in six months from now. You will not be asked again. There is no installer prompt that catches your mistake. You just live with it.

The disk is a blank block device. It does not care about you. /dev/sda if it is a spinning drive, /dev/nvme0n1 if it is an NVMe. You are going to carve it into regions using fdisk and then tell each region what filesystem it should speak.

Use GPT. Not MBR. GPT is the modern partition table standard that works with UEFI firmware and supports disks larger than two terabytes. MBR is from 1983 and you should not use it for a new install in 2026 unless you have a very specific reason and you already know what that reason is.

The partition you absolutely cannot skip is the EFI System Partition. It needs to be FAT32, it needs to be at least 512 megabytes, and the firmware needs to be able to find it. This is where your bootloader lives. Get this wrong and the machine boots nothing. Not a dramatic error. Just silence from the BIOS and a blinking cursor.

After EFI comes /boot for kernels and initramfs images. Then swap, sized to at least match your RAM if you ever want hibernation to work. Then root. Then home, if you want user data on a separate partition that survives a system reinstall.

The commands look simple. fdisk /dev/sda, then g for a new GPT table, then n for each partition with a size suffix like +512M or +80G. Then t to set the partition type, then w to write the table to disk. One wrong character and you start over.

Here is the thing about mkfs. The filesystem format is permanent for practical purposes. You could technically reformat later but you would lose everything on that partition doing it. So you want to make this decision once. ext4 for root and home is the boring correct answer. Fast, mature, well-understood by every recovery tool that exists. btrfs is interesting but adds complexity and you are already installing Gentoo, so maybe one layer of complexity at a time.

fdisk + mkfs — /dev/sda

Partition layout for a fresh 512 GB NVMe drive. GPT table, EFI first, then boot, swap, root, home.

devicefssizemount/dev/sda1FAT32512M/boot/efi/dev/sda2ext41G/boot/dev/sda3swap16G[SWAP]/dev/sda4ext480G//dev/sda5ext4remaining/home
$ fdisk /dev/sda

Stage 3 — Download, Verify, Extract (animated)

Every Gentoo install begins here. The stage3 tarball is a minimal but complete Gentoo root filesystem — about 268 MB compressed. It is the seed from which your entire system grows.

root@gentoo ~ #
$ wget -c https://distfiles.gentoo.org/releases/amd64/autobuilds/
current-stage3-amd64-openrc/stage3-amd64-openrc-20240101T170312Z.tar.xz
Connecting to distfiles.gentoo.org (2001:6b0:1::1):80... connected.
HTTP request sent, awaiting response...

make.conf Is Everything

Every decision about how your system is built flows through /etc/portage/make.conf. The compiler flags go here. The number of parallel build jobs goes here. Your global USE flags go here. Your accepted licenses go here.

The most important setting is MAKEOPTS. On a machine with eight CPU threads, you set MAKEOPTS="-j8". This tells make to run eight compilation jobs in parallel. Single-threaded compilation of the entire system would take days. Eight threads brings it to hours.

The CFLAGS value -march=native tells GCC to optimize compiled code for the exact CPU in this machine. The resulting binaries will not run on a CPU that does not support the same instruction set. That is fine for a desktop and a serious problem if you were building binaries for distribution to other machines.

/etc/portage/make.conf — compiler and feature configuration (animated)

Every package compiled on this machine will use these flags. Setting MAKEOPTS incorrectly wastes cores. Setting CFLAGS incorrectly causes subtle miscompilation that can manifest as mysterious crashes months later.

root@gentoo ~ #
$ nano /etc/portage/make.conf

The Chroot

After extracting the stage3, you have a minimal but complete Linux root filesystem at /mnt/gentoo. It has a working bash, basic utilities, and a skeleton Portage configuration. But it is not running. To work inside it, you use chroot.

The chroot sequence requires mounting the kernel's virtual filesystems into the new root before you enter it. Without /proc, /sys, and /dev, many programs inside the chroot will fail in confusing ways. The mount --rbind commands mirror your running system's device tree into the new root.

After chrooting and sourcing the profile, your shell prompt changes. Everything you run is now running inside the new Gentoo system. Package installs go into it. Config file edits affect it. When you reboot, this is what runs.

Chroot — entering the new system (animated)

Before chrooting, you must mount the kernel virtual filesystems into the new root. Without /proc, /sys, and /dev, many programs inside the chroot will fail. After entering, your shell is running inside the new Gentoo system.

root@gentoo ~ #
$ mkdir -p /mnt/gentoo

/etc/fstab, The File That Decides If Your System Boots

This is one of those files where a single wrong character means your machine drops to a recovery shell at three in the morning and you are staring at /bin/sh wondering what you did. The file is called /etc/fstab. It stands for filesystem table. The kernel reads it at boot and uses it to figure out where to mount everything.

Every partition you created needs an entry. Not the partition name. The UUID. You use UUIDs because /dev/sda4 is not stable. If you add a second drive, if the kernel changes how it enumerates block devices, your root partition might show up as /dev/sdb4 next boot and the fstab entry is wrong and you are back in that recovery shell. UUIDs are permanent. Run blkid to get them.

Each line in fstab has six fields. The device, the mountpoint, the filesystem type, the mount options, the dump flag, and the fsck pass number. The dump field is almost always 0 now. The pass field matters: root should be 1, everything else should be 2 or 0. If two partitions both have pass set to 1, fsck runs them sequentially instead of in parallel and you have slowed down your boot for no reason.

The mount options are where you make real decisions. noatime is the first thing anyone with an SSD should set. By default the kernel records the last access time every time a file is read. On a spinning drive this is already annoying overhead. On an SSD it means pointless write cycles eating into the drive's lifespan. noatime stops it. Set it everywhere.

discard enables TRIM for SSDs. The SSD needs to know which blocks are free so it can manage wear leveling. Without TRIM, performance degrades over time as the drive fills with blocks it thinks are occupied. With TRIM enabled via the discard mount option, the kernel passes this information to the drive automatically on every deletion. This is the right thing to do.

For swap, the options are just sw. No special flags. The kernel handles swap differently from regular filesystems. It does not go through the VFS layer. You just tell fstab where it is and what type it is and the kernel takes it from there.

One entry people often skip is tmpfs on /tmp. Your /tmp directory lives in RAM if you add this line. Anything that writes temporary files there, build systems, package managers, browsers, writes to memory instead of disk. Fast, and the contents vanish on every reboot which is exactly what you want from a temporary directory.

After you write the file, test it before you reboot. mount -a reads fstab and mounts anything not already mounted. If there is an error in your syntax, you find out now instead of at the grub menu.

nano /etc/fstab

Every partition gets a UUID entry. Using UUIDs instead of /dev/sdaX means the table survives device renaming after a kernel update.


Portage and Emerge

The Portage tree is the database of all packages Gentoo knows how to build. As of 2024 it contains over nineteen thousand packages. emerge-webrsync downloads a daily snapshot of this tree as a compressed archive. emerge --sync fetches incremental updates via rsync or git.

emerge --ask --verbose --update --deep --newuse @world is the command that rebuilds the entire system to match your current configuration. The @world set is every package you have explicitly installed plus the system set. After changing make.conf, you run this to rebuild everything with the new settings.

On a fast machine with eight cores, a full world rebuild from a fresh stage3 takes three to six hours. Some packages dominate that time. GCC takes forty-five minutes. LLVM takes ninety minutes. Firefox takes two to three hours. LibreOffice takes over an hour. Many users configure binary package fetching for these specific packages to avoid recompiling them on every update.

emerge-webrsync + emerge @world — package sync and world build (animated)

emerge-webrsync downloads a snapshot of the Portage tree — the database of all 19,000+ packages Gentoo knows how to build. Then emerge @world rebuilds the entire installed system to match your make.conf settings.

(chroot) livecd / #
$ emerge-webrsync

The Kernel

The Linux kernel is not just another package on Gentoo. You compile it yourself, with a configuration file that controls thousands of individual options.

The configuration determines what hardware drivers are compiled in, what filesystems are supported, what security features are enabled, and what scheduling policy the kernel uses. A wrong choice can mean hardware that does not work. A missed filesystem driver means the system cannot read its own root partition. A missing NVMe driver means the install disk is invisible to the running kernel.

make menuconfig launches a text-based configuration interface. You navigate it by category: processor type, device drivers, filesystems, networking. You select options with the spacebar. When you exit and save, it writes a .config file with thousands of lines. Then make -j8 compiles the kernel and all selected modules. On modern hardware this takes about eighteen minutes.

Kernel compilation — make menuconfig + make -j8 (animated)

The most technically demanding part of a Gentoo install. You configure thousands of kernel options, then compile. A wrong driver selection means hardware that does not work. A missed filesystem driver means an unbootable system.

(chroot) livecd /usr/src/linux #
$ ls /usr/src/

The Bootloader

After the kernel is compiled and installed to /boot, you configure GRUB. Two commands handle the full setup. grub-install writes the bootloader to the disk's MBR or EFI partition. grub-mkconfig scans /boot for kernel images and generates the menu configuration.

After this, you exit the chroot, unmount the filesystems, and reboot. If everything went correctly, GRUB appears, you select your Gentoo entry, and the kernel boots into your freshly compiled system.

If everything did not go correctly, you boot back into the live environment and debug.

GRUB installation and first boot (animated)

After the kernel is compiled and installed, two commands configure the bootloader. grub-install writes the bootloader binary to the disk's MBR. grub-mkconfig scans /boot for kernel images and writes the menu.

(chroot) livecd / #
$ emerge --ask sys-boot/grub

How Long It Actually Takes

Install time is primarily a function of CPU speed and core count, because compilation is the bottleneck. Storage speed matters for extraction and package database operations. Network speed matters for the initial sync.

Install Time Comparison — Wall Clock Hours

Gentoo's install time is not in the same order of magnitude as other distributions. The variance on Gentoo reflects hardware more than any other distro because you are compiling everything.

The individual package compile times are where the hours go. Firefox and LLVM alone account for over four hours on an eight-core desktop. Most of the remaining time is GCC, Qt, LibreOffice, and the world rebuild of smaller packages.

Compilation Time for Major Packages — 8-core desktop, -j8 (minutes)

Firefox and LLVM/Clang are the two outliers that make people reconsider binary packages for large packages. GCC at 45 minutes is unavoidable — you need it before anything else can compile.

Total for all 8 packages: ~555 minutes (9.25 hours). Firefox alone accounts for 31% of that.


Why People Still Do It

A properly configured Gentoo system with -march=native and tuned USE flags produces measurably faster binaries for certain workloads. The system contains only the features you explicitly asked for. There is no software you did not choose to install.

But the more honest reason people use Gentoo is what the install teaches you. You cannot complete a Gentoo install without gaining a working understanding of how Linux actually fits together. You have configured a compiler. You have understood the relationship between USE flags and compiled features. You have looked at kernel configuration and understood what each driver does and what hardware you have. You have touched the system at every layer.

That knowledge transfers. Gentoo users tend to be unusually capable Linux administrators because the distribution forces you to understand what you are running. You cannot fall back on "the installer handled it" because there was no installer.

The install is not the obstacle. The install is the point.