Наши партнеры

UnixForum
Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

На главную -> MyLDP -> Тематический каталог -> Процесс начальной загрузки системы

Сказание о Линуксе: загрузчик, initrd и Sys V

Оригинал: The Linux Saga: boot loader, initrd & Sys V
Автор: Keyto
Дата: 22 июля 2008 г.
Перевод: Александр Фарутин foefoe@mail.ru
Дата перевода: 31 января 2009 г.

Linux постепенно заполнял память. Загрузчик извлекал все новые и новые килобайты кода. Ни одной мысли, ни одной эмоции. Да и каких эмоций, по правде говоря, можно ждать от загрузчика?.. Бит за битом, байт за байтом входили в память обрывки кода, сотворенные в результате долгих лет и общих усилий множества мудрых народов. Они душа Системы. Сейчас код загружается, кусок за куском, до последнего бита. Загрузчик бросает взгляд на своё чадо: "Скоро вновь настанет твоё время. Жди", - говорит он и начинает загружать образ initrd. Как и прежде, он трудится не покладая рук. Когда наконец загружены все основные сведения, он передает свои полномочия ядру, отступая в тень. Ядро оживает. Без промедления, без жалоб. Оно внезапно приходит в движение, выглядя так, как будто проработало уже много часов. А затем... наступает тьма. Сумасшедший программист с невменяемой улыбкой нажал кнопку "Reset": "Все работает, как запланировано. Но... что же будет дальше?..", - подумал он. У программиста поехала крыша, но, если не принимать это во внимание, он был гением. Он не набрасывал план перед работой, просто садился и писал код. И сейчас у него было на выбор по меньшей мере три возможности. По меньшей мере.

Данная статья является продолжением статьи "The Linux Saga: Preface" ("Сказание о Линуксе: Предисловие")

Глава 1. Начало: загрузчик.

Как выглядит загрузка операционной системы? Этот вопрос редко приходит в голову обычному пользователю ПК. Он просто нажимает кнопку "Power" и идет на кухню сделать себе кофе, а когда возвращается, тут уже для него подготовлено поле, в которое можно ввести пароль. Однако иногда в голове несколько более увлеченного компьютерами энтузиаста рождается вопрос: "А как же это на самом деле работает?" В чём мы все можем быть твердо уверены, так это в том, что чёрная магия в этом процессе не задействована. Так как же это происходит? На самом деле, все просто: компьютер выполняет серию команд, организованных по определенной логике, по шаблону. Но┘ откуда он "знает", какие команды и когда выполнять? В конце концов, Система - это не один большой исполняемый файл. Их десятки, если не сотни. Так как же она с ними справляется?

Ну прежде всего следует произвести некоторые действия, характер которых не зависит от типа программ, которые мы хотим запустить в системе и от того, каким образом мы хотим запустить их. Мы уже установили, что питание включено, кофе остывает и с "железом" всё в порядке. Первое приложение, которому выпадает честь выполнить заготовленные команды - это загрузчик (также известный как менеджер загрузки). На этом уровне мы пока еще не можем говорить об операционной системе. У нас есть только программа загрузки, которая, будучи единожды запущенной, ответственна за то, чтобы "поднять" ядро системы из указанного местоположения, записанного в файле конфигурации, и загрузить его в память. Не правда ли, все довольно просто? Но у загрузчика есть ещё одно задание: он должен загрузить образ initrd. Теперь о том, что это за зверь.

Глава 2. Initrd.

