CN117608653A - Operating system migration method and computing device - Google Patents

Abstract

The embodiment of the application provides an operating system migration method and computing equipment, relates to the technical field of servers, and can avoid the compatibility problem of software packages so that an operating system can normally complete migration. The method comprises the following steps: determining a target software package in a first operating system; the target software package is a software package which is not updated and is incompatible in the process of migrating the first operating system to the second operating system; deleting the related information of the target software package from the target database; the target database is used for recording the related information of each software package in the first operating system before and after the migration of the first operating system; migrating the first operating system to a second operating system based on the target database; installing a compatible dependency package on a second operating system; the compatible dependency package is used to support the target software package running on the second operating system. The embodiment of the application can be used in the operation and maintenance process of the computing equipment.

Description

Operating system migration method and computing device

Technical field

Embodiments of the present application relate to the field of server technology, and in particular, to an operating system migration method and a computing device.

Background technique

As the operating system is updated and iterated, the original operating system may have loopholes or security issues. For enterprises, operating system migration is required to ensure the security and operational stability of business applications on the operating system.

In the scenario of operating system migration, users often expect to maintain the stability of existing services, that is, they expect that the software packages of some services will not be upgraded along with the operating system migration. However, the retained software packages may have compatibility issues on the new operating system, causing the operating system migration to not be completed normally.

Contents of the invention

Embodiments of the present application provide an operating system migration method and a computing device, which can avoid software package compatibility issues and enable the operating system to complete migration normally.

In a first aspect, embodiments of the present application provide an operating system migration method. The method includes: determining a target software package in a first operating system; wherein the target software package is a process of migrating the first operating system to a second operating system. software packages that are not upgraded and are incompatible; delete the relevant information of the target software package from the target database; the target database is used to record the relevant information of each software package in the first operating system before and after the migration of the first operating system; based on the target database , migrate the first operating system to the second operating system; install the compatible dependency package on the second operating system; the compatible dependency package is used to support the target software package to be compatible with the second operating system.

Embodiments of the present application provide an operating system migration method, which deletes relevant information of the target software package from the target database before the operating system is migrated. Because the migration of the operating system is based on the records of the software packages in the target database. Therefore, the operating system will think that the target software package is not installed and will not process the target software package during the migration process. In this way, the operating system will not report errors due to compatibility issues with the target software package during the migration process, allowing the operating system to complete the migration normally. . Finally, install compatible dependency packages on the migrated operating system to ensure that the target software package can run normally on the new operating system.

In a possible implementation, determining the target software package in the first operating system includes: obtaining the software package to be retained; determining the dependent packages of the software package to be retained; and the dependent package to support the software package to be retained on the first operating system. Run the software package; determine whether the dependent package has a version conflict on the second operating system; the version conflict is used to indicate that there are different versions of the dependent package in the second operating system; in the case of a version conflict, determine whether the software package to be retained is Target package. It is understandable that for the software packages that users need to retain, only the software packages that have compatibility issues to be retained are deleted for subsequent processing, which can effectively improve the efficiency of operating system migration.

In another possible implementation, before installing the compatible dependency package on the second operating system, the method further includes: obtaining the compatible dependency package corresponding to the target software package from the compatible dependency package collection according to the identification of the target software package; The dependency package collection includes software packages that support running on a second operating system without upgrading the software package. It is understandable that directly querying and installing compatible dependency packages from the pre-configured collection of compatible dependency packages can greatly improve migration efficiency.

In another possible implementation, before installing the compatible dependency package on the second operating system, the method further includes: obtaining the compatible dependency package corresponding to the target software package from the compatible dependency package collection according to the identification of the target software package; The dependency package collection includes software packages that support running on a second operating system without upgrading the software package. It is understandable that by changing the package name of a dependent package, you can directly obtain the corresponding compatible dependent package, which is applicable to any type of software package and can effectively improve the versatility of the operating system migration method.

In another possible implementation, before deleting the relevant information of the target software package from the target database, the method also includes: obtaining the relevant information of the target software package from the target database; and backing up the relevant information of the target software package to the storage space. . It is understandable that relevant information should be backed up to avoid data loss and facilitate the subsequent data recovery process.

In another possible implementation, after migrating the first operating system to the second operating system, the method further includes: obtaining relevant information of the target software package from the storage space; and updating the relevant information of the target software package to the target database. . It is understandable that after the data is restored, the relevant information of the target software package is re-recorded in the target database, so that the user can easily maintain the target software package when using the new operating system.

In another possible implementation manner, the method further includes: updating the dependency relationship between the target software package and the compatible dependency package to the relevant information of the target software package in the target database.

In another possible implementation, the target database is the Rpm database.

In yet another possible implementation, the method further includes: during the process of migrating the first operating system to the second operating system, backing up a predetermined directory in the first operating system.

