Почему efi раздел смонтирован?

Существует несколько причин ESP, который, возможно, должен быть получен доступ во множестве обстоятельств:

• /boot/efi/EFI/ubuntu/grubx64.efi - Это - двоичный файл EFI GRUB 2, который должен быть заменен, если пакет GRUB обновляется.
• /boot/efi/EFI/ubuntu/grub.cfg - Это - конфигурационный файл GRUB, который делает очень мало; главным образом это загружается /boot/grub/grub.cfg. Это перенаправление сделано для включения "рычага" для систем Защищенной загрузки; без Защищенной загрузки, grubx64.efi двоичный файл может быть создан локально и указывает непосредственно на /boot/grub/grub.cfg; но как местоположение /boot/grub/grub.cfg варьируется (как замечено ESP) от одной системы до другого, помещая a grub.cfg файл на ESP необходим для Защищенной загрузки, которая не разрешает grubx64.efi быть созданным локально. По моему скромному мнению, имело бы больше смысла помещать основное grub.cfg и другие файлы поддержки GRUB на ESP, но разработчики, отвечающие за это, выбрали более консервативный подход, относительно того, что делает основанная на BIOS система. В любом случае, grub.cfg на ESP редко будет, если когда-либо, быть обновленным; но это могло бы быть необходимо в какой-то момент, особенно если пакет Debian GRUB обновляется.
• /boot/efi/EFI/ubuntu/shimx64.efi - Это - двоичный файл Контейнера, который требуется, чтобы Защищенная загрузка функционировала. Как двоичный файл GRUB 2, это могло бы быть обновлено обновлением пакета Debian, но shim-signed пакет.
• /boot/efi/EFI/ubuntu/MokManager.efi - Это - двоичный файл MokManager, который является инструментом поддержки Контейнера. Как Контейнер, это могло бы быть обновлено в обновлении пакета.
• /boot/efi/EFI/ubuntu/fwupx64.efi - Это - инструмент для помощи в автоматизации обновления встроенного микропрограммного обеспечения на основанном на EFI компьютере. Как с предыдущими двоичными файлами EFI, это могло бы быть обновлено обновлением пакета Debian.
• Файлы встроенного микропрограммного обеспечения EFI - Обновление встроенного микропрограммного обеспечения, вероятно, требует копировать микропрограммные файлы в ESP. Это могло быть ручным процессом или чем-то, что это по крайней мере частично автоматизировало использование Linux fwupdate двоичный файл и соответствие fwupx64.efi Двоичный файл EFI. (Я не на 100% положителен, что последний требует файлов записи к ESP, все же. Это является довольно новым и имеет минимальную документацию в этой точке.)
• Другие связанные с EFI инструменты - Программы как мой диспетчер начальной загрузки перенаходки и другие нестандартные диспетчеры начальной загрузки EFI и инструменты, возможно, должны были бы быть установлены на ESP. Чистое количество инструментов, которые, возможно, должны были бы быть установлены, является значительным, но большинство из них экзотично, таким образом, количество систем, на которые повлияли, является небольшим.
• Ручные корректировки конфигурационного файла - Если Вы хотите реконфигурировать загрузчик, Вы, возможно, должны считать его конфигурационный файл на ESP, отредактировать его и сохранить вырезанный файл назад. В этом отношении просто исследование конфигурации требует, чтобы ESP был смонтирован (хотя это могло быть монтирование только для чтения).
• Инструменты информации о системе - Инструменты как Сценарий Информации о Начальной загрузке читают конфигурационные файлы на ESP для генерации отчета о том, как система настроена. Сценарий Информации о Начальной загрузке, вероятно, монтирует ESP, даже если он размонтирован, чтобы сделать его работу, но я не на 100% положителен относительно этого. Могут быть другие инструменты, которые предполагают, что ESP уже смонтирован, и их функциональность была бы ухудшена, если бы это предположение не было встречено.

В сумме существует довольно много причин, что сама ОС или Вы могли бы хотеть или должны читать из или записать в ESP. Тем не менее эти причины - немногие достаточно в числе, что механизм, чтобы временно смонтировать ESP и затем размонтировать его при выполнении мог бы быть выгодным. Конечно, сценарий установки пакета Debian мог сделать задание, например, как мог автоматизированные инструменты, которые изменяют конфигурационные файлы на ESP. AFAIK, тем не менее, изменяющий состояние монтирования ESP, не находится на горизонте.

Обратите внимание, что ESP смонтирован с довольно строгими полномочиями по умолчанию. Недавно (запускающийся с 15,10 или 16.04, возможно - я не уверен точно, когда), смонтируйте, что полномочия были изменены так, чтобы только root может читать из /boot/efi. Даже к тому времени, только root мог записать в ESP, хотя прочитанные полномочия были более свободными. С тех пор root может смонтировать разделы, существует минимальное преимущество безопасности для отъезда ESP, размонтированного в этой точке, хотя было бы преимущество, в котором будет меньше риска повреждения файловой системы ESP из-за ошибки, сбоя питания, и т.д.