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

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

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

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

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

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

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

Загрузочный сектор - это фактичеки первый этап загрузчика. Существует три загрузчика, используемые большинством дистрибутивов Linux: GRUB, GRUB2 и LILO. GRUB2 является самым современным и используется сегодня гораздо чаще, чем более старые варианты.

GRUB2

GRUB2 означает «GRAND Unified Bootloader, версия 2», и сегодня он является основным загрузчиком для большинства дистрибутивов Linux. GRUB2 - это программа, которая делает компьютер достаточно умным, чтобы найти ядро операционной системы и загрузить его в память. Поскольку проще писать и говорить GRUB, чем GRUB2, я буду использовать термин GRUB в этом документе, но при этом буду ссылаться на GRUB2, если не указано иное.

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

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

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

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

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

Этап 1

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

Поскольку загрузочная запись должна быть такой маленькой, она не очень умна и не понимает структуры файловой системы. Поэтому единственной целью этапа 1 является нахождение и загрузка этапа 1.5. Для этого этап 1.5 GRUB должен быть расположен в пространстве между самой загрузочной записью и первым разделом на диске. После загрузки этапа 1.5 GRUB в ОЗУ, этап 1 передает управление этапу 1.5.

Этап 1.5

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

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

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

Этап 2

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

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

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

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

Ядро

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

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

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

Процесс запуска

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

systemd

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

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

Обратите внимание, что цели и службы являются единицами systemd.

В таблице 1 ниже представлено сравнение целей systemd со старыми уровнями запуска SystemV. Алиасы целей предоставляются systemd для обратной совместимости. Алиасы целей позволяют сценариям и многим системным администраторам, таким как я, использовать команды SystemV, такие как init 3, для изменения уровней запуска. Конечно, команды SystemV для интерпретации и выполнения пересылаются в systemd.

Уровень SystemV	Цели target	Алиасы целей systemd	Описание
-	halt.target	-	Выключает систему без выключения питания.
0	poweroff.target	runlevel0.target	Выключает систему с выключением питания.
S	emergency.target	-	Однопользовательский режим. Службы не работают; файловые системы не смонтированы. Это базовый уровень работы с только аварийной оболочкой, запущенной на главной консоли, чтобы пользователь мог взаимодействовать с системой.
1	rescue.target	runlevel1.target	Базовая система, включающая смонтированные файловые системы только с основными запущенными службами и аварийной оболочкой на главной консоли.
2	-	runlevel2.target	Многопользовательский режим без NFS, но с запущенными остальными консольными службами
3	multi-user.target	runlevel3.target	Все службы работают, но доступен только интерфейс командной строки.
4	-	runlevel4.target	Не используется
5	graphical.target	runlevel5.target	Многопользовательский режим с графическим интерфейсом
6	reboot.target	runlevel6.target
-	default.target	-	Эта цель всегда является символической ссылкой на multi-user.target или graphical.target. system всегда использует default.target для запуска системы. default.никогда не должна ссылаться на halt.target, poweroff.target или reboot.target.

Таблица 1: Сравнение уровней запуска SystemV с целями systemd.

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

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

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

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

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

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

