Встановлення Gentoo (2026): Побудуй один раз, роби швидше назавжди

February 12, 2026 • February 12, 2026 • Читання: 7 хв • Views: 0

Було корисно?

Ви не встановлюєте Gentoo тому, що любите чекати. Ви обираєте його, бо втомилися гадати, що робить ваша система, чому вона повільна і які «корисні налаштування» знищили вам вихідні.

У 2026 році Gentoo досі залишається рідкісним дистрибутивом, що дає змогу будувати систему як оператор: вимірювану, відтворювану і швидку для реального навантаження. Хитрість у тому, щоб розглядати інсталяцію як першу зміну в продакшні. Приймайте рішення, фіксуйте їх і інструментуйте абсолютно все.

Принципи встановлення: продуктивність походить від відтворюваності

Встановлення Gentoo не є складним через те, що воно комплексне. Воно складне через те, що воно чесне. Інші системи ховають рішення у значеннях за замовчуванням і скриптах після інсталяції; Gentoo змушує вас обирати. Це подарунок, якщо ви ставитеся до нього як до конвеєра продакшн-збірки:

Фіксуйте рішення у системі контролю версій. Ваші /etc/portage, конфігурація ядра, конфіг bootloader і розбивка диска мають бути відтворюваними з нуля. Якщо це не відтворюється — це ненадійно.
Надавайте перевагу відпрацьованим за замовчуванням над «тюнінгами з блогу». Робота з продуктивністю — це переважно усунення вузьких місць, а не додавання прапорців.
Вимірюйте кожну зміну. Ви не можете покращити те, чого не спостерігаєте, і ви точно зіпсуєте те, що не вимірюєте.
Оптимізуйте час перебудови, а не лише швидкість виконання. Якщо ви не можете швидко перебудувати, ви не будете швидко виправляти. Так «тюнінг продуктивності» перетворюється на інцидент безпеки.

Одна цитата, яку я бачив доведеною частіше, ніж бачив надрукованою: перефразована думка від Gene Kim: «Надійності не досягають героїчними вчинками; її досягають проектуванням для швидких, безпечних змін.»

Цікаві факти та історія, що й досі важливі

Культура Gentoo завжди формувалася обмеженнями: пропускною здатністю, часом CPU та бажанням розуміти, що саме працює. Кілька конкретних історичних фактів допомагають пояснити, чому сьогоднішні найкращі практики виглядають так, як вони виглядають:

Назва Gentoo походить від пінгвіна Gentoo, якого часто описують як найшвидшого плавця серед пінгвінів — так, брендинг завжди був прямим.
ДНК Portage була натхненна системою BSD ports: рецепти (ebuilds) збирають програмне забезпечення з джерел з опціями (USE flags).
USE flags були раннім практичним рішенням проблеми «усе залежить від усього»: компілюйте потрібні фічі, пропустіть ті, що не потрібні.
Stage tarballs спершу існували, бо бутстрап повного тулчейну на повільному залізі міг бути болючим; stage3 став розумним дефолтом для більшості інсталяцій.
Міф про продуктивність Gentoo (що компіляція всього з -O3 робить систему магічно швидшою) був хибним ще до ери багатоядерних CPU. Він усе одно живе, як поганий кавовий апарат в офісі.
Бінарні пакети існували в Gentoo давно, але сучасний «гібридний» підхід — компілювати те, що потрібно, і ставити бінарі, коли можливо — став мейнстримом через важливість швидкості патчів.
OpenRC довгий час був дефолтною системою ініціалізації Gentoo через простоту, прозорість і дружність до поступових змін; Gentoo також підтримує systemd, якщо вам потрібні його екосистемні переваги.
Gentoo Hardened популяризував налаштування тулчейну та ядра з фокусом на безпеку, що вплинуло на ідеї «secure by default» у інших дистрибутивах.
Cross-compiling і distcc були «хмарною збіркою» ще до того, як це стало модним — команди збирали пакети на потужних машинах для розгортання на слабших системах.

Великі рішення на початку (і що я рекомендую)

1) Прошивка та завантаження: UEFI, завжди (якщо у вас не музей)

UEFI не ідеальний, але інструменти та очікування у 2026 році орієнтовані на нього. Використовуйте GPT, тримайте чистий ESP і обирайте bootloader, який ваш майбутній я зможе відлагодити о 3 ранку.

Рекомендація: UEFI + GPT + виділений EFI System Partition (ESP) + GRUB або systemd-boot. Якщо ви хочете знімки Btrfs/ZFS і відкат ядра, GRUB зазвичай гнучкіший.

2) Система ініціалізації: OpenRC vs systemd

Це не моральне питання. Це питання графа залежностей.

Оберіть OpenRC, якщо вам потрібна мінімалістичність, прозорість і менше рухомих частин. Він відмінно підходить для серверів і для людей, які справді читають логи.
Оберіть systemd, якщо вам потрібна першокласна підтримка від upstream-проєктів, стандартизована семантика unit-файлів або інтеграція з інструментами, що її очікують.

Рекомендація: Для персональної робочої станції підходить будь-який варіант. Для кластера обирайте той, який ваша команда може послідовно підтримувати. Змішані fleet-и — шлях до постійного «працює на хості A» як способу життя.