In a second aspect, embodiments of the present application provide an operating system migration device, which includes: a determination module, a deletion module, a migration module, and an installation module. The determination module is used to determine the target software package in the first operating system; wherein the target software package is a software package that will not be upgraded and is incompatible with the first operating system during the migration to the second operating system; the deletion module is used to, Delete the relevant information of the target software package from the target database; the target database is used to record the relevant information of each software package in the first operating system before and after the migration of the first operating system; the migration module is used to, based on the target database, transfer the first operation The system is migrated to the second operating system; the installation module is used to install the compatible dependency package on the second operating system; the compatible dependency package is used to support the target software package to be compatible with the second operating system.

In a possible implementation, the determination module is specifically used to obtain the software package to be retained; determine the dependent packages of the software package to be retained; the dependent packages are software packages that support the software package to be retained running on the first operating system; determine the dependencies Whether there is a version conflict of the package on the second operating system; the version conflict is used to indicate that there are different versions of the dependent package in the second operating system; if there is a version conflict, the software package to be retained is determined to be the target software package.

In another possible implementation, the above device further includes: an acquisition module. The acquisition module is used to obtain the compatible dependency package corresponding to the target software package from the compatible dependency package set according to the identification of the target software package; the compatible dependency package set includes software packages that support running on the second operating system without upgrading the software package.

In another possible implementation manner, the above device further includes: a change module. The acquisition module is also used to obtain the dependency package that supports the target software package to run on the first operating system; the change module is used to change the package name of the dependency package to obtain a compatible dependency package.

In another possible implementation manner, the above device further includes: a backup module. The acquisition module is also used to obtain the relevant information of the target software package from the target database; the backup module is used to back up the relevant information of the target software package to the storage space.

In another possible implementation manner, the above device further includes: an update module. The acquisition module is also used to obtain the relevant information of the target software package from the storage space; the update module is used to update the relevant information of the target software package to the target database.

In another possible implementation manner, the update module is also used to update the dependency relationship between the target software package and the compatible dependency package to the relevant information of the target software package in the target database.

In another possible implementation, the target database is the Rpm database.

In another possible implementation, the backup module is also used to back up a predetermined directory in the first operating system during the process of migrating the first operating system to the second operating system.

In a third aspect, embodiments of the present application provide a computing device, which includes a processor and a memory; the processor is coupled to the memory; the memory is used to store computer instructions, and the computer instructions are loaded and executed by the processor to enable the computing device to implement the above The first approach.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium. The computer-readable storage medium includes: computer software instructions; when the computer software instructions are run in a computing device, the computing device implements the method of the first aspect. .

In a fifth aspect, embodiments of the present application provide a computer program product. When the computer program product is run on a computing device, it causes the computing device to execute the steps of the related method described in the first aspect to implement the method in the first aspect. .

For the beneficial effects of the above second to fifth aspects, reference can be made to the corresponding descriptions of the first aspect and will not be described again.

Description of drawings

Figure 1 is a schematic diagram of the composition of a computing device provided by an embodiment of the present application;

Figure 2 is a schematic diagram of the interaction between software modules involved in an operating system migration process provided by an embodiment of the present application;

Figure 3 is a schematic flow chart of an operating system migration method provided by an embodiment of the present application;

Figure 4 is a schematic flow chart of another operating system migration method provided by an embodiment of the present application;

Figure 5 is a schematic flow chart of another operating system migration method provided by an embodiment of the present application;

Figure 6 is a schematic flow chart of another operating system migration method provided by an embodiment of the present application;

Figure 7 is a schematic diagram of an operating system migration process provided by an embodiment of the present application;

Figure 8 is a schematic diagram of the composition of an operating system migration device provided by an embodiment of the present application;

FIG. 9 is a schematic diagram of the composition of another computing device provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of this application.

It should be noted that in the embodiments of this application, words such as "exemplarily" or "for example" are used to represent examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "such as" in the embodiments of the present application is not to be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

In order to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as “first” and “second” are used to distinguish the same or similar items with basically the same functions and effects. Skilled persons can understand that words such as "first" and "second" do not limit the quantity and execution order.

The technical terms involved in the embodiments of this application are explained below.

1. Rpm, Red Hat package manager, the full English name is redhat package manager, is a package manager (software program) used to manage various Linux packages, following the rules of the GNU general public license (GPL) And it is powerful and convenient. The RPM-based package management method can make Linux easy to install and upgrade, thereby improving the applicability of Linux.

2. CentOS, community enterprise operating system, the full English name is community enterprise operating system, is a server operating system provided for free by the open source community and is one of the Linux distributions.

3. Dependency package. In the operating system, dependency package refers to the software package/program package required to run a business application/program. When a business application depends on the functions of other programs or library files, these dependent programs or library files are called dependent packages. These dependency packages are usually some dynamic libraries or static libraries that can provide the required functions, data structures, algorithms and other resources for the program. For example, if a program needs to use functions provided in a certain software package to perform specific operations, then this software package is a dependency package of the program.

4. Dracut, a bootable random access memory (RAM) disk imaging tool, which is used to generate initramfs (initial RAM file system). Initramfs is a temporary file system loaded into the memory before the operating system starts. Its function is to guide the normal startup of the operating system. During the Linux boot process, initramfs is a temporary root file system that contains the necessary drivers and file system tools needed during the operating system startup process. These necessary drivers and file system tools can help the operating system identify and load the required device drivers during startup, and allow the operating system to smoothly enter normal operating mode after startup. In addition, Dracut can also customize the initramfs according to the user's needs to meet the user's specific needs. For example, users can add specific drivers to use during the boot process.

As the open source community announced the cessation of services for CentOS, for enterprises, the suspension of CentOS will lead to problems such as system products not evolving and security vulnerabilities not being resolved, which will bring serious security risks to business applications deployed on live network servers. This in turn brings serious system security problems and business continuity risks to users, and even causes major economic losses. Therefore, for enterprises, it is necessary to migrate the operating system to other versions to ensure the security and operational stability of business applications.

The migration of the operating system is not a simple reinstallation of the operating system, but requires the replacement, adaptation or upgrade of the operating system and the application software or business systems it carries. In actual engineering practice, there are many issues that need to be considered, such as Compatibility analysis, business integrity and migration efficiency in complex business scenarios, etc. Among them, operating system migration can be understood as updating one type of operating system to another type of operating system (such as updating foreign operating systems such as CentOS to domestic operating systems such as fusionOS), or it can also be understood as updating the operating system from Upgrade lower version to higher version.

For business applications, the new version of the business application will not be as stable as the old version of the business application due to the short online time and insufficient comprehensive testing. Therefore, the operating system migration process is often accompanied by the upgrade of various business applications installed in the operating system. Therefore, in order to ensure the stability of existing business applications, users often expect to retain the software packages corresponding to some business applications without upgrading them. However, in this case, migration failure is likely to occur during the operating system migration process.

The reasons for the failure of operating system migration are as follows: During the migration process of the operating system, if a certain software package (such as a target software package) needs to be retained without upgrading, the dependent packages corresponding to the target software package need to be retained without upgrading. , this dependency package may have version conflicts in the new operating system, causing the migration of the operating system to fail. For example, the user wants to keep the software package nginx-1.18 without upgrading. The operation of nginx-1.18 depends on openssl-libs-1.0.2. However, most software in the new operating system depends on openssl-libs-1.1.1, so the openssl-libs version 1.1.1 is automatically installed during the operating system migration process. However, different versions of the same software package cannot exist in the same operating system at the same time. Therefore, openssl-libs-1.0.2 and openssl-libs-1.1.1 conflict and cannot coexist, causing the operating system migration to fail.

In addition, dependency packages that cause version conflicts usually belong to relatively low-level software packages, such as openssl-libs-1.1.1, which most software on new operating systems depends on to run normally. Therefore, when a version conflict occurs, the problem cannot be solved by conventional means of ignoring or uninstalling the dependency package, which will cause the migration of the operating system to fail.

In order to solve the operating system migration failure caused by version conflicts, users can only redeploy business applications. This cannot guarantee the integrity of business data and may cause problems in the recovery of business data. Moreover, the redeployment of business applications also takes a long time.

To sum up, there is an urgent need for a solution that can solve the problem of version conflicts after operating system migration and ensure that the operating system completes the migration normally.

Based on this, embodiments of the present application provide an operating system migration method, which deletes relevant information of the target software package from the target database before the operating system is migrated. Because the migration of the operating system is based on the records of the software packages in the target database. Therefore, the operating system will think that the target software package is not installed and will not process the target software package during the migration process. In this way, the operating system will not report an error due to compatibility issues during the migration process, so that the operating system can complete the migration normally. Finally, install compatible dependency packages on the migrated operating system to ensure that the target software package can run normally on the new operating system. The embodiments provided in this application will be specifically introduced below in conjunction with the accompanying drawings of the description.

The technical solutions provided by the embodiments of this application can be applied to computing devices, which specifically can be blade servers, high-density servers, rack servers, or high-performance servers. Figure 1 is a schematic diagram of the system architecture of a computing device. As shown in Figure 1, the hardware of the computing device includes a processor, an out-of-band controller, a memory, and a memory. The software includes an out-of-band management module and an operating system (OS).

Among them, the out-of-band management module runs in the out-of-band controller, and the OS runs on the processor (as shown in Figure 1).

Among them, the out-of-band management module may be a management unit of a non-service module. For example, the out-of-band management module can remotely maintain and manage the computing device through a dedicated data channel. The out-of-band management module is completely independent of the operating system of the computing device and can communicate with basic input through the out-of-band management interface of the computing device. The output system (basic input output system, BIOS) communicates with the OS.

Exemplarily, the out-of-band management module may include a management unit for the operating status of the computing device, a management system in a management chip outside the processor, a computing device baseboard management controller (BMC), a system management mode ,SMM) etc. It should be noted that the embodiment of the present application does not limit the specific form of the out-of-band management module, and the above is only an exemplary description.

