Глава 16. Загрузка и запуск Linux

Содержание

Цели

В этой главе вы изучите:

Разницу между загрузкой и запуском Linux
Что происходит в процессе последовательности загрузки оборудования
Что происходит в процессе последовательности загрузки Linux
Что происходит в процессе последовательности запуска Linux
Как управлять последовательностями загрузки и запуска Linux и изменять их
Основные функции диспетчеров дисплея и окна
Как процесс входа в систему работает в виртуальных консолях и в неком GUI
Что происходит при выходе пользователя из системы

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

Эта глава о современных дистрибутивах Linux, таких как Fedora и прочих дистрибутивах на основе Red Hat, которые пользуются для запуска, останова и управления системой systemd. systemd является современной заменой для init и сценариев init System V.

Обзор

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

Загрузка оборудования, которая выполняет инициализацию аппаратуры данной системы
Загрузка Linux, которая загружает собственно ядро Linux и systemd
Запуск Linux, при котором systemd делает данный хост готовым для производительной работы

Важно отделять саму загрузку аппаратных средств от процесса загрузки 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.

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

Загрузка Linux

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

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”, июль 2014/ Ubuntu 11.04 и выше, апрель 2011.} 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.

Эксперимент 16-1.

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


[root@studentvm1 ~]# lsblk -i
NAME                                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 ~]#

Для просмотра содержимого загрузочной записи данного устройства загрузки воспользуйтесь командой dd. В этом эксперименте я предположил что это устройство с назначением /dev/sda. Значение аргумента bs= в команде определяет размер считываемого блока, а аргумент count= определяет общее число блоков для дампа в STDIO. Значение аргумента if= (inFile) задаёт необходимый источник рассматриваемого потока данных, в данном случае, устройства USB:

Это выводит на печать имеющийся в загрузочной записи текст, который является самым первым блоком нашего диска - любого диска. В данном случае имеются сведения относительно его файловой системы и, хотя она и не читаема, поскольку хранится в двоичном формате, значение таблицы разделов. Стадия 1 GRUB или некоторого иного начального загрузчика расположена в этом секторе, но она, также, по большей части не читаема для нас, простых смертных. Мы можем видеть пару сообщений в тексте ASCII, которые хранятся в данной загрузочной записи. Будет легче прочесть это если мы сделаем это иначе. Наша команда od (octal display - восьмеричное отображение) отображает нам поток данных передаваемый ей конвейерно в восьмеричном формате в прелестной матрице, которая превращает это содержимое в слегка более понятное для чтения. Параметр -a сообщает нашей команде о необходимости преобразования в читаемый ASCII формат символов, когда это возможно. Самый последний - в самом конце данной команды сообщает od о необходимости получения ввода из потока STDIN вместо некого файла:


[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

Обратите внимание на звёздочку (*) между адресами 0000520 и 0000660. Она указывает что все данные в этом диапазоне одни и те же, что и самый последний байт перед ним, 0000520, которые все являются символом null. Это сохраняет пространство в нашем выводимом потоке. Все адреса приводятся восьмеричными, то есть по основанию 8.

Обычная загрузочная запись, не содержащая таблицы разделов размещена в каталоге /boot/grub2/i386-pc. Давайте рассмотрим содержимое этого файла. Не будет необходимо предписывать значения размера блока и счётчика при использовании dd, так как мы просматриваем некий файл, который уже имеет ограничение по длине. Мы также можем воспользоваться od напрямую и опеределить название файла вместо того чтобы применять команду dd, хотя мы можем также сделать и так.

	Замечание
	В Fedora 30 и выше файлы `boot.img` расположены в каталоге `/usr/lib/grub/i386-pc/`. Убедитесь что вы применяете это местоположение при выполнении нашей следующей части данного эксперимента.


[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

В этом выводе имеется вторая область дублируемых данных вежду адресами 0000020 и 0000120. Благодаря этой области имеется отличие от реальной загрузочной записи и в этом файле она представлена символами null, мы можем сделать вывод, что именно здесь размещается соответствующая таблица разделов в реальной загрузочной записи. Также существует занятная утилита, которая позволяет нам просто просмотреть значения строк текста ASCII, содержащихся в неком файле:


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

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

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

Стадия 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 и самымпервым дисковым разделом, достаточно доступного пространства, в котором можно сохранить его.

Эксперимент 16-2.

Файл, содержащий стадию 1.5 GRUB хранится в виде /boot/grub2/i386-pc/core.img. Вы можете убедиться в этом аналогично тому, как мы это делали на стадии 1, сравнивая значение кода в этом файле с тем, что хранится в промежутке 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 ~]#

Это самый первый сектор в котором вмы проведём проверку, но вы вольны изучать этот код дополнительно если пожелаете. Имеются инструенты, которые м можем применять для сопоставления значений файла с данными в GRUB на этапе 1.5 в своём жёстком диске, но очевидно что эти два сектора данных идентичны.

На данный момент нам известны те файлы, которые содержат стадии 1 и 1.5 нашего начального загрузчика GRUB и то, где они расположены на загрузочном диске чтобы выполнять свои функции по мере начальной загрузки Linux.

По причине большего объёма кода, который может выделяться на стадии 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 чтобы просмотреть установленные в настоящий момент ядра в вашей системе.

Эксперимент 16-3.

Выводимый вами перечень ядер Linux должен походить на одну из моих ВМ, однако знаяения версий ядра и возможные номера выпусков будут отличаться. Вам следует позльзоваться в своей ВМ самыми последними выпусками Fedora, а потому это должен быть выпуск 29 или даже выше на момент установки вами своей ВМ. Для подобных экспериментов это не должно представлять никакой разницы:


[root@studentvm1 ~]# ll /boot
total 187716
-rw-r--r--. 1 root root   196376  Apr 23   2018  config-4.16.3-301.fc28.x86_64
-rw-r--r--. 1 root root   196172  Aug 15  08:55  config-4.17.14-202.fc28.x86_64
-rw-r--r--  1 root root   197953  Sep 19  23:02  config-4.18.9-200.fc28.x86_64
drwx------. 4 root root     4096  Apr 30   2018  efi
-rw-r--r--. 1 root root   184380  Jun 28  10:55  elf-memtest86+-5.01
drwxr-xr-x. 2 root root     4096  Apr 25   2018  extlinux
drwx------. 6 root root     4096  Sep 23  21:52  grub2
-rw-------. 1 root root 72032025  Aug 13  16:23  initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img
-rw-------. 1 root root 24768511  Aug 13  16:24  initramfs-4.16.3-301.fc28.x86_64.img
-rw-------. 1 root root 24251484  Aug 18  10:46  initramfs-4.17.14-202.fc28.x86_64.img
-rw-------  1 root root 24313919  Sep 23  21:52  initramfs-4.18.9-200.fc28.x86_64.img
drwxr-xr-x. 3 root root     4096  Apr 25   2018  loader
drwx------. 2 root root    16384  Aug 13  16:16  lost+found
-rw-r--r--. 1 root root   182704  Jun 28  10:55  memtest86+-5.01
-rw-------. 1 root root  3888620  Apr 23   2018  System.map-4.16.3-301.fc28.x86_64
-rw-------. 1 root root  4105662  Aug 15  08:55  System.map-4.17.14-202.fc28.x86_64
-rw-------  1 root root  4102469  Sep 19  23:02  System.map-4.18.9-200.fc28.x86_64
-rwxr-xr-x. 1 root root  8286392  Aug 13  16:23  vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504
-rwxr-xr-x. 1 root root  8286392  Apr 23   2018  vmlinuz-4.16.3-301.fc28.x86_64
-rwxr-xr-x. 1 root root  8552728  Aug 15  08:56  vmlinuz-4.17.14-202.fc28.x86_64
-rwxr-xr-x  1 root root  8605976  Sep 19  23:03  vmlinuz-4.18.9-200.fc28.x86_64
[root@studentvm1 ~]#

Вы можете наблюдать, что в данном списке имеются четыре ядра и поддерживающие их файлы. Файлы System.map являются символьными таблицами, которые устанавливают соотвествие физической адресации имеющихся символов, таких как переменные и функции. Файлы initramfs использовались в более раннем процессе загрузки до того как были загружены драйверы данной файловой системы и смонтированы необходимые файловые системы.

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

Рисунок 16-1

Меню загрузки GRUB допускает выбор различных ядер

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

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

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

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

Настройка GRUB

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

Эксперимент 16-4.

Давайте начнём с версии файла /etc/default/grub без изменений:


[root@studentvm1 ~]# cd /etc/default ; cat grub
GRUB_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]#