3) Файлова система: обирайте за режимами відмов, а не за відчуттями

Gentoo не врятує вас від фізики зберігання. Ваш вибір файлової системи має відображати потреби в знімках, захисті від bitrot, відновленні та передбачуваній продуктивності.

ext4: нудно, достатньо швидко, надійно. Якщо вам не потрібні знімки — це все ще чудовий дефолт.
XFS: сильний для великих файлів і паралельного IO, відмінний на серверах; менш дружній для маленьких «tinker» інсталяцій.
Btrfs: знімки, стиснення, субтоми. Чудово, якщо ви справді тестуєте відновлення і розумієте scrub/баланс.
ZFS: ковдра комфорту для інженера зберігання — контрольні суми, знімки, send/receive. Також потребує більшої інтеграції та роботи з модулем ядра поза основним деревом.

Рекомендація: Для більшості одно-дискових або простих NVMe систем: ext4 для root, плюс опційно Btrfs для даних, якщо хочете знімки. Для серйозної цілісності даних і workflow зі знімками: ZFS, але розглядайте його як платформне рішення.

4) Стратегія компіляції: локальні збірки, distcc або бінарні пакети

Компіляція — засіб, а не риса характеру. Ваше завдання — створити систему, яку можна патчити і підтримувати.

Локальні збірки — найпростіші і дивно прийнятні на сучасних CPU.
distcc корисний, коли у вас є кілька машин і великі збірки, але вводить ризики мережі та несумісності тулчейна.
Бінарні пакети — найкращий виграш по часу для швидкості перебудови і пропускної здатності патчів, якщо ви керуєте ними свідомо.

Рекомендація: Увімкніть бінарні пакети рано. Залишайте локальні збірки для тих частин, які потрібно тюнити або аудтувати.

Жарт №1: Компілірувати Chromium на ноуті — чудовий спосіб перевірити і thermal paste, і ваше терпіння одночасно.

Практичні завдання з командами: виміряйте, а потім вирішуйте

Нижче — реальні завдання, які ви можете виконати під час інсталяції (з live-середовища або після chroot). Кожне включає: команду, приклад виводу, що це означає і яке рішення приймати.

Завдання 1: Підтвердити режим UEFI (не гадати)

cr0x@server:~$ ls /sys/firmware/efi
efivars  fw_platform_size  runtime  systab

Що це означає: Якщо цей каталог існує, ви завантажились у режимі UEFI. Якщо ні — ви в legacy/CSM режимі.

Рішення: Якщо ви планували UEFI, а його немає — перезавантажте й виправте налаштування прошивки зараз. Не продовжуйте і «конвертуйте потім». Потім — це шлях до розділеного завантаження.

Завдання 2: Визначити диски і топологію (NVMe vs SATA, модель, розмір)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,ROTA,TRAN
NAME        TYPE   SIZE MODEL             ROTA TRAN
nvme0n1     disk 953.9G Samsung SSD 990      0 nvme
nvme0n1p1   part   512M                     0 
nvme0n1p2   part   128G                     0 
nvme0n1p3   part 825.4G                     0

Що це означає: ROTA 0 вказує на SSD/NVMe. TRAN показує транспорт. Це важливо для вибору планувальника і очікувань.

Рішення: Підтвердьте, що ви встановлюєте на правильний диск. Якщо ви бачите кілька дисків — промаркуйте їх фізично або за серійним номером перед розбивкою.

Завдання 3: Швидко перевірити стан диска (SMART/NVMe)

cr0x@server:~$ smartctl -a /dev/nvme0n1 | sed -n '1,25p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990
Serial Number:                      S7X3NX0W123456
Firmware Version:                   1B2QJXD7
NVMe Version:                       1.4
Total NVM Capacity:                 1,000,204,886,016 [1.00 TB]
...

Що це означає: Ви перевіряєте, що не встановлюєте на диск, що помирає, або на підробку з дивною прошивкою.

Рішення: Якщо SMART показує помилки медіа, критичні попередження або великий відсоток використання, замініть диск перед тим, як будувати щось «оптимізоване».

Завдання 4: Розбивка GPT (ESP + root + опційно swap)

cr0x@server:~$ parted -s /dev/nvme0n1 mklabel gpt
cr0x@server:~$ parted -s /dev/nvme0n1 mkpart ESP fat32 1MiB 513MiB
cr0x@server:~$ parted -s /dev/nvme0n1 set 1 esp on
cr0x@server:~$ parted -s /dev/nvme0n1 mkpart root ext4 513MiB 100%
cr0x@server:~$ parted -s /dev/nvme0n1 print
Model: Samsung SSD 990 (nvme)
Disk /dev/nvme0n1: 954GB
Partition Table: gpt
Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB                ESP   boot, esp
 2      538MB   954GB   953GB                root

Що це означає: Чистий GPT зі спадковим ESP. Розміри вирівняні. Прапори встановлені.

Рішення: Якщо ви хочете повного шифрування, зазвичай ставлять LUKS на partition 2 і створюють файлову систему в ньому. Рішаєте зараз; додавати шифрування пізніше — це хірургія.