Memory, also known as internal memory or main memory, is installed in a memory slot on the motherboard of a computing device, and communicates with the memory controller through a memory channel. The memory has at least one memory rank (rank). Each memory rank is located on one side of the memory. Each memory rank includes at least one sub-memory rank (subrank). The memory rank or sub-memory rank includes multiple memory chips (device). , each memory chip is divided into multiple storage array groups (bankgroup), each storage array group includes multiple storage arrays (banks), each storage array is divided into multiple storage units (cells), each storage unit has A row address and a column address, each storage unit includes one or more bits. In one division method, memory can be divided into memory chips, storage array groups, storage arrays, storage rows/storage columns, storage units, and bits from upper level to lower level. Among them, memory particles, storage array groups, storage arrays, The addresses of storage rows, columns, storage units, and bits in the memory are real physical addresses. In another way of dividing, the CPU divides the memory chip into multiple memory pages (pages) based on the paging mechanism. The address of the memory page is a virtual address, and the virtual address needs to be converted before it becomes a real physical address.

The memory can be a plug-in hard drive, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computing device, or it can be an external storage device. For example, U disk, etc.

In this embodiment of the present application, the user can pre-install operating system migration software in the memory to enter the pre-installation environment, allowing the user to migrate the original operating system on the computing device.

It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those of ordinary skill in the art will know that , with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

Figure 2 is a schematic diagram of the interaction between software modules involved in an operating system migration process provided by an embodiment of the present application. As shown in Figure 2, it includes two parts, one is the operating system to be migrated (that is, the operating system before migration), and the other is the migration platform, that is, the software module that executes the operating system migration method provided by the embodiment of the present application.

Among them, the operating system to be migrated includes the lowest-level operating system kernel, operating system file system, and various software packages (software packages 1-n) installed in the operating system. Among them, the Rpm database (Rpmdb) is also installed in the operating system file system, and the Rpm database is used to record relevant information of each software in the operating system. Relevant information includes the name, version, dependency information (requires), configuration file, and modification history of the software package.

Among them, the migration platform includes user interface management module, core function module and public module. The user interface management module is used to provide an operation interface for operations related to operating system migration to facilitate user interaction. The core function module is used to implement related functions during operating system migration. Public modules are responsible for some general functions.

The core functional modules specifically include: compatibility analysis module, backup module, migration module and rollback module. The compatibility analysis module is used to analyze the overall differences in operating systems and whether there are conflicts in software packages by analyzing changes in application binary interface (ABI), software package version changes, software package dependency changes, hardware compatibility and other information. The backup module is used to back up critical data using local or remote backup methods. The migration module is used to use the yum (yellow dog updater) management tool or the dnf (dandified yum) management tool, combined with the compatibility analysis results, to formulate corresponding strategies, uninstall, retain, upgrade, and convert software packages to complete the overall migration of the operating system. The rollback module is used to build rollback-specific initramfs and vmlinux through dracut and rely on backup files for key directory rollback to implement operating system rollback.

In addition, the core functional modules also include: retained package migration analysis module. This module is used to delete all information of the target software package from the Rpm database and inform the migration module to perform migration tasks.

The public modules specifically include: log module, user management module and deployment module. The log module is responsible for the generation and centralized management of logs during the operation of the migration platform. The user management module is used to manage user registration, login and other related functions. The deployment module is responsible for the installation and uninstallation of various software packages.

In the embodiment of this application, in the scenario of operating system migration, the user can select the software packages that need to be retained in the operating system to be migrated (that is, the software packages that are not upgraded). (1) The compatibility analysis module in the migration platform performs compatibility analysis on the software packages that need to be retained, and analyzes all incompatible packages, that is, the target software packages. Keep the target software package determined by the package migration analysis module based on the compatibility analysis module. (2) Delete all information related to the target software package from the Rpm database (make a data backup before deletion). Then, (3), the retention package migration analysis module notifies the migration module to perform overall migration of the operating system to be upgraded.

Optionally, during the migration process, the backup module can back up the key operating system directories in the operating system to be migrated and save them in the backup directory. When necessary, the rollback module can roll back the operating system based on the backup in the backup directory (as shown in the dotted line in Figure 2).

Figure 3 is a schematic flowchart of an operating system migration method provided by an embodiment of the present application. Illustratively, the operating system migration method provided by the embodiment of the present application can be applied to the computing device in Figure 1 or the migration platform shown in Figure 2. The following description takes the computing device as the execution subject as an example.

As shown in Figure 3, the operating system migration method provided by the embodiment of the present application may specifically include the following steps:

S301. Determine the target software package in the first operating system.

Among them, the first operating system is the operating system to be migrated.

Among them, the target software package is a software package that will not be upgraded during the migration of the first operating system to the second operating system; and the software package that the target software relies on to run in the first operating system is incompatible in the second operating system. .

