Как происходит процесс загрузки компьютера. Инициализация.

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

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

Самый первй шаг во всём процессе загрузки Linux на самом деле не имеет ничего общего с Linux. Именно это составляет
часть оборудования из общего процесса загрузки и она одна и та же для любых основанных на Intel операционных систем.

Когда питание впервые подаётся в определённый компьютер или конкретную ВМ, которую мы создали для данного курса,
запускается внутреннее самотестирование (POST, power-on self-test), которое является частью BIOS или более нового UEFI (Unified Extensible Firmware Interface, Унифицированного расширенного интерфейса встроенных
программных средств). BIOS является сокращеием от Basic I/O System (Базовой системы ввода/ вывода), а POST для
power-on self-test (внутреннего самотестирования при включении). Когда IBM разработала свой самый первый ПК в далёком
1981, BIOS был разработан для инициализации имеющихся аппаратных компонентов. POST является частью BIOS, чьей задачей
является обеспечение того что оборудование данного компьютера работает должным образом. Если POST завершается неудачей,
такой компьютер не может использоваться, а потому сам процесс загрузки не может быть продолжен.

Наиболее современные материнские платы применяют более новый UEFI как замену для BIOS. Многие материнские платы
также предоставляют наследуемую поддержку BIOS. Как BIOS, так и UEFI выполняют одни и те же функции — проверку и
инициализацию аппаратных средств и загрузку собственно начального загрузчика. Та ВМ, которую мы создали для данного курса,
применяет интерфейсBIOS, который отлично подходит для наших целей.

POST BIOS/UEFI проверяет базовую работоспособность имеющегося оборудования. Далее он находит имеющиеся загрузочные
секторы на всех загружаемых устройствах, включая шпиндельные или SSD дисковые устройства, DVD или CD-ROM, либо
загружаемые устройства памяти USB, как те онлайн устройства USB, которые мы применяли для установки своей виртуальной
машины StudentVM1. Самый первый обнаруженный им сектор загрузки, который содержит некую допустимую главную загрузочную
запись (MBR, master
boot record) загружается в оперативную памяти и управление далее передаётся в эту копию данного загрузочного сектора
в оперативной памяти.

Имеющийся интерфейс пользователя BIOS/UEFI может применяться для настройки имеющегося оборудования системы с целью
таких вопросов как разгон, задание ядер ЦПУ активными или не активными, определённых устройств, с которых способна
грузиться данная система, а также той последовательности, в которой эти устройства следует обнаруживать для загрузки
сектора начальной загрузки. Я больше не создаю и не выполняю загрузку с загружаемых CD или DVD устройств. И применяю
исключительно загружаемые USB устройства памяти для загрузки с внешних удаляемых устройств.
{Прим. пер.: следует отметить, что в отношении хостов серверов в настоящее время более удобно
пользоваться загрузкой через IPMI в BMC — встроенными устройствами управления серверами, представляющие собой эмуляцию виртуального
устройства начальной загрузки с подменой его неким разделяемым сетевым ресурсом, подробнее в нашем разделе
Установка ОС через
iBMC, а при загрузке крупных кластеров активно применяется загрузка через сетевые адаптеры}.

Так как я порой выполняю загрузку с некого внешнего USB устройства — или в нашем случае некой ВМ, загружаемым
образом ISO наподобии использованного онлайн USB устройства — я всегда настраиваю свои системы на загрузку изначально
с такого внешнего устройства USB, а затем с соответствующего внутреннего дискового устройства. Это не рассматривается
в качестве безопасного решения в большинстве коммерческих сред, но зато я выполняю множество загрузок с внешних устройств
USB. Когда они крадут мой компьютер целиком или если происходит разрушение по естественной чрезвычайной ситуации,
я могу вернуться обратно к резервным
копиям, которые я храню в коробке в своём депозитном сейфе.

В большинстве сред вы можете пожелать быть в безопасности и установить свой хост на загрузку исключительно с внутреннего
загрузочного устройства. Для предоствращения доступа неавторизованным пользователям к BIOS для изменений такой устанавливаемой
по умолчанию последовательности загрузки пользуйтесь паролем BIOS.

Аппаратная загрузка завершается когда наш сектор начальной загрузки принимает на себя управление данной системой.

Тот сектор начальной загрузки, который загружается BIOS на самом деле это этап 1 начального загрузчика
GRUB. Сам по себе процесс
загрузки Linux состоит из множества этапов GRUB. В данной разделе мы рассмотрим все этапы.

GRUB2 является самой новой версией начального загрузчика GRUB и он используется в наши дни намного чаще. В данном
курсе мы не будем рассматривать GRUB1 или LILO, поскольку они намного старше GRUB2.

Так как намного проще писать и произносить GRUB, нежели GRUB2, я буду применять в этой главе термин GRUB, но
при этом буду подразумевать GRUB2, пока не указано обратное. GRUB2 является сокращением от “GRand Unified Bootloader,
version 2” (Главный унифицированный начальный загрузчик) и теперь он стандартный начальный загрузчик для большинства
текущих дистрибутивов Linux. GRUB это программа, которая превращает наш компьютер в достаточно сообразительный для
того чтобы отыскать ядро необходимой операционной системы и загрузите его в память, но это требует трёх стадий от
GRUB для осуществления такого действа. В Wikipedia имеется исключительно дельная статься посвящённая GNU GRUB.

GRUB был разработан для совместимости с имеющейся спецификацией множественной загрузки, которая позволяет GRUB
загружать множество версий Linux и прочие свободно распространяемые операционные системы. GRUB способен позволять
своему пользователю выбирать загрузку из нескольких различных ядер для вашего дистрибутива, когда у вас имеется более
одного за счёт обновлений системы. Это предоставляет возможность загружать предыдущую версию ядра если по какой бы то
ни было причине некое обновление падает или не совместимо с каким- то важным фрагментом программного обеспечения.
GRUB может настраиваться при помощи файла /boot/grub/grub.conf.

