TWI808713B - Method and system for deploying operating environments - Google Patents

Abstract

This invention provides an IHS, a method for deploying the IHS, and a computer implemented method for enabling an information handling system to be operated with multiple environments. File system attributes in the virtual image files are included in the EFI bootloader to check if a child virtual image file is failed before the operating system in the child virtual image file is loaded.

Description

Method and system for deploying an operating environment

The present invention relates to an information holding system and a method for deploying an information processing system, and more particularly to a computer-implemented method for enabling an information processing system to operate in a variety of environments.

As the value and use of information continue to increase, individuals and businesses seek more ways to process and store information. One option available to the user is an Information Handling System (IHS; Information Handling System). An information handling system typically processes, compiles, stores and/or communicates information or data for business, personal or other purposes, thereby allowing users to exploit the value of the information. As the technical and information processing needs and requirements vary between different users or applications, information processing systems may also differ in terms of what information to process, how to process information, how much information needs to be processed, stored or communicated, and the speed and efficiency with which information may be processed, stored or transmitted. Different information handling systems allow information handling systems to be general-purpose or configured for a specific user or purpose, such as financial transaction processing, airline reservations, enterprise data storage, or global communications.

Unified Extensible Firmware Interface (UEFI; Unified Extensible Firmware Interface) is a specification for defining a software interface (software interface) between an operating system (OS; Operating System) and platform firmware (platform firmware). Unified Extensible Firmware Interface replaces the Basic Input/Output System (BIOS; Basic Input/Output System). UEF provides a standard framework and data structures to manage initialization and configuration of components, booting of platform resources, and transfer of control to the operating system. The UEFI specification allows the platform firmware to be extended by loading UEFI drivers and applications.

The operating system is the basis for operating an information processing system. However, the complexity of operating system installation includes different applications from different vendors with different hardware configurations or resources to meet various needs. For example, an information processing system may need to have multiple operating systems, such as Microsoft's Windows (Windows) or Linux's UBUNTU for teaching. The disadvantage of multiple operating systems makes the maintenance of information processing systems more difficult.

On the other hand, although teaching seems to be the main goal of many users when applying IHS, teachers choose IHS according to their needs, hoping that the maintenance of IHS will be made easier. For example, in a computer classroom, the computer teacher would like to have all the IHSs; in this way, the IHSs can be targeted to specific students, or kept in the same configuration at the beginning of each term or day. When managing several computers, it is helpful for the administrator to have a computer with a management system. Furthermore, for an information processing system serving as a teaching assistant in a classroom, it is important to effectively maintain information sensitivity because users include teachers and students with different security requirements. Therefore, it is difficult to maintain the information processing system. If the classroom computer is used as an administrative computer, the recovery card needs to be removed to install the administrative software system. All of the above changes increase the complexity of using the information handling system.

Due to the business needs of information technology (IT; Information Technology), sometimes it may be necessary to test different operating environments or restore the previous version of the operating environment as soon as possible to meet 24-hour manufacturing. However, if the operating environment is processed under a virtual machine, the performance of the computer will be reduced and the capacity of the storage device will be significantly increased. In addition, some manufacturing equipment must communicate with information processing systems with native operating environments, so virtual machines is not an appropriate solution.

An object of the present invention is to provide an information processing system with multiple operating environments, wherein the multiple environments can include different applications and data under one operating system.

An object of the present invention is to provide an information processing system with multiple operating systems.

It is an object of the present invention to provide a method for deploying an information processing system with multiple operating environments, wherein bootable virtual image files and dependencies between virtual image files can be checked before loading the operating system.

It is an object of the present invention to provide a method of deploying multiple information processing systems with significant efficiency.

It is an object of the present invention to provide a method of restoring an information processing system that requires no hardware, requires less storage capacity, and is significantly more efficient.

An object of the present invention is to provide a method for remotely deploying or recovering an information processing system.

It is an object of the present invention to provide a computer-implemented method for enabling an information processing system to operate in a variety of environments.

In the present invention, since the file system attributes in the bootable virtual image file are included in the unified extensible firmware interface bootloader, the data and information in the bootable virtual image file can be checked, confirmed and compared.

Accordingly, the present invention provides a method for deploying an information processing system, comprising the following steps: establishing a unified extensible firmware in an extensible firmware interface (EFI; Extensible Firmware Interface) system partition (system partition) in a storage device (storage) Interface (UEFI) boot loader (bootloader), which has a file system (file system) attribute (attribute) of a primary operating system (primary operating system); creating a first bootable parent virtual image file (first bootable parent virtual image file) with the above-mentioned primary operating system in a partition of the aforementioned storage device; The virtual image file differencing is a first child virtual image file (first child virtual image file) in the aforementioned partition in the aforementioned storage device.

In the deployment method of the present invention, when a first data is added to the first child virtual image file, a pair of first child virtual image files are differentially divided into partitions of a first grandchild virtual image file (first grandchild virtual image file) in the storage device.

In the deployment method of the present invention, when a second application program is installed in the first parent bootable virtual image file, dividing the first parent bootable virtual image file into a partition of a second child virtual image file in the storage device.

In the deployment method of the present invention, when a second data is added to the second sub-virtual image file, the second sub-virtual image file is divided into a partition of the second grandchild virtual image file in the storage device.

The deployment method of the present invention further includes creating a second master bootable virtual image file with a secondary operating system in the partition of the storage area.

The deployment method of the present invention further includes a step of including the file system attributes of the second operating system in the UEFI bootloader.

The present invention also provides a method for deploying a plurality of information processing systems, including the following steps: copying the extensible firmware interface boot-loading system to the plurality of storage devices of the plurality of information processing systems; copying the first parent bootable virtual image file to the plurality of above-mentioned The aforementioned plurality of storage devices of the information processing system; and copying the first sub-virtual image file to the aforementioned plurality of storage devices of the aforementioned plurality of information processing systems.

The present invention further includes a method for verifying the dependency between the first parent bootable virtual image file, the first/second child, and the first/second grandchild virtual image file, comprising the following steps: confirming the dependency between the first parent bootable virtual image file and the first child virtual image file; confirming the dependency between the first child virtual image file and the first grandchild virtual image file; confirming the dependency between the first parent bootable virtual image file and the second child virtual image file; and confirming the dependency between the second child virtual image file and the second grandchild virtual image file.

In an embodiment of the present invention, the above step of creating a UEFI bootloader is executed in a living operating system environment.

In an embodiment of the present invention, the above-mentioned step of creating the first mother bootable virtual image file is executed in a native operating system environment.

In an embodiment of the present invention, wherein the above-mentioned UEFI bootloader is restored in the environment of the native operating system, when the UEFUI bootloader is covered by an operating system boot manager.

In an embodiment of the present invention, the above-mentioned Unified Extensible Firmware Interface boot loader (UEFI boot loader) and the first mother bootable virtual image file are provided through a cloud storage.

The present invention further includes a method for verifying the dependency between the first parent bootable virtual image file and the first child virtual image file, comprising a step of confirming the dependency between the first parent bootable virtual image file and the first child virtual image file.

In one embodiment of the present invention, the above-mentioned confirming step includes: confirming the dynamic disk header (dynamic disk header) between the first parent bootable virtual image file and the first child virtual image file disk headers) are the same; and confirm whether a Universally Unique Identifier (UUID; Universally Unique Identifier) in the dynamic disk header of the first sub-virtual image file is the same as a Universally Unique Identifier (UUID) in a hard disk footer of the first parent bootable virtual image file.

In an embodiment of the present invention, a data is added to the first sub-virtual image file in the above-mentioned difference step.

