Out-of-band firmware update

Examples of performing an out-of-band firmware update of a server computing device are described. In an example, a first disk image is mounted onto a server computing device. The first disk image comprises a bootable firmware and is mounted in response to a mount command received through an out-of-band communication service. In another example, a second disk image is also mounted onto the server computing device. The second disk image is also mounted in response to another mount command received through the out-of-band communication service and is to provide a read-writable container, when mounted. Thereafter, a booting process of the server computing device may be initiated based on mounted first image to update the firmware of the server computing device. Information related to the update of the firmware is store in the read-writable container.

BACKGROUND

Server infrastructure, comprising one or more server computing devices, may be used for implementing a variety of functions, such as data storage, emails, or hosting applications. The server computing devices within the server infrastructure may have to be monitored and managed to ensure that the server computing devices continue to operate in a performant manner.

DETAILED DESCRIPTION

Expansive server infrastructures, such as large data centres, may include a plurality of server computing devices. The server computing devices may implement a variety of functions and services. The server computing devices are continually managed and monitored to ensure that the services are available, and that they continue to operate in an efficient manner. Management of the server computing devices may involve performing a host of functions related to hardware components, software, security, and backups. For example, management may involve detecting and replacing faulty hardware, updating software, etc.

The management related functions are implemented through a computer-implemented management system. The management system may remotely monitor and manage a plurality of server computing devices. In case the server computing devices exhibits any issues, the management systems may generate and transmit control instructions to the server computing device. The control instructions may result in performing certain functions to rectify an issue any one or more server computing devices may be experiencing.

The server computing devices may be managed remotely, through either ‘out-of-band’ or ‘in-band’ techniques. ‘In-band’ may typically refer to features or functionalities that may be accessed, initiated, or implemented through an operating system of the server computing device. On the other hand, ‘out-of-band’ techniques may refer to features or functionalities which may be enabled or initiated through a management sub-network of the server computing device, without accessing the operating system of the server computing device. To this end, the server computing devices may be provided with a management controller which may be remotely accessed by the management system. The management system, through out-of-band communication, may communicate with and control the management controller. The management controller may then implement certain functions on the server computing devices. Out-of-band management functions and communication may be based on protocol or specification implementing out-of-band management server management. Examples of such protocols include, but are not limited to, Intelligent Platform Management Interface (IPMI) protocol, and the Redfish® specification.

Out-of-band management techniques for server computing device are preferred since such techniques can provide access of the server computing device even if the server computing device is turned off, is inaccessible, or if their operating system is down or unresponsive. Through out-of-band techniques any server computing device which has access to another management network may be controlled and managed.

Management of server computing devices may include maintenance of hardware, as well as software components of the server computing device. For example, in relation to software components, firmware of the server computing device may be continually updated. The firmware may include executable code for controlling or operating a computing device, such as the server computing device.

Updating the firmware may involve initiating in-band, i.e., through the installed operating system (OS) of the server computing device, the firmware update process. For example, the firmware update process may be initiated through an executable command entered through a command line interface available through the operating system. In some cases, in-band firmware update may not preferred owing to a number of factors. For example, in-band access depends on the server computing devices being in a powered-on state. Also, in-band access is possible through the operating system of the server computing device. If the operating system has crashed or is experiencing errors, in-band access may not be possible. Furthermore, in-band techniques cannot be used for accessing firmware.

For certain server computing devices, out-of-band updating of firmware, although possible, has to be manually initiated through commands entered on interfaces of the operating system. The firmware update process may encounter one or more errors during execution. In some cases, an update process may not include monitoring the firmware update. Such approaches may also not provide a mechanism for determining cause of errors that may have occurred during the firmware update process. Tracking, monitoring, and communicating information pertaining to a firmware update process which is underway, may involve modifying the system firmware of the server computing device, itself. This may not be possible for existing assets within a server infrastructure.

To address the foregoing technical challenges, examples described herein relate to approaches for updating a firmware of a server computing device. The firmware update process may be effected through a management controller implemented within the server computing device. In an example, the firmware update process may be performed using an out-of-band communication between the management controller and a remote management system. The management system, amongst other functions, is to implement remote management and monitoring functions for the server computing device. Out-of-band communication may refer to functions or features that may be implemented through messaging between two entities (which in the present instance include the server computing device and the remote management system).