GRUB1 теперь рассматривается как наследуемый и был заменён в наиболее современных дистрибутивах на GRUB2, который
переписал заново GRUB1. Дистрибутивы на основе Red- Hat обновились на GRUB1 примерно с Fedora 15 и CentOS/ RHEL 7.
{Прим. пер.: начиная с Debian 6 “Squeeze”, июль 2022/ Ubuntu 11.04 и выше, апрель
2022.} GRUB2 предоставляет ту же самую функциональность что и GRUB1, но GRUB2 также предоставляет подобную
мэйнфреймам среду предтечи ОС (pre-OS) на основе команд и делает возможной большую гибкость в процессе фазы
перед загрузкой (pre- boot).

Самая первичная функция GRUB состоит в получении загруженным в память и исполняемым ядра Linux. Само применение
команд GRUB2 в рамках среды предтечи ОС выходит за рамки данной главы. Хотя GRUB официально не прпименяет такую
терминологию для своих трёх стадий, удобно ссылаться на них именно таким образом, чему я и буду следовать.

Стадия 1 GRUB

Как об этом уже упоминалось в соответствующем разделе BIOS/UEFI POST, в самом конце POST BIOS/UEFI определяет
все подключённые диски с некой загрузочной записью, которая расположена в MBR (master boot record, главной загрузочной
записи); он загружает самую первую найденную им в память и затем запускает исполнение такой загрузочной записи.

Данный код самостоятельной загрузки, который является этапом 1 GRUB очень маленький, так как он должен умещаться
в самом первом 512- байтном секторе на имеющемся жёстком диске помимо имеющейся там таблицы разделов. Общий объём выделяемого
под код реальной самораскрутки пространства классически, для общего MBR составляет 446 байт. Такой 446- байтный
файл для этапа 1 имеет название boot.img и не содержит такой таблицы разделов.
Сама таблица разделов создаётся при разбиении данного устройства на разделы и перекрывает рассматриваемую
загрузочную запись начиная с 447 байта.

В системах UEFI обсуждаемая таблица разделов была перенесена из самого MBR в пространство, непосредственно
следующее за MBR. Это предоставляет дополнительное пространство для определения разделов, поэтому они допускают
создание большего числа разделов.

Так как сама загрузочная запись должна быть настолько маленькой, она так же не достаточно смышлёна и не понимает
структуры файловых систем, подобных EXT4. Следовательно единственная цель стадии 1 состоит в загрузке этапа 1.5 GRUB.
Для осуществления этого, GRUB стадии 1.5 обязан располагаться в имеющемся пространстве между своей записью начальной
загрузки и данными разделов UEFI и самым первым разделом в этом устройстве. После загрузки GRUB стадии 1.5 в
оперативную память, этап 1 передаёт управление стадии 1.5.

[root@studentvm1 ~]# lsblk -iNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 60G 0 disk
|-sda1 8:1 0 1G 0 part /boot
`-sda2 8:2 0 59G 0 part |-fedora_studentvm1-root 253:0 0 2G 0 lvm / |-fedora_studentvm1-swap 253:1 0 6G 0 lvm [SWAP] |-fedora_studentvm1-usr 253:2 0 15G 0 lvm /usr |-fedora_studentvm1-home 253:3 0 4G 0 lvm /home |-fedora_studentvm1-var 253:4 0 10G 0 lvm /var `-fedora_studentvm1-tmp 253:5 0 5G 0 lvm /tmp
[root@studentvm1 ~]# 

[root@studentvm1 ~]# dd if=/dev/sda bs=512 count=1 | od -a -1 0 records in
1 0 records out
0000000 k c dle dle so P < nul 0 8 nul nul so X so @
0000020 { > nul | ? nul ack 9 nul stx s $ j ! ack nul
0000040 nul > > bel 8 eot u vt etx F dle soh ~ ~ bel u
0000060 s k syn 4 stx 0 soh ; nul | 2 nul nl t soh vt
0000100 L stx M dc3 j nul | nul nul k ~ nul nul nul nul nul
0000120 nul nul nul nul nul nul nul nul nul nul nul nul soh nul nul nul
0000140 nul nul nul nul del z dle dle v B nul t enq v B p
0000160 t stx 2 nul j y | nul nul 1 @ so X so P <
0000200 nul sp { sp d | < del t stx bs B R > enq |
0000220 1 @ ht D eot @ bs D del ht D stx G eot dle nul
0000240 f vt rs | f ht bs f vt rs ` | f ht
0000260 ff G D ack nul p 4 B M dc3 r enq ; nul p
0000300 k stx k K ` rs 9 nul soh so [ 1 v ? nul nul
0000320 so F | s % us a ` 8 nul ; M sub f enq @
0000340 u gs 8 bel ; ? nul nul f 1 v f ; T C P
0000360 A f 9 nul stx nul nul f : bs nul nul nul M sub a
0000400 del & Z | > us } k etx > . } h 4 nul >
0000420 3 } h . nul M can k ~ G R U B sp nul G
0000440 e o m nul H a r d sp D i s k nul R e
0000460 a d nul sp E r r o r cr nl nul ; soh nul 4
0000500 so M dle , < nul u t C nul nul nul nul nul nul nul
0000520 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000660 nul nul nul nul nul nul nul nul ; ^ . nul nul nul eot
0000700 soh eot etx ~ B del nul bs nul nul nul nul sp nul nul ~
0000720 B del so ~ B del nul bs sp nul nul x _ bel nul nul
0000740 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000760 nul nul nul nul nul nul nul nul nul nul nul nul nul nul U *
0001000 

[root@studentvm1 ~]# od -a /boot/grub2/i386-pc/boot.img
0000000 k c dle nul nul nul nul nul nul nul nul nul nul nul nul nul
0000020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000120 nul nul nul nul nul nul nul nul nul nul nul nul soh nul nul nul
0000140 nul nul nul nul del z k enq v B nul t enq v B p
0000160 t stx 2 nul j y | nul nul 1 @ so X so P <
0000200 nul sp { sp d | < del t stx bs B R > enq |
0000220 1 @ ht D eot @ bs D del ht D stx G eot dle nul
0000240 f vt rs | f ht bs f vt rs ` | f ht
0000260 ff G D ack nul p 4 B M dc3 r enq ; nul p
0000300 k stx k K ` rs 9 nul soh so [ 1 v ? nul nul
0000320 so F | s % us a ` 8 nul ; M sub f enq @
0000340 u gs 8 bel ; ? nul nul f 1 v f ; T C P
0000360 A f 9 nul stx nul nul f : bs nul nul nul M sub a
0000400 del & Z | > us } k etx > . } h 4 nul >
0000420 3 } h . nul M can k ~ G R U B sp nul G
0000440 e o m nul H a r d sp D i s k nul R e
0000460 a d nul sp E r r o r cr nl nul ; soh nul 4
0000500 so M dle , < nul u t C nul nul nul nul nul nul nul
0000520 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000760 nul nul nul nul nul nul nul nul nul nul nul nul nul nul U *
0001000 