Local-fs-pre.target | v (various mounts and (various swap (various cryptsetup fsck services...) devices...) devices...) (various low-level (various low-level | | | services: udevd, API VFS mounts: v v v tmpfiles, random mqueue, configfs, local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...) | | | | | \__________________|_________________ | ___________________|____________________/ \|/ v sysinit.target | ____________________________________/|\________________________________________ / | | | \ | | | | | v v | v v (various (various | (various rescue.service timers...) paths...) | sockets...) | | | | | v v v | v rescue.target timers.target paths.target | sockets.target | | | | v \_________________ | ___________________/ \|/ v basic.target | ____________________________________/| emergency.service / | | | | | | v v v v emergency.target display- (various system (various system manager.service services services) | required for | | graphical UIs) v | | multi-user.target | | | \_________________ | _________________/ \|/ v graphical.target

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

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

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

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

Проблемы

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

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

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

В момент запуска процессор передаёт управление по определённому физическому адресу в ПЗУ. В этот момент начинается выполнение кода BIOS/UEFI. Производится инициализация оборудования и выбирается загрузочный носитель. В случае BIOS происходит считывание в ОЗУ начального загрузчика и передача управления на него. Начальный загрузчик обычно занимает один сектор на диске (MBR) и ограничен размером 384 байт (512 байт – сектор диска, минус 128 байт – таблица разделов). В зависимости от типа загрузочного устройства загрузочный сектор может считываться из разных мест:

• При загрузке с дискеты или HDD загрузчик читается из первого сектора физического носителя;
• При загрузке с CD/DVD – из первого сектора образа загрузочного диска, размещённого в структуре данных CD;
• При сетевой загрузке – из первого сектора образа загрузочного диска, скачиваемого с сервера по протоколу tftp.

При форматировании диска в MBR вместо загрузчика иногда пишется программа, которая пишет на экране информационный текст "No bootable device -- insert boot disk and prress any key"

1.1 Начальный загрузчик считывает в память основной загрузчик (GRUB, LiLo, NTLDR) и передаёт управление ему. Поскольку начальный загрузчик очень мал, то, как правило, в его код жестко прописывают сектора, из которых надо прочитать код основного загрузчика. На HDD это может быть пространство между MBR и первым разделом на диске (нулевая дорожка) или зарезервированное место внутри ФС (зарезервированный Inode в ext2fs). На дискете и при использовании образа диска при загрузке с CD или по сети – основной загрузчик может располагаться сразу вслед за первичным загрузчиком и занимать весь объём образа.

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

Загрузка ядра (vmlinuz) и вспомогательного образа диска (initrd, initramfs). Загрузчик GRUB представляет из себя мини ОС, поддерживающую все основные файловые системы. GRUB ищет конфигурационный файл, в котором прописаны пути к образу ядра и образу вспомогательного диска. При необходимости образ ядра распаковывается в ОЗУ, формируется область памяти, содержащая параметры, передаваемые из загрузчика в ядро, в том числе адрес образа вспомогательного диска.

Ядро загружаемое через GRUB должно соответствовать соглашениям multiboot или multiboot2 . В соответствии с соглашением, образ ядра включает структуру (например в секции данных), которая начинается с магического числа и содержит информацию о желаемом положении ядра в памяти и точке на которую надо передать управление. Перед передачей управления в ядро в регистр EAX помещается ещё одно магическое число, а в регистр EBX - адрес таблицы с параметрами, подготовленными загрузчиком.

Вспомогательный диск необходим современным Linux системам из-за модульности ядра и содержит драйверы (ATA, NFS, RAID и т.п.), необходимые для получения доступа к основной файловой системе. Внутри образа находится файловая система в формате архива cpio.

На этом этапе создаётся процесс с pid=1 , в котором происходит выполнение скрипта init , находящегося в корневом каталоге вспомогательного диска. Параметры, передаваемые ядру, фактически передаются в init , как аргументы командной строки.

Скрипт содержит команды загрузки необходимых драйверов в виде модулей ядра, создание временных файлов устройств в каталоге /dev для доступа к этим модулям, сканирование дисковых разделов для обнаружения и инициализации RAIDов и логических томов. После инициализации логических дисков, делается попытка смонтировать корневую файловую систему, заданную параметром root= . В случае бездисковой сетевой загрузки корневой каталог подключается по NFS.

На экран выдаются сообщения о загрузке драйверов и о поиске виртуальных томов подсистемы LVM. Этап завершается перемонтированием корневого каталога на основную файловую систему и загрузку в процесс с pid=1 основной программы /sbin/init (или её аналога).

В классическом UNIX"е и старых версиях Linux (примерно до 2012 года) программа init считывает конфигурационный файл /etc/inittab , инициализирует текстовые консоли и, как правило, запускает необходимые службы с помощью набора скриптов, расположенных в каталогах /etc/init.d и /etc/rc*.d . В современных дистрибутивах Linux в файле /sbin/init находится более современная программа запуска служб. Наиболее популярной из подобных программ является systemd , который позволяют существенно сократить время этого этапа загрузки.

На экран на этом этапе выдаются строки, сообщающие о запуске служб, и информация об успешности данного процесса ( или ).

Загрузчик GRUB

Загрузиться с установочного диска в режим восстановления - Rescue mode. Для этого в момент загрузки на приглашение boot: необходимо ввести linux rescue

Если всё пойдёт нормально, то корневой каталог основной системы будет смонтирован в /mnt/sysimage , загрузочный каталог в /mnt/sysimage/boot . Кроме того текущие каталоги /proc , /sys и /dev будут смонтированы в соответствующие подкаталоги /mnt/sysimage . Если это не случится, то придётся проделать эти операции вручную.

Когда все каталоги смонтированы, можно сменить корневой каталог

#если выяснится, что вы что-то забыли смонтировать, то можно выйти по ^D chroot /mnt/sysimage

и пересобрать initrd

#копируем старый файл cp -p /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak #создаём новый dracut -f #если версия ядра в основной системе отличается от версии на установочном диске, указываем её явно dracut -f /boot/initramfs-2.6.32-358.el6.x86_64.img 2.6.32-358.el6.x86_64

#копируем старый файл cp -p /boot/initrd-$(uname -r).img /boot/initrd-$(uname -r).img.bak #создаём новый mkinitrd -f -v /boot/initrd-$(uname -r).img $(uname -r) #если версия ядра в основной системе отличается от версии на установочном диске, указываем её явно mkinitrd -f -v /boot/initrd-2.6.18-371.el5.img 2.6.18-371.el5

Cd / sync telinit 6

Полный пример с драйвером i2o_block (SCSI адаптер Adaptec 2010S), который не загружается автоматически. Пример выполняется в CentOS 5, поскольку в стандартном ядре CentOS 6 поддержка этого драйвера отключена.

После загрузки с CD в Rescue mode выдаётся сообщение, что Linux разделы не найдены и их надо монтировать самостоятельно.

#Загружаем драйвер insmod i2o_block #Проверяем, что всё сработало lsmod .... dmesg ... #Создаём файлы устройств на основе информации в dmesg mkdir /dev/i2o mknod /dev/i2o/hda b 80 0 mknod /dev/i2o/hda1 b 80 1 mknod /dev/i2o/hda2 b 80 2 #Активируем VolumeGroup lvm vgchange -a y #Монтируем тома mkdir /mnt/sysimage mount /dev/mapper/VolGroup00-LogVol00 /mnt/sysimage mount /dev/i2o/hda1 /mnt/sysimage/boot #Монтируем спецкаталоги mount --bind /proc /mnt/sysimage/proc mount --bind /dev /mnt/sysimage/dev mount --bind /sys /mnt/sysimage/sys

Далее по инструкции, только при создании образа диска надо указать программе mkinitrd дополнительную опцию --preload=i2o_block и отключить сервисы readahead , поскольку они приводят к зависанию драйвера i2o_block:

Chkconfig early-readahead off chkconfig later-readahead off

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

В этой лекции я расскажу, что делает классическая программа init в сочетании со скриптами rc.d в стиле System V (Систем пять). System V - это классическая версия UNIX на которой построены коммерческие UNIX.

Судя по названию, rc.d это некий каталог. Есть такая традиция UNIX - если вся конфигурация чего-либо умещается в один файл, и он называет config, то при разбиении его на отдельные файлы, которые подключаются к основному, создают каталог с аналогичным именем и добавляют к имени.d – config.d. Буква d означает, что это директория и там лежат вспомогательные части конфигурационного файла. У формата конфигурационных файлов программы init есть две традиции: вариант System V, в котором каждая деталь конфигурации держится в отдельном файле в каталоге rc.d, и традиция BSD систем, в которой есть один файл /etc/rc, содержащий много скриптов и переменных, которые отвечают за поведение системы.

В любом случае, при старте системы у нас создается процесс с PID=1, в котором запущена программа, которая называется init. Как вы видели в прошлый раз, если программу init убить, то ядро впадает в панику и прекращает всяческую работу.

Классический System V init читает файл /etc/inittab и выполняет ряд предписаний, которые прописаны в этом файле. Inittab этот текстовый файл каждая строка которого, это, по сути дела, одна команда или какое-то правило поведения. Inittab выглядит так:

id:3:initdefault:

si::sysinit:/etc/rc.d/rc.sysinit

l3:3:wait:/etc/rc.d/rc 3

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Вначале строки стоит метка. В чем большой смысл этой метки я не очень понимаю. Можно считать, что это простой текст и все. Вторым пунктом стоит либо так называемый уровень загрузки, либо пустое значение. Уровень загрузки - это либо одно число от 0 до 6, либо список чисел через запятую. Дальше идет некое действие. Действия бывают следующие: wait, respawn, sysinit, ctrlaltdel. Есть и другие действия, но это самые используемые. Наконец, в конце строки написана некая команда с именем исполняемого файла и аргументов, которые этой команде надо передать.

Действие sysinit выполняется однократно при старте системы.

Действие ctrlaltdel это на самом деле не совсем действие – это обработчик сочетания клавиш control alt del. Само нажатие перехватывается ядром системы, и информация об этом пересылается в процесс init, который должен выполнить определенную команду. Например, может быть выполнена команда shutdown, которая выполнит выключение компьютера. В принципе сюда можно прописать любую другую программу, например, echo, которая после нажатия control alt del будет выдавать на все терминалы системы какое-нибудь сообщение. камина консолью так

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

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

Итак, есть однократное выполнение с ожиданием результатов и многократное выполнение в асинхронном режиме – запустились, дождались пока закончить, запустили слова.

Уровни загрузки - это некая условность, которая позволяет управлять загружаемыми службами. Ближайший аналог в windows – это загрузка в безопасном режиме, когда грузится только ограниченное число драйверов и стартует минимальное количество служб, загрузка с отладкой, когда каждое действие дополнительно протоколируются и обычная полноценная загрузка.

В Linux по традиции выделяется 6 вариантов загрузки. Это деление довольно условно.

0 и 6 это выключение. 0 - полное выключение электричество, а 6 - режим перезагрузки.

4 в Linux вообще пропущен

Остаются четыре уровня загрузки:

1 - однопользовательский режим. Если передать загрузчику ключевое слово single, то мы окажемся в однопользовательском режиме, где запущен только один процесса и это шелл администратора системы. Этот режим используется для восстановления системы.

3 - нормальный многопользовательский текстовый режим, когда запущены все службы, работает сеть, работают все драйверы.

2 - тоже текстовый режим, но без подключения сетевых дисков. Дело в том, что традиционные сетевая файловая система nfs, которая используется в UNIX, чрезвычайно устойчива к повреждениям сети. Если мы выключили файловый сервер или обрезали сетевой кабель, то сетевая файловая система nfs будет предпринимать многочисленные попытки восстановиться и эти попытки настолько длительны, что я ни разу не смог дождаться времени, когда же наконец появится сообщение об ошибке. Возможно это произойдёт через час, а может и через 6 часов. Всё это время драйвер nfs будет держать компьютер, не давая ничего сделать. Поэтому, если у нас упала сеть или файловый сервер в настройках написано, что при старте необходимо подмонтировать внешние диски, то попытка загрузится в полноценный режим приведёт к тому, что у вас все зависнет. Для этого случая и предусмотрен второй вариант загрузки - все как в третьем, только сетевые диски не подключаются. Сам сетевой адаптер работает, IP адрес назначается, интернет доступен.

5 - то же самое что и 3, но с запуском x window - графического интерфейса.

режим 2 включает себя 1 + многопользовательский режим. 3 включает 2 + монтирование сетевых файловых систем. Наконец, 5 включает в себя 3 + запуск графической подсистемы. Будет ли это реализовано последовательно или нет - это проблема дистрибутива. Вообще говоря, администраторы могут самостоятельно настроить файл inittab так, чтобы эти режимы запускались последовательно, а можно сделать так чтобы все было абсолютно независимо - переключаясь в очередной режим, убираем все что было сделано на предыдущем шаге, и настраиваем все с нуля.

Рассмотрим строки реального файла. Они очень просты.

l3:3:wait:/etc/rc.d/rc 3

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

Программа запуска называется rc и запускается с номером уровня в качестве параметра. Сама программа init достаточно простая. Она умеет построчно читать свой файл с простым синтаксисом и стартовать новые процессы, запуская какие-то вспомогательные программы. Вся логика уровней загрузки спрятана в скрипте rc. Запустив rc с параметром 3 мы перейдем на третий уровень, с параметром 5 - на пятый.

Программа rc тоже очень простая. Это скрипт который выполняет все файлы в каталогах, соответствующих уровню загрузки, например, /etc/rc3.d/. В этих каталогах находятся исполняемые файлы, которые принимают один параметр - либо start, либо stop. Если файл запущен с параметром start, то он стартует службу, если с параметром stop, то останавливает её. Например, network start будет настраивать сетевые интерфейсы, а network stop будет переводить интерфейсы в выключенное состояние. Кроме сетевых интерфейсов есть скрипты подключения/отключение сетевых файловых систем, запуска/остановки сервисов и т.д.

Имена файлов в каталогах построенным по определенным правилам. Они начинаются либо с буквы K либо с буквы S, за которыми идет число и имя службы.

Скрипт rc просматриваем содержимого каталога rc3 и выбирает оттуда все файлы которые начинаются с буквы K (kill). Файлы упорядочиваются в порядке возрастания номера и выполняются с параметром stop. Потом те же действия выполняются с файлами на букву S (start), которые запускаются с параметром start. Вот в общем и вся процедура перехода на определенный уровень.

Можно предположить, что в каталоге /etc/rc0.d/ лежат только файлы, начинающиеся на букву K, поскольку при выключении надо все остановить, а в каталоге /etc/rc1.d/ будет один файл на буку S для запуска консоли администратора.

Для простоты программирования есть отдельный каталог /etc/init.d/, в котором лежат те же самые файлы только без буквы цифр в начале имени. На самом деле, файлы в каталогах уровней это просто символические ссылки на основные файлы. Так /etc/rc3.d/S10apache это ссылка на файл /etc/init.d/apache. Буквы и цифры в названии ссылок нужны для того, чтобы скрипт rc вызвал их в нужном порядке и с нужными аргументами.

В системах, которые построены по такому принципу, чтобы стартовать или остановить какую-либо службу в каталоге /etc/init.d/ надо найти файл который, который ей соответствует, и запустить его с параметром start или stop. Чем не нравится запускать службы именно таким способом - явно вызывая скрипты. Дело в том, что в командной строке linux замечательно работает автодополнение. С его помощью очень быстро можно ввести путь до файла запуска.

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

Программа chkconfig позволяет манипулировать символическими ссылками на соответствующие скрипты. Чтобы посмотреть, что стартует, а что останавливаться на каждом из уровней можно воспользоваться командой ls и выдать список скриптов в соответствующем каталоге, но проще воспользоваться командой chkconfig –list. Программа chkconfig пробегает по всем каталогам rc и выдает список того что стартует, а что останавливается на каждом уровне. Если мы хотим, чтобы при старте системы у нас что-то автоматически стартовала определенная службу мы выполняем chkconfig <имя службы> on и скрипт создает ссылку для запуска в нужном каталоге и с правильным именем. Запуск chkconfig <имя службы> off приводит к удалению ссылки для запуска и созданию ссылки для остановки. Таким образом программа chkconfig позволяет управлять списком служб, которые стартуют в момент старта системы.

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

В стартовых скриптах аргументы start и stop должны обрабатываться обязательно. Кроме того, можно придумать какие-то свои аргументы, которые будут делать что-то полезное.

В большинстве скриптов реализована опция status, которая показывает запущена служба или нет. Когда мы выполняем start, то скрипт после успешного запуска службы получает ее идентификатор PID и записывать его в определенный файл. По команде stop файл удаляется. Обычно такие файлы создаются в каталоге /var/run/. Команда status проверяет есть ли такой файл. Его нет, то сообщает, что служба не запущена. Если файл есть, то она извлекает из него идентификатор процесса и проверяет текущий список процессов. Если этот идентификатор присутствует все запущено, если программа по каким-то причинам поломалась, то статус выдаёт, что была сделана попытка запустить эту службу - файл существует, но сама служба не запущена.

Опция restart последовательно выполняет внутри скрипта две команды – сначала stop, а потом старт. Это совершенно необязательная команда - просто удобная. Наконец, есть службы, которые позволяет на ходу перечитать какие-то конфигурационные файлы. Для них добавляют команду reload, задачей которой является отправка службе сигнала о том, что конфигурация изменилась. Отдельный случай, команды save и load для сохранения конфигурации брандмауэра.

Если администратор системы вместо остановки или старта отдельных службы хочет всю систему перевести на определенный уровень, то этого можно достичь одним из двух способов. Можно вызвать прямо программу /sbin/init. Если ее вызвать с определенным числом в качестве параметра, то она выполнит все инструкцию из файла inittab, для которых прописывал соответствующий уровень. Если запустить, например, /sbin/init 1, то init найдет в своем конфигурационном файле все строчки, в которых есть уровень 1 и выполнит их. В некоторых системах команда shutdown реализована как /sbin/init 0, поскольку нулевой уровень соответствует остановке системы. В последнее время для перехода между уровнями появилась специальная программа под названием telinit, которая является ссылкой на init. Её задача – переслать процессу init сигнал о том, что администратор желает перейти на определенный уровень. telinit q сообщает init о том, что надо перечитать файл inittab. В старых системах это достигалось посылкой сигнала SIGHUP процессу с PID=1 (kill –HUP 1).

Ещё несколько строк в inittab, это запуск терминалов

1:2345:respawn:/sbin/mingetty tty1

Для того, чтобы обеспечить диалоговую доступ к системе, вы inittabе может присутствовать некоторое количество строчек такого рода. 2345 это уровни, на которых надо запускать команду, respawn означает, что программу надо перезапускать в случае завершения. Программа getty – это программа управления терминалом. Традиционно терминал в UNIX называется телетайпом, поскольку первыми терминалами были электрические пишущие машинка. Соответственно, tty это сокращение от телетайпа. Mingetty – программа, которая умеет работать с виртуальными терминалами на персональном компьютере. Она умеет настраивать драйвер терминала, а в качестве параметров получает имя устройства терминала, который надо настроить. В каталоге /dev/ есть файл устройства tty1, который соответствует первому виртуальному терминалу. Если бы у нас был модем и мы хотели бы инициализировать его момент загрузки, то могли бы вызвать getty с параметром ttyS0, который соответствует порту COM1. При инициализации модема можно было бы задать дополнительные параметры: скорость соединения 19200 бод, 7 или 8 бит в байте, четность, количество стоп-битов.

S0:2345:respawn:/sbin/getty ttyS0 19200 8 n 1

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

Текстовые пользовательские сеансы устроены на таких цепочках: сначала init делает свою копию и запускает в ней программу mingetty. Mingetty инициализирует терминал и клавиатуру, а потом запускает в том же процессе программу login. Login выводит на экран приглашения на ввод имени и пароля и, если все прошло успешно то назначает себе привилегии пользователя и в том же процессе, затирая самого себя, запускает интерпретатор пользователя, например, bash. Когда пользователь набирает команду exit, то интерпретатор завершает жизненный путь этого процесса. Когда процесс завершается, init получает об этом сигнал. Init смотрит, что полагается делать, видит действие respawn, снова запускает программу mingetty, которая заново инициализирует терминал и все повторяется. Таким образом каждый сеанс находится внутри одного процесса. Как только мы вышли из сеанса наш процесс закончился и тотчас же запустилась программа, которая почистит за нами терминал и восстановит все настройки по умолчанию.

В файле inittab есть есть ещё одно специальное ключевое слово initdefault - уровень по умолчанию. Если через ядро init получил параметр single, то мы загрузимся на уровень 1. Если через загрузчик ничего не передали, то используется значение по умолчанию. Если после установки графической оболочки оказалось, что наш компьютер слабоват для графики, то можно установит уровень по умолчанию на 3, и после следующей перезагрузки мы попадаем на третий уровень - то есть в текстовый режим. Установили систему без графического режима, потом доустановили все пакеты для x window, поменяли уровень по умолчанию на 5 и после следующей перезагрузки попали сразу в графический режим.

В этой системе скриптов иногда хочется сделать что-то свое, например, при старте удалить все файлы в каталоге /tmp/. Для этого есть отдельный файл под названием /etc/rc.local, который запускается после всех остальных. Это просто скрипт без параметров, в который можно прописать всё, что угодно. Например, на одном из моих роутеров в момент старта системы в этом файле прописываются таблицы маршрутизации. Мне было лень искать где находятся соответствующие стандартные скрипты из дистрибутива и проще оказалось прописать команды в rc.local.

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

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

Когда включается питание, запускается на выполнение загрузочный код, хранящийся на постоянном запоминающем устройстве. Он должен запустить ядро. Ядро опрашивает состояние аппаратных устройств, а затем запускает демон init, идентификатор которого всегда равен 1.

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

Главное - активизировать командную оболочку

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

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

Этапы загрузки

Типичная процедура начальной загрузки состоит из шести отдельных этапов:

• считывание начального загрузчика с главной загрузочной записи;
• обнаружение и конфигурирование устройств;
• создание процессов ядра;
• вмешательство администратора (только в однопользовательском режиме);
• выполнение системных сценариев запуска.

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

Инициализация ядра

Ядро представляет собой программу, и в качестве первой задачи начальной загрузки выполняется запись этой программы в память для последующего выполнения. Имя файлу ядра дает его изготовитель, но по традиции оно называется /unix или /vmunix . В Linux-системах ядро обычно получает путевое имя в виде вариации на тему /boot/ vmlinuz .

В большинстве систем загрузка осуществляется в два этапа. Сначала в память компьютера с диска считывается (с помощью кода, записанного на постоянном запоминающем устройстве) небольшая программа начальной загрузки (именуемая начальным загрузчиком), которая затем выполняет собственно загрузку ядра. Эта процедура совершается вне UNIX-домена и поэтому не стандартизирована среди систем.

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

Конфигурирование аппаратных средств

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

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

Создание процессов ядра

После завершения этапа базовой инициализации ядро создает в области памяти, выделенной для пользовательских программ, несколько «самовыполняющихся» процессов. Это происходит «в обход» стандартного системного механизма fork .

Количество таких процессов зависит от операционной системы, хотя демон init всегда имеет идентификатор процесса (PID ), равный 1. Большинство систем UNIX использует sched в качестве процесса с идентификатором 0.В Linux процесс с идентификатором PID, равным 0, отсутствует. Демон init работает в сопровождении с различными обработчиками памяти и сигналов ядра. Все эти процессы имеют идентификаторы с низкими номерами, а их имена в листингах команды ps заключены в квадратные скобки (например, ). Иногда имена процессов могут содержать в конце символ косой черты и цифру, как, например, . Число указывает процессор, на котором выполняется данный процесс. Эта информация может быть полезна при настройке многопроцессорной системы.

Некоторые наиболее часто встречающиеся процессы ядра в Linux-системах
Процесс Назначение

k journald Записывает обновления журнала на диска
kswapd Выполняет подкачку процессов при недостаточном объеме физической памяти

ksoftirqd Обрабатывает мягкие прерывания, если ими нельзя заняться во время переключения контекста

khubd Выполняет конфигурирование USB-устройств

Для каждой смонтированной файловой системы ext3 или ext4 существует один процесс kjoumald.

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

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

После создания этих процессов ядро больше не принимает участия в процедуре начальной загрузки системы. К этому моменту, однако, еще не создан ни один из процессов, управляющих базовыми операциями (например, регистрацией пользователей в системе), и большинство демонов не запущено. Обо всем этом позаботится (в некоторых случаях косвенно) демон init.

Действия оператора (только в режиме восстановления)

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

В однопользовательском режиме команды выполняются почти так же, как и в полностью загруженной системе. Однако иногда монтируется только корневой раздел. Для того чтобы можно было использовать программы, находящиеся вне каталогов /bin, /sbin или /etc, необходимо вручную смонтировать остальные файловые системы.

Во многих однопользовательских средах корневой каталог файловой системы монтируется в режиме только для чтения. Если каталог /etc является частью корневой файловой системы (обычная ситуация), редактирование многих файлов конфигурации будет невозможно. Чтобы выйти из положения, придется начать однопользовательский сеанс с повторного монтирования каталога / в режиме чтения/записи. Нужное действие в Linux-системах выполняет следующая команда.

# mount -о rw,remount /

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

В системе Red Hat загрузка в однопользовательском режиме выполняется несколько активнее, нежели обычно. До того момента, когда на экран будет выведено приглашение интерпретатора команд, этот дистрибутив попытается смонтировать все локальные файловые системы. Хотя на первый взгляд такой подход кажется удобным, но при использовании недостаточно продуманной файловой системы он может порождать проблемы.

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

Когда интерпретатор команд однопользовательского режима завершит свою работу, система продолжит загрузку в нормальном режиме.

Выполнение сценариев запуска системы

В тот момент, когда система сможет выполнять сценарии запуска, ее уже можно назвать UNIX. Это еще не полностью загруженная система, но «загадочных» этапов процесса загрузки больше не осталось. Файлы сценариев представляют собой обычные командные файлы, которые выбираются и запускаются демоном init по сложному, но, в общем-то, понятному алгоритму.

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

Завершение процесса загрузки

После выполнения сценариев инициализации система полностью готова к работе. Такие системные демоны, как DNS- и SMTP-серверы, принимают и обслуживают подключения. Не забывайте о том, что демон init продолжает играть важную роль даже по завершении начальной загрузки.

У демона init есть один однопользовательский и несколько многопользовательских «уровней выполнения», определяющих, какие ресурсы системы будут доступны пользователю.

Для выбора и запуска операционной системы во время загрузки компьютера используется специализированная программа - загрузчик. Самый популярный загрузчик - Grub. При установке нескольких операционных систем, например, Linux поверх Windows, в меню загрузчика первой будет последняя установленная ОС.

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

Grub Customizer

Grub Customizer - это программа, позволяющая настраивать различные параметры загрузчика Grub. В том числе и положение и очередность пунктов загрузки. Установить программу можно из официальных репозиториев. Например, в Ubuntu нужно использовать ppa:

sudo add-apt-repository ppa:danielrichter2007/grub-customizer
$ sudo apt-get update
$ sudo apt-get install grub-customizer

Для запуска программы откройте терминал (Ctrl+Alt+T) и наберите grub-customizer:

Для работы программы необходимы права root, в некоторых системах возможно придется использовать такую команду:

gksu grub-customizer

Также программу можно запустить из главного меню. Главное окно выглядит вот так:

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

В меню выберите пункт Переместить вверх . Это действие нужно будет повторить несколько раз, пока Windows не будет первой в списке. Теперь будет выполняться загрузка windows по умолчанию grub.

Если потом вы захотите опустить Windows обратно вниз, есть обратное действие - Переместить вниз .

Для сохранения настроек просто нажмите кнопку Сохранить. Готово. Можете перезагружать компьютер и смотреть что получилось.

Но я хочу затронуть еще пару настроек, которые могут быть полезны. Вместо того чтобы делать загрузку Windows первой в Grub, можно изменить пункт запускаемый по умолчанию. Перейдите на вкладку Основные настройки :

Здесь для выбора пункта по умолчанию используемого по умолчанию есть список Задействовать :

Кроме того, можно загружать по умолчанию последнюю загруженную ОС, для этого есть галочка:

Изменение порядка загрузки Grub через терминал

Как я и обещал, теперь рассмотрим как сделать загрузку WIndows первой в Grub с помощью конфигурационных файлов. Конфигурация Grub находится в файле /boot/grub/grub.cfg.

gksu gedit /boot/grub/grub.cfg

Как правило, строки меню выглядят вот так:

menuentry имя_пункта --опции {
...

Например пункт Windows:

menuentry "Windows 8 (loader) (on /dev/sda1)" --class windows --class os $menuentry_id_option "osprob
er-chain-FC324E26324DE66C" {
....

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

Аналогично тому как мы настраивали пункт, загружаемый по умолчанию в Grub Customizer, это можно сделать и в терминале.

Откройте файл /etc/default/grub.

gksu gedit /etc/default/grub

Здесь нас интересует строчка:

Замените 0, на нужный пункт для загрузки, также вместо цифры можно указать имя пункта, например:

GRUB_DEFAULT="Windows 8 (loader) (on /dev/sda1)"

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

sudo grep menuentry /boot/grub/grub.cfg

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

GRUB_SAVEDEFAULT=true

А в GRUB_DEFAULT укажите saved:

GRUB_DEFAULT=saved

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

Не во всех системах работает такой вариант, поэтому можно использовать другую команду:

grub2-mkconfig -o /boot/grub/grub.cfg

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

Похожие записи: