Linux operating system in-situ upgrade migration method, device and equipment and storage medium

Abstract

The invention discloses an in-situ upgrading migration method, device and equipment for a Linux operating system and a storage medium, and relates to the technical field of operating system upgrade.The in-situ upgrading migration method for the Linux operating system comprises the steps that whether the current Linux meets upgrading conditions or not is judged, if yes, adaptation configuration of a new version is loaded, and if not, the adaptation configuration of the new version is not loaded; comprising a warehouse address, a signature key and identification packet mapping; then, the configuration package manager accesses the new warehouse, and the software package is upgraded after multiple rounds of dependency analysis repair are executed; and finally, updating the system identifier, the boot configuration, the service state and the modular warehouse configuration according to the mapping relationship and the boot mode to finish upgrading. According to the method, the Linux operating system can be upgraded to a new version in situ.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of operating system upgrade, in particular to a Linux operating system in-place upgrade migration method, device and storage medium. BACKGROUND

[0002] With the rapid iteration of domestic Linux distributions, the system underlying architecture often undergoes substantial adjustments in repository structure, RPM GPG signature key, system identification package, file path specification and services, and other key elements during version updates. Users hope to smoothly migrate the current running old version to the latest version without interrupting business and reinstalling the system, in order to reduce operation and maintenance costs and maintain business continuity.

[0003] The existing approach is to back up applications and data before upgrading a major version, then install a new target version of the operating system, and finally restore the backup data to the new system. Although the open source community provides migration tools such as Leapp (RHEL specific) or x2openEuler, they are either tailored for specific versions or used for cross-distribution migration, and all require separate development, configuration and maintenance on the target version.

[0004] Problems with the existing approach: (1) Reinstalling takes time and effort, and the business interruption time is long, and the cost of manpower and downtime is multiplied in large-scale cluster scenarios. (2) Special migration tools lack universality and need to be re-customized for each new version or new distribution, resulting in a large maintenance workload. (3) Directly running dnf upgrade / distro-sync will cause conflicts due to repository, signature, dependency and configuration differences, making the upgrade prone to failure and ultimately forced to revert to the reinstall solution. Therefore, how to upgrade the Linux operating system in-place to a new version becomes a problem to be solved.

[0005] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0006] The present application aims to provide a Linux operating system in-place upgrade migration method, device and storage medium, which aims to solve the technical problem of how to upgrade the Linux operating system in-place to a new version.

[0007] To achieve the above purpose, the present application provides a Linux operating system in-place upgrade migration method, which comprises:

[0008] According to the release identification, version information and system state information of the current operating system, it is judged whether the upgrade condition is met, and a judgment result is obtained;

[0009] When the result of the judgment is satisfied, loading adaptation configuration data of the target new version operating system according to the distribution identifier and the version information, the adaptation configuration data including a software package warehouse address, a signature key and a mapping relationship of new and old system identifier packages of the target new version operating system;

[0010] According to the software package warehouse address and the signature key, configuring a software package manager to access a target new version warehouse;

[0011] Based on the configured software package manager, performing a multi-round dependent analysis recursive repair operation, and when the recursive repair operation is completed, performing a software package upgrade operation;

[0012] When the software package upgrade operation is completed, updating system identifier information, a boot loader configuration, a service state and a modular warehouse configuration to a target new version state according to the mapping relationship and the boot mode of the current operating system, and completing the upgrade.

[0013] In an embodiment, when the result of the judgment is satisfied, the step of loading adaptation configuration data of the target new version operating system according to the distribution identifier and the version information includes:

[0014] When the result of the judgment is satisfied, matching a corresponding adaptation plug-in library according to the distribution identifier;

[0015] Loading a configuration file of the target new version operating system from the adaptation plug-in library according to the version information;

[0016] Parsing the configuration file to obtain adaptation configuration data.

[0017] In an embodiment, the step of, based on the configured software package manager, performing a multi-round dependent analysis recursive repair operation, and when the recursive repair operation is completed, performing a software package upgrade operation includes:

[0018] Based on the configured software package manager, executing a simulated upgrade analysis command to obtain dependent conflict output information;

[0019] Parsing the dependent conflict output information to identify a conflict type and generate a marking operation instruction;

[0020] According to the marking operation instruction, constructing a software package manager execution script, and executing the software package manager execution script;

[0021] In a case that the script execution of the software package manager is completed, a step of returning the configured software package manager to execute the simulated upgrade analysis command to obtain the dependency conflict output information until the dependency conflict output information is no longer generated, and completing the recursive repair operation;

[0022] In a case that the recursive repair operation is completed, a software package upgrade operation is performed.

[0023] In an embodiment, the marking operation instruction includes a to-be-uninstalled instruction, a to-be-installed instruction, and a to-be-ignored instruction.

[0024] The step of analyzing the dependency conflict output information, identifying the conflict type, and generating the marking operation instruction includes:

[0025] The dependency conflict output information is analyzed to obtain a conflict type identifier.

[0026] In a case that the conflict type identifier is a software package coexistence conflict, a to-be-uninstalled instruction of an old version software package and a to-be-installed instruction of a new version software package are generated.

[0027] In a case that the conflict type identifier is a dependency missing conflict, a to-be-uninstalled instruction of a local software package causing the missing is generated.

[0028] In a case that the conflict type identifier is a software package replacement conflict, a to-be-ignored instruction of an old software package is generated.

[0029] In an embodiment, the step of configuring a software package manager to access a target new version repository according to the software package repository address and the signature key includes:

[0030] The software package repository address is added to a temporary repository configuration of the software package manager;

[0031] A local file path of the signature key is added to a verification parameter of the temporary repository configuration;

[0032] A signature verification function of the software package manager is enabled;

[0033] A system version identifier corresponding to the target new version repository is added to an environment variable of the software package manager.

[0034] In an embodiment, the step of judging whether an upgrade condition is met according to a distribution identifier, version information, and system state information of a current operating system to obtain a judgment result includes:

[0035] An adaptation rule verification is performed according to the distribution identifier and the version information of the current operating system to obtain an adaptation rule verification result.

[0036] analyzing system state information of the current operating system to obtain a user permission state, a software package database state, and a disk remaining space value;

[0037] verifying the user permission state to obtain an administrator permission confirmation result;

[0038] performing integrity checking on the software package database state to obtain a database integrity state result;

[0039] comparing the disk remaining space value with a preset space threshold to obtain a space sufficiency state result;

[0040] obtaining a judgment result according to the adaptation rule verification result, the administrator permission confirmation result, the database integrity state result, and the space sufficiency state result.

[0041] In an embodiment, the method further comprises:

[0042] creating a system rollback point before the upgrade starts, the rollback point being a file system snapshot or a software package state list;