The present invention also provides a method for deploying an information processing system, comprising the following steps: establishing a boot management program and a configuration module in an extensible interface partition of a storage device; executing a cloud thread command to download a designated bootable virtual image file in the partition of the storage device; attaching a flag to the designated bootable virtual image file and the configuration module; and restarting the information processing system.

The present invention also provides a computer-implemented method, which is used to enable an information processing system to operate in multiple environments, including the following steps: when the above-mentioned information processing system is turned on, confirm whether all components of the aforementioned information processing system are configured correctly through a unified extensible firmware interface (UEFI) read only memory (ROM; Read Only Memory); boot loader), which has a parent bootable virtual image file, a first sub-virtual image file and a second sub-virtual image file in a partition in the above-mentioned storage device; wherein the above-mentioned first and second sub-virtual image files are generated from the aforementioned mother bootable virtual image file, wherein the above-mentioned first virtual image file is before the aforementioned second virtual image file; confirm the dependency between the above-mentioned parent bootable virtual image file and the aforementioned second sub-virtual image file; determine that the above-mentioned second sub-virtual image file is a boot component; and load the operating system of the above-mentioned boot component.

In one embodiment of the present invention, wherein the above-mentioned Extensible Firmware Interface boot loader (UEFI bootloader) includes the above-mentioned operations in the aforementioned mother bootable virtual image file System file system properties.

In one embodiment of the present invention, the above-mentioned confirmation step includes: confirming whether the dynamic disk headers (dynamic disk headers) between the first parent bootable virtual image file and the second child virtual image file are the same; Whether the identification (UUID) characters are the same.

The computer-implemented method of the present invention further includes a step of duplicating the above-mentioned first sub-virtual image file into the aforementioned second sub-virtual image file when the second sub-virtual image file fails in the above-mentioned confirming step.

In an embodiment of the present invention, the above-mentioned covering steps are performed automatically.

The present invention also provides an information processing system, comprising: a storage device for storing at least one Unified Extensible Firmware Interface boot loader (UEFI bootloader); a processor interactively coupled with the storage device, the processor having firmware to execute on it, so that the aforementioned information processing system can operate in multiple environments, wherein the firmware configures the aforementioned processor to: when the aforementioned information processing system is powered on, via a Unified Extensible Firmware Interface (UEFI) read-only memory (ROM) to confirm whether all components of the aforementioned information processing system are The configuration is correct; in an Extensible Firmware Interface system partition (UEFI partition) in a storage device, a unified Extensible Firmware Interface bootloader (UEFI bootloader) is loaded, which has a parent bootable virtual image file, a first sub-virtual image file and a second sub-virtual image file in a partition in the aforementioned storage device; wherein the above-mentioned first and second sub-virtual image files are generated from the aforementioned parent bootable virtual image file, wherein the first virtual image file is ahead of the second virtual image file; confirm the above-mentioned parent The dependency between the bootable virtual image file and the aforementioned second sub-virtual image file; determining the aforementioned second sub-virtual image file as a bootable component; and loading an operating system of the aforementioned bootable component.

In an embodiment of the present invention, wherein the above-mentioned UEFI bootloader includes the file system attribute of the operating system in the parent bootable virtual image file.

In one embodiment of the present invention, wherein the above-mentioned firmware configuration processor is further configured in confirming dependencies: confirming whether the dynamic disk header between the first parent bootable virtual image file and the second child virtual image file is the same;

In an embodiment of the present invention, the above-mentioned firmware further configures the processor to overwrite the first sub-virtual image file into the second sub-virtual image file.

In an embodiment of the present invention, the above-mentioned first sub-virtual image file is automatically overwritten.

The above Summary contains simplifications, generalizations, and omissions of detail and is not intended to be a complete description of claimed subject matter but rather to provide a brief summary of some of the functionality associated therewith. Other systems, methods, functions, features and advantages of the claimed subject matter are or will become apparent to those skilled in the art upon examination of the ensuing illustrations and detailed written description.

10: Cloud storage

20: Mass copying

100: Information Processing System

102: Processor

106: Front busbar

108:Platform Control Hub

110: Graphics device

112: graphic bus

113: Random access memory

114: System memory

116: Memory bus

120: storage device

122: Default unified extensible firmware interface disk

124: Disk 0

125: Extensible firmware interface system partition

126:Microsoft reserved area

127: Primary partition

130: port, pin (pin), connector

134: busbar

136: Peripheral component interconnection standard components

138: Peripheral component interconnection standard bus

139: Non-volatile memory

140:BIOS/Unified Extensible Firmware Interface

142: Super I/O

144: Baseboard Management Controller

146: Low pin count bus

160: Network interface equipment

162: Peripheral component interconnection standard bus

170: Network

180: remote access controller

182: Peripheral component interconnection standard bus

184: Remote access controller memory

186: Sideband bus

202: Application

204: Operating System

250: BIOS/Unified Extensible Firmware Interface

252: Unified Extensible Firmware Interface Runtime Service Table

253: Unified Extensible Firmware Interface Boot Service

254: Unified Extensible Firmware Interface Memory Mapping

255: Multiple Memory Descriptor Capability Bits

256:Advanced configuration and power interface table

260:Firmware

262:Boot management program

262-1: Unified Extensible Firmware Interface Boot Management Program for Information Processing System

262-2: OS Boot Manager

264: Operating system loader

266: Configuration module

268:Boot menu

300: Timing diagram or phase diagram of power-on operation

310: Start-up operation includes safety phase

312: Pre-validator

320: Pre-extensible firmware interface initialization phase

322: Pre-extensible firmware interface initialization phase core

324: CPU initialization

326: Chipset initialization

328: Board resource initialization

330: Driver execution environment stage

334: Driver

332:EFI Driver Scheduler

340: Boot device selection stage

350:Transient system loading phase

352: Bootloader

354: start menu

356: Self-generated operating system environment

360: Runtime Phase

362: Operating system running phase

400: Desktop layering

402: operating system layer

404: Application layer

406: data layer

412: operating system layer

414: Application layer

416: data layer

422: operating system layer

424: application layer

502: virtual disk

504: virtual disk

506: virtual disk

A description of exemplary embodiments can be shown in conjunction with the following figures. It should be understood that, for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to other elements. Embodiments incorporating the teachings of this disclosure are shown and described with respect to the figures presented herein, in which:

FIG. 1 illustrates one embodiment of an information processing system in which various aspects of the present disclosure can be implemented, according to one or more embodiments of the present invention.

Figure 2A illustrates information processing according to one or more embodiments of the present invention Sample contents of system memory in the system.

FIG. 2B illustrates an example of the contents of a non-volatile memory, including firmware for booting an information processing system, according to one or more embodiments of the present invention.

FIG. 3A is a timing diagram or a phase diagram of Unified Extensible Firmware Interface (UEFI) booting for a traditional information processing system.

FIG. 3B is a timing diagram or a phase diagram of Unified Extensible Firmware Interface (UEFI) booting of an information processing system according to an embodiment of the present invention.

FIG. 3C is a timing diagram or a phase diagram of Unified Extensible Firmware Interface (UEFI) booting of an information processing system according to another embodiment of the present invention.

FIG. 4 is a schematic diagram illustrating the boot operation of an information processing system by using a bootable virtual image file according to an embodiment of the present invention.

FIG. 5 is a schematic diagram illustrating a bootable storage with partitions according to an embodiment of the present invention.

Fig. 6 is an embodiment of the present invention, which shows the relationship between many information processing systems, cloud storage, and physical hard disks with bootable virtual image files.

FIG. 7 is a flowchart illustrating one of the methods for deploying an information handling system, according to one embodiment of the present invention.

FIG. 8 is a flowchart illustrating a method for checking dependencies among bootable virtual images according to an embodiment of the present invention.

FIG. 9 is a flowchart illustrating an example of a detailed inspection method for confirming bootable virtual image file data according to an embodiment of the present invention.

Figure 10 is a flowchart illustrating one example of a method of enabling an information handling system to operate in various configurations, according to one embodiment of the present invention.

The illustrated embodiments provide a deployment method, an information processing system and subsystems for enabling the information processing system to operate using different operating system environments, different application environments, or different information data.

In the following detailed description of the illustrated embodiments of the disclosure, specific example embodiments in which the disclosure may be practiced are described in sufficient detail to enable those skilled in the art to practice the embodiments of the disclosure. For example, specific details such as specific method sequences, structures, elements and connections have been presented. It is understood, however, that the specific details presented need not be utilized in practicing embodiments of the disclosure. And it is to be understood that other embodiments may be utilized and logical, architectural, procedural, mechanical, electrical, and other changes may be made without departing from the general scope of the present disclosure. Accordingly, the following detailed description should not be taken in a limiting sense, and the scope of the disclosure is defined by the appended claims and their equivalents.

References in the specification to "one embodiment," "an example," "embodiments," or "one or more embodiments" are intended to indicate a particular feature, structure, or characteristic described in connection with the embodiments, including at least one embodiment in this disclosure. The appearances of these phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Furthermore, various features were described that may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements of some embodiments but not others.

It should be understood that the use of specific component, element and/or parameter names and/or their corresponding acronyms, such as those described herein to implement utility, logic and/or firmware, is by way of example only and is not meant to imply any limitation to the described embodiments. Embodiments may therefore be described using different nomenclature and/or terms used to describe components, devices, parameters, methods and/or functions herein without limitation. References to any specific protocols or proprietary names in describing one or more elements, features, or concepts of the embodiments are intended only as a Examples of such implementations are provided, and such references do not limit the extension of claimed embodiments to embodiments using different elements, features, protocols, or concept names. Accordingly, each term used herein is to be given its broadest interpretation given the context in which that term is used.

FIG. 1 illustrates a block diagram of an exemplary information handling system (HIS; Information Handling System) 100, in which one or more of the described features of various embodiments of the present disclosure can be implemented. For purposes of this disclosure, an information handling system such as information handling system 100 may include information, intelligence, or data in any form operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or exploit for commercial, scientific, control, or other purposes. For example, an information handling system may be a handheld device, personal computer, server, network storage device, or any other suitable device, and may vary in size, shape, performance, functionality, and price. An information processing system may include random access memory (RAM; Random Access Memory), one or more processing resources such as a central processing unit (CPU; Central Process Unit) or hardware or software control logic, read only memory (ROM; Read Only Memory), and/or other types of non-volatile (Non-Volatile) memory. Additional components of an information handling system may include one or more disk drives, one or more network ports for communicating with external devices, and various input and output (I/O; Input/Output) devices, such as keyboards, mice, and monitors. An information handling system may also include one or more buses operable to carry communications between various hardware components.

Referring specifically to FIG. 1 , an example of an information processing system 100 is shown. The information handling system 100 includes one or more processors 102 . In various embodiments, information handling system 100 may be a single processor system including one processor 102, or a multi-processor system including two or more processors 102 (eg, two, four, eight, or any other suitable number). deal with Processor 102 includes any processor capable of executing program instructions. In one embodiment, there is provided a mother board configured to provide structural support, power and electrical connections between the various above-described components. Such motherboards may include a plurality of connector sockets in various configurations adapted to receive pluggable circuit cards, component die packages, and the like. When processor 102 includes a controller for system memory 114 , processor 102 is coupled to system memory 114 via random access memory (RAM) bus 113 . System memory 114 may be configured to store program instructions and/or data accessible by processor 102 . In various embodiments, the system memory 114 may be implemented using any suitable memory technology, such as static random access memory (SRAM; Static RAM), synchronous dynamic random access memory (SDRAM; synchronous DRAM), non-volatile memory/flash memory, or any other type of memory.

The processor 102 is coupled to a platform controller hub (PCH; platform controller hub) named after Intel (Intel), a fusion controller hub (FCH; Fusion Controller Hubs) named after AMD, or a chipset (chipset) 108 through a front-end bus (front-end bus) 106, which will be referred to as a platform controller hub for simplicity below. Platform controller hub 108 may be configured to coordinate input/output traffic between processors 102 and other components. For example, in the specific implementation described above, the platform controller hub 108 is coupled to a graphics device 110 (eg, one or more display cards or add-in cards, etc.) via a graphics bus 112, such as an Accelerated Graphics Port (AGP) or an Accelerated Graphics Port bus (AGP bus), a PCI-E (Peripheral Component Interconnect-Express) bus. If processor 102 includes a controller for graphics device 110 , graphics device 110 may be directly coupled to processor 102 . In one embodiment, graphics device 110 may be built into processor 102 .

Also coupled to memory bus 116 is a storage device or storage 120 in which one or more software and/or firmware may be stored. phantoms and/or profiles (not specifically shown). In one embodiment, the storage 120 may be a hard disk (Hard Disk or Hard Drive) or a solid state disk (Solid State Disk or Solid State Drive). During operation of information handling system 100 , one or more software and/or firmware modules within storage 120 may be loaded into system memory 114 .

The platform controller hub 108 is also coupled to one or more peripheral component interconnect devices (PCI devices) 136 via a peripheral component interconnect bus (PCI bus) 138, such as a modem (MODEM), network card, sound card, display card, shared memory, etc. Platform controller hub 108 is also coupled to ports, pins, and/or adapters 130 through bus bars 134 . In general, the platform controller hub 108 can be configured to handle different input/output operations, and the platform controller hub 108 can provide interfaces, such as USB (Universal Serial Bus), voice, serial, parallel, Ethernet and other interfaces, through ports, pins and/or adapters 130 on the bus 134. For example, platform controller hub 108 may be configured to allow data to be exchanged between information handling system 100 and other devices, such as other information handling systems connected to a network. In various embodiments, the platform controller hub 108 may support communication via a wired or wireless general purpose data network, such as any suitable type of Ethernet, via a telecommunications/telephone network, such as an analog voice network or a digital optical communication network, via a storage area network, such as a Fiber Channel Storage Area Network (SAN), or via any other suitable type of network and/or protocol.

Platform controller hub 108 may also be connected to one or more input devices, such as a keyboard, keypad, touch screen, scanning device, voice or optical recognition device, or any other suitable device for inputting or reading data. There may be multiple input/output devices in the information processing system 100 . In some embodiments, the input/output devices may be separate from the information handling system 100 and may interact with the information handling system 100 through wired or wireless connections. The platform controller hub 108 is coupled via a low pin count (LPC; Low Pin Count) bus 146 A non-volatile memory (NV Memory; Nonvolatile Memory) or a storage device 139 connected to a Basic Input Output System (BIOS; Basic Input Output System)/Unified Extensible Firmware Interface (UEFI; Unified Extensible Firmware Interface) 140 . The platform controller hub 108 is also coupled to a super input/output controller (Super I/O) 142 and a baseboard management controller (BMC; Baseboard Management Controller) 144 through a low pin count bus bar 146 .

Basic Input Output System (BIOS)/Unified Extensible Firmware Interface (UEFI) 140 is stored on non-volatile memory 139 and includes program instructions stored thereon. These instructions can be used by the processor 102 to initialize and test other hardware components and/or load an operating system (OS; Operating System) on the information processing system 100 . Thus, as described in more detail below, the BIOS/UEF interface 140 may include a firmware interface that allows the processor 102 to load and execute specific firmware. In some cases, such firmware may include code compliant with the Unified Extensible Firmware Interface (UEFI) specification, but other types of firmware may also be used.