Завдання 5: Форматування файлових систем з правильними параметрами

cr0x@server:~$ mkfs.vfat -F 32 -n EFI /dev/nvme0n1p1
mkfs.fat 4.2 (2021-01-31)
cr0x@server:~$ mkfs.ext4 -L gentoo-root /dev/nvme0n1p2
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 244190208 4k blocks and 61054976 inodes
Filesystem UUID: 8d3c1b5c-0e7d-4c6d-9a61-9a0d7b2e3c91
...

Що це означає: Мітки й UUID створені. Ви використовуватимете UUID у fstab, щоб пережити перейменування пристроїв.

Рішення: Якщо ви використовуєте SSD, подумайте про періодичний fstrim пізніше. Не монтуйте з дивними старими прапорами, якщо не можете їх пояснити.

Завдання 6: Структура монтування (просте краще, ніж хитре)

cr0x@server:~$ mount /dev/nvme0n1p2 /mnt/gentoo
cr0x@server:~$ mkdir -p /mnt/gentoo/boot
cr0x@server:~$ mount /dev/nvme0n1p1 /mnt/gentoo/boot
cr0x@server:~$ findmnt -R /mnt/gentoo
TARGET           SOURCE         FSTYPE OPTIONS
/mnt/gentoo      /dev/nvme0n1p2 ext4   rw,relatime
/mnt/gentoo/boot /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022

Що це означає: Ви бачите точно, що змонтовано куди. Жодних сюрпризів.

Рішення: Якщо ви плануєте окремі /var або /home, робіть це з конкретною метою (ізоляція IO, знімки, квоти), а не тому, що ви читали пост на форумі 2009 року.

Завдання 7: Перевірити мережу і DNS (збірки ламаються через дурниці)

cr0x@server:~$ ip -brief addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp4s0           UP             192.168.10.24/24 fe80::3a2f:.../64
cr0x@server:~$ getent hosts distfiles.gentoo.org
192.250.249.52   distfiles.gentoo.org

Що це означає: У вас є IP і DNS-резолюція працює.

Рішення: Якщо DNS не працює — виправте це перед тим, як звинувачувати Portage. Дивно багато «Gentoo не працює» насправді — «мій резолвер проклятий».

Завдання 8: Синхронізація часу (TLS і mirror-си ненавидять неправильні годинники)

cr0x@server:~$ date
Wed Feb  5 12:44:02 UTC 2026
cr0x@server:~$ timedatectl status | sed -n '1,8p'
Local time: Wed 2026-02-05 12:44:10 UTC
Universal time: Wed 2026-02-05 12:44:10 UTC
RTC time: Wed 2026-02-05 12:44:09
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

Що це означає: Ваш годинник не зламає TLS-завантаження або перевірку підписаної метадані.

Рішення: Якщо синхронізація часу неправильна — виправте NTP зараз. Неправильний час породжує дивні, переривчасті помилки — саме ті, які ви неправильно діагностуєте як «проблеми компілятора».

Завдання 9: Розпакувати stage3 і перевірити, що ви не змонтували неправильно

cr0x@server:~$ tar xpf stage3-amd64-openrc-*.tar.xz --xattrs-include='*.*' --numeric-owner -C /mnt/gentoo
cr0x@server:~$ ls /mnt/gentoo | head
bin
boot
dev
etc
home
lib
lib64

Що це означає: Файлова система заповнена. Якщо boot порожній але змонтований — добре. Якщо він не змонтований, ви щойно розпакували в неправильне місце і відчуєте це пізніше.

Рішення: Якщо ви забули змонтувати ESP у /mnt/gentoo/boot до розпакування — виправте монтування і продовжуйте, не перевстановлюйте. Але перевірте, куди що потрапило.

Завдання 10: Підготовка chroot (bind mounts і resolv.conf)

cr0x@server:~$ mount --types proc /proc /mnt/gentoo/proc
cr0x@server:~$ mount --rbind /sys /mnt/gentoo/sys
cr0x@server:~$ mount --make-rslave /mnt/gentoo/sys
cr0x@server:~$ mount --rbind /dev /mnt/gentoo/dev
cr0x@server:~$ mount --make-rslave /mnt/gentoo/dev
cr0x@server:~$ cp -L /etc/resolv.conf /mnt/gentoo/etc/
cr0x@server:~$ chroot /mnt/gentoo /bin/bash
cr0x@server:/# source /etc/profile
cr0x@server:/# env | grep -E 'CHOST|CFLAGS|MAKEOPTS' || true

Що це означає: Ваш chroot поводиться як система, з примонтованими пристроями та proc/sys.

Рішення: Якщо DNS не працює всередині chroot — /etc/resolv.conf неправильний. Виправте це перед тим, як emerging великих пакетів.

Завдання 11: Перевірка реальних можливостей CPU та пам’яті (налаштуйте MAKEOPTS відповідно)

cr0x@server:/# nproc
16
cr0x@server:/# free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi       2.1Gi       54Gi       175Mi       6.0Gi        59Gi
Swap:             0B          0B          0B

Що це означає: У вас 16 потоків і багато RAM. Збірки будуть обмежені CPU, а не пам’яттю.

