Boot linux что это

Linux Boot Process

Basically “Boot Process” A CPU gets its instructions from memory. The CPU reads instruction from the BIOS and searches for the hard disks, CD drives and other hardware. The BIOS program looks at the first sector for boot code.

The boot process for Linux goes through several stages. Different systems follows different stage here in Linux have 6 stages of Boot.

• BIOS ( Basic Input/Output System )
• MBR ( Master boot Record )
• GRUB ( Grand Unified Boot Loader )
• Kernel
• init
• run level ( init 0 — init 6 )

BIOS : The term BIOS stands for “Basic I/O System”, It looks for boot loader in CD Rom, hdd, or other boot-able media. Once the boot loader is detected and loaded into memory, BIOS gives the control to it.

So in simple terms we can say that “BIOS loads and executes the MBR boot loader “

MBR : The term MBR stands for “Master boot records” it is located in the first sector of the boo-table disks like /dev/hda or /dev/sda , And it has three component and MBR is less than or equal to 512 Bytes in size

1. Primary boot loader info in 1st 446 bytes
2. Partition table info in next 64 bytes.
3. MBR validation check in last 2 bytes.

so, we can say that, MBR loads(Boot info) and execute the GRUB boot loader.

GRUB : As mention above the term GRUB stands for “Grand unified boot loader” , if we have multiple images installed on our system we can choose one to be execute, GRUB display a splash screen, waits for few seconds, if you don’t enter or press anything, it loads the default Kernel image as specified in the GRUB Configuration file,

So, GRUB loads, it configuration file ( for BIOS system /boot/grub/grub.conf, for UEFI System /boot/efi/EFI/redhat/grub ) and Kernel into System memory. As we will in configuration file, it contains Kernel & initrd image. So in simple terms GRUB just loads and execute Kernel & initrd images.

Kernel : The term Kernel is the core of an operating system which provides access to services and hardware. So the boot loader loads one or multiple “initramfs images” into system memory. [ initramfrs: initial RAM Disk], The kernel use “initramfs”to read drivers and needed modules for booting the system. And it mount the “root file system” as specified in the ‘root=(GRUB configuration file).

So we can say that, After the kernel & initramfs image are loaded, control of the boot process goes through kernel. The kernel now initializes and configure memory and contacted hardware and kernel execute the the /sbin/init program ## since ‘init’ was the 1st program to be executed by linux kernel. It has the process id (PID) of 1 , we can check through command “ ps -ef | grep init “.

init : During this process, the system locates the root partition and file system. Both are checked and mounted then the system start the init process. Which runs the initialization scripts invoking different scripts in the “/etc/rc*.d “ directory. so we can say that init execute run level program.

so init execute the Run level program (init 0- init 6) depend on the default init level settings, system will execute. Look at the /etc/init tab following are the available run level “/etc/init.d/rc.*d”

• init 0 “Halt” /etc/rc.d/rc0.d
• init 1 “Single user mode” /etc/rc.d/rc1.d
• init 2 “Multi user mode without NFS” /etc/rc.d/rc2.d
• init 3 “Multi user mode with NFS” /etc/rc.d/rc3.d
• init 4 “unused” /etc/rc.d/rc4.d
• init 5 “X11- GUI mode” /etc/rc.d/rc5.d
• init 6 “Reboot” /etc/rc.d/rc6.d

Typically we would set the default run level to either init 3 or init 5

Run level : When the Linux System booting up, Those are the run level programs execute from the run level directory or defined by your run level directory.

Under the /etc/rc.d/rc*.d / directories, you would see program that start with S & K.

Program start with S are used during startup S for startup, K for kill.

…….I would love to hear your own experiences in the comments below. Please share your Valuable feedback.

Введение в процессы загрузки ядра и запуска системы Linux

Всем привет! Вот мы и открыли очередной, четвёртый по счёт уже, поток курса «Администратор Linux», который уверенно занимают свою нишу рядом с девопсерским курсом. Больше преподавателей, больше информации и стендов. Ну и как всегда больше интересной информации, которую подобрали преподаватели.

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

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

На самом деле, есть два ряда событий, необходимых для приведения компьютера с Linux в рабочее состояние: загрузка ядра (boot) и запуск системы (startup). Процесс загрузки ядра начинается при включении компьютера и заканчивается с инициализацией ядра и запуском systemd. После этого начинается процесс запуска системы, и именно он доводит компьютер Linux до рабочего состояния.

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

