User:Pietinger/New at Gentoo
I wrote this article so that I can link to it in the Gentoo forums if users have questions about it.
Initial Installation
The most important thing you need to know about Gentoo before you try to install it:
Take your time !
Installing Gentoo will take longer than installing a binary Linux distribution ... and you will also need more time for reading manuals, because your normal Linux knowledge is not (yet) sufficient. Plan several days. But do not worry, the first installation of Gentoo takes some times, but once you are used to it and know the process, it's mostly possible to install it in a few hours.
Before you jump into Handbook:AMD64 to install Gentoo (if it is actually your architecture), I would like to recommend a few things:
First, read this fabulous article by our famous wiki editor @maffblaster (in my opinion, it should actually be the first page in our Handbook):
and right after that these articles:
Secondly, even if you want to use a manually configured kernel, you should first install the precompiled kernel image sys-kernel/gentoo-kernel-bin or sys-kernel/gentoo-kernel (non-precompiled) because you can then select it at any time via the boot manager and thus have a backup kernel when your manually configured kernel causes problems. For a first installation, tweaking the kernel could (would) probably cause useless pain, waste of time, etc. Unless it is actually really needed, for the installation it is probably better to stick to the gentoo-kernel(-bin). This is the first option in Handbook:AMD64/Installation/Kernel.
If you have never configured a kernel manually, I recommend you read this first - including all the linked articles: User:Pietinger/Tutorials/Manual_kernel_configuration
Now you should have a better basis for deciding whether you want to go down this path.
If you are unsure which option to choose here: Handbook:AMD64/Installation/Bootloader then I would recommend:
For an OpenRC system use grub - for a systemd system use systemd-boot.
Don't worry if you want to boot your kernel directly via UEFI, you can always install "Alternative 2: EFI Stub" later. Just read User:Pietinger/Tutorials/Boot_kernel_via_UEFI after you have completed all installation steps.
However, a boot manager to start with is very handy in case you have a problem with a new / your manually configured kernel.
It might be helpful to have the following quick guide printed out next to you while reading the Handbook:AMD64 and to compare it (and to copy the commands from there if you are unsure somewhere): User:Pietinger/Draft/Quick_Installation_OpenRC_for_an_UEFI_System
Pause during Installation
Thirdly, you can take a break at any time during the initial installation to continue the next day. If you are at any step after this one:
Handbook:AMD64/Installation/Base#Preparing_for_a_bootloader
and before you have completed this step:
Handbook:AMD64/Installation/Bootloader#Rebooting_the_system
you can pause by executing both in reverse order:
Instead of a reboot, you naturally perform a
root #
shutdown -h now
and if you want start the next day you boot again: Handbook:AMD64/Installation/Media#Booting_the_installation_media
and do these steps again = Chrooting into your Gentoo system:
1. Handbook:AMD64/Installation/Disks#Mounting_the_root_partition =>
root #
mount /dev/sda3 /mnt/gentoo
2. Handbook:AMD64/Installation/Base#Mounting_the_necessary_filesystems =>
root #
arch-chroot /mnt/gentoo
3. Handbook:AMD64/Installation/Base#Entering_the_new_environment =>
root #
source /etc/profile
4. Mount your boot partition OR your ESP, depending if you use old BIOS boot or UEFI boot - Handbook:AMD64/Installation/Base#Preparing_for_a_bootloader =>
root #
mount /dev/sda1 /efi
Now continue where you left off yesterday ;-)
These steps are also necessary to switch back to your installation when your system does not boot after Handbook:AMD64/Installation/Bootloader#Rebooting_the_system.
The Power of Gentoo
is the use of Profiles and Use-flags. We have excellent articles in our Gentoo Wiki and I will give you the most important links in a moment. But first I would like to give you an overview so that you can classify everything correctly.
Before you clarify questions about the Use-flags, you should have selected the right profile, because this profile already activates a lot of Use-flags for you, so you don't have to set them yourself in /etc/portage/make.conf. If you now think that this is unfortunately not possible for you because, for example, you are using the hardened sources AND want to have a KDE, but there is no profile for this, here is my first hint:
You can also combine profiles (the links will follow shortly).
Why is it so important that the correct profile is set? Because our Gentoo developers sometimes change it. You will get this change automatically with the next "emerge --sync". For example, the last change was that the Use-flag “vulkan” was activated globally for all desktop profiles. If you have a desktop but only a server profile active then it would be missing for you ... and the problems will start.
Only when you have set the correct profile should you think about Use-flags that are still missing OR that you now have too many of. The most important thing you need to know about Use-flags is that they can be set globally for the whole system or only for a single package.
So when should a Use-flag be set globally and when only for a specific package? This question is not always easy to answer. In principle, it is of course always safer to activate a Use-flag for one package only, as this has less impact on the system. On the other hand, there are some Use-flags that determine what hardware you have in your system at all, or which global applications are available. One example is the "bluetooth" Use-flag. If you do not have this (or do not want it) then it makes sense to activate or deactivate it globally. Now start first:
root #
eselect profile list
Have you already set the correct profile? If not, here are the promised links:
- Profile_(Portage)
- Hardened_Desktop_Profiles
- KDE/Hardened_KDE_Plasma_profile
- GNOME/Guide/Hardened_GNOME_Profiles
- There is even an old forum thread that dealt, for example, with the linking of No-Multilib and Plasma (caution: this was at a time when the 17.1 profiles were current; today, of course, 23.0 is current): [[1]]
Now check which Use-flags are already active. These do not need to be additionally activated - at the very least deactivated again if not desired (I do not have Bluetooth, for example, and therefore have the line USE="-bluetooth ..." in my make.conf):
root #
emerge --info
Take a look at the line “USE=...” and you will be amazed at how many use flags are already activated. Now read all about Use-flags:
My recommendation for the beginning is: First use the default settings and later change only one Use-flag at a time. Check the change and only then make further changes. To get an overview of all set Use-flags (including the package-specific ones) use: User:Pietinger/Overview_of_System_Information.
One last note: There are some Use-flags that you should never set globally, such as “debug”, “static”, “static-libs” and “test”. These should really only be set for individual packages (and if you know what you are doing with them). You can always check what a global Use-flag WOULD do in your system by making this query:
USE="USEFLAG" emerge -uUDvp @world
or what would happen if you wanted to remove an already active Use-flag:
USE="-USEFLAG" emerge -uUDvp @world
Examples:
USE="magic" emerge -uUDvp @world
USE="-bluetooth" emerge -uUDvp @world
The most common mistake beginners make with Gentoo
Now that you are done with the basic installation, you should keep your Gentoo up to date.
The best way to keep your Gentoo up to date is to update everything after an emerge --sync with an emerge -uUDv @world.
(See also: User:Pietinger/Tutorials/Optimize_compile_times#My_Recommendation).
Gentoo also allows you to update only individual packages and not everything at once. For example, you are allowed to update only the kernel. You have two options for this:
root #
emerge -uD gentoo-kernel-bin
or
root #
emerge -1uD gentoo-kernel-bin
You may have noticed that I also use this parameter -1 in my CheatSheet for a kernel update. What does this do?
As you have probably already seen from the installation, there are packages that require other packages - dependencies. Gentoo - Portage - knows these dependencies and automatically resolves them for you and installs these packages automatically. For example, if KDE needs a “gcc”, you don't have to install it beforehand, but it is automatically installed during the installation of KDE (in reality, every program needs the gcc, so it is/was already in stage3). Now take a look at the file /var/lib/portage/world. Do you see the “gcc” in your world file? No. This file only contains all the packages that you have just explicitly installed, but not the dependencies. There is a good reason for this:
If you no longer want a package and therefore uninstall it, it will disappear from the world file. If you then do an emerge -c, all packages that were ONLY a dependency of this package will also be uninstalled ...
... as long as you have not “included” these dependencies in the world file. However, this is exactly what happens if you update individual packages and do not use this parameter -1. Without the -1 parameter for a single update, such packages are added to the world file ... and THEN they are no longer deleted with an emerge -c. This means: You should actually always use the -1 parameter for every SINGLE update - you only don't need it for an update to @world. (Actually, this only applies to slotted packages - but as a Gentoo newbie you won't know what that is yet).
Only omit this parameter if you really want to keep a specific version. In this example you can see that I wanted to keep a specific kernel and therefore portage automatically made this additional entry in my /var/lib/portage/world:
/var/lib/portage/world
...
sys-kernel/gentoo-sources
sys-kernel/gentoo-sources:6.12.21
...
With today's update to @world I got a new kernel version. Of course I want to delete the old version, but portage will not delete the protected version 6.12.21 (and of course the current one), only the old one:
root #
emerge -cp
[...] >>> These are the packages that would be unmerged: sys-kernel/gentoo-sources selected: 6.14.2 protected: none omitted: 6.12.21 6.14.3 [...]
You should now know all about this parameter so that you understand what this thread is about: [[2]]
Further note: It is strongly recommended not to edit file /var/lib/portage/world manually. If you want to uninstall a package, let Portage do it for you. Why? Because Portage may find out that it is a bad idea. Try an emerge -c gcc. Portage will not allow you to do it. If you add the -v parameter, Portage will also tell you why it's a bad idea:
root #
emerge -cv gcc
Calculating dependencies... done! sys-devel/gcc-14.2.1_p20241221 pulled in by: @system requires sys-devel/gcc ... sys-libs/glibc-2.40-r8 requires >=sys-devel/gcc-6.2 >>> No packages selected for removal by depclean
Deleting a GCC version would only be possible if you have a new (additional) version after an update to @world. Then Portage would allow you to delete the old version. If you just want to check if you could uninstall a package use the parameter -p to be on the safe side; i.e. emerge -cpv PACKAGENAME.