CN110998517A

CN110998517A - System and method for customized operating system translation

Info

Publication number: CN110998517A
Application number: CN201880048725.4A
Authority: CN
Inventors: G·蒂尔尼; W·A·斯沃茨
Original assignee: Mastercard International Inc
Current assignee: Mastercard International Inc
Priority date: 2017-08-02
Filing date: 2018-07-13
Publication date: 2020-04-10
Anticipated expiration: 2038-07-13
Also published as: US20190042583A1; EP3662362B1; US10565162B2; EP3662362A1; CN110998517B; WO2019027654A1; JP2020530154A; JP6861886B2; CA3071787A1

Abstract

An operating system translation (OSC) computing device generates a custom archive file for a host computing device having a first OS that includes an OS image file associated with a second Operating System (OS). The OSC computing device formats a data storage device of a host computing device to include a first partition associated with a first OS and a second partition associated with a second OS, transmits a custom archive file to the host computing device, and generates a loopback file system installed to the host computing device to emulate a physical data storage device using the custom archive file. The OS image file may be accessed by a loopback file system. The OSC computing device stores the OS image file in an installation directory of the second partition and converts the OS operating on the host computing device from the first OS to the second OS.

Description

System and method for customized operating system translation

Cross Reference to Related Applications

This application claims benefit and priority from U.S. patent application No.15/667,093 filed on 8/2/2017. The entire disclosure of the above application is incorporated herein by reference.

Technical Field

The field of the present disclosure relates generally to transforming operating systems operating on host computing devices, and more particularly, to network-based systems and methods for remotely customizable transformation of operating systems operating on host computing devices.

Background

Servers and other data storage devices are used to store and transfer data for various applications. For example, the server may be used to store data associated with a payment network that processes transactions using a payment card (e.g., a credit or debit card) and a payment account. Servers typically include multiple data storage devices (e.g., hard disk drives and solid state drives) to provide data redundancy and/or increased data storage. An operating system is installed on each server to enable the server to perform standard functions, such as communicating with other devices, storing data, and displaying a Graphical User Interface (GUI). The operating system includes a set of protocols for controlling each function such that data is received, processed, and transmitted according to the specific format supported by the operating system. For example, the operating system may include one or more file system architectures for connected storage devices to store data, such as a File Allocation Table (FAT), a fourth extended file system (ext4), and/or a New Technology File System (NTFS).

In some cases, the server may be scheduled to change or convert the operating system (i.e., due to lack of support, replacement of the operating system, etc.). However, translating between operating systems can cause problems with data stored in file system architectures that are not supported by the new operating system. Thus, the server may require a field technology profile, additional data storage, and/or one or more reboots to install the new operating system. The downtime resulting from the installation and conversion processes can be long and inconvenient for users attempting to access the servers and the data stored by the servers, particularly data critical to the particular processes or services performed by the servers.

Disclosure of Invention

In one aspect, an Operating System Conversion (OSC) computing device includes at least one processor and a memory in communication with the at least one processor. The at least one processor is programmed to generate a customized archive file for a host computing device having a first Operating System (OS). The custom archive file includes an OS image file associated with the second OS. The at least one processor is also programmed to format a first data storage device of the host computing device to include a first partition associated with the first OS and a second partition associated with the second OS, transmit a custom archive file to the host computing device, and generate a loopback (loopback) file system installed to the host computing device to emulate a physical data storage device using the custom archive file. The OS image file may be accessed by a loopback file system. The at least one processor is further programmed to store the OS image file within an installation directory of the second partition and convert an OS operating on the host computing device from the first OS to the second OS. The OS image file installs the second OS on the second data storage device of the host computing device from the installation directory.

In another aspect, a method for transitioning a host computing device from a first OS to a second OS is provided. The method is performed at least in part by an OS conversion (OSC) computing device. The host computing device includes a first data storage device. The method includes generating a customized archive file for a host computing device. The custom archive file includes an OS image file associated with the second OS. The method also includes formatting the first data storage device to include a first partition associated with the first OS and a second partition associated with the second OS, transmitting the custom archive file to the host computing device, generating a loopback file system to be installed to the host computing device to emulate a physical data storage device using the custom archive file. The OS image file may be accessed by a loopback file system. The method also includes storing the OS image file in an installation directory of the second partition and converting an OS operating on the host computing device from the first OS to the second OS. The OS image file installs the second OS on the second data storage device of the host computing device from the installation directory.

In yet another aspect, at least one non-transitory computer-readable storage medium having computer-executable instructions embodied thereon is provided. The computer-executable instructions, when executed by the at least one processor, cause the processor to generate a customized archive file for a host computing device having a first OS. The custom archive file includes an OS image file associated with the second OS. The computer-executable instructions further cause the processor to format a first data storage device of the host computing device to include a first partition associated with the first OS and a second partition associated with the second OS, transmit a custom archive file to the host computing device, and generate a loopback file system installed to the host computing device to emulate a physical data storage device using the custom archive file. The OS image file may be accessed by a loopback file system. The computer-executable instructions further cause the processor to store the OS image file in an installation directory of the second partition and convert an OS operating on the host computing device from the first OS to the second OS. The OS image file installs the second OS on the second data storage device of the host computing device from the installation directory.

Drawings

Fig. 1-6 illustrate example embodiments of the methods and systems described herein.

Fig. 1 is a block diagram illustrating an example operating system translation (OSC) system for translating a host computing device from a first operating system to a second operating system, according to one embodiment of the present disclosure.

FIG. 2 is an exemplary data flow diagram for operating system conversion processing using the system shown in FIG. 1.

FIG. 3 is an expanded block diagram of an example embodiment of a remote device for use in the system shown in FIG. 1.

Fig. 4 illustrates an example configuration of a host system used in the system shown in fig. 1.

FIG. 5 is a flow diagram of an example process for converting an operating system using the system shown in FIG. 1.

FIG. 6 is a diagram of components of one or more example computing devices that may be used in embodiments of the described systems and methods.

Detailed Description

Systems and methods consistent with the present disclosure relate to using an operating system translation system to translate an operating system on a host computing device from a first operating system to a second operating system. More specifically, the present disclosure describes network-based systems and methods that include an operating system translation system configured to remotely translate an operating system on a host computing device from a first operating system to a second operating system.

