Struct RecoverySynchronousProxy

Source

pub struct RecoverySynchronousProxy { /* private fields */ }

Implementations§

Source §

pub fn wait_for_event( &self, deadline: MonotonicInstant, ) -> Result<RecoveryEvent, Error>

Waits until an event arrives and returns it. It is safe for other threads to make concurrent requests while waiting for an event.

Source

pub fn init_system_partition_table( &self, partitions: &[PartitionInfo], ___deadline: MonotonicInstant, ) -> Result<RecoveryInitSystemPartitionTableResult, Error>

Wipes and re-initializes the system partition table. This is a destructive operation!

Source

pub fn write_data_file( &self, filename: &str, payload: Vmo, ___deadline: MonotonicInstant, ) -> Result<RecoveryWriteDataFileResult, Error>

Writes filename into the data partition with contents from payload, formatting the data partition if it isn’t already formatted. Overwrites file if it already exists.

This can only be called while the data partition isn’t already mounted, which is typically in recovery builds where fshost is running with the ramdisk_image flag set.

Source

pub fn format_system_blob_volume( &self, ___deadline: MonotonicInstant, ) -> Result<RecoveryFormatSystemBlobVolumeResult, Error>

Formats the blob volume in the system container. If the system container does not have a blob volume, a new one will be created. All existing blobs will be deleted. If the system container is corrupt or unmountable, this function will have no effect and will leave the disk intact.

WARNING: This can cause irreversible data loss and can render a device unbootable.

Source

pub fn mount_system_blob_volume( &self, blob_exposed_dir: ServerEnd<DirectoryMarker>, ___deadline: MonotonicInstant, ) -> Result<RecoveryMountSystemBlobVolumeResult, Error>

Mounts the system container’s blob volume, and returns a handle to the blob volume’s exposed directory to facilitate writing a new system. The system container will remain mounted as long as blob_exposed_dir is kept open. Only the blob volume will be mounted.

Source

pub fn get_blob_image_handle( &self, ___deadline: MonotonicInstant, ) -> Result<RecoveryGetBlobImageHandleResult, Error>

Obtains a handle to a file where a new system blob volume can be written. The contents of the file must be a valid fxfs partition image containing a blob volume. The existing blob volume will remain unmodified until the system is rebooted, or InstallBlobImage is called. The system container will remain mounted as long as mount_token is kept open. NOTE: This method will delete any existing image data cached on disk. Callers are responsible for keeping the returned image_file and mount_token alive until the system image has been fully written and flushed to disk.

§Errors

ZX_ERR_IO_DATA_INTEGRITY: An existing filesystem was found on the device, but it could not be mounted. This indicates that the filesystem is possibly corrupt, or has a newer on-disk version than the recovery image. To avoid unintended data loss, the user should explicitly initiate any remedial action, such as wiping the device or using a newer image.
ZX_ERR_INTERNAL: An internal error occured; see fshost logs for more context.

Source

pub fn install_blob_image( &self, ___deadline: MonotonicInstant, ) -> Result<RecoveryInstallBlobImageResult, Error>

Installs the blob volume previously written via GetBlobImageHandle, replacing the existing blob volume in the system container. On failure, the existing blob volume will remain intact, and the written image will be deleted to free space. A new blob image can then be written and the installation process restarted. If no blob volume has been written, this will have no effect. This function will block until the system container is unmounted.