Почему initramfs монтирует корневую файловую систему, только для чтения

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

initrd существует, потому что в современных системах, загрузчик не может быть сделан достаточно умным для нахождения корневой файловой системы надежно. Существует только слишком много возможностей для такой небольшой программы как загрузчик для покрытия. Рассмотрите корень NFS, нестандартные платы RAID, и т.д. Загрузчик должен сделать, его работа с помощью только BIOS плюс любой код может быть переполнена в загрузочный сектор.

initrd хранится где-нибудь, загрузчик может найти, и это является достаточно маленьким, что дополнительный бит места, которое он занимает, обычно не беспокоит никого. (В маленьких встроенных системах обычно нет никакого "реального" корня, просто initrd.)

initrd драгоценен: его содержание должно быть сохранено при всех условиях, потому что, если initrd повреждается, система не может загрузиться. Одно проектное решение, которое его разработчики сделали для обеспечения этого, должно заставить загрузчик загрузить initrd только для чтения. Существуют другие принципы, которые работают к этому также, такому как это в случае маленьких систем, где нет никакого "реального" корня, Вы все еще монтируетесь отдельный /tmp, /var/cache и такой для хранения вещей. Изменение initrd делается только редко и затем должно быть сделано очень тщательно.

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

Самая важная вещь, которая происходит во время этой фазы только для чтения, состоит в том, что корневая файловая система проверяется, чтобы видеть, была ли она размонтирована чисто. Это - что-то, что загрузчик мог, конечно, сделать вместо того, чтобы оставить это initrd, но что затем происходит, если корневая файловая система не была размонтирована чисто? Затем это должно звонить fsck проверять и возможно фиксировать его. Так, где был бы initrd добраться fsck, если это было ответственно за этот шаг вместо того, чтобы ожидать до передачи "реальному" корню? Вы могли сказать, что необходимо скопировать fsck в initrd при создании его, но теперь он больше. И вдобавок ко всему, который fsck Вы скопируете? Системы Linux регулярно используют приблизительно дюжину различных файловых систем. Вы копируете только тот, необходимый для реального корня в то время initrd создается? Действительно ли Вы поднимаетесь на воздушном шаре размер initrd путем копирования всех доступных fsck.foo программы в него, в случае, если корневая файловая система позже перемещена в некоторый другой тип файловой системы, и кто-то забывает восстанавливать initrd?

Системные архитекторы начальной загрузки Linux мудро приняли решение не обременить initrd этими проблемами. Они делегировали проверку реальной корневой файловой системы к реальной корневой файловой системе, так как это находится в лучшем положении, чтобы сделать это, чем initrd.

После того как процесс начальной загрузки продолжился достаточно далеко, что безопасно сделать так, initrd подкачивается из-под реального корня с pivot_root(8), и файловая система повторно смонтирована в режиме чтения-записи.