A baseboard management controller (BMC; Board Management Controller) 144 may include a non-volatile memory 139 storing program instructions thereon, and these program instructions may be used by the processor 102 to implement remote management of the information processing system 100 . For example, baseboard management controller (BMC) 144 may enable a user to discover, configure, and manage baseboard management controller (BMC) 144 , set configuration options, troubleshoot and manage hardware or software problems, and the like. Additionally or alternatively, baseboard management controller (BMC) 144 may include one or more baseboard management controller firmware volumes, each volume having one or more firmware files that are used by the BIOS's firmware interface to initialize and test components of information handling system 100. Super I/O controller 142 combines the interfaces of various low bandwidth or low data rate devices. These devices may include, for example, floppy disks, parallel ports, keyboards and mice, among others.

In some cases, information handling system 100 may be configured to access Different types of computer-accessible media are separate from system memory 114 . In general, computer-accessible storage devices may include any tangible (tangible), non-transitory (non-transitory) storage media or storage media, such as electronic, magnetic or optical media (optical media), for example, disk drives, hard disks, optical disks (CD/DVD-ROM), flash memory, etc. can be coupled to the platform control hub 108 .

The information handling system 100 also includes one or more network interface devices (NIDs) 160 coupled to the platform controller hub 108 via a peripheral component interconnect bus (PCI bus) 162 . Network interface device 160 enables information handling system 100 to communicate with and/or interface with other devices, services, and components external to information handling system 100 . These devices, services, and components may communicate with information processing system 100 via an external network, such as network 170 for example, using one or more communication protocols. In one embodiment, a custom system/platform may include multiple devices located in a distributed network, and the network interface device 160 enables the information handling system 100 to connect to these other devices. The network 170 may be a local area network, a wide area network, a personal network, etc., and the connection between and/or between the network 170 and the information processing system 100 may be wired or wireless or a combination thereof. For purposes of discussion, network 170 is indicated as a single collective component for simplicity. It should be understood, however, that network 170 may include one or more direct connections to other devices as well as a more complex set of interconnections, such as may exist in a wide area network, such as the Internet in the Internet.

The information handling system 100 further includes a remote access controller (RAC; Remote Access Controller) 180 coupled to the platform controller hub 108 through a peripheral component interconnect bus (PCI bus) 182 . Remote Access Controller (RAC) 180 provides management functions allowing administrators to deploy, monitor, manage, configure, update, troubleshoot and repair information handling system 100 . Remote access controller (RAC) 180 is also coupled to remote access controller memory (RAC memory) 184 . In one embodiment, remote access controller memory 184 may communicate with processor 102 shared. Remote access controller 180 is also communicatively coupled to network interface device 160 via sideband bus 186 .

Remote access controller (RAC) 180 monitors and controls the operation of information handling system 100 and other systems and devices communicatively coupled with information handling system 100 . The remote access controller (RAC) 180 can also configure and remotely control other connected information processing systems. Remote access controller (RAC) 180 may execute certain software and/or firmware modules stored in RAC memory 184 . Processor 102 and remote access controller (RAC) 180 include specific firmware that enables processor 102 and remote access controller (RAC) 180 to perform the various functions described herein.

As used herein, the terms "tangible" and "non-transitory" are intended to describe computer-readable storage media (or "memory") that do not include propagating electromagnetic signals; but are not intended to otherwise limit the types of tangible computer-readable storage devices covered by the phrase "computer-readable medium" or memory. For example, the terms "non-transitory computer-readable medium" or "tangible memory" are intended to cover types of storage devices that do not necessarily store information permanently, including, for example, random access memory. Program instructions and data stored in a non-transitory form on a computer-accessible tangible storage medium may subsequently be transmitted via transmission media or signals, such as electrical, electromagnetic or digital signals, which may pass through communication media, such as a network and/or a wireless link.

Those skilled in the art will appreciate that the information handling system 100 is illustrative only and is not intended to limit the scope of the disclosure described herein. In particular, any computer system and/or device may include any combination of hardware or software capable of performing certain operations described herein. For example, although information handling system 100 is illustrated as conforming to a first type of architecture, the various systems and methods described herein may be adapted to work with any other architecture having a different chipset and/or remote access controller configuration. Furthermore, in some embodiments, operations performed by illustrated components may be performed by fewer components or distributed over additional components. Similarly, in other embodiments, certain illustrations The component's operations may not be executed, and/or there may be other additional operations.

In other implementations, one or more devices or components shown in Figure 1 may not be present, or one or more other components may be added. Accordingly, the systems and methods described herein can be implemented or performed with other computer system configurations.

Referring now to FIG. 2A, one embodiment of exemplary contents of system memory 114 of information handling system 100 is illustrated. System memory 114 includes data, software and/or firmware modules, including applications 202 and operating system 204 . The system memory 114 may also include other data, software and/or firmware modules.

Turning to FIG. 2B, one embodiment of exemplary content of non-volatile memory 139 of information handling system 100 is illustrated. The non-volatile memory 139 includes a BIOS/UEFI or UEFI ROM 140 and a separate firmware 260 capable of booting the information processing system 100 when the BIOS/UEFI 140 includes multiple memory descriptors. The BIOS/UEF 140 stores a UEFI image 250 that can be loaded by the information processing system 100 during system startup. The UEFI image 250 includes a UEFI runtime service table 252 , a UEFI boot service 253 and an ACPI (Advanced Configuration and Power Interface) table 256 . The BIOS/UEFI 140 also includes a BIOS/UEFI memory map (UEFI memory map) 254 and a multiple memory descriptor capability (MMDC; Multiple Memory Descriptor Capable) bit (bit) 255 .

Advanced Configuration and Power Interface is an industry specification that provides an open standard that operating systems can use for computer hardware discovery, configuration, power management, and monitoring. Advanced Configuration and Power Interface by providing certain command lists or tables as system firmware part to output available features. The ACPI table 256 is loaded into the system memory 114 during system startup and executed during the operating system startup phase. The ADPI table 256 defines the interface between the operating system and the system firmware conforming to the ADPI. Most firmware ACPI functions are provided in ACPI Machine Language (AML) byte-code stored in the ACPI table 256 . When the multiple memory descriptor capability bit (MMDC bit) 255 is set, the operating system supports multiple runtime memory descriptors (descriptor). The UEFI runtime services from the UEFI runtime service table 252 are services available during system boot-up after the device execution phase has begun until the operating system 204 is running. Unified Extensible Firmware Interface boot service (UEFI boot service) 253 is a service available only when the firmware owns the platform (that is, before the ExitBootServices call), which includes text files and graphics consoles on various devices, as well as bus, block and file services.

The firmware 260 includes a boot manager or UEFI loader 262 , an OS loader module 264 and a configuration module 266 . Firmware 260 is software and/or firmware modules that execute on processor 102 of information handling system 100 (ie, at boot time). In one embodiment, the boot manager 262 includes an information handling system unified extensible firmware interface boot manager (IHS UEFI boot manager) 262-1 and an operating system boot manager (OS boot manager) (OS boot manager) 262-2, which runs during the device execution phase (DXE; device execution phase) of booting and facilitates the loading of the unified extensible firmware interface image (UEFI image) 250 . The operating system loader (OS loader) 264 runs during the transient system load phase (TSL; transient system load phase) of booting and facilitates the loading of the operating system 204 . The configuration module 266 runs during the transient system load phase (TSL) phase and enables the information handling system to perform small/specific tasks. as The operating system update or other factors cause the information processing system unified extensible firmware interface boot manager 262-1 to be overwritten with the operating system boot manager 262-2, and the booting will be executed by the operating system boot manager 262-2. At this time, the configuration module 266 will enter the self-generated operating system environment 356 to restore the information processing system unified extensible firmware interface boot manager 262-1 to its original state.

