Яка причина встановлення кореневої файлової системи roв initramfs (і в initrd).
Наприклад, посібник Gitoo initramfs монтує кореневу файлову систему за допомогою:
mount -o ro /dev/sda1 /mnt/root
Чому б не наступне?
mount -o rw /dev/sda1 /mnt/root
Я бачу, що, мабуть, є вагомі причини (і це, мабуть, пов'язано switchroot), однак, здається, це ніде не задокументовано.
Відповіді:
Електронний диск (Initrd) зазвичай являє собою урізану версію кореневої файлової системи , що містить тільки те , що необхідно , щоб змонтувати дійсну кореневу файлову систему і руку від завантаження до нього.
Initrd існує тому, що в сучасних системах завантажувач не може бути досить розумним, щоб надійно знаходити кореневу файлову систему. Існує занадто багато можливостей для такої невеликої програми, як завантажувач. Розглянемо корінь NFS, нестандартні RAID-карти тощо. Завантажувач повинен виконувати свою роботу, використовуючи лише BIOS плюс будь-який код, який може бути забитий у завантажувальному секторі.
Інітард зберігається десь, де завантажувач може знайти, і це досить мало, що зайвий біт місця, як правило, нікого не турбує. (У невеликих вбудованих системах зазвичай немає "справжнього" кореня, а лише initrd.)
Інірт є дорогоцінним: його вміст повинен зберігатися за будь-яких умов, тому що якщо інітрд зламається, система не може завантажитися. Один з варіантів дизайну, який його дизайнери зробили для того, щоб забезпечити це завантажувачем завантаження initrd лише для читання. Є й інші принципи, які також працюють на цьому, наприклад, у випадку невеликих систем, де немає «справжнього» корінця, ви все одно змонтуєте окремо /tmp, /var/cacheі таке для зберігання речей. Зміна initrd робиться лише рідко, а потім слід робити дуже обережно.
Повертаючись до нормального нагоди , коли є це реальна коренева файлова система, вона спочатку встановлена тільки для читання , так як Initrd було. Потім він зберігається лише для читання якомога довше з тих самих причин. Будь-яке записування до справжнього кореня, яке потрібно зробити, відкладається до завантаження системи за бажанням або принаймні до пізнього процесу завантаження, коли цю перевагу неможливо виконати.
Найголовніше, що трапляється під час цієї фази лише для читання, - це перевірити кореневу файлову систему, щоб перевірити, чи не було вимкнено її. Це те, що завантажувач, безумовно, міг би зробити замість того, щоб залишити його в initrd, але що буде, якщо коренева файлова система не була відключена чисто? Тоді він повинен зателефонувати, fsckщоб перевірити і, можливо, виправити це. Отже, де б initrdвзяти fsck, якби він відповідав за цей крок, а не чекати, поки передача передачі "справжньому" кореню? Можна сказати, що вам потрібно скопіювати його fsckв той initrdмомент, коли його будуєте, але тепер він більший. І поверх того, що fsck ви будете копіювати? Системи Linux регулярно використовують десяток чи більше різних файлових систем. Ви копіюєте лише той, який потрібен для справжнього кореня на той моментinitrdстворено? Ви надуваєте розмір initrd, копіюючи в нього всі доступні fsck.fooпрограми, якщо пізніше коренева файлова система перейде на якийсь інший тип файлової системи, а хтось забуде відновити інтриду?
Архітектори завантажувальної системи Linux розумно вирішили не обтяжувати своїх проблем цими проблемами. Вони делегували перевірку реальної кореневої файлової системи реальній кореневій файловій системі, оскільки це в кращому становищі для цього, ніж initrd.
Після того як процес завантаження пройшов досить далеко, щоб це зробити безпечно, initrd витісняється з-під реального кореня на pivot_root(8), а файлова система перераховується в режимі читання-запису.
Однією з причин, про яку я можу задуматися, є запобігання корупції. Наприклад, ви можете монтувати файлову систему ext4 як ext2 (або навпаки), і це безпечно в ro-режимі, але може спричинити несумісні зміни формату, якщо встановити rw від initram.
О, і є ще одна причина: initramfs, ймовірно, не має fsck, але вам, можливо, доведеться перевірити файлову систему перед тим, як встановити її rw.