Завантаження системи

GRUB

LILO

Досистемная завантаження Linux

Не дивлячись на те, що досистемная завантаження не залежить від типу операційної системи, яка починає роботу потім, більшість систем надають власні засоби по її організації. У Linux найбільш популярні підсистеми завантаження LILO (Linux LOader) і GRUB (GRand Unified Bootloader). Обоє ці підсистеми мають текстовий і графічний варіанти інтерфейсу, що надає користувачеві можливість вибрати визначений заздалегідь налагоджений тип завантаження.

Підсистема завантаження LILO використовує і для первинного, і для вторинного завантажувача схему з картою розміщення. Це робить роботу з lilo заняттям, що вимагає підвищеної акуратності, оскільки зміна процедури завантаження не атомарно: спочатку користувач змінює ядро або його модулі, потім - редагує файл /etc/lilo.conf, в якому містяться зведення про усі варіанти завантаження комп'ютера, а потім - запускає команду lilo, яка збирає таблиці розміщення для усіх вказаних ядер і вторинного завантажувача і записує первинний і вторинний завантажувач разом з картами у вказане місце диска. Первинний завантажувач LILO (він називається LI) можна записувати і в MBR, і в початок розділу Linux.

Простий файл lilo.conf може виглядати так:

boot=/dev/hda кулі/boot/map image=/boot/vmlinuz - up

roote/dev/hdal

Приклад 1. Просте налаштування LILO : приклад файлу lilo.conf

Таке налаштування lilo визначає тільки один варіант завантаження : первинний завантажувач записується в початок першого жорсткого диска (строчка boot = /dev/hda), карту розміщення утиліта lilo записує у файл /boot/map, ядро добувається з файлу /boot/vmlinuz - up, а запис root = /dev/hdal вказує ядру, що коренева файлова система знаходиться на першому розділі першого диска.

Тут Linux була встановлена на п'ятий розділ диска, а на першому знаходиться MS - DOS. Окрім завантаження MS - DOS передбачене два варіанти завантаження Linux і ще один - будь-якої операційної системи з дискети. Кожен варіант завантаження помічений рядком label=варіант. При старті LILO виводить просте віконце, в якому перераховані усі мітки (в даному випадку - "linux-up", "failsafe", "dos" і "floppy"). Користувач за допомогою "стрілок" вибирає потрібний йому варіант і натискає Enter. При необхідності користувач може вручну дописати декілька параметрів, вони передадуться ядру системи. Якщо користувач нічого не чіпає, то після закінчення тайм-ауту вибирається мітка, вказана в полі default.

Мітки linux - up і failsafe в прикладі використовують одне і те ж ядро (vmlinuz - up), але в другому випадку перенастроюється режим графічної карти і додаються параметри, що відключають підтримку необов'язкових для завантаження апаратних розширень (багатопроцесорність, автоматичне управління електроживленням і тому подібне). Строчку, що стоїть потім append =, користувач міг би ввести і самостійно, це і є параметри ядра. Поле initrd = вказує, в якому файлі знаходиться стартовий віртуальний диск (йому присвячений розділ "Стартовий віртуальний диск і модулі" цієї лекції), а що вселяє деякі побоювання напис "unsafe" (для мітки floppy) означає усього лише, що дискета - знімний пристрій, тому безглуздо під час запуску lilo перевіряти правильність її завантажувального сектора і складати карту.

Нарешті, записи виду other-пристрій говорять про те, що LILO невідомий тип операційної системи, що знаходиться на цьому пристрої, а значить, завантажити ядро неможливо. Зате очікується, що в першому секторі пристрою буде виявлений ще один первинний завантажувач, LILO завантажить його і передасть управління по ланцюжку. Так і завантажується MS - DOS на цій машині: первинний завантажувач береться (по мітці dos) з початку першого розділу першого диска.

Підсистема завантаження GRUB влаштована складніше. Вона також має первинний завантажувач, який записується в перший сектор диска або розділу, і вторинний завантажувач, розташований у файловій системі. Проте карта розміщення в GRUB зазвичай використовується тільки для так званого "полуторного" завантажувача ("stage 1.5") - по суті справи, драйвера однієї певної файлової системи. Процедура завантаження при цьому виглядає так. Первинний завантажувач завантажує полуторний по записаній в нього карті розміщення. Ця карта може бути дуже простою, оскільки зазвичай полуторний завантажувач розміщується безпосередньо після первинного в декількох секторах* підряд, або в іншому спеціально відведеному місці поза файловою системою. Полуторний завантажувач уміє розпізнавати одну файлову систему і знаходити там вторинний вже по імені (зазвичай /boot/grub/stage2). Нарешті, вторинний завантажувач, користуючись можливостями полуторного, читає з файлу /boot/grub/menu. 1st меню, в якому користувач може вибирати варіанти завантаження так само, як і в lilo. Таким чином, оновлення і переналаштування встановленого GRUB не вимагає перерахунку карт розміщення і зміни чогось, окрім файлів в каталозі /boot/grub.