• BIOS POST;
• Загрузка ядра (GRUB2);
• Инициализация ядра;
• Запуск systemd, родителя всех процессов.

Процесс загрузки ядра

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

BIOS POST

Первый шаг процесса загрузки ядра Linux не имеет никакого отношения к Linux. Это аппаратная часть процесса, одинаковая для всех операционных систем. Когда питание подается на компьютер, в первую очередь происходит запуск POST (Power On Self Test), являющегося частью BIOS (Basic I/O System, Базовая Система Ввода-Вывода).

Когда IBM выпустила первый персональный компьютер в 1981 году, BIOS был разработан для инициализации аппаратных компонентов. POST — часть BIOS, задачей которого является обеспечение корректной работы компьютерного оборудования. Если POST заканчивается неудачно, то возможно компьютер неисправен, и процесс загрузки не продолжается.

BIOS POST проверяет базовую работоспособность железа, а затем вызывает прерывание BIOS — INT 13H, которое находит секторы загрузки ядра на всех подключенных устройствах с возможностью загрузки. Первый найденный сектор, в котором содержится валидная загрузочная запись, загружается в RAM, после чего контроль передается коду из загрузочного сектора.
Загрузочный сектор — только первый этап. В большинстве дистрибутивов Linux используется один из трех вариантов загрузчика: GRUB, GRUB2 и LILO. GRUB2 — самый новый и сейчас его используют гораздо чаще более старых вариантов.

GRUB2 расшифровывается как “GRand Unified Bootloader, version 2”, и теперь он является основным загрузчиком для большинства современных дистрибутивов Linux. GRUB2 — программа, которая делает компьютер достаточно “умным”, чтобы тот смог найти ядро операционной системы и загрузить его в память. Поскольку говорить и писать просто GRUB легче, чем GRUB2, в этой статье я возможно буду использовать термин GRUB, но подразумевать GRUB2, если не будет иного уточнения.

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

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

GRUB1 сейчас уже считается устаревшим и в большинстве современных дистрибутивов заменен на GRUB2, который является его переписанным вариантом. Дистрибутивы на основе Red Hat обновились до GRUB2 около Fedora 15 и CentOS/RHEL 7. GRUB2 имеет тот же загрузочный функционал, что и GRUB1, но в дополнении предоставляет mainframe-like, pre-OS окружение на базе команд и бОльшую гибкость на предзагрузочном этапе. Настройка GRUB2 происходит в /boot/grub2/grub.cfg .

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

Хоть официально GRUB2 не использует нумерацию этапов, ради удобства я воспользуюсь ей в этой статье.

Как уже упоминалось в разделе BIOS POST, в конце POST BIOS ищет загрузочные записи на прикрепленных дисках, обычно расположенных в Главной Загрузочной Записи (Master Boot Record, MBR), после чего он загружает первую найденную запись в память и приступает к ее исполнению. Bootstrap-код, то есть 1-ый этап GRUB2, занимает очень мало места, потому что должен влезать в первый 512-байтовый сектор на жестком диске вместе с таблицей разделов. Общее количество места, выделенного для самого bootstrap-кода в стандартной MBR — 446 байт. 446-байтовый файл для этапа 1 называется boot-img и не содержит таблицу разделов — она добавляется в загрузочную запись отдельно.

Поскольку загрузочная запись должна быть настолько маленькой, она не очень “умная” и не понимает структуру файловой системы. Поэтому единственной целью этапа 1 является обнаружение и загрузка этапа 1.5. Чтобы достичь этого, этап 1.5 GRUB должен располагаться в пространстве между самой загрузочной записью и первым разделом на диске. После загрузки этапа 1.5 GRUB в RAM, этап 1 передает контроль этапу 1.5.

Как было замечено выше, этап 1.5 GRUB должен находиться между загрузочной записью и первый разделом на диске. Исторически сложилось, что это пространство остается неиспользованным по техническим причинам. Первый раздел на жестком диске начинается в 63 секторе, а с учетом MBR в секторе 0, остается 62 512-байтовых секторов — 31744 байта — в которых можно хранить файл core.img — 1.5 этап GRUB. Файл core.img весит 25389 байт, что достаточно места для его хранения между MBR и первым разделом диска.

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

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