[root@studentvm1 ~]# strings /boot/grub2/i386-pc/boot.imgTCPAf
GRUB
Geom
Hard Disk
Read Error
> 

Стадия 1.5 GRUB

Как уже упоминалось ранее, стадия 1.5 GRUB должна определить место в пространстве между имеющимися загрузочной записью
и данными разделов UEFI вполть до самого первого раздела на рассматриваемом дисковом устройстве. Это простанство
оставалось исторически незанятым по техническим причинам и для сопровождения совместимости и порой именовалось
“boot track” (следом загрузки) или “MBR gap” (промежутком MBR). Самый первый раздел на жёстком диске начинается с
сектора 63 и вместе с самим MBR в секторе 0 это оставляет 62 секторов по 512 байт — 31 744 байт — с хранимой в них
стадией 1.5 GRUB, которая распространяется в виде файла core.img. Этот файл
core.img имеет длину 28 535 байт на момент написания данного текста, а
следовтельно там, между обсуждённой MBR и самымпервым дисковым разделом, достаточно доступного пространства, в котором
можно сохранить его.

[root@studentvm1 ~]# dd if=/dev/sda bs=512 count=1 skip=1 | od -a -1 0 records in
1 0 records out
512 bytes copied, 0.000132697 s, 3.9 MB/s
0000000 R ? t soh f 1 @ vt E bs f A ` ht f #
0000020 l soh f vt - etx } bs nul si eot d nul nul | del
0000040 nul t F f vt gs f vt M eot f 1 @ 0 del 9
0000060 E bs del etx vt E bs ) E bs f soh enq f etx U
0000100 eot nul G eot dle nul ht D stx f ht bs f ht L
0000120 ff G D ack nul p P G D eot nul nul 4 B M dc3
0000140 si stx nul ; nul p k h f vt E eot f ht @
0000160 si enq D nul f vt enq f 1 R f w 4 bs T nl
0000200 f 1 R f w t eot bs T vt ht D ff ; D bs
0000220 si cr $ nul vt eot * D nl 9 E bs del etx vt E
0000240 bs ) E bs f soh enq f etx U eot nul nl T cr @
0000260 b ack nl L nl ~ A bs Q nl l ff Z R nl t
0000300 vt P ; nul p so C 1 [ 4 stx M dc3 r q ff
0000320 C so E nl X A ` enq soh E nl ` rs A ` etx
0000340 ht A 1 del 1 v so [ | s % us > V soh h
0000360 ack nul a etx } bs nul si enq " del etx o ff i dc4
0000400 del ` 8 bel ; ; nul nul so C f 1 del ? nul stx
0000420 f ; T C P A f > l soh nul nul g f vt so
0000440 f 1 v f : ht nul nul nul M sub a > X soh h
0000460 F nul Z j nul stx nul nul > [ soh h : nul k ack
0000500 > ` soh h 2 nul > e soh h , nul k ~ l o
0000520 a d i n g nul . nul cr nl nul G e o m nul
0000540 R e a d nul sp E r r o r nul nul nul nul nul
0000560 ; soh nul 4 so M dle F nl eot < nul u r C nul
0000600 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000760 nul nul nul nul stx nul nul nul nul nul nul nul o nul sp bs
0001000
[root@studentvm1 ~]# dd if=/boot/grub2/i386-pc/core.img bs=512 count=1 | od -a -1 0 records in
1 0 records out
512 bytes copied, 5.1455e-05 s, 10.0 MB/s
0000000 R ? t soh f 1 @ vt E bs f A ` ht f #
0000020 l soh f vt - etx } bs nul si eot d nul nul | del
0000040 nul t F f vt gs f vt M eot f 1 @ 0 del 9
0000060 E bs del etx vt E bs ) E bs f soh enq f etx U
0000100 eot nul G eot dle nul ht D stx f ht bs f ht L
0000120 ff G D ack nul p P G D eot nul nul 4 B M dc3
0000140 si stx nul ; nul p k h f vt E eot f ht @
0000160 si enq D nul f vt enq f 1 R f w 4 bs T nl
0000200 f 1 R f w t eot bs T vt ht D ff ; D bs
0000220 si cr $ nul vt eot * D nl 9 E bs del etx vt E
0000240 bs ) E bs f soh enq f etx U eot nul nl T cr @
0000260 b ack nl L nl ~ A bs Q nl l ff Z R nl t
0000300 vt P ; nul p so C 1 [ 4 stx M dc3 r q ff
0000320 C so E nl X A ` enq soh E nl ` rs A ` etx
0000340 ht A 1 del 1 v so [ | s % us > V soh h
0000360 ack nul a etx } bs nul si enq " del etx o ff i dc4
0000400 del ` 8 bel ; ; nul nul so C f 1 del ? nul stx
0000420 f ; T C P A f > l soh nul nul g f vt so
0000440 f 1 v f : ht nul nul nul M sub a > X soh h
0000460 F nul Z j nul stx nul nul > [ soh h : nul k ack
0000500 > ` soh h 2 nul > e soh h , nul k ~ l o
0000520 a d i n g nul . nul cr nl nul G e o m nul
0000540 R e a d nul sp E r r o r nul nul nul nul nul
0000560 ; soh nul 4 so M dle F nl eot < nul u r C nul
0000600 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000760 nul nul nul nul stx nul nul nul nul nul nul nul 7 nul sp bs
0001000
[root@studentvm1 ~]# 