Рішення: Встановіть MAKEOPTS="-j16" (або -j15, якщо хочете залишити систему більш чуйною). Якби у вас було 8GB RAM — треба бути обережнішим, особливо з LLVM-важкими збірками.

Завдання 12: Виміряти вузьке місце збірки (CPU vs IO)

cr0x@server:/# emerge --info | sed -n '1,40p'
Portage 3.0.67 (python 3.12.7-final-0, default/linux/amd64/23.0, gcc-14.1.0, glibc-2.40, 6.6.0-gentoo x86_64)
System uname: Linux-6.6.0-gentoo-x86_64-Intel-R-_Core-TM-_i9-12900K-with-glibc2.40
KiB Mem:   65923304 total,  57213448 free
KiB Swap:         0 total,         0 free
...

Що це означає: Ви захоплюєте базові дані про тулчейн і профіль. Цей вивід стає вашим «чеком збірки».

Рішення: Збережіть це у нотатках збірки. Якщо продуктивність зміниться пізніше — порівняйте. Gentoo робить дрейф очевидним; ваше завдання — зробити дрейф помітним.

Завдання 13: Перевірити здоров’я синхронізації репозиторію Portage

cr0x@server:/# emaint sync -a
=== Syncing repositories...
gentoo
	Syncing with rsync mirror...
	Successfully synced repository gentoo

Що це означає: Ваш tree актуальний. Якщо sync падає — ви будете ганятися за привидами залежностей.

Рішення: Якщо rsync ненадійний у вашому середовищі — перейдіть на метод, що працює для вас, і стандартизуйтесь на ньому для всіх машин.

Завдання 14: Переконатися, що ви використовуєте правильний профіль (не «на око»)

cr0x@server:/# eselect profile list | sed -n '1,14p'
Available profile symlink targets:
  [1]   default/linux/amd64/23.0 (stable)
  [2]   default/linux/amd64/23.0/systemd (stable)
  [3]   default/linux/amd64/23.0/desktop (stable)
  [4]   default/linux/amd64/23.0/desktop/systemd (stable)
cr0x@server:/# eselect profile set 1

Що це означає: Профілі визначають значення за замовчуванням: USE flags, маски, системні пакети. Обрати профіль — означає обрати модель експлуатації.

Рішення: Якщо ви хочете systemd — оберіть його зараз. Зміна пізніше — це міграційний проєкт, а не простий тумблер.

Завдання 15: Встановити джерела ядра і обрати підхід до ядра

cr0x@server:/# emerge --ask sys-kernel/gentoo-sources
[ebuild  N     ] sys-kernel/gentoo-sources-6.6.74  USE="-experimental" 0 KiB
Would you like to merge these packages? [Yes/No] yes

Що це означає: Ви встановлюєте джерела ядра, які використовує патчсет Gentoo.

Рішення: Якщо вам потрібно мінімум мороки — розгляньте пакет дистрибуційного ядра або відомий робочий конфіг. Якщо потрібен custom — робіть це, але тримайте конфіг у версійній системі для відтворюваності.

Завдання 16: Перевірити потреби в прошивці перед перезавантаженням (Wi‑Fi — класична пастка)

cr0x@server:/# lspci -nn | grep -Ei 'network|ethernet|wifi'
02:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-V [8086:15f3]
03:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6E AX211 [8086:7a70]

Що це означає: Ви можете передбачити, чи потрібні пакети linux-firmware для мережі після перезавантаження.

Рішення: Якщо бачите Wi‑Fi обладнання — заплануйте встановлення прошивки перед cutover. Інакше перший запуск стане полюванням за мережею.

Інженерні рішення для зберігання: ext4, XFS, Btrfs, ZFS

Зберігання — це місце, куди йдуть болі тюнінгу продуктивності, якщо ви не розумієте режим відмов. Для Gentoo вибір файлової системи також впливає на швидкість перебудови, бо збірки багато пишуть: розпаковування tarball, збір об’єктів, лінкування і запис пакетів.

ext4: дефолт, що не робить вас цікавим

ext4 досі найкраща відповідь на «Мені потрібно, щоб це завантажувалося, оновлювалося і виживало». Воно добре працює на NVMe, відновлюється передбачувано і не вимагає PhD для перевірки метаданих.

Операційно ext4 виграє тим, що коли щось йде не так — зазвичай вирішується стандартними інструментами і ясною ментальною моделлю. Це важливіше за теоретичний піковий throughput.

Btrfs: знімки і стиснення, але треба експлуатувати

Btrfs привабливий для Gentoo через знімки: можна зробити snapshot кореня перед ризикованим @world-апгрейдом і відкотитися, якщо ядро або libc стануть проблемою. Стиснення може зменшити IO під час збірок, особливо на повільніших SSD.

Підводний камінь: Btrfs потребує регулярної гігієни. Якщо ви його використовуєте — ви повинні реально запускати scrub, перевіряти помилки пристроїв і розуміти структуру субтомів. Файлова система з фічами — це файлова система з обов’язками.

ZFS: цілісність і відкат як стиль життя

