Найкращий спосіб зрозуміти, як працює операційна система Linux, — це простежити поетапно її завантаження. Саме під час завантаження запускаються всі ті механізми, що призводять ОС в рух. Процес цей складний, багатоступінчастий і часом заплутаний. Вивчати його цікаво, а відкриття, які ви зробите при цьому, можуть сильно вас здивувати.
В цілому завантаження Linux дистрибутива можна розділити на 5 етапів:
Зміст
Етапи завантаження Linux
Ми пройдемося по всіх стадіях і дізнаємося, що відбувається під час завантаження типового дистрибутива Linux, трохи відхилившись убік BSD, macOS і Android шляхом. У багатьох випадках це дозволить зрозуміти, чому процес завантаження Linux саме такий, який є.
1. Завантажувач
Все починається з завантажувача, якому під час старту машини BIOS передає управління. У старі часи, коли Linux був не так популярний, як завантажувача використовувався LILO (Linux Loader) — простий, дуже примітивний і не дозволяє змінювати конфігурацію завантаження на льоту. Фактично конфігураційний файл був вшитий в сам завантажувач, і його доводилося заново після кожної зміни налаштувань: оновив ядро, забув перевстановити, і твій ноутбук більше не вантажиться.
Сьогодні завантаженням Linux практично в будь-якому дистрибутиві займається Grub, спочатку розроблений для операційної системи GNU/Hard. Grub набагато складніше LILO і фактично сам є повноцінною ОС. Він не просто читає конфіг завантаження (зазвичай це /boot/grub/grub.cfg) прямо з диска, але і дозволяє виправити цей конфіг на місці. Grub має вбудовану командний рядок, працює з десятком різних файлових систем і дозволяє формувати складні ланцюжки завантаження.
Як тільки користувач вибирає потрібний пункт меню (або після закінчення тайм-ауту), Grub знаходить пов’язаний з цим пунктом меню образ ядра Linux на диску (зазвичай, це файл /boot/vmlinuz), а також закріплений за ним образ initramfs (про нього трохи пізніше), завантажує в пам’ять і передає управління ядру.
Етапи завантаження Linux
Щоб побачити меню Grub в Ubuntu, необхідно утримувати Shift
2. Ядро і initramfs
Отримавши управління, ядро починає первинну ініціалізацію: запускається підсистема управління пам’яттю, налаштовується обробник переривань, ініціалізуються необхідні для подальшої роботи ядра структури даних. Коли ця робота буде закінчена, ядро розпаковує архів initramfs (зазвичай він має ім’я виду /boot/initramfs-linux.img і являє собою архів cpio, стиснутий за допомогою gzip) у файлову систему в оперативній пам’яті (tmpfs), робить її кореневої файлової системи, і запускає скрипт /init (в різних дистрибутивах ім’я може відрізнятися).
Initramfs включає в себе базовий набір компонентів Linux-дистрибутива: стандартні системні каталоги /bin, /lib, /etc і так далі, найпростіший командний інтерпретатор (зазвичай ash), набір команд BusyBox, кілька допоміжних бібліотек та набір модулів ядра (драйверів), призначених для роботи з різними накопичувачами і файловими системами.
Етапи завантаження Linux. Вміст initramfs.
Сенс існування initramfs в тому, щоб вирішити проблему курки і яйця: завантажити драйвери для підключення реальної кореневої файлової системи до того, як вона буде підключена. Саме це і відбувається, коли система запускає скрипт /init. Він визначає встановлені в систему накопичувачі, завантажує ядро драйвери для роботи з ними, а потім підключає потрібний розділ потрібного накопичувача (про те, який саме, ядро дізнається завдяки переданому при завантаженні параметру root) до кореня, перекриваючи таким чином вміст initramfs. Потім запускає скрипт /sbin/init, з якого і починається наступний крок завантаження ОС.
Завантаження Linux. Скрипту init з initramfs.
3. Первинна ініціалізація
Після того як скрипт /init з initramfs закінчує свою роботу, він запускає утиліту /sbin/init реальної файлової системи. З цього моменту починається ініціалізація самої ОС: завантаження необхідних драйверів, підключення файлових систем і розділів підкачки, налаштування мережевих інтерфейсів і запуск системних служб.
Історично /sbin/init була дуже простий утилітою, яка займалася лише тим, що передавала управління певним скриптам в залежності від переданого їй параметра (скрипти розташовувалися в каталогах /etc/rcX.d/, де X — рівень завантаження). Кожен скрипт відповідав за строго певну операцію: один підключав перераховані у файлі /etc/fstab файлові системи, інший конфигурировал мережеві інтерфейси, ще один запускав демон cron (він займається запуском періодичних завдань), ще один — демон syslog (він відповідає за прийом журнальних повідомлень та їх запис на диск) і так далі. Цей стиль ініціалізації отримав ім’я SystemV по імені версії UNIX, в якій він з’явився.
Достоїнство стилю ініціалізації SystemV в його крайній простоті: його легко зрозуміти, його легко реалізувати, з ним просто працювати. Проте він абсолютно не підходить до сучасних реалій.
Сьогодні завантаження ОС не зводиться до завантаження пари-трійки драйверів, підключення двох файлових систем, налаштування одного мереженого інтерфейсу і запуску трьох служб. Стандартна конфігурація може включати в себе десятки різних демонів, на запуск кожного з яких може піти чимало часу, а сам демон може впасти. SystemV запускає служби послідовно і не контролює їх життєвий цикл, тому завантаження стає повільною, а коректна робота в подальшому не гарантується.
Щоб оминути ці проблеми, розробники macOS в свій час створили альтернативу /sbin/init під назвою launchd. Це без перебільшення геніальна розробка — launchd не тільки вміє контролювати життєвий цикл служб, але і запускає їх лише тоді, коли ці служби стають потрібні. Причому робить це вельми неординарним чином.
Про те, як це відбувається, ми ще поговоримо. Зараз в історії з launchd нас цікавить інше, а саме те, що під його враженням був створений той самий systemd. Сьогодні systemd — частина більшості дистрибутивів Linux. Він набагато складніший /sbin/init і навіть launchd, а в його конструкції немає і натяку на рівні запуску і скрипти. Systemd оперує поняттям юніт (unit), який може уособлювати собою службу, операцію монтування, операцію налаштування мережевого інтерфейсу і інші.
Завантаження Linux. Конфіг юніта демона Tor.
Для опису юнітів використовується спеціальний декларативний мову, тому допустити помилку конфігурації складніше, ніж при написанні сценарію. Юніти можуть мати залежно один від одного і запускаються паралельно або коли в них виникає необхідність. Наприклад, служби (демони), що не залежать від мережевого підключення, можуть бути запущені раніше налаштування мережевого інтерфейсу, інші — відразу після його установки, треті — тільки тоді, коли до них звертаються програми або інші служби.
4. Запуск демонів
Запуск служб (демонів) — один з ключових моментів завантаження Linux. Особливе місце тут займає демон udev, без якого типовий дистрибутив Linux виявиться непрацездатний.
Udev займається керуванням вмістом каталогу /dev. Як ми всі знаємо, в Linux-системах цей каталог використовується для зберігання так званих файлів пристроїв — особливого типу файлів, які уособлюють собою ті чи інші компоненти ПК. Саме з допомогою файлів пристроїв в Linux відбувається робота з обладнанням: читаєш файл /dev/sda1 і отримуєш вміст першого розділу першого жорсткого диска, записуєш дані в /dev/fb0 і виводиш картинку на екран.
У ранньому UNIX каталог /dev був статичним. Він містив набір файлів на всі випадки життя: навіть якщо ПК не була встановлена звукова карта, файл /dev/dsp для виводу звуку все одно існував. Коли кількість різноманітного обладнання було невелике, а plug’n’play ще не народився, проблем не було: лише десяток-інший файлів. Але з часом він все більше захламлялся і в підсумку перетворився у смітник.
Перший варіант вирішення цієї проблеми полягав у тому, щоб підключити до /dev віртуальну файлову систему (devfs), вмістом якої керувала б ядро. Воно знаходило все встановлене обладнання і створювало файли тільки для тих пристроїв, які реально присутні в машині.
Таке рішення досі використовується в macOS і FreeBSD, але розробники Linux пішли іншим шляхом. Тут є спеціальна файлова система sysfs, підключена до каталогу /sys. Це щось на зразок детальної бази даних про всіх пристроях ПК, починаючи від процесора і контролера переривань і закінчуючи пахвами і геймпадами.
Завантаження Linux. З допомогою /sys можна не тільки отримати інформацію про пристрої, але і керувати ними.
З допомогою /sys можна не тільки отримати інформацію про пристрої, але і керувати ними.
На основі інформації, отриманої з /sys, демон udev створює файли пристроїв /dev. Під час першого старту він проходить по всіх пристроїв в /sys, а потім засинає і чекає, поки не буде додано або видалено пристрій: встромив флешку — в /sys з’явилися нові файли, udev прокинувся і створив на їх основі файл пристрою /dev, завантаживши потрібні драйвери.
Ще один важливий для UNIX-систем демон — syslog. Це свого роду агрегатор логів додатків, який складав їх в каталог /var/logs. У заснованих на systemd дистрибутивах замість нього зазвичай використовується systemd-journald, який зберігає звіти в спеціальному бінарному форматі (syslog оперує текстом). В нього можна додавати нові записи, але вилучати не можна. Це захист від зломщиків, які могли б видалити потрібні рядки з файлів, щоб приховати сліди свого перебування в системі.
У середньостатистичному дистрибутиві Linux також є інші демони:
- cron — відповідає за виконання завдань по часу. Може запускати команди через певні проміжки або у чітко визначений час. Найпростіший варіант використання — створення бекапу по ночах;
- cups — демон друку. Слідкує за чергою відправлених на друк документів і віддає їх принтера;
- systemd-logind — управляє користувацькими сесіями, дозволяє швидко перемикатися між сесіями, дає дозвіл на автомонтирование пристроїв від імені користувача і виконує інші завдання;
- dbus — демон, що обслуговує роботу шини даних, що дозволяє програмам обмінюватися інформацією. В основному використовується в середовищах робочого столу і графічних додатках;
- NetworkManager — конфігуратор мережевих інтерфейсів. Використовується тільки в десктопних варіантах дистрибутивів і може бути замінений на аналог. Наприклад, wicd.
В більшості своїй демони обмінюються інформацією з додатками та іншими демонами за допомогою UNIX-сокетів. Це канал комунікації, закріплений за файлом. Наприклад, демон cups створює сокет /var/run/cups/cups.sock (у різних дистрибутивах розташування може відрізнятися). Записуючи в нього дані, можна надсилати документи на друк.
Саме цю особливість використовують launchd і systemd, щоб запускати демони тільки в міру необхідності. Трюк полягає в тому, щоб заздалегідь створити сокети для всіх системних демонів, а самі демони запускати лише тоді, коли хто-небудь запише дані в сокет; немає сенсу запускати cups при завантаженні або в будь-який інший момент, якщо ніхто не відправляє завдання на друк.
5. X Window System і PAM
Останній етап завантаження — запуск менеджера логіна. В консолі функцію менеджера логіна виконує зв’язка утиліт getty (зазвичай використовується більш просунутий варіант agetty) та login. Getty являє собою рудимент, який залишився з часів мейнфреймів і віддалених терміналів (назва розшифровується як get teletype). Він виводить на термінал текстове повідомлення і потім запускає утиліту login, яка запитує логін і пароль користувача. Коли користувач вводить коректний пароль, login запускає від його імені шелл, вказаний у файлі /etc/passwd.
Графічний менеджер логіна називається дисплейний менеджер (Display Manager), і в кожної графічної середовищі він свій. KDE використовує менеджер KDM, GNOME — GDM, також є можливість використовувати універсальний дисплейний менеджер, наприклад Slim. У будь-якому разі завдання дисплейного менеджера — вивести на екран вікно запиту імені користувача і пароля, а після авторизації або запустити віконний менеджер безпосередньо, або виконати ряд команд, записаних у власний файл ~/.xinitrc.
Етапи завантаження Linux. Дисплейний менеджер KDM в Debian.
Одночасно із запуском дисплейного менеджера запускається графічна система X Window System, а в сучасних дистрибутивах — Xorg. Це клієнт-серверна система виведення графіки на екран, де сервер відповідає за компонування загальної картинки, сформованої різними програмами-клієнтами. X Window System — не графічна середовище, а лише прошарок, що дозволяє додаткам відправляти зображення на екран і отримувати події введення від користувача. Щоб побудувати на її основі графічний інтерфейс, також потрібен менеджер вікон (window manager), який дозволить користувачеві управляти вікнами додатків.
Менеджер вікон може працювати як окремо (наприклад, fluxbox, window maker, i3), так і у складі комплексної середовища робочого столу (KDE, GNOME, XFCE). Крім менеджера вікон, вони також включають в себе набір засобів для формування повноцінного десктопа: панель завдань в нижній або верхній частині екрана, док, систему розташування іконок на робочому столі та інше. Зазвичай кожен з цих елементів управляється одним або декількома спеціальними додатками.
Незалежно від того, який спосіб входу використовує юзер, за контроль доступу завжди відповідає PAM. Це модульна система аутентифікації користувача, яка може перевіряти його особистість самими різними способами, попутно виконуючи ряд перевірок. За замовчуванням PAM використовує аутентифікацію виключно за допомогою пароля, але, помінявши конфігураційні файли /etc/pam.d, порядок аутентифікації можна змінити, додавши до нього, наприклад, необхідність прикласти палець до сканера відбитків, вставити спеціальну флешку-ключ і навіть використовувати підтвердження за допомогою смартфона. Про те, як це зробити, ми вже писали.
Завантаження Linux. Конфігураційний файл PAM утиліти login
На цьому процес завантаження можна вважати закінченим. Ти або виконуєш логін в консоль і бачиш запрошення командного інтерпретатора або вводиш дані облікового запису у вікно дисплейного менеджера, і в результаті на екрані з’являється робочий стіл.
Замість висновку
Так виглядає завантаження сучасного дистрибутива Linux. Деякі не особливо важливі і не особливо цікаві деталі я опустив, але спробував розповісти про найголовніше. Якщо вдуматися, це не такий вже і складний процес, фактично операційна система готова приймати команди користувача вже на етапі підключення initramfs, все інше — запуск оточення, яке необхідно для повноцінної роботи користувача.