The operating system translation (OSC) system described herein facilitates installation of an Operating System (OS) at a host computing device without requiring physical access to the host computing device. In an example embodiment, an OSC system includes an OSC computing device that is communicatively coupled to a host computing device that is configured to execute one or more services or processes. In one example, a host computing device is configured to store, generate, receive, and transmit data associated with a payment network. A payment network is a closed network (e.g., private or secure) with a particular messaging protocol configured to enable parties involved in a payment transaction to communicate with each other to authenticate, authorize, settle, and/or otherwise process the payment transaction using a payment account and a payment card (e.g., credit and debit cards). In other embodiments, the host computing device is configured to perform a variety of different services or processes.

The host computing device includes at least a first data storage device and a second data storage device. In other embodiments, the host computing device includes additional data storage devices. The first and second data storage devices may be Hard Disk Drives (HDDs), Solid State Drives (SSDs), and/or any other suitable type of data storage. Each data storage device includes one or more partitions. In at least some embodiments, a partition may include a plurality of slices. Each slice may be configured to include a different file system architecture supported by the OS associated with the partition. In at least some embodiments, the first and second data storage devices are configured in a multi-disk (MD) array for data redundancy, increased storage, and/or improved performance. For example, the first and second data storage devices may be in a redundant array of a disk-independent (RAID) configuration, such as RAID1 or RAID 5.

In an example embodiment, the first and second data storage devices include at least one partition associated with a first OS (also sometimes referred to herein as an "installed OS" or a "previous OS"). That is, the partition associated with the first OS stores OS data for the first OS and/or is formatted according to the particular file system architecture supported by the first OS, thereby enabling the first OS to read and write data from the partition.

In at least some embodiments, the installed OS may be replaced with a new OS ("second OS"). For example, if an installed OS loses value due to lack of support, a new OS may be installed on the host computing device. To convert the host computing device to the second OS, the OSC computing device is configured to perform an OS conversion process on the host computing device. That is, the OSC computing device is configured to facilitate installation of the second OS on the host computing device without requiring a technician to physically access the host computing device (e.g., using a portable physical data storage device to install the second OS). In addition, the OSC computing device is configured to install the second OS without removing the first OS, thereby enabling the host computing device to operate using the first OS when necessary.

In an example embodiment, to begin the OS conversion process, the OSC computing device is configured to retrieve an archive file associated with the second OS. In at least some embodiments, the archive file is retrieved from a database communicatively coupled to the OSC computing device. The archive file stores data for installing the second OS in a compressed format, thereby contributing to reduction in retrieval time and reduction in storage space for storing data. The archived file may be, for example, an ISO file formatted according to a standard set by the international standards organization (e.g., ISO-9660). In an example embodiment, the archived file includes an OS image file that emulates a physical data storage device. The OS image file includes data, such as an installation kernel, software package, etc., for installing the second OS on the data storage device.

In some embodiments, the archived file may be too large to be used in the OS conversion process. In one example, at least some of the file system architectures described herein may not support operations (reads, writes, etc.) on data files that exceed four Gigabytes (GB). In such embodiments, the OSC computing device is configured to extract the OS image file from the archive file and remove one or more software packages from the OS image file. The software package includes one or more data files that provide one or more applications to the second OS. The removed software package may be manually removed from the OS image file to remove unnecessary or unwanted software applications. Alternatively, the software package to be removed may be predefined such that the OSC computing device automatically removes the software package. For example, in embodiments where the OSC computing device converts multiple host computing devices into a second OS, the removal of the software package may be repeated several times, and thus automated to reduce the amount of user input required.

In an example embodiment, the OSC computing device is configured to generate a kickstart file associated with the second OS. The kickstart file is a predefined set of instructions that, when executed, facilitate automatically installing the second OS according to settings defined by the set of instructions, without manual input from a user. During installation of the second OS as described herein, the second OS (or boot loader) may detect the kickstart file and automatically execute the set of instructions. In an example embodiment, the OSC computing device stores a kickstart template used to generate a kickstart file. The kickstart template contains one or more defining variables that are populated with host computing device specific environment information such as, but not limited to, host name, Internet Protocol (IP) address, network mask, default network gateway, network speed, and disk size associated with the first and second data storage devices. In some embodiments, the OSC computing device requests context information from the host computing device and populates a kickstart template with the received context information to generate a kickstart file. In other embodiments, the OSC computing device may generate a script that includes a kickstart template to cause the host computing device to populate the template. A script is a set of computer instructions that, when executed by a computing device, cause the computing device to automatically perform one or more tasks.

After generating the kickstart file, the OSC computing device is configured to generate a custom archive file for the second OS. The custom archive file includes an OS image file and a kickstart file in a compressed format. In some embodiments, the custom archive file may also include other data, such as a data file or other script configured for the second OS. The custom archive file is used to facilitate transfer and storage of the OS image file and the kickstart file at the host computing device.

In an example embodiment, an OSC computing device is configured to control the operation of a host computing device. That is, instructions (e.g., command line instructions) received by the host computing device from the OSC computing device are executed without physically accessing the host computing device. Although the OSC computing device is described herein as performing the steps of the OS conversion process, it should be understood that performing the steps of the OS conversion process may include the OSC computing device controlling the host computing device to perform these steps. In one embodiment, the OSC computing device is configured to provide instructions for the OS conversion process separately to the host computing device. In other embodiments, the OSC computing device generates a script for the OS conversion process and transmits the script to the host computing device.

The OSC computing device is configured to create one or more partitions for the second OS on one of the data storage devices within the host computing device. In an example embodiment, the OSC computing device begins by examining the status of the data storage devices to determine whether any of the data storage devices is in a degraded state or a failed state. If any of the data storage devices is in a degraded state, the OSC computing device may terminate the OS conversion process to facilitate repair and/or replacement of the degraded data storage device. The data storage device is configured in a partitioned array according to a protocol supported by the first OS. More specifically, the data storage device stores metadata defining an array of partitions between the first and second data storage devices. In other embodiments, the data storage devices are not in an array, but rather store data independently of each other. In an example embodiment, the OSC computing device removes the partition(s) of the first data storage device by separating the first data storage device from the partition array by updating the metadata stored by the first data storage device and the second data storage device.