Все файлы этапа 2 GRUB находятся в директории /boot/grub2 и нескольких поддиректориях. В GRUB2 нет файла образа как в этапах 1 и 2. Вместо этого он по большей части состоит из runtime модулей ядра, которые грузятся по необходимости из директории /boot/grub2/i386-pc .

Задача этапа 2 GRUB2 — обнаружить и загрузить ядро Linux в RAM и передать контроль управления компьютером ядру. Ядро и связанные с ним файлы находятся в директории /boot . Файлы ядра легко узнать, поскольку их названия начинаются с vmlinuz. Вы можете составить список содержимого директории /boot , чтобы посмотреть текущие установленные ядра в вашей системе.

GRUB2, как и GRUB1, поддерживает загрузку одного из нескольких ядер Linux. Система управления пакетами Red Hat поддерживает сохранение нескольких версий ядра, чтобы можно было загрузить старую версию ядра в случае возникновения проблем с самой новой. По умолчанию, GRUB предоставляет предварительно загруженное меню установленные ядер, включая опцию rescue, а после настройки, и опцию recovery.

Этап 2 GRUB2 загружает выбранное ядро в память и передает контроль управления компьютером ядру.

Все ядра находятся в самораспаковывающемся, сжатом формате для экономии места. Ядра расположены в директории /boot , вместе с исходным образом диска RAM и списком разделов на жестких дисках.

После того, как выбранное ядро загружено в память и начинает исполняться, в первую очередь, оно должно извлечь самого себя из сжатой версии файла, перед тем как начать выполнять полезную работу. Как только извлечение произошло, оно загружает systemd, который является заменой старой программе SysV init, и передает ему контроль.

Это конец процесса загрузки ядра. К этому моменту, ядро Linux и systemd запущены, но не могут выполнять какие-либо полезные задачи для конечного пользователя, так как выполнять еще нечего.

Процесс запуска системы

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

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

Сначала, systemd монтирует файловые системы, как определено в /etc/fstab , включая любые swap-файлы и разделы. К этому моменту, он может получить доступ к файлам конфигурации, расположенным в /etc , включая его собственным. Он использует собственный конфигурационный файл /etc/systemd/system/default.target , чтобы определить таргет (target), по которому нужно загрузить хост. Файл default.target — просто симлинк на настоящий target файл. Для настольной рабочей станции обычно это graphical.target, эквивалентный runlevel 5 в старом инициализаторе SystemV. Для сервера, по умолчанию скорее всего будет multi-user.target, аналогичный runlevel 3 в SystemV. emergency.target похож на однопользовательский режим.

Обратите внимание, что target’ы и сервисы являются юнитами systemd.

Ниже представлена Таблица 1, в которой идет сравнение всех таргетов systemd со старыми уровнями выполнения (runlevel) в SystemV. Псевдонимы таргета systemd предоставляются systemd для обратной совместимости. Псевдонимы таргета разрешают скриптам — и многим сисадминам, мне в том числе — использовать такие SystemV команды как init3 для изменения уровней выполнения. Конечно, команды SystemV направлены systemd для интерпретации и исполнения.

Runlevel	aliases	Description
halt.target	Приостанавливает систему без отключения питания
0	poweroff.target	runlevel0.target	Приостанавливает систему и отключает питание
S	emergency.target	Однопользовательский режим. Сервисы не запущены; файловые системы не смонтированы. Это самый базовый уровень оперирования. Для взаимодействия пользователя с системой в главной консоли запущена только аварийная оболочка.
1	rescue.target	runlevel1.target	Базовая система, включающая монтирование файловой системы с самым базовым набором сервисов и rescue оболочкой в главной консоли.
2	runlevel2.target	Многопользовательский режим, без NFS, но все сервисы, не относящиеся к GUI, запущены.
3	multi-user.target	runlevel3.target	Все сервисы запущены, но только через интерфейс командной строки (CLI).
4	runlevel4.target	Не используется.
5	graphical.target	runlevel5.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.

Таблица 1: Сравнение уровней управления SystemV с target’ами systemd и некоторые псевдонимы таргетов.

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

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

Рисунок 1, представленный ниже, напрямую скопирован с главной страницы bootup. На нем показана общая последовательность событий во время запуска systemd и базовые требования для обеспечения его успешности.

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