In operation, the management system may cause a first disk image and a second disk image to be mounted onto a server computing device. The mounting of the first disk image and the second disk image is performed in response to an out-of-band mount command transmitted by the management system and received by the server computing device. The first disk image comprises a bootable firmware bundle based on which firmware of the server computing device is to be updated. The second disk image is a read-writable (i.e., capable of being read from and written to) disk image based on which a read-writable disk space may be provided within the server computing device, once the second disk image is mounted.

Once the first disk image and the second disk image are mounted, the server computing device may initiate a boot-up process based on the bootable firmware mounted on the server computing device. The boot-up process may result in the firmware of the server computing device to be updated. In an example, any information pertaining to the firmware update process may be obtained in the form of logs and written to the read-writable disk space. Once the firmware update process is complete, the second disk image may be unmounted from the server computing device. The unmounted second disk image, which now includes the logs written to the read-writable disk space, may be mounted on the management system and may thereafter be used for retrieving the logs. In an example, the management system may provide a status of the firmware update to the user.

The present examples enable out-of-band updating of the firmware of the server computing device through the management system. Furthermore, such approaches also allow information pertaining to the firmware update process to be retrieved based on which the firmware update process may be further analyzed in case any errors occurred during the firmware update process. The present examples may be performed without any user intervention and without involving any changes to be made to the firmware of the server computing device. These and other examples are further described in conjunction with the accompanying figures.

FIG.1illustrates an example system102for performing out-of-band firmware update of a server computing devices. The system102may be communicatively coupled to the server computing device and is to provide management and monitoring capabilities independently of the operating system and other components of the server computing device. Examples of the components of the server computing device include, hardware components (e.g., the central processing unit or the CPU), and software components (e.g., firmware or operating system). Although described with respect to a single server computing device, the described examples may also be implemented for multiple server computing devices which may be present within a server infrastructure.

The system102includes a processor104, and a machine-readable storage medium106which is coupled to, and accessible by, the processor104. The system102may be implemented in any computing system, such as a server, desktop or a laptop computing device, a distributed computing enabled system, or the like. Although not depicted, the system102may include other components, such as interfaces to communicate over the network or with external storage or computing devices, display, input/output interfaces, operating systems, applications, data, and the like, which have not been described for brevity.