The OSC computing device is configured to format the first data storage device to include a first partition associated with the first OS and a second partition associated with the second OS. More specifically, the OSC computing device updates the partition table stored by the first data storage device to include the first and second partitions in the particular file system architecture supported by the first and second OSs, respectively. Some file system architectures may be supported by two OSs, such as a 32-bit file allocation table (FAT 32). The partition table is metadata stored by the data storage device that indicates the name, size, and file system architecture of each partition within the corresponding data storage device.

The OSC computing device creates a file system supported by the second OS on the second partition of the first data storage device to facilitate storing data within the custom archive file and installing the second OS on the second data storage device (or another data storage device of the host computing device). In an example embodiment, the file system is a FAT file system, and more specifically, a FAT32 file system. In other embodiments, the file system is a different file system supported by at least the second OS.

The OSC computing device then formats the first partition to match the size of a third partition on the second data storage device associated with the first OS. More specifically, at least one slice of the first partition is configured to mirror a corresponding slice of the third partition. The slices of the first and third partitions store data associated with the first OS. The first partition is then rejoined to the partition array by updating the metadata stored by the first and second data storage devices to include a reference pointer to the first partition. By matching the first partition to the third partition, the data storage device continues to operate in the mirrored state of the first OS (i.e., redundant array).

In an example embodiment, the OSC computing device mounts the second partition to a file system supported by the first OS (i.e., provides access to the second partition), thereby enabling the host computing device to access (i.e., read and write to) the second partition. In one embodiment, the second partition is installed to a Personal Computer File System (PCFS). The PCFS is configured to enable the first OS to access the second partition using protocols supported by the first OS. When the second OS is installed, the PCFS may be configured to also facilitate access by the second OS. In an example embodiment, the OSC computing device transmits a custom archive file for storage in the second partition. In some embodiments, the OSC computing device is configured to support the file system architecture of the second partition and directly store the custom archive file. In other embodiments, the host computing device receives the customized archive file and stores the customized archive file in the second partition using PCFS.

The OSC computing device is configured to generate an echo file system using the custom archive file. The loopback file system causes the custom archive file to emulate a physical data storage device to provide access to data within the custom archive file (i.e., the OS image file and the kickstart file). That is, the first OS treats the custom archive file as a data storage device. The loopback file system may also cause the OS image file to emulate a data storage device, thereby providing access to data within the OS image file (e.g., an installation kernel, an installation repository, a software package, etc.). The OSC computing device mounts the loopback file system to the host computing device to provide access to the loopback file system. In one example, the OSC computing device mounts the loopback file system as a compact disc read only memory (CD-ROM) to the host computing device. More specifically, the OSC computing device installs the loopback file system in a directory associated with the CD-ROM. In another example, the OSC computing device mounts the loopback file system as a Universal Serial Bus (USB) device.

After installing the loopback file system, the OSC computing device creates an installation directory within the second partition to store data from the OS image file. Mount directories are identifiable locations within a file system for storing files and other directories. In an example embodiment, an installation directory is created on the second partition via a first OS-supported PCFS. The OS image file and the kickstart file are then stored in the mount directory, and the loopback file system is unloaded from the host computing device. In at least some embodiments, data files (e.g., installation kernel, software package, etc.) within the OS image file are extracted and stored within the installation directory.

After the installation directory is populated, the OS computing device is configured to convert an OS operating on the host computing device from the first OS to the second OS. In at least some embodiments, the OSC computing device can update the boot loader of the host computing device to identify the installation directory. A boot loader is a software application that loads or starts an OS on a host computing device. The boot loader has an associated boot menu that identifies different OSs that may be launched. In an example embodiment, the boot menu includes a boot identifier for each entry on the boot menu that points to an OS stored within the data storage device. The OSC computing device creates a boot identifier associated with the installation directory and updates the boot menu to include the created boot identifier. In some embodiments, the created boot identifier references an installation directory and/or an OS image file. In other embodiments, the created boot identifier references the second partition or the first data storage device. In such embodiments, the boot loader scans the partition or data storage device to identify any stored OS image files. In an example embodiment, the OSC computing device updates the boot loader to set the created boot identifier to a default option (i.e., the second OS is automatically launched when the host computing device is rebooted). In at least some embodiments, the OSC computing device is configured to add a reference pointer associated with the kickstart file to the boot identifier of the second OS. In such an embodiment, when the second OS is initialized to begin installation, the boot loader is configured to identify the kickstart file based on the reference pointer in the boot identifier and cause instructions stored in the kickstart file to be automatically executed to install the second OS.

In an example embodiment, the host computing device is then rebooted to begin an installation process of the second OS on the second data storage device. At least some of the data stored on the second data storage device may be backed up prior to the reboot. The kickstart file causes the host computing device to automatically install and configure the second OS according to predefined configuration settings. For example, the kickstart file may configure the host name, interface, and/or disk layout of the host computing device. In an example embodiment, the kickstart file causes data within the second data storage device to be removed to facilitate installation of the second OS on the second data storage device. The Kickstart file does not completely remove the first OS from the host computing device so that if any problems occur with the second OS, it can fall back to operating with the first OS. That is, the first OS is stored on the first data storage device to facilitate dual booting (i.e., selecting between the first OS and the second OS each time the host computing device is turned on or rebooted).

In at least some embodiments, the host computing device operates for a period of time using the second OS for testing. After a determination is made to completely switch to the second OS, the first OS is removed from the data storage device and the data storage device is configured in a multi-disk array within the second OS for data redundancy. In particular, a data alignment process is performed (e.g., by a host computing device) to format the first data storage device and the second data storage device to mirror each other for the array while limiting the impact of the formatting on the services or processes performed by the host computing device.

The kickstart file may be configured to format the data storage device during installation of the second OS to facilitate the data alignment process. In one example, the kickstart file is configured to create an array of partitions on the second data storage device. The partition array is a redundant partition array (i.e., each partition in the array has at least one matching partition). The kickstart file is configured to identify a portion of a partition as a failed partition or device. More specifically, the kickstart file updates metadata associated with the partition array to identify a portion of the partition as a failed partition. The partition array includes a first subset of partitions that are "active" partitions (i.e., non-failing partitions) and a second subset of partitions that are failing partitions. Creating a failing partition facilitates the ability to take advantage of the "hot swapping" of redundant arrays. Hot swapping is a feature that enables replacement partitions or data storage devices to replace failed devices without additional configuration. Thus, in the data alignment process, the failed partition is removed from the array of partitions, and the first data storage device is configured as a new subset of storage partitions to replace the failed partition in the array without requiring multiple reboots of the host computing device. The first subset of partitions on the second data storage device and the new subset of partitions on the first data storage device are then aligned to match each other and the data alignment process is completed.