Таким образом, sysinit.target достигается, когда завершены все юниты, от которых он зависит. Должны быть завершены все следующие юниты: монтирование файловых систем, настройка swap-файлов, запуск udev, настройка начального состояния генератора случайных чисел, инициализация низкоуровневых сервисов, настройка криптографических сервисов, если хотя бы одна файловая система зашифрована. В sysinit.target они могут выполняться параллельно.
sysinit.target запускает все низкоуровневые сервисы и юниты необходимые для минимальной функциональности системы, и те, что нужны для перехода к basic.target.

Рисунок 1. Карта запуска systemd

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

Наконец, можно начать инициализацию таргетов пользовательского уровня: multi-user.target или graphical.target. Стоит отметить, что multi-user.target должен быть достигнут до того, как будут выполнены зависимости графического таргета.

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

Недавно мне пришлось поменять дефолтное загрузочное ядро на компьютере Linux, который использовал GRUB2. Я обнаружил, что некоторые команды перестали работать корректно, или же я пользовался ими как-то некорректно. До сих пор не знаю, в чем была проблема, потребуется больше времени на ее исследование.

Команда grub2-set-default неправильно настроила дефолтный индекс ядра в файле /etc/default/grub , поэтому желаемое альтернативное ядро не загружалось. Я вручную поменял /etc/default/grub GRUB_DEFAULT=saved на GRUB_DEFAULT=2 , где 2 — индекс установленного ядра, которое я хотел запустить. Затем, я запустил команду grub2-mkconfig > /boot/grub2/grub.cfg для создания нового конфигурационного файла grub. Эта уловка сработала, и альтернативное ядро было запущено.

GRUB2 и система инициализации systemd — ключевые компоненты для фаз загрузки ядра и запуска системы большинства современных дистрибутивов Linux. Несмотря на противоречия, особенно вокруг systemd, эти два компонента хорошо работаю вместе для загрузки ядра и запуска всех системных сервисов, необходимых для создания функциональной системы Linux.
Хоть я и считаю GRUB2 и systemd в целом более сложными, чем их предшественники, они ничуть не сложнее в освоении и управлении. В мануалах содержится большое количество информации о systemd, а на freedesktop.org список его страниц представлен полностью. За большей информацией обратитесь к ссылкам ниже:

(Wikipedia) l (GNU.org) (Wikipedia) (Wikipedia) (Wikipedia) (Freedesktop.org) (Freedesktop.org)

Вот и всё. Ждём вопросы и комментарии тут или их можно задать напрямую на открытом уроке.

Процесс загрузки Linux

Задумывались ли вы о том, как происходит загрузка операционной системы? Как компьютер узнаёт о том, где находится операционная система? Давайте рассмотрим процесс запуска Linux от включения компьютера и до входа в систему.

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

Процесс загрузки Linux

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

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

Первый этап: включение компьютера

Запуск компьютера с BIOS и UEFI отличается. Первый BIOS появился в середине 70-х годов, а MBR стали использовать с 1983 года. Стоит ли говорить о том, что для современного компьютера предпочтительнее использовать UEFI и GPT. А теперь перейдём непосредственно к рассмотрению первого этапа загрузки.

BIOS + MBR

BIOS – это базовая система ввода-вывода. Она представляет из себя набор программ для взаимодействия с устройствами компьютера. BIOS хранится на микросхеме EEPROM материнской платы. При каждом запуске компьютера плата автоматически отправляет код процессору на исполнение. Далее BIOS проводит проверку оборудования (тест POST) и обращается к жёсткому диску или твердотельному накопителю. От него ему нужны первые 512 байт, именно там находится главная загрузочная запись (MBR). Ниже вы можете видеть структуру MBR.

Если подпись MBR равна 55AAh, то система начинает выполнять код первичного загрузчика. В случае с Linux, MBR передаёт управление основному загрузчику GRUB. Он располагается сразу после MBR. До начала первого раздела на накопителе есть не менее 32 килобайт свободного места (современные системы оставляют 1 Мбайт), этого достаточно для того, чтобы разместить GRUB.

Таблица разделов в MBR имеет крайне скромный размер, есть место всего на 4 позиции. В связи с этим нельзя разметить накопители объёмом более 2 терабайт. К тому же она использует устаревшую адресацию, с цилиндрами, головками и секторами жёсткого диска.

На компьютерах с UEFI поддержка MBR никуда не делась, но для этого вам придётся активировать BIOS или CSM mode, в зависимости от производителя материнской платы. Это нужно для совместимости со старыми операционными системами.