The processor104may be implemented as a dedicated processor, a shared processor, or a plurality of individual processors, some of which may be shared. For example, the processor104may include a microcontroller, a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), a data processing unit (DPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a system-on-a-chip (SOC), etc. The machine-readable storage medium106may be communicatively connected to the processor104. Among other capabilities, the processor104may fetch and execute computer-readable instructions, including instructions108, stored in the machine-readable storage medium106. The machine-readable storage medium106may include non-transitory computer-readable medium including, for example, volatile memory such as RAM (Random Access Memory), or non-volatile memory such as EPROM (Erasable Programmable Read Only Memory), flash memory, and the like. The instructions108may be executed to perform out-of-band firmware update of the server computing device.

In an example, as a result of the execution of instructions108, the system102may initially generate and transmit a mount command to the server computing device. In an example, the mount command is transmitted through an out-of-band communication services. Out-of-band communication services may refer to functions or features that may be implemented through messaging between two entities (which in the present instance, include the server computing device and the remote management system). Such communication services may be provided over a management channel which enables the management system to manage and monitor the server computing devices. Out-of-band management functions and communication may be based on protocol or specification implementing out-of-band management server computing devices. Examples of such protocols include, but are not limited to, Intelligent Platform Management Interface (IPMI) protocol, and the Redfish® specification.

Returning to the present example, the instructions110may be executed to cause mounting a first disk image and a second disk image onto the server computing device. In an example, the first disk image may include bootable firmware based on which the firmware of the server computing device is to be updated. When mounted, the bootable firmware within the first disk image may be provided within a partition in the server computing device. The second disk image on the other hand, when mounted, provides a read-writable disk space within the partition of the server computing device. The read-writable disk space is to store information related to updating a firmware of the server computing device. The instructions110for mounting the first disk image and the second disk image may either be specifically defined by an infrastructure administrator or may be implemented as services provided under out-of-band management protocols. For example, a virtual media service (e.g., of a management controller of the server computing device) may be used for mounting the first disk image and the second disk image onto the server computing device.

In an example, the bootable firmware may be specified as a boot target for the server computing device. The bootable firmware in the first disk image may include updated operational or control instructions for the server computing device. Once the first disk image and the second disk image are mounted, instructions112may be executed to cause the server computing device to be booted based on the mounted first disk image. Since the first disk image comprises the bootable firmware, boot-up of the server computing device updates the firmware of the server computing device. Thereafter, the instructions114may be executed to store information related to the firmware update process in the read-writable disk space provided within the server computing device.

FIG.2illustrates a computing environment200(also referred to herein as environment200) comprising a management system202and a server computing device204. The system202may be any computing system or a subsystem implementing one or more interface specifications or protocols, based on which the system202may perform out-of-band management of the server computing device204(also referred to herein as the server204). Although a single server204is depicted, the environment200may include multiple server computing devices similar to the server204, without limiting the present subject matter. The environment200may also refer to examples in which different elements of the environment200(e.g., the system202and the server204) are locally situated within a data center. The environment200may also refer to examples in which such elements are geographically dispersed with one or more of its elements (e.g., the system202, the server204or other server computing devices) being remote from other elements. Such different examples would still fall within the scope of the present subject matter.

The system202may communicate with the server204through a network206. The network206may be a private network or a public network and may be implemented as a wired network, a wireless network, or a combination of a wired and wireless network. Amongst other functions, the network206functions as an out-of-band network to allow out-of-band communication between the system202and the server204. In an example, the network206may provide an alternate secure and remote connection or a management channel between the system202and the server204during instances involving outages or disruptions to an otherwise operational communication channel through which the server204may be generally accessed.

The system202may further include a processor208, interfaces210, and memory212. The processor208may be implemented as microprocessors, microcomputers, microcontrollers, digital signal processors, CPUs, state machines, logic circuitries, and/or other devices that manipulate signals or requests based on operational instructions. The interfaces210may allow the connection or coupling of the system202with either a single computing device or multiple computing devices, such the server204, through a wired network, a wireless network, or a combination of a wired and wireless network. The interfaces210may also enable intercommunication between different logical as well as hardware components of the system202. The term interfaces210here is illustrative and is not to be construed as being limited to a certain type of interfaces.

The memory212may be a computer-readable medium, examples of which include volatile memory (e.g., RAM, also referred to as the main memory), and/or non-volatile memory (e.g., erasable programmable read-only memory, i.e., EPROM, flash memory, etc.). The memory212may be an external memory, or internal memory, such as a flash drive, a compact disk drive, an external hard disk drive, or the like. The memory212may further store data which either may be utilized or generated during the operation of the system202.

Similar to the system102, the system202may include instructions214. The system202may further include a management engine216and data218. In an example, the instructions214are fetched from the memory212and executed by the processor208included within the system202to implement the management engine216, which performs out-of-band management of the server204, as further described. During such functions, the management engine216may either utilize or generate data218for performing such functions.

The server204may also include a processor, memory, interfaces, and instructions (not depicted inFIG.2), similar to the components of the system202. In an example, the server204may include a management controller220. As will be explained further, server204may also implement an orchestration engine222during the out-of-band firmware update of the server204. The manner in which the orchestration engine222is implemented on the server204will be discussed and explained later.

The management engine216, the management controller220, and the orchestration engine222(collectively referred to as engines) may be implemented as a combination of hardware and programming, for example, programmable instructions to implement a variety of functionalities. In further examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the engines may be executable instructions, such as instructions214. Such instructions may be stored on a non-transitory machine-readable storage medium which may be coupled either directly with the system202or indirectly (for example, through networked means). In an example, the engines, if implemented as a hardware component, may include a processing resource, for example, either a single processor or a combination of multiple processors, to execute such instructions. In other examples, the engines may be implemented as electronic circuitry.

The management controller220(hereinafter referred to as controller220) enables out-of-band control of the server204, as well as communication between the server204and a management application (e.g., management engine216) on the system202. The out-of-band communication may be based on any protocol or specification which supports out-of-band management of the server204by the system202. Examples of such protocols include, but are not limited to, Intelligent Platform Management Interface (IPMI) protocol, and the Redfish® specification. The controller220may be a rack management controller in a server rack arrangement. In such a case, the server rack may house a plurality of server equipment. The rack management controller, in such an example, may gather operational information from the system board of such different equipment, and share the same with a management subsystem, such as the system202. In certain cases, the rack management controller may communicate with baseboard management controllers provided on the different equipment. In another example, controller220may refer to, and include, one or more baseboard management controllers, or a combination of the rack management controller and the baseboard management controllers, without limiting the scope of the present subject matter.

The system202may further include firmware disk image224and a read-writable disk image226. A disk image, in the context of computing, may be a computer processable file containing contents and structure of a volume, or of an entire data storage device (e.g., a hard disk drive, tape drive, floppy disk, optical disc, or USB flash drive).

The firmware disk image224may refer to a disk image of bootable firmware for the server204. The term bootable firmware may refer to a copy of firmware that is natively present in the server204. Such bootable firmware may be used for installing or reinstalling the firmware onto the server204, for example, in instances of fresh installations. The term bootable firmware may also refer to an updated firmware which is to be installed on the server204. Such updates may include incremental code which is to be deployed onto the server204or may refer to an amended or updated firmware which may be installed on the server204. The bootable firmware may also include executable code which when executed may invoke or activate executable instances or tasks for effecting and monitoring the boot-up process. The read-writable disk image226is to provide a read-writable disk space or read-writable disk image file system within the server204. In an example, the firmware disk image224and the read-writable disk image226may be provided by an infrastructure administrator. In another example, the read-writable disk image226may be created by the system202.

In operation, the management engine216may determine whether any firmware update is to be performed for the server204. Such a determination may be based on presence of a firmware disk image224within the system202or may be determined based on a command provided by the infrastructure administrator. Thereafter, the management engine216within the system202may initiate the firmware update process of the server204.

For performing the firmware update process, the server204may be powered down. While in the powered down state, the management engine216may communicate with the controller220of the server204through out-of-band communication over the network206to initiate the firmware update process. In an example, the management engine216may generate and transmit to the controller220, a mount command. The mount command when executed results in mounting the firmware disk image224and the read-writable disk image226onto a storage medium of the server204. In an example, the firmware disk image224and the read-writable disk image226may be mounted onto a partition228within the server204.

The mounting command may be processed by the controller220, and the server204may make the bootable firmware available as bootable firmware230within the partition228. Once available within the server204, the controller220may set the bootable firmware230as a boot target for the server204. Setting as a boot target enables initiating and performing the boot process based on the bootable firmware230as opposed to a native firmware which may be present within a memory of the server204.

With respect to the read-writable disk image226, the controller220may provide a read-writable container232(referred to as the container232) within the partition228. The read-writable container232may refer to a read-writable space corresponding to the read-writable disk image226within the partition228, to which data may be written. In an example, the container232may be a read-writable file system, or a file within a file system onto which data may be written and stored. Once the bootable firmware230and the container232are available, the management engine216may transmit control instructions to the controller220to power on the server204. As the server204is powered on, the bootable firmware230is detected as the boot target. The server204may then initiate the booting-up of the server204and the firmware update process based on the bootable firmware230.

As described previously, the bootable firmware230may include updated firmware or incremental code which is to be installed on the server204. The bootable firmware230may also include instructions which when executed may invoke or activate executable tasks for effecting and monitoring the boot-up process. In an example, orchestration engine222may be activated based on the bootable firmware230. The orchestration engine222may monitor the firmware update process. It may be noted that the orchestration engine222may not be natively present on the server204but may be invoked to execute on the server204through the bootable firmware230. Although originating from the bootable firmware230, the orchestration engine222may be implemented through any other mechanisms without deviating from the scope of the present subject matter.

The orchestration engine222during the course of the firmware update process, may monitor and capture firmware update related information. For example, such information may indicate a list of drivers, files, or other software components, which may have been successfully loaded or otherwise implemented onto the server204. Such information may also indicate components that may not have successfully loaded (or installed) or may include errors that may have occurred during the boot-up process. In an example, the orchestration engine222may record such updated related information as logs234. The logs234in turn are stored within the read-writable container232.

The orchestration engine222may continue to record the logs234in the container232. Once the boot-up process is completed, the read-writable disk image226may be unmounted from the partition228of the server204. At this stage, the read-writable disk image226includes the container232and the logs234stored therein. The orchestration engine222may then initiate the powering down of the server204. The unmounted read-writable disk image226may then be retrieved by the system202. Once retrieved, the read-writable disk image226may then be mounted by the system202. Mounting the read-writable disk image226onto the system202makes the logs234available to the system202. The logs234may thereafter be obtained by the system202.

The information thus obtained from the logs234may be presented to an infrastructure administrator for reviewing. In response to the reviewing, the infrastructure administrator may determine whether the firmware update process completed successfully or whether any had errors occurred. The infrastructure administrator may, based on the information available in the logs234may also be in a position to ascertain causative factors that may have resulted in errors (if they occur) during the firmware update process. In an example, the logs234may be analyzed based on executable instructions or other external applications. Such instructions or other external applications may be present in the system202or may be present in other systems, without deviating from the scope of the present subject.

The above approaches enable performing the firmware update process without any intervention from the infrastructure administrator. Furthermore, the entire process may be performed through out-of-band management techniques. The described examples also implement mechanisms which can monitor the firmware update process and may also enable the infrastructure administrator to ascertain whether any issues occurred during the same.

FIG.3illustrates an example method300for performing an out-of-band firmware update of a server computing device, in accordance with examples of the present subject matter. The order in which the above-mentioned methods are described is not intended to be construed as a limitation, and some of the described method blocks may be combined in a different order to implement the methods, or alternative methods.

The above-mentioned methods may be implemented as hardware or a combination of hardware and programming. The steps of such methods may be performed by either a processor-based system under the instruction of machine executable instructions stored on a non-transitory computer readable medium or by dedicated hardware circuits, microcontrollers, or logic circuits. For example, the methods may be performed by a computing device, which may include the management system202. In an example, the management system202may be communicatively coupled to a server computing device204through a network206.

At block302, a read-writable file system in a server computing device is provided to a server computing device in response to an out-of-band mount command for mounting a read-writable disk image onto the server computing device. For example, the system202may generate and transmit a mount command for mounting a firmware disk image224and a read-writable disk image226onto the server204. The mount command may be processed by the controller220of the server204to provide a read-writable file system within a partition (such as the partition228) on the server204. The read-writable file system, in an example, may be the container232. The container232provides a logical division on the partition228for storing data. The firmware disk image224may include bootable firmware which may be used for performing a firmware update process of the server204. Once mounted, the bootable firmware is available as bootable firmware230in the server204.

At block304, the server computing device may be booted-up based on the bootable firmware to initiate a firmware update process. For example, the management engine216may transmit control instructions to the controller220to power on the server204. Based on the received control instructions, the controller220may power on the server204, and boot-up the server204based on the bootable firmware230and initiate the firmware update process of the server204.

At block306, information pertaining to the firmware update process is written to the read-writable file system. In an example, the initiation of the firmware update process may result in activating the orchestration engine220based on the bootable firmware230. The orchestration engine222, may monitor and capture update related information, which may include information pertaining to drivers, files, or other software components, which may have been successfully loaded or otherwise installed onto the server204, during the firmware update process. In an example, the orchestration engine222may record such updated related information as logs234. The logs234in turn may be stored within the read-writable container232.

FIG.4illustrates an example method400for performing an out-of-band firmware update of a server computing device, in accordance with examples of the present subject matter. The order in which the above-mentioned methods are described is not intended to be construed as a limitation, and some of the described method blocks may be combined in a different order to implement the methods, or alternative methods. The method400is further described in the context of the environment200, which includes the management system202, which may perform out-of-band management of the server204.

At block402, presence of a firmware update to be performed may be determined. For example, the management engine216of the system202may make such a determination based on availability of a firmware disk image224within the system202or based on a command provided by an infrastructure administrator. Based on the determination, the management engine216within the system202may initiate the firmware update process of the server204. In an example, the server204may be powered down (i.e., switched off) in preparation for the firmware update process to be performed.

At block404, an out-of-band mount command is generated and transmitted by the management system to the server computing device. For example, the management engine216may generate and transmit an out-of-band mount command to the server204. The out-of-band mount command may be transmitted over the network206which provides an out-of-band management channel between the system202and the server204. The network206may be used in instances involving outages or disruptions to an otherwise operational communication channel through which the server204may be accessed. In an example, the mount command is for mounting a firmware disk image224and a read-writable disk image226onto the server204.

At block406, the first disk image may be mounted. For example, in response to the mount command received from the management engine216, the controller220may mount the firmware disk image224onto a partition228of the server204. The firmware disk image224may include bootable firmware for the server204. The term bootable firmware may refer to either firmware that is natively present in the server204, or to an updated version of the firmware which is to be installed on the server204. The updates may be in the form of incremental code which is to be deployed onto the server204or may refer to an amended or updated firmware which may be installed on the server204. Once mounted, the bootable firmware may be made available as bootable firmware230in the partition228.

At block408, the bootable firmware in the server computing device is set as a bootable target. For example, the controller220may set the bootable firmware230as a boot target for the server204. Setting as a boot target enables initiating the booting-up of the server204and performing the firmware update process based on the bootable firmware230.

At block410, the second disk image is mounted onto the server computing device. For example, the controller220, in response to the mount command received from the management engine216, may mount the read-writable disk image226onto the partition228of the server204to provide a container232. The container232provides a read-writable space within the partition228in the form of a read-writable file system, or a file within a file system, onto which data may be written and stored.

At block412, the server computing device may be booted up. In an example, the management engine216of the system202may generate and transmit control instructions to the controller220for powering on the server204. Since the server204is in the powered down state, such instructions are transmitted out-of-band over the network206. Based on the control instructions, the controller220may initiate powering on of the server204. As the server204is powered on, it detects the bootable firmware230as the boot target and initiates the booting-up of the server204based on the bootable firmware230. As the server204is booting-up, the firmware of the server204is updated based on the bootable firmware230.

At block414, tasks for effecting and monitoring the booting-up process may be activated during the boot-up process. For example, the bootable firmware230may also include instructions which when executed may invoke or activate executable tasks for effecting and monitoring the boot-up process. An example of such an executable task may be the orchestration engine222. The orchestration engine220may be activated based on the bootable firmware230. Once activated, the orchestration engine222may monitor the booting-up and the firmware update process of the server204.

At block416, information pertaining to the firmware update process are recorded to the read-writable container. In an example, the orchestration engine220monitors and captures update related information of the boot-up process of the server204, initiated by the controller220. Such information may indicate a list of drivers, files, or other software components, which may have been successfully loaded or otherwise implemented onto the server204, during the boot-up process. The information may also indicate components that may not have successfully loaded (or installed) or may include errors that may have occurred during the boot-up process. In an example, the orchestration engine222may record such updated related information as logs234. Once recorded, the orchestration engine220may write the logs234to the read-writable container232.

At block418, the second disk image may be unmounted. For example, the controller220may unmount the read-writable disk image226, which includes the container232, from the partition228of the server204. In an example, the read-writable disk image226may be unmounted on determining that the boot-up process has completed. Once the read-writable disk image226is unmounted, the orchestration engine222may initiate the powering down of the server204.

At block420, the firmware update related information is obtained by the management system. For example, the management engine216may retrieve the read-writable disk image226once the boot-up process has completed. The management engine216may thereafter mount the read-writable disk image226(which had been unmounted from the server204) onto the system202, and retrieve the logs234that had been recorded onto the container232. In an example, the retrieved information obtained from the logs234may be presented to the infrastructure administrator or any other user for reviewing and further analysis. For example, the infrastructure administrator may analyze the information retrieved from the logs234and determine whether the firmware update process completed successfully or whether any errors had occurred. The infrastructure administrator may ascertain causative factors that may have resulted in errors (if they occur) during the firmware update process. In an example, the logs234may be analyzed based on executable instructions or other external applications.

FIG.5illustrates a computing environment500implementing a non-transitory computer readable medium for managing data objects of different sizes within a distributed file system, as per an example. In an example, the computing environment500includes processor(s)502communicatively coupled to a non-transitory computer readable medium504through a communication link506. In an example implementation, the computing environment500may be or serve as, for example, the system102or the object gateway202. In an example, the processor(s)502may have a single processing resource or multiple processing resources for fetching and executing computer-readable instructions from the non-transitory computer readable medium504. The processor(s)502and the non-transitory computer readable medium504may be implemented, for example, in system102or the system202(as has been described in conjunction with the preceding figures).

The processor(s)502may include a microcontroller, a microprocessor, a CPU, an ASIC, an FPGA, an SOC, and/or other hardware device suitable for retrieval and/or execution of instructions from the non-transitory computer readable medium504to perform functions related to various examples. Additionally, or alternatively, the processor(s) may include or be coupled to electronic circuitry or dedicated logic for performing some or all of the functionality of the instructions described herein.

The non-transitory computer readable medium504may be, for example, an internal memory device or an external memory device, such as RAM, ROM, EEPROM, flash memory, a hard disk drive, an optical disc, or the like. The computer readable medium504may be disposed within a computer system, in which case the executable instructions may be deemed installed or embedded on the computer system. Alternatively, the computer readable medium504may be a portable (e.g., external) storage medium, and may be part of an installation package. In an example implementation, the communication link506may be a network communication link. The processor(s)502and the non-transitory computer readable medium504may also be communicatively coupled to a computing device508over the network.

In an example implementation, the non-transitory computer readable medium504includes a set of computer readable instructions510(referred to as instructions510) which may be accessed by the processor(s)502through the communication link506. The computer readable instructions500may be useful for implementing the object engine216that interacts with the distributed file system204.

Referring toFIG.5, in an example, the non-transitory computer readable medium504includes instructions510that when executed may cause a first disk image to be mounted onto a server computing device in response to a mount command. The mount command may be received through an out-of-band communication service. The first disk image comprises a bootable firmware which may be used for updating the firmware of the server computing device. In an example, the instructions510may cause the controller220to mount the firmware disk image224onto the server204. The mounting of the firmware disk image224is performed in response to an out-of-band mount command received from the management engine216of the system202. Once the firmware disk image224is mounted, the bootable firmware230include therein, is made available in a partition228of the server204.

The instructions510may be further executed to cause a second disk image to be mounted onto the server computing device, in response to another mount command received through the out-of-band communication service. The second disk image is such, that when mounted, is to provide a read-writable container within a partition of a memory of the server computing device. In an example, the read-writable container is to store information related to updating a firmware of the server computing device. For example, the management engine216may generate and transmit to the controller220, a mount command. The mount command when executed results in mounting the firmware disk image224and the read-writable disk image226onto a storage medium of the server204. In an example, the firmware disk image224and the read-writable disk image226may be mounted onto a partition228within the server204. Once mounted, the server204may make the bootable firmware available as bootable firmware230within the partition228. With respect to the read-writable disk image226, the controller220may provide a read-writable container232(referred to as the container232) within the partition228.

The instructions510may then be executed to initiate a boot-up and performing a firmware update of the server computing device based on the bootable firmware included in the first disk image. For example, the instructions510may cause the controller220to boot-up and update the firmware of the server204based on the bootable firmware230. Once the boot-up process is complete, the firmware of the server204is accordingly updated. In an example, the instructions510may cause information related to the update of firmware to be written to a read-writable container within the server computing device. For example, the orchestration engine222during the course of the firmware update process, may record firmware update related information as logs234in the container232. Such information, in an example, may indicate a list of drivers, files, or other software components, which may have been successfully loaded or otherwise implemented onto the server204. In another example, update related information may also indicate components that may not have successfully loaded or installed, or may include errors that may have occurred during the boot-up process. Such information may be retrieved by the system202for further analysis.

Although examples for the present disclosure have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed and explained as examples of the present disclosure.