The methods and systems described herein may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein a technical effect may be achieved by performing one of the following steps: (i) generating a kickstart file for a host computing device having a first OS or an installed OS, the kickstart file including environment information associated with the host computing device; (ii) retrieving an archive file associated with the second OS or the new OS, the archive file comprising an OS image file of the second OS; (iii) extracting the OS image file from the archived file; (iv) removing at least one software package from the OS image file; (v) generating a customized archive file including an OS image file and a kickstart file; (vi) formatting a first data storage device of a host computing device to include a first partition associated with a first OS and a second partition associated with a second OS; (vii) transmitting the customized archive file to the host computing device; (viii) installing a second partition to the PCFS to enable the first OS to access the second partition; (ix) generating, using the customized archive file, a loopback file system installed on the host computing device to provide access to the OS image file and the kickstart file within the customized archive file; (x) Storing the OS image file and the kickstart file in an installation directory of the second partition for installing the second OS on a second data storage device of the host computing device; and (xi) converting the OS operating on the host computing device from the first OS to the second OS based on the OS image file and the kickstart file.

Systems and methods described herein are configured to facilitate (a) reducing bandwidth and processing interference with services and processes using data on a storage data storage device when transitioning to a new OS; (b) reducing expertise profiles by automating OS conversion processing using scripts; (c) reduce installation costs by enabling installation without physical contact with the host computing device, thereby reducing travel, labor, and equipment (e.g., installation media) costs; (d) by removing the software package prior to OS conversion processing, the data transfer and processing speed of the OS image file is increased; and (e) improving data security by providing an option to return to the original OS when testing the new OS.

Described herein are computer systems, such as host computing devices and OSC computing devices. As described herein, all such computer systems include a processor and memory.

In addition, any processor in a computing device referred to herein may also refer to one or more processors, where a processor may be in one computing device or a plurality of computing devices operating in parallel. Further, any memory in a computing device referred to herein may also refer to one or more memories, where a memory may be in one computing device or in multiple computing devices operating in parallel.

As used herein, a processor may include any programmable system including systems using microcontrollers, Reduced Instruction Set Circuits (RISC), Application Specific Integrated Circuits (ASIC), logic circuits, and any other circuit or processor capable of executing the functions described herein. The above examples are merely examples, and are thus not intended to limit in any way the definition and/or meaning of the term "processor".

As used herein, the term "database" may refer to the body of data, or a relational database management system (RDBMS), or both. As used herein, a database may include any collection of data, including hierarchical databases, relational databases, flat file databases, object relational databases, object oriented databases, and any other structured records or data stored in a computer systemAnd (4) data collection. The above examples are merely examples, and are thus not intended to limit in any way the definition and/or meaning of the term database. Examples of RDBMSs include, but are not limited to including

Database, MySQL,

DB2、

SQL Server、

And PostgreSQL. However, any database that enables the systems and methods described herein may be used. (Oracle is a registered trademark of Oracle corporation of RedwoodShores, Calif.; IBM is a registered trademark of International Business machines corporation of Armonk, N.Y.; Microsoft is a registered trademark of Microsoft corporation of Redmond, Washington, and Sybase is a registered trademark of Sybase of Dublin, Calif.).

In one embodiment, a computer program is provided and embodied on a computer readable medium. In an example embodiment, the system executes on a single computer system without requiring a connection to a server computer. In another embodiment, the system is in

Running in the environment (Windows is a registered trademark of Microsoft corporation of Redmond, Wash.). In yet another embodiment, the system is in a mainframe environment and

running on a server environment (UNIX is a registered trademark of X/Open, Inc. of Berkshire, Reading, UK). Applications are flexible and designed to run in a variety of different environments without affecting any major functionality. In some embodiments, the system includes a plurality of computing devices distributed over a plurality of computing devicesA plurality of components of (a). One or more components may be in the form of computer-executable instructions embodied in a computer-readable medium.

As used herein, an element or step recited in the singular and proceeded with the word "a" or "an" should be understood as not excluding plural elements or steps, unless such exclusion is explicitly recited. Furthermore, references to "an example embodiment" or "one embodiment" of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features.

As used herein, the terms "software" and "firmware" are interchangeable, and include any computer program stored in memory for execution by a processor, including RAM memory, ROM memory, EPROM memory, EEPROM memory, and non-volatile RAM (NVRAM) memory. The above memory types are exemplary only, and are thus not limiting as to the types of memory usable for storage of a computer program.

The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process may be practiced independently and separately from other components and processes described herein. Each component and process can also be used in conjunction with other assembly packages and processes.

The following detailed description illustrates embodiments of the disclosure by way of example and not by way of limitation. It is contemplated that the present disclosure has general application to translating an operating system of a remote host computing device.

Fig. 1 is a block diagram of an example operating system translation (OSC) system 100 for translating a host computing device 102 from a first Operating System (OS) to a second OS. In an example embodiment, the system 100 includes an OSC computing device 104 that is communicatively coupled to the host computing device 102. The OSC computing device 104 includes a processor 106 and a memory device 108 in communication with the processor 106. The OSC computing device 104 communicates with the database 105 for storing and retrieving scripts, kickstart files, OS images, etc., as described herein. In other embodiments, system 100 may include additional, fewer, or alternative components, including those described elsewhere herein.

The host computing device 102 includes a processor 110, a memory device 112 in communication with the processor 110, a first data storage device 114, and a second data storage device 116. In some embodiments, the first and/or second

data storage devices

114, 116 are physically separate from the host computing device 102. For example, the first and second

data storage devices

114, 116 may be configured as Network Attached Storage (NAS) in communication with the host computing device 102. In some embodiments, host computing device 102 may include three or more data storage devices.

In an example embodiment, the first and second

data storage devices

114, 116 are configured in a multi-disk array for data redundancy. In one example, the

data storage devices

114, 116 are in a RAID1 configuration. The

data storage devices

114, 116 store array metadata 118 that defines the structure of the array. To add a device, remove a device, or otherwise adjust the configuration of the array, the host computing device 102 modifies the array metadata 118 in each data storage device associated with the array.