It should be understood that, as described in the background art, during the migration process of the operating system, if the user needs to retain a certain software package, the dependent packages of the software package need to be retained. However, these dependent packages will conflict with other software packages on the new operating system (second operating system), which means that there are compatibility issues with the target software packages during the migration process.

Optionally, the above S301 can be implemented as the following steps a-step d: Step a. Obtain the software package to be retained. Step b: Determine the dependent packages of the software package to be retained; the dependent packages are software packages that support the software package to be retained running on the first operating system. Step c: Determine whether there is a version conflict of the dependent package on the second operating system. The version conflict is used to indicate that different versions of the dependent package exist in the second operating system. Step d. If there is a version conflict, determine the software package to be retained as the target software package. It is understandable that for the software packages that users need to retain, only the software packages that have compatibility issues to be retained are deleted for subsequent processing, which can effectively improve the efficiency of operating system migration.

For example, the computing device can obtain the identifier of the software package that needs to be retained input by the user, and for each software package to be retained, the computing device can determine the dependent package in the first operating system that supports the running of the software package to be retained. Further, the computing device determines whether a software package of the same type (same package name) but different version as the dependent package already exists in the second operating system. If it exists, it is determined that the dependent package has a version conflict on the second operating system, and the software package to be retained corresponding to the dependent package is a target software package that is incompatible with the second operating system and will cause subsequent operating system migration to fail.

It should be understood that if there are no compatibility issues in the software packages to be retained, there will be no problems that will cause the operating system migration to fail.

S302. Delete the relevant information of the target software package from the target database.

The target database is used to record relevant information of each software package in the first operating system before and after migration of the first operating system. For example, as shown in Figure 7, before migration, the target database records relevant information of software packages in the first operating system, and after migration, the target database records relevant information of software packages in the second operating system.

It should be understood that the target database records relevant information of each software package in the current operating system. During the migration process, the operating system is migrated based on the list of software packages recorded in the target database. Therefore, in this embodiment of the present application, the computing device can query and determine the relevant information of the target software package from the target database according to the identification of the target software package, and delete the relevant information from the target database, thus ensuring subsequent operating system migration. The target software package is ignored during migration.

For example, the relevant information of the target software package recorded in the target database may include version, requires, provides, files, conflicts, obsoletes, spec, etc. information. Among them, version refers to the version number of the software package. It is usually a string such as "1.0.0", indicating that this is the 1.0.0 version of the package. requires lists other software packages or system components that the software package depends on to run, that is, a software package may require a specific version of another software package to run. provides specifies which functions the package provides that are required by other packages, allowing other software to query this package to find the dependencies they need. In other words, provides can indicate which other software packages the package can use as a dependency package. files lists the files installed by the package, which may include binaries, configuration files, documentation, etc. conflicts lists other packages that are incompatible with this package. Often, if these conflicting packages are also installed, it can cause problems or conflicts. obsoletes means that if this package is installed, then some other package in the operating system will be marked as obsolete or no longer needed. A spec usually refers to a specific specification or standards document that describes how to build and package software programs. In most Linux distributions, spec files are used to describe how to build RPM packages. This file contains various metadata as well as instructions and scripts required for the build.

Optional, the target database is the Rpm database. The Rpm database can record various information about software packages and their files. The Rpm package manager manages software packages based on the Rpm database.

S303. Migrate the first operating system to the second operating system based on the target database.

In this embodiment of the present application, after the relevant information of the target software package is deleted from the target database, the operating system can be migrated based on the deleted target database, and the current first operating system can be migrated to the second operating system.

Optionally, you can use the yum tool or the dnf tool to implement the operating system migration process.

It can be understood that in the above S302, the relevant information of the target software package in the target database is deleted (the actual running file of the target software package still exists in the computing device), because the migration of the operating system is based on the software package recorded in the target database. Listing is performed so that the target package is not processed by the computing device during the operating system migration process. That is to say, during the operating system migration process, the computing device will think that the target software package is not installed, which is equivalent to bypassing the target software package for migration. In this way, migration failure will not occur due to compatibility issues in the target software package. If an error or alarm is reported, the operating system can complete the migration normally.

S304. Install compatible dependency packages on the second operating system.

Among them, the compatibility dependency package is used to support the target software package to be compatible with the second operating system.

It should be understood that by deleting the relevant information of the target software package in the target database, the target software package can be bypassed and the normal migration of the operating system can be completed. However, the target software package cannot run normally on the migrated operating system (second operating system) because it lacks the necessary dependency packages to support its operation. Because the dependent packages of the target software package may have been upgraded with the migration of the operating system (for example, the target software package nginx-1.18 depends on openssl-libs-1.0.2, but after the operating system is migrated, openssl-libs-1.0.2 will also Subsequently upgraded to openssl-libs-1.1.1). Therefore, in order to ensure the normal operation of the target software package, a compatible dependency package that supports the operation of the target software package can be installed on the second operating system to solve the operation problem of the target software package.

