Lumier

В принципе, если гуглить «Gentoo Handbook», то результат не заставит себя ждать. Но те хэндбуки, которые вам предложат, имеют следующие общие недостатки.
Во-первых, все они на английском языке. Даже для человека, достаточно хорошо учившего инглиш в школе, работа по таким руководствам сопряжена с трехкратным перерасходом умственных и нервных ресурсов. А такие ресурсы имеют свойство пропорционально конвертироваться в белково-фосфорные, а те, в свою очередь, - в рублево-долларовые. Отсюда очевидное решение: перевести хэндбук на русский, но…
Во-вторых, хотя хэндбук на первый взгляд выглядит достаточно подробно, фактически в нем имеются некоторые пробелы, особенно на границах этапов. Так что читателю бывает трудно понять, где он сейчас находится и почему именно сейчас нужно выполнить именно эту операцию.
В-третьих, в хэндбуке весь процесс описывается как чисто линейный, как будто все операции выполняются с первой попытки и с положительным результатом. Готов поверить, что в большинстве случаев так и происходит. Но такой большой корабль, как я, завсегда найдет свою мель там, где маленькие лодки и катера проходят свободно. И вот первая же моя попытка установить Генту привела к нескольким аварийным ситуациям, о которых в хэндбуке ни слова. Я, разументся, с вами своими «открытиями» поделюсь.
В-четвертых, я предпочитаю в своих статьях излагать только ту информацию, которую проверил, так сказать, на своей шкуре. Ну разве что с эпизодическими примечаниями типа «товарищ пишет, но сам я не пробовал». Такую информацию я считаю более ценной, чем любой перевод.

Прежде всего хочу оговориться, так сказать, глобально: эта статья для владельцев обычных PC-совместимых компьютеров (настольных, ноутбуков и серверов на процессорах Интел и АМД). Генту ставят и на другие компьютеры, но это не та работа, в которую нужно бросаться очертя голову без надлежащей подготовки.
Если я когда-нибудь буду профессором, то эту тему буду преподавать на третьем курсе. Исхожу из расчета: на первом курсе - установка какого-нибудь легкожанрового дистрибутива типа Linux Mint, работа в качестве конечного пользователя (Libre Office, GIMP, Image Magick, mplayer, VLC, Konqueror…), начала системного администрирования (консольные команды, bash-скрипты https://losst.ru/napisanie-skriptov-na-bash , Практикум по написанию сценариев оболочки), настройка сетей на уровне статических IP-адресов и DHCP, основные клиент-серверные протоколы; на втором курсе - установка более серьезного дистрибутива типа Debian и, соответственно, более глубокое системное администрирование с написанием конфигурационных файлов (см., например, мои же статьи Udev и его применение для монтирования файловой системы, PPPD и его применение для "мобилизации" интернета в Linux), основы сетевой маршрутизации. И вот на третьем курсе - Гента… а что на четвертом? Вероятно Linux from scratch https://habrahabr.ru/post/113615/ https://losst.ru/lts-linux-from-scratch .
Какими знаниями и умениями должен обладать начинающий гентушник?
Перечисляю то, что можно с успехом изучить в рамках Дебиана:
* Представление о жестких дисках и дископодобных запоминающих устройствах, разделах, файловых системах и операции монтирования;
* Навыки создания образов дисков и записи их на CD/DVD диск;
* Начальные навыки налаживания локальных сетей Ethernet, представление о маршрутизации, основные клиент-серверные протоколы;
* Установка ПО с репозиториев в бинарных дистрибутивах с использованием пакетных менеджеров типа dpkg, apt, aptitude, synaptic или их красношапочных аналогов;
* Использование системных утилит типа tar, текстовых редакторов (типа nano, vi/vim) и другого сисадминского инструментария.
* Хорошо прокачанный инглиш: без него вам в гентовском мире придется туго.

Чтобы ответить на этот вопрос, разберемся, чем Gentoo отличается от других систем.
Что такое вообще проект GNU/Linux? Это огромный набор колесиков-винтиков, камешков-кирпичиков для сборки операционной системы. Если это все собрать воедино, то получим что-то монструозное и совершенно нерабочее. Поэтому умные люди собирают не все в кучу, а выборочно. Скачивают исходные тексты программ, компилируют и получают систему такую, как им надо. Во времена моей досовской молодости таких людей называли отморозками или беспредельщиками, но в линуксах вообще нет понятия «беспредел»: эдесь это нормальное явление. Другое дело что такая технология сложна, хлопотна, требует больших знаний и в общем-то не всем нужна. Отсюда вытекает идея и понятие дистрибутива.
Что такое дистрибутив? Дистрибутив характеризуется (а) репозиторием - централизованным хранилищем софта, (б) стандартизованным форматом пакетов, размещаемых на этом хранилище, (в) типовой процедурой установки этих пакетов, (г) подбором софта для размещения в репозитории на вкус создателя дистрибутива и (д) своими программными средствами, облегчающими установку системы. Грубо говоря, разработчик дистрибутива сделал за нас половину работы по формированию системы из «колесиков и винтиков». Сделал на свой вкус, но это не означает, что сделал с бухты-барахты: надо понимать, что его «вкус» имеет под собой какие-то технические обоснования. А вот какие именно - это уже другой разговор.
Большинство дистрибутивов - «бинарные». Этот термин означает, что в них весь софт (как системный, так и прикладной) представлен в репозитории в виде предварительно скомпилированных пакетов, содержащих выполнимый («бинарный») код, а не исходные тексты программ. Такие пакеты сравнительно быстро устанавливаются, но без возможности для нас выбирать, что в той или иной программе нам действительно нужно, а что нет: каждая программа содержит в себе весь функционал, заложенный в нее разработчиком. Это же относится и к ядру системы.
Дистрибутивов очень много, так что теоретически каждый может найти систему, удовлетворяющую его требованиям. Однако быстрорастущему линуксоиду со временем становится тесно в рамках дистрибутива - и он начинает задумываться о Генте…
Каково место Генты в картине, которую мы только что нарисовали?
Ее место в середине. С одной стороны, здесь, как и в дистрибутивах, имеется репозиторий с пакетами, но наши пакеты содержат не выполнимый код, а исходные тексты программ, и компилировать их приходится нам на нашем компьютере, на который мы их хотим установить (хотя в то же время имеется и поддержка предварительно скомпилированных пакетов). С другой стороны, создатель Генты ничего не решает для нас / за нас, оставляя нам полную свободу выбора.
Установка гентовских пакетов включает компиляцию исходных кодов, а это долгий процесс: установка, например, Libre Office может затянуться на целую ночь. За что такая плата? - За возможность исключить из программ (любых - вплоть до ядра системы) много такого, что нам не нужно. Причем копаться в исходных текстах программ нам не придется: предусмотрен другой механизм. В результате можем получить компактную и быструю систему, максимально приспособленную как к нашему оборудованию, так и к нашим задачам. Попросту говоря - «допиленную для себя». Причем вся конфигурация системы осуществляется либо посредством консольных команд, либо с помощью обычных текстовых файлов, которые могут быть прочитаны человеком. А если можно прочитать, то отчего бы не попробовать написать? Разумеется, все это требует знаний - более глубоких, чем для освоения бинарных дистрибутивов. Простая копипаста здесь мало полезна.
Генту иногда называют метадистрибутивом.
Получается, что Гента - система не просто для очень продвинутого пользователя, но для любителя и ценителя, но такая система никогда не захватит весь рынок линуксоидных систем (если здесь вообще уместно говорить о рынке) - она стоит и будет стоять особняком.
Нужна ли такая система вообще? - Без нее линуксоидный мир был бы совсем не тот… Gentoo - это мир, где можно выбирать все. Здесь вас не будут заставлять делать то, что вам не нравится. Это система с ясной и гибкой структурой, которая ничего не прячет под капюшоном. (это я просто перевел несколько фраз из хэндбука - время от времени я все же буду к этому прибегать).
Нужна ли Гента конкретно вам? - вот вопрос, на который никто, кроме вас, не сможет ответить. После трех лет в Дебиане, когда я еще смотрел на Генту с определенным пессимизмом («сложная, зараза!»), у меня состоялся примерно такой разговор с моим компьютерным гуру:
– Может, не стоит мне соваться в Генту, может, лучше стать хорошим дебианщиком, чем посредственным гентушником?
– Ты не сможешь стать хорошим дебианщиком, пока не побываешь посредственным гентушником.
К этому, собственно, остается добавить еще вот что. Установка Генты и последующее ее обновление выполняется путем закачки софта из интернета. Так что, если у вас нет возможности хотя бы эпизодически подключаться к недорогому скоростному интернету, то, вероятно, Гента - не ваш вариант.
Ну а если выбор сделан, тогда - полный вперед!

Что имеем на начальном этапе нашей работы: компьютер с материнской платой, процессором и оперативной памятью; к компьютеру подсоединен жесткий диск («винчестер»), на котором либо совсем ничего нет, либо установлена какая-то другая ОС, которую не жалко снести (вместе со всем файловым хозяйством, если оно еще не скопировано на другие носители!!!).
Что касается количественных требований к «железу», то Гента, в свете того что мы про нее уже знаем, может рассматриваться как легковесный дистрибутив с весьма скромными аппаратными притязаниями. В хэндбуке пишут: нужно 512МБ оперативной памяти и 2.5ГБ на жестком диске. Последняя цифра у меня вызывает некоторые сомнения - вероятно она устарела. Сейчас я экспериментирую на предмет установки Генты на 8-ГБ раздел. Впрочем, в наше время, когда винчестер на 80ГБ уже считается безнадежным старьем, такие сомнения можно просто забыть.
Здесь надо заметить, что в Генте, в отличие от большинства других ОС разных семейств, не предусмотрено никаких особых программ-установщиков. Она, подобно строительному башенному крану, сама себя поднимает с помощью своих собственных механизмов, не нуждаясь в какой-либо посторонней помощи. И это чертовски здорово, потому что процесс установки (при наличии хорошей «технологической документации») уже сам по себе обогащает нас массой знаний и впечатлений. Однако из этого следует, что на первом этапе нам надо загрузить компьютер Гентой с какого-то вспомогательного носителя без установки ее на жесткий диск, чтобы установить ее туда уже потом. В принципе, можно использовать и негентовый загрузочный диск. Например Debian Live-DVD (да, теперь и такой бывает).
В хэндбуке упоминается множество вариантов: установка с флэшки, или по сети, или наоборот совсем без сети…
Минимальный установочный диск имеет объем порядка 200МБ, но для того чтобы им воспользоваться, нам сразу потребуется подключение к Сети. LiveDVD содержит хотя и минималистическую, но все же полностью жизнеспособную систему, с помощью которой мы сможем выполнять кое-какие операции, даже если подключиться к Сети не удается.

Будем использовать загрузочный LiveDVD-диск. У запасливого гентового сисадмина такой диск имеется в сундуке на самом дне. А если нет, то придется изготовить его сейчас. Для этого нам сгодится любой компьютер с любой операционной системой - да хоть с виндами, лишь бы была возможность скачать из Сети образ диска и «прожечь его на болванку». Как это делается, я сейчас конкретизировать не буду. Сейчас для нас более существенный вопрос: откуда качать?
Вот отсюда:
https://www.gentoo.org/downloads/
Там нужно выбрать файл образа, соответствующий архитектуре вашей машины.

Архитектура - совокупность важнейших черт внутреннего устройства, которыми разные компьютеры сходны или различны между собой. В нынешнем компьютерном мире разных архитектур довольно много (даже не считая тех, которые уже вышли или скоро выйдут из употребления). Генту можно установить на самые разные компьютероподобные устройства, но сегодня мы ограничимся «нормальными», или «большими», или общеупотребительными компьютерами.
В этот класс входят обычные настольные ПК, ноутбуки и серверы. Их общая черта: имеется жесткий диск, на котором хранится как сама операционная система, так и прикладное ПО, и пользовательское «файловое хозяйство». И с этого же жесткого диска система должна загружаться при включении компьютера, так что нам придется выполнить работу по установке системы на жесткий диск.
Если рассматривать именно такие компьютеры, то окажется, что разнообразие их архитектур не так уж и велико. Архитектура x86, она же i386, она же i486…i686, соответствует устаревшим 32-разрядным компьютерам. Еще более старые процессоры типа 486 мы здесь не рассматриваем. Более современные 64-разрядные машины строятся на процессорах Intel или AMD, т. е. имеем всего три архитектуры. К сожалению, в названиях архитектур нет какого-то общепринятого стандарта, и из-за этого может создаться впечатление, что их больше.
Софт, собранный для 64-разрядного компьютера, на 32-разрядном работать не будет категорически. ПО для 32-разрядного на 64-разрядном будет работать так же, как на 32-разрядном, т. е. без использования преимуществ 64-разрядного процессора. И уж, конечно, если у вас процессор многоядерный, то с 32-разрядным ПО вы никакой многоядерности не увидите.
Между процессорами Intel и AMD гораздо больше сходства, чем различия. Архитектура x86_64 (иногда для полной ясности пишут Generic x86_64) описывает обе эти архитектуры в той части, насколько они сходны. Грубо говоря, в такой программе имеются только команды, общие для двух марок процессоров - это компромиссное решение. Впрочем, в наше время все это уже неактуально: несколько лет назад Intel выкупил технологии AMD, так что теперь x86_64 и amd64 - одно и то же, и остается для нас всего две архитектуры: x86 и x86_64.
Как узнать, какой у вас процессор?
Вот таким текстом я буду изображать экран компьютера вместе со всем, что на него выводится, а подчеркнутым - наши команды:

LiveCD # uname -m
i686

(в этом примере видим 32-разрядный процессор).

Размер iso-образа около 2ГБ, так что CD-диском тут не обойдется - нужен DVD.
Однако по-любому дисковая технология должна считаться устаревшей. Чем носить с собой 13-сантиметровый диск (к тому же довольно хрупкий), который еще надо куда-то воткнуть (не все современные компьютеры имеют дисководы), куда удобнее использовать USB-флэшку, умещающуюся в любой карман. Игра построена на том, что компьютер не знает, на каком материале и каким физическим образом записаны данные. Да ему и дела до этого нет: он видит просто блочное устройство и файловую систему на нем - и работает как ему привычно. Мы же можем «прожечь» ISO-образ на флэшку почти так же, как и на диск:

root@bigwhite:/home/igor# dd if=/home/igor/livedvd-amd64-multilib.iso of=/dev/sdb bs=1M

Уточните имя вашего образа и букву устройства (!!!), чтобы не разрушить какое-то другое файловое устройство на вашем компьютере.
Эта команда выполняется довольно долго, а по ее итогам получим флэшку, вся структура данных на которой полностью имитирует Live-диск. Все данные «весят» чуть больше 2ГБ, стало быть понадобится флэшка на 4ГБ. На ней останется порядочное пустое место, но использовать его обычным образом мы не сможем: свойственная флэшке файловая система vfat нарушена, а файловая система Live-диска не приспособлена для записи новых файлов. Существуют хитрости, позволяющие это обойти, но сейчас на этом останавливаться не будем.
Вот здесь http://www.opennet.ru/base/sys/live_flash2.txt.html изложен более интеллигентный вариант, суть которого в том, что мы не просто воспроизводим на флэшке копию Live-диска, а копируем файлы и каталоги в рамках файловой системы vfat, которая на флешках практически всегда применяется. Увы, сегодня такой метод неосуществим: в составе LiveDVD имеется один файл, размер которого больше 2ГБ, а такой файл в системе vfat не может быть записан.
Есть, конечно, еще более красивый вариант: установить на флэшку не Live, а полнопрофильную систему. Но для этого нам все равно потребуется какой-то вспомогательный загрузочный носитель, а уж если он у нас есть, то установить полнопрофильную систему на флэшку можно будет точно так же, как на «винчестер».

Теперь загружаем «приговоренный» к установке компьютер с этого диска. В процессе загрузки на экран будет выдаваться множество сообщений о том, какие операции выполняются на каждом этапе загрузки. В частности, система «прощупывает» все устройства, подключенные к компьютеру, и устанавливает нужные драйверы. Заканчивается это все системным приглашением:

LiveCD #

Это приглашение намекает на то, что система готова к работе и ждет наших команд. Причем знак # говорит о том, что мы сразу можем давать команды с полномочиями суперпользователя (рута) - без этого установить систему едва ли удалось бы.
Вся последующая установка системы выполняется с консоли, в диалоговом режиме: никаких графических средств на этом этапе нам не обеспечено.
Итак, приступаем.

Что имеем: наш компьютер загружен настоящей Гентой, но минималистической: в нашем распоряжении лишь «малый джентльменский набор» команд, необходимых для последующей установки системы на жесткий диск. Для полноценной работы на компьютере нам потребуется более серьезный программный арсенал, так что на жестком диске система будет занимать гораздо больший объем. То, чего нам сейчас не хватает, придется докачивать из интернета - значит первое, что нам нужно сделать сейчас, - это поднять сеть.
Предполагается, что читатель знаком с простейшими приемами работы с сетью, хотя бы с терминологией.
Позже, на этапе послеустановочной конфигурации, мы снова будем поднимать сеть. Почему снова, а не все за один раз?
В рамках послеустановочной конфигурации нам надо будет настроить систему так, чтобы она автоматически поднимала сеть при включении компьютера. Для этого мы впишем нужные параметры в конфигурационные файлы и поместим все это в нужные каталоги. Позже, при каждой очередной загрузке система будет читать эти файлы и настраивать сеть согласно тому, что там записано. Сейчас у нас задача другая. Записывать конфигурационные файлы нам просто некуда, а сеть нужна прямо сейчас. Поэтому для ее настройки будем использовать консольные команды непосредственного действия, а ряд последующих операций желательно будет произвести «в один присест», чтобы потом не пришлось возвращаться к подъему сети.
Команды, которые мы сейчас будем использовать, общие для всех линуксоидных систем, да и в BSD, и в макоси все делается так же (ну, может быть, с точностью до каких-то нюансов). Так что ничего генто-специфичного нам сейчас делать не придется.

Live-диск «сконструирован» так, чтобы максимально автоматизировать подъем сети в наиболее типичной ситуации, которую разработчик может себе представить. Предполагается, что наш компьютер подключен к локальной сети Ethernet, а в сети имеется шлюз-маршрутизатор для доступа в интернет, а также DHCP-сервер, автоматически раздающий параметры настройки сети всем заинтересованным участникам.
Возможно, ваша сеть работает по-другому, например с использованием ADSL, PPP (PPPoE) или PPTP (в Билайне - L2TP). Я с такими сетями дела не имел, поэтому о них не пишу - смотрите хэндбук. Там пишут, что на установочном диске все нужные инструменты имеются.
Если же сеть у вас такая, как предполагает разработчик Live-диска, то с 99% вероятности можно предположить, что сеть уже поднята. Однако проверим:

LiveCD # ifconfig
enp1s0 Link encap:Ethernet HWaddr 00:0c:76:4e:a4:1d
inet addr:192.168.222.246 Bcast:192.168.222.255 Mask:255.255.255.240
inet6 addr: fe80::20c:76ff:fe4e:a41d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1717 errors:0 dropped:0 overruns:0 frame:0
TX packets:1835 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1266328 (1.2 MiB) TX bytes:254151 (248.1 KiB)
Interrupt:23 Base address:0xe800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
<дальше неинтересно>

Если сетевая карта работает, то в выводе команды ifconfig мы увидим раздел с именем, похожим на eth0, в данном случае enp1s0. Такое имя - нововведение из серии «хотели как лучше, а получилось как всегда». На этапе послеустановочной конфигурации мы от этого избавимся, вернемся к традиционному eth0, но сейчас заморачиваться не будем. Слово UP означает, что интерфейс поднят, т. е. разным программам разрешено принимать и отправлять данные по сети. Слово RUNNING означает, что сетевая карта ощущает присутствие работающего оборудования на другом конце провода. Inet addr:192.168.222.246 - это IP-адрес (у вас будет другой) - если вы его видите, значит ваш компьютер «дозвонился» до DHCP-сервера и получил параметры настройки, соответствующие той сети, в которой он в данный момент находится. Иначе этому адресу просто неоткуда было бы взяться.

А если ничего похожего на eth0 или enp1s0 вообще нет?
Значит компьютер «не видит» сетевую карту как таковую. Эта проблема имеет источник в нашем компьютере, а не в сети. По идее, при загрузке ОС компьютер «прощупывает» все периферийные устройства, определяет, кто есть кто из них, и операционная система автоматически устанавливает нужные модули ядра (драйверы). Однако если у вас какая-нибудь хитрая сетевая карта, то этот процесс может не дать результата. Значит, модуль драйвера сетевой карты придется установить вручную. Сам я этого не делал, поэтому просто даю перевод из хэндбука.
Используйте команду ls, чтобы выяснить, какие модули ядра обеспечены на загрузочном диске:

LiveCD # ls /lib/modules/`uname -r`/kernel/drivers/net

Если в полученном списке имеется модуль для вашей сетевой карты, используйте команду modprobe для загрузки нужного модуля ядра. Для примера установим модуль pcnet32:

LiveCD # modprobe pcnet32

Снова используйте ifconfig, чтобы проверить, обнаруживается ли теперь сетевая карта.

1). Есть ли слово UP в выхлопе команды ifconfig? Если нет, значит сетевой интерфейс нужно поднять принудительно:

LiveCD # ifconfig enp1s0 up

Эта операция чисто программная, никаких неисправностей быть не должно.
2). Есть ли слово RUNNING? Если нет: (а) где-то не контачит провод, (б) ближайшее к нам промежуточное сетевое устройство неисправно или выключено.
3). Если UP и RUNNING, но нет IP-адреса, значит DHCP-сервер нам его не выдал.

Причин для этого может быть много, но источник, вероятно, где-то за пределами нашего компьютера. DHCP-сервера может вообще не быть, или он неисправен, или выключен, или просто по каким-то причинам не хочет выдавать DHCP конкретно нам…
Попробуем использовать команду dhcpcd для явного запроса к DHCP-серверу:

LiveCD # dhcpcd enp1s0

Некоторые сисадмины требуют, чтобы мы на своем компьютере использовали имя хоста и домена, обеспечиваемое DHCP-сервером. В таком случае нужна команда:

LiveCD # dhcpcd -HD enp1s0

и снова ifconfig для проверки. Если нужных параметров по-прежнему нет, - придется их выставить самим.
Нужно выяснить IP-адрес для этого компьютера, маску сети и адрес маршрутизатора (маршрутизатор - такой же компьютер, как и все, и тоже имеет IP-адрес).
Если у вас сеть своя (в квартире и т. п.) - никто лучше вас эти параметры знать не может. Если сеть корпоративная, уточните у системного администратора. Далее командуем:

LiveCD # ifconfig enp1s0 192.168.222.249 netmask 255.255.255.240

(я для примера привожу свои параметры). Проверяем как выше.

Мы выяснили параметры локальной сети, а для выхода в интернет нам еще потребуется маршрут по умолчанию. Следующая команда выдаст действующую на данный момент таблицу маршрутов:

LiveCD # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.222.244 0.0.0.0 UG 0 0 0 eth0
192.168.222.240 0.0.0.0 255.255.255.240 U 0 0 0 eth0

Строка, где Destination = 0.0.0.0, а в колонке Flags присутствует буква G, - это как раз и есть маршрут по умолчанию (дефолтный маршрут - default route). Адрес в этой строке в колонке Gateway - адрес вашего шлюза (маршрутизатора). Он должен «перекликаться» с IP-адресом, который мы получили в прошлой команде (скорее всего они будут отличаться одной или несколькими последними цифрами). По идее, грамотно настроенный DHCP-сервер должен нам его дать вместе с нашим IP-адресом. Если же маршрута по умолчанию нет, придется задать его вручную:

LiveCD # route add default gw 192.168.222.244

Для полного душевного спокойствия снова проверяем, как выше.

Я здесь описываю самые простые и самые типичные команды для работы с сетью. Они должны помочь с 99% вероятностью. Если, несмотря на предпринимаемые вами усилия, что-то идет не так, значит дело сложное, и в рамках настоящей статьи я на этой теме не сосредоточиваюсь: устранение неисправностей в сетях - тема для отдельной…даже не статьи, а целой книги.
Какие у нас варианты?
Ниже следует глава «Подготовка жесткого диска к установке системы» - это немалая работа, большую часть которой мы можем выполнить, даже не имея возможности подключиться к Сети. Правда, нам потребуется скачать из Сети два больших архивных файла, но для этого можно обратиться к друзьям, коллегам или родственникам, у кого есть быстрый безлимитный интернет: эта часть работы выполняется как один эпизод, а уж после этого мы всегда найдем способ перенести скачанные архивы на подготовленный для них компьютер.
Еще один вариант - если в вашем распоряжении имеется налаженный компьютер с любой линуксоидной системой, и хорошо бы с выходом в интернет. Тогда можно «винчестер», на который будем ставить Генту, подключить временно к этому компьютеру и всю подготовку сделать на нем. Это очень удобный вариант: работать в привычной позе, имея под руками привычные инструменты.

Что имеем: наш компьютер загружен и подключен к Сети, но мы хотим иметь ОС на жестком диске, а там пока что ничего нет.
Что требуется сделать: заполнить наш жесткий диск необходимыми файлами. В рамках этой задачи нам предстоит выполнить следующие технологические операции:
* Разметить на «винчестере» разделы;
* Создать на разделах файловые системы (пустые) - в терминологии DOS/Windows выполнить высокоуровневое форматирование;
* Примонтировать разделы к общей файловой системе и тем самым обеспечить возможность что-либо на них писать;
* Скачать из Сети архивные файлы и развернуть их на «винчестер»;
* Составить первоочередные конфигурационные файлы (это можно сделать и позже).
Если присмотреться внимательнее, то мы увидим, что в этих операциях нет ничего специфически гентушного. Нечто подобное придется делать при установке любой ОС. Но когда мы устанавливали винды (или тот же Дебиан), к нашим услугам была программа-установщик, которая что-то делала за нас, где-то предлагала меню или другие средства «дружественного интерфейса». В Генте все придется делать врукопашную. Это может показаться сложным, но зато дает «ощущение машины», да и к пониманию внутримашинных процессов приближает.