UEFI + GPT

Интерфейс расширяемой прошивки EFI (позднее унифицированный UEFI) – это разработка Intel. Он был создан потому, что BIOS имеет ряд недостатков. К ним можно причислить работу в 16-битном режиме, последовательную проверку устройств и загрузку только через MBR.

Физически поменялось не многое, разве что FLASH-накопитель для хранения прошивки стал больше. Зато программная часть претерпела значительные изменения. UEFI работает в 32- и 64-битном режиме, поддерживает таблицу разделов GPT, может иметь красивый графический интерфейс, оболочку EFI Shell и управление с помощью мыши. К тому же опрос оборудования происходит гораздо быстрее.

Оглавление таблицы GPT располагается в первом логическом блоке (LBA 1). В GPT перешли к использованию логических блоков, к тому же их понимают современные жёсткие диски и SSD. Нулевой блок по-прежнему отдаётся под MBR, но в этот раз он выполняет защитную функцию, чтобы старые операционные системы не переписали GPT.

Каждой записи таблицы даётся 128 байт, что позволяет разметить накопители практически неограниченного объёма. Да и самих записей может быть больше 100.

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

После проверки устройств, UEFI может самостоятельно обратиться к таблице разделов GPT. В ней её интересует EFI раздел. Обычно под него выделяется 520-540 Мбайт. Такой размер связан с тем, что ранние версии EFI могли выдавать ошибку при работе с меньшим объёмом. Но Windows уже отходит от этой традиции и ограничивается 100 Мбайтами.

В разделе EFI обязательно должна быть папка EFI/BOOT, в ней находится загрузчик по умолчанию. Но никто не мешает добавить свой загрузчик, например, для Ubuntu и Windows.

К минусам UEFI можно отнести Secure Boot. Загрузчик без подписи просто не сможет быть использован. Эти меры направлены в первую очередь на компьютеры с Windows, чтобы не допустить использование старых систем на новых омпьютерах. Для Linux в этом случае приходится искать подписанный загрузчик или отключать Secure Boot, если имеется такая возможность.

Ещё одним способом загрузки является PXE – загрузка через сетевой интерфейс. Первичный загрузчик находится в ПЗУ сетевой карты. С его помощью карта через протокол TFTP получает основной загрузчик.

Этот способ загрузки будет работать как с BIOS, так и с UEFI. Он полезен для работы с тонкими клиентами и для установки операционной системы по сети.

Второй этап: загрузчик

Загрузчик подготавливает систему к загрузке ядра операционной системы. Например, для Linux он может передавать параметры запуска ядра. В зависимости от того, что используется, BIOS или UEFI, выбор загрузчика отличается.

Как можете видеть, в Ubuntu есть как .efi загрузчик, так и GRUB.

GRUB – это основной загрузчик для большинства дистрибутивов Linux. Он примечателен тем, что позволяет не только запустить ядро Linux или другой операционной системы, но ещё и сам по себе способен выполнять некоторые операции. Он имеет собственную командную строку и в теории позволяет устранить собственные ошибки. GRUB существует в версиях как для BIOS, так и UEFI. Но последний не имеет цифровой подписи для Secure Boot.

Syslinux Project

Дальше выполняется загрузка ядра Linux. Ядро лежит в папке boot под названием vmlinuz. «vm» в начале говорит о том, что ядро будет размещено в виртуальной памяти. А «z» на конце означает то, что ядро запаковано в архив и требует распаковку. Это возможно благодаря тому, что в начале архива находится исполняемый код.

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

Ядро Linux монолитное, драйверы устройств хранятся прямо в нём. Однако, это утверждение верно лишь отчасти. Большая часть периферийных устройств не имеет драйверов в ядре Linux. Вместо этого в оперативной памяти распаковывается ещё один файл во временной файловой системе – initrd.img.

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

Четвертый этап: запуск пользовательских служб

Ядро загрузилось и работает. Но этого недостаточно для работы с операционной системой. Вы по-прежнему не можете взаимодействовать с ней на прикладном уровне. Для того, чтобы можно было что-то сделать в Linux, управление получает подсистема инициализации и управления службами. Обычно этот процесс имеет идентификационный номер PID-1.

Systemd

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

Стоит пару слов уделить D-Bus. Эта служба позволяет процессам взаимодействовать друг с другом. Например, через неё служба управления звуковыми устройствами узнаёт о том, что была нажата клавиша увеличения громкости, распознанная другой службой. Такой подход позволяет создавать простые, но эффективные службы.