In one implementation, before S304, the computing device can obtain the compatible dependency package in the following manner: according to the identifier of the target software package, query the compatible dependency package corresponding to the target software package from the compatible dependency package collection. The set of compatible dependency packages includes software packages that support running on a second operating system without upgrading the software package.

It can be understood that the computing device can be pre-configured with a set of compatible dependency packages used by various software packages to run on the second operating system. The set of compatible dependency packages can be stored locally (such as on a computing device) or on the network side. After the operating system migration is completed, the computing device can query the compatible dependency package corresponding to the target software package from the compatible dependency package collection, and install the compatible dependency package on the second operating system to support the target software package on the second operating system. of normal operation. Directly query and install compatible dependency packages from the pre-configured collection of compatible dependency packages, which can greatly improve migration efficiency.

In another implementation, before S304, the computing device can also obtain the compatible dependency package in the following manner: step a, obtain the dependency package that supports the target software package to run on the first operating system; step b, transfer the dependency package of the dependency package to Change the name to get compatible dependency packages.

It is understandable that, as mentioned before, dependent packages have version conflicts because different versions of similar software packages exist on the same operating system. In other words, the target software package (such as nginx-1.18) needs to be supported by the old version of the dependent package (such as openssl-libs-1.0.2) when running on the second operating system, but the second operating system will install the new version by default. Dependent package (openssl-libs-1.1.1), in this case, the old version of the dependent package cannot be reinstalled on the second operating system. Therefore, the computing device can change the package name of the old version of the dependent package (for example, change openssl-libs-1.0.2 to compat-openssl-libs-1.0.2) and install it after obtaining the compatible dependent package. In this way, for the computing device Or the operating system will think that the dependent package after the package name is modified is a new type of software package that is not found in the existing operating system, so no version conflicts will be reported during the installation process. It is easy to understand that the essence of this compatible dependency package is consistent with the old version of the dependency package (the functions are the same), only the package name is different. This method of changing the package name of a dependent package can directly obtain the corresponding compatible dependent package, which is applicable to any type of software package and can effectively improve the versatility of the operating system migration method.

Wherein, the computing device obtains the dependency package of the target software package running on the first operating system, which may be obtained and saved in advance before the operating system is migrated. It may also be that after the operating system is migrated, the computing device temporarily downloads the corresponding dependency package from the network, and further modifies the package name to obtain a compatible dependency package. The embodiments of the present application do not specifically limit this.

As mentioned above, the target database is used to record the relevant information of each software package in the first operating system before and after the migration of the first operating system, and to subsequently manage each software package in the migrated operating system (such as upgrade, change, uninstallation). etc.) are also performed depending on the target database. However, since there is no relevant information about the target software package in the target database, it is inconvenient for subsequent management and maintenance of the target software package.

Therefore, in conjunction with Figure 3, as shown in Figure 4, the operating system migration method provided by the embodiment of the present application also includes the following:

S401. Obtain relevant information of the target software package from the target database.

S402. Back up the relevant information of the target software package to the storage space.

The above S401 and S402 can be executed before the above S302. That is, before deleting the relevant information of the target software package from the target database, the computing device can query and obtain the relevant information of the target software package from the target database, make a backup and save it to facilitate subsequent data recovery. The storage space for backup saving may be a local storage space of the computing device or a storage space on the network side, which is not specifically limited in the embodiment of the present application.

Combined with Figure 3, as shown in Figure 5, after the operating system migration is completed in S303, the operating system migration method provided by the embodiment of the present application also includes the following:

S403. Obtain relevant information of the target software package from the storage space.

S404. Update relevant information of the target software package to the target database.

For the above S403 and S404, after the operating system migration is completed, the computing device can obtain the relevant information of the target software package from the storage space, and update and restore the relevant information to the target database. In this way, the relevant information of the target software package is re-recorded in the target database, so that the user can easily maintain the target software package when using the new operating system.

In addition, the target database also records the dependencies (requires) of each software package, that is, which dependent packages are required to run a software package. Therefore, in conjunction with Figure 3, as shown in Figure 6, the operating system migration method provided by the embodiment of the present application also includes the following:

S305. Update the dependency relationship between the target software package and the compatible dependent package to the relevant information of the target software package in the target database.

Among them, the dependency relationship is used to reflect the relationship between the software package that supports the operation of the target software package and the target software package.

The above S305 may be executed after the above S304. It should be understood that in this embodiment of the present application, the computing device backs up relevant information when the target software package runs on the first operating system. After the operating system migration is completed, the dependencies of the target software package have changed, so the dependencies of the software package are not the latest in the relevant information after backup and restoration. Therefore, after installing the compatible dependency package on the second operating system, the computing device can update the dependency relationship between the target software package and the compatible dependency package to the target database, so that the user can update the target software package during subsequent use of the operating system. Dependencies are maintained.

Optionally, the operating system migration method provided by the embodiment of this application also includes the following S306.

S306. During the process of migrating the first operating system to the second operating system, back up the predetermined directory in the first operating system.