FIG. 3A illustrates a timing diagram or phase diagram 300 of a conventional power-on operation of the information handling system 100 . As shown in the figure, the boot operation includes a security phase (SEC; Security Phase) 310, a pre-extensible firmware interface initialization phase (PEI; Pre-EFI Initialization Phase) 320, a driver execution environment phase (DXE; Driver Execution Environment Phase) 330, a boot device selection phase (BDS; Boot Device Selection Phase) 340, and a transient system loading phase (TSL; Transient System Load Phase) 350, and a runtime phase (RT; Run Time) 360. The Security Phase (SEC) 310 is the first phase of the Unified Extensible Firmware Interface (UEFI) boot process on the information processing system, and is used to configure a pre-verifier 312 . A pre-verifier 312 handles all reboot events on the information handling system and temporarily allocates a portion of memory for other boot phases. A security stage (SEC) 310 executes in firmware residing on the information handling system and serves as the system's root of trust.

The boot operation includes a Security Phase (SEC) 310 passing execution to a Pre-Extensible Firmware Interface Initialization Phase (PEI) 320 which initializes system memory for the information handling system. The pre-extensible firmware interface initialization phase (PEI) 320 sets a pre-extensible firmware interface initialization phase core (PEI core) 322, which includes a CPU initialization (CPU initialization) 324, a chipset initialization (chipset initialization) 326, and a board resource initialization (board resource initialization) 328. Pre-Extensible Firmware Interface Initialization Phase (PEI) 320 passes execution to Driver Execution Environment Phase (DXE) 330, which performs device-specific initialization for the information handling system. In particular, the Driver Execution Environment stage (DXE) 330 performs operations to load the extensible An extension firmware interface program dispatcher (EFI driver dispatcher) 332 . Driver Execution Environment stage (DXE) 330 passes execution to Boot Device Selection stage (BDS) 340 , which executes Boot Manager 262 and Configuration Module 266 . In a particular embodiment, the configuration module 266 runs in a driver execution environment stage (DXE) 330 and a transient system loader stage (TSL) 350 . The boot manager 262 also identifies a boot target and passes execution to a transient system loader (TSL) 350 . Transient system loader stage (TSL) 350 starts operating system loader 264 . The operating system loader 264 loads the operating system and passes execution to the operating system when the operating system is running (OS runtime) 362 . Note also that for traditional multiple bootable OS environments, instructions and data during the boot process may switch back and forth between the boot device selection phase (BDS) 340, the transient system load phase (TSL) 350, and the runtime phase (RT; Run Time) 360. If the startup procedure fails, the startup operation needs to go back to the security phase (SEC) 310 and restart the complete startup procedure.

FIG. 3B illustrates a timing diagram or phase diagram 300 for Unified Extensible Firmware Interface (UEFI) booting of an information processing system according to an embodiment of the present invention. A desktop layering (Desktop Layering) 400 is provided in the transient system loading stage (TSL) 350 so that one of different operating systems can be selected as the booting operating system. When a bit field, such as a flag, is written into the configuration module 266, the transient system loader stage (TSL) 350 starts the operating system loader 264, which loads the operating system in a specified layer in the desktop layer 400, and passes execution to the operating system at the operating system runtime (OS runtime) 362.

FIG. 3C illustrates a unified extensible firmware interface (UEFI) boot timing diagram or phase diagram 300 of an information processing system according to another embodiment of the present invention. The traditional boot manager 262 in the boot device selection stage (BDS) 340 is now divided into an IHS UEFI boot manager (IHS UEFI boot manager) 262-1 and an operating system boot manager 262-2. The information processing system Unified Extensible Firmware Interface boot manager 262-1, that is, the Unified Extensible Firmware Interface boot loader (UEFI bootloader), can confirm or judge the desktop layering (Desktop Layering) Whether all layers in 400 are correct or invalid. If all files in the desktop layer 400 are correct, a boot menu 268 is displayed corresponding to the specific layer in the desktop layer 400 selected by the user. The startup menu 268 including the self-adaptive function (the menu is displayed only when there is a corresponding file) will first confirm the existence of all setting lists, and then describe the list to the user. The Transient System Loader (TSL) 350 starts the OS loader 264, which loads the OS of a specific layer in the desktop layer 400, and passes execution to the OS at OS runtime 362.

Note also that for multiple bootable OS environments, instructions and data during boot may switch back and forth between the boot device selection phase (BDS) 340 and the transient system load phase (TSL) 350 . In the present invention, even if the startup procedure fails, the startup operation only needs to go back to the boot device selection stage (BDS) 340 to check whether the layer in the desktop layer 400 is correct. The above functions can be implemented in a live operating system environment (LOE). When the boot process fails, the operating system boot manager 262-2 starts the native operating system environment 356, wherein the native operating system environment 356 can use the system memory to simulate a virtual hard disk, and load the native operating system into the virtual hard disk. Thus, any disk layer within the desktop hierarchy 400 can be created, generated, or overwritten. A native operating system environment, such as Windows Pre-installation (WinPE; Windows Pre-Install) or any operating system's native environment, which is a mini operating system environment that is easy to operate. The files of the native system are very small and can be stored and installed in storage, USB disk or CD. Therefore, a parent bootable virtual image, child and grandchild virtual images can be created or constructed under the native operating system. If the Sundata virtual image file fails or is damaged, the Unified Extensible Firmware Interface boot loader (UEFI bootloader) can start the native operating system to restore the previous version of the Sundata virtual image file. In addition, the self-hosting operating system can control the information processing system through the Internet or cloud storage, so that the telematics system can be maintained or restored.

In one embodiment, different operating systems can be built in the desktop layer 400, as shown in FIG. 4 . It can be the first operating system layer 402 of the Microsoft (Microsoft) Windows (Windows®) operating system, the first application (AP; Application) layer 404 installed with multiple application programs, and the first data layer 406 in which some data and information are stored. The user may be provided with a second operating system layer 412 which may include GNU/Linux, FreeBSD, Unix or Chrome OS. There is also provided a second application layer 414 and a second data layer 416 having applications installed to a second operating system.

Both an operating system loader (OS loader) 264 and a desktop layer 400 are stored in the storage 120 . For details, please refer to Figure 5. A default UEFI disk 122 is provided as the storage 120, which includes a disk 0 (disk 0) area 124 defined by Microsoft. The three partitions formed under the requirements of Microsoft include an Extensible Firmware Interface System Partition (ESP; EFI System Partition) 125 , a Microsoft Reserve (MSR; Microsoft Reserve) partition 126 and a primary partition 127 . Microsoft reserved partition 126 is not a necessary partition in the present invention. The Extensible Firmware Interface System Partition (ESP) 125 contains the files Bootx64.efi, Bootmgfw.efi or GRUB4DOS (Grand Unified Boot-loader for DOS)-for UEFI under the specified directory, which can be the Extensible Firmware Interface Boot Manager (IHS UEFI Boot Manager) 262-1 of the Information Processing System, or can be simplified as the Extensible Firmware Interface Boot Loader (UEFI boot) loader), where Bootmgfw.efi is the Windows boot environment file. All bootable virtual image files and virtual image files, as layers in the desktop layer 400 , are stored in the primary partition 127 . The operating system boot manager can allow users to create bootable virtual image files or virtual image files, such as virtual hard disks in .VHD or .VHDX format, through the Windows boot manager. Native boot VHDX can be used as the operating system running on the specified hardware without any other parent operating system. This is different from the case where the VHDX is connected to a guest virtual machine (guest virtual machine) on an information processing system with a host operating system (host OS).