А ещё в комплект утилит Systemd входит супервизор. Он следит за тем, чтобы все критически важные службы работали. Если он заметит, что какой-то службы не хватает, то сразу же запустит её снова. Его также применяют для поддержания работы серверов.

Sysvinit, OpenRC и другие

Sysvinit считается устаревшей системой. Она следует принципам, заложенным ещё в 80-х годах для операционной системы Unix System V. Запуск служб происходит последовательно, а настройка производится с помощью скриптов, что несколько проще, чем у systemd.

Для дистрибутива Gentoo разрабатывается система инициализации OpenRC. Её можно назвать осовремененной sysvinit. Но важно понимать, что рядовому пользователю система инициализации безразлична, она интересует лишь тех, кто добавляет свои службы и утилиты в дистрибутив Linux.

О других системах, вроде Runit, Daemontools или S6, справедливо предыдущее утверждение, к тому же их доля совсем невелика. Хотя они тоже имеют свои особенности. После этого процесс загрузки Linux практически завершен.

Пятый этап: экранный менеджер и окружение рабочего стола

Нельзя списывать со счетов и дисплейный менеджер. Это по сути первая программа с графическим интерфейсом. Она отвечает за вход в систему. Хотя и до её запуска проводились некоторые работы, был запущен сервер X11 для обращения к видеокарте и обработки команд управления c мыши и клавиатуры.

После ввода пароля запускается оконный менеджер с библиотеками отображения (обычно GTK3 или Qt) и непосредственно само окружение рабочего стола. Эти службы отвечают за то, чтобы вы могли перемещать окна, перетаскивать файлы, иметь несколько рабочих столов и тому подобное. Всё, загрузка Linux выполнена и операционная система полностью готова к использованию!

Выводы

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

Что же касается выбора между BIOS и UEFI, то последний однозначно выигрывает. Как минимум потому, что он практически не тратит время на проверку оборудования, а также позволяет практически сразу передать управление ядру Linux.

Guide to the Boot Process of a Linux System

If you have a few years of experience in the Linux ecosystem, and you’re interested in sharing that experience with the community, have a look at our Contribution Guidelines.

1. Introduction

The start-up of a Linux operating system follows a step-by-step process. This process starts with the power on or by running a command in the terminal:

In this tutorial, we’ll go through the booting steps of a Linux system.

2. BIOS and UEFI

First, the BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) program kicks in once the system powers up. Usually, the BIOS contains all the code to gain initial access to the main machine devices:

• keyboard
• display screen
• disk drives
• serial communications

However, most of these devices will have dedicated device drivers taking over once the system boots fully.

BIOS and UEFI are firmware interfaces that computers use to boot up the operating system (OS). Yet, the two programs differ in how they store metadata on and about the drive:

• BIOS uses the Master Boot Record (MBR)
• UEFI uses the GUID Partition Table (GPT)

Next, the BIOS or UEFI runs the power-on self-test (POST). The POST does a series of tasks:

• verify the hardware components and peripherals
• carry out tests to ensure that the computer is in proper working condition

Further, if this test finds any error, it commonly shows an error message on the screen. In case the test fails to detect the RAM, POST triggers a beeping sound.

Finally, if the system passes the POST, it signals the start-up process to the next stage.

3. Boot Loader

Now, the BIOS or UEFI has run the POST to check the state of the machine. Moving on, the BIOS/UEFI selects a boot device depending on the system configuration. Usually, there’s a default boot order:

1. Hard drives
2. USB drives
3. CD drives

Of course, we can configure the BIOS or UEFI to choose the boot device in any order. Whatever their order, the computer looks for the boot loader in these devices one by one.

In fact, a BIOS system has the boot loader located in the first sector of the boot device; this is the MBR. It takes up the first 512 bytes on the disk. On the other hand, a UEFI system stores all startup data in an .efi file. The file is on the EFI System Partition, which contains the boot loader.

For example, we can use fdisk to check the system partition on our machine:

Notably, the boot loader is a small program that loads the operating system. The main job of the boot loader is to perform three actions with the kernel: locate on the disk, insert into memory, and execute with the supplied options.

The following are some of the available boot loaders for a Linux system:

• LILO
• SYSILINUX
• GRUB2