ZFS для людей, які хочуть сильний контрольних сум, знімки і реплікаційні workflow. Він відмінний у продакшні при правильній експлуатації. Але це не «встановив і забув». Ви обираєте екосистему: сумісність модуля ядра, інтеграцію initramfs, рішення по розташуванню пулів і моніторинг.

Якщо ви будуєте робочу станцію і вам не потрібна модель цілісності ZFS — не використовуйте його лише тому, що бачили скріншот списку знімків. Використовуйте його, якщо хочете послідовний, тестований відкат і захист даних.

Практичне правило продуктивності зберігання для збірок Gentoo

Якщо збірки здаються повільними, не починайте з тюнінгу прапорців компілятора. Спочатку запитайте: чи обмежені ви IO під час розпакування та запису великої кількості малих файлів? Якщо так — затримка файлової системи й диска домінує. NVMe допомагає. Також корисно тримати PORTAGE_TMPDIR на швидкому локальному сховищі і уникати мережевих директорій для збірки.

Стратегія ядра: generic, custom і «не будьте хитрими» посередині

Ядро — це місце, де новачки в Gentoo або вчаться дисципліні, або вчаться на помилках. У вас є три життєздатні стратегії:

Стратегія A: Використовувати generic/distribution kernel

Це найкращий підхід, коли вам важлива швидкість до робочої системи. Ви отримуєте широку підтримку обладнання, менше сюрпризів і легші оновлення. Якщо ви розгортаєте fleet — стандартизуйте тут.

Стратегія B: Мінімальне кастомне ядро

Це «не будьте хитрими» посередина: почніть від відомого робочого конфігу (часто defconfig або конфіг дистро), ввімкніть тільки потрібне (файлові системи, NVMe, мережа) і тримайте його відтворюваним. Мета — не крихітне ядро, а ядро, яке ви можете перебудувати і відлагодити.

Стратегія C: Агресивне кастомне ядро

Робіть це тоді, коли знаєте, навіщо: latency-sensitive навантаження, вбудовані обмеження або жорсткі вимоги безпеки. Якщо ваша мотивація — «воно буде швидше» — зупиніться. Більшість продуктивності походить від планувальника, шляху IO і поведінки пам’яті — не від видалення випадкових драйверів.

Жарт №2: Кастомне ядро — як татуювання: воно може мати сенс, але «мені було нудно» — не найкраща мотивація.

Налаштування Portage для швидкості без обману

Конфігурація Portage — інтерфейс між вашим залізом і вашим часом. Мета — не «максимальна оптимізація». Мета — передбачувані збірки, швидкі оновлення і достатня швидкість, щоб ви не відкладали патчі.

make.conf: розумні значення за замовчуванням

У 2026 найбільші помилки все ще класичні: надмірно агресивні CFLAGS, занадто паралельні збірки і ввімкнення всіх USE flags через «фічі — це добре». Фічі — це залежності. Залежності — це вектор атак і час перебудови.

Що я рекомендую:

Тримайте CFLAGS консервативними. -O2 -pipe і правильний -march зазвичай достатні. Уникайте -Ofast, якщо не можете перевірити коректність для вашого навантаження.
Використовуйте MAKEOPTS відповідно до пам’яті. Потоки дешеві, поки не стають дорогими. Під час лінкування пам’ять різко зростає.
Увімкніть FEATURES="buildpkg" на початку. Бінарні пакети — машина часу. Ви подякуєте собі, коли потрібно перевстановити або відкотитися.
Зафіксуйте глобальні USE flags у реальності. Включуйте те, що використовуєте. Якщо ви не користуєтеся Bluetooth — не компілюйте Bluetooth у всьому world.

Вибір компілятора: GCC підходить, LLVM підходить — просто будьте консистентні

Варіації тулчейна викликають дивні помилки. Оберіть компілятор і стандартизуйтесь на ньому, якщо ви ділитеся бінарями між системами. Якщо будуєте на хості A і ставите на хост B — вирівняйте CPU-таргети і версії тулчейна, або збирайте «Illegal instruction» як сувенірні випадки.

ccache: хороший слуга, поганий господар

ccache може значно скоротити час перебудов, особливо для ітеративних збірок ядра і великих C/C++ проектів. Але це не магія. Воно займає диск. Може приховувати проблеми, якщо ви не інвалюєте кеш вчасно. Використовуйте з моніторингом і лімітом розміру.

Бінарні пакети: дорослий компроміс

Неприємна правда: найкраща «оптимізація продуктивності Gentoo» — це не прапорець компілятора. Це робочий процес. Бінарні пакети дають можливість перебудувати один раз і розгорнути багато разів, або принаймні перевстановити без повного податку на компіляцію.

На практиці бінарні пакети допомагають у:

Швидкому відновленні. Якщо диск помер — ви перевстановлюєте і тягнете бінарі з кешу або репозиторію.
Безпечних оновленнях. Якщо апгрейд ламає userland — відкат легший, коли можна перевстановити відомі добрі бінарі.
Консистентності fleet-а. Якщо у вас більше однієї Gentoo-машини, узгоджені бінарі зменшують дрейф.