Название "initrd" - это аббревиатура для "Initial RAM disk" ("диск в оперативной памяти для начальной инициализации"). Это файл, который заключает в себе образ файловой системы. Идея заключается в следующем: электронный диск (RAM disk, то есть тщательно выбранный участок памяти, который остальные видят просто как еще одно устройство для хранения информации; он может быть описан как виртуальный жесткий диск) создается в памяти компьютера. Его содержимое хранится в файле initrd. Сам собой напрашивается вопрос: почему все происходит именно так? Почему мы не можем просто напрямую использовать жесткий диск? Ну, мы могли бы, конечно, но виртуальный диск обладает неоспоримыми преимуществами. В первую очередь, его использование даёт нам гарантию, что у нас будет дееспособная файловая система в независимости от того, удастся нам подключить какой-либо невиртуальный диск или нет. Более того, давайте представим, что мы являемся счастливыми обладателями нового сверхсовременного "Ultra-SAS-SATA X"-устройства (такие будут в широком употреблении через 55 лет, но у нам уже предоставили для тестирования предварительную версию, и не спрашивайте, как нам удалось достать ее). В настоящий момент ядро Linux не имеет ни малейшего представления о том, как монтировать такой диск. Помните и о том, что монолитные ядра, такие, как Linux, всецело ответственны за управление оборудованием. Если же ядро "само по себе" не знает, как управлять некоторым оборудованием, оно, как нетрудно догадаться, имеет модуль для работы с ним. А где находится этот модуль? Конечно же, на жестком диске. И здесь замыкается порочный круг, потому что этот диск и является тем оборудованием, к которому мы хотели получить доступ. Неужели все так плохо? Не совсем. Мы можем загрузить модуль благодаря "патенту" initrd. Встроенная в образ initrd файловая система имеет модуль как раз для этого жесткого диска, так что все должно работать. Великолепно. Теперь Вы, вероятно, собираетесь спросить что-нибудь вроде: "Почему это ядро не может получить доступ к этому гребаному модулю, а менеджер загрузки - без проблем?". Менеджер загрузки и операционная система - это два разных мира. Когда работает менеджер загрузки, операционная система неактивна, и наоборот. Так что не следует их сравнивать. Помимо того, где это я сказал, что менеджер загрузки должен брать образ ядра с того же самого диска, на котором находится целевая файловая система? Несколько лет назад у меня был компьютер, оборудованный диском SATA с установленной ОС Red Hat 8.0. Корневой каталог ("/") был расположен на диске SATA, который ядро "не видело". Чтобы устранить это "небольшое недоразумение", само ядро вместе со специально подготовленным образом initrd было расположено на "обычном" старом IDE-диске. Есть, конечно, и ряд других примеров. Ветераны могут припомнить, как они ставили Slackware в старые добрые времена. Им приходилось создавать два образа дискет: один для загрузчика и образа и один для образа initrd (называемый rootdisk). Ключевым резидентом последнего была установочная программа, которая инсталлировала старую добрую Slackware. Но давайте временно прекратим теоретические измышления и вместо этого проведем следующий эксперимент.

Эксперимент 1: Как легче всего использовать некоторые из дистрибутивов на LiveCD. Давайте возьмём, к примеру, SLAX 6.0 и сделаем следующее:

  1. Запустите систему с CD.
  2. Создайте директорию /initr d.
  3. Найдите файл /mnt/live/mnt/hdc/boot/initrd.gz и распакуйте его содержимое в только что созданную директорию /initrd. Для этой цели мы можем воспользоваться Ark, который доступен в контекстовом меню файла в KDE, или же по старинке сделать все при помощи командной строки.
  4. Создайте новую директорию: /initrd/mount.
  5. Выполните: 
    root@slax: /mount -o loop /initrd/initrd /initrd/mount
  6. В /initrd/mount мы теперь видим "загадочный" образ initrd. Мне бы хотелось обратить ваше внимание на сценарии, которые подробно описал в недавней статье "SLAX"... как он работает?" ("SLAX"... how does it work?")
  7. Конец эксперимента.

Оборвем дискуссию об initrd, с ней или без нее, но мы обладаем полнофункциональной операционной системой. Здесь я основываюсь на том определении, что ОС - это ядро, а все остальное - это приложения. У нас также есть готовая файловая система. Говоря "готовая" я подразумеваю "готовая к использованию", а не обязательно "смонтированная"! Наше ядро требует только того, чтобы была готовая к использованию виртуальная файловая система. Может существовать лишь один пустой корневой каталог, и этого будет достаточно. Монтирование дисков - это совсем другая история. Теперь пришло время запустить систему. Лучше, чтобы процедура эта была полностью автоматической. Нам бы хотелось иметь дееспособную систему, готовую к работе, со всеми традиционными составляющими, как то: графическая оболочка, звук, мышь, сетевое подключение, веб-сервер, программы для общего доступа к файлам в локальной сети и т.д. И здесь начинаются настоящие проблемы, потому что теория и практика во многих случаях - это не одно и то же. Совсем не одно и то же...

