Особливості завантажувача Linux

 

Під час завантаження Linux використовують двоетапний завантажувач. Є кілька програмних продуктів, що реалізують такі завантажувачі, найвідоміший із них lilo (від linux loader). Він може бути встановлений як у MBR (замінивши там код, що завантажує перший сектор активного розділу), так і у завантажувальному секторі якогось (звичайно активного) розділу диска. Другий підхід є безпечні­шим за умов, коли на комп'ютері встановлено кілька ОС у режимі мультизаван-таження, оскільки деякі ОС можуть перезаписувати MBR за своєю ініціативою.

Перша частина І і lo, записана у завантажувальний сектор або MBR, під час свого виконання готує пам'ять і завантажує в неї другу частину. Та зчитує із дис­ка двійкове відображення карти наявних на комп'ютері варіантів завантаження (різні ОС, різні установки Linux тощо) і пропонує користувачу вибрати один із них (за допомогою підказки «LILO boot>). Зазначимо, що вихідну версію карти варіантів завантаження створює користувач (системний адміністратор) у вигляді звичайного текстового файла /etc/lilo.conf. Після кожної зміни карти необхідно об­новлювати її відображення на диску, використовуване завантажувачем. Для цього виконують команду (із правами root):

# lilo

 

Після вибору користувачем одного із варіантів завантаження поведінка заван­тажувача залежить від характеру файлової системи для розділу. У разі вибору розділу з іншою ОС (наприклад, Windows) зчитують у пам'ять і виконують за­вантажувальний сектор цього розділу (тому за допомогою Шо можна завантажи­ти будь-яку ОС), якщо ж вибрано розділ із Linux, у пам'ять завантажують ядро системи (його адреса на диску міститься в карті варіантів завантаження). Після завантаження у пам'яті з'являється стиснуте ядро системи і придатний для вико­нання код двох функцій завантаження: setupO і startup_32(). Код завантажувача переходить до виконання функції setupO, починаючи ініціалізацію ядра.

 

Ініціалізація ядра

Перший етап ініціалізації ядра відбувається у реальному режимі процесора. Пе­реважно здійснюється ініціалізація апаратних пристроїв (Linux не довіряє цього BIOS). Функція setupO визначає фізичний обсяг пам'яті у системі, ініціалізує клавіатуру, відеокарту, контролер жорсткого диска, деякі інші пристрої, переви-значає таблицю переривань, переводить процесор у захищений режим і передає управління функції startup_32(), код якої також перебуває поза стиснутим ядром.

Функція startup_32() задає сегментні регістри і стек, розпаковує образ ядра і розташовує його у пам'яті. Далі виконують код розпакованого ядра, при цьому керування спочатку дістає функція, яку також називають startup_32(). Вона фор­мує середовище виконання для першого потоку ядра Linux («процес 0»), створює його стек (із цього моменту вважають, що він є), вмикає підтримку сторінкової організації пам'яті, задає початкові (порожні) оброблювачі переривань, визначає модель процесора і переходить до виконання функції start kernel ().

Функцію Start kernel () виконують у межах потоку ядра «процес 0», завер­шуючи ініціалізацію ядра. Вона доводить до робочого стану практично кожен компонент ядра, зокрема:

♦ ініціалізує таблиці сторінок і всі дескриптори сторінок;

♦ остаточно ініціалізує таблицю переривань;

♦ ініціалізує кусковий розподілювач пам'яті;

♦ встановлює системні дату і час;

♦ виконує код ініціалізації драйверів пристроїв;

♦ робить доступною кореневу файлову систему (де розташовані файли, необ­хідні для завантаження системи).

 

Крім того, за допомогою функції kernel_thread() створюють потік ініціалізації («процес 1»), що виконує код функції і пі t (). Цей потік створює інші потоки ядра і виконує програму /sbin/init, перетворюючись у перший у системі процес кори­стувача і nit. Зазначимо, що для коректного завантаження і nit повинна бути дос­тупна коренева файлова система із найважливішими розділюваними бібліотека­ми (каталог /lib має бути на тому самому розділі, що і кореневий каталог /).

