Tip: Switching to Gentoo? Start in a Virtual Machine

Considering the type of Linux user that I am, Gentoo has always seemed like the perfect match. However, it took me a few years to finally make the switch. There's a few reasons for that, but the main one is pretty simple: I can not afford having my daily driver inoperable for more than a few hours at a time.

After switching to Gentoo, I can safely say that using and maintaining it is no more time consuming than any other distribution, but installing it is another story. How long it takes to install depends on how you configure your system, and since I tweaked a lot of stuff (which includes using LLVM as the default toolchain, and gcc as a fallback) it goes without saying that in my case, an install would take at least a day.

So how did I manage to finally switch to Gentoo? Easy: I started in a VM.

The Logic

As I mentioned above, I can't have my daily driver stay in an inoperable state for a whole day, nor do I have the time to spend a whole day installing a system. If you're not in that situation, or if you plan on installing on a secondary device, then it may not be worth your while to do this in a VM first. Likewise, you could stick to defaults and use Gentoo's pre-built binaries if you don't need to have any special configuration and USE flags.

In any case, the point is simple: configuring the whole system (+ kernel) and building packages in a Virtual Machine allowed me to do it in my free time and it didn't matter how long it would take.

So, how did I go about it?

The Process

This is nothing special. Install the system following the handbook, just like you would on bare metal. Configure portage to your liking, and make sure the buildpkg feature is enabled (it should be enabled by default). With FEATURE=buildpkg, every software you install with emerge will be saved to /var/cache/binpkgs (or wherever you tell portage to save your packages) in the .gpkg.tar format.

Building packages is the real time saver here, but note that you won't be able to use the -march=native compile flag. When you're done installing, configuring and building packages, save all your config files (don't forget the @world file as well), and create a tarball of /var/cache/binpkgs, e.g.

# cd /var/cache/binpkgs
# tar czvf ../binpkgs.tgz .

This will save the tarball to /var/cache.

When you're ready to install on bare metal, proceed with the installation. When you reach the Configuring compile options step, copy your configs to the appropriate directories. Next, when you reach the Optional: Updating the @world set phase, extract binpkgs.tgz:

# mkdir -p /var/cache/binpkgs
# tar xzvf /path/to/binpkgs.tgz -C /var/cache/binpkgs

Then, just to be 100% sure, run

# emaint -f binhost

This command ensures that the Packages file is updated to contain all packages in binpkgs. If you installed app-portage/mirrorselect first, for example, then this step is mandatory. Remember this command, because if you ever decide to build packages on another system (be it a VM or other computer) and copy them to your main system, you will need to run it before updating.

Afterwards, emerge @world with the proper flags

# emerge -avuDN --with-bdeps=y --usepkg @world

Depending on how many packages you have in world, it may take a while, but nowhere near as long as if you had to compile everything. Take note that --usepkg will prefer ebuilds over binpkgs if a newer version of a package is available, which means some packages may be compiled instead. You could use the --usepkgonly flag instead, but I strongly discourage it, because you'll still have to update those packages afterwards anyway.

If you want to avoid rebuilding packages as much as possible, make sure to emerge @world in your VM before creating binpkgs.tgz and rest assured that the update frequency on Gentoo sits somewhere in between Debian and Arch, which means that unless you have a ton of packages, you probably won't have to rebuild too many packages even if you waited a day or two before doing your final install.

About the Kernel

The binpkgs feature will not build a package for the kernel, however. If you choose to configure your own kernel, you can create a "release" tarball by using the dir-pkg Make option:

# make -j$(nproc) dir-pkg
[...wait for compilation to finish]
# cd tar-install
# tar czvf ../linux-${VERSION}.tgz --sort=name *

To install the kernel to your main system, extract the tarball and copy the contents of boot to your boot directory, and the directory in lib/modules (e.g. 6.12.21-gentoo) to /usr/lib/modules.

You can find more details here (though using kmake is not necessary):
https://wiki.gentoo.org/wiki/Kernel/Building_from_userspace#Packaging_a_kernel_for_use_on_another_host

Closing thoughts

This may not be the traditional method to install Gentoo, but it does save you a lot of time during installation. One added benefit is that you can experiment as much as you please, and risk breaking the system, without issues. Of course, I advise to clone your VM once you have a basic/working install in order to avoid having to reinstall if you go too far.

Note: cloning VMs shouldn't be used as an excuse to avoid fixing issues that might occur during experimentation. Fixing a system rather than reinstalling is a skill that can save your behind in the future.

If you're interested in seeing how far Gentoo can be configured, have a look at the etc/portage/ directory in Ragnarok's src repository: https://github.com/RagnarokOS/src/tree/master/etc/portage.