Глава 3. Уровни загрузки системы (runlevels).

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

  • То, что пользователи могут запускать несколько приложений?
  • То, что несколько пользователей могут войти в систему на одном ПК?
  • То, что несколько пользователей могут запускать по несколько приложений?

Если мы думаем о многозадачности в таком ключе, мы на самом деле говорим о приложениях, которые, будучи запущены единовременно, являются показателем функциональности системы. Я хотел бы недвусмысленно заявить: Linux - это не Трансформер. Однажды запущенный, он работает так, как скомпилирован. Все остальное производится приложениями, запущенными поверх него. Если мы запускаем на нашей машине некий гипотетический минимальный набор приложений, у нас, конечно, будет возможность запустить множество программ, но только в текстовом режиме и только в том случае, если мы физически находимся в непосредственной близости от машины. Дополнительные предложения включают поддержку наличия нескольких пользователей, другие - поддержку сетевых подключений, третьи позволяют пользователям входить в систему через эти соединения. Небольшое приложение под названием "sshd" позволяет удаленно управлять нашими компьютерами, используя протокол SSH. Другие приложения "организуют" графический интерфейс, звук и т.д. и т.п. Эти наборы приложений, имеющих определенные функции, объединены в так называемые уровни загрузки (runlevels). Установлено, что у нас их восемь, они обозначены цифрами от нуля до шести, и есть еще уровень "S" (или "s"). Также предложена следующая интерпретация этих уровней:

УровеньВыполняется...
S...в процессе загрузки системы. Теоретически, результатом этого уровня должна явиться базовая система с одним пользователем...
0...в процессе выключения.
1...режим одного пользователя. Используется для администрирования системы с правами root'а. Запущен минимальный набор приложений. Нет сетевых подключений, отсутствует графический интерфейс.
2...многопользовательская среда, тестовый режим, подключение либо отсутствует либо обладает ограниченным набором функций.
3...полностью многопользовательский режим. Все еще в текстовом режиме, но с поддержкой сети, звука и разных прочих приятностей.
4...личные настройки. Обычно то же самое, что в режиме 3.
5...то же, что в режиме 3, но с графической оболочкой. Так называемая "полная фукнциональность".
6...во время перезагрузки ситемы.

Таблица 1. Уровни загрузки ОС.


Slackware, уровень загрузки 3

Как я уже писал прежде, "так бывает", и именно так это выглядит, например, в Red Hat или Fedora, но нетрудно понять, что из этого "правила" существует целая кипа исключений. Например:

Debian - режим по умолчанию - 2, многопользовательский режим, где работает сеть, графическая оболочка, звук и множество других технических приятностей. Уровни 3-5 ничего не значат или, можно сказать, являются тем же самым вторым уровнем.

Ubuntu - то же самое. Конечно, он основан на Debian.

Slackware - режимы 2 и 4 не используются, но устроены как уровень 3. Еще более "забавным" является то, какой уровень является уровнем по умолчанию в определенном дистрибутиве. Это:

  • Debian / Ubuntu - уровень 2,
  • Slackware - уровень 3, (который, заметьте, менее функционален, чем чем уровень 2 Debian),,
  • Gentoo - уровень 3,,
  • Red Hat / Fedora - уровень 3 или 5,,
  • SUSE / openSUSE - уровень 5,

Slackware, уровень загрузки S

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

# runlevel

если вы вошли как root. А если как простой смертный, то:

$ who -r

И мы возвращаемся к вопросу о загрузке системы...

Глава 4. Init.

Первой исполняемой программой в готовом к работе окружении является обычно программа init. Эта программа расположена в директории /sbin, ее файлом конфигурации является /etc/inittab. В Linux программа init является ключевой. Почему? Это "родоначальник всех процессов" (выписано из руководства). Более подробно об этом процессе мы расскажем во второй части "Сказания". Сейчас же достаточно будет написать, что в файле конфигурации этой программы есть крайне важная для загрузки строчка. Ее пример (из Debian):

si::sysinit:/etc/init.d/rcS

Указанный файл будет исполнен в процессе загрузки. Этот файл устанавливает, какие приложения будут работать во время загрузки, то есть на уровне S. Это довольно важно, потому что впоследствии уровни могут меняться. Скажем, root запускает команду init 1 (в командной строке), чтобы придать себе функции администратора. Он исполняет функции администратора, а затем выполняет init 5, и тут в дело вновь вступаем мы, простые пользователи. Во время переключения уровней загрузки исполняются определенные сценарии, которые должным образом настраивают окружение. Но существуют программы, запускать которые требуется всего лишь один раз. Например, swap partition выполняется при загрузке компьютера и работает дальше, несмотря на то, какой уровень загрузки мы установили, разве не так? Было бы абсолютно неразумно подключать и отключать разделы каждый раз, когда мы меняем уровень загрузки. В этом просто нет смысла. И вновь возвращаясь к программе init: /etc/inittab содержит также еще одну интересную строку:

id:2:initdefault

Это уровень загрузки системы по умолчанию. Если для Вашей, к примеру, Slackware установлен третий уровень, мы можем, изменяя эту строку, установить по умолчанию "графическую" загрузку. Но, конечно же, Вы должны знать, что в Slackware многопользовательским уровнем с графической оболочкой является 4-й, а не, например, 5-й, как в Red Hat. Строка, приведённая в качестве примера, была взята из Debian, а в Debian 2 означает "полный набор функций". На самом деле, /etc/inittab содержит только интересные строки: что система должна делать после нажатия ctrl+alt+del, после перебоя в питании, сколько может быть доступно виртуальных консолей...

Глава 5. Необычайно короткая глава о том, какие программы запускаются.

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

  • alsa - запускает программы, позволяющие слушать музыку,
  • apache2 - запускает веб-сервер,
  • gdm - включает графический менеджер входа в систему,
  • samba - предоставляет возможность сделать доступным содержимое локальной сети,
  • urandom - сценарий, который (если выполнять его во время загрузки и перезагрузки системы и выключения компьютера) "запоминает" данные.

Но давайте не углубляться в скучные подробности: включение того или иного уровня загрузки системы - это всего лишь выполнение сценариев в определенной последовательности. Обычно из директории /etc/init. d, но необязательно.

Программист все думал и думал... Он знал общепринятые способы запуска и закрытия (да: не забудьте и о закрытии, потому что иногда нам приходится перезагружать компьютер, а иногда даже и выключать его) приложений во время переключения уровней загрузки системы. Но ни один из них не устраивал его. В стиле BSD? За этим сложно проследить. Может, в стиле SysV? Может, попробовать один из менее популярных способов? В следующий миг он понял: "Да! Ну конечно! Теперь все заработает быстрее и лучше!" - воскликнул он и немедленно приступил к работе. Если бы программисты, работающие с системами вроде Solaris, Debian или Slackware, увидели на экране код, набранный Сумасшедшим, у них бы глаза полезли на лоб от изумления, они бы позеленели от зависти. Если бы они поняли хоть часть того, что увидели.

Глава 6. В стиле BSD.

Какой способ выполнения сценариев приложений, требующихся во время работы на определенном уровне загрузки системы является наиболее простым? Это легко: Вы должны написать соответствующий скрипт. Такой метод применяется в системах семейства BSD и в некоторых дистрибутивах Linux, таких, как, например, Slackware или CRUX. В директории /etc/rc. d есть сценарии rc.S, rc.0, rc.4, rc.6 и т.д. Среди этих скриптов есть изящные сценарии, выполняющие запуск соответствующих программ, и даже сценарии автономных приложений. Что значит здесь слово "изящные"? Ну вот вам пример:

if [ -x /usr/bin/gdm ]; then
    exec /usr/bin/gdm -nodeamon
fi

Это значит примерно следующее: "Если есть какой-либо графический GNU-менеджер входа в систему, запусти его". "Изящный" применяется по отношению к управлению или информации, если то, чего мы ждем от системы, вообще возможно. На самом деле, здесь действует простое правило: мы пишем сценарий, который ведет машину к начальному уровню загрузки ("S"), а затем и к желаемому: например, 4-му, который в случае Slackware означает полный набор функций. Подобным же образом мы создаем скрипт для запуска приложений, которые предоставляют возможности уровню root, скрипт, для перезапуска системы и т.п. Можно ли сделать это по-другому?