В Главе 6 документации GRUB содержится полный список всех возможных записей в таком файле /etc/default/grub, но имеются лишь три, которые мы должны здесь рассмотреть.

Я всегда изменяю GRUB_TIMEOUT, значение числа секунд для обратного отсчёта времени отображения меню GRUB, с пяти на десять, что даёт немного больше времени на отклик в меню GRUB прежде чем обратный отсчёт достигнет нуля.

Я также изменяю GRUB_DISABLE_RECOVERY с “true” на “false”, что слегка переворачивает логику программирования. Я обнаружил, что имеющийся вариант аварийной загрузки не всегда работает. Для того чтобы обмануть эту проблему, я изменяю данный оператор чтобы разрешить последующей команде grub2-mkconfig выработать некий аварийный вариант для всех установленных ядер; я обнаружил, что когда сам аварииный вариант отказывает, срабатывает эта опция. Это также предоставляет ядра восстановления для их применения в случае определённых инструментов или программных пакетов, которым требуется исполнение определённой версии ядра для своей работы.

	Замечание
	Изменение `GRUB_DISABLE_RECOVERY` в установленнй по умолчанию конфигурации более не работает начиная с Fedora 30. Все прочие изменения, `GRUB_TIMEOUT` и удаление “rhgb quiet” из переменной `GRUB_CMDLINE_LINUX` всё ещё срабатывают.

Также можно изменить строку GRUB_CMDLINE_LINUX. Данная строка перечисляет параметры командной строки, которые передаются соответствующему ядру в момент загрузки. Обычно я удаляю из этой строки два последних параметра. Параметр rhgb это сокращение от Red Hat Graphical Boot и он вызывает небольшую графическую анимацию иконки Fedora при отображении в процессе инициализации выбранного ядра вместо отображения сообщений времени загрузки. Параметр quiet предотвращает отображение сообщений самого запуска, которые документируют прохождение самого процесса запуска и все ошибки, которые могут происходить. Удалите обе эти записи, так как СисАдминам следует видеть эти сообщения. Если в процессе загрузки что- то идёт не так, отображаемые на экране сообщения могут указать нам ту причину, которая вызвала данную проблему.

Измените эти три строки, как я описал, с тем чтобы файл grub выглядел так:


[root@studentvm1 default]# cat grub
GRUB_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]#

Проверьте текущее содержимое файла /boot/grub2/grub.cfg. Для обновления файла конфигурации /boot/grub2/grub.cfg исполните следующую команду:


[root@studentvm1 grub2]# grub2-mkconfig > /boot/grub2/grub.cfg
Generating 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]#

Проверьте повторно /boot/grub2/grub.cfg, который должен отразить те изменения, которые мы предприняли. Вы можете выполнить grep для конкретных изменённых нами строк чтобы убедиться что эти изменения произошли. Мы также можем воспользоваться альтернативным видом данной команды для создания файла вывода, grub2-mkconfig -o /boot/grub2/grub.cfg. Работают обе разновидности и результат один и тот же.

Перезагрузите виртуальную машину StudentVM1. Когда высветится меню GRUB, нажмите клавишу Esc. Самое первое отличие, которое вы можете обнаружить в появившемся меню GRUB состоит в том, что обратный отсчёт начинается с десяти секунд. Меню GRUB теперь аналогично отображённому на Рисунке 16-02

Рисунок 16-2

После изменения /etc/default/grub и выполнения grub2-mkconfig, меню загрузки GRUB теперь содержит некий режим восстановления для всех ядер