Fig. 6 is an embodiment of the present invention, which shows the relationship between many information processing systems, cloud storage, and physical hard disks with bootable virtual image files. An information processing system 100 including a physical hard disk 122 will run under boot operations including a security phase (SEC) 310 , a pre-extensible firmware interface initialization phase (PEI) 320 , a driver execution environment phase (DXE) 330 , and a boot device selection phase (BDS) 340 . A native operating system environment 356 accesses all files on the physical hard disk 122 . All files, such as the first operating system layer 402 , the first application layer 404 , the first data layer 406 , the second application layer 414 , the second data layer 416 , the second operating system layer 422 and the third application layer 424 are all stored in the physical hard disk 122 . However, if the first data layer 406 is selected or determined to be loaded, then the first operating system layer 402 and the first application layer 404 must be included in the first data layer 406 as a bootable environment, and the virtual disk (virtual disk) 502 of the partition A (distribution A) has a complete operating environment (operating environment) for the user. Thus, the first data layer 406 is dependent on the first application layer 404 , which is dependent on the first operating system layer 402 . If the first application layer 404 is selected or determined to be loaded, the first operating system layer 402 must be used together with the first application layer 404 as a bootable environment, and the virtual disk 502 of distribution A with all application programs but no data operating environment is displayed to the user. If it is selected or determined to load the second data layer 416, the first operating system layer 402 and the second application layer 414 must be included together with the second data layer 416 as a bootable environment, and the virtual disk 504 of partition B is displayed. In one embodiment, a redundant data layer 418 , also dependent on the application layer 414 , is a spare file for the second data layer 416 . If the subsequent second data layer 416 fails, the second data layer 416 can be duplicated with the backup data layer 418 , and this step can be performed under the native operating system environment 356 . If the third application layer 426 is selected or determined to be loaded, the second operating system layer 422 must be included together with the third application layer 424 as a bootable environment, and the virtual disk 506 of the partition C is displayed. In the last embodiment, both data and applications are stored in the application layer 424 .

In one embodiment, the redundant data layer 418 is generated Under the operating system environment 356, it can also be directly generated through the second application layer. In this embodiment, a backup data layer 418 can be generated if the client has additional data backups. In another embodiment, when the second data layer 416 is updated, the backup data layer 418 can be automatically generated. Since only data is generated, the files of the second data layer 416 and the backup data layer 418 are not too large, and the latter embodiment can generate a real-time backup solution.

The native operating system environment 356 can update or restore all files in the physical hard disk 122 from the cloud storage 10 . In one embodiment, the operating system layer 422 and the application layer 424 can be downloaded from the cloud 10 in the native operating system environment 356 . Therefore, a management user can deploy a large number of information processing systems 20 through the Internet.

In one embodiment, the user can directly update the operating system of the information processing system 100 without going through the native operating system environment 356 . A specified operating system layer 422 can be directly downloaded from the cloud storage 10 and stored in the physical hard disk 122 . A bit field, such as a flag, can be written or appended to specify the operating system layer 422 and the configuration module 266 . After the information processing system 100 is rebooted next, the specified operating system layer 422 can be booted directly, as shown in FIG. 3B .

In another embodiment, the user can directly update or install the operating system of the information processing system 100 without pre-installing the operating system in the information processing system 100 . A cloud storage daemon, such as a Linux mini kernel, can be stored in the storage device 120 of the information processing system 100 . When the information processing system 100 is booted and the boot device selection stage 340 starts the boot management program 262 to load the BIOS/UIF 140 to the system memory 114, the boot management program 262 confirms the web-storable execution thread located in the storage device 120 as a boot target. Afterwards, the executable thread that can be stored online can download a specified operating system layer 422 from the cloud 10 , which is a specified bootable virtual image file, and its sub-parts to the physical hard disk 11 in the information processing system 100 . One-bit column (bit field), such as a flag (flag), can be written or appended to specify the operating system layer 422 and the configuration module 266 here. After the information processing system 100 is rebooted next, the designated operating system layer 422 can be booted directly, as shown in FIG. 3A .

In the present invention, the operating system layer 402, the self-generated operating system environment 356, or the online storage thread can perform the same functions as above, that is, the executable instructions of the Internet-enabled thread include: booting the information processing system 100; downloading a specified operating system layer 422 from the cloud 10; adding a bit field to the operating system layer 422 and the configuration module 266;

Referring to FIG. 7, a method for deploying an information processing system is provided. First, build or create a unified Extensible Firmware Interface boot loader (UEFI boot loader) with file system attributes of the primary operating system in the Extensible Firmware Interface Service Partition (ESP) 125 of the storage 120, as shown in step S7-1. In a traditional example, the main operating system is Microsoft Windows 10, and the file system is NTFS (New Technology File System). Therefore, all NTFS-related file system attributes are included in the operating system loader, so that the data or information in the virtual image file can be identified when the operating system is loaded. In one embodiment of the present invention, the main operating system is Microsoft Windows 10, and the file system (File System) can be NTFS, EXFAT (Extended File Allocation Table), REFS (Resilient File System) or BTRFS (B-tree FS). Therefore, all file system attributes related to the file system must be included in the Unified Extensible Firmware Interface boot loader (UEFI bootloader), so that the data or information in the virtual image file can be identified before the operating system is loaded. It is important to be able to check dependencies between the operating system layer and the application layer, or between the operating system bootable virtual image and the application virtual image, before loading the operating system. The Unified Extensible Firmware Interface bootloader (UEFI bootloader) in one embodiment is Bootx64.efi. Then, in one embodiment, build tools via disk instruction The first parent (parent) with the main operating system can boot the virtual image file, as shown in step S7-2.

Then, using disk commands to differentiate the first parent bootable virtual image file into a first child virtual image file, and simultaneously install the first application program into the first parent bootable virtual image file, as shown in step S7-3. Then, further use the disk command to divide the first sub-virtual image file into first grandchild virtual image files, and at the same time add or write the first data to the first sub-virtual image file, as shown in step S7-4. Thus, an environment dedicated to the first user in the information handling system 100 is provided. If the first user wants to use the information handling system 100 in her own environment, she can start the first grandchild virtual image file while starting the information handling system 100 . In this embodiment, the first grandchild virtual image file is selected as the boot device having the first child virtual image file and the first parent bootable virtual image file.

Then, use the disk command to divide the first parent bootable virtual image file into a second child virtual image file, and install the second application program into the first parent bootable virtual image file, as shown in step S7-5, if the first user wants to test a specific application program, or the second user wants to use some specific application programs to build his own dedicated environment. Then, divide the second sub-virtual image file into a second grandchild virtual image file by disk command, and add or write second data to the second sub-virtual image file at the same time, as shown in step S7-6. Therefore, a second environment with a main operating system is provided.

Next, create a second parent bootable virtual image file with a secondary operating system, as shown in step S7-7. In one embodiment, the secondary operating system can be Linux, and the file system can be ext (Extended File System), ext2, ext3, ext4, JFS (Journal File System), XFS (high-speed JFS), REFS or Btrfs (B tree file system). However, the original UIF boot loader may not be able to recognize the file system in the second parent bootable virtual image file, so the UEF boot loader must include the file system attributes of the secondary operating system, as shown in step S7-8. Similarly, the second female can be opened The computer virtual image file is divided into a third sub-virtual image file, thereby providing a third operating environment for the second operating system.