The host computing device 102 is configured to provide one or more processes or services associated with data stored in the first and second

data storage devices

114, 116. For example, the host computing device 102 may be configured to facilitate data communication between different parties in a payment network, such as to transmit and receive messages regarding authenticating, authorizing, settling, and/or otherwise processing payment transactions in the payment network. In other embodiments, the host computing device 102 is configured to provide different services or processes using data stored in the

data storage devices

114, 116.

When a determination is made to transition the host computing device 102 from the first OS to the second OS, the OSC computing device 104 is configured to perform an OS conversion process. The OS conversion process installs the second OS on the second data storage device 116 while maintaining the first OS on the first data storage device 114 until a full conversion to the second OS is performed. The OSC computing device 104 is configured to enable execution of the OS conversion process without physically accessing the host computing device 102 to manually insert a physical medium (e.g., CD-ROM, USB device, etc.) into the host computing device to install the second OS.

FIG. 2 is a data flow diagram during an example OS conversion process performed by the system 100 shown in FIG. 1. In other embodiments, the OS conversion process may include additional, fewer, or alternative data and/or steps, including those described elsewhere herein.

In an example embodiment, to begin the OS conversion process, the OSC computing device 104 is configured to retrieve the archive file 202 associated with the second OS. In at least some embodiments, archived file 202 is retrieved from database 105. The archive file 202 stores data for installing the second OS in a compressed format, thereby facilitating reduction in retrieval time and reduction in storage space for storing data. The archived file 202 may be, for example, an ISO file formatted according to a standard set by the international standards organization (e.g., ISO-9660). In an example embodiment, archive file 202 includes an OS image file 204 that emulates a physical data storage device. The OS image file 204 includes data for installing the second OS on the data storage device. For example, the OS image file 204 may include an installation kernel, an installation repository, and/or a software package associated with the second OS.

In some embodiments, archived file 202 may be too large to be used in the OS conversion process. In one example, at least some file system architectures may not support operations (reads, writes, etc.) on data files that exceed four Gigabytes (GB). In such embodiments, the OSC computing device 104 is configured to extract the OS image file 204 from the archive file 202 and remove one or more software packages 206 from the OS image file 204. The software package 206 includes one or more data files that provide one or more applications to the second OS. The removed software package 206 may be manually removed from the OS image file 204 to remove unnecessary or unwanted software applications. Alternatively, the software package 206 to be removed may be predefined such that the OSC computing device 104 automatically removes the software package 206. For example, in embodiments where the OSC computing device 104 is converting multiple host computing devices 102 to a second OS, the removal of the software package 206 may be repeated several times and thus automated to reduce the amount of user input required.

In an example embodiment, the OSC computing device 104 is configured to generate a kickstart file 208 associated with the second OS. The kickstart file 208 is a predefined set of instructions that, when executed, facilitate automatically installing the second OS according to settings defined by the set of instructions, without manual input from a user. During installation of the second OS as described herein, the second OS (or boot loader) may detect the kickstart file 208 and automatically execute the set of instructions. In an example embodiment, the OSC computing device 104 stores a kickstart template 210 used to generate the kickstart file 208 in the database 105. The kickstart template 210 contains one or more defined variables 212, which defined variables 212 are populated with host computing device 102 specific context information 214 such as, but not limited to, host name, Internet Protocol (IP) address, network mask, default network gateway, network speed, and disk size associated with the first and second

data storage devices

114, 116. In some embodiments, the OSC computing device 104 requests the environment information 214 from the host computing device 102 and populates the kickstart template 210 with the received environment information 214 to generate the kickstart file 208. In other embodiments, the OSC computing device 104 can generate a script (not shown) that includes the kickstart template 210 to cause the host computing device 102 to populate the template 210.

After generating the kickstart file 208, the OSC computing device 104 is configured to generate a custom archive file 216 for the second OS. Custom archive file 216 includes the compressed format of OS image file 204 and the kickstart file 208. In some embodiments, the custom archive file 216 may also include other data, such as a data file or other script for the second OS. Custom archive file 216 is used to facilitate the transfer and storage of OS image files 204 and kickstart files 208 at host computing device 102.

In an example embodiment, the OSC computing device 104 is configured to control the operation of the host computing device 102. That is, the instructions (e.g., command line instructions) received by the host computing device 102 from the OSC computing device 104 are executed without physically accessing the host computing device 102. Although the OSC computing device 104 is described herein as performing the steps of the OS conversion process, it should be understood that performing the steps of the OS conversion process may include controlling the host computing device 102 to perform these steps. In one embodiment, the OSC computing device 104 is configured to provide instructions for the OS conversion process separately to the host computing device 104. In other embodiments, the OSC computing device 104 generates a script for the OS conversion process and transmits the script to the host computing device 102.

The OSC computing device 104 is configured to create one or more partitions for the second OS on the first data storage device 114. In an example embodiment, the OSC computing device 104 begins by examining the status of the

data storage devices

114, 116 to determine whether either

data storage device

114 or 116 is in a degraded state or a failed state. If either

data storage device

114, 116 is degraded or fails, the OS transition process may terminate until the degraded or failed data storage device is repaired. In an example embodiment, the OSC computing device 104 removes data associated with the partition(s) of the first data storage device 114 by separating the first data storage device 114 from the partition array by updating the metadata 118 stored by the first data storage device 114 and the second data storage device 116.

The OSC computing device 104 is configured to format the first data storage device 114 to include a first partition 218 associated with a first OS and a second partition 220 associated with a second OS. More specifically, the OSC computing device 104 updates the partition table 222 stored by the first data storage device 114 to include the first partition 218 and the second partition 220 in the particular file system architecture supported by the first OS and the second OS, respectively. In an example embodiment, both OSs support a file system architecture associated with the second partition 220, such as a 32-bit file allocation table (FAT 32). In some embodiments, both OSs may also support the file system architecture associated with the first partition 218. The partition table 222 is metadata stored by the

data storage devices

114, 116 that indicates the name, size, and file system architecture of each partition within the respective data storage device.

The OSC computing device 104 creates a file system on the second partition 220 of the first data storage device 114 to facilitate storing custom archive files and installing the second OS. In an example embodiment, the file system is a FAT file system, and more specifically, a FAT32 file system. In other embodiments, the file system is a different file system supported by the first OS and the second OS.