Воспользуйтесь стрелками для высвечивания варианта восстановления выбранного по умолчанию ядра - второго варианта - и нажмите клавишу Enter для завершения процесса загрузки и запуска. Это приведёт вас в режим восстановления с применением данного ядра. Вы также можете обнаружить на своём экране отображение множества сообщений по мере загрузки данной системы и прохождения через её запуск. Некоторые из этих сообщений можно рассмотреть на Рисунке 16-03 совместно с сообщениями, принадлежащими аварийной оболочке.

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


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

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

Обратите также внимание, что в самом низу экрана на Рисунке 16-03 показан небольшой след сообщений, которые мы будем встраивать в Главе 17 в файлы настройки запуска bash, отображает здесь что при входе в систему запускались файлы /etc/bashrc и /etc/profile.d/myBashConfig.sh - совместно со всеми прочими файлами настройки в /etc/profile.d. Я слегка проскочил этот момент, но я покажу вам как проверить их самостоятельно в Главе 17. Это хорошие сведения для того чтобы иметь их, так как вы бедете знать что ожидать по пути настройки оболочки при работе в режиме восстановления.

Находясь в режиме восстановления, изучите эту систему, так как она является эквивалентом того, что будет применяться в режиме единственного пользователя. Утилита lsblk покажет что все файловые системы смонтированы в их верных местоположениях, а команда ip addr покажет, что сетевая среда не была запущена. Наш компьютер поднялся и работает, однако это очень минимальный режим для работы. Доступны лишь наиболее существенные службы чтобы позволить разрешению проблем. Команда runlevel покажет, что данный хост является эквивалентом уровня исполнения 1 старой SystemV.

Рисунок 16-3

После загрузки ядра в режиме восстановления вы пользуетесь паролем root для входа в поддерживаемый режим

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

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

Существует три различных термина, которые обычно применяются к режиму восстановления: восстановление (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

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

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

Запуск Linux

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

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 для интерпретации и исполнения.

Таблица 16-4. Cопоставление целей systemd с runlevel SystemV и некоторыми псевдонимами целей
Runlevel SystemV	Цель systemd	Псевдонимы цели systemd	Описание
	`halt.target`		Останавливает данную систему без отключения питания.
`0`	`poweroff.target`	`runlevel0.target`	Останавливает данную систему и отключает питание.
`S`	`emergency.target`		Режим единственного пользователя. Никакие службы не исполняются; файловые системы не смонтированы. Это наиболее базовый уровень работы с исполнением лишь аварийной оболочки в самой основной консоли для данного посльзователя для взаимодействия с этой системой.
`1`	`rescue.target`	`runlevel1.target`	Некая базовая система, содержащая необходимые файловые системы запущенными с лишь самыми основными службами и некую аварийную оболочку в своей основной консоли.
`2`		`runlevel2.target`	Множество пользователей без NFS, но все прочие службы без GUI запущенными.
`3`	`multi-user.target`	`runlevel3.target`	Все службы запущены, но интерфейсом является лишь CLI.
`4`		`runlevel4.target`	Не применяется, но идннтичен multi-user.target. Данная цель может настраиваться персонально для запуска локальных служб без изменения установленного по умолчанию multi-user.target.
`5`	`graphical.target`	`runlevel5.target`	multi-user.target с GUI.
`6`	`reboot.target`	`runlevel6.target`	Перезагрузка
	`default.target`		Эта цель всегда обозначается псевдонимом символической ссылки либо для multi-user.target, либо для graphical.target . systemd всегда применяет default.target для запуска данной системы. Никогда не следует применять в качестве псевдонима default.target для halt.target, poweroff.target или reboot.target.

Каждая из целей имеет некий набор зависимостей, описываемых в её файде конфигураций. 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 для входа в систему вы увидите, будет зависеть от установленного по умолчанию диспетчера отображения.

Рисунок 16-5

Карта запуска systemd

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

Эксперимент 16-5.

До сих пор у нас загружался лишь graphical.target, поэтому давайте изменим эту установленную по умолчанию цель на multi-user.target чтобы загрузить интерфейс консоли вместо некого интерфейса GUI.

От имени пользователя root StudentVM1 измените свой каталог на тот в котором сопровождается конфигурирование systemd и выполните его беглый просмотр:


[root@studentvm1 ~]# cd /etc/systemd/system/ ; ll
drwxr-xr-x. 2 root root 4096 Apr 25 2018 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 2018 display-manager.service -> /usr/lib/systemd/system/lightdm.service
drwxr-xr-x. 2 root root 4096 Apr 25 2018 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 2018 local-fs.target.wants
drwxr-xr-x. 2 root root 4096 Oct 30 16:54 multi-user.target.wants
<snip>
[root@studentvm1 system]#

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

Имеющаяся запись default.target это символическая ссылка (symlink, soft link - подробнее жёсткие и мягкие ссылки подробнее обсуждаются в Главе 18) этого тома, symlink это то же самое что и soft link) на соответствующий каталог, /lib/systemd/system/graphical.target. Выведите перечень этого каталога чтобы увидеть что там ещё имеется:


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