In general, once the computer finds the boot loader on a device, it will run it. Consequently, this loads a larger and more complex program which eventually starts our operating system.

Let’s highlight some of the boot loaders in use with Linux.

3.1. LILO

Initially, LILO (Linux Loader) was one of the most widely used Linux boot loaders. However, it has lost favor because it has no support for multi-boot environments and for UEFI. Also, it has limited support for new filesystems.

Officially, the developers of LILO halted its development and support in December 2015. Hence, the Linux Loader is old and mostly obsolete.

3.2. SYSLINUX

Equally, SYSLINUX is a boot loader for the Linux operating system, which runs on a FAT filesystem, typical for a Windows system. In short, its goal is to ease the process of installing Linux for the first time.

Further, SYSLINUX supports several major filesystems:

• FAT
• ext2
• ext3
• ext4

In addition, SYSLINUX can support Btrfs and XFS filesystems with some constraints.

3.3. GRUB2

Despite the many choices, almost all (non-embedded) modern Linux distributions use GRUB (GRand Unified Boot Loader) because it’s very feature-rich:

• ability to boot multiple operating systems
• boots both a graphical and a text-based interface
• allows ease of use over a serial cable
• strong command line interface for interactive configuration
• network-based diskless booting

Presently, GRUB2 has replaced its past version (GRUB), which is now known as GRUB Legacy. Importantly, we can check for the GRUB version in our system using the following command:

Now, let’s see what GRUB2 does in the boot process:

1. takes over from BIOS or UEFI at boot time
2. loads itself
3. inserts the Linux kernel into memory
4. turns over execution to the kernel

Notably, the GRUB configuration file is located at /boot/grub by default:

Initially, GRUB Legacy had three stages in the boot process:

1. Stage 1
2. Stage 1.5
3. Stage 2

However, with GRUB2, these stages don’t exist anymore. Instead, it contains various *.img files that serve similar functions.

At this point, GRUB2 inserts the kernel into memory and turns control of the system over to the kernel.

4. Kernel

After going through BIOS or UEFI, POST, and using a boot loader to initiate the kernel, the operating system now controls access to our computer resources.

Here, the Linux kernel follows a predefined procedure:

1. decompress itself in place
2. perform hardware checks
3. gain access to vital peripheral hardware
4. run the init process

Next, the init process continues the system startup by running init scripts for the parent process. Also, the init process inserts more kernel modules (like device drivers).

5. Systemd

To reiterate, the kernel initiates the init process, which starts the parent process. Here, the parent of all Linux processes is Systemd, which replaces the old SysVinit process. Following the booting steps, Systemd performs a range of tasks:

• probe all remaining hardware
• mount filesystems
• initiate and terminate services
• manage essential system processes like user login
• run a desktop environment

Indeed, these and other tasks allow users to interact with the system. Lastly, Systemd uses the /etc/systemd/system/default.target file to decide the state or target the Linux system boots into.

6. Run Levels

In Linux, the run level stands for the current state of the operating system. Run levels define which system services are running. Previously, SysVinit identified run levels by number. However, .target files now replace run levels in Systemd.

Further, Systemd activates the default.target unit by default when the system boots. Let’s check our default target:

Now, let’s see the link between run level numbers and targets:

1. poweroff.target, run level 0: turn off (shut down) the computer
2. rescue.target, run level 1: initiate a rescue shell process
3. multi-user.target, run level 3: configure the system as a non-graphical (console) multi-user environment
4. graphical.target, run level 5: establish a graphical multi-user interface with network services
5. reboot.target, run level 6: restart the machine
6. emergency.target: emergency run level

For instance, the target value for a desktop workstation with a graphical user interface (GUI) is 5. This value stands for run level 5 which is graphical.target. Also, the run level for a server without a GUI is 3 because the default target is multi-user.target.

In addition, we can change the target (run level) while the system runs. This change entails that only services and other units defined under that target will now run on the system.

For example, to switch to run level 3 from run level 5, we can run the following command:

Then, to take the system to run level 5, let’s run the command:

This command returns the run level to graphical.target, equivalent to level 5 for GUI.

7. Conclusion

In this article, we’ve seen the boot process of a Linux system. Also, we discussed several boot loaders and their functions. Finally, we went over the various run levels that a Linux system can enter during the boot process.

If you have a few years of experience in the Linux ecosystem, and you’re interested in sharing that experience with the community, have a look at our Contribution Guidelines.