Блочное устройство (block device) - применяемый в юниксоидных системах абстрактный интерфейс для работы с жесткими дисками и дископодобными устройствами. Такие устройства внутри себя могут содержать как классический магнитный диск с головками и другими нужными механизмами, так и энергонезависимую электронную память (SSD или flash-память). Для присоединения таких устройств к компьютеру могут использоваться физические интерфейсы IDE, SATA и USB. Кстати в англоязычных хэндбуках про USB нет ни слова, зато упоминается SCSI, которого я в живой природе уже лет 20 не видел.
В Генте, так же как в Дебиане и многих других дистрибутивах, блочные устройства представлены как файлы с именами sda, sdb, sdc… в каталоге /dev. Такой подход позволяет различным программам читать данные с устройств и писать на них, не задумываясь ни о внутреннем принципе их работы, ни о физическом интерфейсе: программа может просто обращаться к дисковой памти как к набору из 512-байтных блоков.
На каждом блочном устройстве самый первый блок используется в качестве главной загрузочной записи (master boot record - MBR).
Хотя теоретически возможно использование целого блочного устройства для размещения операционной системы, на практике так никогда не делается. Блочное устройство разбивается на несколько разделов (partitions), меньших по емкости, но более удобных для управления и обслуживания.
Разделы бывают первичные, расширенные и логические.
* Первичный раздел (primary partition) предназначен для размещения файловой системы и зарегистрирован в MBR. Поскольку в MBR очень мало места, можно создать не более 4 первичных разделов. Кому-то этого достаточно, кому-то нет. На случай, если недостаточно, люди придумали расширенные разделы.
* Расширенный раздел (extended partition), подобно первичному, регистрируется в MBR, но отличается тем, что он не предназначен для размещения файловой системы непосредственно на нем: вместо этого он разбивается на разделы, которые называются логическими, т. е. расширенный раздел является контейнером для нескольких логических. В MBR может быть не более одного расширенного раздела, он записывается последним и занимает на диске все свободное место, оставшееся после разметки первичных разделов.
* Логический раздел (logical partition), подобно первичному, предназначен для размещения файловой системы, но зарегистрирован не в MBR, а в расширенном разделе.
Таким образом, имеем вариант разметки «винчестера»: три первичных раздела и один расширенный - в MBR, и четыре логических - внутри расширенного, т. е. всего 7 разделов для размещения файловых систем. Если и этого недостаточно, то в расширенном разделе можно сделать другой расширенный раздел, и т. д.
Если наше устройство - sda, то первичные разделы на нем будут: sda1, sda2, sda3, а логические нумеруются начиная с sda5.

Нужны ли разделы конкретно нам? Сколько нужно, и каких размеров? Самый простой вариант: сделать всего один раздел на всю емкость «винчестера». Но хорошо ли?
На первый вопрос отвечаю: нужно. И на последний соответственно: плохо.
Разделы на винчестере - как отсеки в подводной лодке: они дают всей системе шанс на выживание в аварийной ситуации. Если авария случается в каком-то одном разделе, система в целом может продолжать действовать. Самый простой пример аварийной ситуации, нередкий в реальной жизни, - переполнение, т. е. невозможно записать файл на диск из-за отсутствия на нем места. Чаще всего это происходит в процессе повседневной работы пользователя: вы приехали из путешествия и привезли несколько гигов фотографий… Результат предсказуем, и отсюда очевидная мораль: для пользовательского файлового хозяйства отвести отдельный отсек раздел, и желательно побольше.
Однако и в повседневной жизни, в спокойной обстановке, разбивка диска на разделы дает преимущества:
* Повышение скорости работы компьютера за счет использования оптимальных файловых систем на разных разделах (это фича для специалистов);
* Упрощение и ускорение периодических проверок дисков;
* Повышение безопасности за счет монтирования разделов с ограничительными опциями типа nodev, noexec, nosuid и даже ro.
Следующий момент: отдельный раздел желателен для свопинга («подкачки»). Если его не сделать, то для подкачки будет использоваться файл на обычном разделе, а это может стать причиной «торможения», а то и лишних ошибок. Сколько гигов нужно для подкачки? Одни пишут: столько, сколько у вас оперативной памяти. Другие пишут: но не меньше 1ГБ. Третьи пишут: если у вас оперативная память 1ГБ или больше, то якобы свопинг не нужен… Короче, не будем париться: 2ГБ под свопинг.
Итак, имеем минимум три раздела. В хэндбуке можно встретить совет отводить отдельные разделы для /var, /opt и /usr… Мотивируют это тем, что в /usr пишут очень редко, а в /var каждый день и по многу раз… Какие же все-таки нужны размеры?
На этот вопрос не существует стандартного ответа. Сколько людей, столько мнений. Излагаю свое, личное и поэтому неизбежно субъективное.
Моя статья пишется для начинающего гентушника. Если вы ее читаете, значит вы не возражаете, чтобы вас таковым считали? Но тогда на вопрос, сколько гигов вам нужно для /var и для /usr, вы ответить не готовы. А лучше вас ответить никто не сможет - задачи-то у всех разные. Вывод: все системные файлы разместить на одном разделе, а если в будущем его станет не хватать, то, вероятно, ваш компьютер позволяет подключить еще винчестер?
Итак, мы пришли к компромиссной схеме разметки жесткого диска с тремя разделами. Будем исходить из того, что общая емкость вашего винчестера уж вряд ли меньше 80 гигов (2017-й год на дворе!), и тогда под системный раздел отводим 20ГБ, под свопинг 2ГБ, и все остальное - пользовательский раздел (/home).

Внимание, fdisk - потенциально опасная игрушка! Чтобы не разрушить файловую систему на каком-то другом диске, запускаем ее с параметром - именем диска, на который будем устанавливать систему. Вероятнее всего это будет sda. Утилита fdisk - очень древняя и имеет характерный для своей эпохи пользовательский интерфейс: программа приветствует нас приглашением Command (m for help), и мы в ответ на него вводим команды: каждая команда - одной буквой. После ввода команды нас, вероятно, попросят уточнить какие-то параметры.
Три самых первых, самых главных команды: m - manual - подсказка по всем командам, p - print - печать имеющейся на диске таблицы разделов, q - quit - выход из программы.
Нам нужно удалить все лишние разделы (команда d - delete) и, убедившись, что таблица разделов пуста, создать новые, добавляя их по одному (команда n - new - добавить новый). В ответ на эту команду нас попросят ввести тип раздела (p - первичный, e - расширенный), начальный сектор создаваемого раздела (просто соглашаемся с тем, что нам предлагают по умолчанию, нажимая ENTER) и размер раздела. Размер предваряем знаком плюс, и не забудем ввести букву M или G для мегабайт или гигабайт соответственно. Проверяем результат командой p и, если все правильно, записываем результат на диск командой w - write - писать.
И вот здесь - «толстая тонкость», не освещенная должным образом в хэндбуке (я вам рассказывал про большой корабль на мели?). По старой традиции принято, чтобы раздел, с которого наша операционная система будет загружаться, был помечен в MBR как «активный» (загрузочный). Мало-мальски современные компьютеры к этому равнодушны и спокойно загружаются без этого, но вот мне как раз попался компьютер, который не хотел загружаться, пока ему явно не указали загрузочный раздел.

Что имеем: компьютер с подсоединенным жестким диском («винчестером» или SSD-памятью), на котором размечены разделы. Самое время создать на этих разделах файловые системы (пока пустые). В терминологии DOS/Windows эта работа называется «быстрое высокоуровневое форматирование».

В современном линуксоидном мире стандартом является файловая система ext4: если нет весомых аргументов против, то следует использовать именно ее. Эта система имеет в качестве предков системы ext2 и ext3. Последняя из них, вероятно, отжила свое, а ext2, хотя и более старая и примитивная, тем не менее может быть рекомендована для небольших разделов, не предназначенных для частой записи.
Заметим, что на разделе для свопинга файловая система не создается: там применяется иная организация данных.
Системы JFS, ReiserFS и XFS претендуют на роль более современных и скоростных, но пока что получили ограниченное распространение и для начинающих линуксоидов не рекомендуются.
Также упомяну файловую систему NTFS: она применяется в Windows начиная с версии NT. Всего несколько лет назад линуксоидные системы могли читать NTFS, но запись в нее была сопряжена с определенными трудностями. Сегодня эти трудности практически преодолены, но использовать NTFS для установки линукса - категорически не рекомендуется.
И еще одна файловая система - FAT (точнее это целое семейство VFAT, хотя с названиями не все однозначно). Эта ФС сейчас используется на флэшках.

Итак, мы договорились, что у нас на диске sda будет три раздела: sda1 - системный (ext4), sda2 - свопинговый, sda3 - пользовательский (ext4). Командуем:

LiveCD # mkfs.ext4 /dev/sda1
LiveCD # mkfs.ext4 /dev/sda3
LiveCD # mkswap /dev/sda2
LiveCD # swapon /dev/sda2

(последняя команда говорит системе, что с этого момента весь свопинг должен производиться на этом устройстве).
Если в ответ тишина, - значит все прошло успешно.

Мы создали на нашем «винчестере» разделы с файловыми системами - пока что они пусты. Чтобы обеспечить возможность что-то писать на эти разделы, файловые системы надо смонтировать. Собственно, на данном этапе нам достаточно смонтировать только ФС системного раздела: к пользовательскому разделу мы пока не прикасаемся, а раздел свопинга не имеет ФС и монтированию не подлежит.
В качестве теорминимума по монтированию - читайте первую половину моей статьи Udev и его применение для монтирования файловой системы.
Командуем:

LiveCD # mkdir /mnt/gentoo
LiveCD # mount /dev/sda1 /mnt/gentoo

Никаких неисправностей, по идее, быть не должно.

Что имеем: наш системный раздел на «винчестере» пока пуст, но полностью готов к записи на него всех нужных файлов. Откуда их взять? - Из интернета: как я уже говорил, Гента устанавливается только так. Это абсолютно легально и абсолютно бесплатно. Будем исходить из того, что сеть у нас поднята. Однако прежде чем приступить к закачке файлов, нужно проверить, правильно ли выставлена дата в нашем компьютере: если неправильно, то это может привести к странным результатам на последующих этапах работы. Проверяем дату:

LiveCD # date
Срд Фев 1 18:01:54 MSK 2017

Если дата неправильна, то устанавливаем ее командой date MMDDhhmmYYYY, где MM - месяц цифрами, DD - число, hh - часы, mm - минуты, YYYY - год.
Теперь можем выходить в интернет, чтобы скачать из репозитория архивы со всеми нужными нам файлами.
Как я уже говорил, всю подготовку диска к установке Генты можно выполнить на любом компьютере, подоткнув к нему наш «винчестер». В этой ситуации для закачки архивов можно использовать ваш обычный WEB-браузер. Если же установка производится на том самом компьютере, на котором Гента будет эксплуатироваться, в режиме Live-диска, то выбор браузера будет ограничен: скорее всего мы сможем использовать только консольный браузер links.
Важный вопрос: откуда качать?
Обычно рекомендуют: с ближайшего к вам официального репозитория Gentoo. Поскольку я свою статью пишу по-русски, ближайший репозиторий будет mirror.yandex.ru. Однако у меня при скачивании с этого зеркала файл часто получался с ошибками, поэтому я теперь качаю с https://www.gentoo.org/downloads/ .
В хэндбуке говорится про один файл, который называется stage3-tarball (stage3 потому, что раньше были stage1 и stage2, но теперь технология изменилась, и нужен только stage3). На самом деле нам потребуется еще один файл - portage. Найти все это в репозитории, вообще говоря, может быть затруднительно: хозяйство там реально большое. Но поскольку мы сегодня говорим о 64-разрядных процессорах intel/AMD, то задача несколько упрощается. Тарбол ищем вот здесь:
https://mirror.yandex.ru/gentoo-distfiles/releases/amd64/autobuilds/current-stage3-amd64/
или вот здесь:
https://mirror.yandex.ru/gentoo-distfiles/releases/x86/autobuilds/current-stage3-i686/
- наш файл раньше имел имя stage3…….tar.bz2, а теперь stage3…….tar.xz.
Портеж вот здесь: http://mirror.yandex.ru/gentoo-distfiles/snapshots/ - наш файл portage-latest.tar.bz2.
При поиске тарбола нам важно не забыть, что этот файл архитектурозависимый, т. е. нам нужно выбрать тот, который соответствует нашему процессору. К сожалению, с именами архитектур имеет место путаница. С этим придется жить. Название архитектуры amd64 не должно пугать владельцев процессоров Intel, а название ia64 не должно вводить в соблазн владельцев Intel Atom - это совсем другое, а нам надо именно amd64.
Портеж-файл представляет собой базу данных, описывающую весь софт, доступный для установки с репозитория. Процессорных команд в нем нет, так что он един для всех архитектур.
Мы не забыли, что наш системный раздел смонтирован как /mnt/gentoo? Вот туда и нужно поместить оба файла.
Каждый из этих файлов представляет собой архив, т. е. содержит внутри себя множество файлов и каталогов.
Поскольку файлы большие, закачка может занять ощутимое время. После этого архивы нужно развернуть пофайлово (разархивировать) на системный раздел:

LiveCD # cd /mnt/gentoo
LiveCD # tar -xvjpf stage3…….tar.bz2 && tar -xvjpf portage…….tar.bz2

Объясняю ключи в команде tar. x - extract - извлечь файлы из архива (разархивировать, распаковать); v - verbose - «болтливый» - отображать ход процесса на консоль; j - распаковывать по алгоритму bzip2 (заглавная J для файлов .tar.xz); p - permissions - сохранять права доступа для всех файлов согласно тому как они записаны в архиве; f - file - говорит о том, что далее следует имя архивного файла, подлежащего разархивированию.
Это небыстрая операция - может растянуться на полчаса, а то и больше. Поэтому, убедившись, что процесс пошел, отправляемся на перекур/перекус/прогулку с собакой…[недостающее вписать].
Если файл portage разархивировался в корень диска, то образовавшийся каталог portage надо переместить:

LiveCD # mv /mnt/gentoo/portage /mnt/gentoo/usr/

По итогам этой операции имеем на системном разделе «винчестера» долгожданные каталоги /bin, /sbin, /etc, /var, /tmp, /usr… (ничего не забыл?) - со всеми (ну или почти всеми) надлежащими файлами внутри.