[0043] during the upgrade process, recording operation logs, configuration change records, and error information of a package manager to a log file;

[0044] continuously monitoring the log file during the upgrade process, and when a preset error mode is detected, re-downloading a damaged software package or repairing an incomplete installation;

[0045] when an upgrade failure is detected, triggering a rollback operation according to the file system snapshot and the software package state list.

[0046] In addition, to achieve the above-mentioned purpose, the present application also provides a Linux operating system in-place upgrade migration device, the device comprises:

[0047] an environment detection module configured to determine whether an upgrade condition is met according to a distribution version identifier, version information, and system state information of a current operating system, and obtain a judgment result;

[0048] a parameter adaptation module configured to, when the judgment result is that the upgrade condition is met, load adaptation configuration data of a target new version operating system according to the distribution version identifier and the version information, the adaptation configuration data comprising a software package repository address, a signature key, and a mapping relationship between new and old system identifier packages of the target new version operating system;

[0049] a manager configuration module configured to configure a software package manager to access a target new version repository according to the software package repository address and the signature key;

[0050] The upgrading module is configured to perform a multi-round dependency analysis recursive repair operation based on the configured software package manager, and perform a software package upgrading operation when the recursive repair operation is completed.

[0051] The state switching module is configured to update system identification information, a bootloader configuration, a service state and a modular repository configuration to a target new version state according to the mapping relationship and a boot mode of the current operating system when the software package upgrading operation is completed, and complete the upgrading.

[0052] In addition, to achieve the above-mentioned purpose, the present application further provides a Linux operating system in-place upgrade migration device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the Linux operating system in-place upgrade migration method as described above.

[0053] In addition, to achieve the above-mentioned purpose, the present application further provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the Linux operating system in-place upgrade migration method as described above.

[0054] In addition, to achieve the above-mentioned purpose, the present application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the Linux operating system in-place upgrade migration method as described above.

[0055] The one or more technical solutions provided by the present application have at least the following technical effects:

[0056] Firstly, the upgrade migration system judges whether the upgrade condition is met according to the release identification, version information and system state information of the current operating system, obtains a judgment result, avoids upgrading in an incompatible or resource insufficient environment, and thus ensures the reliability and safety of the upgrade process. When the judgment result is that the condition is met, the system loads the adaptation configuration data of the target new version operating system according to the release identification and version information, including the software package repository address, signature key and mapping relationship of new and old system identification packages, provides necessary configuration information for subsequent upgrade operations, and ensures that the upgrade process can proceed smoothly. Then, the system configures the software package manager to access the target new version repository according to the software package repository address and signature key, ensures that the software package manager can correctly access the target new version repository, obtains the required software package, and lays a foundation for subsequent software package upgrade operations. Then, the system performs multiple rounds of dependency analysis and recursive repair operations based on the configured software package manager, and performs software package upgrade operations when the recursive repair operations are completed. This step improves the upgrade success rate by automatically processing dependency conflicts and incompatibility problems, and ensures the smooth progress of the software package upgrade operation. Finally, when the software package upgrade operation is completed, the system updates the system identification information, bootloader configuration, service state and modular repository configuration to the target new version state according to the mapping relationship and the boot mode of the current operating system, and completes the upgrade. This step ensures that the upgraded system is consistent with the target new version in terms of identification, boot, service and module configuration, so that the Linux operating system can be upgraded to a new version in place. BRIEF DESCRIPTION OF DRAWINGS

[0057] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0058] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0059] Figure 1 A flowchart provided for the Linux operating system in-place upgrade migration method embodiment one of the present application;

[0060] Figure 2 A flowchart provided for the Linux operating system in-place upgrade migration method embodiment two of the present application;

[0061] Figure 3 A brief flowchart of the Linux operating system in-place upgrade migration method provided for the embodiment two of the present application;

[0062] Figure 4 A module structure diagram of an in-place upgrade migration device for an embodiment of the Linux operating system of the present application;

[0063] Figure 5 A device structure diagram of a hardware running environment involved in the in-place upgrade migration method for the Linux operating system in the embodiment of the present application.

[0064] The object implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0065] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application, and are not used to limit the present application.

[0066] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the drawings of the specification and the specific embodiments.

[0067] It should be noted that the execution subject of the embodiment of the present application can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, an upgrade migration system, etc. capable of realizing the above functions. The following will take the upgrade migration system as an example to describe the embodiment and each of the following embodiments.

[0068] Based on this, the embodiment of the present application provides an in-place upgrade migration method for the Linux operating system, which is described in detail with reference to Figure 1 , Figure 1 A flowchart of the first embodiment of the in-place upgrade migration method for the Linux operating system of the present application.

[0069] In the embodiment, the in-place upgrade migration method for the Linux operating system includes steps S10-S50:

[0070] Step S10, according to the release identification, version information and system state information of the current operating system, it is judged whether the upgrade condition is met, and the judgment result is obtained.

[0071] It should be noted that the current operating system refers to a local Linux instance running an upgrade program, i.e., to be upgraded in place. The distribution identifier refers to symbolic information that can uniquely identify the source and ancestry of the operating system, such as the distribution name (e.g., openEuler, Kylin, Anolis), manufacturer mark, family code, etc. The version information refers to the specific iteration identifier of the operating system in its life cycle, usually represented as a version number (e.g., 20.03, V10 SP2), kernel version, release date, or internal code, used to distinguish new and old feature sets. The system state information refers to the instantaneous snapshot of the current running environment, including but not limited to CPU architecture, boot mode (BIOS / UEFI), disk remaining space, installed software package integrity, root permission availability, and system service running status, etc. The upgrade condition refers to a series of pre-requirements that must be met to ensure successful upgrade, such as having administrator privileges, system not in damaged state, disk remaining space greater than threshold, distribution and target version within support matrix, RPM database consistent, etc. The judgment result refers to the conclusion output after comparing with the preset upgrade condition, only containing "satisfy" or "not satisfy" two states, used to decide whether to continue in-place upgrade.

[0072] As an example, the step of judging whether the upgrade condition is satisfied according to the distribution identifier, version information and system state information of the current operating system, and obtaining a judgment result includes: performing adaptation rule verification according to the distribution identifier and version information of the current operating system, and obtaining an adaptation rule verification result; analyzing the system state information of the current operating system to obtain user permission state, software package database state and disk remaining space value; verifying the user permission state to obtain an administrator permission confirmation result; performing integrity check on the software package database state to obtain a database integrity state result; comparing the disk remaining space value with a preset space threshold to obtain a space sufficient state result; and obtaining a judgment result according to the adaptation rule verification result, the administrator permission confirmation result, the database integrity state result and the space sufficient state result.