It should be understood that the predetermined directory is used to save core files of the first operating system. Backing up the predetermined directory can facilitate subsequent operating system rollback when the second operating system after migration encounters problems and cannot run, ensuring the fault tolerance of the migration plan.

The following is a complete description of the operating system migration method provided by the embodiments of the present application with reference to specific examples. Figure 7 is a schematic diagram of an operating system migration process provided by an embodiment of the present application, as shown in Figure 7 . First, determine nginx1.0 as the target software package that needs to be retained. 1. Obtain its corresponding relevant information in the Rpm database and back it up. 2. Delete the relevant information from the Rpm database. Further, 3. Migrate the operating system based on the deleted Rpm database, in which most software packages in the operating system are also upgraded to new versions. For example, aaa.1.0 is upgraded to aaa.3.0, httpd.1.0 is upgraded to httpd.2.0, openssl-libs-1.0.2 is upgraded to openssl-libs-1.1.1, etc. However, the target software package is still nginx1.0, and the version has not been updated accordingly. Then, 4. Restore the backed up information to the Rpm database. Further, on the migrated operating system, 5. Install the compatible dependency package compat-openssl-libs-1.0.2 to support the normal operation of nginx1.0. At this point, the operating system migration is completed.

Embodiments of the present application provide an operating system migration method, which deletes relevant information of the target software package from the target database before the operating system is migrated. Because the migration of the operating system is based on the records of the software packages in the target database. Therefore, the operating system will think that the target software package is not installed and will not process the target software package during the migration process. In this way, the operating system will not report an error due to compatibility issues during the migration process, so that the operating system can complete the migration normally. Finally, install compatible dependency packages on the migrated operating system to ensure that the target software package can run normally on the new operating system.

Furthermore, before deleting the relevant information, the relevant information is also backed up to facilitate recovery to the target database after the operating system migration is completed, and to facilitate subsequent management and maintenance of the software package. In addition, updating the dependency relationship between the compatible dependency package and the target software package to the target database can further facilitate the operation and maintenance management of the software package and improve the user experience. Compared with the redeployment solution, this method is more efficient and saves more upgrade time. In addition, the backup storage space required for redeployment can be saved, and the storage resources of the computing device can be saved.

It can be seen that the solutions provided by the embodiments of the present application are mainly introduced from the perspective of methods. In order to realize the above functions, embodiments of the present application provide corresponding hardware structures and/or software modules to perform each function. Those skilled in the art should easily realize that, in conjunction with the modules and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is performed by hardware or by computer software driving the hardware depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each specific application, but such implementations should not be considered beyond the scope of this application.

In an exemplary embodiment, the present application also provides an operating system migration device. The migration device may be the aforementioned computing device, or may be a processor in the computing device. The migration device may include one or more functional modules for implementing the operating system migration method of the above method embodiment.

For example, FIG. 8 is a schematic diagram of the composition of an operating system migration device provided by an embodiment of the present application. As shown in FIG. 8 , the operating system migration device includes: a determination module 801 , a deletion module 802 , a migration module 803 and an installation module 804 . The determination module 801, the deletion module 802, the migration module 803 and the installation module 804 are connected to each other.

The determination module 801 is used to determine the target software package in the first operating system; wherein the target software package is a software package that will not be upgraded and is incompatible with the first operating system during the migration to the second operating system; the deletion module 802 is used to delete the relevant information of the target software package from the target database; the target database is used to record the relevant information of each software package in the first operating system before and after the migration of the first operating system; the migration module 803 is used to, based on the target database , migrate the first operating system to the second operating system; the installation module 804 is used to install the compatible dependency package on the second operating system; the compatible dependency package is used to support the target software package to be compatible with the second operating system.

In one possible implementation, the determination module 801 is specifically configured to obtain the software package to be retained; determine the dependent packages of the software package to be retained; the dependent packages are software packages that support the software package to be retained running on the first operating system; determine Whether there is a version conflict of the dependent package on the second operating system; the version conflict is used to indicate that different versions of the dependent package exist in the second operating system; if there is a version conflict, the software package to be retained is determined to be the target software package.

In another possible implementation, the above device further includes: an acquisition module 805. The acquisition module 805 is used to obtain the compatible dependency package corresponding to the target software package from the compatible dependency package set according to the identification of the target software package; the compatible dependency package set includes software packages that support non-upgraded software packages running on the second operating system. .

In another possible implementation, the above device further includes: a modification module 806. The obtaining module 805 is also used to obtain the dependency package that supports the target software package to run on the first operating system; the changing module 806 is used to change the package name of the dependency package to obtain a compatible dependency package.

In another possible implementation, the above device further includes: a backup module 807. The acquisition module 805 is also used to obtain the relevant information of the target software package from the target database; the backup module 807 is used to back up the relevant information of the target software package to the storage space.

In another possible implementation, the above device further includes: an update module 808. The acquisition module 805 is also used to obtain relevant information from the storage space; the update module 808 is used to update the relevant information to the target database.