По причине большего объёма кода, который может выделяться на стадии 1.5, нежели на стадии 1, может иметься
достаточно кода чтобы содержать несколько распространённых драйверов файловых систем, например, EXT, XFS и прочих
файловых систем Linux, таких как FAT и NTFS. core.img GRUB2 намного более
сложен и вооружён чем более ранние GRUB1 стадии 1.5. Это означает, что стадия 2 GRUB2 может располагаться в некой
стандартной файловой системе EXT, но не может находиться в неком логическом томе, так как это потребует считываний
из специфических местоположений в таком загружаемом томе прежде чем будут загружены драйверы такой файловой системы.

Обратите внимание, что каталог /boot должен располагаться в некой файловой
системе, которая поддерживается GRUB, например EXT4. Это могут быть не все файловые системы. Основная функция стадии
1.5 состоит в начале работы с теми драйверами файловой системы, которые требуются для определения местоположеия файлов
стадии 2 в имеющейся файловой системе /boot и загрузке необходимых
драйверов.

Стадия 2 GRUB

Все необходимые для стадии 2 GRUB файлы расположены в каталоге /boot/grub2
и его подкаталогах. GRUB2 не имеет некого образа файла, как это присутствует на стадиях 1 и 1.5. Вместо этого он
состоит из тех файлов и модулей ядра времени исполнения, которые загружаются по мере необходимости из его каталога
/boot/grub2, а также содержащихся в нём подкаталогов. Некоторые дистрибутивы
Linux могут хранить эти файлы в своём каталоге /boot/grub.

Основной функцией GRUB на стадии 2 является определение местоположения ядра Linux и его загрузка в оперативную
память и переключение управления над данным компьютером такому ядру. Данное ядро и связанные с ним файлы расположены
в каталоге /boot. Основные файлы ядра легко идентифицируются, так как все они
именуются начиная с vmlinuz. Вы можете вывести список каталога
/boot чтобы просмотреть установленные в настоящий момент ядра в вашей
системе.

GRUB поддерживает загрузку с одного из выбранных установленных ядер Linux. Диспетчер пакетов Red Hat, DNF,
поддерживает отслеживание множества версий текущего ядра с тем, чтобы при возникновении некой проблемы с самым
новым была загружена более старая версия такого ядра. Как это отображено на
Рисунке 16-01, GRUB предоставляет меню предтечи загрузки
из установленных ядер, включая вариант спасения (аварийной загрузки, rescue option) и, если он настроен, вариант восстановления
(recovery option) для каждого из ядер.

Устанавливаемое по умолчанию ядро всегда самое последнее из тех что были установлены в процессе обновлений и оно
будет загружаться автоматически после короткого промежутка тайм аута в пять секунд. Если нажаты стрелки вверх или вниз,
отсчёт времени вниз прекращается и блок отображения перемещается на другое ядро. Для загрузки выбранного ядра
нажмите на Enter

Когда нажимается практически любая отличная от стрелок вверх или вниз клавиша, либо нажаты кнопки
e» или
«с«, обратный отсчёт останавливается
и дожидается дополнительного ввода. Теперь вы можете получить время на применение клавиш стрелок для выбора некого
ядра для загрузки, а затем нажать клавишу Enter
для его загрузки. Стадия 2 GRUB загружает выбранное ядро в оперативную память и переключает управление данным
компьютером на это ядро.

Вариант аварийной загрузки предназначен в качестве некокрайней меры при попытке разрешить серьёзные проблемы
обслуживания загрузки — которые не позволяют системе Linux завершить процесс загрузки. При возникновении неких
типов ошибок в процессе загрузки GRUB автоматически возвращается к загрузке из образа восстановления.

Записи меню GRUB для установленных ядер оказывались мне полезными. Прежде чем я познакомился в VirtualBox, я применял
некое коммерческое программное обеспечение виртуализации, которое порой испытывало проблемы при обновлениях Linux.
Хотя все компании стараются отслеживать изменения в ядрах, они в конечном итоге прекращают обновлять своё программное
обеспечение для работы со всеми версиями ядер. Всякий раз когда они не поддерживают некую версию ядра, к которой я
произвёл обновление, я применяю меню GRUB для выбора некого более раннего ядра, о котором мне известно что оно будет
работать. Я обнаружил, что поддержка только трёх более ранних ядер была не всегда недостаточной, а потому я настроил
свой диспетчер пакетов DNF на хранение до десяти ядер. Настройка диспетчера пакетов DNF обсуждается в
Главе 12, 1 тома.

GRUB настраивается в /boot/grub2/grub.cfg, однако мы не будем вносить изменения в
этот файл, так как он может быть перезаписан при обновлении нашего ядра более новой версией. Вместо этого мы внесём изменения
в /etc/default/grub.

[root@studentvm1 ~]# cd /etc/default ; cat grubGRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_studentvm1-swap rd.lvm.
lv=fedora_studentvm1/root rd.lvm.lv=fedora_studentvm1/swap rd.lvm.lv=fedora_studentvm1/usr rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
[root@studentvm1 default]# 