Вы должны обнаружить в этом листинге файлы, каталоги и дополнительные ссылки, но взгляните на multi-user.target и graphical.target. Теперь отобразите содержимое default.target, коим выступает /lib/systemd/system/graphical.target:


[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]#

Эта ссылка на соответствующий файл graphical.target теперь поясняет все необходимые предварительные требования, которые нужны для такого графического интерфейса. Чтобы позволить данному хосту загрузку в режиме со множеством пользователей нам требуется удалить эту имеющуюся ссылку, а затем создать новую, которая укажет на верную цель. Выполните PWD /etc/systemd/system, если ещё не сделали этого:


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

Выведите листинг ссылки default.target чтобы убедиться что она связана с правильным файлом:


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

Если ваша ссылка не выглядит в точности так, удалите её и попытайтесь снова. Выведите лсписок содержимого своей ссылки default.target:


[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]#

Данная default.target имеет различные требования в своём разделе [unit]. Они не требуют диспетчера графического дисплея.

Перезагрузитесь. Ваша ВМ должна загрузить соотвествующую консоль входа в систему для виртуальной консоли 1, которая указана в соответсвующем дисплее как tty1. Теперь, когда вам известно что требуется для изменения вашей цели по умолчанию, верните её обратно в graphical.target при помощи разработанной под это команды. Вначале давайте проверим текущую цель по умолчанию:


[root@studentvm1 ~]# systemctl get-default
multi-user.target
[root@studentvm1 ~]# systemctl set-default graphical.target
Removed /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

Я не совсем понимаю почему для данной подкоманды разработчиками systemd был выбран термин "isolate". Тем не менее его действие состоит в переключении целей с одной запущенной цели на другую, в данном случае с соответствующей критической цели на графическую цель. Наша предыдущая команда эквивалентна старой команде init 5 из дней SystemV, запускавшей сценарии и саму программу init.

Зарегистрируйтесь в полученном рабочем месте GUI.

Более подробно мы изучим systemd в Главе 13, тома 2.

Инициализация системы 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.

Таблица 16-6. Краткий перечень диспетчеров дисплея
Рабочий стол	Диспетчер дисплея	Комментарий
`GNOME`	`gdm`	Диспетчер дисплея GNOME
`KDE`	`kdm`	Диспетчер дисплея KDE (вплоть до Fedora 20)
	`lightdm`	Диспетчер дисплея Lightweight
`LXDE`	`lxdm`	Диспетчер дисплея LXDE
`KDE`	`sddm`	Simple Desktop Display manager (Fedora 21 и далее)
	`xdm`	Устанавливаемый по умолчанию диспетчер дисплея X Windows System

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

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

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

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

Таблица 16-7. Краткий перечень диспетчеров окон
Рабочий стол	Диспетчер Окон	Комментарии
`Unity`	`Compiz`
	`Fluxbox`
	`FVWM`
	`IceWM`
