Для чего действительно нужен раздел / 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 был Basic In / Out - обычные программы вызывали прошивку для таких вещей, как рисование экрана и доступ к диску. Их называли прерываниями - старые шляпы могли помнить их лучше всего для острых ощущений восторга, которые они часто находили при назначении IRQ для своей новой точечной матрицы или USR.

INT13H

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

Система BIOS проверяет первые несколько байтов каждого найденного диска и ищет шаблон, который она распознает как главную загрузочную запись ( илиMBR ) . Это стандарт де-факто, который существует уже несколько десятилетий и включает в себя немного необработанного исполняемого двоичного файла, который записывается в заголовок диска. MBR помечает диск BIOS как загрузочный. Он перестанет проверять, когда найдет его, и практически один - это все, что вы получите без какой-нибудь хитрой хитрости. Когда он находит его, он отображает его в память и выполняет его (в режиме реального времени, но я все еще не собираюсь туда) .

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

Когда загрузчик читает текущее ядро ​​и выполняет его в памяти (как мы все молимся об этом каждый раз) , он, вероятно, сделает это, запросив BIOS через INT13Hвызов прерывания. И если этого не произойдет - многие более интересные загрузчики будут монтировать файловые системы в общепринятом смысле и выполнять код другим способом - тогда очень маловероятно, что загрузчик стал настолько причудливым без INT13Hили двух. Часто загрузчики должны загружать себя - или различные этапы - потому что 512 байтов, выделенных им вначале, не удовлетворяют даже их потребностям.

ЦЫПЛЕНОК И ЯЙЦО

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

Видите ли, после того, как ядро ​​выполнится и все его многочисленные подпрограммы для доступа и управления оборудованием будут запущены, все эти проблемы как бы исчезнут (или, по крайней мере, несколько изменятся) , потому что современные ОС получают полный контроль над системой, но до тех пор, пока они не сделают это, ограничения системы будут расширяться только настолько, насколько позволит встроенное ПО. Это говорит о многом - BIOS не сильно изменился с INT13H8086 года. Звонок является оригиналом 8086. Да, были (бесчисленные) расширения и хаки, конечно, но инновации ...?

ЛУЧШЕ И ЛУЧШЕ

Большинство изменений в BIOS в лучшем случае были просто повязками. Раньше это был жесткий диск, который должен был быть физически отображен - различные и специфические аспекты его геометрии использовались при сохранении или извлечении данных. Со временем обычный жесткий диск вырос до размера, который запрещал это. Даже просто абстрактная карта была слишком большой информацией для BIOS. Поскольку он может работать только в реальном режиме, BIOS ограничен 1 МБ на каждый регистр памяти. Увеличьте карту цилиндров на большее, чем это, или сделайте любое из ее свойств больше, чем можно было бы рассмотреть в стольких битах, и BIOS буквально потерян - за пределами.

Этот барьер встречался и преодолевался много раз. Каждый раз карта абстрагируется и кодируется новым, умным и менее точным способом. И поэтому в настоящее время для BIOS практически невозможно точно сопоставить диск. Адресация логических блоков в настоящее время является стандартом де-факто, хотя некоторые переводы Cylinder / Head / Sector (или CHS) все еще необходимы. То, что микропрограмма материнской платы потеряла в точности / ответственности, такие расширения абстрагировали и добавили к ответственности микропрограммы диска, чтобы заполнить пробелы.

Это игра в кошки-мышки, которая упоминается в вашем вопросе. Когда BIOS не может понять диск за определенной точкой из-за его огромного размера, тогда любые данные, которые вы, возможно, захотите получить для себя при загрузке, например, загрузчик или ядро, лучше не располагать за этой точкой. Это откуда /bootвзялось.

МОЖЕТ БЫТЬ АКТУАЛЬНО ЛУЧШЕ

В наши дни такие вещи, к счастью, не имеют отношения к гибели BIOS. Прошло 30 лет, но в последние несколько лет он был в значительной степени заменен стандартом UEFI (или EFI 2.0) . UEFI обеспечивает монтирование с первой минуты, он инициализируется в защищенном режиме, включает собственный загрузчик, обеспечивает постоянную перезагрузку для хранения переменных на флэш-памяти, он может обрабатывать не более десятка зетабайт или что угодно на диск ... и многое другое остальное. Это далеко от совершенства, но это значительное улучшение по сравнению с предшественником.

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

И поэтому отдельный /bootраздел, вероятно, не должен беспокоить вас слишком сильно , и если вы находитесь в системе EFI, то, возможно, у вас уже есть аналог в разделе системы EFI, так как это является требованием для загрузки режима EFI.

То, что /bootкаталог существует, исторически определено и оттуда «исправлено» в Стандарте иерархии файловой системы . Наличие такого стандарта позволяет программам (и системным администраторам) ожидать определенные файлы в определенных местах. В этом случае файлы, связанные с процессом загрузки.

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

Также может быть очень удобно иметь отдельный раздел / boot. На моей машине у меня есть много дистрибутивов и резервных копий, каждый в своем собственном разделе, но все они имеют один и тот же раздел / boot, где находятся все ядра для всех ОС. Кроме того, все дистрибутивы указывают на мою единственную копию 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 поделился между разными дистрибутивами