[0073] The adaptation rule verification result refers to the "match" or "no match" conclusion obtained after matching the release identification and version information of the current operating system with the defined target version adaptation rule. The user permission state refers to the identity level of the current execution upgrade process. The package database state refers to whether the RPM / DNF database is damaged or missing index. The disk remaining space value refers to the amount of free bytes in the root partition and temporary directory available for upgrade. The administrator permission confirmation result refers to the "has root permission" or "does not have root permission" determination obtained according to the user permission state. The database integrity state result refers to the "complete" or "damaged" conclusion obtained after checking the package database state. The space sufficient state result refers to the "sufficient" or "insufficient" determination obtained after comparing the disk remaining space value with the preset threshold.

[0074] Firstly, the upgrade migration system reads files such as / etc / os-release, extracts the release name and version number string, and compares it with the built-in adaptation rule list item by item. If a matching item is found, the "adaptation rule verification result" is set to pass, otherwise it is set to fail. In this way, unsupported system combinations can be excluded in advance. Secondly, the system calls getuid / geteuid to determine whether the current process UID (user identifier) is 0. If it is, the "administrator permission confirmation result" is set to pass, otherwise it is set to fail. Then rpm--rebuilddb is executed and the return code is checked. If the return code is 0, the "database integrity state result" is set to pass, otherwise it is set to fail. The free byte amount of the root partition and temporary directory is obtained by df -B 1 / / var / tmp, and compared with the preset threshold of 2GB (2x1024x1024x1024 bytes). If it is greater than or equal to, the "space sufficient state result" is set to sufficient, otherwise it is set to insufficient. These three parallel verifications ensure that the subsequent upgrade has permission, the data is not damaged, and the space is sufficient. Finally, the system performs a logical AND operation on the above four Boolean values. If all are true, the "judgment result" is output as "satisfy upgrade conditions", and if any is false, it is output as "not satisfy upgrade conditions", thereby deciding whether to continue the subsequent upgrade process.

[0075] In step S20, when the judgment result is satisfied, the adaptation configuration data of the target new version operating system is loaded according to the release identification and the version information. The adaptation configuration data includes the package repository address, signature key and mapping relationship of new and old system identification package of the target new version operating system.

[0076] It should be noted that the target new version operating system refers to the next generation Linux distribution entity released by the same manufacturer that the user hopes to upgrade to in place. The adaptation configuration data refers to all parameter sets saved in a structured file or plug-in form, read by the upgrade program and used to complete cross-version difference processing. The software package repository address refers to the HTTP / HTTPS root path where the RPM package is stored on the official or mirror site of the target new version operating system. The signature key refers to the GPG public key file or its fingerprint value used to verify the integrity and source credibility of the RPM package in the repository. The new and old system identification package refers to the distribution identification RPM package representing the identity of the old and new version systems, such as distro-release, logos, release-notes, etc. The mapping relationship refers to the one-to-one association table of the package name of the old version system identification package and the corresponding package name of the new version system identification package.

[0077] As an example, when the judgment result is satisfied, the step of loading the adaptation configuration data of the target new version operating system according to the distribution identification and the version information includes: when the judgment result is satisfied, matching the corresponding adaptation plug-in library according to the distribution identification; loading the configuration file of the target new version operating system from the adaptation plug-in library according to the version information; and parsing the configuration file to obtain the adaptation configuration data.

[0078] The adaptation plug-in library refers to a collection directory or repository storing various distribution upgrade adaptation plug-ins, wherein each subdirectory or compressed package is named by a distribution identification, and contains scripts, keys and mapping tables required for upgrading all historical versions of the distribution to the target new version. The configuration file refers to a text file in YAML / JSON format located in the corresponding adaptation plug-in directory, which lists the software package repository address, signature key, new and old system identification package mapping and other upgrade parameters of the target new version operating system item by item, for the upgrade program to parse and execute.

[0079] First, the upgrade migration system takes the distribution identification string extracted from the current system as a directory name, and searches in two places: locally in / opt / migrate / adapters and remotely on the server. First, try locally, if it does not exist, initiate an HTTPS GET request to the remote repository, pull the filelist.json of the corresponding directory, and compare whether the directory name matches exactly. If the match is successful, the directory is locked, thereby ensuring that the correct adaptation plug-in library can be found whether offline or online. Second, the system concatenates the current system version number and the target version number to form the complete file name v<old version>-to-<new version>.yaml, and confirms the existence of the file in the directory by stat or HEAD request, and then calls curl-L-o / tmp / target.yaml <url>(Download to a temporary file) or directly open ( / opt / migrate / adapters / <distribution> / v<version>.yaml) to read the local file, which can avoid loading failure due to spelling differences in file names. Finally, the system uses the Python PyYAML or Goyaml.v3 library to parse / tmp / target.yaml line by line, and maps the top-level keys repo_url, gpg_key_path, package_mapping, etc. to the in-memory structure AdapterConfig{}. After parsing, it immediately checks whether the mandatory fields are empty, whether the URL is reachable, and whether the GPG fingerprint format is correct. If the check fails, an exception is thrown to terminate, preventing subsequent upgrades from failing due to missing parameters. After passing the check, AdapterConfig{} is the final available adaptation configuration data, which is directly called by the subsequent software repository switching and package mapping steps.

[0080] In step S30, the software package manager is configured to access the target new version repository according to the software package repository address and the signature key.

[0081] It should be noted that the software package manager refers to the core tool in the operating system responsible for installing, upgrading, deleting, and querying RPM software packages, usually dnf (Dandified YUM). The target new version repository refers to the official or mirror network address set of all RPM software packages and their metadata of the target new version operating system, which serves as the only source for the software package manager to obtain new version software packages during upgrading.

[0082] As an example, the step of configuring the software package manager to access the target new version repository according to the software package repository address and the signature key includes: adding the software package repository address to the temporary repository configuration of the software package manager; adding the local file path of the signature key to the verification parameters of the temporary repository configuration; enabling the signature verification function of the software package manager; and adding the system version identifier corresponding to the target new version repository to the environment variable of the software package manager.

[0083] The temporary repository configuration refers to the dnf repository segment generated dynamically by the upgrade migration system during the upgrade session and only resides in the memory, which is injected by using --setopt=repoid.<option>=<value>(--setopt=repoid.option=value) or --repofrompath=repoid,url(--repofrompath=repository identifier, repository address) and is invalidated after exiting to avoid polluting the original system repo file. The local file path refers to the absolute path after the signature key GPG public key file has been pre-downloaded to the local disk, for example, / etc / pki / rpm-gpg / RPM-GPG-KEY-target. The verification parameter refers to the two settings of gpgkey=file: / / <local file path>(gpgkey=file: / / <local file path>) and gpgcheck=1(gpgcheck=1) in the temporary repository configuration, which is used to tell dnf to verify the package signature of the repository with the specified key. The signature verification function refers to the automatic calling of the GPG mechanism by dnf to verify the signature of the rpm header and payload when downloading the software package, and the verification fails to refuse to install, preventing man-in-the-middle attacks or package tampering. The environment variable refers to the $releasever($releasever) variable temporarily written in the upgrade process, and its value is set to the system version number corresponding to the "target new version repository", which ensures that dnf references the correct version path when constructing the URL.