The OSC computing device 104 then formats the first partition 218 to match the size of the third partition 224 associated with the first OS on the second data storage device 116. More specifically, at least one slice of the first partition 218 is configured to mirror a corresponding slice of the third partition 224. The mirrored slice is configured to store data associated with the first OS. The first partition 218 is then rejoined to the partition array by updating the array metadata 118 stored by the first and second

data storage devices

114, 116 to include a reference pointer to the first partition 218. By matching the first partition 218 with the third partition 224, the

data storage devices

114, 116 continue to operate in the mirrored state (i.e., redundant array) of the first OS until the second OS is installed.

In an example embodiment, the OSC computing device 104 mounts the second partition 220 to a file system 226 supported by the first OS (i.e., provides access to the second partition 220), thereby enabling the host computing device 102 to access (i.e., read from and write to) the second partition 220. In one embodiment, the second partition 220 is installed to a Personal Computer File System (PCFS) 226. PCFS 226 is configured to enable the first OS to access second partition 220 using protocols supported by the first OS. In some embodiments, PCFS 226 may be configured to enable a second OS to access first and/or

second partitions

218, 220. In an example embodiment, the OSC computing device 104 transmits the custom archive file 216 for storage in the second partition 220. In some embodiments, the OSC computing device 104 is configured to support the file system architecture of the second partition 220 and directly store the custom archive file 216. In other embodiments, host computing device 102 receives customized archive file 216 and stores customized archive file 216 in second partition 220 using PCFS 226.

The OSC computing device 104 is configured to generate the loopback file system 228 using the custom archive file 216. The loopback file system 228 causes the custom archive file 216 to emulate a physical data storage device to provide access to data within the custom archive file 216 (i.e., the OS image file 204 and the kickstart file 208). That is, the first OS treats the custom archive file 216 as a data storage device. In an example embodiment, the loopback file system 228 is further configured to cause the OS image file 204 to emulate a data storage device, thereby facilitating access to data within the OS image file 204 (e.g., an installation kernel, an installation repository, etc.). The OSC computing device 104 mounts the loopback file system 228 to the host computing device 102 to provide access to the loopback file system 228. In one example, the OSC computing device 10 mounts the loopback file system 228 as a CD-ROM to the host computing device 102. In another example, the OSC computing device 104 mounts the loopback file system 228 as a USB device.

After installing the loopback file system 228, the OSC computing device 104 creates an installation directory 230 within the second partition 220 to store the OS image file 204. Mount directory 230 is an identifiable location within the file system for storing files and other directories. In an example embodiment, an installation directory 230 is created on the second partition 220 via the first OS-supported PCFS 226. The OS image file 204 and the kickstart file 208 are then stored in the installation directory 230, and the loopback file system 228 is unloaded from the host computing device 102.

After the installation directory 230 is populated, the OSC computing device 104 is configured to convert the OS operating on the host computing device 102 from a first OS to a second OS. In at least some embodiments, the OSC computing device 104 can update the boot loader 232 of the host computing device 102 to identify the installation directory 230. The boot loader 232 is a software application that loads or starts the OS on the host computing device 102. The boot loader 232 has an associated boot menu 234, the boot menu 234 identifying different OSs that may be launched. In an example embodiment, the boot menu 234 includes a boot identifier 236 for each entry on the boot menu 234 that points to the OS stored within the

data storage device

114, 116. The OSC computing device 104 creates a bootstrap identifier 236 associated with the installation directory 230 and updates the bootstrap menu 234 to include the created bootstrap identifier 236. In some embodiments, the created boot identifier 236 references the installation directory 230 and/or the OS image file 204. In other embodiments, the created boot identifier 236 references the second partition 220 or the first data storage device 114. In such embodiments, the boot loader 232 scans the referenced partition or data storage device to identify any stored OS image files. In an example embodiment, the OSC computing device 104 updates the boot loader 232 to set the created boot identifier 236 to the default option (i.e., the second OS is automatically launched when the host computing device 102 is rebooted). In at least some embodiments, the boot identifier 236 includes a reference pointer associated with the kickstart file 208. When the boot loader 232 selects the boot identifier 236 to launch the second OS, the kickstart file 208 is retrieved and executed to install the second OS.

In an example embodiment, the host computing device 102 is then rebooted to begin the installation process of the second OS on the second data storage device 116. At least some of the data stored on the second data storage device 116 may be backed up prior to the reboot. The kickstart file 208 causes the host computing device 102 to automatically install and configure the second OS according to predefined configuration settings. For example, the kickstart file 208 may configure the host name, interface, and/or disk layout of the host computing device 102 within the second OS. At least a portion of the data stored in the second data storage device 116 is removed to install the second OS on the second data storage device 116. The kickstart file 208 does not completely remove the first OS from the host computing device 102 so that if any problems occur with the second OS, it can fall back to operating with the first OS. In an example embodiment, the first OS remains installed on the first data storage device 114 while the second OS is installed on the second data storage device 116. Because the second partition 220 has a file system architecture that is accessible to both OSs, the first OS and the second OS can use the second partition 220 to transfer data to each other (e.g., for backing up data).

After testing and operating on the second OS, a determination may be made to fully convert the host computing device 102 to the second OS. During a complete transition to the second OS, the first OS is removed from the first data storage device 114 to install data associated with the second OS, and the

data storage devices

114, 116 are configured as redundant arrays to facilitate increasing data security of services and processes performed by the host computing device 102.

Fig. 3 depicts an exemplary configuration of a remote or user computing device 302, such as the OSC computing device 104 (shown in fig. 1). Computing device 302 may include a processor 305 for executing instructions. In some embodiments, executable instructions may be stored in memory area 310. Processor 305 may include one or more processing units (e.g., in a multi-core configuration). Memory area 310 may be any device that allows information, such as executable instructions and/or other data, to be stored and retrieved. Memory area 310 may include one or more computer-readable media.

Computing device 302 may also include at least one media output component 315 for presenting information to user 301. Media output component 315 may be any component capable of conveying information to user 301. In some embodiments, media output component 315 may include an output adapter, such as a video adapter and/or an audio adapter. An output adapter may be operatively coupled to processor 305 and to an output device, such as a display device (e.g., a Liquid Crystal Display (LCD), Organic Light Emitting Diode (OLED) display, Cathode Ray Tube (CRT), or "electronic ink" display) or an audio output device (e.g., a speaker or headphones). In some embodiments, media output component 315 may be configured to present an interactive user interface (e.g., a web browser or client application) to user 301.

