Як Linux має справу з окремим / завантажувальним розділом?

Мені цікаво дізнатися про те, як Linux працює з окремими завантажувальними розділами. Мені не цікаво насправді цим займатися, але хотілося б знати, як це працює під кришкою.

Розглянемо жорсткий диск sda, який має дві секції sda1та sda2. Скажімо, sda2це rootрозділ, /який містить ОС Linux.

Я розумію, що завантажувач GRUB2встановлений на /boot. Однак, коли каталог /bootзнаходиться на окремому розділі sda2, як це може статися раніше, ніж /насправді встановлено?

Як взаємодія між BIOS, головним завантажувальним записом та GRUB (або файлами /boot) успішно відбувається в цьому випадку? Хіба що дані в /bootнасправді не змонтовані у /файловій системі на цій ранній стадії?

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

Ось проблема у вашому розумінні:

Я розумію, що завантажувач GRUB2, змонтований до / boot.

GRUB не "встановлений" на завантаженні. GRUB буде встановлений в /boot, і завантажується з коду в Master Boot Record. Ось спрощений огляд сучасного процесу завантаження, припускаючи дистрибутив GNU / Linux з MBR / BIOS (не GPT / UEFI):

1. BIOS завантажується.
2. BIOS завантажує невеликий фрагмент коду, який знаходиться в Master Boot Record.
3. GRUB не вміщується в 440 байт, розмір Master Boot Record. Отже, завантажений код насправді просто аналізує таблицю розділів, знаходить /bootрозділ (який, на мою думку, визначається при встановленні GRUB в Master Boot Record) та аналізує інформацію файлової системи. Потім він завантажує етап 2 GRUB. (Тут відбувається спрощення.)
4. Етап 2 GRUB завантажує все необхідне, включаючи конфігурацію GRUB, а потім представляє меню (чи ні, залежно від конфігурації користувача).
5. Вибирається послідовність завантаження. Це може бути тайм-аут, вибираючи користувачем запис у меню або завантажуючи список команд.
6. Початок завантаження починається виконувати. Це може зробити ряд речей - наприклад, завантаження ядра, завантаження ланцюга в інший завантажувач - але припустимо, що послідовність завантаження є стандартною GNU / Linux.
7. GRUB завантажує ядро ​​Linux.
8. GRUB завантажує початковий ramdisk .
9. Початковий ramdisk монтується /під /new_root(можливо, криптографічно розблокуючи його), запускає udev, починає резюме від swap тощо.
10. Початковий ramdisk використовує pivot_rootутиліту для встановлення /new_rootяк реальну /.
11. initпочинається. Перегородки встановлюються, демони запускаються, а система завантажується.

Зверніть увагу, як ядро ​​завантажується лише на етапі 7. Через це не існує концепції монтажу до етапу 7 . Ось чому /bootйого потрібно знову встановити на кроці 9, навіть якщо GRUB вже використовував це.

Також може бути корисним переглянути розділ GRUB 2 сторінки Вікіпедії на GRUB.

Питання 1

Я розумію, що завантажувач GRUB2, змонтований до / boot. Однак, коли каталог / завантажувач знаходиться на окремому розділі sda2, проте, як це може статися раніше / насправді встановлено?

Я не думаю, що ти розумієшся тут цілком правильно. На сторінці Вікіпедії GNU GRUB :

витяг

Коли комп'ютер увімкнено, BIOS комп'ютера знаходить налаштований первинний завантажувальний пристрій (як правило, жорсткий диск комп'ютера) і завантажує та виконує початкову програму завантаження з головного запису завантаження (MBR). MBR є першим сектором жорсткого диска і має число 0 (підрахунок секторів починається з 0). Тривалий час розмір сектора становив 512 байт, але з 2009 року є доступні жорсткі диски розміром сектора 4096 байт, які називаються розширеними форматами дисків. Станом на жовтень 2013 року такі жорсткі диски все ще доступні в 512-байтових секторах, використовуючи емуляцію 512e .

У версії 2 GRUB відбувається наступне:

витяг

Завантаження комп'ютера

При включенні живлення відбувається таке:

• Апаратне забезпечення ініціалізується, встановлює процесор в реальний режим (без віртуальної пам'яті) і переходить у фіксовану локацію 0xFFFF0 (провідний в ланцюзі процесора)
• Таким чином виконується код BIOS, що зберігається в ПЗУ або флеш-пам'яті, відображений у цьому місці.
• Код BIOS розглядає дані конфігурації BIOS, щоб побачити, що є завантажувальним пристроєм. Ці конфігураційні дані BIOS зазвичай можна редагувати, натискаючи якусь спеціальну послідовність клавіш відразу після включення живлення, внаслідок чого програма конфігурації BIOS запускається. Серед іншого, тут зазвичай можна вибрати завантажувальний пристрій.
• Код BIOS завантажує MBR завантажувального пристрою в оперативну пам'ять. Пам'ятайте, що MBR - це всього 512 байт! Завантажені дані - це звичайно програма та дані, які динамічно створювали та записували grub-install, коли виконувалася програма установки grub.
• Код BIOS переходить до стартової адреси завантаженого MBR (тобто Grub-код виконується вперше з моменту включення).
• Код MBR Груба завантажує один сектор, адреса якого провідним способом передається в блок MBR. Потім він перетинає пари (address, len) в цьому секторі, завантажуючи в пам'ять усі ці дані з диска (тобто завантажує вміст файлу /boot/grub/core.imgабо його "вбудовану" копію). Потім код MBR переходить до завантаженого коду, тобто "виконує" програму в core.img.
• Як описано в розділі "Встановлення Grub", цей трюк вбудовування адресних блоків дискового блоку дозволяє зберігати core.imgв просторі, який не знаходиться в розділі, і який ніколи не був відформатований як файлова система ("вбудовування"). І в цьому випадку, якщо core.imgбуде змінено, доки нова версія буде "вбудована" в одному місці, код MBR не потребує оновлення.
• Крім того, можливо, що core.imgдля перебування всередині реальної файлової системи, а для Grub читати core.imgвміст файлу, не маючи драйвера для цієї файлової системи. Однак у цьому випадку, якщо core.imgйого змінено, то першому блоку файлу цілком може бути надана нова адреса на диску; якщо це станеться, MBR необхідно оновити, щоб вказати на це нове місце. Тим не менш, як core.imgце зазвичай оновлюється за допомогою встановлення grub, це зазвичай не є проблемою.
• Зауважте, що теоретично, якщо core.imgна іншому пристрої, ніж MBR, додано нове обладнання, то запис MBR, що генерується Grub, не зможе правильно завантажити core.imgфайл; ідентифікатор пристрою, на якому core.imgповинен бути знайдений перший сектор, провідний в MBR, не шукається. Однак для цього немає рішення; немає можливості вставити еквівалент команди "Пошук" Grub в 512-байтовий MBR. Ця проблема, мабуть, малоймовірна; як правило core.img, вбудований на той же пристрій, що і MBR. І як тільки core.imgвін буде завантажений, він може використовувати search.mod для пошуку всіх подальших /boot/grubфайлів, і тому не застрахований від апаратних перестановок.
• Тепер виконаний core.imgкод ініціалізує всі вбудовані в нього модулі (пов'язані в core.img); один з цих модулів буде драйвером файлової системи, здатним читати файлову систему, в якій /boot/grubживе каталог .
• Він також реєструє набір вбудованих команд: set, unset, ls, insmod.
• Якщо «конфігураційний файл» був пов’язаний core.img, він передається дуже простому вбудованому аналізатору сценаріїв для обробки. Команди сценаріїв у конфігураційному файлі можуть викликати лише вбудовані або пов'язані команди. Прості сценарії (наприклад, завантаження типового настільного комп'ютера з локального диска) не потребують конфігураційного файлу; цей засіб використовується для таких речей, як завантаження через pxe, віддалений nfs або коли /boot/grubє на пристрої LVM.
• Core.imgтепер “/boot/grub/normal.mod”динамічно завантажує файл з диска та переходить до його функції введення. Зауважте, що для цього кроку потрібно встановити відповідний драйвер файлової системи (тобто вбудований).

ПРИМІТКА. Коли ви бачите типове меню GRUB2, де ви вибираєте ОС / ядро ​​для завантаження, ви посилаєтесь на /boot/grubкаталог системи в цей момент.

Список літератури

• Завантаження Linux на x86 за допомогою Grub2
• GNU GRUB - Вікіпедія
• 6 етапів процесу завантаження Linux (послідовність запуску)
• Всередині процесу завантаження Linux
• Процес запуску Linux
• Завантажувач GRUB 2 - Повний підручник - Dedoimedo

Linux (ядро) байдуже, скільки у вас завантажувальних розділів. Завантаження ядра з диска є роботою завантажувача (наприклад grub, grub2, lilo) і ці кошти також не дбають про кількість місць ядро може бути розташовані. Вони дбають лише про конкретне місце розташування.

Наприклад, мій завантажувальний розділ - /dev/md1це дзеркало mdadm RAID, підкріплене фізичними розділами /dev/sde1та /dev/sdf1. Я можу їх монтувати окремо, якщо хотів, і як такий технічно вважається, що має два завантажувальні розділи, хоча вони повинні містити однакові дані.

Наявність двох розділів для / boot для мене - це питання доступності, але вони однаково можуть бути різними / завантажувальними розділами. Наступний крок - як дізнається завантажувач? Ось як:

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

Це уривок з grub2конфігурації, і ви зауважите, що єдині відмінності є root=hd0,1і root=hd1,1визначають, який завантажувальний розділ, який посилання на запис.

Тепер ходимо, хоч чобіт, щоб ти зрозумів, що тут відбувається.

• BIOS зчитує MBR з обсягу завантаження і переходить до завантажувача
• Завантажувач (наприклад grub2) налаштований так, щоб знати, який пристрій і розділ містить ваше ядро. Grub2 отримує доступ до цього розділу безпосередньо та завантажує ваше ядро ​​в пам'ять.
• Потім завантажувач завантажується в ядро, і ядро ​​завантажує вашу машину.

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

Ядро байдуже, скільки у вас завантажувальних розділів, тому що їх ніколи не потрібно їх бачити (потрібно лише мати доступне для додавання нових ядер, наприклад).