[0084] First, the upgrade migration system generates a temporary configuration file named target.repo in the / run / migrate / directory using printf, writes the content of the four lines [target], name=target, baseurl=<repository address>, enabled=1, gpgcheck=1, and gpgkey=file: / / <signature key path> in sequence, and then executes chmod 600 to limit permissions and prevent tampering by other processes; in this way, dnf will automatically read this file when it starts without modifying any files in / etc / yum.repos.d, achieving "zero residue". Second, the system calls dnf --setopt=reposdir= / run / migrate --disablerepo='*' --enablerepo=target makecache-y to force only the temporary repository just generated to be enabled and immediately build a metadata cache, while triggering GPG (GNU Privacy Guard) verification logic, which will immediately report an error and stop if the signature does not match, avoiding subsequent downloads of tampered packages. Finally, before executing any actual upgrade command, the system injects a variable into the current shell environment by exporting DNF_VARS_RELEASEVER=<target version number> (for example, 9), and then starts dnf --releasever=$DNF_VARS_RELEASEVER distro-sync, so that the $releasever variable in the repository URL is correctly replaced with the target version number, ensuring that the package path pulled is completely consistent with the target system.

[0085] In step S40, a plurality of rounds of dependency analysis and recursive repair operations are performed based on the configured package manager, and a software package upgrade operation is performed when the recursive repair operation is completed.

[0086] It should be noted that the dependency analysis and recursive repair operation refers to the upgrade migration system driving dnf to perform a closed loop of "simulated upgrade → capture conflicts → generate repair instructions → again simulate" round by round until all software package dependency conflicts and compatibility problems are automatically eliminated. The software package upgrade operation refers to the system calling dnf to actually perform the distro-sync transaction after confirming that there are no conflicts, downloading and installing all RPM software packages of the target new version, and completing the file-level upgrade of the operating system.

[0087] It can be understood that the upgrade migration system first performs a simulation of only parsing without installation, captures all conflicts and missing dependencies; then redirects the output to the log, extracts the package names that need to be unloaded, installed or ignored according to the predefined rules, generates the next round of `dnf shell` script, adds `remove package A` (unload package A), `install package B` (install package B) and other instructions and automatically rebuilds the rpm database; the above "simulation-parsing-script generation-re-simulation" process is repeated for a maximum of ten rounds until `dnf` no longer reports errors, which is considered to be completed. The recursive repair; immediately after confirming that there is no conflict, execute `dnf --assumeyes distro-sync --allowerasing`, download and replace all software packages at one time, complete the software package upgrade operation.

[0088] Step S50, in the case where the software package upgrade operation is completed, updating the system identification information, the bootloader configuration, the service state and the modular repository configuration to the target new version state according to the mapping relationship and the boot mode of the current operating system, completing the upgrade.

[0089] It should be noted that the system identification information refers to the distribution name, version number, ID, PRETTY_NAME and other fields recorded in the / etc / os-release, / etc / issue, / etc / redhat-release and other files, as well as possible logo packages, distribution icons and other content. The program configuration refers to all key configurations related to startup, including boot entry in EFI partition in UEFI mode, grub.cfg of GRUB2, kernel and initramfs path, startup parameter, default startup item serial number and the like. The service state refers to the specific list of units managed by systemd before upgrade, such as the start and stop settings and the boot self-start settings of services such as sshd, NetworkManager and firewalld. The modular repository configuration refers to the stream and profile information in the dnf module system that has been enabled, such as php:7.4 / common, container-tools:rhel8 / common and the like. The target new version state refers to the above system identification, boot configuration, service list and module configuration, which are all consistent with the newly installed target version system, ensuring that the identity, startup behavior, service running environment and module selection of the system presented to the outside after upgrade are consistent with the official specifications of the new version.

[0090] It can be understood that first, the upgrade migration system reads the mapping table, directly replaces the PRETTY_NAME, VERSION_ID and other fields in / etc / os-release, / etc / issue with sed-i"s / old string / new string / g", and installs the new *-release, *logos package specified in the mapping table with rpm-Uvh, to ensure that the version number displayed by the system is consistent with the target; at the same time, the old identification package is uninstalled with rpm-e to avoid residual. Second, the system detects whether / sys / firmware / efi exists: if it exists, it calls efibootmgr-c-d / dev / sda-p 1-l\\EFI\\<distribution>\\grubx64.efi-L"new distribution" to create Boot000X entry, and then grub2-mkconfig-o / boot / efi / EFI / <distribution> / grub.cfg to regenerate the UEFI boot menu; if it does not exist, grub2-mkconfig-o / boot / grub2 / grub.cfg updates the traditional BIOS menu, and writes the path of the new kernel and initramfs to the default=0 line to ensure that the new kernel is directly entered after reboot. Finally, the system reads the list saved by systemctl list-unit-files--state=enabled before upgrading, executes systemctlenable<service> or replaces it with systemctl enable<new service name> and systemctl start<new service name> for each service name according to the mapping table; then use dnf module reset<old flow>&&dnf module enable<new flow>:<new version> to switch the enabled module flow to the target version, at which point all identifications, boot, services, and modules are in the target new version state, and the upgrade is complete.

[0091] As an example, the method further comprises: creating a system rollback point before the upgrade starts, the rollback point being a file system snapshot or a software package state list; during the upgrade process, recording operation logs, configuration change records and error information of the software package manager to a log file; continuously monitoring the log file during the upgrade process, and when a preset error pattern is detected, re-downloading a damaged software package or repairing an incomplete installation; when an upgrade failure is detected, triggering a rollback operation according to the file system snapshot and the software package state list.

[0092] System rollback point refers to the restoration benchmark established by the upgrade migration system for the current operating system before the upgrade begins, which can be used to completely restore to the pre-upgrade state. File system snapshot refers to the read-only time point copy of the root partition or subvolume made using storage technologies such as LVM, Btrfs or ZFS, which can be completed in seconds and almost does not occupy additional space. Package state list refers to the list of current system installed package name-version-architecture triplets saved in JSON / YAML form, used to accurately roll back to the package set before the upgrade. Operation log refers to the actual command and output of each step executed by the package manager, configuration change record refers to the record of adding, deleting and modifying each configuration file under / etc, error information refers to the non-zero code and stderr text returned by dnf / rpm. Preset error mode refers to known failure scenarios in the log that match regular expressions such as "checksum mismatch", "GPG signature BAD", "package xyz not found", etc. Damaged package refers to an rpm file that has a checksum value that does not match the repository metadata after downloading, causing the installation to be interrupted. Incomplete installation refers to the state where the rpm database has recorded a certain package, but some files are missing or have incorrect permissions in the file system.