After the differencing step of the above method, the child or grandchild virtual image file may be invalid and needs to be repaired, so a checking step should be provided to confirm the correctness of the child or grandchild virtual image file. Please refer to FIG. 8 to check the dependency relationship between the first parent bootable virtual image file and the first child virtual image file, as shown in step S8-1. Since the file system attributes of the main operating system are included in the Unified Extensible Firmware Interface boot loader (UEFI bootloader), files in the first parent bootable virtual image file and the first child virtual image file can be identified and checked. Similarly, check the dependency relationship between the first child virtual image file and the first grandchild virtual image file, as shown in step S8-2; check the dependency relationship between the first parent bootable virtual image file and the second child virtual image file, as shown in step S8-3; and check the dependency relationship between the second child virtual image file and the second grandchild virtual image file, as shown in step S8-4.

Details of checking dependencies can be found in Figure 9. Firstly, it is confirmed whether the dynamic disk headers between the first parent bootable virtual image file and the first child virtual image file are consistent, as shown in step S9-1. Then, confirm that the parent (UUID; Universally Unique Identifier) in the dynamic disk header of the first child virtual image file is the same as the hard disk footer of the first parent bootable virtual image file, as shown in step S9-2.

FIG. 10 illustrates a flowchart of an exemplary method by which the processor 102 in the preceding figures performs different aspects of the process implementing one or more embodiments of the present disclosure. In general, a method represents a computer-implemented method for enabling an information processing system to operate in multiple environments, where the aforementioned environments may include the same operating system but different applications or data, or different operating systems. The method description will generally refer to specific elements previously illustrated in Figures 1-6. Generally, the methods will be described as being implemented by the processor 102, particularly the execution of code provided by the firmware 260, particularly the information handling system unified extensible firmware A UI boot manager 262 - 1 , an OS boot manager 262 - 2 , an OS loader 264 , and a firmware execution 266 of configuration modules function within the processor 102 . In one embodiment, a method may be described as being implemented by the processor 102 , particularly the execution of code provided by a UIF boot service functioning within the processor 102 . It should be understood, however, that certain aspects of the described methods may be implemented by other processing devices and/or the execution of other code.

While starting the information processing system, the processor 102 starts to confirm whether all the devices of the information processing system are correctly configured by the Unified Extensible Firmware Interface Read Only Memory (UEFI ROM), as shown in step S10-1. Then, the processor 102 loads the unified extensible firmware interface boot loader in the extensible firmware interface system partition (ESP) 125, which has the parent bootable virtual image file, the first sub virtual image file and the second sub virtual image file stored in the main partition area 127, as shown in step S10-2. In this embodiment, both the first sub-virtual image file and the second sub-virtual image file are built by the parent bootable virtual image file, and the first sub-virtual image file is used as a redundant support before the second sub-virtual image file. Also, the first sub-virtual image has been checked and confirmed to be correct, while the second sub-virtual image has just been created.

Next, the processor 102 checks the dependency relationship between the parent bootable virtual image file and the second child virtual image file, as shown in step S10-3. Next, if the second sub-virtual image file fails, the processor 102 rebuilds the second sub-virtual image file from the first sub-virtual image file, or duplicates the first sub-virtual image file as the second virtual image file, as in step S10-4. In response to the user's selection, the processor 102 determines the second sub-virtual image file as the boot device, as shown in step S10-5. Next, the processor 102 loads the operating system of the boot device as shown in step S10-6. The above process and steps can be processed under the Live Operating System Environment (Live Operating System Environment) that can only be loaded into the system memory.

In the present invention, since the data is packaged into several virtual image files for storage, it is necessary to copy a large number of small files in comparison with the environment where the entire operating system and application software are installed, copy or move the internal A single virtual image file with multiple small files, both storage devices HDD and SSD will benefit from less access time and will be much faster than directly copying or moving multiple small files in storage. Therefore, the backup data or recovery process is much faster than any traditional data backup solution.

In the present invention, multiple information processing systems can be deployed within minutes because these virtual images can be replicated to multiple information processing systems very quickly. In addition, all virtual images can be replicated from cloud storage to multiple information processing systems via the Internet.

In the present invention, multiple information processing systems can be deployed in teaching classrooms, with higher efficiency and better security control. If student A creates or builds some data during one semester of an information processing system, all of student A's information can be packaged into the first data virtual image file. If Student B also created or built some other data during the same term on the information processing system, all of Student B's information can be packaged into a second data virtual image file. Therefore, Student B cannot refer to Student A's material or cheat on assignments during the semester. Data privacy will be much better than any other traditional security method.

In the present invention, multiple information processing systems can also be deployed for a department of a company with better efficiency and better security control. If employee A creates or constructs some data in an information processing system to test the function of a device controlled by the information processing system, especially the result of the function belongs to the first company, all the information created or constructed by employee A can be packaged into the first data virtual image file. If employee A needs to create or build some other data in the information processing system to test the function of the equipment controlled by the information processing system, and the function result belongs to the second company, all the information created or built by employee A can be packaged into the second data virtual image file. If worker A needs to test equipment controlled by a particular information handling system, the present invention can easily remove all test information and data on the information handling system during recovery.

In the present invention, there is no operating system and application program in the data virtual image file. If two virtual images of data are created for recovery purposes, it requires less Requires less storage capacity.

In the present invention, due to the Unified Extensible Firmware Interface Read-Only Memory (UEFI ROM), the number of supported operating systems is not limited.

In the present invention, a single information processing system or a plurality of information processing systems can be restored or deployed through the Internet and remote control.

In the present invention, recovery or deployment can be performed on a batch information processing system without any general-purpose serial bus disk or other hardware devices.

The recovery or deployment process is very fast because the bootable virtual image file can be copied or moved very quickly, whereas many small files to be copied or moved from one directory to another would take a lot of time to complete. Even better when the storage is a solid state drive.

In the present invention, the dependencies of any bootable virtual image file can be checked before the operating system is loaded. And the recovery procedure can be handled automatically.

In the flowcharts described above, one or more methods may be embodied in a computer-readable medium containing computer-readable codes, such that a series of functional processes are performed when the computer-readable codes are executed on a computing device. In some embodiments, certain steps of the methods may be combined, performed simultaneously or in a different order, or possibly omitted, without departing from the scope of the present disclosure. Therefore, although method blocks are described and illustrated in a particular order, use of the particular order in which the functional processes are represented in the blocks is not meant to imply any limitation on the present disclosure. Changes may be made to the order of the processes without departing from the scope of the present disclosure. Accordingly, the use of a particular order should not be viewed in a limiting sense, and the scope of the disclosure is limited only by the terms of the appended claims.

Various viewpoints of the disclosure are described above, which refer to flow charts and/or block diagrams of methods, devices (systems) and computer program products in the embodiments of the disclosure. It should be understood that each block of the flowcharts and/or block diagrams, and groups of blocks in the flowcharts and/or block diagrams Combination can be realized by computer program instructions. Computer program code for performing operations in various aspects of this disclosure may be written in any combination of one or more programming languages, including but not limited to a UEFI Oriented programming language that can be written. These computer program instructions can be provided to the processors of general-purpose computers, special-purpose computers (such as service processors) or other programmable data processing devices to produce machines, so that the instructions executed by the processors of the computers or other programmable data processing devices execute methods for realizing the functions/actions specified in the flowcharts and/or block diagrams.

One or more of the described embodiments of the present disclosure may be implemented at least in part using a software-controlled programmable processing device, such as a microprocessor, digital signal processor, or other processing device, data processing device, or system. Therefore, it is to be understood that a computer program for configuring a programmable device, apparatus or system to implement the aforementioned methods is conceived as an aspect of this disclosure. A computer program may be embodied as source code or compiled for implementation on a processing device, device or system. Suitably, the computer program is stored on a carrier device in a machine- or device-readable form, for example in solid-state storage, magnetic storage such as a magnetic disk or magnetic tape, magneto-optically readable memory such as an optical disc or digital versatile disk, flash memory, etc. A processing device, apparatus, or system utilizes a program, or a portion thereof, to configure the processing device, apparatus, or system to operate.