In some embodiments, computing device 302 may include an input device 320 for receiving input from user 301. Input devices 320 may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive pad (e.g., a touchpad or a touch screen), a camera, a gyroscope, an accelerometer, a position detector, and/or an audio input device. A single component, such as a touch screen, may serve as both an output device for media output component 315 and input device 320.

Computing device 302 may also include a communication interface 325, which may be communicatively coupled to a remote device. The communication interface 325 may include, for example, a wired or wireless network adapter or a wireless data transceiver for use with a mobile telephone network (e.g., global system for mobile communications (GSM), 3G, 4G, or bluetooth) or other mobile data network (e.g., Worldwide Interoperability for Microwave Access (WIMAX)).

Stored in memory area 310 are, for example, computer readable instructions for providing a user interface to user 301 via media output component 315, and optionally, receiving and processing input from input device 320. The user interface may include, among other possibilities, a web browser and a client application. The Web browser enables user 301 to display and interact with media and other information typically embedded on a Web page or Web site from a Web server. The client application allows user 301 to interact with a server application associated with a vendor or enterprise, for example.

Fig. 4 depicts an exemplary configuration of a host computing device 402, such as the host computing device 102 and the OSC computing device 104 (both shown in fig. 1). Host computing device 402 may include a processor 405 for executing instructions. For example, instructions may be stored in memory area 410. Processor 405 may include one or more processing units (e.g., in a multi-core configuration).

The processor 405 may be operatively coupled to a communication interface 415 enabling the host computing device 402 to communicate with a remote device, such as the computing device 302 shown in fig. 3 or another host computing device 402. For example, the communication interface 415 may receive requests from the user computing device 302 via the internet.

The processor 405 may also be operably coupled to a storage device 425 (e.g., the first and second

data storage devices

108, 110 shown in fig. 1). Storage 425 may be any computer-operated hardware suitable for storing and/or retrieving data. In some embodiments, the storage device 425 may be integrated in the host computing device 402. For example, host computing device 402 may include one or more hard disk drives as storage devices 425. In other embodiments, the storage device 425 may be external to the host computing device 402 and may be accessible by multiple host computing devices 402. For example, the storage device 425 may include a plurality of storage units, such as hard disks or solid state disks in a Redundant Array of Inexpensive Disks (RAID) configuration. The storage devices 425 may include Storage Area Networks (SANs) and/or Network Attached Storage (NAS) systems.

In some embodiments, processor 405 may be operatively coupled to storage 425 via storage interface 420. Storage interface 420 may be any component capable of providing processor 405 with access to storage device 425. Storage interface 420 may include, for example, an Advanced Technology Attachment (ATA) adapter, a serial ATA (sata) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component that provides processor 305 with access to storage device 425.

Memory regions 310 (shown in fig. 3) and 410 may include, but are not limited to, Random Access Memory (RAM), such as dynamic RAM (dram) or static RAM (sram), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and non-volatile RAM (nvram). The above memory types are exemplary only, and are thus not limiting as to the types of memory usable for storage of a computer program.

Fig. 5 is a flow diagram of an example method 500 for transitioning a host computing device from a first OS to a second OS using an OSC system, such as system 100 (shown in fig. 1). The method 500 is performed, at least in part, by an OSC computing device (e.g., the OSC computing device 104 shown in fig. 1). In other embodiments, the method 500 may include additional, fewer, or alternative steps, including those described elsewhere herein.

The method 500 begins with the OSC computing device generating 502 a kickstart file for a host computing device. In at least some embodiments, the OSC computing device retrieves the kickstart template and collects context information from the host computing device. The kickstart template is automatically populated with context information to generate 502 a kickstart file. The OSC computing device generates 504 a custom archive file for the host computing device. The custom archive file includes an OS image file and a kickstart file of the second OS. In some embodiments, prior to generating 504 the custom archive file, the OSC computing device retrieves an archive file that stores the OS image file, extracts the OS image file, and removes one or more software packages from the OS image file to reduce the size of the OS image file. The reduced OS image file is then added to the custom archive file.

The OSC computing device formats 506 a first data storage device of the host computing device to include a first partition associated with a first OS and a second partition associated with a second OS. The OSC computing device also transmits 508 the custom archive file to the host computing device to facilitate installation of the second OS. In at least some embodiments, the OSC computing device installs the second partition to the PCFS of the first OS to facilitate access to the second partition from the first OS. The OSC computing device then generates 510 a loopback file system at the host computing device using the custom archive file. The loopback file system is mounted to a host computing device to emulate a physical data storage device storing an OS image file and a kickstart file. The OSC computing device creates an installation directory within the second partition and stores the 512OS image file and the kickstart file within the installation directory to install the second OS on the second data storage device of the host computing device. The OSC computing device then converts 514 the OS operating on the host computing device from the first OS to a second OS based at least in part on the OS image file and the kickstart file. In some embodiments, the OSC computing device updates the boot loader of the host computing device to identify the installation directory and the kickstart file so that the boot loader can launch the second OS and the kickstart file by accessing data of the OS image file (such as the installation kernel).

FIG. 6 is a diagram 600 of components of one or more example computing devices that may be used in the method shown in FIG. 5. Fig. 6 also illustrates a configuration of a data storage system 610, the data storage system 610 being coupled to several separate components within the OSC computing device 104 (shown in fig. 1) that perform certain tasks.

The OSC computing device 104 includes a generation component 602, the generation component 602 configured to generate a kickstart file and a custom archive file for the host computing device. The generation component 602 is further configured to generate an echo file system for installation to a host computing device using the customized archive file. The OSC computing device 104 also includes a formatting component 604, the formatting component 604 configured to format a first data storage device of the host computing device to include a first partition associated with the first OS and a second partition associated with the second OS. The OSC computing device 104 also includes a transmission component 606, and the transmission component 606 is configured to transmit the customized archive file to the host computing device. The OSC computing device 104 also includes a storage component 608, the storage component 608 configured to store the OS image file and the kickstart file within the installation directory of the second partition. The OSC computing device 104 also includes a conversion component 610, the conversion component 610 configured to convert an OS operating on the host computing device from a first OS to a second OS.