Компроміс — операційний: потрібно зберігати пакети десь, керувати підписами, якщо важливо, і враховувати ABI‑сумісність. Варто того.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через хибне припущення

У середній компанії з міксованим fleet-ом Linux команда вирішила використовувати Gentoo для latency-sensitive сервіса. Вони зібрали красиве кастомне ядро, підлаштували CPU flags і запхнули в продакшн. Все виглядало добре — поки не настав перший цикл рутинних оновлень.

Хибне припущення було тонким: вони вважали, що «та сама сімейство CPU» означає «такий же набір інструкцій». Хост для збірок мав новіші CPU з додатковими інструкціями. Продакшн-хости були подібної марки і покоління, але не ідентичні. Бінарі, побудовані з агресивним -march, нормально працювали в staging (той же хардвер, що й build box) і падали в продакшні з Illegal instruction.

On-call спочатку підозрював корупцію пам’яті або поганий компілятор. Підписи падінь були непослідовні, бо різні процеси викликали різні кодові шляхи. Логи були шумними. Сервіс флапав під навантаженням.

Виправлення було нудним: перебудувати з консервативним таргетом, вирівняним за найстарішим CPU у fleet, і ввести CI-gate, що проганяє тест валідації набору інструкцій на репрезентативному обладнанні перед релізом.

Урок закріпився: портативність не безкоштовна, і «воно завантажується» — це не доказ. Якщо ви будете шукати бінарі між машинами — вам потрібен контракт сумісності апаратури.

Міні-історія 2: Оптимізація, що відвернулася назад

Інша організація спробувала «прискорити збірки», помістивши тимчасову директорію Portage на мережевий файловий шар, спільний для билдерів. Ідея здавалася ефективною на папері: централізоване сховище, великий кеш, менше дублювання.

На практиці це було латентне лихо. Збірки створюють і видаляють гори дрібних файлів. Операції метаданих домінували. Мережевий ФС поводився так, як це властиво мережевим ФС під таким навантаженням: він став симулятором розподілених локів.

Гірше того, коли команда зберігання робила рутинне обслуговування, спільний ФС мав короткі зупинки. Локальні збірки зависали. CI-джоби накопичувались. Розробники вирішили, що Gentoo «не масштабується», що було несправедливо — вузьким місцем була їхня IO-архітектура.

Відкат був простим: тримайте PORTAGE_TMPDIR локально на NVMe для кожного билдера, зберігайте фінальні бінарні пакети на спільному сховищі, і покладайтесь на ccache плюс дзеркалення distfiles, а не NFS для scratch-space.

Урок: оптимізація без чіткого визначення вузького місця — це дорогий спосіб пересунути проблеми.

Міні-історія 3: Сумна практика, що врятувала день

Регульована компанія використовувала Gentoo на кількох внутрішніх серверах — нічого гламурного, переважно оркестрація збірок і управління артефактами. Підхід не був хитрим. Він був дисциплінований.

Всі конфіги жили у контролі версій: /etc/portage, конфіги ядра, конфіги bootloader, fstab, навіть невеликий post-install скрипт, що застосовував sysctl і вмикав сервіси. Коли систему інсталювали, її не «налаштовували вручну». Її «застосовували».

Одного дня самовпевнена зміна глобальних USE flags спричинила перебудову, що тонко змінила вибір залежностей. Сервіс почав відмовляти при запуску після перезавантаження, бо плагін більше не компілювався. Це могло стати довгим пошуком винних.

Натомість вони зробили чистий відкат, відкативши коміт до попереднього відомо доброго стану, перебудували бінарі в CI і перевикотили. Вони повернулися в сервіс до того, як бізнес встиг би назвати це простою.

Урок: операційна досконалість — це переважно паперова робота й звички. Це нецікаво, але працює.

Плейбук швидкої діагностики: знайти вузьке місце за хвилини

Коли ваш Gentoo інстал або збірка здається повільною, не починайте «тюнінг». Почніть діагностику. Ось порядок, що економить час.

Спочатку: Чи чекаєте ви мережі?

Симптоми: emerge зависає під час fetch, sync йде вічно, переривчасті таймаути.
Перевірка: DNS-резолюція, досяжність mirror-ів, втрата пакетів.

cr0x@server:~$ ping -c 3 distfiles.gentoo.org
PING distfiles.gentoo.org (192.250.249.52) 56(84) bytes of data.
64 bytes from 192.250.249.52: icmp_seq=1 ttl=49 time=23.4 ms
64 bytes from 192.250.249.52: icmp_seq=2 ttl=49 time=24.1 ms
64 bytes from 192.250.249.52: icmp_seq=3 ttl=49 time=22.9 ms

--- distfiles.gentoo.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Рішення: Якщо втрата пакетів ненульова або латентність нестабільна — виправте мережу спочатку або змініть mirror. Не «просто повторюйте» і не вважайте це вирішенням.

Друге: Чи прив’язано це до IO?

Симптоми: CPU під час збірок низький, багато очікування, система «смикається».
Перевірка: завантаження диска, IO wait, стан файлової системи.

cr0x@server:~$ iostat -xz 1 3
Linux 6.6.0-gentoo (server) 	02/05/26 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.30    0.00    4.10   28.70    0.00   54.90

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1          45.0   2100.0     0.0    0.0    1.2    46.7     980.0  22000.0     0.0    0.0   16.5    22.4   16.3   98.0

