An unavailable memory device initialization system includes a memory controller device that is configured to determine whether a memory system includes unavailable memory devices during initialization operations. During the first initialization operations, a BIOS engine identifies unavailable memory device(s) in the memory system that were determined to be unavailable by the memory controller device during the first initialization operations and, in response, stores respective unavailable memory device identifier(s) associated with each unavailable memory device in a non-volatile storage subsystem. Subsequently, during second initialization operations and based on the respective unavailable memory device identifier(s) stored in the non-volatile storage subsystem, the BIOS engine generates a memory overlay that hides each unavailable memory device from the memory controller device such that the memory controller device determines that the memory system does not include any unavailable memory devices during the second initialization operations.

A processor can be configured to access boot firmware from a remote location independent from use of a chipset. After a processor powers-on or reboots, the processor can execute microcode. The microcode will cause the processor to train a link with a remote device. The remote device can provide the processor with access to boot firmware. The processor can copy the boot firmware to the processor's cache or memory. The processor will attempt to authenticate the boot firmware. If the boot firmware is authenticated, the processor executes the copy of the boot firmware.

Data is identified that defines a known good state for a current operating system. The identified data includes read-only sets that are not updated during operation of the computing device, and modifiable sets that can be updated during operation of the computing device. The read-only sets are captured on an opportunistic basis and the modifiable sets are captured when the computing device is to be rebooted. A first and second virtual disk are allocated as snapshots of the identified data. The first virtual disk is updated to generate an updated state. The updates to the first virtual disk are isolated from the second virtual disk. The second virtual disk is maintained as an immutable snapshot of the identified data. In response to a failed reboot with the updated state, the computing device reverts to the known good state using the snapshot of the identified data.

A feature is updated on a computing device. One or more composite image files are accessed that correspond to updates to be implemented in the computing device. The composite image files are signed containers. A runtime in-memory merge of the composite image files is performed. The merged composite image files are exposed as a read-only volume. The features are made available to the computing device. A system boot using the read-only volume can be initiated.

A data storage device includes a controller, a data storage unit, a microprocessor, and a network communication unit. The controller includes a firmware. The data storage unit includes a first system storage sector and a second system storage sector. The first system storage sector stores an original operating system, and the second system storage sector stores a backup operating system. When the data storage device receives an operating system differential file from a cloud management platform, the firmware updates the backup operating system in the second system storage sector to obtain a new version of backup operating system. Accordingly, the backup operating system of the data storage device can be quickly updated by downloading a small file size of the operating system differential file so as to enhance the convenience for the updating of the backup operating system.

A computer system is rebooted after updating a boot image without running platform firmware with its power-on self-test of system hardware devices and without retrieving all of the modules included in a boot image from an external source and reloading them into system memory. The reboot process includes the steps of loading one or more updated modules of the boot image into the system memory, executing the boot loader module to load for execution modules of the boot image including a system software kernel and the updated modules, and transferring execution control to the system software kernel.

In an approach to allowing a computer to boot from a user trusted device (UTD), the computer comprises a data storage device storing operating system (OS) services, and a version of an OS loader. The UTD is connectable to the computer and stores a boot loader, detectable by a firmware executing at the computer, and an OS loader, and wherein the UTD prevents an unauthenticated user to modify the boot loader and the OS loader stored thereon. The computer then, upon connection, lets the boot loader be detected by the firmware for execution of the boot loader at least partly at the computer, to cause to transfer the OS loader from the UTD to the computer, and executes the transferred OS loader at least partly from the computer, to execute at least one crypto driver for the OS, to start the OS services and complete booting of the computer.

In an aspect of the disclosure, a method, a computer-readable medium, and a computer system are provided. The computer system includes a baseboard management controller (BMC). The BMC receives a first message from a first remote device on a management network. The BMC determines whether the first message is directed to a storage service or fabric service running on a host of the BMC. The host is a storage device. The BMC extracts a service management command from the first message, when the first message is directed to the storage service or fabric service. The BMC sends, through a BMC communication channel to the host, a second message containing the service management command to the host. The BMC communication channel established for communicating baseboard management commands between the BMC and the host.

Trusted firmware on a host server is used for managing access to a hardware security module (HSM) connected to the host server. The HSM stores confidential information associated with an operating system. As part of access management, the firmware detects a boot device identifier associated with a boot device configured to boot the operating system on the host server. The firmware then receives a second boot device identifier from the HSM. The boot device identifier and the second boot device identifier are then compared by the firmware. Based on the comparison, the firmware determines that the boot device identifier matches with the second boot device identifier. Based on this determination, the firmware grants the operating system access to the HSM.

A method for resetting a memory in the computer system includes turning on the computer system, and a memory controller of the computer system executing a boot code to initialize the memory. After the memory controller executes the boot code, the memory controller updates a programmable initialization code according to the boot code to generate an updated programmable initialization code. After resetting the computer system, the memory controller executes the updated programmable initialization code to restore the memory back to a default state. After the memory is restored to the default state, the memory controller executes the boot code to initialize the memory again. After the memory is initialized, the memory controller controls the memory to perform a normal operation.