[0093] First, the system takes a 10GB snapshot of the root partition with lvcreate, and saves the rpm-qa result as pkg.list.gz, so that the disk and package list can be rolled back at any time. Second, tail the log in the background and use grep to find keywords, and once a bad package is matched, automatically reinstall it with dnf, and reinstall it again after finding the missing file with rpm-Va, ensuring that it can self-heal if a problem occurs during the process. Finally, if the error exceeds the limit, the system immediately writes the snapshot back to the root volume with lvconvert--merge, and after rebooting, reinstall all old version packages with the list and uninstall all redundant new packages, and return to the pre-upgrade state with one key.

[0094] The embodiment provides a Linux operating system in-place upgrade migration method, first, the upgrade migration system judges whether the upgrade condition is met according to the distribution identification, version information and system state information of the current operating system, obtains a judgment result, avoids upgrading in an incompatible or resource insufficient environment, and thus guarantees the reliability and safety of the upgrade process. When the judgment result is that the condition is met, the system loads the adaptive configuration data of the target new version operating system according to the distribution identification and version information, including the software package warehouse address, signature key and mapping relationship of new and old system identification packages, provides necessary configuration information for subsequent upgrade operation, and ensures that the upgrade process can proceed smoothly. Then, the system configures the software package manager to access the target new version warehouse according to the software package warehouse address and signature key, ensures that the software package manager can correctly access the target new version warehouse, obtains the required software package, and lays a foundation for subsequent software package upgrade operation. Then, the system executes multiple rounds of dependent analysis recursive repair operation based on the configured software package manager, and executes the software package upgrade operation when the recursive repair operation is completed. This step improves the upgrade success rate by automatically processing the dependency conflict and incompatibility problem, and ensures the smooth progress of the software package upgrade operation. Finally, when the software package upgrade operation is completed, the system updates the system identification information, boot loader configuration, service state and modular warehouse configuration to the target new version state according to the mapping relationship and the boot mode of the current operating system, and completes the upgrade. This step ensures that the upgraded system is consistent with the target new version in terms of identification, boot, service and module configuration, so that the Linux operating system can be upgraded to the new version in place.

[0095] Compared with the prior art, the beneficial effects and characteristics of the application mainly lie in the following aspects:

[0096] (1) No need to reinstall, save upgrade cost: the application realizes in-place upgrade of large version of operating system, and users no longer need to backup, reinstall and restore data as in the traditional method. Compared with the reinstallation, the new method automates the upgrade process, reduces manual participation and error opportunities, and significantly saves maintenance time and labor cost. For server cluster environment, in-place upgrade can be performed through batch script, so that long-time business interruption caused by shutdown and reinstallation is avoided.

[0097] (2) Universality and scalability: The universal adaptation layer and modular architecture proposed in this application enable the same set of core code to adapt to the upgrade needs of multiple different distributions. By adding or modifying adaptation plugins, new Linux distributions or new version upgrades can be supported. For example, by providing the new repository address and signature key parameters of the target distribution, the system can perform the upgrade. This universality is not possessed by existing special migration tools: traditionally, each manufacturer develops its own upgrade tool, while the system provides a unified platform with better scalability and maintainability.

[0098] (3) Automatic conflict resolution, high upgrade success rate: The unique "multi-round DNF analysis and recursive repair" strategy of this application enables the system to automatically solve dependency conflicts and software package incompatibility problems encountered during the upgrade process. In the prior art, conflicts during the upgrade process often result in the termination of the upgrade, which requires manual uninstallation or replacement of related software packages and then retries, which is time-consuming and prone to errors. In contrast, the system can intelligently analyze the error logs of DNF and automatically determine how to handle conflicts (uninstall old packages, install alternative packages, etc.), and cycle until the problem is solved, significantly improving the probability of one-time upgrade success. In actual testing, for complex scenarios with a large number of software package replacements, the method of this application can stably complete the upgrade without manual intervention.

[0099] (4) Complete system identification switching, ensuring consistency: After the upgrade is complete, this application automatically switches the new system identification and configuration (such as distribution name, version, boot configuration, etc.), making the upgraded system indistinguishable from a newly installed system in appearance and internal configuration. This point is often overlooked in some existing upgrade solutions, which may result in the system being upgraded but the identification file still containing old version information, or the boot configuration not being updated resulting in boot item confusion. The system, through the core configuration switching module, ensures that / etc / os-release, boot items, software source configuration, and key service status are all matched with the new version, improving the consistency and reliability of the upgraded system.

[0100] (5) Safety and reliability, providing rollback: This application focuses on the safety of the upgrade process. By using a new RPM GPG key adaptation, it ensures that all installed software packages are correctly signed and verified, avoiding security risks caused by skipping verification due to key mismatch. In addition, the system's detailed log recording and fault automatic detection mechanism can detect and handle problems in a timely manner when the upgrade process encounters exceptions. Most importantly, a rollback mechanism is provided as a safeguard - if the upgrade encounters a fault that cannot be automatically repaired, the user can choose to roll back to the pre-upgrade state, ensuring business continuity. This safety net design largely mitigates the risks that may be brought about by in-place upgrades, making the solution of this application more practical.

[0101] It should be noted that the present application focuses on solving the upgrade compatibility problem between different versions of the same manufacturer's distribution, and does not involve cross-manufacturer (completely different distribution) or cross-architecture upgrade migration. This makes the problem domain more focused and the solution more controllable. The distribution of the same manufacturer usually inherits similar system architecture, and the present application takes advantage of this to achieve highly automated upgrade; for cross-distribution migration, the difference is too large to be discussed in the present application. However, the system architecture still has reference significance for distributions with similar RPM architecture, and can support more scenarios through adaptation. In summary, the present application provides a solution with significant technical advantages in the field of domestic Linux operating system upgrade.

[0102] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as the above embodiment one can refer to the above introduction, and the following will not be repeated. On this basis, please refer to Figure 2 , Figure 2 is a flowchart of the second embodiment of the Linux operating system in-place upgrade migration method of the present application. The steps S40 of the Linux operating system in-place upgrade migration method include steps S41-S45:

[0103] Step S41, based on the configured software package manager, execute a simulated upgrade analysis command to obtain dependency conflict output information.