Рішення: Високий %iowait і близька до 100% завантаженість диска означають, що обмеження — це сховище. Перенесіть тимчасові файли збірки на швидше сховище, увімкніть стиснення за потреби або зменшіть паралелізм.

Третє: Чи обмежено це CPU або пам’яттю?

Симптоми: CPU в 100%, вентилятори гуде, кроки лінкування OOM, збірки падають загадково.
Перевірка: load average проти кількості CPU, тиск пам’яті, свопінг.

cr0x@server:~$ uptime
 12:58:02 up  1:14,  1 user,  load average: 28.12, 23.55, 18.42
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
18  2      0 1520000 110000 4200000  0    0   120  2200 4200 9000 65  8 10 17  0

Рішення: Якщо load значно перевищує кількість потоків CPU і wa високий — це IO. Якщо з’являється активність si/so (своп) — у вас дефіцит пам’яті; зменшіть -j або додайте swap.

Поширені помилки: симптом → корінь проблеми → вирішення

1) «Не завантажується після встановлення»

Симптом: Завантаження заходить у меню прошивки або повідомляє «no bootable device».

Корінь проблеми: Встановлено в legacy-режимі, а очікували UEFI; ESP не був змонтований під час інсталяції; або bootloader не встановлено в ESP.

Вирішення: Завантажте live-медіа в режимі UEFI, змонтуйте ESP у /boot, перевстановіть bootloader, перевірте записи NVRAM.

cr0x@server:~$ efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0003
Boot0001* gentoo	HD(1,GPT,...)File(\EFI\gentoo\grubx64.efi)

Рішення: Якщо немає запису для Gentoo — створіть/перевстановіть його. Якщо запис існує, але вказує на неправильний шлях — виправте шлях встановлення bootloader.

2) «emerge повільний, а CPU простає»

Симптом: Збірка повзає, CPU низько, індикатор диска горить постійно.

Корінь проблеми: IO-вузьке місце, часто через повільний диск, невдалий вибір FS для навантаження або розміщення build dir на мережевому сховищі.

Вирішення: Помістіть PORTAGE_TMPDIR на швидкий локальний SSD/NVMe, переконайтесь, що немає дивних опцій монтування, зменшіть MAKEOPTS, якщо ви насичуєте IO паралельними записами.

3) «Випадкові збої збірок, що зникають при повторі»

Симптом: Компіляція випадково падає.

Корінь проблеми: Нестабільна RAM, перегрів CPU, ненадійне сховище або агресивний розгін; інколи misbehaving ccache.

Вирішення: Прогнати тести пам’яті, перевірити термальні умови, перевірити SMART, відключити розгін, очистити ccache.

cr0x@server:~$ dmesg -T | tail -n 12
[Wed Feb  5 13:10:22 2026] mce: [Hardware Error]: CPU 7: Machine Check: 0 Bank 5: bea0000000000108
[Wed Feb  5 13:10:22 2026] mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000

Рішення: Якщо бачите MCEs — перестаньте «відлагоджувати Gentoo» і почніть відлагоджувати апаратне забезпечення.

4) «World update хоче перебудувати півпланети»

Симптом: Велика перебудова після малої зміни.

Корінь проблеми: Зміни глобальних USE flags, зміна профілю, ABI-break (компілятор/glibc) або зміна Python slot.

Вирішення: Робіть зміни свідомо, перегляньте depgraph і віддавайте перевагу per-package USE flags для вузьких фіч. Використовуйте бінарні пакети, щоб зробити перебудови менш болісними.

cr0x@server:~$ emerge -pvuDN @world | head -n 18
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  U  ] sys-libs/zlib-1.3.1 [1.3] USE="minizip -static-libs"
[ebuild  R  ] media-libs/libpng-1.6.43  USE="apng -static-libs"
...

Рішення: Якщо список величезний — зупиніться і з’ясуйте, що змінилося. Не дозволяйте перебудову, якій не можете пояснити.

5) «Wi‑Fi працював у live, але не після перезавантаження»

Симптом: Відсутній бездротовий інтерфейс або помилки завантаження прошивки в dmesg.

Корінь проблеми: Відсутні пакети прошивки в установленій системі.

Вирішення: Встановіть прошивку і переконайтесь, що конфіг ядра включає потрібні драйвери.

cr0x@server:~$ dmesg -T | grep -i firmware | tail
[Wed Feb  5 14:02:11 2026] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-83.ucode failed with error -2

Рішення: Якщо бачите failed with error -2 — це відсутня прошивка. Встановіть її перед тим, як чіпати мережеві налаштування.

Контрольні списки / покроковий план

Фаза 0: Preflight (зробіть це перед роботою з дисками)

Завантажте live-медіа у режимі UEFI (існує /sys/firmware/efi).
Підтвердьте правильний диск за допомогою lsblk та моделі/розміру.
Перевірте стан диска (SMART/NVMe summary).
Підтвердьте мережу і DNS-резолюцію.
Синхронізуйте годинник (NTP active).

