Для чого насправді розділ / boot?

Я читаю відносно старий текст про розділи та файлові системи Linux ( Біблія сертифікації LPIC 1 ). Він говорить:

Деякі версії завантажувачів Linux не можуть отримати доступ до ядра, яке знаходиться поза першими 1024 циліндрами на диску. Поклавши розділ / boot на початку диска, ви можете бути впевнені, що не матимете проблем при доступі до ядра під час завантаження. Ця проблема виявляється найчастіше у випадках подвійного завантаження Linux разом з іншою операційною системою, яка знаходиться на першому розділі.

Чому завантажувач не матиме " доступу до ядра поза першими 1024 циліндрами на диску "?

Крім того, що означає " ставити розділ / boot на початку диска "?

Це обмеження, накладене дуже старим BIOS і завантажувачем, а не самим Linux. BIOS зможе отримати доступ лише до перших 1024 циліндрів диска (див. Тут для отримання додаткової інформації про те, що таке циліндри / головки / сектори). Це обмеження пошириться на завантажувачі, які через свою просту природу не мали б власних драйверів дисків і використовували б послуги BIOS для доступу до диска.

Це означало, що і завантажувач, і ядро ​​(оскільки його завантажувач повинен завантажувати) повинні знаходитись у перших 1024 циліндрах на системах із цим обмеженням. Простий спосіб зробити це - створити окремий /bootрозділ, що містить ядро, і помістити його на початку диска (зазвичай, просто зробивши його першим розділом). Це означає, що він фізично знаходився б у перших 1024 циліндрах, якщо, звичайно, перегородка була не надто великою.

Обмеження більше не є проблемою, оскільки воно стосується лише старих BIOS. Також багато сучасних завантажувачів (наприклад, GRUB) мають власні дискові драйвери, тому не потрібно покладатися на послуги BIOS. Сучасні завантажувачі можуть використовуватись і /bootдля інших цілей, але більше не потрібно знаходитись як на окремій перегородці, так і в межах перших 1024 циліндрів (хоча є чимало випадків, коли потрібно мати /bootна окремій перегородці).

Історія

/bootмістить файли, які використовуються не операційною системою, а її завантажувачем . Ви знайдете як файли самого завантажувача (наприклад, /boot/grub/*для Grub), так і ядра Linux ( /boot/vmlinuz*) та часто пов'язані з ним initrd або initramfs .

На ПК із застарілим BIOS (на відміну від новіших UEFI, знайдених на останніх комп'ютерах) програмне забезпечення в ПЗУ завантажує в пам'ять перші 512 байти завантажувального диска ( завантажувальний сектор ). Маючи лише 512 байт (не всі з яких навіть містять код: частина з них містить такі дані, як таблиця розділів), код не може зробити багато - там не може бути справжнього драйвера диска. Все, що можна зробити в такому обмеженому просторі, - це використовувати інтерфейс BIOS для завантаження більшої кількості коду. Цей інтерфейс надає команду для завантаження N-го сектора на диск - і розмір N обмежений, тому таким чином можна досягти лише початку диска.

Інтерфейс BIOS трохи розвинувся за три десятиліття або близько того, але він вже існував, але його обмеження розміру намагалися не відставати від розмірів дисків, внаслідок чого старі BIOS і завантажувачі завантажувались на 32 МБ, 512 МБ, 2 ГБ, 8 ГБ (і можливо інші пороги, які я не пам’ятаю). Завантажувач повинен мати можливість використовувати інтерфейс BIOS для завантаження всіх фрагментів, необхідних для прямого доступу до дисковода. Завантажувачі зазвичай не містять драйвери для всіх дискових контролерів навколо, тому все, що стосується завантаження ядра Linux (і initrd / initramfs), має використовувати інтерфейс BIOS і, таким чином, повинен вміщуватися на початку диска.

Зауважте, що це обмеження BIOS або завантажувача, а не самого Linux або дистрибутива.

/bootСьогодні відокремте

У системі з недавнім BIOS і недавним завантажувачем, або з UEFI, обмеження розміру вже не актуальні: розміри дисків тепер мають довго наздогнати. Однак є й інші випадки використання, які роблять окремий /bootрозділ корисним. Це дозволяє основній системі знаходитись на пристрої RAID, який завантажувач не підтримує, або на типі файлової системи, яку завантажувач не підтримує. Це дозволяє основній системі знаходитися на зашифрованому пристрої, який Linux може розшифрувати, але не завантажувачем.

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

Ще одна причина, окрім згаданої проблеми BIOS, полягає в тому, що окремий /bootрозділ дозволяє використовувати файлову систему для /обсягу, якого завантажувач не розуміє (не обмежуючись блокуванням завантаження списку, як при lilo).

РОЗЧИНУВАННЯ ТРУДНО

Завантаження ... ну ... це справді найважча частина. Кожен раз, коли комп'ютер завантажується, він в основному зустрічається заново. Вона знайомиться з різними її частинами, і для кожної, яка відповідає їй, вона набуває можливостей. Але він повинен щоразу підтягуватися власними завантажувальними системами, так би мовити, з квадратних.

При розробці процесу завантаження хитрість полягає в тому, щоб підняти машину поетапно. Ваш черевик повинен бути швидким і надійним, і це має бути обидві речі у абсолютно невідомому середовищі кожного разу . Я навіть не буду братися за розмову в режимі реального / захищеного режиму (що не означає, що я навіть міг) , але при завантаженні відбувається багато чого. Оскільки комп'ютер засвоює різні компоненти кожного разу, коли це робиться поступово. Напевно, найважливішим із них є перехід від виконання бортового коду до виконання коду на диску, або, іншими словами - ядра exec. Це коли прошивка (нібито) здається в операційну систему.

Багато років тому це було не так вже й так. Раніше BIOS справді був базовим входом / виходом - звичайні програми здійснювали дзвінки до вбудованого програмного забезпечення для таких речей, як малювання екрана та доступ до диска. Їх називали перериваннями - старі капелюхи, можливо, запам’ятовували їх найкраще за відчуття насолоди, які вони часто зустрічаються при призначенні IRQ для їх нової крапки-матриці або USR.

INT13H

Це серія функцій 13H, що забезпечує переривання ( або INTв монтажі lingo ), що пропонує BIOS як послуги доступу до диска. Вони досі навіть використовуються для систем BIOS в процесі завантаження, щоб зробити перехід від прошивки до диска.

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

Виконаний MBR майже точно не є вашим системним ядром - 512 байтів (дайте або візьміть) було б марно в цьому відділі. Це, мабуть, завантажувач - програма, спеціально розроблена для подолання одного з багатьох обмежень щодо адресації BIOS - зокрема, що вона взагалі не розуміє файлову систему.

Коли завантажувач зачитує фактичне ядро ​​і виконує його в пам'яті (як ми всі молимося, що це буде кожен раз) , він, ймовірно, зробить це, запитуючи BIOS через INT13Hвиклик переривання. А якщо цього не відбувається - багато шалених завантажувачів змонтують файлові системи в загальноприйнятому розумінні та виконають код іншим способом - тоді дуже мало ймовірно, що завантажувач набув такого фантазії без INT13Hдвох-двох. Часто завантажувачі завантажують ланцюг самостійно - або на різних етапах - оскільки 512 байтів, що їх було виділено, не відповідає навіть їхнім потребам.

ЦИЦЕН І ЯЙЦЬ

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

Розумієте, як тільки ядро ​​виконує і всі його безлічі процедур доступу та контролю апаратного забезпечення ініціюється, всі ці проблеми начебто зникають (або, принаймні, дещо змінюються) , тому що сучасні ОС беруть повний контроль над системою, але поки вони не роблять, обмеження системи поширюються лише настільки, наскільки це дозволить прошивка. Це дуже багато говорить - BIOS не сильно змінився з INT13H8086 року. Виклик є оригіналом 8086. Так, були (безліч) розширення, і хаки звичайно, але нововведення ...?

КРАЩЕ І ЛИШЕ

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

Цей бар'єр був зустрінутий і зламаний багато разів. Кожен раз, коли карта абстрагується та кодується якимось новим, розумним та менш точним способом. І тому в ці дні для BIOS буквально неможливо точно зіставити диск. Адресація логічного блоку зараз є де-факто стандартом, хоча деякі переклади циліндра / голови / сектора (або CHS) все ще потрібні. Що прошивка материнської плати втратила в точності / відповідальності, такі розширення абстрагувались та додавали до відповідальності прошивки диска, щоб заповнити прогалини.

Саме ця гра «коти-мишки» посилається на ваше запитання. Коли BIOS не в змозі зрозуміти диск за певним моментом через його розмір, то будь-які дані, які ви могли б отримати, він буде завантажений для вас під час завантаження - наприклад, завантажувач або ядро ​​- мабуть, краще не знаходитись поза цією точкою. Ось звідки /bootвзявся.

МОЖЕ ТОЧНО ЛИШЕ

В наші дні подібні речі, на щастя, зробили невідповідними наслідки кон'юнктури BIOS. Минуло 30 років, але в останні кілька років його значною мірою замінив стандарт UEFI (або EFI 2.0) . UEFI забезпечує кріплення з хвилини, він ініціалізується в захищеному режимі, він включає в себе власний завантажувач, він забезпечує стійке перезавантаження стійкого флеш-пам’яті змінного сховища, він повинен працювати з декількома незрозумілими zetabytes або будь-яким іншим на диску ... і багато іншого ще. Це далеко не ідеально, але це величезне вдосконалення в порівнянні з попередником.

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

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

Про те, що існує /bootкаталог, визначається історично і звідти "фіксується" в Ієрархічному стандарті файлової системи . Наявність такого стандарту дозволяє програмам (і sysadmins) очікувати певних файлів у певних місцях. У цьому випадку файли, пов'язані з процесом завантаження.

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

Також може бути дуже упорядкованим мати окремий / завантажувальний розділ. На моїй машині у мене є багато дистрибутивів та резервних копій, кожен має свої розділи, але всі вони мають однаковий / завантажувальний розділ, де знаходяться всі ядра для всіх ОС. Крім того, всі дистрибутиви вказують на мою єдину копію lilo.conf, яка також знаходиться в / boot, тому мені ніколи не доведеться здогадуватися, що, до біса, відбувається, коли я додаю ядра, додаю дистрибутив, що завгодно. Ось фрагмент з мого lilo.conf:

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

... це лише мої резервні копії Debian на двох дисках. Подивіться, як легко відслідковувати ядра? (зараз усі резервні копії, що використовують одне ядро).

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

Припустимо, що основна файлова система пошкоджена таким чином, що деякий завантажувач нижньої стадії не в змозі правильно прочитати наступний етап. Якщо натомість матеріали завантажувача перебувають у власному розділі, то ядро ​​може підійти і належним чином опрацювати корумпований кореневий розділ через fsck. Це саме може бути у власному розділі.

Завантажувальний розділ може дати вам параметри для "порятунку", як-от встановлення альтернативного кореневого розділу. Крім того, що робити, якщо ви завантажуєте різні операційні системи в різні розділи? Тоді завантажувальні матеріали не належать до жодної з цих систем. Це розумно мати власну перегородку. Ви можете замінити будь-який з розділів ОС на іншу ОС, але поки не зможете завантажувати решту ОС.

Крім того, що робити, якщо ви хочете використовувати файлову систему для вашого основного розділу, який завантажувач зовсім не розуміє? Або, скажімо, для яких підтримка з боку завантажувача просто експериментальна? У таких ситуаціях файл часу завантаження все ще може використовуватися, якщо є секторна карта (а завантажувач підтримує таке: старий хороший завантажувач Linux LILO використовував секторні карти, і тому не довелося розуміти файлову систему структура взагалі). Але галузеві карти за своєю суттю нечіткі. Якщо файлова система реорганізована, сектори переміщуються, і тому секторні карти стають неправильними і повинні бути відновлені, інакше система не може перезавантажитися.

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

Це не було обмеженням дистрибутива Linux, але було обмеженням старих BIOS. Ще в ті часи, щоб забезпечити завантаження Linux, усі файли, пов’язані з завантаженням, були розміщені у власному розділі, який зробив перший розділ на жорсткому диску, щоб забезпечити завантаження завантажувача у перші 1024 циліндри. Створіть розділ менший за будь-який розмір у 1024 циліндрах (варіюється від жорсткого диска до жорсткого диска). Але якщо створити перший розділ, більший за цю межу, є ймовірність, що файли завантажувача будуть розташовані поза 1024 циліндрами, і BIOS не зможе їх завантажити.

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

Ще однією причиною завантаження цих днів є:

• завантаження з NFS або NBD
• зашифрований розділ кореня
• / boot поділився між різними дистрибутивами