In another possible implementation, the update module 808 is also used to update the dependency relationship between the target software package and the compatible dependency package to the relevant information of the target software package in the target database.

In another possible implementation, the target database is the Rpm database.

In another possible implementation, the backup module 807 is also used to back up a predetermined directory in the first operating system during the process of migrating the first operating system to the second operating system.

In an exemplary embodiment, the embodiment of the present application also provides a computing device. Figure 9 is a schematic diagram of the composition of a computing device provided by an embodiment of the present application. As shown in Figure 9, the computing device may include: a processor 901 and a memory 902; the memory 902 stores instructions executable by the processor 901; when the processor 901 is configured to execute the instructions, the computing device implements the foregoing method embodiments. method described in .

An embodiment of the present application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be completed by computer instructions to instruct relevant hardware. The program can be stored in the above computer-readable storage medium. When executed, the program can include the processes of the above method embodiments. . The computer-readable storage medium may be the memory of any of the aforementioned embodiments. The computer-readable storage medium may also be an external storage device of the recovery device, such as a plug-in hard drive, a smart media card (SMC), or a secure digital (SD) card equipped on the recovery device. Flash card, etc. Furthermore, the computer-readable storage medium may also include both the internal storage unit of the recovery device and an external storage device. The above-mentioned computer-readable storage medium is used to store the above-mentioned computer program and other programs and data required by the above-mentioned recovery device. The above-mentioned computer-readable storage media can also be used to temporarily store data that has been output or is to be output.

An embodiment of the present application also provides a computer program product. The computer product includes a computer program. When the computer program product is run on a computer, it causes the computer to perform any of the operating system migration methods provided in the above embodiments.

Although the present application has been described herein in connection with various embodiments, in practicing the claimed application, those skilled in the art can understand and implement the disclosure by reviewing the drawings, the disclosure, and the appended claims. Other variations of the embodiment. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit may perform several of the functions recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not mean that a combination of these measures cannot be combined to advantageous effects.

Although the present application has been described in conjunction with specific features and embodiments thereof, it will be apparent that various modifications and combinations may be made without departing from the spirit and scope of the application. Accordingly, the specification and drawings are intended to be merely illustrative of the application as defined by the appended claims and are to be construed to cover any and all modifications, variations, combinations or equivalents within the scope of the application. Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. In this way, if these modifications and variations of the present application fall within the scope of the claims of the present application and equivalent technologies, the present application is also intended to include these modifications and variations.

The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be covered by the protection scope of the present application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims (10)

1. A method of operating system migration, the method comprising:

determining a target software package in a first operating system; the target software package is a software package which is not updated and is incompatible in the process of migrating the first operating system to the second operating system;

deleting the related information of the target software package from a target database; the target database is used for recording the related information of each software package in the first operating system before and after the migration of the first operating system;

migrating the first operating system to the second operating system based on the target database;

installing a compatibility dependent package on the second operating system; the compatibility dependency package is used for supporting the target software package to be compatible and run on the second operating system.

2. The method of claim 1, wherein the determining the target software package in the first operating system comprises:

Acquiring a software package to be reserved;

determining a dependent package of the software package to be reserved; the dependency package is a software package supporting the software package to be reserved to run on the first operating system;

determining whether a version conflict exists on the second operating system for the dependency package; the version conflict is used for indicating that different versions of the dependent package exist in the second operating system;

and determining the software package to be reserved as the target software package under the condition that version conflict exists.

3. The method of claim 1 or 2, wherein prior to installing a compatible dependency package on the second operating system, the method further comprises:

acquiring a compatible dependency package corresponding to the target software package from a compatible dependency package set according to the identification of the target software package; the set of compatible dependency packages includes software packages that support non-upgraded software packages running on the second operating system.

4. The method of claim 1 or 2, wherein prior to installing a compatible dependency package on the second operating system, the method further comprises:

acquiring a dependency package supporting the target software package to run on the first operating system;

And changing the packet name of the dependent packet to obtain the compatible dependent packet.

5. The method of any of claims 1-4, wherein prior to deleting the relevant information of the target software package from the target database, the method further comprises:

acquiring related information of the target software package from the target database;

and backing up the related information of the target software package to a storage space.

6. The method of claim 5, wherein after migrating the first operating system to the second operating system, the method further comprises:

acquiring related information of the target software package from the storage space;

and updating the related information of the target software package to the target database.

7. The method of claim 6, wherein the method further comprises:

and updating the dependency relationship between the target software package and the compatible dependency package into the related information of the target software package in the target database.

8. The method according to any one of claims 1-7, wherein the target database is a red cap package manager Rpm database.

9. The method according to any one of claims 1-8, further comprising: and in the process of migrating the first operating system to the second operating system, backing up a preset catalogue in the first operating system.

10. A computing device, the computing device comprising a processor and a memory; the processor is coupled with the memory; the memory is configured to store computer instructions that are loaded and executed by the processor to cause a computing device to implement the operating system migration method of any one of claims 1-9.