[0104] It should be noted that the simulated upgrade analysis command is `dnf--assumeno distro-sync`, that is, without actually installing any software package, let the software package manager complete a complete dependency resolution and output the operation list to be executed. The dependency conflict output information refers to the text content produced after the command execution, indicating that the software packages cannot be installed simultaneously, missing dependencies or file conflicts, etc.

[0105] It can be understood that the upgrade migration system first constructs a temporary repository parameter, injects the target new version repository address and signature key into dnf at one time, and then runs the simulated upgrade analysis command to let the package manager traverse all the software packages to be upgraded in the mode of only parsing without installation; the complete text output by the command is redirected to / tmp / dryrun.log, which contains a list of all potential problems such as packages that cannot be installed simultaneously, missing dependencies, file path conflicts, etc. The list is the original information relied on for subsequent loop repair.

[0106] Step S42, analyze the dependency conflict output information, identify the conflict type and generate a marked operation instruction.

[0107] It should be noted that the conflict type refers to specific categories such as the inability to install new and old packages with the same name, missing dependencies, package replacement, or file path conflicts. The marking operation instruction refers to the list of actions to be executed generated by the system according to the conflict type, including marking the old package as to be uninstalled, the new package as to be installed, the missing dependency package as to be removed, or ignoring.

[0108] As an example, the marking operation instruction includes to-be-uninstalled instructions, to-be-installed instructions, and to-be-ignored instructions; the step of analyzing the dependency conflict output information, identifying the conflict type, and generating the marking operation instruction includes: analyzing the dependency conflict output information to obtain a conflict type identifier; when the conflict type identifier is a software package coexistence conflict, generating a to-be-uninstalled instruction for the old version software package and a to-be-installed instruction for the new version software package; when the conflict type identifier is a dependency missing conflict, generating a to-be-uninstalled instruction for the local software package that causes the missing; and when the conflict type identifier is a software package replacement conflict, generating a to-be-ignored instruction for the old software package.

[0109] The conflict type identifier refers to a label obtained after analyzing the dependency conflict output information, used to distinguish the conflict category, such as coexist (coexistence), missing (missing), and obsoleted (replacement). The software package coexistence conflict refers to the inability to install the same name or same function software package of the old version and the new version in the same system. The to-be-uninstalled instruction refers to the instruction for marking the specified old version software package as to be removed in the next round of operation. The to-be-installed instruction refers to the instruction for marking the specified new version software package as to be installed in the next round of operation. The dependency missing conflict refers to the fact that the dependency required by a certain installed software package does not exist in the target repository, resulting in the inability to meet the dependency relationship. The local software package that causes the missing refers to the installed software package that causes the conflict due to its own dependency missing. The software package replacement conflict refers to the fact that a certain software package in the new version repository declares to replace the old software package, so that the old package is no longer needed. The to-be-ignored instruction for the old software package refers to letting the upgrade process skip the update or removal action for the old software package, maintaining its existing state.

[0110] First, the upgrade migration system filters the output of `dnf --assumeno` with `grep -E 'cannot install both|requires.*but none|obsoletes'`, and then uses `awk` to label each line as `coexist`, `missing`, or `obsoleted`. If the label is `coexist`, the old package name is appended to `remove.list` (a list of packages to be removed), and the new package name is appended to `install.list` (a list of packages to be installed). If the label is `missing`, the local package name that triggered the missing is extracted and written to `remove.list`. If the label is `obsoleted`, the old package name is written to `ignore.list` (a list of packages to be ignored).

[0111] Step S43, according to the marking operation instruction, constructing a software package manager execution script, and executing the software package manager execution script.

[0112] It should be noted that the software package manager execution script refers to a dnf shell command sequence file automatically generated by the upgrade migration system according to the to-be-removed instruction, the to-be-installed instruction, and the to-be-ignored instruction. The content includes remove old package, install new package, distro-sync, and the like, which are used to complete conflict resolution and software package replacement in one transaction.

[0113] It can be understood that the upgrade migration system writes the package names in remove.list into dnf remove package name line by line, writes the package names in install.list into dnf install package name, and writes the package names in ignore.list into dnf mark install package name. The three commands are written in order in / tmp / fix.script. Then, dnf shell --setopt=tsflags=noscripts / tmp / fix.script is called to execute once, and conflict resolution and package replacement are completed.

[0114] Step S44, in the case where the software package manager execution script is executed, returning the software package manager execution simulation upgrade analysis command based on the configuration to obtain the dependency conflict output information until no more dependency conflict output information is generated, and completing the recursive repair operation.

[0115] It can be understood that after the script is executed, the system immediately runs the simulated upgrade analysis command again, and the new output is compared with the last round of log diff; if there are still conflict lines, a new remove / install / ignore list is generated according to the same pipeline, and the script is executed again, and the cycle of detection-analysis-repair is repeated until the dnf echoes "Nothing todo" (no conflict output), and the recursive repair is completed.

[0116] Step S45, in the case where the recursive repair operation is completed, a software package upgrade operation is performed.

[0117] It can be understood that after the recursive repair is completed, the system immediately calls dnf distro-sync--assumeyes--allowerasing to pull and install all new version software packages with solved dependencies at one time, and the old packages are automatically uninstalled, the file system is synchronized to the target version, and the software package upgrade is completed.

[0118] The processing method example code of the upgrade process is as follows:

[0119]

[0120] The embodiment first executes a simulated upgrade analysis command based on the configured software package manager to obtain dependency conflict output information, which can discover dependency conflict problems that may occur in the upgrade process in advance and provide a basis for subsequent repair. Then, the dependency conflict output information is analyzed to identify conflict types and generate marked operation instructions, which can accurately identify conflict types and provide guidance for subsequent repair operations. Next, according to the marked operation instructions, a software package manager execution script is constructed and executed, which can generate corresponding operation instructions according to the identified conflict types to solve dependency conflict problems. After the software package manager execution script is executed, the step of executing the simulated upgrade analysis command is returned to obtain the dependency conflict output information until no dependency conflict output information is generated, and the recursive repair operation is completed, which can gradually solve all dependency conflict problems through recursive repair to ensure the smooth progress of the upgrade process. Finally, in the case where the recursive repair operation is completed, a software package upgrade operation is performed, which can upgrade the Linux operating system to a new version in place and complete the entire upgrade process.

[0121] By way of example, in order to facilitate understanding of the implementation process of the Linux operating system in-place upgrade migration method obtained after the above-mentioned embodiment one, please refer to Figure 3 , Figure 3 A brief flowchart of a Linux operating system in-place upgrade migration method is provided, specifically:

[0122] The flow starts with "Start checking current system environment", in which the system obtains key information such as distribution identification, system version, architecture, boot mode, and verifies whether the prerequisites for upgrading are met, such as administrator permission, system integrity, disk space, etc. Next is "Parameterized adaptation layer", in which the system loads the adaptation plug-in or configuration data of the corresponding distribution and target version according to the environment detection results. These configurations describe the repository structure of the target new version, software source address, RPM GPG signature public key, difference between new and old system identification package name, difference between key file paths, etc.

[0123] Then "DNF simulation upgrade analysis" is performed, in which the system adopts the "multi-round DNF analysis and recursive repair" strategy. First, according to the new version repository information provided by the adaptation layer, the system dynamically constructs the software source configuration of DNF, and then performs a simulation upgrade analysis to capture possible software package dependency conflicts or incompatibility. If the analysis result shows "conflict or incompatibility exists", it enters the "recursive dependency conflict resolution" step, in which the system analyzes the conflict information output by DNF one by one, generates the corresponding software package list to be uninstalled, installed or ignored, and performs DNF dependency analysis again. This cycle is repeated recursively until there is no new conflict.

[0124] Once the conflict is resolved, "no conflict", the "perform formal upgrade" is performed, which performs the actual software package upgrade operation. The system downloads and installs the new version of the software package, replacing the old version of the software package. After the upgrade is completed, the system "switches the new system core configuration", automatically adjusts the system configuration closely related to the new system version, including switching the system identification, updating the EFI boot configuration, and handling the difference in the RPM database path, etc., to ensure that the upgraded system environment is correct and accurate.

[0125] Finally, the flow ends with "Upgrade completed", indicating that the operating system has been successfully upgraded to the new version in place, and the system records detailed operation logs through the log and rollback module, providing automatic error repair and rollback mechanism to reduce the impact of upgrade failure.

[0126] It should be noted that the above example is only for understanding the present application and does not constitute a limitation on the Linux operating system in-place upgrade migration method of the present application. Further simple transformations based on this technical concept are within the scope of protection of the present application.

[0127] The present application also provides a Linux operating system in-place upgrade migration device, please refer to Figure 4 , the Linux operating system in-place upgrade migration device comprises:

[0128] The environment detection module 10 is configured to determine whether an upgrade condition is met according to a release identification, version information and system state information of a current operating system, and obtain a determination result.

[0129] The parameter adaptation module 20 is configured to load adaptation configuration data of a target new version operating system according to the release identification and the version information when the determination result is that the upgrade condition is met, the adaptation configuration data including a software package repository address, a signature key and a mapping relationship of new and old system identification packages of the target new version operating system.

[0130] The manager configuration module 30 is configured to configure a software package manager to access a target new version repository according to the software package repository address and the signature key.

[0131] The upgrade module 40 is configured to perform a multi-round dependent analysis recursive repair operation based on the configured software package manager, and perform a software package upgrade operation when the recursive repair operation is completed.

[0132] The state switching module 50 is configured to update system identification information, a bootloader configuration, a service state and a modular repository configuration to a target new version state according to the mapping relationship and a boot mode of the current operating system when the software package upgrade operation is completed, and complete the upgrade.

[0133] The Linux operating system in-place upgrade migration device provided by the application adopts the Linux operating system in-place upgrade migration method in the above embodiment, and can solve the technical problem of how to upgrade the Linux operating system to a new version in place. Compared with the prior art, the Linux operating system in-place upgrade migration device provided by the application has the same beneficial effects as the Linux operating system in-place upgrade migration method provided by the above embodiment, and other technical features in the Linux operating system in-place upgrade migration device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0134] The application provides a Linux operating system in-place upgrade migration device, which comprises at least one processor and a memory in communication connection with the at least one processor. The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the Linux operating system in-place upgrade migration method in the above embodiment one.

[0135] The following refers to Figure 5 This document illustrates a structural diagram of a Linux operating system in-situ upgrade and migration device suitable for implementing embodiments of this application. The Linux operating system in-situ upgrade and migration device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The Linux operating system upgrade and migration of the device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0136] like Figure 5 As shown, the Linux operating system in-situ upgrade and migration device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to programs stored in ROM (Read Only Memory) 1002 or programs loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the Linux operating system in-situ upgrade and migration device operation. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, LCDs (Liquid Crystal Displays), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the Linux operating system in-situ upgrade / migration device to exchange data with other devices wirelessly or via wired communication. Although the figure shows a Linux operating system in-situ upgrade / migration device with various systems, it should be understood that implementing or having all the systems shown is not required. More or fewer systems can be implemented alternatively.

[0137] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the method shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network through a communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiments disclosed in the present application are executed.

[0138] The Linux operating system in-place upgrade migration device provided by the present application adopts the Linux operating system in-place upgrade migration method in the above-mentioned embodiments, and can solve the technical problem of how to upgrade the Linux operating system to a new version in place. Compared with the prior art, the Linux operating system in-place upgrade migration device provided by the present application has the same beneficial effects as the Linux operating system in-place upgrade migration method provided by the above-mentioned embodiments, and other technical features in the Linux operating system in-place upgrade migration device are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0139] It should be understood that parts of the present application can be realized by hardware, software, firmware or a combination thereof. In the description of the above-mentioned embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0140] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0141] The present application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e. computer program) for executing the Linux operating system in-place upgrade migration method in the above-mentioned embodiments.

[0142] The computer readable storage medium provided in the application may be, for example, a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination of the above. More specific examples of the computer readable storage medium may include, but are not limited to, an electrical connection with one or more conductive wires, a portable computer disk, a hard disk, a RAM (Random Access Memory), a ROM (Read Only Memory), an EPROM (Erasable Programmable Read Only Memory or flash memory), an optical fiber, a CD-ROM (CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiment, the computer readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electrical wire, an optical cable, an RF (Radio Frequency), and the like, or any suitable combination of the above.

[0143] The computer readable storage medium described above may be contained in a Linux operating system live migration device or may exist separately without being assembled into the Linux operating system live migration device.

[0144] The computer readable storage medium described above carries one or more programs, which, when executed by the Linux operating system live migration device, cause the Linux operating system live migration device to: determine whether an upgrade condition is met according to a distribution identification, version information, and system state information of a current operating system, and obtain a determination result; when the determination result is that the condition is met, load adaptation configuration data of a target new version operating system according to the distribution identification and the version information, the adaptation configuration data including a software package repository address, a signature key, and a mapping relationship of new and old system identification packages of the target new version operating system; configure a software package manager to access a target new version repository according to the software package repository address and the signature key; perform a multi-round dependent analysis recursive repair operation based on the configured software package manager, and perform a software package upgrade operation when the recursive repair operation is completed; and update system identification information, a bootloader configuration, a service state, and a modular repository configuration to a target new version state according to the mapping relationship and the boot mode of the current operating system when the software package upgrade operation is completed, and complete the upgrade.

[0145] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0146] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0147] The modules involved in the embodiments of the present application can be implemented in software or hardware. In some cases, the names of the modules do not constitute a limitation on the modules themselves.

