A method and system for handling linux operating system boot failure

Abstract

The application relates to a method and system for processing Linux operating system startup failure, comprising the following steps: pre-configuring a key configuration file, a key path default file and a file failure knowledge base; performing file system mounting inspection on a virtual machine; if the file system of the virtual machine is not mounted, determining whether the virtual machine is a self-built system; if the file system of the virtual machine is mounted, performing MBR inspection; performing Boot directory inspection; determining whether the key path default file is missing; comparing the file content in a startup path, determining whether the file content is modified; and synchronizing the modified file content to a virtual machine log. The method and system can solve various types of problems encountered by a private cloud Linux virtual machine partition when system startup failure occurs, realize script-based automatic detection and processing, reduce the processing time length of each failure as much as possible, guarantee a certain timeliness, and reduce the burden of system operation and maintenance.

Description

Technical Field

[0001] This invention relates to the field of system fault troubleshooting technology, and in particular to a method and system for handling Linux operating system startup failures. Background Technology

[0002] The operating system is the cornerstone of the entire computer system. Whether it is a database system, various platform applications, big data, containers, etc., they all rely on the normal operation of the operating system to run. Its importance is self-evident.

[0003] Virtual machine hosts in an environment can generally be divided into two types: one is for deploying stateless applications. These hosts can usually be deployed quickly according to standard procedures (or hosts deployed according to standard procedures with only minor modifications, such as deploying Apache and only modifying one configuration file). The other is for deploying stateful applications. These hosts are usually deployed according to standard procedures, but the specific user still needs to make a lot of modifications, such as database servers or big data application servers with professional software installed.

[0004] If the host is deploying stateless applications, considering time and labor costs, system-level failures can be easily reversed and redeployed using standard procedures on a new machine, which is a relatively efficient approach. However, if stateful applications are deployed, it's generally desirable for the system to start and function normally most of the time, as redeployment is more costly, and some specialized software requires dedicated personnel for deployment.

[0005] Currently, resolving stateful Linux boot failures mostly relies on manual intervention by system administrators. This involves mounting a bootable CD of the same version to the console, booting the system into rescue mode, and then diagnosing the problem based on information provided by the operator and their experience. If the operator cannot provide useful information, or if file loss or corruption is due to an abnormal system shutdown, each problem needs to be addressed individually based on the specific error message. Of course, system errors vary greatly, and even experienced system administrators cannot understand them all. When the error message is relatively ambiguous, a trial-and-error approach is often necessary, repeatedly cycling between modifications and reboots. Finding the problem among hundreds of files is no easy task, primarily because system administrators lack a comprehensive view of the system at the time of the failure.

[0006] Currently, troubleshooting boot-level failures in Linux systems is extremely cumbersome. The primary requirement is that system administrators possess extensive fault diagnosis skills, which in turn require long-term technical experience and cannot be acquired overnight. Furthermore, these types of failures require operations to be performed in the terminal console, as there is no option to copy and paste commands or scripts; all operations must be completed manually.

[0007] In a typical environment, if someone makes system-level modifications and makes mistakes due to a lack of understanding of the underlying principles, they cannot accurately report the fault. System administrators can only deduce the error based on their existing experience. Usually, modifying one part requires restarting the host to test if it can boot. If it cannot boot, it needs to boot from the CD again, which is very time-consuming. For some hidden errors, the time cost is very high, taking anywhere from hours to days to resolve. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention proposes a method and system for handling Linux operating system startup failures. This method enables self-healing of operating system startup failures, allowing even novice system administrators to handle system-level failures, reducing troubleshooting time, and improving productivity.

[0009] To achieve the above objectives, the technical solution adopted by the present invention includes:

[0010] A method for handling Linux operating system boot failures, characterized by comprising:

[0011] S1. Pre-configure key configuration files, default files for key paths, and a file fault knowledge base;

[0012] S2. Perform a file system mount check on the virtual machine;

[0013] S3. If the virtual machine does not mount the file system, determine whether it is a self-built system.

[0014] S4. If the virtual machine mounts the file system, then perform an MBR check;

[0015] S5. Check the boot directory of the virtual machine;

[0016] S6. Determine if any default files for the critical paths of the virtual machine are missing;

[0017] S7. Compare the files in the virtual machine's startup path with the pre-configured default files in the critical paths to determine whether the contents of the files in the startup path have been modified.

[0018] S8. Synchronize the files in the modified startup path to the virtual machine log.

[0019] Furthermore, the key configuration files include: the MBR sector information file, the grub boot configuration file grub.cfg, the file system configuration file fstab, and the environment variable configuration file profile;

[0020] The default files for the critical paths include: the filenames, absolute paths, file types, and file sizes of all files in the / boot, / etc, / bin, / sbin, / lib, and / lib64 folders;

[0021] The file fault knowledge base includes: text documents recording configuration faults and / or configuration faults that have occurred in text-based configuration files.

[0022] Furthermore, step S4 includes the following sub-steps:

[0023] S41. Export the MBR sector information file from the virtual machine and compare it with the MBR sector information file in the pre-configured key configuration file information;

[0024] S42. If the comparison results are inconsistent, it indicates that there is a fault in the master boot sector of the virtual machine; import the MBR sector information file in the pre-configured key configuration file into the master boot sector of the virtual machine in the form of data blocks.

[0025] S43. If the comparison results are consistent, then perform a Boot directory check.

[0026] Furthermore, step S5 includes the following sub-steps:

[0027] S51. Check if the kernel image file, driver file, and device mapping file in the Boot directory are missing;

[0028] S52. If any part is missing, it is supplemented using grub-specific commands, and then the grub boot configuration file grub.cfg from the pre-configured key configuration files is copied to the Boot directory;

[0029] S53. If there are no missing files, determine whether the default files in the critical path are missing.

[0030] Furthermore, step S6 includes the following sub-steps:

[0031] S61. Recursively process the default files of the critical path of the virtual machine, using a loop to obtain the absolute path, file name, file type and file size of the file, and compare them with the pre-configured default files of the critical path.

[0032] S62. If a file is missing, copy the missing file from the pre-configured critical path default file.

[0033] S63. If no critical files are missing, compare the contents of the files in the startup path to determine whether the file contents have been modified.

[0034] Furthermore, step S7 includes the following sub-steps:

[0035] S71. Determine if the file is readable;

[0036] S72. If the file is unreadable, determine whether the file content has been modified by comparing the file size with the default file of the pre-configured critical path.

[0037] S73. If the file is readable, determine whether the file has been modified by comparing its size and content with the pre-configured default file for the critical path.

[0038] This invention also relates to a system for handling Linux operating system boot failures, characterized in that it comprises:

[0039] The pre-configuration module is used to pre-configure critical configuration files, default files for critical paths, and a file fault knowledge base;

[0040] The mount check module is used to perform file system mount checks on virtual machines.

[0041] The self-built system judgment module is used to determine whether a virtual machine is a self-built system if the file system is not mounted.

[0042] The MBR check module is used to perform an MBR check if the virtual machine mounts the file system.

[0043] The Boot directory inspection module is used to inspect the Boot directory of the virtual machine;

[0044] The file missing detection module is used to determine whether the default files on the critical paths of the virtual machine are missing.

[0045] The file content comparison module is used to compare the files in the startup path with the default files in the pre-configured critical paths to determine whether the file content in the startup path has been modified.

[0046] The synchronization module is used to synchronize files in the modified startup path to the virtual machine logs.

[0047] The present invention also relates to a computer-readable storage medium, characterized in that the storage medium stores a computer program, which, when executed by a processor, implements the above-described method for handling Linux operating system startup failures.

[0048] The present invention also relates to an electronic device, characterized in that it includes a processor and a memory;

[0049] The memory is used to store key configuration files, default files for key paths, and a file fault knowledge base;

[0050] The processor is used to execute the above-mentioned method for handling Linux operating system startup failures by calling key configuration files, key path default files, and file fault knowledge bases.

[0051] The present invention also relates to a computer program product, including a computer program and / or instructions, characterized in that, when the computer program and / or instructions are executed by a processor, they implement the steps of the above-described method for handling Linux operating system startup failures.

[0052] The beneficial effects of this invention are as follows:

[0053] This invention employs a method and system for handling Linux operating system startup failures. Guided by the Linux concept that everything is a file, it categorizes various problems encountered during the Linux startup process based on experience. Instead of troubleshooting individual problems separately, it uses scripts to handle these problems uniformly. Problems that can self-heal are handled, while those that cannot are given key information prompts. This provides system administrators with a holistic view of the current system status, minimizing troubleshooting time. Problems occurring at key points along the startup path are categorized and handled in a concise and clear manner. A single script execution provides a comprehensive view of the current system, offering direct information to determine the cause of the failure. Recurring failures are self-healing, while non-recurring failures reduce the number of trial and error attempts. Shell scripting, being a fundamental scripting language for system administrators, facilitates understanding the startup process by serializing the failure handling along the startup path. Furthermore, script functionality can be added, expanding the fault knowledge base and covering more fault points. Attached Figure Description

[0054] Figure 1 This describes the boot process of the Linux operating system.

[0055] Figure 2 This is a schematic flowchart of a method for handling Linux operating system startup failures according to the present invention.

[0056] Figure 3 This is a schematic diagram of a system structure for handling Linux operating system startup failures according to the present invention. Detailed Implementation

[0057] To better understand the content of this invention, it will be described in detail with reference to the accompanying drawings and embodiments.

[0058] To troubleshoot operating system startup failures, it's necessary to understand the underlying principles. Since the entire startup process is quite complex, the key points are briefly outlined below:

[0059] like Figure 1This describes the boot process of the Linux operating system. The entire boot process is divided into booting and starting. First, the host performs a BIOS-POST self-test to check for any hardware problems. If the self-test confirms that all hardware is normal, the host interrupt INT 13H is used to locate the first sector of the boot hard drive and load it into memory, namely the Master Boot Record (MBR). The MBR is only 512 bytes long, and its main function is to load the various file system drivers from STAGE 1.5 into memory. With the drivers, the boot partition in STAGE 2 can be recognized, including the GRUB configuration file and related kernel image. The image is then loaded into memory for self-extraction, thus completing the booting stage. Next, systemd (the parent process of all processes) is loaded. systemd reads the contents of / etc / fstab and mounts the file systems defined therein. Then, the default target is loaded, and the relevant services defined therein are started. Once all services have started, the operating system is in an interactive state, where the output interface displays a message waiting for the user to enter a username and password. This completes the entire boot process.

[0060] The first aspect of this invention relates to a method for handling Linux operating system boot failures, with the following steps: Figure 1 The method shown includes:

[0061] S1. Pre-configure key configuration files, default files for key paths, and a file fault knowledge base;

[0062] The key configuration files include: the MBR sector information file, the grub boot configuration file grub.cfg, the file system configuration file fstab, and the environment variable configuration file profile;

[0063] The default files for the critical paths include: the filenames, absolute paths, file types, and file sizes of all files in the / boot, / etc, / bin, / sbin, / lib, and / lib64 folders;

[0064] The file fault knowledge base includes: predictable configuration faults in text-based configuration files and / or recorded text documents based on configuration faults that have occurred.

[0065] Because the handling of system startup failures is quite unique, it can only be operated through the local console, and many common software programs and languages ​​are unusable in this situation. Therefore, the script uses a shell script that closely resembles the system for processing, and the pre-embedded comparison data is saved in a plain text file. The pre-embedded data is divided into three categories: 1. Critical configuration file information, including MBR sector information files, the grub boot configuration file grub.cfg, the file system configuration file fstab, and the environment variable configuration file profile. Since these files cannot be provided during rescue operation, the entire contents of these files need to be copied. 2. Default file information for critical paths, including the filenames, absolute paths, file types, and file sizes of all files under / boot, / etc, / bin, / sbin, / lib, and / lib64, saved line by line to a text file. Obtaining these two parts requires traversing and saving information using a minimally installed operating system. 3. A configuration file failure knowledge base, recording and saving predictable configuration failures or configuration failures that have already occurred in text configuration files to a separate text document. For example, configuring `source / etc / profile` in `profile` to cause infinite recursion, or configuring `*soft / hardmemlockunlimited` in `limits.conf` to cause total memory locking, will definitely lead to system startup failures.

[0066] Shell itself is the language closest to the system, and scripts can also be done using Python. After all, in some aspects, using a programming language is much more convenient and concise than using a scripting language. However, in boot mode, the relevant environment needs to be configured, which brings some complexity.

[0067] Scripts and pre-embedded data need to be added to the system in a special way. The data files are packaged into an ISO image, and after booting in rescue mode, they are loaded into the system as a second CD-ROM. After mounting, the required files can be extracted. For pre-embedded data, the operating system can also be pre-embedded, meaning the script files are directly added to the operating system image. This method is more convenient for troubleshooting, but it somewhat disrupts the system's neatness and simplicity (normally, the operating system image should only include the files required by the operating system itself).

[0068] The faults that need to be handled can be roughly divided into four categories, including:

[0069] 1. Troubleshooting during the boot phase

[0070] 2. Missing critical files during startup

[0071] 3. The contents of critical configuration files were modified or replaced during the startup phase.

[0072] 4. File system failure during startup

[0073] S2. Perform a file system mount check on the virtual machine;

[0074] S3. If the virtual machine does not mount the file system, determine whether it is a self-built system.

[0075] First, the booted virtual machine is checked for file system mounting. If the VG is not activated, it is automatically activated via a script. After activation, the original file system is automatically mounted according to a fixed correspondence. For those that fail to mount at this point, an fsck scan is performed to repair them, and then another attempt is made to mount them. If the original non-self-built file system still fails to mount, the script exits, prompting for manual intervention. If manual intervention is successful, the script can be executed again to check. If the self-built file system still fails to mount, the relevant fstab entries are commented out. For boot file systems that fail to mount and cannot be repaired, since they are separate partitions and not managed in the LVM logical volume, a complete rebuild is performed.

[0076] S4. If the virtual machine mounts the file system, then perform an MBR check;

[0077] The function of the MBR is to check whether the partition table is correct and to determine which partition is the boot partition. When the program ends, it loads the boot program (that is, the operating system boot sector) of that partition into memory for execution.

[0078] First, the Master Boot Record (MBR) is read and the partition table is copied from the MBR. Then, the MBR places the MBR containing the malicious binary data into the Master Boot Sector and copies the new partition table to it.

[0079] S41. Export the virtual machine MBR and compare it with the MBR sector information file in the pre-configured key configuration file information;

[0080] S42. If the comparison results are inconsistent, it indicates that there is a fault in the master boot sector; import the MBR sector information file in the pre-configured key configuration file directly into the master sector in the form of data blocks.

[0081] S43. If the comparison results are consistent, then perform a Boot directory check;

[0082] Export the local MBR and compare it with the MBR pre-embedded in the image. If the results are inconsistent, it indicates that there is a problem with the master boot sector. Since the system is generally generated by cloning the same image, all virtual machine MBRs are the same. In this case, the pre-embedded MBR can be directly imported into the master sector in the form of data blocks.

[0083] S5. Perform a Boot directory check;

[0084] Files and directories in the / boot / directory:

[0085] When a Linux system boots locally, the files and directories in the / boot / directory include:

[0086] (1) System Kernel configuration files;

[0087] (2) Start the directory of the management program GRUB, which contains the screens, configurations and files for each stage (stage1, stage1.5, stage2) required by GRUB when it starts up;

[0088] (3) The Initrd file is the main source of module supply during system startup;

[0089] (4) The System.map file is a variable mapping table in the system kernel;

[0090] (5) vmlinuz is the most important file during the startup process because it is the kernel used by the actual system.

[0091] / boot / grub directory

[0092] The grub.conf file is the configuration file for the GRUB boot manager. In the same directory ( / boot / grub / ), there is also a mirror file called menu.lst. In SUSE, menu.lst is the file actually used by GRUB.

[0093] root(hd0,0) represents the path to / boot / . My / boot / is located at / dev / sda1, which is sector 0 of hard drive 0 detected by the BIOS.

[0094] The absolute path is / boot / vmlinuz-2.4.20-8, while the physical location of the file is / dev / sda1. The 'ro' indicates that the file is read-only, and 'root=LABEL= / ' indicates that the file system with the label ' / ' is the root file system. This root file system is different from the location of / boot / . Here, 'root' is a parameter used when loading the kernel to tell the kernel where the root file system is located. In reality, / boot / can be mounted on other hard drives. As long as the location of 'A' is accurate, it's fine; for example, root(hd1,0) means / boot / is on the second hard drive.

[0095] The grub.conf file is the most important among the other files, but there are also some other files in / boot / grub / ;

[0096] The stages file is a backup file of the hardware boot sector (MBR).

[0097] *xxx_stage1_5: These files serve as a channel connecting stage1 to stage2. The only thing they contain is the format of the system files, so for any supported file, a format file will be pre-stored in them.

[0098] *stage2: This file is the core program of GRUB, used to: provide menus, read configuration files, and connect to the next bootsector.

[0099] The System.map file is an index file that records the location of symbols in the kernel. Symbols include variable or function names.

[0100] The kernel is primarily responsible for the Northbridge, Southbridge, CPU, and memory, which are the most important hardware cores of the entire host. If there is a problem with the kernel, the system will definitely fail to boot.

[0101] The initrd file (initial ramdisk) is the virtual disk that needs to be loaded to boot the system. During system startup, the kernel, initrd, and system modules are loaded sequentially. The initrd contains some kernel modules, mainly some critical external hardware, such as peripherals like SATA, SCSI, and USB. Its failure will naturally affect system startup.

[0102] S51. Check if the kernel image file, driver file, and device mapping file in the Boot directory are missing;

[0103] S52. If any parts are missing, the grub-specific command is used to supplement and generate them, and then the grub boot configuration file grub.cfg from the pre-configured key configuration files is copied to the Boot directory.

[0104] S53. If there are no missing files, determine whether the default files of the critical path are missing.

[0105] If no problems are found, continue checking the bootloader for missing kernel image files, driver files, device mapping files, etc. If any are missing, use GRUB-specific commands to supplement and generate them, then copy the pre-installed GRUB configuration files to the specified directory. Problems and solutions during the boot phase are relatively fixed and can be handled automatically in the script.

[0106] S6. Determine if any default files in the critical path are missing;

[0107] S61. Recursively process the default files of the critical path of the virtual machine, using a loop to obtain the absolute path, file name, and file type of the file, and compare them with the pre-configured default files of the critical path.

[0108] S62. If any files are missing, copy the missing entity files from the system and rebuild the missing link files using system commands.

[0109] S63. If no critical files are missing, compare the contents of the files in the startup path to determine whether the file contents have been modified.

[0110] The next stage begins by scanning files under the critical path, recursively processing folders, and using a loop to obtain the absolute path, filename, and file type of local files. This information is then compared with pre-embedded file information. This round of comparison primarily identifies any missing files. Missing physical files can be directly copied from the runtime system, while missing linked files are reconstructed using system commands. All operations here must be synchronized to the local operation log file for system administrator review. Failures at this stage are often caused by accidental file deletion or unexpected file loss due to abnormal shutdowns. For example, the loss of files such as `target` and `udev` can prevent the system from booting normally.

[0111] S7. Compare the contents of the files in the startup path to determine whether the file contents have been modified;

[0112] S71. For unreadable files, determine whether the file content has been modified by checking if the file size is consistent.

[0113] If the file sizes are inconsistent, the file content is modified; the file is renamed to become a backup file, and the same version of the file is copied from the runtime.

[0114] S72. For readable files, determine whether the file has been modified by comparing the file size with the default file of the pre-configured critical path.

[0115] S8. Synchronize the modified file content to the virtual machine log.

[0116] The final stage requires comparing files on the startup path to confirm whether they have been modified. This comparison primarily involves comparing file size information with pre-embedded data. For binary command files and library files, since the file content itself is unreadable, only their file size can be used for judgment. If the sizes are inconsistent, the files may have been modified. This could lead to two scenarios: either a forced upgrade of some library files caused other library dependencies to fail, which is the cause of the fault; or a correct upgrade where all dependencies are normal and not the cause of the fault. However, this distinction is not made here. The current file is uniformly renamed to a backup file, and then the same version of the file is copied from the runtime. After the system starts normally, the relevant information is confirmed with the operator. At this point, the operator can log in to the host normally. If it is a normal upgrade, the files can be replaced in batches. For configuration files with readable content, in the case of inconsistent sizes, regular expressions are used to precisely match the content in the fault knowledge base with the existing files. Once a match is found, the relevant configuration items are directly commented out. Modifications here also need to be synchronized with local logs for future reference. If no match is found, the modified configuration file name is reported, requiring manual intervention for investigation. This narrows the scope of investigation and improves processing efficiency.

[0117] After all processes are completed, data synchronization is performed to ensure that the changes take effect, and the system is restarted for verification.

[0118] Another aspect of the present invention relates to a system for handling Linux operating system boot failures, the structure of which is as follows: Figure 2 As shown, it includes:

[0119] The pre-configuration module is used to pre-configure critical configuration files, default files for critical paths, and a file fault knowledge base;

[0120] The mount check module is used to perform file system mount checks on virtual machines.

[0121] The self-built system judgment module is used to determine whether a virtual machine is a self-built system if the file system is not mounted.

[0122] The MBR check module is used to perform an MBR check if the virtual machine mounts the file system.

[0123] The Boot directory check module is used to perform Boot directory checks.

[0124] The file missing detection module is used to determine whether the default files in the critical path are missing.

[0125] The file content comparison module is used to compare the contents of files in the startup path to determine whether the file contents have been modified.

[0126] The synchronization module is used to synchronize the modified file content to the virtual machine log.

[0127] By using this system, the aforementioned computational processing methods can be executed and the corresponding technical effects can be achieved.

[0128] Embodiments of the present invention also provide a computer-readable storage medium capable of implementing all the steps of the methods in the above embodiments, wherein the computer-readable storage medium stores a computer program that, when executed by a processor, implements all the steps of the methods in the above embodiments.

[0129] Embodiments of the present invention also provide an electronic device for performing the above-described method. As an implementation device for the method, the electronic device has at least a processor and a memory. In particular, the memory stores data and related computer programs required for performing the method, such as pre-configured key configuration files, key path default files, and file fault knowledge bases. The processor calls the data and programs in the memory to execute all steps of the method and obtain the corresponding technical effects.

[0130] Preferably, the electronic device may include a bus architecture, which may include any number of interconnected buses and bridges. The bus will include various circuits linked together by one or more processors and memories. The bus may also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface between the bus and the receiver and transmitter. The receiver and transmitter may be the same element, i.e., a transceiver, providing a unit for communicating with various other systems over a transmission medium. The processor is responsible for managing the bus and general processing, while the memory may be used to store data used by the processor during operation.

[0131] Additionally, the electronic device may further include components such as a communication module, an input unit, an audio processor, a display, and a power supply. The processor (or controller, operating control) used may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device; the memory may be one or more of a buffer, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices, which can store the aforementioned data information, and may also store programs for executing the information, and the processor can execute the program stored in the memory to achieve information storage or processing, etc.; the input unit is used to provide input to the processor, for example, it can be a button or touch input device; the power supply is used to provide power to the electronic device; the display is used to display images and text, for example, it can be an LCD display. The communication module is a transmitter / receiver that transmits and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor to provide input signals and receive output signals, which can be the same as in conventional mobile communication terminals. Based on different communication technologies, multiple communication modules can be incorporated into the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) is also coupled to a speaker and microphone via an audio processor to provide audio output through the speaker and receive audio input from the microphone, thereby enabling typical telecommunications functions. The audio processor can include any suitable buffer, decoder, amplifier, etc. Furthermore, the audio processor is coupled to a central processing unit, enabling on-device recording via the microphone and on-device playback of stored sound via the speaker.

[0132] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0133] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0134] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0135] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the functions specified in one or more boxes. Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.

[0136] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for handling Linux operating system boot failures, characterized in that, include: S1. Pre-configure key configuration files, default files for key paths, and a file fault knowledge base; S2. Perform a file system mount check on the virtual machine; S3. If the virtual machine does not mount the file system, determine whether it is a self-built system. S4. If the virtual machine mounts the file system, then perform an MBR check; S5. Check the boot directory of the virtual machine; S6. Determine if any default files for the critical paths of the virtual machine are missing; S7. Compare the files in the virtual machine's startup path with the pre-configured default files in the critical paths to determine whether the contents of the files in the startup path have been modified. S8. Synchronize the files in the modified startup path to the virtual machine log; The key configuration files include: the MBR sector information file, the grub boot configuration file grub.cfg, the file system configuration file fstab, and the environment variable configuration file profile; The default files for the critical paths include: the filenames, absolute paths, file types, and file sizes of all files in the / boot, / etc, / bin, / sbin, / lib, and / lib64 folders; The file fault knowledge base includes: text documents recording configuration faults and / or configuration faults that have occurred in text-based configuration files; Step S7 includes the following sub-steps: S71. Determine if the file is readable; S72. If the file is unreadable, determine whether the file content has been modified by comparing the file size with the default file of the pre-configured critical path. S73. If the file is readable, determine whether the file has been modified by comparing its size and content with the pre-configured default file for the critical path. The system uses scripts to handle various issues in a unified manner. The scripts are processed using a shell that is closest to the system. The pre-embedded comparison data is saved in a plain text file. The scripts and pre-embedded data need to be added to the system in a special way. The data files are packaged into an ISO image. After booting in rescue mode, the image is loaded into the system as a second CD. After mounting, the required files can be extracted.

2. The method as described in claim 1, characterized in that, Step S4 includes the following sub-steps: S41. Export the MBR sector information file from the virtual machine and compare it with the MBR sector information file in the pre-configured key configuration file information; S42. If the comparison results are inconsistent, it indicates that there is a fault in the master boot sector of the virtual machine; import the MBR sector information file in the pre-configured key configuration file into the master boot sector of the virtual machine in the form of data blocks. S43. If the comparison results are consistent, then perform a Boot directory check.

3. The method as described in claim 1, characterized in that, Step S5 includes the following sub-steps: S51. Check if the kernel image file, driver file, and device mapping file in the Boot directory are missing; S52. If any part is missing, it is supplemented using grub-specific commands, and then the grub boot configuration file grub.cfg from the pre-configured key configuration files is copied to the Boot directory; S53. If there are no missing files, determine whether the default files in the critical path are missing.

4. The method as described in claim 1, characterized in that, Step S6 includes the following sub-steps: S61. Recursively process the default files of the critical path of the virtual machine, using a loop to obtain the absolute path, file name, file type and file size of the file, and compare them with the pre-configured default files of the critical path. S62. If a file is missing, copy the missing file from the pre-configured critical path default file. S63. If no critical files are missing, compare the contents of the files in the startup path to determine whether the file contents have been modified.

5. A system for handling Linux operating system boot failures, characterized in that, include: The pre-configuration module is used to pre-configure critical configuration files, default files for critical paths, and a file fault knowledge base; The mount check module is used to perform file system mount checks on virtual machines. The self-built system judgment module is used to determine whether a virtual machine is a self-built system if the file system is not mounted. The MBR check module is used to perform an MBR check if the virtual machine mounts the file system. The Boot directory inspection module is used to inspect the Boot directory of the virtual machine; The file missing detection module is used to determine whether the default files on the critical paths of the virtual machine are missing. The file content comparison module is used to compare the files in the startup path with the default files in the pre-configured critical paths to determine whether the file content in the startup path has been modified. The synchronization module is used to synchronize files in the modified startup path to the virtual machine logs. The key configuration files include: the MBR sector information file, the grub boot configuration file grub.cfg, the file system configuration file fstab, and the environment variable configuration file profile; The default files for the critical paths include: the filenames, absolute paths, file types, and file sizes of all files in the / boot, / etc, / bin, / sbin, / lib, and / lib64 folders; The file fault knowledge base includes: text documents recording configuration faults and / or configuration faults that have occurred in text-based configuration files; The file content comparison module is also used for: Determine if a file is readable; If the file is unreadable, the file size is compared with the default file of the pre-configured critical path to determine whether the file content has been modified. If the file is readable, the file size and content are compared with the pre-configured default file for the critical path to determine whether the file has been modified. The system uses scripts to handle various issues in a unified manner. The scripts are processed using a shell that is closest to the system. The pre-embedded comparison data is saved in a plain text file. The scripts and pre-embedded data need to be added to the system in a special way. The data files are packaged into an ISO image. After booting in rescue mode, the image is loaded into the system as a second CD. After mounting, the required files can be extracted.

6. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method for handling Linux operating system startup failures as described in any one of claims 1 to 4.

7. An electronic device, characterized in that, Including processor and memory; The memory is used to store key configuration files, default files for key paths, and a file fault knowledge base; The processor is configured to execute the method for handling Linux operating system startup failures as described in any one of claims 1 to 4 by invoking key configuration files, key path default files, and a file fault knowledge base.

8. A computer program product, comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the steps of the method for handling Linux operating system startup failures as described in any one of claims 1 to 4.

Images