Сейчас я несколько забегу вперед по сравнению с тем, как излагается последовательность операций в хэндбуке. Там нам предлагают все эти конфигурации выполнить после установки ядра и загрузчика, и так поступить действительно можно. Предлагаемая мною последовательность работ дает некоторое преимущество в том случае, если вы выполняете всю подготовку на винчестере, временно подоткнутом к вашему повседневно используемому компьютеру. В этой ситуации редактировать файлы на привычном рабочем месте с помощью вашего любимого текстового редактора будет удобнее. Вероятно также удобно заготовить эти файлы впрок: когда будем устанавливать Генту в следующий раз, просто оптом скопируем эти файлы на винчестер.
В рамках этой главы мы не будем устанавливать и настраивать ПО (хотя некоторая теоретическая подковка по этой теме нам потребуется) - мы только заготовим конфигурационные файлы. А почему именно такие файлы и как они будут применяться - об этом разговор пойдет в последующих главах.
Собственно, только сейчас мы подбираемся к специфическим гентовским операциям, которые нам не приходилось выполнять, пока жили в других ОС.

Для начала вспомним, как ПО устанавливается в других дистрибутивах. В Дебиане и родственных ему системах программы представлены в виде пакетов определенного формата. Имена файлов пакетов имеют расширение .deb. Для распаковки одиночного пакета используется утилита dpkg. Утилита apt представляет собой надстройку над dpkg, смысл которой в поиске «зависимостей» и установке нужных пакетов сразу со всеми «зависимостями». Обе упомянутых утилиты имеют командно-строчное управление.
Утилиты aptitude и synaptic представляют собой надстройки над apt, обеспечивающие более user-friend-ный интерфейс управления: соответственно консольно-псевдографический (независимый от X-сервера) и полный графический.
В Генте все по-другому. Пакетное представление программ здесь тоже имеет место, но структура пакетов, как я уже говорил в самом начале статьи, совершенно другая. Наши пакеты называются ebuild. На нашем диске должен быть каталог /usr/portage. Как вы, вероятно, помните, мы его только что создали путем разархивирования файла, скачанного с репозитория. По сути он представляет собой базу данных обо всех пакетах, которые имеются в репозитории и доступны для установки. Но это только база данных, самих пакетов здесь нет!
Собственно установкой софта заведует утилита emerge (с командно-строчным интерфейсом). По сути она представляет собой скрипт на языке питон. Эта утилита использует целый ряд других программ, имеющихся в системе, и в частности, - make. Для нее необходим конфигурационный файл /etc/portage/make.conf (имя я пишу так, как оно будет выглядеть в нашей окончательной системе, а пока что /mnt/gentoo/etc/portage/make.conf).
Use-флаги - это особая тема. В самом начале статьи я говорил, что в Генте у нас есть выбор: что из предлагаемого разработчиками ПО нам действительно надо, а что нет. Если по-простому, то каждая программа содержит некоторую обязательную часть, ради которой она, собственно, и создавалась, и без которой установка этой программы просто не имеет смысла, и некоторые «принадлежности», которые кому-то могут быть нужны, а кому-то нет. Чтобы понять, где в программе заканчивается обязательная часть и начинаются «принадлежности», нам нет необходимости изучать, а тем более переписывать исходный текст программы: в Генте на уровне системы предусмотрен механизм Use-флагов, решающий эту задачу гораздо проще и эффективнее. Когда мы устанавливаем программу с помощью emerge, мы можем узнать, какие вообще Use-флаги относятся к этой программе, и решить, какие нам нужны и какие нет. Если потом окажется, что мы что-то решили неправильно, программу можно будет пересобрать.
Основная проблема с Use-флагами состоит в том, что здесь не может быть каких-либо рекомендаций или типовых решений: у каждого из нас свои задачи, а значит никто лучше вас самих не может знать, какие Use-флаги ставить.
Всего Use-флагов очень много (смотрите, например, вот здесь: http://wiki.enchtex.info/doc/gentoo/gentoo_use-flags ), тем не менее никакого исчерпывающего списка не существует: система развивается, а значит неизбежно появляются новые.
Как узнать, что означает некоторый Use-флаг?

LiveCD # euse -i <флаг>

(Утилита euse - из пакета gentoolkit).
Еще несколько утилит для работы с Use-флагами.
Утилита equery обладает следующими возможностями:
* Поиск файлов, принадлежащих пакету и проверка их целостности;
* Поиск пакета, которому принадлежит файл;
* Поиск пакетов, которые зависят от данного, и вывод дерева зависимостей данного пакета;
* Поиск пакетов, использующие USE-флаг;
* Вывод USE-флагов пакета и их описаний.
Источники: http://gentoo-wiki.vfose.ru/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%B0%D0%BC%D0%B8
http://www.opennet.ru/man.shtml?category=1&russian=0&topic=euse
http://www.calculate-linux.ru/main/ru/equery
Утилита eclean (из пакета gentoolkit) удаляет ненужные файлы. Источник: http://gentoo.theserverside.ru/gentoo-doc/Gentoo_doc-1.5-62.html
Use-флаги могут быть заданы глобально, т. е. для всей системы, или индивидуально - для каждого устанавливаемого пакета.
Когда мы что-то устанавливаем, emerge определяет нужные/ненужные Use-флаги, используя следующие источники (в порядке приоритета): (а) профиль установки системы; (б) файл /etc/portage/make.conf (глобально); (в) файл /etc/portage.package.use (индивидуально для каждого пакета); (г) переменные окружения, которые мы можем задать в командной строке перед запуском emerge; (д) в процессе работы, если задан ключ –ask, программа даст нам возможность еще что-то переопределить.
Глобальные Use-флаги можно вписать в файл, которым мы сейчас непосредственно займемся.
Мы ознакомились с процессом установки софта, но заниматься этим будем чуть позже, а сейчас только напишем файл, без которого установка будет невозможна.

По итогам разархивирования stage3-архива мы этот файл уже имеем, так что писать его с нуля не придется, но кое-что нужно допилить напильником.
Напоминаю, что мы имеем дело с файлом, который сейчас называется /mnt/gentoo/etc/portage/make.conf.
В качестве теорминимума по этому файлу:
http://www.opennet.ru/man.shtml?topic=makeconf
http://www.calculate-linux.org/main/ru/make_conf
Этот файл содержит множество параметров в формате имя=значение, которые можно разделить на несколько групп.
Первая группа параметров указывает компилятору и программе make особенности установки софта на данном компьютере. Параметр CFLAGS=«-O2 -pipe» можно (с ничтожным риском) так и оставить, или добавить в него -march=native - это будет означать, что программы компилируются под тот же самый процессор, на котором компиляция происходит (что по жизни чаще всего так, но не всегда). Рекомендация из хэндбука: -march=core2 - для всех процессоров в стандарте EM64T (а это все 64-разрядные АМД и интеловские Core2Duo и Quad).
Параметр CHOST укажет компилятору языка С, для какой машины собирать код https://wiki.gentoo.org/wiki/CHOST. «Изменять эту переменную - не то, что можно делать запросто» (буквальный перевод хэндбука). На самом деле эта переменная содержит 4 слова, разделенные дефисами: ProcessorArchitecture-Vendor-OperatingSystem-CLibrary, где ProcessorArchitecture - i686 или x86_64, остальные для нас: pc-linux-gnu.
CHOST=«i686-pc-linux-gnu» - для 32-разрядных процессоров;
CHOST=«x86_64-pc-linux-gnu» - для 64-разрядных. Если перепутать, при установке софта будет возникать ошибка, понять причину которой будет не так просто.
MAKEOPTS=«-j2» - цифру в этой переменной рекомендуется вставить на единицу больше количества ядер в вашем процессоре.
CPU_FLAGS_X86 - должна содержать список «флагов» нашего процессора (о господи, ну и выражения у разработчиков линуксов!). В статьях, подобных моей, мы находим рекомендации смотреть флаги с помощью программы cpuinfo2cpuflags - у меня ее нет, на самом деле проще прочитать файл /proc/cpuinfo - там есть строка flags. Или можно дать команду:

LiveCD # cat /proc/cpuinfo | grep flag

Флагов много, но по большому счету, нам важны mmx, sse и sse2 - в мало-мальски современном процессоре они наверняка имеются, так что можно с минимальным риском писать их на авось.
EMERGE_DEFAULT_OPTS=«–verbose –ask» - это ключи командной строки, с которыми emerge будет запускаться. Это необязательный параметр. Изучите руководство по emerge, чтобы понять, какие ключи нужны конкретно вам. Verbose - подробно излагать на консоль все выполняемые действия, ask - при необходимости спрашивать разрешения на то или иное действие…
Следующие параметры будут нужны для сборки софта, использующего X-сервер:
INPUT_DEVICES=«evdev»
VIDEO_CARDS=«amdgpu fbdev intel nouveau radeon radeonsi vesa»
Последняя строка - по результатам команды eselect news read, которую я выполнил 15 апреля 2017 г.
Следующая группа параметров указывает каталоги: что откуда брать при сборке софта и куда класть.
PORTDIR=«/usr/portage», DISTDIR=«${PORTDIR}/distfiles», PKGDIR=«${PORTDIR}/packages» - задаем каталоги, откуда что брать и куда что класть. Если они есть, то можно с ними соглашаться.
FEATURES=«parallel-fetch» - ускоряет работу за счет одновременной загрузки пакетов с компиляцией ранее загруженных пакетов.
GENTOO_MIRRORS=«ftp://mirror.yandex.ru/gentoo-distfiles/» - интернет-адрес репозитория - важнейший параметр, который по умолчанию не задан, а без него ни туды ни сюды. Вообще-то существует утилита mirrorselect с псевдографическим управлением. Воспользоваться ею можно так:

LiveCD # mirrorselect -i -o » /mnt/gentoo/etc/portage/make.conf

но я такие программы не очень люблю - предпочитаю прямое редактирование файлов.
LINGUAS=«ru» - эта настройка облегчит русификацию большинства программ.
В этом же файле рекомендуется задать глобальные use-флаги. Синтаксис: USE=«флаг флаг флаг …» Те use-флаги, которые нам нужны, пишем просто через пробелы, а которые не нужны - предваряем каждый знаком минус. Это общий, самый простой вариант. А вот пример более интеллигентной записи:

# Нужные флаги:
ENABLE=«7zip aac acpi alsa apache2»
# Ненужные флаги:
DISABLE=«-a52 -abiword -acl -berkdb -bindist -branding -cairo -gstreamer -bluetooth -wallpapers»
# Глобальные флаги:
USE=«${ENABLE} ${DISABLE}»

Как видим, здесь заданы две вспомогательные переменные ENABLE и DISABLE, каждая из которых задана так, как сказано выше, а общая переменная USE образуется просто путем составления из этих двух. Обратите внимание на минусы перед именами use-флагов в DISABLE.
Сохраняем файл на диск, выходим.

Файл layout.conf у нас тоже имеется, а подправить в нем нужно только одну строку: masters = gentoo.
Файл /etc/hostname должен содержать единственную строку и в ней единственное слово - имя компьютера. То самое имя, которое выводится после выполнения каждой команды в системной подсказке после имени пользователя. В хэндбуке советуют писать hostname=<имя> - на самом деле никакого hostname= не надо.
Если никакое имя не задано, будет использовано localhost, но я рекомендую вам задать свое.
Сохраняем, выходим.

Этот файл описывает используемые нашей будущей системой дискообразные устройства или разделы жестких дисков.
Шаблон этого файла у нас имеется по итогам распаковки stage3, но его тоже надо допилить.
Каждая действующая строка (действующая - т. е. не комментарий) в этом файле описывает то или иное дискообразное устройство (раздел) с точки зрения: куда и как монтировать файловую систему этого устройства при старте ОС. Каждая строка должна содержать строго 6 полей:
* имя устройства (что монтировать);
* точка монтирования (куда монтировать);
* тип файловой системы (или иной способ использования устройства, например swap для свопинга);
* опции монтирования (как монтировать);
* нужно ли использовать утилиту dump для копирования файловой системы (обычно ставится 0);
* нужно ли (и в каком порядке) проверять файловую систему с помощью утилиты fsck (чаще всего пишут 0, другие цифры определяют порядок проверки разных устройств/разделов).
Если следовать схеме разметки разделов жесткого диска, которую мы рассмотрели выше, то получаем вот такие строки для вставки в этот файл:

/dev/sda1 / ext4 noatime 0 0
/dev/sda2 none swap sw 0 0
/dev/sda3 /home ext4 noatime,nodev,noexec,nosuid 0 0

Тип файловой системы ext4 можно указывать и для более старых систем ext2 и ext3.
Опции монтирования мы, вероятно, еще будем подгонять в процессе эксплуатации нашей системы, а на первых порах достаточно опции noatime, согласно которой время изменения файла, регистрируемое в каталоге, будет обновляться только при создании/изменении файла, а не при любом обращении к нему: это несколько ускорит чтение файлов и продлит жизнь «винчестера».
Сохраняем, выходим.

В каталоге /usr/share/zoneinfo выберите нужный континент (это каталог, в моем случае Europe) и в нем файл с именем города, соответствующий вашему часовому поясу (у меня Moscow, поскольку Питера нет). Скопируйте этот файл:

LiveCD # cp /mnt/gentoo/usr/share/zoneinfo/Europe/Moscow /mnt/gentoo/etc/localtime
LiveCD # echo «Europe/Moscow» > /mnt/gentoo/etc/timezone

Хотя вместо первой команды можно сделать символическую ссылку (вместо cp написать ln -s). Источник: https://shpargalki.org.ua/160/vremya-v-linux-utc-ili-localtime
В линуксах имеется служба ntp - Network Time Protocol для подстройки системных часов по сигналам точного времени, которые циркулируют по интернету. Заведует этим ntpd - Network Time Protocol Daemon (из пакета ntp, который нам предстоит установить). Мой файл конфигурации /etc/ntp.conf для этой службы:

# Файл настройки службы точного времени
# Должен быть размещен: /etc/ntp.conf
disable monitor
# — Общедоступные ntp-серверы, от которых получаем время —-
server ntp1.kangran.su
server ntp21.imvp.ru
server ticktock.net.ru
server ntp.psn.ru
server ntp.ru
server ntp2.kangran.su
server ntp.letinet.ru
# — Запрещаем доступ для всех других ————————
restrict default ignore
# — Не разрешаем общедоступным серверам что-либо менять
# у нас и синхронизироваться с нами
restrict ntp1.kangran.su nomodify noquery notrap
restrict ntp21.imvp.ru nomodify noquery notrap
restrict ticktock.net.ru nomodify noquery notrap
restrict ntp.psn.ru nomodify noquery notrap
restrict ntp.ru nomodify noquery notrap
restrict ntp2.kangran.su nomodify noquery notrap
restrict ntp.letinet.ru nomodify noquery notrap
# — Без этого не будет работать: —————————-
restrict 127.0.0.1 nomodify notrap
# — Раздаем время в локальную сеть,
# но запрещаем участникам влиять на сервер
restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap nopeer
# — Файлы отчета: ——————————————-
logfile /var/log/ntp.log
driftfile /var/lib/ntp/drift
# ————————————————————-

а что откуда взято и почему - ссылки на первоисточники в главе «Послеустановочный тюнинг - Настройка службы точного времени».
В принципе все настройки, касающиеся времени, можно было бы сейчас оставить, а выполнить эту работу на этапе послеустановочного тюнинга.

Подробнее про эти операции - в главе «Послеустановочный тюнинг», а пока что заготовим для этой цели четыре небольших файла. В комплекте со stage3-архивом мы их уже имеем, но то, что в них содержится, для русского пользователя не представляет ценности, так что вполне можно переписать их заново.
Файл /etc/locale.gen может содержать единственную строку:

ru_RU.UTF-8 UTF-8

Следующий файл /etc/env.d/02locale (если вы где-нибудь в Сети увидите имя 02-locale - не верьте!):

LANG=«ru_RU.UTF-8»
LC_MESSAGES=«ru_RU.UTF-8»
LANGUAGE=ru_RU:ru
LC_NUMERIC=«POSIX»
LC_TIME=«POSIX»
LC_TIME=«ru_RU.UTF-8»
LC_MONETARY=«ru_RU.UTF-8»
LC_ADDRESS=«ru_RU.UTF-8»
LC_TELEPHONE=«ru_RU.UTF-8»
LC_NAME=«ru_RU.UTF-8»
LC_MEASUREMENT=«ru_RU.UTF-8»
LC_IDENTIFICATION=«ru_RU.UTF-8»
LC_PAPER=«ru_RU.UTF-8»

Поскольку я пишу статью по-русски, то и значения параметров даю сразу такие, которые нужны русскоязычному пользователю. Для нас наиболее важны три первых строки. Остальные, в принципе, могут быть с вариантами.
В файл /etc/conf.d/consolefont вписываем следующие значения:

consolefont=«cyr-sun16» вместо consolefont=«default8x16»
consoletrans=«koi8-r_to_uni» (хотя у меня этого нет - и однако работает).

И еще один файл /etc/conf.d/keymaps:

keymap=«ruwin_ct_sh-UTF-8» (или «ruwin_alt_sh-UTF-8»)

Мы проделали немалую работу - теперь можно подвести некоторые итоги. Сейчас вся файловая система на нашем компьютере похожа на некий организм, носящий внутри себя эмбрион. Этот эмбрион уже очень похож на материнский организм, но к самостоятельной жизни он еще не готов: некоторые органы не выросли. Если сейчас выключить компьютер, то плоды нашей работы уже не пропадут. Однако при последующем включении наша система на «винчестере» не сможет сама загрузиться - снова потребуется загрузка со вспомогательного носителя. Из того, что мы сегодня сделали, нам потребуется только заново поднять сеть (если опять-таки она не поднимется автоматически) и примонтировать системный раздел «винчестера» одной командой mount, как мы уже делали.

Выше я сравнил нашу будущую Генту с эмбрионом, которому для самостоятельной жизни не хватает некоторых органов. Эти органы: ядро и загрузчик. Настала пора их создать.
Сейчас мы воспользуемся Live-ядром, которое уже загружено в оперативную память (а загрузчик в данный момент не нужен - нам предстоит изготовить его для будущего использования). Первая мысль: скопировать ядро из оперативной памяти на диск - и дело с концом. На самом деле в Генте такая операция не предусмотрена. Ядро придется строить с нуля. А пока что нам надо «запрячь в одну упряжку» то ядро, которое у нас в памяти (это может быть даже совсем негентовское ядро!), и то «окружение», которое у нас на жестком диске уже в достаточно высокой степени готовности.
Командуем:

LiveCD # cp -L /etc/resolv.conf /mnt/gentoo/etc
LiveCD # mount -t proc proc /mnt/gentoo/proc
LiveCD # mount –rbind /sys /mnt/gentoo/sys
LiveCD # mount –rbind /dev /mnt/gentoo/dev
LiveCD # mount –rbind /dev/pts /mnt/gentoo/dev/pts
LiveCD # chroot /mnt/gentoo /bin/bash
LiveCD # env-update
LiveCD # source /etc/profile
LiveCD # export PS1=«(chroot) $PS1»

И объясняю смысл.
Если совсем коротко, то нужно передать «эмбриональной» системе некоторые органы управления, которые имеются у «материнской» системы. Когда у «эмбриона» вырастет собственное ядро, с этим проблем не будет, а пока приходится обеспечивать его жизнеспособность вот таким образом.
Команда cp с ключом -L копирует настоящее содержимое файла (/etc/resolv.conf - символическая ссылка). Этот файл содержит IP-адреса DNS-серверов, без которых нам не удастся выходить в интернет. Сейчас они находятся в /etc/resolv.conf («материнская» файловая система), но после выполнения chroot этот файл не будет виден, а процедура разрешения URL-адресов в IP-адреса будет пытаться искать адреса DNS-серверов в одноименном файле «эмбриональной» файловой системы… а там ничего нет… значит надо заранее скопировать. Аналогичная ситуация с proc, sys и dev. Напомню, что proc, sys и dev - это псевдофайловые системы, которые не хранятся ни на каких устройствах. Как и настоящие файловые системы, они должны быть надлежащим образом смонтированы, но поскольку они все-таки ненастоящие (или по-какой-то иной причине?), примонтировать их во вторую точку, не теряя первую, обычным путем не получится - приходится указывать ключ –rbind (в некоторых руководствах пишут -o bind - в данной ситуации это равнозначно). То есть файловые системы sys и dev теперь будут доступны как «материнской» ОС, так и «эмбриону». Команда chroot позволяет запустить некоторую программу (в нашем случае диалоговую оболочку /bin/bash) так, чтобы эта программа видела не всю файловую систему, которая имеется на компьютере, а некоторую ее ветвь - в данном случае наш винчестер со всеми файлами и каталогами, которые мы на нем создали. Однако, когда мы запускаем баш командой chroot, он не читает файлы с переменными окружения, которые находятся в каталоге /etc/env.d - значит придется это сделать принудительно командой env-update. Команда source /etc/profile здесь - самая трудная для понимания. Гуглить по слову source бесперспективно, и мануала по ней тоже нет, потому что это встроенная команда нашей диалоговой оболочки. В принципе, мы могли бы сейчас сказать, что это совершенно отдельная тема, «просто так надо», но я все же скажу пару слов. Etc/profile представляет собой скрипт на языке баш, только он не имеет шебанга и поэтому не может выполняться как самостоятельная программа. По команде source баш - тот самый баш, который сейчас с нами работает в качестве диалоговой оболочки, - выполняет этот скрипт, формирующий переменные окружения для баша, и по окончании выполнения скрипта эти переменные остаются в нашем распоряжении (чего не было бы, если бы мы запустили /etc/profile как самостоятельный скрипт). Если командой env просмотреть переменные окружения баша до и после команды source /etc/profile, разница будет видна невооруженным глазом. Ну и последняя команда меняет вид системного приглашения (переменная PS1): теперь оно каждый раз будет нам напоминать, что мы работаем в chroot-режиме. Кстати чтобы вернуться в среду с полной файловой системой, нам нужно просто завершить работу той программы, для которой делали chroot. То есть просто дать команду exit - и мы снова увидим системное приглашение без (chroot).

Совсем простая операция. Даем команду passwd - нас попросят ввести новый пароль администратора (рута, суперпользователя) - вводим. Попросят повторить - повторяем.

Мы прошли уже несколько этапов работы, но пока что не сделали ничего специфически гентушного: такие действия как форматирование дисков и заполнение их файлами имеют место в разных дистрибутивах, и даже установка Windows без этого не обходится. И вот сейчас мы подходим к операции, которая пользователям других операционных систем незнакома.
Мы уже отмечали основное отличие Генты от других ОС: возможность выбирать, что нам надо и что нет, и мы уже знаем, что основной инструмент, обеспечивающий этот выбор, - Use-флаги. Их очень много, и работа с ними «врукопашную» может оказаться весьма хлопотной. Но Гента не была бы Гентой, если бы в ней не был предусмотрен механизм более высокого уровня, упрощающий эту работу. Таким механизмом служат профили установки системы.
Философия профилей: имея ОДИН набор «сырых материалов» для сборки системы и НЕСКОЛЬКО профилей, получаем соответствующее множество типовых вариантов системы, каждый из которых ориентирован на свою сферу применения, например для сервера или для десктопного компьютера, или для рабочего места разработчика программ… Их наличие (да к тому же возможность создания новых) делает Генту метадистрибутивом, т. е. средством создания новых дистрибутивов. Идеология состоит в том, что каждый профиль представляет собой не что иное как рационально подобранный комплект Use-флагов. Технически это реализовано как дерево каталогов, корень которого находится в /var/db/repos/gentoo/profiles - это базовый профиль, а все другие основываются на нем или друг на друге. «Полазать» по этому дереву может быть весьма поучительно, но лучше оставить это на потом, чтобы сейчас не отклоняться от «дорожной карты». Профиль, выбранный для установки системы в данный момент, определяется файлом /etc/portage/make.profile. Этот файл представляет собой символическую ссылку, которая ведет на одну из ветвей дерева профилей. Мы должны были получить его в составе stage3-архива. Проверим?

(chroot) LiveCD # ls -l /etc/portage/make.profile
lrwxrwxrwx 1 root root 65 окт 12 23:53 make.profile → ../../var/db/repos/gentoo/profiles/default/linuх/amd64/17.0

Последняя цифра у вас, вероятно, будет больше.
Как видим, символическая ссылка имеется в наличии, и сейчас она указывает на базовый профиль, который нам рекомендован по умолчанию. Навести символическую ссылку на другой профиль можно, конечно, и вручную, но в этом нет необходимости: Гента опять-таки не была бы Гентой, если бы ее разработчики не придумали для нас еще одну приспособу - утилиту eselect. Увидеть, какой профиль стоит в данный момент, можно командой:

(chroot) LiveCD # eselect profile show
Current /etc/portage/make.profile symlink:
default/linux/amd64/17.0

Вывод этой команды очевидным образом «перекликается» с выводом предыдущей.
Следующая команда покажет все профили, какие доступны:

(chroot) LiveCD # eselect profile list
[1] default/linux/amd64/17.0 (stable) *
[2] default/linux/amd64/17.0/selinux (stable)
(и еще много других)

Мы, конечно, хотим только стабильную версию? (Мы же договорились, что мы начинающие гентушники, но тогда соваться в нестабильные версии нам рано). Тогда рекомендация из https://pingvinus.ru/note/gentoo-install давать команду вот так:

(chroot) LiveCD # eselect profile list | grep stable

В английском хэндбуке нам рассказывают про 3-4 профиля, в нынешней реальной жизни их гораздо больше (я у себя в 2017 году видел 22 - сколько же лет этому хэндбуку?). В будущем, вероятно, их будет еще больше. Как в них ориентироваться?
Названия некоторых профилей начинаются с default/linux/amd64/17.0, далее видим: desktop - для обычного настольного компьютера с графической оболочкой, server - для сервера, developer - для компьютера, на котором будет производиться разработка программ. Далее: desktop/gnome, desktop/kde - кто хочет, тот поймет. А для тех, кто не поймет, имеется дефолтное решение, отмеченное звездочкой.
Следующая группа профилей в списке имеет вместо слова default - hardened - это профили с повышенной безопасностью.
Определившись с выбором профиля, командуем примерно так:

(chroot) LiveCD # eselect profile set 5

(или укажите номер нужного вам профиля вместо 5). Если проследить, в какой каталог теперь ведет наша символическая ссылка, то найдем там файл make.defaults, содержащий use-флаги и другие переменные, определяющие поведение программы emerge. Ничего не переписывайте в этом файле и вообще в каталоге, т. к. при обновлении дерева портежей все ваши исправления будут «забыты». Если на самом деле есть нужда что-то переопределить, то вспомните, что я вам писал выше про make.conf, и редактируйте его.
Чтобы зафиксировать сделанные изменения, командуем:

(chroot) LiveCD # env-update && source /etc/profile

Увидеть результаты этого этапа работы можно командой euse –active –global, но для этого нам потребуется установить пакет gentoolkit (это можно сделать прямо сейчас).

Ядро - сердце операционной системы, одна из двух ее важнейших составных частей (другая часть - все что вне ядра - периферия или оболочка, хотя на самом деле она включает множество вложенных друг в друга оболочек).
Ядро - такая же программа, как и другие… такая, да не такая. Особая.
Оно представляет собой набор из множества процедур - «системных вызовов», которые обеспечивают работу внеядерных (оболочечных) программ: запуск приложений, чтение и запись файлов, прием и передачу данных через сеть и иные устройства… Всего этих процедур очень много, но на каждом конкретном компьютере нужны не все. Например, если на нашем компьютере стоит только линукс, то не нужны процедуры чтения/записи файловой системы NTFS, которая используется в «форточках». Если мы не собираемся использовать сеть IEEE1394 (FireWire), то не нужна поддержка соответствующего «железа», а для имеющейся у нас сетевой карты Ethernet нужен единственный драйвер из множества существующих в мире…
Процедуры - составные части ядра - могут встраиваться в него «монолитно» или по принципу модулей. Если у нас сравнительно несложная аппаратная конфигурация и мы не планируем подключать новых перифирийных устройств, то неплохое решение состоит в том, чтобы сделать полностью монолитное ядро вообще без поддержки модульности. Такое ядро более безопасно, т. к. злоумышленник не сможет вместо нашего модуля подставить что-то свое.
Подробнее читайте вот здесь: http://linux4u.jinr.ru/docs/add04/kernel-2.6-install-2.0.html

Следующую команду я рекомендую тем из вас, кто имеет лишь эпизодический доступ в интернет: будучи выполнена как один эпизод, эта команда обеспечит нам фронт работы на целую главу вперед.

(chroot) LiveCD # emerge gentoo-sources gentoolkit pciutils lilo ntp dhcpcd terminus-fonts

Таким образом мы установим целый ряд пакетов, но непосредственно к ядру относится только первый из них. Команда emerge сделает то, что может сделать в пределах своей компетенции. Но то, что получим в результате, - это еще не ядро, это, говоря по-английски, DIY-kit, а по-русски - набор «сделай сам», из которого нам теперь предстоит скомпилировать (собрать) ядро.
А если при такой установке исходников возникает ошибка?
Причина ошибки может скрываться очень глубоко, так что отследить ее может быть весьма затруднительно, а в хэндбуке вообще ни про какие ошибки ни слова. У меня, например, компилятор языка С не мог выполнить свою работу из-за ненадлежащего значения переменной CHOST в файле /etc/portage/make.conf - эта переменная в хэндбуке даже не упоминается, а в образцовом файле, который мы получили в комплекте со stage3-архивом, написано просто «не меняйте эту переменную без достаточной уверенности» - ну так я и не менял!
Поступим так, как написано вот здесь: http://linux4u.jinr.ru/docs/add04/kernel-2.6-install-2.0.html . То есть просто скачаем архив, точно так же, как мы это делали для stage3 и portage. Если в архиве имеется дефект, при скачивании мы этого не увидим. Попробуем разархивировать. Команда такая же, как для stage3, только без ключа -j, и нужно указать каталог, куда складывать файлы. В общем так:

(chroot) LiveCD # tar -xvpf linux-4.10.1.tar.xz -C /mnt/gentoo/usr/src

Вот тут-то все дефекты и вылезут наружу (точнее вылезет первый по ходу движения, но и этого будет достаточно, чтобы архиватор отказался продолжать работу). Наша тактика: скачиваем архивы нескольких последних версий ядра и пытаемся разархивировать их начиная с более старой и далее по порядку до последней стабильной - авось какая-то одна окажется абсолютно исправной. В итоге получим в каталоге /usr/src несколько подкаталогов: linux-4.1.38, linux-4.4.52 и т. д. Последний по номеру версии - наш, остальные удаляем.
Можно, конечно, сразу после скачивания проверить архив по md5-сумме, но едва ли это обещает большую экономию времени.
Использование ядра с kernel.org возможно, но мы же не беспредельщики - мы же правильные гентовские пацаны! Значит, жить надо все-таки по гентовским понятиям: устанавливать любой софт только посредством системы портежей, т. е. через emerge.

Заплатка, или патч (англ. patch) - файл определенной структуры, описывающий локальные изменения, которые требуется внести в некоторый другой файл (например исходный текст программы). Применение патчей позволяет обновить файл, не переписывая его полностью с нуля (в предположении что он достаточно большой). Для этой цели в линуксах есть специальная утилита patch.
Заплатки к ядру (ну мы понимаем: к исходникам ядра) делятся по назначению: для обновления и для придания ядру каких-то нестандартных возможностей (в т. ч. в экспериментальном порядке). На https://www.kernel.org/ мы видим архивы версий ядра и в соседнем столбике - патчи обновления, смысл которых следующий: если, допустим, у нас стоит ядро версии 4.9.13, а мы хотим 4.10.1, то нам не надо качать и разархивировать исходники новой версии: достаточно скачать патчи (во много раз меньшие по объему), наложить их на имеющиеся у нас исходники (если конечно мы их не стерли) - и получим новое ядро.
To patch or not to patch? - вот шекспировский вопрос, на который нет стандартного ответа. «Официальное» ядро, скачанное с kernel.org и собранное без патчей (или только с патчами обновления, скачанными оттуда же), называется ванильным (происхождение слова не объясняют, но так уж назвали). Какое ядро лучше: ванильное или пропатченное? Смотрите вот здесь: https://www.linux.org.ru/forum/desktop/2013995 - с первого же взгляда видно, что у разных людей нет единого мнения. Однако сам факт, что люди годами живут в ванильном ядре, говорит о том, что такой образ жизни имеет место быть. Мы же с вами договорились, что, читая эту статью, вы даете согласие считать себя начинающими гентушниками. Отсюда ответ: not to patch.

Что имеем: исходные тексты ядра, полностью готовые к компиляции (сборке). Чтобы осуществить собственно сборку, нужна «технологическая карта», в которой описано, что и как собирать. В роли технологической карты выступают, с одной стороны, файл Makefile, который мы получили в комплекте с исходниками, и с другой стороны - файл /usr/src/linux/.config, который нам сейчас предстоит создать.
Конфигурацию ядра многие считают одной из труднейших операций в Генте. В хэндбуке пишут: «nothing is less true» - «нет ничего, что было бы меньшей правдой». Я бы сказал так: не надо путать дар божий с яичницей, туризм - с эмиграцией, а трудную работу - с миссией для подготовленных парней.
И все же есть одна вещь, которая правда: прежде чем приступать собственно к сборке, нам надо знать наш компьютер со всем его «железом». С помощью команды lspci (из пакета pciutils, который мы только что поставили) выясним и запомним (а лучше запишем), какие периферийные устройства имеются на нашем компьютере. В ядро нужно будет встроить драйверы для их поддержки.
Можно также воспользоваться командой lsmod: она покажет список модулей, подгруженных в данный момент к ядру, которое у нас в оперативной памяти. А мы используем этот список в качестве шпаргалки: подключим эти же модули к нашему будущему ядру.
Подготовить файл конфигурации ядра можно несколькими разными способами. Например, существует утилита genkernel, которая сделает это с максимальной долей автоматизации… но полученное ядро будет включать все что можно по максимуму, а это не то что мы хотим. Если мы хотим оптимизировать и минимизировать ядро, то не избежать ручной конфигурации, которую можно (и удобнее) произвести с использованием графических или псевдографических средств.
Продолжаем:

(chroot) LiveCD # cd /usr/src/linux
(chroot) LiveCD # make menuconfig

В ответ на последнюю команду компьютер на сколько-то минут «задумывается», а затем на экран выводится псевдографическое меню в духе древних нортоновских утилит для DOS (хотя бывалые линуксоиды и сейчас предпочитают программы в таком стиле, коих в репозиториях совсем даже немало). Меню многоуровневое и довольно замысловатое.
В нижней части окна меню видим «кнопки» Select, Exit, Help, Save, Load - на них можно «нажимать» путем нажатия соответствующих клавиш на клавиатуре, только не забыть переключиться на латинский шрифт. Чтобы вызвать подсказку, нажимаем клавишу H (Help). В верхней части окна подсказки увидим имя переменной (что-нибудь типа CONFIG_SUSPEND) - это имя мы потом найдем в файле конфигурации ядра.
Как я уже говорил, отдельные части ядра могут собираться монолитно или модульно. Около каждого пункта меню мы видим в квадратных или угловых скобках знак: пробел - если данная функция не нужна, звездочка - включить монолитно, M - включить модульно (там где возможно модульное включение). Используем клавишу пробел, чтобы выбрать нужный способ включения.
Некоторые опции в меню помечены как New или Experimental. То есть разработчик ядра ввел в свое творение некоторую новую функцию, о существовании которой еще год или полгода назад люди даже не догадывались, и предлагает нам принять участие в «обкатке» этой функции в боевых условиях. Однако для нас разумная тактика состоит в том, чтобы сначала построить минималистическое работоспособное ядро и обкатать как следует его, а уж потом дополнять его чем-то, чем захотим, и в эксперименты до полной уверенности в успехе этого процесса не втравливаться.
На что следует обратить первостепенное внимание?
General Setup –> Kernel .config support и вложенный в него пункт Enable access… - полезная фича: конфигурация ядра будет храниться в нем самом и будет доступна через /proc/config.gz, что облегчит последующую пересборку ядра в случае если таковая потребуется;
General Setup –> Support for paging of anonymous memory - практически это поддержка свопинга;
General Setup –> System V IPC - полезная вещь для работы некоторых программ, пытающихся обмениваться информацией друг с другом (а где-то пишут: включить обязательно);
General Setup –> Compiler optimization level –> Optimize for performance - для нормальных компьютеров (альтернатива Optimize for size - для специализированных устройств);
General Setup –> Configure standard kernel features - это не для нас, это для очень опытных пользователей;
General Setup –> Profiling support - только для программистов-разработчиков, и то не для всех;
Enable block layer –> Partition types –> - это всевозможные виды разбивки жестких дисков, как в компьютерах Amiga, Macintosh и др. - оставляем единственный: PC BIOS (MSDOS);
Enable block layer –> Partition types –> Command line partition support - не понимаю, что это и зачем, но, включив этот пункт «на авось», я устранил kernel panic при старте ядра;
Processor type and features - все что относится к вашему процессору, который никто лучше вас не может знать.
Processor type and features –> Symmetric multi-processing support - на однопроцессорном/одноядерном компьютере не нужно, но может потребоваться для серверов с несколькими процессорами, а также для процессоров с hyperthreading;
Processor type and features –> Processor family - здесь выберите свой тип («семейство») процессоров;
Processor type and features –> Generic x86 support - нам не нужно (только для разработчиков дистрибутивов);
Processor type and features –> Preemption model –> Preemptible kernel - это улучшит работу системы (повышает «отзывчивость» при большой нагрузке, в т. ч при работе с графикой) - нужно для домашнего компьютера или рабочей станции, на которой будут рисовать-чертить;
Processor type and features –> Machine check - overheating report - контроль состояния аппаратуры и сообщение о перегреве;
Processor type and features –> Tickless system - хорошо для ноутбуков (якобы экономит аккумулятор), а для компьютера с питанием от сети не имеет большого смысла;
Processor type and features –> CPU microcode loading - загрузка прошивок центрального процессора - нам это точно не нужно, а люди пишут, что это вообще бессмысленно;
Processor type and features –> Math emulation - для нормальных компьютеров с процессорами Intel и AMD обязательно отключить, т. к. в нынешних процессорах математические операции производятся аппаратно без всякого emulation;
Processor type and features –> MTRR - улучшит (ускорит) работу с видеокартами;
Processor type and features –> kexec system call - полезная фича: вы сможете, скомпилировав ядро, сразу запустить его в работу командой kexec, без установки/переустановки системного загрузчика и с меньшими затратами времени на перезагрузку;
Processor type and features –> Local APIC support… - рекомендуется включить, но может оказаться вредным для компьютеров с ошибочно реализованным контроллером прерываний (и тогда придется отключить);
Processor type and features –> Machine check exceptions - надо, это проверка процессора на сбой и перегрев;
Power management support - управление энергопотреблением - нужно в основном для ноутбуков, но для настольного компьютера полезны опции Fan, Button, Thermal Zone (последняя - защита процессора от перегрева);
Bus Options - опции, относящиеся не к процессору, а к вашей материнской плате, которую опять-таки никто лучше вас не может знать, и к имеющимся (не имеющимся) на ней интерфейсам (шинам - Bus). Если у вас нет шин PCI Express, PCI Hotplug, ISA, PCMCIA, то смело отключайте все опции, предназначенные для них.
Bus options –> Interrupts on hypertransport devices - в онлайн-подсказке пишут: «если вы не уверены, скажите ДА»;
Bus options –> PCI access mode - поставить Any;
Bus options –> PCI device name database - включить;
Bus options –> Legacy proc/pci interface - нам не надо: это обеспечивает просмотр /proc/pci, но у нас для этого есть lspci;
Bus options –> Message Signalled Interrupts - только для некоторых новых мамок с PCI Express;
Bus options –> EDAC core system… - только для некоторых серверных мамок;
Bus options –> Support for hot-plug devices - для работы с флэшками и т. п.;
Bus options –> EISA virtual root - обязательно отключить;
Executable file formats - включаем все;
Networking support - все что касается сетевых технологий (кроме драйверов сетевых карт, которые в разделе Device Drivers);
Networking support –> Amateur Radio support - нам с вами это вряд ли нужно;
Networking support –> Networking options - здесь много настроек TCP/IP, которые нам будут нужны, и скорее всего они уже помечены звездочками, но лишний раз проверить не помешает;
Networking support –> Networking options –> Layer Two Tunneling Protocol - потребуется тем из вас, у кого интернет Билайн (у меня нет);
Device drivers –> Block Devices –> Loopback device support - пригодится при монтировании CD-дисков и не только;
Device drivers –> Serial ATA and Parallel ATA (libata) –> - владельцам винчестеров SATA (Serial ATA) не забыть включить драйвер вашего контроллера, а владельцам винчестеров IDE не забыть, что IDE есть не что иное как PATA (Parallel ATA) и соответственно тоже включить свой драйвер. В моем случае, например, VIA PATA support.
Device drivers –> ATA/ATAPI –> Enhanced IDE –> - здесь включаем на всякий случай все по максимуму для работы с жесткими дисками;
Device drivers –> Multiple devices support (RAID and LVM) - только если вы собираетесь строить сервер с программными RAID-массивами, а для обычного компьютера это вряд ли нужно. Эта опция находится в противоречии с EVMS, но в ванильном ядре EVMS нет;
Device drivers –> Macintosh Device drivers - нам не надо;
Device drivers –> Input device support –> - убрать все лишнее: джойстики, тачскрины, ненашенские типы клавиатур и мышей…
Device drivers –> Network Device support –> Ethernet driver support –> - здесь очень много драйверов для всевозможных сетевых карт, многие из них по умолчанию включены, но нам-то, скорее всего, понадобится один-единственный;
Device drivers –> Network Device support –> PPP support и Device drivers –> USB support –> USB serial converter –> USB driver for GSM and CDMA - без этого не обойдется мобильный интернет (см. мою статью PPPD и его применение для "мобилизации" интернета в Linux);
Device drivers –> Graphics support –> /dev/agpgart (AGP) - если вы используете видеокарту AGP, включите драйверы чипсета, расположенного на материнской плате и отвечающего за AGP (у меня - VIA);
Device drivers –> Graphics support –> Maximal number of GPUs - максимальное число видеокарт (графических процессоров) - более 2 мало кому нужно;
Device drivers –> Graphics support –> - включите драйвер вашего графического процессора (у меня ATI Radeon);
Device drivers –> Graphics support –> Direct Rendering Manager –> Enable legacy fbdev - поддержка старого фреймбуфера (говорят, что он не нужен, если есть иксы?);
Device drivers –> Sound card support –> Advanced Linux Sound Architecture - необходимо для воспроизведения аудио и кино;
Device drivers –> USB support –> USB modem (CDC ACM) - тоже для «мобилизации» интернета;
Device drivers –> USB support –> USB mass storage support - для флэшек и подобных им гаджетов;
Device drivers –> HID devices –> USB HID support - поддержка клавиатур и мышей USB;
Device drivers –> X86 Platform specific… - специфические опции для ноутбуков Acer, Hewpett-Paccard и т. п.
File systems - пометьте файловые системы, с которыми вы на самом деле планируете работать.
File systems –> CD/DVD filesystems - аналогично;
File systems –> DOS/FAT/NT filesystems - аналогично: DOS/FAT - для флэшек, NTFS - для двухОСных компьютеров с Windows;
File systems –> Pseudo filesystems - обязательно: это системы /sys, /proc и /dev, без которых линукс не линукс;
File systems –> Quota support - поддержка квот дискового пространства - нужно только для многопользовательских систем, а для персонального компьютера нет;
File systems –> Network file systems - кому-то из нас это понадобится, кому-то нет;
File systems –> FUSE - мне нужно для sshfs, а вам?
File systems –> Native language support –> - пометьте Codepage437, Codepage866, ASCII, NLS UTF8;
Kernel hacking - это для специалистов (это не то, что можно подумать с первого взгляда).
В принципе, можно соглашаться с той конфигурацией ядра, которую вам предложат по умолчанию. Такое ядро, с множеством фактически ненужных функций, будет «весить» порядка 7 МБайт. Тщательная «зачистка» ядра от ненужного функционала позволит сократить размер ядра раза в полтора-два, и процесс компиляции, и загрузка ядра при последующем включении компьютера ускорятся примерно так же.
По окончании конфигурации ядра нажимаем «кнопку» Save в нижней части меню. Нам предложат записать результаты в файл .config - с этим можно соглашаться. Затем нажимаем Exit.
По команде ls -al увидим скрытый файл .config длиной порядка 100кБ. Изучение его может быть весьма познавательно, но файл большой - не будем отвлекаться. Если впоследствии возникнет необходимость пересобрать ядро, вызываем снова make menuconfig - и получим свою конфигурацию, в которую можно будет вносить изменения. Если ядро собралось и запустилось нормально, то после минимальной «обкатки» ядра скопируйте файл .config под другим именем на случай, если при последующей пересборке ядра возникнут проблемы и вы захотите вернуть все как было.
Читайте еще: https://losst.ru/sobiraem-yadro-linux
http://www.opennet.ru/base/sys/kern_config.txt.html
http://www.linuxcenter.ru/lib/articles/system/kernel26_install.phtml
http://ru.friendsland.wikia.com/wiki/%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D1%8F%D0%B4%D1%80%D0%B0_%28%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80%29

Когда меню исчезнет и мы снова окажемся в консоли, командуем:

(chroot) LiveCD # make && make modules_install

Начнется собственно компиляция, которая может занять порядка часа.
Вероятная аварийная ситуация: bc command not found - лечится установкой пакета bc. Вероятно раньше мы его не установили? По идее, он установится как зависимость вместе с установкой исходников гентовского ядра, но если мы используем ванильное ядро, то bc надо устанавливать отдельно.
Если все идет по плану, то на экран будут сыпаться строки с именами обрабатываемых файлов… и в конце - долгожданное сообщение о готовности ядра:

Kernel: arch/amd64/boot/bzImage is ready

Результат компиляции ядра - файл /usr/src/linux/arch/amd64/boot/bzImage. Размер его может быть порядка 4..7 МБ, в зависимости от того насколько тщательно мы его конфигурировали (ну и собственно от конфигурации, т. е. от решаемых задач, конечно). Теперь надо его скопировать на его рабочее место и с нужным именем. Имя, вообще говоря, может быть любое, нам главное ничего не перепутать на следующем этапе работы - на этапе установки загрузчика: в конфигурационном файле загрузчика нужно будет указать строго такое же имя.

(chroot) LiveCD # cp arch/amd64/boot/bzImage /boot/kernel-gentoo
(chroot) LiveCD # cp /usr/src/linux/System.map /boot

Если вы собираете ядро не в первый раз и с прошлого раза у вас имеется рабочее ядро (допустим вы хотите что-то оптимизировать), то старое ядро рекомендуется сохранить в другой файл в том же каталоге /boot. Потом, когда будем устанавливать загрузчик, в его меню пропишем варианты загрузки со старым и новым ядром. Если новое ядро «не пойдет», перезагрузимся со старым.

Загрузчик (системный загрузчик, англ. bootloader) - второй после ядра орган, которым нужно снабдить нашу систему, чтобы придать ей полную жизнеспособность.

Рассмотрим, как происходит загрузка операционной системы в компьютер.
При включении питания компьютера или после нажатия и отпускания кнопки «Reset» вступает в работу программа, «зашитая» в материнской плате. Эта программа выводит на экран какую-то ознакомительную информацию (часто с картинками), производит тест оперативной памяти, «прощупывает» периферийные устройства… Когда все готово, эта программа читает с жесткого диска первый сектор - главную загрузочную запись - Master Boot Record - MBR. Часть MBR отведена под т. н. первичный загрузчик - совсем небольшую программу, которая по известным только ей алгоритмам находит на диске вторичный загрузчик, загружает его в оперативную память и передает ему управление. Вторичный загрузчик не так ограничен в размерах, как первичный, поэтому может решать более сложные задачи. А задача у него, собственно, одна: найти на диске ядро, загрузить его в оперативную память и передать ему управление. И решает он эту задачу опять-таки по своим алгоритмам, потому что воспользоваться процедурами чтения файловой системы он не может: эти процедуры - в ядре, и они недоступны, пока ядро не вступило в работу.
Про ядро мы говорили, что оно - сердце операционной системы (а вместо сердца у нас, как известно, пламенный мотор). Это то, без чего никакое движение в системе невозможно. Роль загрузчика в нашей системе аналогична роли стартера в автомобиле. Стартер нужен лишь в короткий момент запуска двигателя. Когда машина в движении, стартер отдыхает. Но, когда машина остановится, он снова будет нужен, поэтому приходится постоянно возить его с собой.
В линуксах наибольшую популярность имеют два конкурирующих загрузчика: GRUB и Lilo. Первый имеет весьма специфический синтаксис конфигурационного файла с нестандартными названиями дисковых устройств. Это ему прощалось, пока он единственный умел загружать другие ОС, в частности Windows, и таким образом обеспечивал создание двухОСных компьютеров. Теперь, когда Lilo тоже научился это делать, есть веские основания остановить выбор на нем.
См. также https://www.ibm.com/developerworks/ru/library/l-linuxboot/index.html
Lilo (собственно как и GRUB) поставляется в виде ebuild-пакета с таким же именем и представляет собой программный комплект «три в одном»: он содержит и первичный, и вторичный загрузчики, и инструмент (утилиту) для их установки на жесткий диск.

Мы говорим: «установка Lilo» - подразумеваем два совершенно разных действия: установку утилиты lilo и установку lilo как системного загрузчика на жесткий диск с использованием этой утилиты.
Первое из этих действий выполняется уже понятной нам командой:

(chroot) LiveCD # emerge lilo

(если мы не сделали это раньше, как я советовал). В результате получаем утилиту для установки загрузчика: /sbin/lilo.
Второе - вызовом этой утилиты:

(chroot) LiveCD # lilo
Warning: /dev/sdb is not on the first disk
Added gentoo *
One warning was issued.

Но прежде нужно составить конфигурационный файл, в котором будет описано, куда и как эта утилита должна будет устанавливать системный загрузчик. Вот мой вариант:

# Файл конфигурации загрузчика lilo
# Должен быть размещен: /etc/lilo.conf
# —– Общая конфигурация загрузчика ——————————————————
boot=/dev/sdb # установить загрузчик в главную загрузочную запись (MBR) диска
compact # позволяет ускорить загрузку
lba32 # умные люди советуют
prompt # обеспечить пользователю выбор варианта загрузки
timeout=50 # 5 секунд на выбор варианта загрузки
default=gentoo # вариант загрузки, выбираемый по умолчанию
# —– Вариант загрузки (основной): gentoo на /dev/sdb2 ———————————–
image=/boot/kernel-gentoo # полное имя файла - образа ядра
label=gentoo # будет выведено в меню загрузки
read-only # рекомендуется не менять
root=/dev/sdb2 # раздел винчестера, с которого грузимся
# —– Вариант загрузки (резервный): debian на /dev/sda1 ———————————-
image=/boot/vmlinuz-3.2.0-4-686-pae
label=debian # будет выведено в меню загрузки
read-only # рекомендуется не менять
root=/dev/sda1 # раздел винчестера, с которого грузимся
# ——————————————————————————————

а что здесь откуда и почему - смотрите в источниках:
https://www.ibm.com/developerworks/ru/library/l-lpic1-v3-102-2/index.html
http://linuxdoc.ru/lilo-conf.html
http://www.linuxcookbook.ru/howto/mini/LILO/x57.html
Кстати в комплекте со stage3-архивом мы получаем два примера /etc/lilo.conf.example с подробными комментариями на английском - можно изучать.
На что следует обратить внимание: в главе «Установка ядра на жесткий диск» я писал, что образ ядра нужно скопировать в каталог /boot с новым именем, которое в принципе может быть любым - и вот теперь в параметре image нужно указать строго то имя, которое мы присвоили нашему ядру.
То, что мы увидим на экране в ответ на команду lilo, в принципе не представляет большого интереса. Нам выдали предупреждение о том, что мы загружаемся не с первого диска - но мы это и без того знаем. Нам явно говорят, что вариант загрузки с меткой gentoo добавлен - этого можно было и не говорить, потому что обычно в наших системах принято рассматривать молчание как знак согласия… Короче, загрузчик установлен - самое время опробовать его в действии.

При загрузке новой системы может возникнуть kernel panic: на экран выдается много сообщений, понять которые трудно даже глубокому специалисту. А может быть и так, что ядро просто тихо зависает, ничего не сообщая о причинах.
Рассуждаем так: kernel panic - авария в ядре. То есть загрузчик свое дело сделал - загрузил ядро в оперативную память и передал ему управление… а ядро не может выполнить какую-то из необходимых ему операций - значит, разбираться надо с ним. Возможно, оно не может смонтировать корневую файловую систему:
а). Ядро не видит винчестер, потому что в нем не вкомпилирован драйвер контроллера IDE/SATA.
б). Ядро не видит разделы на винчестере, потому что не вкомпилирована поддержка нужного типа разбивки.
в). Ядро не видит файловую систему, потому что не вкомпилирована поддержка данного типа ФС.
Очевидно, лечится это пересборкой ядра с тщательной проверкой по нужным пунктам меню конфигурации.