[0148] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e., computer programs) for executing the Linux operating system in-place upgrade migration method described above, and can solve the technical problem of how to upgrade the Linux operating system to a new version in place. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the Linux operating system in-place upgrade migration method provided by the above-mentioned embodiments, and will not be described here.

[0149] The application also provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the Linux operating system in-place upgrade migration method as described above.

[0150] The computer program product provided by the application can solve the technical problem of how to upgrade the Linux operating system to a new version in place. Compared with the prior art, the beneficial effects of the computer program product provided by the application are the same as those of the Linux operating system in-place upgrade migration method provided by the above-mentioned embodiments, and are not described here.

[0151] The above only describes some embodiments of the application, and does not limit the patent scope of the application. Any equivalent structural transformation made by using the content of the application specification and drawings, or direct / indirect application in other related technical fields is included in the patent protection scope of the application.< / url>

Claims

1. A Linux operating system live migration upgrade method, characterized in that, The method comprises: According to the release version identification, version information and system state information of the current operating system, it is judged whether the upgrade condition is met, and a judgment result is obtained; When the judgment result is met, the adaptation configuration data of the target new version operating system is loaded according to the release version identification and the version information, and the adaptation configuration data comprises the software package warehouse address, signature key and mapping relationship of new and old system identification package of the target new version operating system; According to the software package warehouse address and the signature key, the software package manager accesses the target new version warehouse; Based on the configured software package manager, a multi-round dependent analysis recursive repair operation is performed, and when the recursive repair operation is completed, a software package upgrade operation is performed; When the software package upgrade operation is completed, the system identification information, bootloader configuration, service state and modular warehouse configuration are updated to the target new version state according to the mapping relationship and the boot mode of the current operating system, and the upgrade is completed.

2. The method of claim 1, wherein, When the judgment result is met, the adaptation configuration data of the target new version operating system is loaded according to the release version identification and the version information, and the adaptation configuration data comprises the software package warehouse address, signature key and mapping relationship of new and old system identification package of the target new version operating system; When the judgment result is met, the adaptation configuration data of the target new version operating system is loaded according to the release version identification and the version information, and the adaptation configuration data comprises the software package warehouse address, signature key and mapping relationship of new and old system identification package of the target new version operating system; The step of performing a multi-round dependent analysis recursive repair operation based on the configured software package manager, and performing a software package upgrade operation when the recursive repair operation is completed, comprises: Based on the configured software package manager, a simulation upgrade analysis command is executed, and dependent conflict output information is obtained; 3. The method of claim 1, wherein, The dependent conflict output information is parsed, the conflict type is identified, and a marking operation instruction is generated; According to the marking operation instruction, a software package manager execution script is constructed, and the software package manager execution script is executed; When the software package manager execution script is executed, the step of executing a simulation upgrade analysis command based on the configured software package manager to obtain dependent conflict output information is returned until no dependent conflict output information is generated, and the recursive repair operation is completed; When the recursive repair operation is completed, a software package upgrade operation is performed. The marking operation instruction comprises a to-be-uninstalled instruction, a to-be-installed instruction and a to-be-ignored instruction; The step of parsing the dependent conflict output information, identifying the conflict type and generating the marking operation instruction comprises:

4. The method of claim 3, wherein, The conflict type identification is obtained by parsing the dependent conflict output information; When the conflict type identification is a software package coexistence conflict, a to-be-uninstalled instruction of an old version software package and a to-be-installed instruction of a new version software package are generated; When the conflict type identification is a dependent missing conflict, a to-be-uninstalled instruction of a local software package causing the missing is generated; When the conflict type identification is a software package replacement conflict, a to-be-ignored instruction of an old software package is generated. ​ ​ 5. The method of claim 1, wherein, The step of configuring a package manager to access a target new version repository according to the package repository address and the signature key comprises: adding the package repository address to a temporary repository configuration of the package manager; adding a local file path of the signature key to a verification parameter of the temporary repository configuration; enabling a signature verification function of the package manager; adding a system version identification corresponding to the target new version repository to an environment variable of the package manager.

6. The method of claim 1, wherein, The step of determining whether an upgrade condition is met according to a distribution identification, version information and system state information of a current operating system to obtain a determination result comprises: performing an adaptation rule verification according to the distribution identification and the version information of the current operating system to obtain an adaptation rule verification result; analyzing the system state information of the current operating system to obtain a user permission state, a package database state and a disk remaining space value; verifying the user permission state to obtain an administrator permission confirmation result; performing an integrity check on the package database state to obtain a database integrity state result; comparing the disk remaining space value with a preset space threshold to obtain a space sufficiency state result; obtaining the determination result according to the adaptation rule verification result, the administrator permission confirmation result, the database integrity state result and the space sufficiency state result.

7. The method of any one of claims 1 to 6, wherein, The method further comprises: creating a system rollback point before the upgrade starts, the rollback point being a file system snapshot or a package state list; during the upgrade, recording operation logs, configuration change records and error information of the package manager to a log file; continuously monitoring the log file during the upgrade, and when a preset error mode is detected, re-downloading a damaged package or repairing an incomplete installation; when an upgrade failure is detected, triggering a rollback operation according to the file system snapshot and the package state list.

8. A Linux operating system in-place upgrade migration apparatus, characterized by, The device comprises: an environment detection module configured to determine whether an upgrade condition is met according to a distribution identification, version information and system state information of a current operating system to obtain a determination result; a parameter adaptation module configured to, when the determination result is that the upgrade condition is met, load adaptation configuration data of a target new version operating system according to the distribution identification and the version information, the adaptation configuration data comprising a package repository address, a signature key and a mapping relationship of new and old system identification packages of the target new version operating system; a manager configuration module configured to configure a package manager to access a target new version repository according to the package repository address and the signature key; an upgrade module configured to perform a multi-round dependent analysis recursive repair operation based on the configured package manager, and perform a package upgrade operation when the recursive repair operation is completed; a state switching module configured to, when the package upgrade operation is completed, update system identification information, a bootloader configuration, a service state and a modular repository configuration to a target new version state according to the mapping relationship and a boot mode of the current operating system, and complete the upgrade.

9. A Linux operating system in-place upgrade migration device, comprising: The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the Linux operating system in-place upgrade migration method according to any one of claims 1 to 7.

10. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the Linux operating system in-place upgrade migration method according to any one of claims 1 to 7.

Images