[root@studentvm1 default]# cat grubGRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_studentvm1-swap rd.lvm.
lv=fedora_studentvm1/root rd.lvm.lv=fedora_studentvm1/swap rd.lvm.lv=fedora_
studentvm1/usr"
GRUB_DISABLE_RECOVERY="false"
[root@studentvm1 default]#

[root@studentvm1 grub2]# grub2-mkconfig > /boot/grub2/grub.cfgGenerating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.9-200.fc28.x86_64
Found initrd image: /boot/initramfs-4.18.9-200.fc28.x86_64.img
Found linux image: /boot/vmlinuz-4.17.14-202.fc28.x86_64
Found initrd image: /boot/initramfs-4.17.14-202.fc28.x86_64.img
Found linux image: /boot/vmlinuz-4.16.3-301.fc28.x86_64
Found initrd image: /boot/initramfs-4.16.3-301.fc28.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504
Found initrd image: /boot/initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img
done
[root@studentvm1 grub2]#

Give root password for maintenance
(or press Control-D to continue): 

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

Я обнаружил, что такое аварийное ядро, тот вариант, который находится в самом низу меню GRUB на Рисунках
16-01,
16-02 и
16-03, почти никогда не работает, когда я испытываю его на
различных физическом оборудовании и виртуальных машинах и это всегда завершается неудачей. Поэтому мне требуется
восстанавливать ядра, и именно по этой причине я настраиваю GRUB под создание таких вариантов меню восстановления.

На Рисунке 16-02, после настройки GRUB и запустил команду
grub2-mkconfig -o /boot/grub2/grub.cfg,
имелось два варианта меню аварийного режима. В ходе своих проверок я обнаружил, что опция самого верхнего аварийного
меню не работает, а работчей является лишь нижний вариант меню аварийного режима, который мы только что создали. На самом
деле, похоже, это не имеет значения, потому что, как я уже сказал, аварийный режим и режим восстановления обеспечивают
абсолютно одинаковую функциональность. Данная проблема является некой ошибкой, возможно в GRUB, а потому я сообщил о ней
Red Hat при помощи Bugzilla.

Часть нашей ответственности в качестве СисАдминов и как часть отдачи сообществу открытого исходного кода состоит
в сообщении об ошибках когда вы на них натыкаетесь. Любой может создать учётную запись и зарегистрироваться для
сообщений об ошибках. Обновления будут вам отправляться по электроннй почте всякий раз, когда в отчёт о данной
ошибке вносятся изменения.

Все ядра Linux пребывают в неком самораспаковывающемся, сжатом формате для сохранения пространства. Эти ядра
находятся в основном каталоге /boot, совместно с неким начальным образом
диска оперативной памяти и символьными соответствиями. После того как выбранное ядро загружается GRUB в оперативную
память и приступает к работе, оно вначале должно распаковать себя из полученной сжатой версии, загрузить systemd
и переключить ему управление.

Это завершает сам процесс загрузки. На данный момент наши ядро Linux и systemd запущены, но не способны выыполнять
никакие продуктивные задачи для своего конечного пользователя, так как пока ещё ничто не работает, нет оболочки
для предоставления какой- то командной строки, никаких фоновых процессов для управления сетевой средой или прочими
коммуникационными связями и ничего, что позволяет данному компьютеру выполнять какую- то производительную функцию.

Процесс запуска следует сразу за процессом загрузки и приводит ваш компьютер Linux в поднятое и рабочее состояние
в котором он и примаеняется для плодотворной работы. Данный процесс запуска начинается когда ваше ядро передаёт
управление всем хостом в systemd.

systemd (и до, systemd
всегда следует писать именно так, без заглавных букв, документация systemd чётко указывает на это) это мать всех
процессов и он отвечает за перевод хоста Linux в рабочее состояние, при котором он сможет работать производительно.
Некоторые из его функций, которые намного шире тех, что имелись в старой программе init System V,, способны управлять многими сторонами работы
хота Linux, включая монтирование файловых систем и запуск систем управления службами, которые необходимы для
производительного хоста Linux. Все задачи systemd, которые не связаны с последовательностью запуска выходят за рамки
этой главы, но мы изучим их в Главе
13, тома 2.

Первые монтирования необходимых файловых систем systemd определяются в etc/fstab,
включая все файлы подкачки и разделы. На данный момент к можно осуществить доступ к общим файлам настроек, расположенным
в /etc, включая свои собственные. Для определения того каковы состояние или
цель, с которых следует загружать данный хост, он использует их ссылку конфигурации,
/etc/systemd/system/default.target. Значением файла
default.target является символическая ссылка на истинный целевой файл.
Для некой графической рабочей станции является обычным выступать в роли graphical.target,
что эквивалентно уровню исполнения в SystemV. Для сервера значением по умолчанию скорее всего будет
multi-user.target, что подобно уровню исполнения 3 в SystemV. Значение
emergency.target аналогично режиму отдельного пользователя. Цели и службы являются
элементами systemd.

Таблица 16-4 является сопоставлением целей systemd со
старыми уровнями исполнения запуска SystemV. Такие псевдонимы целей systemd предоставляются systemd для обратной
совместимости. Такие псевдонимы целей делают возможными сценарии — а многим СисАдминам навроде меня — применять команды
SystemV подобные init 3 для изменения уровней исполнения. Естественно, команды самой SystemV передаются в systemd для
интерпретации и исполнения.

Каждая из целей имеет некий набор зависимостей, описываемых в её файде конфигураций. systemd запускает все необходимые
зависимости. Эти зависимости являются теми службами, которые требуются для запуска рассматриваемого хоста на определённом
уровне функциональности. Когда все перечисленные в соответствующем файле конфигурации необходимые зависимости
загружены и запущены, данная система работает на данном целевом уровне.