После пересборки ядра, и вообще после любой манипулции с ядром, нужно переустанавливать загрузчик.

Что имеем на этом этапе: на нашем винчестере находится уже не эмбрион, а полностью жизнеспособная система, которая может загружаться, не нуждаясь более во вспомогательном диске (флэшке). Сейчас мы рассмотрим несколько технологических операций, смысл которых в том, чтобы, не меняя что-либо в этой системе радикально, научить ее некоторым «взрослым» навыкам, подогнать ее под наши потребности. В данном случае уместна распространенная у линуксоидов формулировка «работать напильником», а я использую автомобильно-яхтенное словечко «тюнинг», которое как раз и означает такую подгонку.

Как я уже говорил в главе «Подъем сети», на этапе послеустановочного тюнинга нам придется вернуться к сетевым делам, но с несколько иными целями - и, соответственно, с несколько иными методами.
В тот раз мы применяли команды прямого действия, чтобы поднять сеть «здесь и сейчас». Теперь нам нужно сконфигурировать сеть так, чтобы она поднималась автоматически при каждом последующем включении компьютера.
В отличие от Дебиана, где основные сетевые конфигурации записываются в файл /etc/network/interfaces, в Генте используется файл /etc/conf.d/network, и синтаксис этого файла тоже иной, чем в Дебиане.
Я пишу свою статью в предположении, что наш компьютер включен в локальную сеть, имеющую выход в интернет через маршрутизатор. В локальной сети, как правило, бывает принята некоторая единая политика настройки компьютеров-участников: либо это автоматическая раздача параметров по DHCP, либо самостоятельная настройка каждого узла со статическим IP-адресом. Как обстоит дело в вашей конкретной сети, никто лучше вас знать не может.
Начнем с самой простой ситуации: если наш компьютер должен получать сетевые настройки динамически (по dhcp). В этом случае файл /etc/conf.d/net должен содержать единственную строку:

config_eth0=«dhcp»

Нам потребуется dhcp-клиент - dhcpcd - его я рекомендовал установить заранее, но можно и чуть позже. Как это сделать, вы в принципе уже знаете.
Если же наш компьютер должен не получать, а раздавать dhcp, то нам потребуется установить и настроить dhcp-сервер, но это совершенно отдельная тема. Возможно я напишу об этом отдельную статью. А сейчас для нас важно, что компьютер, раздающий dhcp, сам должен иметь статическую настройку сети, так же как любой компьютер в сети без dhcp. Файл /etc/conf.d/net в случае статической настройки может иметь примерно такой вид:

config_eth0=«192.168.1.2 netmask 255.255.255.0 brd 192.168.1.255»
routes_eth0=«default via 192.168.1.1»

Это основные параметры, которые потребуются практически каждому пользователю. Кстати в комплекте с Гентой поставляется файл-пример с множеством вариантов конфигурации и подробными комментариями. Найти его можно вот здесь: /usr/share/doc/netifrc*/net.example.bz2 (в хэндбуке пишут: /usr/share/doc/openrc-*/net.example.bz2).
Однако прежде чем приводить в действие эти настройки, нужно разобраться с именами сетевых интерфейсов.

Большинство обитателей линуксоидного мира привыкли к тому, что единственная сетевая карта, имеющаяся на компьютере, называется eth0. А если она не единственная, то другие называются eth1, eth2 и т. д. На серверах-маршрутизаторах обычно eth0 смотрит в сеть провайдера, а eth1 - в локальную. Грубо говоря, мы всегда получаем интернет через eth0, а если раздаем, то раздаем через eth1 и последующие. Это стандарт де-факто, соблюдение которого облегчит нам общение с коллегами в интернете и использование чужих конфигов, и даже позволит не стыдиться за свои конфиги, которые мы выкладываем в Сеть.
Однако я на своем компьютере вместо привычных eth0 и eth1 вижу enp0s5 и enp0s18. Это нововведение выросло из того обстоятельства, что прежние названия могут меняться в зависимости от того, какие устройства и в каком порядке подключаются к компьютеру.
Допустим, у нас была единственная сетевая карта eth0, а мы вставили вторую - и вот может получиться так, что имя eth0 будет присвоено новой карте, а старая получит имя eth1 или даже eth2… Чтобы избежать такой путаницы, был предложен новый udev, в котором заложена система «постоянных» (persistent) имен, с привязкой к местам подключения сетевых карт к материнской плате: обнаружив новое устройство, udev его переименовывает согласно правилам, придуманным разработчиком этой системы. Новшество получилось не очень удачное. Если бы вся проблема была только в непривычных именах, то с этим можно было бы жить. На самом деле проблема шире. Во-первых, у разных людей на разных компьютерах имена сетевах интерфейсов могут оказаться разными до неузнаваемости. Во-вторых, как ни крути, а все равно эти имена непостоянны. Например, при замене материнской платы они почти наверняка «поплывут». В общем, нос вытащили, а хвост увяз.
Какие наши варианты? Привыкать к новой системе? Вернуть все как было? Или, может, сохранить преимущества старой системы и исправить ее недостатки?
Вот несколько ссылок - информация к размышлению:
https://unixforum.org/index.php?showtopic=87861
http://www.programmersforum.ru/showthread.php?t=295436
https://wiki.archlinux.org/index.php/Network_configuration_%28%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9%29
Недовольство множества людей новой системой привело к разработке нового варианта - eudev, который отличается «фокусом»: если создать файл правил 80-persistent-net.rules, не содержащий ни одного правила (либо совсем пустой, либо содержащий только комментарии), то имена сетевых интерфейсов будут как прежде. У меня такие решения не вызывают энтузазизма: это маневр по принципу «нормальные герои всегда идут в обход». К сожалению, более логически прозрачные варианты на сегодня не вырисовываются.