`KDE`	`Kwin`	Стартовал с KDE Plasma 4 в 2008
`GNOME`	`Metacity`	Подразумеваемый по умолчанию в GNOME 2
`GNOME`	`Mutter`	Подразумеваемый по умолчанию в GNOME 3
`LXDE`	`Openbox`
	`twm`	Очень старый и очеь простой диспетчер окон. Некоторые диструбутивы, например Fedora, применяют его в качестве отступления когда не доступен никакой иной диспетчер окон или рабочий стол.
`Xfce`	`xfwm4`

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

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

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

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

Эксперимент 16-6.

Выполните данный эксперимент от имени root. Мы установим дополнительные диспетчеры дисплея и обособленные диспетчеры окон затем будут переключаться между ними.

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


[root@studentvm1 ~]# dnf list compiz fluxbox fvwm icewm xorg-x11-twm xfwm4
Last metadata expiration check: 1:00:54 ago on Thu 29 Nov 2018 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-xdm
Last metadata expiration check: 2:15:20 ago on Thu 29 Nov 2018 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.D20161111gita548c73e.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 ~]#

Все dm запускаются в виде службы systemd, поэтому другой способ определения того какие из них именно установлены состоит в проверке каталога /usr/lib/systemd/system/. Наш диспетчер дисплея lightdm показан установленным и доступным дважды, так как для него дотсупны обновления:


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]#

Как и в моей машине, у вас должен иметься лишь некий единственный dm, lightdm. Давайте установим lxdm и xorg-x11-xdm в качестве дополнительных диспетчеров дисплея с FVWM, fluxbox и icewm для диспетчеров окон:


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

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


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

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


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

Но в этом втором методе слегка больше набора текста. Переключитесь обратно в регистрацию lightdm в vc1 и взгляните на правый верхний угол своего экрана lightdm. Самая левая иконка, которая в моей ВМ выглядит как лист бумаги с загибом (иконка в вашей версии lightdm может отличаться, у меня она изменилась по крайней мере один раз после обновлений), позволяет нам выбирать те рабочий стол и диспетчер окон, которые мы пожелаем применять до того как войдём в систему. Для входа в систему кликните по этой иконке и выберите из меню FVWM, как это показано на Рисунке 16-08 .

Рисунок 16-8

Меню диспетчер дисплея lightdm теперь отображает вновь установленные диспетчеры окон

Исследуйте этот диспетчер окон. Откройте экземпляр Xterm и отыщите те варианты меню, которые предоставляют доступ к прикладным программам. Рисунок 16-09 отображает рабочий Fvwm (это не рабочий стол среды подобной KDE или GNOME) с неким открытым экземпляром Xterm, а также дерево меню, которое открывается при клике левой кнопкой по данному диспле. При клике правой кнопкой открывается другое меню.

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

Обратите внимание, что XDGMenu на Рисунке 16-09 также содержит приложения Xfce. Элемент меню Start Here приводит в меню Fvwm, которое содержит все стандартные приложения Linux, установленные в данном хосте.

Рисунок 16-9

Диспетчер окон Fvwm с неким экземпляром Xterm и какими- то из доступных меню

После того как вы проведёте некое время за изучением интерфейса Fvwm, выйдите из системы. Не можете найти как это сделать? Вот и я не мог, поскольку интуитивно это непонятно. Щёлкните левой кнопкой мыши по рабочему столу и откройте FvwmConsole. Затем наберите команду Quit - и да, с Q в верхнем регистре - и нажмите Enter.

Также мы можем открыть некий сеанс Xterm и воспользоваться следующей командой, которая убивает все экземпляры диспетчера окон Fvwm, относящиеся к данному пользователю student:


[student@studentvm1 ~]# killall fvwm

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

Давайте теперь сменим свой диспетчер дисплея на один из тех что мы установили. Каждый dm имеет те же самые функции чтобы предоставлять вход в систему через GUI и некие настройки, такие как значение среды рабочего стола или диспетчера окон для старта в качестве интерфейса пользователя. Измените каталог на /etc/systemd/system/ и перечислите ссылки на имеющиеся службы диспетчера диспдея:


[root@studentvm1 ~]# cd /etc/systemd/system/ ; ll display-manager.service
total 60
lrwxrwxrwx. 1 root root 39 Apr 25 2018 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  2018 /usr/lib/systemd/system/lxdm.service
-rw-r--r-- 1 root root  287 Feb 10  2018 /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.service
lrwxrwxrwx 1 root root 35 Nov 30 09:03 display.manager.service -> /usr/lib/systemd/system/xdm.service
[root@studentvm1 system]#

Насколько я могу судить, перезагрузка хоста- единственный способ надёжно активировать свой новый dm Пройдите далее и перезагрузите свою ВМ для этого.

Существует некий инструмент, system-switch-displaymanager, который поддерживается для выполнения необходимых изменений и он порой выглядит выполняющим эту работу. Однако этот инструмент не перезапускает необходимый dm, а множество раз данный шаг завершался неудачно при его исполнении. К сожалению, мои собственные эксперименты выявили, что перезапуск самой службы диспетчера дисплея не активирует новый dm/ Приводимые далее шаги выглядят как работающие; попробуйте их чтобы убедиться что они работают у вас переключая обратно к диспетчеру дисплея lightdm:


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

Если последующие два шага из этой последовательности не работают, тогда перезагружайтесь. Мой технический рецензент, Джейсон Бэйкер, сказал: "Мне показалось что это должно работать, но на самом деле мне не удалось войти в lightdm, а потому я перезагрузился."

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

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

Про вход в систему

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

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

Экран входа в систему через CLI

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

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

systemd запускает демон systemd-getty-generator.
Этот systemd-getty-generator порождает некий agetty для каждой из имеющихся виртуальных консолей при помощи serial-getty@.service.
Все agetty ожидают соединения с виртуальными консолями (VC), что является подключением определённого пользователя к одной из таких VC.
Данный agetty предоставляет для отображения экран входа в систему в текстовом режиме.
Данный пользователь выполняет регистрацию в системе.
Запускается предписанная в /etc/passwd оболочка.
Выполняется сценарий конфигурации оболочки.
Данный пользователь работает в сеансе этой оболочки.
Пользователь выполняет выход из системы.
Имеющийся systemd-getty-generator порождает по выходу из виртуальной консоли agetty.
Переходим к шагу 3.

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

Экран графического входа в систему

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

В конце последовательности запуска предписанный диспетчер дисплея (dm) запускается из systemd.
Данный диспетчер дисплеев отображает экран графического входа в систему, обычно в виртуальной консоли 1.
Сам dm ожидает входа в систему.
Определённый пользователь регистрируется в системе.
Запускается предписанный диспетчер окон.
В случае его определения запускается заданный GUI рабочего стола.
Вошедший в систему пользователь выполняет работу в соответствующем диспетчере окон/ рабочем столе.
Пользователь выполняет выход из системы.
systemd вторично порождает необходимый диспетчер дисплея.
Переходим на шаг 2.

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

Выводы главы

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

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

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

Упражнения

Опишите процесс загрузки Linux.
Опишите процесс запуска Linux.
Что делает GRUB?
Где находится на жёстком диске загрузки стадия 1 GRUB?
В чем состоят необходимые функции systemd в процессе запуска?
Где находятся целевые файлы и ссылки запуска systemd?
Настройте хост StudentVM1 с тем чтобы перезагрузить default.target.

После того как понаблюдаете перезагрузкумэтой ВМ пару раз, перенастройте default.target снова и перезагрузитесь.
В чём состоит основная функция agetty?
Опишите основную функцию диспетчера дисплея.
Какие компоненты Linux подключают виртуальную консоль и отображают экран входа в систему в текстовом режиме?
Перечислите и опишите те компоненты Linux, которые вовлечены в процесс входа пользователя в некую виртуальную консоль вплоть до его выхода из системы, а также всю последовательность событий при этом.
Что происходит когда служба диспетчера дисплея повторно запускается из некого терминального сеанса в имеющемся рабочем столе при помощи команды systemctl restart display-manager.service?