It can be further understood that the processes in the embodiments of the present disclosure can be implemented by any combination of software, firmware or hardware. Accordingly, aspects of this disclosure may take the form of an entirely hardware embodiment or an embodiment combining software (including firmware, resident software, microcode, etc.) and hardware aspects, which may be collectively referred to herein as a "circuit," "module," or "system." Additionally, aspects of this disclosure may take the form of a computer program product embodied in one or more computer-readable storage devices having computer-readable storage devices embodied thereon. Brain-readable program code. Any combination of one or more computer readable storage devices may be utilized. A computer readable storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer readable storage devices would include the following: electrical connection with one or more wires, portable computer disk, hard disk, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), optical fiber, portable compact disc read only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage device may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

While the disclosure has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the disclosure. In addition, many modifications may be made to adapt a particular system, device, or component thereof to the teachings of the disclosure without departing from the essential scope thereof. Therefore, it is intended that the disclosure not be limited to the particular embodiments disclosed for carrying out this disclosure, but that this disclosure will include all embodiments falling within the scope of the appended claims. Furthermore, the use of the terms first, second, etc. does not imply any order or importance, but rather the terms first, second, etc. are used to distinguish one element from another. Furthermore, the terms "primary OS" and "secondary OS" are used only to denote a "first" and "secondary" OS, and are not intended to indicate that the primary OS is better or more important than the secondary OS.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will be further understood that the terms "comprising" and/or "comprising", when used in this specification, designate that said features, integers, steps, operations, The presence of elements and/or components does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.

The description of this disclosure is presented for purposes of illustration and description, but is not intended to be exhaustive or limiting of the disclosure in the form of the disclosure. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the present disclosure. The embodiments presented were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure with various modifications for the particular use contemplated.

While the invention has been described in detail based on the illustrated embodiments, those skilled in the art will readily recognize that there are many variations of the embodiments that will fall within the spirit and scope of the invention. Accordingly, those skilled in the art can obtain many amendments without departing from the appended claims.

262-1: Unified Extensible Firmware Interface Boot Management Program for Information Processing System

262-2: Operating System Boot Manager

264: Operating system loader

266: Configuration module

268:Boot menu

300: Timing diagram or phase diagram of power-on operation

310: Start-up operation includes safety phase

312: Pre-validator

320: Pre-extensible firmware interface initialization phase

322: Pre-extensible firmware interface initialization phase core

324: CPU initialization

326: Chipset initialization

328: Board resource initialization

330: Driver execution environment stage

334: Driver

332:EFI Driver Scheduler

340: Boot device selection stage

350:Transient system loading phase

352: Bootloader

356: Self-generated operating system environment

360: Runtime Phase

362: Operating system running phase

400: Desktop layering

Claims (10)

A method for deploying an information processing system is used to enable an information processing system to operate in multiple environments, comprising the following steps: in an Extensible Firmware Interface (EFI) system partition (system partition) in a storage device (storage), create a Unified Extensible Firmware Interface (UEFI) boot loader (bootloader), which has a file system (file system) attribute of a primary (primary) operating system; The parent bootable virtual image file is in a partition of the storage area; and when a first application program is installed in the first parent bootable virtual image file, the first parent bootable virtual image file is differentiated into a first child virtual image file in the partition of the storage device. The method as described in Item 1 of the scope of the patent application further includes the following steps: when a first data is added to the first sub-virtual image file, it further includes a pair of the first sub-virtual image file to be divided into a first grandchild (grandchild) virtual image file in the partition in the storage device; The image file is divided into a second grandchild virtual image file in the partition of the storage device; a second parent bootable virtual image file with a second main operating system is established in the partition of the storage area; and the file system attribute of the second operating system is included in the extensible firmware interface boot loader. A method for verifying the dependency between the first parent bootable virtual image file, the first/second child, and the first/second grandchild virtual image file in item 2 of the scope of the patent application, comprising the following steps: confirming the dependency between the first parent bootable virtual image file and the first child virtual image file; confirming the dependency between the first child virtual image file and the first grandchild virtual image file; confirming the dependency between the first parent bootable virtual image file and the second child virtual image file; and confirming the second child virtual image file and the second grandchild virtual image file Dependency between files, wherein the above confirmation step includes: confirming the dynamic disk header between the first parent bootable virtual image file and the first sub-virtual image file; The method described in Item 1 of the scope of the patent application, wherein the above-mentioned step of establishing the boot loader of the unified extensible firmware interface and the step of establishing the first mother bootable virtual image file are run under a self-generated operating system environment, when the boot loader of the unified extensible firmware interface is covered by an operating system boot manager, the above-mentioned unified extensible firmware interface boot loader is restored under the environment of the native operating system. The method described in item 1 of the scope of the patent application, wherein the above-mentioned unified extensible firmware interface is booted The loader and the first mother bootable virtual image file are provided through a cloud storage. A method for deploying a plurality of information processing systems, comprising the following steps: copying the extensible firmware interface bootloading system described in item 1 of the patent application to the plurality of storage devices of the plurality of information processing systems; copying the first parent bootable virtual image file described in item 1 of the application for patents to the plurality of storage devices of the plurality of information processing systems; and copying the first child virtual image file described in item 1 of the application for patents to the plurality of storage devices of the multiple information processing systems. A computer-implemented method for enabling an information processing system to operate in multiple environments, comprising the following steps: when the information processing system is powered on, confirming whether all components of the information processing system are configured correctly through a UIFI read-only memory; loading a UIFI boot loader in an eXFI system partition in a storage device, which has a parent bootable virtual image file, a first sub-virtual image file and a second sub-virtual image file in a partition in the storage device area; wherein the first and second sub-virtual image files are generated from the parent bootable virtual image file, wherein the first virtual image file is earlier than the second virtual image file; confirm the dependency between the parent bootable virtual image file and the second sub-virtual image file; determine that the second sub-virtual image file is a boot component; and load an operating system of the boot component. The method described in item 7 of the scope of the patent application, wherein the above-mentioned extensible firmware interface boot loader includes the file system attribute of the operating system in the parent bootable virtual image file, the above-mentioned confirming step includes: confirming the dynamic disk header between the first parent bootable virtual image file and the second child virtual image file; In the confirming step, when the second sub-virtual image file becomes invalid, a step is further included to automatically overwrite the first sub-virtual image file as the second sub-virtual image file. A method for deploying an information processing system is used to enable an information processing system to operate in multiple environments, comprising the following steps: establishing a boot management program and a configuration module in an extensible interface partition of a storage device; executing a cloud thread command to download a designated bootable virtual image file in the partition of the storage device; attaching a flag to the designated bootable virtual image file and the configuration module; and rebooting the information processing system. An information processing system comprising: A storage device is used to store at least one UIF interface boot loader; a processor is interactively coupled with the storage device, and the processor has firmware to execute on it, so that the information processing system can operate in multiple environments, wherein the firmware configures the processor to: when the information processing system is started, confirm whether all components of the information processing system are configured correctly through a UIF interface read-only memory; load a UEF interface into a system partition of the UEF interface in a storage device. The body interface boot loading program has a parent bootable virtual image file, a first child virtual image file and a second child virtual image file in a partition in the storage device; wherein the first and second child virtual image files are generated from the parent bootable virtual image file, wherein the first virtual image file is before the second virtual image file; confirm the dependency between the parent bootable virtual image file and the second child virtual image file; determine that the second child virtual image file is a boot component; and load the operating system of the boot component.

Images