На перетворенні цього потоку в і nit ініціалізація ядра завершена, функція start kernel () переходить у нескінченний цикл простою (idle loop), не займаючи ресурсів процесора. Подальша ініціалізація системи відбувається під час вико­нання і nit.

 

 

Виконання процесу init

 

Процес init є предком усіх інших процесів у системі. Після запуску він читає свій конфігураційний файл /etc/inittab і запускає процеси, визначені в ньому. Набір процесів, які запускаються, залежить від дистрибутива Linux. Приклад виконан­ня і пі t під час завантаження системи Red Hat Linux наведено нижче.

Файл /etc/inittab визначає кілька рівнів роботи (runlevels). Кожен із них - це особлива програмна конфігурація системи, у якій може існувати тільки певна група процесів. Рівень роботи визначає режим функціонування ОС (однокори-стувацький, багатокористувацький, перезавантаження тощо). Стандартними рів­нями роботи є рівні з 0 по 6. Ось найважливіші з них:

 

♦ 0 — завершення роботи (shutdown);

♦ 1- однокористувацький режим (single user mode) - у ньому не дозволене ви­конання деяких фонових процесів, доступ до системи через мережу тощо;

♦ 3 — стандартний багатокористувацький режим (звичайно цей рівень задають за замовчуванням);

♦ 6 — перезавантаження (reboot).

 

Для деяких рівнів задано символьні синоніми (наприклад, для рівня 1 синоні­мом є рівень S). У файлі /etc/inittab визначено різні командні файли (із програма­ми, написаними мовою командного інтерпретатора, далі їх називатимемо скрип-тами), які повинні виконуватися для різних рівнів виконання.

Синтаксис рядка /etc/inittab такий:

 

і дентифі катор:рі вень_роботи:ді я:програми

 

Перший скрипт, який запускає init, визначений у рядку /etc/inittab із дією, за­даною ключовим словом sysinit. Точне його ім'я залежить від поставки Linux, у Red Hat це /etc/rc.d/rc.sysinit. Його називають також стартовим скриптом. Ось відповідний рядок /etc/inittab:

 

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

 

Стартовий скрипт налаштовує базові системні сервіси, зокрема:

♦ час від часу перевіряє диски на помилки командою fsck;

♦ завантажує модулі ядра для драйверів пристроїв, які не повинні бути заванта­жені раніше;

♦ ініціалізує ділянку підкачування командою swapon;

♦ монтує файлові системи відповідно до файла /etc/fstab.

 

У файлі /etc/fstab задано, яка файлова система має бути змонтована у який ка­талог кореневої файлової системи. Кожний рядок цього файла відповідає одній операції монтування і містить інформацію про тип файлової системи, розділ, де вона розташована, точку монтування тощо.

Крім стартового скрипта, у каталозі /etc/red перебувають кілька інших скриптів:

♦ /etc/rc.d/rc - викликають у разі зміни рівня виконання; як параметр він при­ймає номер рівня, звичайно запускає всі скрипти, що відповідають рівню (такі скрипти розглянемо трохи пізніше);

♦ /etc/rc.d/rc.local — викликають останнім під час завантаження системи; він міс­тить специфічні для конкретної машини команди (зазвичай не рекомендують поміщати такі команди у стартовий скрипт, оскільки у разі перевстановлення або відновлення системи той файл стирають, а гс.іосаі - ні).

Запуск системних фонових процесів та ініціалізацію системних служб (на­приклад, мережних інтерфейсів) виконують із використанням набору файлів ' підкаталогів у каталозі /etc.

 

У каталозі /etc/rc.d/init.d зберігають набір індивідуальних стартових скриптів, відповідальних за керування різними фоновими процесами і службами. Наприклад, скрипт /etc/rc.d/init.d/httpd відповідає за керування веб-сервером Apache. Кожний стартовий скрипт має обробляти отримані як параметри ключові слова start і stop, запускаючи і зупиняючи відповідний процес.

 