Різниця між lilo.conf тільки в синтаксисі, та ще в тому, що жорсткі диски і розділи на них GRUB іменує по-своєму, у виді (hdno -мер_диска, номер_розділу), причому нумерувати починає з нуля. Мітки ("title") теж нумеруються з нуля, так що запис default 0 означає, що після закінчення тайм-ауту буде завантажена найперша конфігурація (на ім'я "linux-up").

Виявляється, в GRUB не лише параметри, але і самі файли (ядро, стартовий віртуальний диск і тому подібне) розпізнаються і завантажуються в процесі роботи. Замість пунктів меню можна вибрати режим командного рядка, підозріло схожий на bash, в якому можна змусити GRUB завантажити яке-небудь інше, не наказане конфігурацією, ядро, подивитися вміст каталогів файлової системи, розпізнаваної полуторним завантажувачем, і навіть утримуване цих файлів, незважаючи ні на які права доступу : система-то ще не завантажена. Мало того, можна по-своєму перенастроювати завантажувач і записати результати налаштування.

Дії ядра Linux в процесі початкового завантаження

Отже, досистемне завантаження проходить в три етапи.

1. Завантажувач з ПЗП визначає, з яких пристроїв можна вантажитися і, можливо, пропонує користувачеві вибрати одне з них. Він завантажує з вибраного пристрою первинний завантажувач і передає йому управління.

2. Первинний завантажувач визначає (а найчастіше - знає), де знаходиться вторинний завантажувач - велика і досить інтелектуальна програма. Йому це зробити простіше, ніж програмі з ПЗП: по-перше, тому що для кожного пристрою первинний завантажувач свій, а по-друге, тому що його можна легко змінювати при зміні налаштувань завантажуваної системи. У схемі, пропонованій LILO і GRUB, первинний завантажувач не вступає в розмови з користувачем, а негайно завантажує вторинний і передає йому управління.

3. Вторинний завантажувач досить розумний, щоб знати, де знаходиться ядро системи (можливо, не одне), запропонувати користувачеві декілька варіантів завантаження на вибір, і навіть, у разі GRUB, дозволяє задавати власні варіанти завантаження. Його завдання - завантажити в пам'ять ядро і усе необхідне для старту системи (іноді - модулі, іноді - стартовий віртуальний диск), настроїти усе це і передати управління ядру.

Ядро - це і мозок, і серце Linux. Усі дії, які не можна довірити окремій підзадачі (процесу) системи, виконуються ядром. Доступом до оперативної пам'яті, мережі, дисковим і іншим зовнішнім пристроям завідує ядро. Ядро запускає і реєструє процеси, управляє розподілом часу між ними. Ядро реалізує розмежування прав і взагалі визначає політику безпеки, обійти яку, не звертаючись до нього, не можна просто тому, що в Linux більше ніхто не надає подібних послуг.

Ядро працює в спеціальному режимі, так званому "режимі супервізора", що дозволяє йому мати доступ відразу до усієї оперативної пам'яті і апаратної таблиці завдань. Процеси запускаються в "режимі користувача" : кожен жорстко прив'язаний ядром до одного запису таблиці завдань, в якій, в числі інших даних, вказано, до якої саме частини оперативної пам'яті цей процес має доступ. Ядро постійно знаходиться в пам'яті, виконуючи системні виклики - запити від процесів на виконання цих підпрограм.

ядро

Набір підпрограм, використовуваних для організації доступу до ресурсів комп'ютера, для забезпечення запуску і взаємодії процесів, для проведення політики безпеки системи і для інших дій, які можуть виконуватися тільки в режимі повного доступу (т. н. "режимі супервізора").

Функції ядра після того, як йому передано управління, і до того, як воно почне працювати в штатному режимі, виконуючи системні виклики, зводяться до наступного.

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

Потім ядро запускає декілька процесів ядра. Процес ядра - це частина ядра Linux, зареєстрована в таблиці процесів. Такому процесу можна послати сигнал і взагалі користуватися засобами міжпроцесною взаємодії, на нього поширюється політика планувальника завдань, проте ніякому завданню в режимі користувача він не відповідає - це просто ще одна іпостась ядра. Команда ps -ef показує процеси ядра в квадратних дужках, крім того, в Linux прийнято (але не обов'язково), щоб імена таких процесів починалися на "К": [kswapd], [keventd] і тому подібне

Далі ядро підключає (монтує) кореневу файлову систему відповідно до переданих параметрів (у наших прикладах - root = /dev/hda5). Підключення це відбувається в режимі "тільки для читання" (read - only) : якщо цілісність файлової системи порушена, цей режим дозволить, не посилюючи положення, прочитати і запустити утиліту fsck (file system check). Пізніше, в процесі завантаження, коренева файлова система підключиться на запис.

Нарешті, ядро запускає з файлу /sbin/init перший справжній процес. Ідентифікатор процесу (PID) у нього дорівнює одиниці, він - перший в таблиці процесів, навіть не дивлячись на те, що до нього там були зареєстровані процеси ядра. Процес init - дуже старий винахід, він мало не старший за саму історію UNIX, і з давніх пір його ідентифікатор дорівнює 1.

Із запуску init починається завантаження самої системи. За часів молодості Linux і раніше в цьому місці ніяких підводних каменів не спостерігалися. Якщо ядро містило підпрограми для роботи з усіма необхідними пристроями (так звані "драйвери"), воно завантажувалося і запускало init. Якщо ядру бракувало якихось важливих драйверів (наприклад, підтримка дискового масиву, з якого і йшло завантаження) - воно не завантажувалося і не запускало. З положення виходили просто: в ядро прагнули включити якомога більше драйверів. Таке ядро називалося базовим (generic) і мало досить значний розмір. Завантаживши систему з базовим ядром, адміністратор зазвичай збирав заново його: викидав із спеціального файлу-профілю драйвери усіх відсутніх в системі пристроїв, можливо, додавав нові (ті, що не потрібні для завантаження, але потрібні для роботи, наприклад, звукові) і компілював з початкових текстів нове, профільне ядро.

Стартовий віртуальний диск і модулі ядра

Нова сборка ядра у наш час вимагається дуже рідко. По-перше, в Linux підтримується незчисленна кількість різних зовнішніх пристроїв, драйвери яких (особливо схожих, але різних) цілком можуть перешкодити один одному працювати, якщо їх використовувати одночасно. Довелося б збирати безліч різних ядер, без можливості вказати користувачеві, яке з них підходить для його комп'ютера. По-друге, з'ясуванням того, який саме драйвер потрібний знайденому пристрою, займаються зараз спеціальні програми, у розпорядженні яких є цілі бази даних, - ядру таку роботу виконувати незручно, та і немає чого. Це робить процедуру нової сборки ядра майже обов'язковою (поки не завантажено базове ядро, незрозуміло, які драйвери додавати в профільне). А по-третє, нова сборка ядра вимагає дуже високій кваліфікації. Цей процес не можна ні автоматизувати, ні спростити. Утиліта linuxconf, влаштована саме для цього на основі вікон і меню, дає на виході працездатне ядро в трьох випадках: (1) в руках професіонала, (2) при чіткому дотриманні повної інструкції і (3) завдяки випадку.

Зовсім інші часи настали, коли винайшли і активно впровадили в Linux завантажувані модулі ядра. Модуль ядра - це частина ядра Linux, яку можна додавати і видаляти під час роботи системи. Модуль ядра - не процес, він працює в режимі супервізора і в таблиці процесів не реєструється: це набір підпрограм для роботи з певним пристроєм, які додаються до можливостей ядра. При завантаженні в пам'ять модуль компонується з ядром, утворюючи з ним одне ціле. Проглянути список завантажених модулів можна командою 1 smod, а підвантажити модуль в пам'ять, додавши його до ядра, і видалити його звідти - командами insmod і rmmod відповідно.

Змінилося і базове ядро: тепер воно включає тільки пристрої, необхідні для завантаження системи, : головним чином диски і графічну консоль. Інші пристрої визначаться вже самою системою - тоді можна буде і розпізнати екзотичну апаратуру, і модуль для неї підвантажити. Проте повністю перевести драйвери усіх зовнішніх пристроїв в модулі заважає наступне міркування: що, якщо завантаження системи відбувається саме з того пристрою, чий модуль ще не завантажений в ядро, наприклад, з дискового масиву (RAID)? Вторинний завантажувач і ядро можна, недовго думаючи, розмістити на іншому носієві (наприклад, на лазерному диску) або добути з дискового масиву засобами BIOS (карти розміщення дозволяють не звертати уваги на логічну структуру RAID). Але як добути модуль роботи з RAID, той самий, що розпізнає цю логічну структуру?

модуль ядра

Необов'язкова частина ядра, що розширює його функціональність. Модуль можна завантажити в пам'ять або видалити звідти в процесі роботи системи.

Підсистема завантаження GRUB уміє розбиратися у файлових системах і навіть підключати модулі до ядра, проте для того, щоб зробити процес завантаження більш менш універсальним, довелося б навчити GRUB усім видам логіки RAID і усім способам підключення модулів. І те, і інше постійно змінюється, і устигати за цими змінами означає підтримувати власну, паралельну Linux, дискову підсистему.

Вдумаємося. Для того, щоб засобами Linux підключити модуль ядра, що працює з дисковим пристроєм, необхідно завантажити Linux з цього ж пристрою. Чи так це неможливо? Адже якщо можна прочитати звідти "ядро", то, напевно, можна прочитати і "Linux"? Точніше, на додаток до однієї області даних, відповідної ядру, потрібно прочитати другу, відповідну деякій зменшеній до межі установці Linux, в якій знаходяться тільки потрібні програми і модулі, завантажити звідти "маленький Linux", який настроїть і підключить нещасливий RAID і запустить процес завантаження повноцінної системи звідти.

Гранично стислий варіант Linux є - це проект busybox, використовуваний у вбудованих системах, де дорогий кожен байт. Розмістити файлову систему в пам'яті теж легко - цим, наприклад, займається модуль tmpfs, який можна включити в базове ядро. Залишилося тільки навчити підсистеми завантаження GRUB і LILO прочитувати не одну, а дві області даних - ядро і образ файлової системи. Ядру при цьому передається параметр "користуйся віртуальним диском", щоб воно підключило завантажений образ як тимчасову кореневу файлову систему. Можна також зажадати, щоб пам'ять, займана тимчасовою файловою системою, звільнялася в процесі подальшого завантаження.

Такий механізм називається initrd (initial ram disk, де "ram" - це random access memory, тобто оперативна пам'ять) або стартовим віртуальним диском. Стартовий віртуальний диск збирається по команді mkinitrd відповідно до профілю комп'ютера і записується на диск за тими ж правилами, що і ядро. Ніяких вимог до назв ядер в Linux немає, це справа авторів дистрибутива. В цьому випадку в імені ядра і образу диска зустрічається версія ядра (2.4.26), тип зборки std (мабуть, "standard") і тип архітектури up (uniprocessor, тобто однопроцесорна).

стартовий віртуальний диск

Мінімальний набір програм і модулів Linux, необхідний для забезпечення завантаження системи. Є віртуальною файловою системою в оперативній пам'яті. Завантажується вторинним завантажувачем разом з ядром.

Батько усіх процесів

Якщо в параметрах не вказане інше, ядро вважає, що init називається /sbin/init. У стартовому віртуальному диску це звичайно деякий простий сценарій, а в повноцінній системі у init інше завдання: він запускає усі процеси. Якщо процеси запускає не він сам, то це роблять його нащадки, так що усі процеси Linux, окрім ядерних, походять від init, як увесь рід людський - від Адама.

Насамперед init розбирає власний конфігураційний файл - /etc/inittab. Файл цей має досить просту структуру: кожен рядок (якщо вона не коментар) має вигляд "id -. рівні -. действи -. процес", де id - це деяка дво- або односимвольна мітка, рівні - це слово, кожна буква якого відповідає рівню виконання (про рівні виконання буде розказано далі), дія -это спосіб запуску процесу.

Getty поводиться так несхоже на інші процеси: не просто запускає з-під себе login, а чекає закінчення його роботи, відсутній при цьому в таблиці процесів. Насправді чекає не getty, a init, використовуючи метод "respawn" : породжується (у фоні) процес getty з певним PID, a init не діє до тих пір, поки існує процес з цим PID: getty, login, стартовий командний інтерпретатор або програма, запущена з нього за допомогою exec (); коли ж процес, нарешті, помирає, породжується новий getty.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Завантажувач ядра	\|	Зупинка системи

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.007 сек.