Struct MountedImageRoot 

pub(crate) struct MountedImageRoot {
    esp_device: Utf8PathBuf,
    esp_mounted: Cell<bool>,
    _tmp: MountGuard,
    composefs: TempMount,
    pub(crate) esp_subdir: &'static str,
}

A composefs image attached to a temporary directory with the ESP and a tmpfs mounted inside it, ready for bootloader installation.

The composefs image (a detached fsmount(2) fd with no VFS path) is attached to a tmpdir via move_mount(2), giving us a real filesystem path that mount(2) and bootctl can use. The ESP is mounted at <tmpdir>/efi (if that directory exists in the image) or <tmpdir>/boot, per the Boot Loader Specification. A tmpfs is also mounted at <tmpdir>/tmp to provide a writable scratch area for tools invoked with --root.

Drop order matters: the tmpfs guard is declared before composefs so it is unmounted (and flushed) before the composefs root is detached.

Fields

esp_device: Utf8PathBuf

esp_mounted: Cell<bool>

_tmp: MountGuard

composefs: TempMount

esp_subdir: &'static str

Implementations

impl MountedImageRoot

pub(crate) fn new(composefs_mnt_fd: OwnedFd, device: &Device) -> Result<Self>

Find the ESP on device, attach the composefs image to a tmpdir, and mount the ESP and a scratch tmpfs inside it.

pub(crate) fn dir(&self) -> &Dir

The composefs image as a capability-safe directory (for file reads).

pub(crate) fn root_path(&self) -> &Path

Real filesystem path of the composefs tmpdir root.

pub(crate) fn open_esp_dir(&self) -> Result<Dir>

Open the mounted ESP as a capability-safe directory.

Fails unless called from within a call to Self::with_esp: the ESP is only actually mounted for the duration of that call, and esp_subdir otherwise refers to an ordinary (empty) directory that already exists directly in the composefs image.

pub(crate) fn with_esp<T>(&self, f: impl FnOnce(&Dir) -> Result<T>) -> Result<T>

Mount the ESP at <tmpdir>/<esp_subdir> for the duration of f, then unmount it again. Nothing is mounted there outside of calls to this method, so callers that need to invoke bootloader-install tooling that itself creates a private mount namespace (e.g. via ChrootCmd) can safely do so without risking this mount being shadowed/duplicated by that tooling’s own mount-namespace setup.