# /etc/rc.d/init.d/httpd start

 

Стартові скрипти не запускаються безпосередньо процесом init під час заванта­ження системи. Для організації такого запуску в /etc/red є набір каталогів (rcO.d... rcö.d), кожен із них містить символічні зв'язки, що вказують на стартові скрипти. У разі переходу на певний рівень виконання і nit запускає скрипт /etc/rc.d/rc, який пе­реглядає всі зв'язки каталогу, що відповідає рівню, і виконує дії відповідно до їх імен.

Кожен зв'язок має деяке ім'я у форматі Кяиім'я або S/гшм'я (де пп - цифри, наприклад S70httpd), яке характеризується такими особливостями.

 

Якщо ім'я починається на S, то на цьому рівні служба має бути запущена (як­що вона не запущена, потрібно виконати відповідний стартовий скрипт із пара­метром start); на К - на цьому рівні служба не повинна бути запущена (якщо вона запущена, її потрібно зупинити, виконавши стартовий скрипт із парамет­ром stop).

Число пп задає номер послідовності, що визначає порядок запуску або зупин­ки служб у разі переходу на рівень. Що більший пп, то пізніше виконається скрипт; важливо, щоб до цього часу вже були запущені всі служби, від яких зале­жить ця. Наприклад, ініціалізацію мережі потрібно виконувати якомога раніше, тому зв'язок, що вказує на скрипт, при цьому може бути такий: S20network. Ім'я зв'язку завершують іменем стартового скрипта, на який він вказує.

Наприклад, коли init переходить на рівень виконання 3, усі зв'язки, що почи­наються на S у каталозі /etc/rc.d/rc3.d, буде запущено в порядку їхніх номерів, і для кожного запуску буде задано параметр start. Після виконання всіх скриптів ви­моги до рівня виконання 3 задовольняться.

В /etc/inittab має бути заданий рівень виконання за замовчуванням, для чого потрібно включити у файл рядок із ключовим словом initdefault. Система завер­шить своє завантаження після переходу на цей рівень. Звичайно, це - рівень 3.

 

id:3:initdefault:

 

Після запуску всіх скриптів для переходу на рівень за замовчуванням init завжди запускає спеціальну програму getty, що відповідає за зв'язок із користу­вачем через консоль і термінали (звичайно створюють кілька таких процесів - по одному на кожну консоль). Є різні реалізації цієї програми, у Linux популярними є agetty і mingetty. Саме getty видає підказку «login:».

Рядок у /etc/inittab, що задає запуск версії getty, має такий вигляд (ключове слово respawn означає, що процес буде перезапущено, якщо він припиниться):

 

1:2345:respawn:/sbi n/mingetty ttyl

 

Після того як користувач ввів своє ім'я, getty викликає програму /bin/login, що запитує пароль (видавши підказку «password:»), перевіряє його та ініціалізує сесію користувача. У більшості випадків це зводиться до запуску для користува­ча копії командного інтерпретатора (звичайно bash) у його домашньому каталозі. У результаті користувач може розпочати роботу із системою.

Процес і nit залишається у пам'яті і після завантаження. Він відповідає за ав­томатичний перезапуск процесів (для цього потрібно прописати програму в /etc/ inittab із дією respawn, як getty); і nit також стає предком для всіх процесів, чий безпосередній предок припинив свою роботу.

Як зазначалося, у разі перезавантаження або зупинки система також перехо­дить на певні рівні виконання, і при цьому виконуються скрипти з /etc/rc.d/init.d через зв'язки в каталогах для цих рівнів (rcO.d для зупинки, rc6.d для перезаванта­ження; такі зв'язки починаються на К). Для того щоб розпочати перезавантажен­ня або зупинити систему, використовують спеціальну програму /sbin/shutdown, доступну лише суперкористувачу root. Консоль Linux також підтримує організа­цію перезавантаження від клавіатури натисканням на Ctrl+Alt+Del.

 

Завантаження Windows ХР

 

Завантаження Windows ХР починають стандартним способом 4- із передавання керування коду завантажувального сектора активного розділу диска. Головне його завдання - визначити місцезнаходження файла ntldr у кореневому каталозі цього розділу, завантажити його в пам'ять і передати керування на його точку входу. Зазначимо, що код завантажувального сектора залежить від того, яка файлова система встановлена для цього розділу: для FAT виконують один варіант, для NTFS - інший.

Файл ntldr можна розглядати як завантажувач другого етапу. Він починає своє виконання у 16-бітному режимі процесора, передусім переводить процесор у захи­щений режим і вмикає підтримку сторінкової організації пам'яті, після цього зчи­тує з кореневого каталогу файл boot.ini і робить його синтаксичний розбір. Ось фрагмент файла boot.ini:

 

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(l)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(l)\WINDOWS="Windows XP"

C:\="Windows 98"

Після тегу [boot loader] задано варіант завантаження за замовчуванням і час, після закінчення якого система автоматично завантажуватиметься відповідно до цього варіанта, після [operating systems] - список можливих варіантів заванта­ження. Для кожного варіанта може бути задано одну із кількох адрес завантаження:

♦ розділ із кореневим каталогом WINDOWS (для завантаження Windows ХР);

♦ літерне позначення тому, на якому перебуває інша ОС;

♦ ім'я файла із зазначенням тому.

 

У разі зазначення літерного імені розділу (як у прикладі) ntldr знаходить на диску файл bootsec.dos (у якому після встановлення Windows ХР зберігають за­вантажувальний сектор DOS або Consumer Windows, якщо поверх нього записа­ний завантажувальний сектор Windows ХР), перемикає процесор у реальний ре­жим і починає виконувати код цього завантажувального сектора.

Якщо задано ім'я файла, ntldr завантажуватиме файл із таким іменем; отже, якщо у файлі зберегти завантажувальний сектор іншої ОС, наприклад, Linux, ntldr зможе завантажити і його, для цього варіант завантаження має такий вигляд:

 

C:\bootsec.lnx="Linux"

 

Далі наведемо випадок завантаження Windows ХР. Зазначимо, що розділ з ус­тановкою Windows ХР у bootini не зобов'язаний збігатися із розділом, з якого від­бувається завантаження, - таких розділів може бути кілька.

 

Коли є один варіант завантаження, система відразу починає завантажуватися, коли їх більше - відображають меню завантаження. Після вибору варіанта із меню ntldr запускає програму ntdetect.com, що в реальному режимі визначає базову кон­фігурацію комп'ютера (подібно до того, як це робила функція setup () для Linux -жодна із сучасних систем не довіряє цей код BIOS). Зібрану інформацію збері­гають у системі, пізніше вона буде збережена в реєстрі. Внизу екрана з'являється текстовий індикатор прогресу. У цій ситуації можна натиснути на F8 і перейти в меню додаткових можливостей завантаження (у безпечному режимі тощо).

Потім ntldr завантажує у пам'ять ntoskrnl.exe (що містить ядро і виконавчу під­систему Windows ХР), bootvid.dll (відеодрайвер за замовчуванням, що відповідає за відображення інформації під час завантаження), hal.dll (рівень абстрагування від устаткування) та основні файли реєстру. Після цього він визначає із реєстру, які драйвери встановлені в режимі запуску під час завантаження (це, наприклад, драйвер жорсткого диска) і завантажує їх (без ініціалізації). Буде завантажено та­кож драйвер кореневої файлової системи. На цьому роль ntldr у завантаженні за­вершується, і він викликає головну функцію в ntoskrnl.exe для продовження завантаження.

Ініціалізація ntoskrnl.exe складається із двох етапів: фаз Oil. Багато підсистем виконавчої системи приймають параметр, який показує, у якій фазі ініціалізації зараз перебуває система.