Глава 7. В стиле SysV

Точно так же, как и раньше, когда мы приводили в качестве примера Slackware, теперь мы хотим поиздеваться над ее сильно младшим братом: дистрибутивом Debian. Это канонический (это только прилагательное, а не название производителя) пример данного стиля настройки уровня загрузки системы, который, кстати, является доминирующим в Linux. В этом случае все гораздо интереснее, а на первый взгляд - так прямо волшебство. Но давайте же приступим.

Эксперимент 2. Давайте создадим на нашем компьютере директорию. Наш эксперимент может быть успешно проведен и в Slackware: мы будем использовать стандартные команды. Давайте назовем нашу директорию "scripts".

keyto@server:~/$ mkdir ~/scripts
keyto@server:~/$ cd ~/scripts

Отлично. Теперь давайте создадим в этой директории три файла, как описано ниже:

keyto@server:~/scripts$ echo '#!/bin/bash' > 01_script
keyto@server:~/scripts$ echo 'echo Executes script 01' >> 01_script

Мы создадим остальные два файла таким же образом, только все последовательности символов "01" заменим на "02" и "03". Конечно же, Вы можете создать хоть сотню таких, если захотите. Для того, чтобы "вспомнить" последнюю команду и изменить ее, я предлагаю использовать клавишу "стрелка вверх". Следующим шагом будет придание нашим псевдосценариям свойства исполняемости:

keyto@server:~/scripts$ chmod 700 *script

А теперь самое интересное. Как нам уже известно, мы можем выполнить любой сценарий, например:

keyto@server:~/scripts$ ./01_script
Executes script 01

Вы можете также выполнить сразу несколько, например:

keyto@server:~/scripts$ ./01_script; ./02_script
Executes script 01
Executes script 02

Пока что ничего нового. Но что, если мы хотим выполнить все сценарии, а их там не 5, а 105? Ну, или что, если другой пользователь нашего ПК, Боб Кодер, добавил еще два сценария? (Что, конечно, отнюдь не значит, что он плохой программист. Или все-таки плохой?) Так что же делать? Выписывать имена всех файлов, потом напряженно "вбивать" их в командную строку? Конечно же, нет. Система содержит определенную команду, которой мы прямо сейчас и воспользуемся:

keyto@server:~/scripts$ run-parts .
Executes script 01
Executes script 02
Executes script 03

Интересно? Не забывайте ставить точку в конце имени команды. Хотелось бы напомнить вам, что точка не означает конец предложения. Это всего лишь имя текущей директории. Подобным образом Debian проводит выполнение загрузочных сценариев. Проверьте, пожалуйста, следующие директории. Для начала - /etc/rcS.d. эти сценарии выполняются при старте системы. Пример из моего компьютера (фрагмент):

keyto@server:~/scripts$ ls -1 /etc/rcS.d

S02mountvirtfs
S04udev
S05bootlogd
S10checkroot

И так далее, и тому подобное... Как вы видите, имена начинаются с последовательности: "S" плюс номер. Дело в том, что программа "запуска-по-частям" ("run-parts") выполняет сценарии в алфавитном порядке. Если Вы хотите, чтобы тот или иной сценарий выполнялся раньше либо позже, Вам нужно лишь сменить его номер. Например, с "S04udev" на "S76udev". (Но не делайте этого! Это всего лишь возможность, из чего не следует, что это будет хорошо для системы!) Похожую ситуацию можно наблюдать в директориях от /etc/rc0.d до /etc/rc6.d. Важно также то, что все проанализированное здесь содержимое директорий является символьными ссылками, созданными командой "ln -s". Нет ни смысла, ни необходимости в том, чтобы копировать указанные файлы. "Оригиналы" тихо-смирно сидят в директории /etc/init.d, и их именам не предшествуют никакие числа. Иными словами, директория /etc/init.d содержит всю совокупность загрузочных сценариев. Если мы хотим выполнить, например, чтобы сценарий "gdm" (запуск менеджера входа в систему, сходного с GNOME, в графической оболочке) автоматически выполнялся при старте системы, мы выполняем следующую команду:

root@server:/ # ln -s /etc/init.d /etc/rc2.d/S99gdm

И теперь о самом графическом менеджере входа в систему. Благодаря наличию номеров в именах сценариев Вы можете достичь эффекта, сходного с тем, что мы наблюдаем в MS Windows©, когда система на самом деле еще загружает требуемые приложения, но пользователь уже видит экран входа. Вам просто нужно передвинуть запуск программы gdm на несколько более раннее время. Но есть ли в этом какой-либо смысл? Решение этого вопроса я оставляю на суд читателя. Сценарий также может быть выполнен при помощи следующей команды:

for i in /etc/rcS.d/S??*
do
    (...)
done

Что значит: для каждого файла, расположенного в директории /etc/rcS.d/ и обладающего именем, подходящим под шаблон "S, плюс два символа, плюс еще что угодно", выполнить... Debian использует этот метод наравне с программой "запуска-по-частям". Будет ли используемый в Debian способ запуска приложений для нужд уровня загрузки системы лучше того, который используется в Slackware? Это непростой вопрос. Как я уже упоминал ранее, в Slackware Вам нужно напряженно печатать в сто втором, сто третьем, сто четвертом скрипте из тех, что Вам нужны, а в Debian все это как будто проще, но с другой стороны... Когда Вы редактируете файлы, которыми хотите воспользоваться, Вы теоретически больше осведомлены о том, что случится с вашей системой, а в сценариях Slackware вы можете писать собственные комментарии. Однако для Debian и его "семьи" существуют специальные программы: update-rc.d (запускается в консоли) или KsysV (это часть среды KDE), которые делают проще управление символьными ссылками на сценарии для определенных уровней загрузки системы.


KSysV в Debian

Конечно, можно применять различные методы.

Глава 8. GoboLinux.

GoboLinux - нечто совсем другое. Условимся, что это факт, а факты мы не оспариваем. Если он отличен от других дистрибутивов, то и запускаться и прекращать работу стандартным образом он также не может. Он в этом плане больше напоминает BSD, но со своими особенностями. В Gobo использованы сценарии, которые содержат в себе сложную процедуру загрузки и не менее сложную процедуру выхода из системы. В Slackware Вам приходилось выполнять несколько сценариев (например, два), таких, как rc.S и rc.4 для загрузки в "полном" режиме (с графической оболочкой). А в Gobo сценарий загрузки (BootUp, размещённый в директории /System/Settings/BootScripts) содержит все шаги по загрузке системы. От начала до конца. Есть также похожий сценарий Shutdown. Думаю, вы сами в силах догадаться, для чего он нужен (тоже мне - ребус!)

Около полуночи зазвонил телефон. Гуру несколько лениво убавил громкость и поднял трубку. "Это Мичук. У нас проблема", - услышал он. Через мгновение он сухо спросил: "В чем дело?" - "Keyto получил доступ к исходникам системы Сумасшедшего программиста. Он украл их, или что-то вроде того... Он пытался обработать эти сведения для своей статьи, но не выдержал сложности кода и сломался под давлением огромного количества информации", - "О чем это ты!?" - "Он не смог, Гуру", - "Он сошел с ума", - "О Боже! Ты видел этот код?" - "Конечно, нет". "И что теперь? Надо что-то предпринять", - опечалился Гуру, - "Я еще не полностью уверен, из-за психического ли это состояния Keyto, или это просто последствие серьезных проблем с пониманием кода Безумца". "Окей, хорошо, я встречусь кое с кем. Психиатр и Линус Торвальдс с Ричардом Столлманом уже в пути..."

Post scriptum:

  • Во-первых: про диск "Ultra-SAS-SATA X" - это, конечно, шутка. Их выпустят не через 55, а через 57 лет.
  • Во-вторых: данная статья описывает процесс загрузки UNIX-систем. Загрузка Windows-систем будет описана на соответствующем сайте, когда он наконец откроется.
  • В-третьих: продолжение следует. В следующей статье этой серии я расскажу вам что-нибудь о директории /proc и о многом другом, так что не пропустите...

Подробнее узнать о процессе загрузки вы можете в статье "Исследуем процесс загрузки Linux" и других статьях раздела "Настройка процедур загрузки системы" нашей Библиотеки.