systemd также просматривает имеющиеся унаследованные каталоги init SystemV для просмотра того нет ли там каких- то
файлов запуска. Если это так, systemd применяет их как файлы конфигурации для запуска всех служб, которые описаны в
этих файлах. Устаревшие сетевые службы являются хорошим примером того, что всё ещё используют файлы запуска SystemV
Fedora.

Рисунок 16-05 скопирован непосредственно из страницы man
загрузки. Она отображает соответствие данной общей последовательности событий в процессе запуска systemd и базовых
операционных требований для гарантии некого успешного запуска.

Цели sysinit.target и basic.target
могут рассматриваться как контрольные точки в данном процессе запуска. Хотя systemd имеет одной из своих целей
параллельный запуск системных служб, всё ещё имеются определённые службы и цели функциональности, которые должны
запускаться до того как могут быть запущены прочие службы и цели. Эти контрольные точки не могут проходиться пока
не будут удовлетворены все те службы и цели, которые требуются данной контрольной точкой.

sysinit.target достигается когда завершены все эти определённые в его
зависимостях элементы. Все эти элементы, монтирования файловых систем, настройки файлов подкачки, запуски udev,
настройки генераторов случайных посевных зёрен, инициации служб нижнего уровня и установки криптографических служб
когда одна или более файловых систем шифруются, должны быть выполнены, однако в рамках sysinit.target
эти задачи могут выполняться параллельно.

sysinit.target запускает все необходимые службы нижнего уровня и элементы,
еобходимые данной системы чтобы быть в основном функциональной и которые требуются для включения перехода к
basic.target.

После удовлетворения sysinit.target, systemd далее запускает
basic.target, стартуя все требующиеся для его удовлетворения элементы. Такие
базовые цели предоставляют некую дополнительную функциональность, запуская элементы, которые необходимы всем послежующим
целям. Это включает в себя настройку таких моментов как пути к различным каталогам исполнения, сокеты взаимодействия и
таймеры.

Наконец могут быть инициализированы, цели уровня пользователя, multi-user.target
или graphical.target. multi-user.target
должны быть достигнуты до того как могут быть приведены в соответствие зависимости graphical.target.
подчёркнутые на Рисунке 16-05 цели обычно выступают целями
запуска. Когда достигается одна из этих целей, тогда запуск выполнен. При установленой по умолчании цели
multi-user.target, вам следует наблюдать в качестве консоли для входа в систему
регистрацию в текстовом режиме. Когда по умолчанию установлен graphical.target,
тогда вы должны обнаружить графическое окно регистрации; какой именно экран GUI для входа в систему вы увидите,
будет зависеть от установленного по умолчанию диспетчера отображения.

Страница man загрузки токже описывает и предоставляет соответствия данной загрузки в диске RAM и имеющийся процесс
останова systemd.

[root@studentvm1 ~]# cd /etc/systemd/system/ ; lldrwxr-xr-x. 2 root root 4096 Apr 25 2022 basic.target.wants
<snip>
lrwxrwxrwx. 1 root root 36 Aug 13 16:23 default.target -> /lib/systemd/system/graphical.target
lrwxrwxrwx. 1 root root 39 Apr 25 2022 display-manager.service -> /usr/lib/systemd/system/lightdm.service
drwxr-xr-x. 2 root root 4096 Apr 25 2022 getty.target.wants
drwxr-xr-x. 2 root root 4096 Aug 18 10:16 graphical.target.wants
drwxr-xr-x. 2 root root 4096 Apr 25 2022 local-fs.target.wants
drwxr-xr-x. 2 root root 4096 Oct 30 16:54 multi-user.target.wants
<snip>
[root@studentvm1 system]#

[root@studentvm1 system]# ll /lib/systemd/system/ | less

[root@studentvm1 system]# cat default.target# SPDX-License-Identifier: LGPL-2.1
# #
This file is part of systemd.
# #
systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
[root@studentvm1 system]#

[root@studentvm1 system]# rm -f default.target[root@studentvm1 system]# ln -s /lib/systemd/system/multi-user.target default.target

[root@studentvm1 system]# ll default.targetlrwxrwxrwx 1 root root 37 Nov 28 16:08 default.target -> /lib/systemd/system/multi-user.target
[root@studentvm1 system]#

[root@studentvm1 system]# cat default.target# SPDX-License-Identifier: LGPL-2.1
# #
This file is part of systemd.
# #
systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
[root@studentvm1 system]#

[root@studentvm1 ~]# systemctl get-defaultmulti-user.target
[root@studentvm1 ~]# systemctl set-default graphical.targetRemoved /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/
system/graphical.target.
[root@studentvm1 ~]#

[root@studentvm1 system]# systemctl isolate default.target

Инициализация системы GRUB и соответствующим systemd являются ключевыми компонентами в необходимых фазах загрузки
и запуска большинства современных дистрибутивов Linux. Эти два компонента плавно работают сообща для того чтобы
вначале загрузить само ядро, а затем запустить все требуемые службы системы, необходимые для продуктивной
функциональности системы GNU/ Linux.

Хотя я и нахожу и GRUB, и systemd более сложными чем их предшественники, они к тому же проще в обучении и управлении.
Их страницы man имеют значительный объём сведений относительно systemd, а freedesktop.org обладает веб сайтом,
который описывает весь всё выполнение процесса запуска и полный набор страниц man systemd.

Имеются ещё два компонента, которые фигурируют в самом конце данного процесса загрузки и запуска для
graphical.target, а именно, диспетчер дисплея (dm, display manager) и
диспетчер окон (wm, windows manager). Эти две программы, вне зависимости от того какую именно систему рабочего места
GUI Linux вы применяете, всегда тесно связаны вместе чтобы сделать гладкой и бесшовной вашу практику входа в систему
через GUI прежде чем вы получите свой рабочий стол.

Диспетчер дисплея

Диспетчер дисплея это
программа с единственной функцией предоставления собственно GUI экрана входа в систему для вашего рабочего стола Linux. После того
как вы войдёте в некий GUI рабочего стола, этот диспетчер дисплея передаст управление диспетчеру окон. При вашей регистрации в
данном рабочем столе такой диспетчер дисплея устанавливает контроль над отображением самого экрана входа в систему и ожидания другого
входа.

Существуют различные диспетчеры дисплея; некоторые предоставляются своими соответствующими рабочими столами. Например, диспетчер
дисплея kdm предоставляется с рабочим столом KDE. Многие диспетчеры дисплея напрямую не ассоциированы
с определённым рабочим столом. Все такие диспетчеры дисплея могут применяться для вашего экрана регистрации вне зависимости от того
какой рабочий стол вы применяете. К тому же не все рабочие столы используют свои собственные диспетчеры дисплея. Такова гибкость Linux
и хорошо написанного, модульного кода.

Типичные рабочие столы и диспетчеры дисплея показаны в Таблице 16-6.
Тот диспетчер дисплея, который устанавливается для первого рабочего стола, то есть GNOME, KDE и т.п., становится применяемым по
умолчанию. Для Fedora обычно это gdm, который выступает диспетчером дисплея в GNOME. Когда
GNOME не установлен, тогда диспетчером дисплея по умолчанию выступает то, которым является диспетчер для установленного по умолчанию
рабочего стола. Когда выбранный рабочий стол в процессе установки не обладает назначенным по умолчанию диспетчером дисплея, тогда
устанавливается и используется gdm. Если вы применяете в качестве своего рабочего стола KDE,
устанавливаемым по умолчанию диспетчером дисплея будет SDDM.

Вне зависимости от того какой диспетчер дисплея настроен в качестве подразумеваемого по умолчанию на момент установки,
последующая установка дополнительных рабочих столов автоматически не изменяет этот используемый диспетчер дисплея. Если вы желаете
изменить установленный диспетчер дисплея, вам следует сделать это из своей командной строки. Вне зависимости от того какие
диспетчер окон и рабочий стол используются, может применяться любой диспетчер дисплея.

Диспетчер окон

Основной функцией диспетчера окон
состоит в управлении созданием, перемещением и уничтожением окон в неком GUI рабочего стола, включая сам экран GUI входа в систему.
Такой диспетчер окон работает с системой Xwindow
или более новой Wayland
для осуществления подобных задач. Система Xwindow предоставляет все необходимые графические примитивы и функции для выработки
требуемой графическому интерфейсу Linux или Unix графики.

Как это осносится и ко всем прочим компонентам Linux, существует множество различных диспетчеров окон из которых можно осуществлять
выбо. Список в Таблице 16-7 представляет лишь некие примеры доступных
диспетчеров окон. Некоторые из этих диспетчеров окон являются обособленными, то есть они не связаны с неким рабочим столом и могут
применяться для предоставления какого- то простого графического интерфейса без более сложного, обогащённого функциональнвми возможностями
и более ресурсоёмкие издержки полной среды рабочего стола. Обособленные диспетчеры окон не следует применять ни в каких определённых
средах рабочего стола.

Большинство диспетчеров окон напрямую не связаны ни с какими особыми рабочими столами. Фактически некоторые диспетчеры окон могут
применяться без программного обеспечения рабочего стола любого вида, такого как KDE или GNOME для предоставления самой минимальной
практики GUI пользователям. Многие среды рабочих столов поддерживают эти применение более одного диспетчера окон.

Как мне управиться со всем эти богатством?

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

Теперь, когда systemd стал во многих дистрибутивах стандартной системой запуска, вы можете устанавливать предпочтительные диспетчеры
дисплея в /etc/systemd/system, в котором расположены все основные конфигурации запуска
системы. Имеется символическая ссылка (symlink) с названием display-manager.service, которая
указывает на один из имеющихся в /usr/lib/systemd/system элементов служб диспетчеров дисплея.
Для изменения установленного активным диспетчера дисплея удалите имеющуюся ссылку
display-manager.service и замените её той, которую пожелаете.

[root@studentvm1 ~]# dnf list compiz fluxbox fvwm icewm xorg-x11-twm xfwm4Last metadata expiration check: 1:00:54 ago on Thu 29 Nov 2022 11:31:21 AM EST.
Installed Packages
xfwm4.x86_64 4.12.5-1.fc28 @updates
Available Packages
compiz.i686 1:0.8.14-5.fc28 fedora
compiz.x86_64 1:0.8.14-5.fc28 fedora
fluxbox.x86_64 1.3.7-4.fc28 fedora
fvwm.x86_64 2.6.8-1.fc28 updates
icewm.x86_64 1.3.8-15.fc28 fedora
xorg-x11-twm.x86_64 1:1.0.9-7.fc28 fedora
[root@studentvm1 ~]#

[root@studentvm1 ~]# dnf list gdm kdm lightdm lxdm sddm xfdm xorg-x11-xdmLast metadata expiration check: 2:15:20 ago on Thu 29 Nov 2022 11:31:21 AM EST.
Installed Packages
lightdm.x86_64 1.28.0-1.fc28 @updates
Available Packages
gdm.i686 1:3.28.4-1.fc28 updates
gdm.x86_64 1:3.28.4-1.fc28 updates
kdm.x86_64 1:4.11.22-22.fc28 fedora
lightdm.i686 1.28.0-2.fc28 updates
lightdm.x86_64 1.28.0-2.fc28 updates
lxdm.x86_64 0.5.3-10.D20221111gita548c73e.fc28 fedora
sddm.i686 0.17.0-3.fc28 updates
sddm.x86_64 0.17.0-3.fc28 updates
xorg-x11-xdm.x86_64 1:1.1.11-16.fc28 fedora
[root@studentvm1 ~]#

root@studentvm1 ~]# cd /usr/lib/systemd/system/ ; ll *dm.service-rw-r--r-- 1 root root 1059 Sep 1 11:38 lightdm.service
[root@studentvm1 system]#

[root@studentvm1 ~]# dnf install -y lxdm xorg-x11-xdm compiz fvwm fluxbox icewm

[root@studentvm1 ~]# systemctl restart display-manager.service

[root@studentvm1 ~]# systemctl isolate multi-user.target[root@studentvm1 ~]# systemctl isolate graphical.target

[student@studentvm1 ~]# killall fvwm

[root@studentvm1 ~]# cd /etc/systemd/system/ ; ll display-manager.servicetotal 60
lrwxrwxrwx. 1 root root 39 Apr 25 2022 display-manager.service -> /usr/
lib/systemd/system/lightdm.service
Locate all of the display manager services in /usr/lib/systemd/system/:
[root@studentvm1 system]# ll /usr/lib/systemd/system/*dm.service-rw-r--r-- 1 root root 1059 Sep 26 11:04 /usr/lib/systemd/system/lightdm.service
-rw-r--r-- 1 root root 384 Feb 14 2022 /usr/lib/systemd/system/lxdm.service
-rw-r--r-- 1 root root 287 Feb 10 2022 /usr/lib/systemd/system/xdm.service

[root@studentvm1 system]# rm -f display-manager.service[root@studentvm1 system]# ln -s /usr/lib/systemd/system/xdm.service display.manager.service[root@studentvm1 system]# ll display-manager.servicelrwxrwxrwx 1 root root 35 Nov 30 09:03 display.manager.service -> /usr/lib/systemd/system/xdm.service
[root@studentvm1 system]#

[root@studentvm1 ~]# dnf -y install system-switch-displaymanager[root@studentvm1 ~]# system-switch-displaymanager lightdm[root@studentvm1 ~]# systemctl restart display-manager.service

Различные дистрибутивы и рабочие столы обладают различными средствами изменения своего диспетчера окон, но, в целом, изменение установленной
среды рабочего стола также меняет сам диспетчер окон на один из установленных по умолчанию для этого рабочего стола. Для текущих
выпусков Fedora Linux такая среда рабочего стола может изменяться в соответствующем экране входа в систему диспетчера дисплея. Когда также
установлены и обособленные диспетчеры дисплея, они также способны появляться в данном перечне с установленными средами рабочих столов.

Имеется множество различных вариантов для доступных диспетчеров дисплея и окон. Когда вы устанавливаете последние современные
дистрибутивы с любым видом рабочего стола, подобнве выборы того какие из них устанавливать и активировать обычно выполняются самой
программой установки. У большинства пользователей может никогда не возникать никаких потребностей в смене таких выборов. Для части же прочих,
которые имеют иными склонностями, или для тех что ищут дополнительных приключений, имеется множество вариантов и комбинаций таких
возможностей. Выполним небольшие исследования, вы способны внести занимательные изменения.

После включения хоста Linux он загружается и проходит процесс запуска. После завершения процесса запуска нам представляется
графический экран или экран командной строки для входа в систему. Без некого приглашения на регистрацию невозможно
войти в хост Linux.

Как высвечивается такое приглашение на вход и как некое новое отображается после выхода пользователя это окончательная
стадия понимания запуска Linux.

Экран командной строки входа в систему инициируется некой программой, имеющей название getty,
что является сокращением от GET TTY. Основной исторической функцией
getty, было ожидание подключения от удалённого непрограммируемого терминала на вход через
линию последовательного взаимодействия. Программа getty порождала бы необходимое окно
регистрации и ожидала бы входа пользователя в систему. После того как такой удалйнный пользователь зарегистрировался бы,
эта getty завершилась бы и запустилась бы установленная по умолчанию оболочка для
учётной записи этого пользователя и позовлила бы данному пользователю своему пользователю взаимодействовать с данным
хостом в такой командной строке. Когда бы пользователь покидал систему, имеющаяся программа init
порождала бы новый getty для ожидания последущего подключения.

И в наши дни процесс во многом тот же с несколькими обновлениями. Теперь мы применяем
agetty, которая расширяется расширением {advanced} getty
в сочетании с установленным диспетчером служб systemd, обслуживающим имеющиеся
виртуальные консоли Linux, а также невероятно редко приходящие модемные линии. Перечисляемые ниже шаги отображают такую
последовательность событий в современном компьютере Linux:

Начиная с шага 3 именно этот циклический процесс повторяется до тех пор, пока поднят и исполняется его хост.
Новые окна входа в систему отображаются в некой виртуальной консоли сразу после того как их пользователь покидает
свой старый сеанс.

Отображаемый диспетчером дисплея экран GUI входа в систему обрабатывается во многом так же как и
systemd-getty-generator обрабатывает вход в систему в текстовом режиме:

Все шаги почти такие же, за исключением того, что сам диспетчер дисплея работает как некая графическая версия
agetty.

Мы до некоторой степени изучили процессы загрузки и запуска Linux. Эта глава исследовала перестройку имеющегося
начального загрузчика GRUB на отображение сообщений загрузки и запуска ядра, а также создания для меню GRUB записей режима
восстановления, которые работают в действительности. Поскольку существует некая ошибка при попытке загрузки в режиме
восстановления ядра, мы обсудили свою ответственность в качестве СисАдмина за отчёты об ошибках по соответствующим каналам.

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

Эта глава также рассмотрела такие инструменты как dd,
которые применяются для выделения данных из заданных мест на конкретном жёстком диске. Понимание таких инструментов и того
чем они могут быть полезны для определения и отслеживания данных и файлов предоставляет СисАдминам навыки, которые можно
применять для изучения прочих сторон Linux.