Під час виконання фази 0 переривання заборонені, на екрані нічого не відобра­жається. Основною метою цього етапу є підготовка початкових структур даних, необхідних для розширеної ініціалізації під час виконання фази 1. Зазначимо, що менеджер процесів на цьому етапі ініціалізується майже повністю, за його допо­могою створюють початковий об'єкт-процес із назвою Idle, процес System і систем­ний потік для виконання ініціалізації фази 1.

Після завершення фази 0 переривання дозволені, і починає виконуватися системний потік. Під час виконання фази 1 керування екраном здійснює відео­драйвер bootvid.dll, що відображає завантажувальний екран і графічний індикатор прогресу на ньому (цей індикатор змінюватиметься упродовж всієї фази 1). Від­бувається остаточна ініціалізація різних підсистем виконавчої системи (менеджера об 'єктів, планувальника, служби безпеки, менеджера віртуальної пам'яті, мене­джера кеша тощо). Під час ініціалізації підсистеми введення-виведення (яка за­ймає до 50 % часу цієї фази) відбувається підготовка необхідних структур даних, ініціалізація драйверів із запуском під час завантаження (boot-start), завантажен­ня та ініціалізація драйверів із системним запуском (system-start). Фаза 1 завер­шується запуском менеджера сесій (smss.exe).

Подальше завантаження виконують три системні процеси, розглянуті у розді­лі 2: менеджер сесій smss.exe, процес реєстрації у системі winlogon.exe і менеджер керування сервісами (SCM, services.exe). Основним завданням менеджера сесій є завантаження та ініціалізація всіх компонентів підсистеми Win32 (як режиму користувача, так і режиму ядра), а також остаточна ініціалізація реєстру і запуск winlogon.exe.

Процес реєстрації у системі запускає менеджер керування сервісами і мене­джер аутентифікації, а також організовує реєстрацію користувачів у системі, як описано у пункті 18.5.2.

Менеджер сервісів (SCM) завантажує та ініціалізує сервіси режиму користу­вача, встановлені в режимі автоматичного завантаження. Цей процес може трива­ти вже після початку інтерактивної роботи користувачів. Після ініціалізації сер­вісів завантаження вважають успішним.

 

Висновки

 

♦ Жодна операційна система не може розпочати роботу без виконання процеду­ри завантаження та ініціалізації. Під час цього процесу спочатку виконується найпростіший завантажувач ОС, що перебуває у фіксованому місці жорстко­го диска, потім він відшукує ядро ОС і завантажує його у пам'ять. Ядро в свою чергу ініціалізує свої внутрішні структури та апаратне забезпечення і передає керування процесам користувача або системним процесам, які завершують процес ініціалізації.

 

♦ Широко розповсюджене двоетапне завантаження, під час якого завантажувач ОС передає керування складнішому завантажувачу другого етапу, який може керувати завантаженням кількох систем, установлених на комп'ютері. Такий завантажувач виконує основні дії щодо взаємодії із користувачем і заванта­ження потрібної системи.

 

Контрольні запитання та завдання

1. Які додаткові можливості адміністрування надають ОС, у яких є підтримка за­вантаження ядра системи з флоппі-диска?

2. Вкажіть переваги встановлення завантажувача системи в MBR порівняно з його встановленням у завантажувальний сектор одного з розділів диска.

3. Комп'ютерна система включає кілька НЖМД, на кожному з яких встановлена своя файлова система. Опишіть, у якій послідовності ці системи повинні бути змонтовані під час завантаження. Чи є необхідність у ході завантаження одер­жувати доступ до диска без використання засобів ядра?

4. Ідентифікатор процесу для init дорівнює одиниці, він менший, ніж у будь-яко­го потоку ядра Linux. У той же час init стає процесом пізніше, ніж будуть створені потоки ядра. Як можна це пояснити?

5. Альтернативним способом завантаження ОС є підхід, реалізований для Linux утилітою loadl in. Ця утиліта виконувалася під керуванням MS-DOS або Windows і завантажувала ядро Linux з файлової системи FAT. Після завантаження ядра в пам'ять подальший процес ішов, як описано в розділі 19.2. Назвіть переваги і недоліки такого підходу.

 

Розділ 20