Method and device for detecting and repairing glibc corruption in a linux system

Abstract

This invention discloses a method and device for detecting and repairing corrupted glibc in a Linux system, belonging to the field of computer data processing technology. The method includes: loading a specified Initramfs, identifying and mounting the corrupted root file system of the target operating system, establishing and switching to a minimal chroot environment, scanning the specified glibc components of the target operating system, and constructing a dependency graph; performing preset tests and capturing error information for matching and identifying fault types; extracting the distribution and version identifier from the target operating system, determining the correct glibc version number and file integrity check value, and obtaining corresponding repair resources; replacing the corrupted glibc file with the correct version using atomic operations within the chroot environment; and finally verifying the execution status of core commands and the loading status of library files. This invention can significantly improve the accuracy and efficiency of system library fault handling.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, specifically to a method and device for automatically detecting and repairing glibc corruption in the Linux operating system. Background Technology

[0002] With the widespread application of the Linux operating system in critical areas such as servers, cloud computing, and embedded devices, the stability of the system's core shared libraries has become an important foundation for ensuring business continuity.

[0003] The GNU C Library (glibc) serves as the core interface between the operating system kernel and applications. If it is corrupted, has a version mismatch (e.g., due to interruption during system upgrades or accidental operation), or has incorrect file permissions, the system will be unable to load any user-mode programs, leading to system startup failure, or even kernel crashes or continuous reboots during the boot phase.

[0004] Currently, mainstream repair methods rely on external media such as Rescue Mode and Live CD / USB, and involve manual operation to mount the system, switch environments, and diagnose and replace library files.

[0005] However, the above methods are inefficient and have a high risk of errors because the repair process requires the manual execution of complex commands and relies on the operator's in-depth understanding of the system's underlying structure. For example, manually replacing core library files (especially glibc) is extremely risky, and any intermediate operation error may lead to secondary damage, making the system completely unrecoverable. At the same time, existing technologies lack a diagnostic system that can automatically analyze the dependencies of the damaged system, match fault types, and automatically determine the correct version information. Therefore, existing technologies are difficult to meet the needs of high-availability production environments for rapid automatic recovery.

[0006] Therefore, this application proposes a method for detecting and repairing glibc corruption in a Linux system to solve the above-mentioned technical problems. Summary of the Invention

[0007] The main objective of this invention is to provide a method for detecting and repairing glibc corruption in a Linux system, so as to solve the technical problems mentioned in the background art.

[0008] The present invention solves the above-mentioned technical problems by adopting the following technical solutions:

[0009] A method for detecting and repairing glibc corruption in a Linux system, performed via a computer device, includes the following steps:

[0010] After loading the specified Initramfs, it automatically identifies and mounts the damaged target operating system root file system, establishes and switches to a minimal chroot environment, and scans the target operating system for critical executable files and their dependent glibc components to build a critical dependency graph in order to assess the scope of the failure.

[0011] Automatically execute preset test commands (such as attempting to execute / rootmnt / bin / ls and capturing segment faults or link errors), capture the generated runtime error information, and match the error information with a predefined fault mode database to accurately identify the fault type, including but not limited to missing library files, version mismatches, or file permission errors;

[0012] Extract the distribution and version identifier from the target operating system, automatically query and determine the correct glibc version number and file integrity check value from the preset source as the repair benchmark, and automatically select and obtain the corresponding repair resources from the preset software image or the Initramfs built-in cache according to the identified fault type.

[0013] Within the chroot environment, atomic operations are used to replace the damaged system's glibc file with the correct version of the repaired resource, ensuring the atomicity and safety of the replacement process.

[0014] The script automatically runs a health check to verify the execution status of core commands and the loading status of library files, ensuring that glibc functionality has been restored.

[0015] Preferably, the process for obtaining and updating the specified Initramfs includes:

[0016] During system installation, the dracut command is used to obtain the corresponding glibc library file during the execution of the glibc corruption diagnosis process, and a set of specified initramfs files are constructed to load the hash value of the glibc library file.

[0017] During the installation of a new version of glibc, the glibc version number is compared. If the installation of the new version of glibc is a major version update, the initramfs file is not updated; if the installation of the new version of glibc is a minor version update, the initramfs file is updated.

[0018] Preferably, the key dependency graph is constructed by scanning key system services and binary files (systemd, bash, etc.), based on the dependency relationships of the binary files and the recursive dependencies of the dependencies (dependencies of dependencies), and the dependency graph is simplified to obtain all glibc-related .so files that are ultimately dependent.

[0019] Preferably, during the matching process between the error message and the predefined fault mode database based on the .so file, the matching scenarios include missing libc.so.6, version number mismatch, and file permission error. The fault mode database performs corresponding recovery operations based on the internally stored error messages and corresponding processing methods.

[0020] Preferably, the fault type identification process also determines the correct glibc version number and hash value based on the system release information. At this time, the version number and hash value are the glibc version when the system was installed. The results are queried and compared through file records. If the results are the same, the correction is successful; if they are different, the correction fails, and the results are printed to the root file system.

[0021] Preferably, a device for automatically detecting and repairing glibc corruption in a Linux operating system, used to execute any of the above-described methods for detecting and repairing glibc corruption in an initramfs environment, includes:

[0022] (1) The startup and isolation module is used to load the specified Initramfs, identify and mount the damaged target operating system root file system, and finally establish and switch to a minimal chroot environment;

[0023] (2) Intelligent diagnostic module, used to perform fault matching query operation on glibc version number and hash value based on chroot environment to confirm whether glibc has a fault. The following process operation is performed:

[0024] (a) Dependency graph analysis: Mount the real root file system, scan the glibc files of the target system and its main dependent programs (such as ld.so). At this stage, the system's key services and binaries (systemd, bash, etc.) are mainly scanned. After obtaining the dependencies of the binary files and the dependencies of the dependencies, a set of key dependency graphs are constructed. By using this dependency graph for simplification, all the glibc-related so files that are ultimately dependent are obtained.

[0025] (b) Fault mode matching: Perform error detection tests (such as trying to execute / rootmnt / bin / ls and capturing segment faults or link errors), and match the test results with a predefined glibc fault mode database (such as: missing libc.so.6, version number mismatch, file permission errors, etc.). The database mainly stores glibc errors and handling methods. After matching the corresponding error, the corresponding repair operation is performed in the automatic recovery module.

[0026] (c) Obtain the desired state: Automatically determine the correct glibc version number and hash value based on the system release information. At this time, the version number and hash value are the glibc version when the system was installed. Query through file records, compare the results. If the results are the same, the correction is successful. If they are different, the correction fails. Finally, print the correction judgment result to the root file system for easy querying of the correction result.

[0027] (3) An automated recovery module is used to automatically execute the optimal corresponding replacement and correction strategy after glibc confirms a fault, and to automatically run a preset health check script after the replacement and correction are completed to verify whether glibc has been repaired. The replacement and correction operations include:

[0028] (a) Strategy selection: If the versions do not match, the correct package will be automatically downloaded from the preset mirror source or the cache built into initramfs;

[0029] (b) Atomic replacement: In the chroot environment, atomic operations (rsync and mv together) are used to safely replace the corrupted glibc file to ensure that no secondary damage is caused during the replacement process.

[0030] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0031] As can be seen from the above technical solution, the present invention provides a method for detecting and repairing glibc corruption in a Linux system. Compared with the prior art, the present invention has the following advantages:

[0032] 1. This invention, through the fusion dependency analysis and fault mode matching capabilities of the intelligent diagnostic module, combined with a pre-built fault mode database, can significantly improve the accuracy and efficiency of system library fault handling. At this time, by accurately locating the root cause of the fault through automated scanning and testing, it can effectively avoid the excessive reliance on human experience in traditional repair methods, thus ensuring the reliability of repair operations.

[0033] 2. This invention addresses complex library corruption scenarios by employing atomic replacement and system verification schemes to achieve secure repair of critical files and integrity checks of system status. It also supports adaptive recovery across multiple distribution environments, significantly reducing operational risks and system downtime, and improving the automation level of operating system recovery.

[0034] It should be understood that the descriptions in this section are not intended to identify key or essential features of embodiments of the invention, nor are they intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Of course, implementing any product of the invention does not necessarily require achieving all of the advantages described above simultaneously. Attached Figure Description

[0035] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0036] Figure 1 This is a schematic diagram of the method flow of the present invention;

[0037] Figure 2 This is a schematic diagram of the overall data processing flow of the device according to the present invention;

[0038] Figure 3 This is a schematic diagram of the system modules of the present invention. Detailed Implementation

[0039] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0040] For details in the embodiments, please refer to Figures 1 to 3 .

[0041] like Figure 1 As shown in the embodiments of the present invention, the method for detecting and repairing glibc corruption in a Linux system mainly runs in an initramfs environment and includes the following steps:

[0042] S1. Environment Preprocessing Settings: After loading the specified Initramfs, the system automatically identifies and mounts the damaged target operating system root file system, establishes and switches to a minimal chroot environment, and scans the target operating system for critical executable files and their dependent glibc components. It constructs a critical dependency graph to assess the scope of the failure. The critical dependency graph is constructed by recursively parsing the direct dependencies and dependencies of dependencies of critical system services and core binaries (such as systemd, bash, etc.) to build a complete system dependency graph. After simplification, it is used to obtain all glibc-related .so files that are ultimately dependent on.

[0043] For example, in one set of embodiments, the critical binary bash of the system directly depends on library files such as libreadline, which in turn depends on libncurses, which in turn depends on basic libraries such as libc. By recursively resolving this dependency and the dependency of the dependency, a complete dependency chain can be constructed, ultimately forming a system dependency graph.

[0044] In a further example, the process for obtaining and updating Initramfs is specified here, including:

[0045] During system installation, the dracut command is used to obtain the corresponding glibc library file during the execution of the glibc corruption diagnosis process, and a set of specified initramfs files are constructed to load the hash value of the glibc library file.

[0046] During the installation of a new version of glibc, the glibc version number is compared. If the installation of the new version of glibc is a major version update, the initramfs file is not updated. If the installation of the new version of glibc is a minor version update, the initramfs file is updated. For example, the glibc version division standard follows the semantic versioning specification: a major version number change is considered a major version update (e.g., 2.x→3.x), a minor version number change is considered a minor version update (e.g., 2.28→2.29), and a revision number change does not affect the initramfs update (e.g., 2.28-225→2.28-226).

[0047] S2. Automatically execute preset test commands (such as attempting to execute / rootmnt / bin / ls and capturing segment faults or link errors), capture the generated runtime error information, and match the error information with a predefined fault mode database to accurately identify the fault type, including but not limited to missing library files, version mismatches, or file permission errors.

[0048] At this point, the error message is matched with the predefined fault mode database based on the .so file. The matching scenarios include missing libc.so.6, version number mismatch, file permission error, etc. The fault mode database performs the corresponding recovery operation based on the error message and corresponding processing method stored internally.

[0049] In summary, this method, through the fusion dependency analysis and fault mode matching capabilities of the intelligent diagnostic module and the pre-built fault mode database, can significantly improve the accuracy and efficiency of fault handling in the system library. In particular, the diagnostic module accurately locates the root cause of the fault through automated scanning and testing, effectively avoiding the excessive reliance on human experience in traditional repair methods and ensuring the reliability of the repair operation.

[0050] S3. Extract the distribution and version identifier from the target operating system, automatically query and determine the correct glibc version number and file integrity check value from the preset source as the repair benchmark, and automatically select and obtain the corresponding repair resources from the preset software image or the Initramfs built-in cache according to the identified fault type.

[0051] It should also be emphasized that the correct glibc version number and hash value are determined based on the system distribution information. At this time, the version number and hash value are the glibc version at the time of system installation. The results are queried and compared through file records. If the results are the same, the correction is successful; if they are different, the correction fails, and the results are printed to the root file system.

[0052] S4. Within the chroot environment, use atomic operations to replace the corrupted system's glibc file with the correct version of the repaired resource to ensure the atomicity and safety of the replacement process.

[0053] S5. Automatically run a health check script to verify the execution status of core commands and the loading status of library files to ensure that glibc functionality has been restored to normal.

[0054] For complex library corruption scenarios, an atomic replacement and system verification scheme was adopted to achieve secure repair of critical files and integrity checks of system status. It also supports adaptive recovery in multi-distribution environments, which greatly reduces operational risks and system downtime, and improves the automation level of operating system recovery.

[0055] On the other hand, this invention also discloses a device for automatically detecting and repairing glibc corruption in a Linux operating system, used to execute the method for detecting and repairing glibc corruption in the Linux system described in the above embodiments within an initramfs environment, such as... Figure 3 As shown, its interior includes:

[0056] (1) The startup and isolation module is used to load the specified Initramfs, identify and mount the damaged target operating system root file system, and finally establish and switch to a minimal chroot environment;

[0057] (2) The intelligent diagnostic module is used to perform fault matching query operations based on the glibc version number and hash value in the chroot environment to confirm whether there is a fault in glibc. At this time, the database being matched mainly stores glibc errors and handling methods. After matching the corresponding error, the method is passed to the automated recovery module. The intelligent diagnostic module performs the following process operations:

[0058] (a) Dependency graph analysis: Mount the real root file system and scan the core library glibc file of the target system and its main dependent programs (such as ld.so). At this stage, the main focus is on scanning the critical system services and binaries (systemd, bash, etc.) to obtain their actual status parameters (dependencies of binary files and dependencies of dependencies), such as version number, file hash, loading error code, etc., and construct a set of key dependency graphs. By using this dependency graph for simplification, all the glibc-related so files that are ultimately dependent are obtained.

[0059] (b) Fault mode matching: Perform error detection tests (such as attempting to execute / rootmnt / bin / ls and capturing segment faults or link errors), and match the test results (actual status parameters) with the pre-stored glibc fault mode database (such as: missing libc.so.6, version number mismatch, file permission error, etc.) to determine the fault type. The database mainly stores glibc errors and handling methods, which are used to compare and determine whether there are known and repairable faults. After matching the corresponding error, the corresponding repair operation is performed in the automatic recovery module.

[0060] In a specific embodiment of a set of examples, the predefined fault mode database is stored in the ` / etc / glibc_fault_db.json` file in initramfs, containing three core fault modes and matching rules: <1> Missing library file: The error message contains "libc.so.6: cannot open shared object file", and the matching rule is to match the first 30 characters of the error string exactly. <2> Version mismatch: The error message contains "version 'GLIBC_2.32' not found", and the matching rule is a regular expression matching "GLIBC_[0-9]" and "not found"; <3> File permission error: The error message contains "Permission denied" and involves the path / lib64 / libc.so.6. The matching rule is to match the path with the error string. The database also stores the repair priority and operation instructions for each type of fault. For example, the repair instruction for missing library files is "cp / initramfs / glibc / libc.so.6 / rootmnt / lib64".

[0061] (c) Obtain the expected state: The correct glibc expected state parameters are automatically determined based on the system release information. These are generally the version number and hash value. The version number and hash value are the glibc version when the system was installed. The results are queried through file records and compared. If the results are the same, the correction is successful; otherwise, the correction fails. Finally, the correction judgment result is printed to the root file system for easy querying of the correction result.

[0062] (3) An automated recovery module is used to automatically execute the best corresponding replacement and correction strategy after glibc confirms a fault, and automatically run a preset health check script to retest the program after the replacement and correction are completed, in order to verify whether glibc has been repaired. The replacement and correction operations include:

[0063] (a) Strategy selection: If the versions do not match, the correct package will be automatically downloaded from the preset mirror source or the cache built into initramfs;

[0064] (b) Atomic replacement: In the chroot environment, atomic operations (rsync and mv together) are used to safely replace the corrupted glibc file to ensure that no secondary damage is caused during the replacement process;

[0065] In a specific embodiment of a set of examples, the atomic operation is implemented using a combination of the rsync tool (version 3.1.3) and the mv tool (version 8.30). The specific steps are as follows: (b1) Execute rsync -a --delete / initramfs / glibc / / rootmnt / tmp / glibc_temp / to synchronize the correct glibc file to the target system's temporary directory; (b2) Execute mv -f / rootmnt / tmp / glibc_temp / * / rootmnt / lib64 / to overwrite the corrupted glibc file; (b3) Execute rm -rf / rootmnt / tmp / glibc_temp / to clean up the temporary directory. The entire process is locked by flock / rootmnt / lib64 / to prevent concurrent operations from causing file corruption.

[0066] At this point, the health check script is / initramfs / check_glibc.sh, and the execution steps are as follows:

[0067] Step 1: Execute the three core commands: / rootmnt / bin / ls, / rootmnt / bin / bash, and / rootmnt / bin / systemctl. If there are no segment faults or link errors, the commands are considered to have executed normally.

[0068] Step 2: Execute ldd / rootmnt / bin / ls to check that the loading path of libs.so.6 is / rootmnt / lib64 / libc.so.6, and that the version number is known as expected;

[0069] Step 3: Calculate the MD5 value of / rootmnt / lib64 / libs.so.6 and compare it with the checksum stored in initramfs. If all three conditions are met, the repair is considered successful; otherwise, the repair is considered unsuccessful.

[0070] In addition, during actual use, the device automatically downloads the glibc core library installation package or library file that matches the expected version number to ensure the completion of the overall diagnostic comparison and recovery operation.

[0071] In addition, in one specific example, the device also includes a repair verification module, in which the system module of the device can also be applied to the CUOS system to create an automatically correcting initramfs option for automatic system correction after the system glibc encounters an error.

[0072] At this time, the device is executing as follows: Figure 2 The following operations are shown:

[0073] (a) If the system fails to start or the bootloader detects a fault, it first boots a specially made INITRAMFS (isolation environment), then automatically mounts the target file system ( / rootmnt) and sets up the chroot isolation environment, and then enters the intelligent diagnostic module;

[0074] (b) After entering the intelligent diagnostic module, perform the following operations:

[0075] First, scan the target system's GLIBC files and critical dependencies (.so) and obtain the actual GLIBC status parameters, including version number, file hash, and linker error code. At the same time, automatically identify the system distribution information to obtain the expected GLIBC status parameters. The comparison results between the above actual status parameters and expected status parameters are matched against the GLIBC failure mode database. The matched failure scenarios include version mismatch, file loss, and permission errors.

[0076] After the matching is completed, the diagnostic results are obtained, and it is determined whether there are any known and repairable faults: if there are no known and repairable faults (unknown or cannot be automatically repaired), detailed logs are recorded and manual shell is entered; if there are known and repairable faults (repairable), the automatic recovery module is entered.

[0077] (c) After entering the automated recovery module, perform the following operations:

[0078] First, select the contingency plan to determine the best repair strategy (e.g., automatic download or built-in cache replacement), then perform the atomic file replacement operation (replace the corrupted GLIBC file), and then enter the automatic repair verification module;

[0079] (d) After entering the automatic repair verification module, perform the following operations:

[0080] Run the health check script to verify GLIBC functionality and determine if the verification was successful. If the verification fails (repair fails), record detailed logs and enter manual shell.

[0081] If the verification is successful, all mount points will be unloaded and INITRAMFS will be exited. The system will then be rebooted to complete the repair and start normally.

[0082] In summary, this device system, during system installation, obtains the glibc library files required for glibc corruption diagnosis using the dracut command and writes their hash values ​​to a specified initramfs file. Combined with a differentiated initramfs update strategy that distinguishes between major and minor version updates during new glibc installations, and a diagnostic system that automatically analyzes corrupted system dependencies, matches fault types, and determines the correct version information, this approach effectively avoids compatibility conflicts between the initramfs file and the new glibc environment during major version updates, providing a reliable basis for glibc corruption diagnosis. It also overcomes the shortcomings of existing technologies in lacking automatic diagnostic capabilities, achieving accurate fault type identification and rapid determination of the correct system version information. This solves the core technical problem of existing technologies failing to meet the rapid automatic recovery requirements of high-availability production environments, significantly shortening fault diagnosis and system recovery time, reducing manual intervention costs, significantly improving system fault tolerance and operational efficiency, and ensuring the continuous and stable operation of high-availability production environments.

[0083] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0084] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0085] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the method for detecting and repairing glibc corruption in any of the Linux systems described above.

[0086] It is understood that the system provided in the embodiments of the present invention corresponds to the method provided in the embodiments of the present invention, and the explanation, examples and beneficial effects of the relevant content can be referred to the corresponding parts of the above methods.

[0087] This application also provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0088] Memory, used to store computer programs;

[0089] The processor, when executing programs stored in memory, implements the aforementioned method for detecting and repairing glibc corruption in Linux systems.

[0090] The communication bus mentioned in the above-mentioned electronic devices can be a standard bus for interconnecting peripheral components or an extended industrial standard structure bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc.

[0091] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0092] The memory may include random access memory or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0093] The processors mentioned above can be general-purpose processors, including central processing units, network processors, etc.; they can also be digital signal processors, application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0094] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, an optical medium, or a semiconductor medium, etc.

[0095] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0096] Furthermore, it should be noted that the technical solutions proposed in the above embodiments are implemented based on a Linux distribution (CentOS 8.5), the initramfs tool (dracut-049-191.el8.x86_64), and the glibc library (version 2.28-225.el8). All tools, commands, and configurations involved are standard components of the open-source system, without relying on third-party proprietary software or undisclosed technologies. Key steps in the technical solution, such as "initramfs build," "chroot environment switching," and "atomic file replacement," are all implemented through standardized commands, specifically including dracut build commands, chroot switching commands, and rsync and mv combined replacement commands, etc., ensuring strong reproducibility of the operation process. The predefined glibc fault mode database ( / etc / glibc_fault_db.json) explicitly includes matching rules (exact matching / regular expression matching) and repair instructions for three core fault types: missing library files, version mismatch, and permission errors. The verification logic of the health check script (check_glibc.sh) (core command execution, library file loading, and MD5 verification) is clear and unambiguous. The repair tests for different fault scenarios in the embodiments were all completed in a real damaged Linux system environment. The repair success rate and system recovery effect can be confirmed by conventional methods such as virsh console login verification and ldd command verification. For details not specified in this invention (such as the configuration of the initramfs cache size), they can be determined by conventional technical means in the field (dynamic allocation based on system disk space) and will not affect the overall implementation of the technical solution. This invention ensures that those skilled in the art can accurately understand and successfully implement this solution by clearly defining the entire process logic of fault diagnosis, repair execution, and result verification.

[0097] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the meaning of "and / or" throughout the text includes three parallel solutions; for example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, in the embodiments of this invention, "multiple" refers to two or more. Moreover, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

Claims

1. A method for detecting and repairing corrupted glibc in a Linux system, characterized in that, include: After loading the specified Initramfs, the system identifies and mounts the corrupted target operating system root file system, establishes and switches to a minimal chroot environment, and scans the executable files and their dependent glibc components in the target operating system to build a dependency graph. Execute preset test commands, capture the generated runtime error information, and match the error information with a predefined fault mode database to identify the fault type; Extract the distribution and version identifier from the target operating system, query and determine the correct glibc version number and file integrity check value from the preset source, and select and obtain the corresponding repair resources from the preset software image or the Initramfs built-in cache based on the identified fault type. Within the chroot environment, atomic operations are used to replace the corrupted glibc file with the correct version that repairs the resource. Run the health check script to verify the execution status of core commands and the loading status of library files.

2. The method for detecting and repairing glibc corruption in a Linux system as described in claim 1, characterized in that, The process for obtaining and updating the specified Initramfs includes: During system installation, the dracut command is used to obtain the corresponding glibc library file during the execution of the glibc corruption diagnosis process, and a set of specified initramfs files are constructed to load the hash value of the glibc library file. During the installation of a new version of glibc, the glibc version number is compared. If the installation of the new version of glibc is a major version update, the initramfs file is not updated; if the installation of the new version of glibc is a minor version update, the initramfs file is updated.

3. The method for detecting and repairing glibc corruption in a Linux system as described in claim 2, characterized in that, The dependency graph is constructed by scanning key system services and binary files, based on the dependency relationships of the binary files and the recursive dependencies of those dependencies, and the dependency graph is simplified to obtain all relevant .so files that ultimately depend on glibc.

4. The method for detecting and repairing glibc corruption in a Linux system as described in claim 1, characterized in that, During the matching process of the fault mode database based on .so files, the matching scenarios include missing libc.so.6, version number mismatch, and file permission error. The fault mode database performs corresponding recovery operations based on the error information and corresponding processing methods stored internally.

5. The method for detecting and repairing glibc corruption in a Linux system as described in claim 4, characterized in that, In the fault type identification process, the correct glibc version number and hash value are determined based on the system release information. At this time, the version number and hash value are the glibc version when the system was installed. The results are queried and compared through file records. If the results are the same, the correction is successful; if they are different, the correction fails, and the results are printed to the root file system.

6. A device for automatically detecting and repairing glibc corruption in a Linux operating system, used to execute the method for detecting and repairing glibc corruption in a Linux system as described in any one of claims 1-5 under an initramfs environment, characterized in that... include: The boot and isolation module is used to load the specified Initramfs, identify and mount the damaged target operating system root file system, and finally establish and switch to a minimal chroot environment. The intelligent diagnostic module is used to perform fault matching queries based on the glibc version number and hash value in the chroot environment to confirm whether there is a fault in glibc. The automated recovery module is used to automatically execute the best repair strategy after glibc confirms the existence of a fault.

7. The device for automatically detecting and repairing glibc corruption in the Linux operating system as described in claim 6, characterized in that, The intelligent diagnostic module performs the following procedures: Dependency graph analysis: Mount the real root file system, scan the glibc files and their main dependent programs of the target system, obtain the dependencies of binary files, and the dependencies of those dependencies, construct a set of key dependency graphs, and simplify using this dependency graph to obtain all the glibc-related .so files that are ultimately dependent on it; Fault mode matching: Perform error detection tests and match the test results with a predefined glibc fault mode database. Once a matching error is found, perform the corresponding repair operation in the automated recovery module. Obtain the desired state: Automatically determine the correct glibc version number and hash value based on the system release information. At this time, the version number and hash value are the glibc version when the system was installed. Query through file records and compare the results. If the results are the same, the correction is successful; if they are different, the correction fails. Finally, output the correction judgment result.

8. The device for automatically detecting and repairing glibc corruption in the Linux operating system as described in claim 7, characterized in that, The automated recovery module performs corresponding replacement and correction operations, and after the replacement and correction are completed, it runs a preset health check script to verify whether glibc has been repaired. The replacement and correction operations include: Strategy selection: If the versions do not match, download the correct package from the preset mirror source or the initramfs built-in cache; Atomic replacement: In a chroot environment, use atomic operations to replace corrupted glibc files.

Images