Мы имеем нужные файлы для настройки сети - теперь нам нужно, во-первых, привести их немедленно в действие и, во-вторых, позаботиться о том, чтобы при каждой последующей загрузке компьютера наша система читала эти файлы и настраивала сеть согласно тому, что мы в этих файлах прописали. Командуем:

root@bigwhite # cd /etc/init.d
root@bigwhite # net.eth0 restart
root@bigwhite # ln -s net.lo net.eth0
root@bigwhite # rc-update add net.eth0 default

Для eth1 и последующих - аналогично.

В главе «Первоочередные конфигурации» мы заготовили несколько файлов без объяснения, почему и для чего. Сейчас рассмотрим эти операции более подробно. Вообще-то это две разных операции, но выполняют их обычно сразу.
Что такое локаль?
Это совокупность параметров, отвечающих за соблюдение нашим компьютером неких писаных и неписаных стандартов, принятых в той стране, в которой мы находимся или с которой мы себя ассоциируем. Это формат записи больших чисел, дат, денежных сумм, но прежде всего, конечно, - язык, на котором компьютер будет с нами общаться.
Создадим с помощью нашего текстового редактора файл /etc/locale.gen следующего содержания:

en_US.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8

и на его основании генерируем локаль:

root@bigwhite # locale-gen