In the exemplary embodiment, data storage system 612 is divided into a plurality of sectors including, but not limited to, an OS data sector 614, a kickstart data sector 616, and a device metadata sector 618. These sectors are interconnected by the OSC computing device 104 to update and retrieve information as needed.

As will be appreciated based on the foregoing specification, the above-discussed embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting computer program, having computer-readable and/or computer-executable instructions, may be embodied or provided within one or more computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed embodiments of the present disclosure. These computer programs (also known as programs, software applications or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium," "computer-readable medium," and "computer-readable medium" (media) refer to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal.

This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.

Claims

1. An operating system translation (OSC) computing device comprising at least one processor and a memory in communication with the at least one processor, wherein the at least one processor is programmed to:

generating a custom archive file for a host computing device having a first Operating System (OS), the custom archive file comprising an OS image file associated with a second OS;

formatting a first data storage device of a host computing device to include a first partition associated with a first OS and a second partition associated with a second OS;

transmitting the customized archive file to the host computing device;

generating a loopback file system using the custom archive file, the loopback file system mounted to the host computing device to emulate a physical data storage device, wherein the OS image file is accessible through the loopback file system;

storing the OS image file in an installation directory of the second partition, wherein the OS image file is configured to install the second OS on a second data storage device of the host computing device from the installation directory; and

an OS operating on a host computing device is converted from a first OS to a second OS.

2. The OSC computing device of claim 1, wherein the at least one processor is further programmed to:

generating a kickstart file for a host computing device, the kickstart file including environmental information associated with the host computing device;

adding a kickstart file to the custom archive file; and

storing a kickstart file in an installation directory, wherein the OS image file and the kickstart file are configured to install a second OS on the host computing device.

3. The OSC computing device of claim 2, wherein the kickstart file includes a set of predefined instructions for automatically installing the second OS, wherein the set of predefined instructions is populated with environmental information.

4. The OSC computing device of claim 3, wherein the kickstart file is configured to create a partition array for the second OS on the second data storage device, the partition array including a first subset of partitions and a second subset of partitions, wherein the second subset of partitions is identified as a failed partition.

5. The OSC computing device of claim 1, wherein the at least one processor is further programmed to format the first partition to match a size of a third partition on a second data storage device of the host computing device for a redundant partition array.

6. The OSC computing device of claim 1, wherein the at least one processor is further programmed to install the second partition to a Personal Computer File System (PCFS) to enable the first OS to access the second partition.

7. The OSC computing device of claim 1, wherein the processor is further programmed to:

retrieving an archived file associated with the second OS that includes the OS image file;

extracting the OS image file from the archived file;

removing at least one software package from the OS image file; and

and generating a customized archived file.

8. The OSC computing device of claim 1, wherein the processor is further programmed to:

generating a boot identifier associated with the second OS, the boot identifier referencing an installation directory and a kickstart file associated with the second OS;

updating a boot menu of a boot loader associated with the host computing device to include a boot identifier; and

setting a boot identifier as a default selection of a boot menu, wherein the host computing device is configured to automatically launch the second OS and the kickstart file based on the boot identifier.

9. A method for transitioning a host computing device from a first operating system, OS, to a second OS, the host computing device comprising a first data storage device, the method comprising:

generating, by the OS conversion OSC computing device, a custom archive file for the host computing device, the custom archive file comprising an OS image file associated with the second OS;

formatting the first data storage device to include a first partition associated with the first OS and a second partition associated with the second OS;

transmitting the customized archive file to the host computing device;

storing, by the OSC computing device, an OS image file within an installation directory of the second partition, wherein the OS image file is configured to install a second OS from the installation directory on a second data storage device of the host computing device; and

10. The method of claim 9, further comprising:

generating, by an OSC computing device, a kickstart file for a host computing, the kickstart file including environmental information associated with the host computing device;

adding a kickstart file to the custom archive file; and

11. The method of claim 10, wherein the kickstart file includes a set of predefined instructions for automatically installing the second OS, wherein the set of predefined instructions is populated with the context information.

12. The method of claim 11, wherein the kickstart file is configured to create a partition array for the second OS on the second data storage device, the partition array comprising a first subset of partitions and a second subset of partitions, wherein the second subset of partitions is identified as a failed partition.

13. The method of claim 9, wherein formatting the first data storage device further comprises: the first partition is formatted by the OSC computing device to match a size of a third partition on a second data storage device of the host computing device for the redundant partition array.

14. The method of claim 9, wherein transmitting the customized archive file to the host computing device further comprises: the second partition is installed to a Personal Computer File System (PCFS) by the OSC computing device to enable the first OS to access the second partition.

15. The method of claim 9, wherein generating a customized archive further comprises:

retrieving, by the OSC computing device, an archive file associated with the second OS that includes the OS image file;

extracting the OS image file from the archived file;

removing, by the OSC computing device, the at least one software package from the OS image file; and

and generating a customized archived file.

16. The method of claim 9, wherein translating the OS operating on the host computing device further comprises:

generating, by the OSC computing device, a boot identifier associated with the second OS, the boot identifier referencing an installation directory and a kickstart file associated with the second OS;

setting, by the OSC computing device, a boot identifier as a default selection of the boot menu, wherein the host computing device is configured to automatically launch the second OS and the kickstart file based on the boot identifier.

17. At least one non-transitory computer-readable storage medium having computer-executable instructions embodied thereon, wherein the computer-executable instructions, when executed by at least one processor, cause the processor to:

transmitting the customized archive file to the host computing device;

18. The computer-readable storage medium of claim 17, wherein the computer-executable instructions further cause the processor to:

adding a kickstart file to the custom archive file; and

19. The computer readable storage medium of claim 18, wherein the kickstart file includes a set of predefined instructions for automatically installing the second OS, wherein the set of predefined instructions is populated with the context information.

20. The computer-readable storage media of claim 17, wherein the computer-executable instructions further cause the processor to format the first partition to match a size of a third partition on a second data storage device of the host computing device for the redundant partition array.

21. The computer-readable storage media of claim 17, wherein the computer-executable instructions further cause the processor to install a second partition to a Personal Computer File System (PCFS) to enable the first OS to access the second partition.

22. The computer-readable storage medium of claim 17, wherein the computer-executable instructions further cause the processor to:

extracting the OS image file from the archived file;

removing at least one software package from the OS image file; and

and generating a customized archived file.