Фаза 1: Розбивка диска (тримайте просто)

Створіть GPT.
Створіть ESP (512MiB цілком підходить).
Створіть root-партіцію (або LUKS-контейнер).
Форматуйте ESP як FAT32; формат root як ext4/Btrfs/ZFS за вибором.
Змонтуйте root у /mnt/gentoo, ESP у /mnt/gentoo/boot.

Фаза 2: Базова система (stage3 + chroot)

Розпакуйте stage3 з xattrs.
Змонтуйте /proc, /sys, /dev bind mounts.
Скопіюйте resolv.conf.
Chroot і завантажте середовище.
Синхронізуйте репозиторії і виберіть профіль.

Фаза 3: Вибір параметрів збірки (зробіть так, щоб швидко перебудовувати)

Встановіть консервативні CFLAGS, розумні MAKEOPTS.
Увімкніть бінарні пакети (FEATURES="buildpkg") і вирішіть, де зберігати.
Опційно увімкніть ccache і обмежте його розмір.
Встановіть джерела ядра і оберіть стратегію ядра.
Встановіть пакети прошивки, релевантні вашому обладнанню.

Фаза 4: Завантаження і перший reboot (саме тут інсталяції вмирають)

Створіть /etc/fstab використовуючи UUID.
Встановіть і налаштуйте bootloader для UEFI.
Згенеруйте initramfs, якщо потрібно (шифрування, ZFS, складне зберігання).
Встановіть hostname, мережу, часовий пояс і користувачів.
Перезавантажте і перевірте: логи завантаження, мережу, точки монтування.

ЧаПи

1) Чи варто встановлювати Gentoo у 2026?

Так, якщо вам важливий контроль, відтворюваність і довготривалий тюнінг продуктивності. Ні, якщо ви хочете систему, що ховає складність і приймає рішення за вас.

2) Чи слід використовувати `-march=native`?

На одній машині, що ніколи не ділитиметься бінарями — це ок. У fleet-і або будь-якому workflow, що розгортає бінарі між хостами — це пастка, якщо залізо не ідентичне.

3) OpenRC чи systemd: яка операційна різниця?

OpenRC прозорий і легкий; systemd тісно інтегрований з сучасним Linux userland. Оберіть один і стандартизуйте. Найгірша система ініціалізації — «обидві, залежить від хоста».

4) Чи потрібен swap на сучасній машині?

Якщо ви компілюєте великі C++ проекти, трохи swap може запобігти катастрофічним OOM під час лінкування. Навіть невеликий swapfile — дешева страховка, особливо на системах з 16GB або менше.

5) Яка файлова система найкраща для продуктивності Gentoo?

На NVMe ext4 важко побити за простотою і швидкістю без зайвих ускладнень. Btrfs може бути чудовим зі стисненням і знімками, якщо ви вмієте його експлуатувати. ZFS відмінний для цілісності і відкатів, але з інтеграційними витратами.

6) Як зробити оновлення `@world` менш болючими?

Використовуйте бінарні пакети, уникайте випадкових змін глобальних USE, тримайте профіль стабільним і переглядайте плановані мержі перед натисканням Enter.

7) Який найшвидший безпечний спосіб прискорити збірки?

Почніть з бінарних пакетів + ccache + розумний паралелізм. Залізо теж допомагає: більше RAM і швидкий NVMe часто перевершують будь-яку фігуру з прапорцями компілятора.

8) Чому збірки падають лише на одній машині?

Зазвичай це нестабільність апаратури, thermal throttling, невідповідність набору інструкцій або відмінний тулчейн. Перевірте MCE логи, CPU flags і версії тулчейна, перш ніж звинувачувати ebuild.

9) Чи можна використовувати Gentoo на ноутбуках без мук?

Так: активно використовуйте бінарні пакети, уникайте компіляцій від батареї і не перетворюйте ноутбук на build farm, якщо вас не приваблює тепло і шум вентиляторів.

10) Що тримати в контролі версій?

/etc/portage, конфіги ядра, конфіги bootloader і будь-які post-install скрипти або sysctl налаштування. Якщо це змінює поведінку — воно має бути в репозиторії.

Висновок: наступні кроки, які можете зробити сьогодні

Хороша інсталяція Gentoo — це не понт. Це операційний актив: система, яку можна перебудувати, патчити і тюнити без містики. Головний рух — припинити ставитися до інсталяції як до ритуалу й почати розглядати її як продукт збірки.

Наступні кроки, що віддають віддачу відразу:

Закомітьте /etc/portage і конфіг ядра у систему контролю версій.
Увімкніть бінарні пакети і вирішіть, де вони житимуть (локальний кеш, NAS або сервер артефактів).
Програйте плейбук швидкої діагностики один раз під час великої збірки, щоб дізнатися, чи ви CPU-, IO- чи мережево-обмежені.
Оберіть одну оптимізацію, яку можна виміряти (ccache hit rate, час збірки, IO wait) і покращуйте її, не порушуючи відтворюваність.

Якщо ви це зробите, отримаєте справжню користь від Gentoo: не «зібрано», а контрольовано. І швидше назавжди, бо ви зможете довести, що змінили.