В ответ увидим несколько сообщений (я их здесь не повторяю), из которых ясно, что локаль сгенерирована.
Следующий файл, который создадим аналогичным образом, - /etc/env.d/02locale (если вы где-нибудь в Сети увидите имя 02-locale - не верьте!):

LANG=«ru_RU.UTF-8»
LC_MESSAGES=«ru_RU.UTF-8»
LANGUAGE=ru_RU:ru
LC_NUMERIC=«POSIX»
LC_TIME=«POSIX»
LC_TIME=«ru_RU.UTF-8»
LC_MONETARY=«ru_RU.UTF-8»
LC_ADDRESS=«ru_RU.UTF-8»
LC_TELEPHONE=«ru_RU.UTF-8»
LC_NAME=«ru_RU.UTF-8»
LC_MEASUREMENT=«ru_RU.UTF-8»
LC_IDENTIFICATION=«ru_RU.UTF-8»
LC_PAPER=«ru_RU.UTF-8»

В этом файле для нас наиболее важны три первых строки: переменные LANG, LANGUAGE и LC_MESSAGES - они определяют язык, на котором система будет общаться с нами. Остальные параметры, в принципе, могут быть с вариантами. Поскольку я пишу статью по-русски, то и значения параметров даю сразу такие, которые нужны русскоязычному пользователю.
Следующий файл, который нам понадобится, - /etc/rc.conf - его не надо переписывать, надо лишь проверить, имеется ли в нем строка unicode=«YES» - скорее всего имеется, но закомментирована. Надо ее «выпустить на свободу».
Мы внесли изменения в файлы, а чтобы эти изменения немедленно вступили в силу, даем команды:

root@bigwhite # env-update && source /etc/profile

Собственно, локализация закончена. Чтобы проверить, даем какую-нибудь заведомо ошибочную команду, например cd на несуществующий каталог, и ожидаем увидеть сообщение об ошибке на русском языке… но вместо русских букв мы увидим квадратики. (Попробуйте сопоставить их количество с количеством букв в ожидаемом сообщении). Результат на данном этапе закономерен и предсказуем: операционная система пытается говорить по-нашенски, но консоль еще не умеет отображать русские буквы. Значит, следующая наша задача - установить консольный шрифт.

Шрифт в нашем понимании - файл, содержащий точечные рисунки всех букв и других символов, которые должны отображаться на экране. Шрифты находятся в каталоге /usr/share/consolefonts - их там много (мы их получили со stage3-архивом), но те, что есть, - не годятся: они не русифицированы. В Генте русские шрифты, так же как и весь софт, существуют в виде пакетов, которые нужно установить с репозитория:

root@bigwhite # emerge cronyx-fonts terminus-font

По итогам этой операции имеем в каталоге /usr/share/consolefonts множество шрифтовых файлов с расширениями .psf.gz или psfu.gz. В файл /etc/conf.d/consolefont нужно вписать параметр consolefont, который должен ссылаться на один из этих шрифтов (имя файла дается без расширения!), а также параметр consoletrans, который должен ссылаться на один из файлов в каталоге /usr/share/consoletrans. Открываем с помощью редактора файл /etc/conf.d/consolefont и вписываем следующие значения:
consolefont=«cyr-sun16» вместо consolefont=«default8x16»
consoletrans=«koi8-r_to_uni» (хотя у меня этого нет - и однако работает).
Мы внесли изменения в файл, а чтобы эти изменения немедленно вступили в силу, даем команду:

root@bigwhite # /etc/init.d/consolefont restart

И проверяем результат, как мы делали только что для локали. Теперь, если все сделано правильно, сообщение об ошибке должно отображаться нормальными русскими буквами, без всяких квадратиков. И еще одна проверка: даем команду ls -l на любой существующий каталог и в ответ ожидаем увидеть русские названия месяцев в датах создания файлов, а время создания файлов - в 24-часовом формате.
Однако это еще не все. Такой режим работы консоли будет иметь место до выключения компьютера. Следующая команда:

root@bigwhite # rc-update add consolefont default

обеспечит нам загрузку консольного шрифта при последующем включении компьютера.

В общих чертах это делается так же, как и установка консольного шрифта, и даже несколько проще. Открываем с помощью редактора файл /etc/conf.d/keymaps и вставляем следующие значения:

keymap=«ruwin_ct_sh-UTF-8» (или «ruwin_alt_sh-UTF-8»)
windowkeys=«YES»
# dumpkeys_charset=«koi8-r»

(последнюю строку закоментировать, поскольку используем UTF-8)
Затем командуем:

root@bigwhite # /etc/init.d/keymaps restart

И проверяем результат: просто пробуем переключать клавиатуру на русский/английский алфавит (в такой конфигурации для переключения нажимаем Ctrl+Shift) и набирать какие-нибудь буквы.
На этом русификацию можно считать законченной.
При написании этой главы использовались следующие материалы:
http://aidalinux.ru/w/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5_%D1%80%D0%B0%D1%81%D0%BA%D0%BB%D0%B0%D0%B4%D0%BA%D0%B8_%D0%BA%D0%BB%D0%B0%D0%B2%D0%B8%D0%B0%D1%82%D1%83%D1%80%D1%8B
https://wiki.gentoo.org/wiki/Localization/Guide/ru
http://odessa-linux.blogspot.ru/2015/02/gentoo.html
http://www.oldnix.org/rus-gentoo-linux/
https://www.mvoronin.pro/ru/blog/post-40
https://www.shellhacks.com/ru/linux-define-locale-language-settings/
https://www.shellhacks.com/ru/linux-check-change-file-encoding/
https://wiki.gentoo.org/wiki/Keyboard_layout_switching#X11 (на английском)

Чтобы системное время на нашем компьютере всегда соответствовало действительности, в линуксах имеется программа ntpd - Network Time Protocol Daemon. В репозиториях она представлена пакетом ntp, который мы, возможно, уже установили. А если нет, то не поздно сделать это сейчас. Аналогично для конфигурационного файла /etc/ntp.conf (см. главу «Первоочередные конфигурации»).
Этот файл написан в предположении, что наш компьютер будет получать сигналы точного времени из интернета и раздавать их в локальную сеть. Если мы хотим только получать, но не раздавать, конфигурацию можно упростить.
Мы установили службу точного времени, а теперь хотим, чтобы она запускалась при каждом включении компьютера и работала непрерывно. Для этого в файл /etc/rc.conf (он у нас уже имеется и содержит много важных параметров!) дописываем строку: ntpd_enable=«YES»
Вот информация к размышлению на тему ntp / ntpd:
https://www.freebsd.org/doc/ru/books/handbook/network-ntp.html
http://wiki.dieg.info/ntp
https://blog.selectel.ru/nastrojka-ntp-na-servere/
http://www.k-max.name/linux/ntp-server-na-linux/
http://www.opennet.ru/base/sys/date_and_time.txt.html
http://chip0k.blogspot.ru/2014/05/ntp-linux.html
http://unboxit.ru/blog/32-pravilnaya-nastrojka-servera-vremeni-ntp-na-linux.html

В принципе, та система, которую имеем на данный момент, пригодна для работы. Однако существует инструмент, без которого линукс - не линукс: это системный регистратор (логгер).
Первым делом установим пакеты:

root@bigwhite # emerge syslog-ng app-admin/logrotate

Вообще-то собственно логгер - это одно, а программа logrotate - это совсем другое: эта программа «откладывает в ящик» законченные логи и удаляет старые. Но поскольку эти два программных средства обычно работают в паре, наладку их будем рассматривать вместе.

Извините, эта глава еще не готова.
Первоисточники:
https://losst.ru/nastrojka-logrotate
https://doc.ispsystem.ru/index.php/%D0%9A%D0%B0%D0%BA_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82_%D1%80%D0%BE%D1%82%D0%B0%D1%86%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B3%D0%BE%D0%B2
https://popsul.ru/blog/2013/01/post-42.html
https://mnorin.com/logrotate-nastrojka-rotatsii-logov.html