Как ядро ​​монтирует корневой раздел?

Мой вопрос касается загрузки системы Linux из отдельного раздела / boot. Если большинство файлов конфигурации находятся в отдельном разделе /, как ядро ​​правильно монтирует его во время загрузки?

Любая проработка этого была бы великолепна. Я чувствую, что мне не хватает чего-то простого. В основном меня интересует процесс и порядок операций.

Благодарность!

РЕДАКТИРОВАТЬ: Я думаю, что мне нужно было спросить больше о файле dev, который используется в параметре корневого ядра. Например, скажем, я задаю свой корневой параметр как root = / dev / sda2. Как ядро ​​отображает файл / dev / sda2?

Linux изначально загружается с RAM- initrdдиска (называемого , для "INITial RamDisk") как /. Этого диска достаточно, чтобы найти настоящий корневой раздел (включая любые необходимые драйверы и модули файловой системы). Он монтирует корневой раздел во временную точку монтирования на initrd, а затем вызывает, pivot_root(8)чтобы поменять местами корневую и временную точки монтирования, оставляя initrdположение для umountредактирования и фактическую корневую файловую систему включенной /.

В древние времена ядро ​​было жестко запрограммировано, чтобы знать основной / младший номер устройства root fs, и монтировало это устройство после инициализации всех драйверов устройств, которые были встроены в ядро. rdevУтилита может быть использована для изменения количества корневого устройства в образе ядра без необходимости перекомпилировать его.

В конце концов появились загрузчики, которые могли передать командную строку ядру. Если root=аргумент был передан, это говорит ядру, где находится корень fs вместо встроенного значения. Драйверы, необходимые для доступа, должны быть встроены в ядро. Несмотря на то, что аргумент выглядит как обычный узел устройства в /devкаталоге, очевидно, что нет /devкаталога до монтирования корневого fs, поэтому ядро ​​не может искать там узел dev. Вместо этого некоторые хорошо известные имена устройств жестко запрограммированы в ядре, поэтому строку можно преобразовать в номер устройства. Из-за этого ядро ​​может распознавать такие вещи, как /dev/sda1, но не более экзотические вещи, такие /dev/mapper/vg0-rootкак UUID тома или тома.

Позже initrdпришло в картину. Наряду с ядром загрузчик будет загружать initrdобраз, представляющий собой сжатый образ файловой системы (образ gzipped ext2, образ gzipped romfs, в конечном итоге squashfs стал доминирующим). Ядро распаковывает этот образ в виртуальный диск и монтирует виртуальный диск как корень fs. Этот образ содержит некоторые дополнительные драйверы и загрузочные скрипты вместо реальных init. Эти загрузочные сценарии выполняли различные задачи для распознавания оборудования, активации таких вещей, как raid-массивы и LVM, обнаружение UUID и синтаксический анализ командной строки ядра, чтобы найти реальный корень, который теперь можно указывать с помощью UUID, метки тома и других сложных вещей. Затем он смонтировал настоящий root-файл /initrd, затем выполнил pivot_rootсистемный вызов для замены ядра /и/initrd, затем exec /sbin/initдля реального корня, который затем размонтирует /initrdи освободит виртуальный диск.

Наконец, сегодня у нас есть initramfs. Это похоже на initrd, но вместо сжатого образа файловой системы, загружаемого в виртуальный диск, это сжатый архив cpio. Tmpfs монтируется как корень, и архив там извлекается. Вместо использования pivot_root, которое считалось грязным хаком, initramfsзагрузочные скрипты монтируют настоящий корень /root, удаляют все файлы в корне tmpfs, затем chrootв /rootи исполняют /sbin/init.

Похоже, вы спрашиваете, как ядро ​​«знает», какой раздел является корневым разделом, без доступа к файлам конфигурации в / etc.

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

Один из этих вариантов командной строки root, где вы можете указать корневую файловую систему, то есть root=/dev/sda1.

Если ядро ​​использует initrd, загрузчик отвечает за то, чтобы сообщить ядру, где оно находится, или помещает initrd в стандартную область памяти (я думаю) - по крайней мере, так работает на моем Guruplug.

Вполне возможно не указывать его, а затем сразу начать паниковать с ядром, жалуясь на то, что он не может найти корневую файловую систему.

Могут быть и другие способы передачи этой опции ядру.

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

Например, в Grub's menu.lst:

kernel /boot/linux root=/dev/sda2

Да ладно, GRUB не «монтирует» / boot, он просто читает «menu.lst» и некоторые модули, он также не является частью ядра LINUX. Когда вы вызываете ядро, вы передаете «корневой» аргумент с корневым разделом. В худшем случае ядро ​​знает, что just / boot был смонтирован (LOL).

Далее: geekosaur прав, Linux использует исходный псевдодиск в формате сжатого изображения, а затем монтирует реальную корневую файловую систему с помощью вызова pivot_root. Таким образом, Linux начинает работать с образа, а затем с вашего локального диска.

Загрузчик, будь то grub или lilo или что-то еще, сообщает ядру, где искать с root=флагом, и дополнительно загружает начальный виртуальный диск в память через initrdперед загрузкой ядра.

Затем ядро ​​загружает, тестирует свое оборудование и драйверы устройств и просматривает систему на предмет того, что оно может видеть (вы можете просмотреть эту диагностическую информацию, набрав dmesg; в настоящее время оно, вероятно, прокручивается слишком быстро, чтобы видеть), а затем пытается смонтировать раздел, упомянутый в root=параметр.

Если присутствует initrd, он монтируется первым, и все модули / драйверы на нем загружаются и проверяются перед монтированием корневой файловой системы. Таким образом, вы можете скомпилировать драйверы для ваших жестких дисков в виде модулей и при этом иметь возможность загружаться.