Kdump online debugging method and device under kernel crash scenario

Abstract

This invention discloses an online debugging method and apparatus for Kdump in kernel crash scenarios, belonging to the field of computer technology. It includes: packaging the vmlinux file into a read-only image and storing it in the disk boot partition; modifying the kdump-capture service configuration; inserting instructions to mount the read-only image and start the interactive shell before the memory dump tool's startup instruction; when the kernel crashes, starting the capture kernel and initializing the serial port driver; the capture kernel probing the disk boot partition, mounting the read-only image, and starting a countdown to monitor interrupt signals in the interactive shell; when an interrupt signal is detected within the countdown, extracting the first Build-ID of vmlinux in the read-only image and comparing it with the second Build-ID of the crashed kernel in the capture kernel; if the comparison is successful, executing the memory dump tool's memory dump operation. By pre-setting the vmlinux image, introducing the interactive shell, and adding Build-ID verification, the online debugging window is reserved during the kernel crash Kdump capture stage, and memory dump is performed after kernel matching.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a Kdump online debugging method and apparatus for kernel crash scenarios. Background Technology

[0002] In Linux kernel development and maintenance scenarios, quickly and accurately locating kernel panic crashes is crucial for ensuring system stability. After a kernel crash occurs, the system automatically switches to Kdump to capture the kernel and perform a memory dump.

[0003] However, in the traditional mode, kernel capture only supports fully automatic dumping, and it is not possible to query the kernel status, control the dumping process, or perform custom analysis before dumping. At the same time, the problem of mismatch between the debug kernel image file (vmlinux) and the crashed kernel version can only be discovered after the memory dump snapshot file (vmcore) is generated, which seriously affects the debugging efficiency of kernel faults.

[0004] Limited by the existing Kdump processing mechanism, kernel crash debugging can only be done offline, and it is impossible to intervene in debugging in place and verify the legality of debugging files. The flexibility and reliability of troubleshooting are poor, making it difficult to meet the actual needs of efficient operation and maintenance. Summary of the Invention

[0005] This invention provides a Kdump online debugging method and apparatus for kernel crash scenarios, in order to solve the technical problems of poor flexibility and reliability of fault diagnosis and low efficiency of kernel fault debugging in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a Kdump online debugging method for kernel crash scenarios, including: Package the vmlinux kernel file to generate a read-only image, store the read-only image in the disk boot partition, modify the kdump-capture.service service configuration, and insert the command to mount the read-only image and the command to start the interactive shell before the makedumpfile startup command; When the kernel crashes and triggers the kdump mechanism, Kdump is started to capture the kernel. Kdump captures the kernel to initialize the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. Kdump captures kernel probes of disk boot partitions, mounts read-only images to temporary mount directories by executing commands to mount read-only images, and starts a preset countdown in the interactive shell based on commands, monitoring terminal interrupt signals during the countdown period; When a terminal interrupt signal is detected within the preset countdown time, the first Build-ID information of the vmlinux kernel file in the read-only image is extracted, and the second Build-ID information of the crashed kernel is obtained from the vmcore accessible by the captured kernel. The first Build-ID information and the second Build-ID information are compared. After the comparison is successful, the makedumpfile memory dump operation is executed.

[0007] Secondly, embodiments of the present invention also provide a Kdump online debugging device for kernel crash scenarios, comprising: Insert a mount module to package the vmlinux kernel file into a read-only image and store the read-only image in the disk boot partition. Modify the kdump-capture.service service configuration to insert the command to mount the read-only image and the command to start the interactive shell before the makedumpfile startup command. The initialization module is used to start Kdump to capture the kernel when the kernel crashes and triggers the kdump mechanism. Kdump captures the kernel to initialize the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. The signal detection module is used by Kdump to capture kernel probe disk boot partitions. By executing the command to mount the read-only image, it mounts the read-only image to a temporary mount directory. Based on the commands in the interactive shell, it starts a preset countdown in the interactive shell and monitors terminal interrupt signals during the countdown period. The memory dump module is used to extract the first Build-ID information of the vmlinux kernel file in the read-only image when a terminal interrupt signal is detected within a preset countdown time, and to obtain the second Build-ID information of the crashed kernel from the vmcore that the kernel can access. The first Build-ID information and the second Build-ID information are compared. If the comparison is successful, the makedumpfile memory dump operation is executed.

[0008] Thirdly, embodiments of the present invention also provide a terminal, including: One or more processors; Storage device for storing one or more programs; When one or more programs are executed by one or more processors, the one or more processors implement the Kdump online debugging method for kernel crash scenarios as provided in the above embodiments.

[0009] Fourthly, embodiments of the present invention also provide a medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the Kdump online debugging method for kernel crash scenarios as provided in the above embodiments.

[0010] The Kdump online debugging method and apparatus for kernel crash scenarios provided in this invention package the vmlinux kernel file into a read-only image and store the read-only image in the disk boot partition. The kdump-capture.service service configuration is modified to insert instructions for mounting the read-only image and starting the interactive shell before the makedumpfile startup instruction. When the kernel crashes and triggers the kdump mechanism, the Kdump capture kernel is started. The Kdump capture kernel initializes the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. The Kdump capture kernel probes the disk boot partition. The partitioning process involves mounting a read-only image to a temporary mount directory using commands. An interactive shell countdown is then initiated within the shell, monitoring for terminal interruptions during the countdown period. Upon detecting an interruption within the countdown, the first Build-ID information of the vmlinux kernel file in the read-only image is extracted, and the second Build-ID information of the crashed kernel is obtained from the captured kernel-accessible vmcore. The first and second Build-ID information are compared; if the comparison is successful, a makedumpfile memory dump operation is executed. This entire process—pre-building a debug image, intercepting the dump execution flow to build an interactive terminal, intercepting user operations during the crash countdown, and pre-verifying kernel identifiers—achieves in-situ online debugging during kernel crashes, pre-verifying kernel image compatibility, and flexibly managing the memory dump process. Attached Figure Description

[0011] The accompanying drawings, which form part of this invention, 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 improper limitation of the invention.

[0012] Figure 1 This is a flowchart of the Kdump online debugging method for kernel crash scenarios provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the Kdump online debugging method for kernel crash scenarios provided in Embodiment 2 of the present invention; Figure 3 This is a structural diagram of the Kdump online debugging device for kernel crash scenarios provided in Embodiment 3 of the present invention; Figure 4This is a structural diagram of the terminal provided in Embodiment 4 of the present invention. Detailed Implementation

[0013] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0014] Example 1 Figure 1 This is a flowchart of the Kdump online debugging method for kernel crash scenarios provided in Embodiment 1 of the present invention. This embodiment is applicable to scenarios where the system experiences a kernel panic crash, and interactive troubleshooting is performed by capturing the kernel using Kdump. Specifically, it includes the following steps: Step 110: Package the vmlinux kernel file to generate a read-only image, store the read-only image in the disk boot partition, modify the kdump-capture.service service configuration, and insert the command to mount the read-only image and the command to start the interactive shell before the makedumpfile startup command.

[0015] vmlinux is an uncompressed ELF format kernel image file output by the kernel compilation process. It contains complete kernel code and kernel symbol information, and is the foundational file for kernel fault analysis by debugging tools such as Crash. It can be obtained from the kernel debugging symbol directory or the kernel source code compilation output directory, and can be used to parse crashed kernel runtime information to perform fault location tasks such as kernel exception stack backtracking and variable viewing.

[0016] After the kernel crash triggers the Kdump mechanism to switch to the capture kernel, the capture kernel does not carry a vmlinux file matching the crashed kernel by default. The vmlinux file is packaged and stored in the disk boot partition in advance, so that it can be directly mounted and read during the operation phase of the capture kernel, without relying on network transmission or external storage for file copying, which ensures no additional storage dependency at the crash site. Meanwhile, debugging assets are pre-packaged and solidified to ensure that the kernel image of the matching version can be retrieved during online debugging. For example, the server uses the Phytium D3000 chip and is installed with the Galaxy Kylin Advanced Server Operating System V10SP1. During the deployment phase of the production kernel environment, the vmlinux kernel file is extracted from the debug symbol directory corresponding to the production kernel or the kernel build output directory, with a typical path such as / usr / lib / debug / lib / modules / <kernel version> / vmlinux or the vmlinux under the kernel source code build directory. The vmlinux kernel file is encapsulated as a SquashFS format read-only compressed image as a mandatory file, and then the encapsulated image is persistently stored in the disk boot partition. The disk boot partition has the feature of being identifiable and mountable by the Kdump capture kernel. When the system has a kernel crash and switches to the capture kernel, the capture kernel can detect and mount the partition, and read the vmlinux file in the image.

[0017] kdump-capture.service is a system service unit supporting the Kdump mechanism, which is automatically loaded and run after the kernel crashes and switches to the Kdump capture kernel. In the native logic, the service directly schedules the makedumpfile tool to execute the memory dump process. It is the core service that controls the execution timing of the capture kernel memory dump task, and determines the start time and execution sequence of the memory snapshot dump task in the capture kernel. The native kdump-capture.service runs with the logic of directly starting makedumpfile to fully automatically perform memory dump, without a pause interaction link. By modifying the service configuration to realize pre-injection of instructions, it is possible to seize the execution timing before the automatic dump is triggered, complete the mounting of the debugging asset image and launch an interactive Shell. This breaks the execution link of the traditional Kdump that can only perform offline dump, and realizes kernel information verification and in-situ debugging of the fault site before memory dump.

[0018] For example, the configuration of kdump-capture.service in the capture kernel environment is adjusted. Before the makedumpfile startup command in the service script, an automatic mount command for the read-only image of the debug asset and an interactive shell startup logic based on the ptrace mechanism are inserted sequentially. After the configuration takes effect, when the capture kernel starts and kdump-capture.service starts running, the image mount operation will be executed first, followed by the execution flow managed by the ptrace parent process, which will then launch the interactive online debugging shell. Operations personnel can use the interactive shell to call the pre-built verification program within the image to complete kernel image matching verification, control the startup timing of makedumpfile as needed, and achieve interactive troubleshooting of kernel crash scenarios.

[0019] By pre-deploying debugging assets and modifying the capture kernel execution chain, debugging resources such as the vmlinux kernel file are packaged into read-only images and stored in the disk boot partition, ensuring stable retrieval of debugging files after switching to the capture kernel following a kernel crash. Furthermore, by preempting the execution sequence of makedumpfile, the capture kernel completes image mounting and launches an interactive shell before automatic memory dumping begins. Ultimately, this enables in-situ online debugging of the kernel crash scene, supports advance kernel version matching verification, and allows operations personnel to flexibly intervene in the memory dumping process. This avoids the loss of real-time fault analysis conditions caused by the traditional Kdump mechanism's direct execution of memory dumps, improving the flexibility and efficiency of kernel anomaly troubleshooting.

[0020] Step 120: When the kernel crashes and triggers the kdump mechanism, Kdump is started to capture the kernel. Kdump captures the kernel to initialize the serial port driver and provides terminal interaction for the interactive shell through the serial port driver.

[0021] The Kdump capture kernel is a standby kernel that is pre-loaded into a portion of system memory. When the production kernel panics, it switches to run using the kexec mechanism and takes over CPU control. The capture kernel runs independently of the faulty production kernel and is not affected by the abnormal state of the crashed kernel. It is specifically used to save a memory snapshot of the crash scene and perform fault scene handling. It is the core carrier for Kdump's crash information preservation mechanism.

[0022] Traditional Kdump capture kernels only perform memory dumps and lack a human-machine interaction channel. By initializing the UART serial port driver in the capture kernel and establishing an interactive shell terminal link, a remote operation channel can be established at the crash site. Operations personnel can directly access the capture kernel for real-time debugging without relying on a graphical interface or network environment. For example, a hardware anomaly automatically triggers the production kernel to enter Panic state. Subsequently, the system uses kexec to transfer CPU control to the pre-resident Kdump capture kernel. After the capture kernel starts, it loads and mounts the initramfs root file system, completes the UART serial port driver initialization, establishes a standard input / output redirection link, and builds a terminal interaction path based on the serial port hardware channel. The interactive shell reuses the serial port link to send and receive commands and output information. Operations personnel can access the capture kernel environment through a serial port terminal to achieve online debugging operations. Optionally, when there is no hardware anomaly to automatically trigger the production kernel to enter Panic state, to verify the effectiveness of this embodiment, the production kernel can be manually triggered to enter Panic state using the SysRq signal.

[0023] During the kernel startup phase captured by Kdump, the UART serial port driver is initialized, and a stable terminal interaction link is established based on the serial port hardware channel, providing human-computer interaction support for the interactive shell. This allows maintenance personnel to access the captured kernel and perform real-time debugging operations at the kernel crash site without relying on a network environment, enabling on-site manual intervention at the crash site. This overcomes the limitations of the traditional Kdump mechanism, which lacks a real-time interactive channel and can only perform fully automatic memory dumps.

[0024] Step 130: Kdump captures the kernel's probe disk boot partition, mounts the read-only image to a temporary mount directory by executing the command to mount the read-only image, and starts a preset countdown in the interactive shell based on the command in the interactive shell, monitoring the terminal interrupt signal during the countdown period.

[0025] The system automatically mounts read-only images of debugging resources, allowing the capture kernel to directly access pre-built verification programs and debugging tools within the image. Furthermore, it introduces a countdown and terminal interrupt signal monitoring mechanism, accommodating both manual interactive debugging and automated memory dumping modes. This provides maintenance personnel with a window for on-site troubleshooting of crashes, while automatically executing the memory dump process if no intervention is provided after a timeout, preventing prolonged system blockage. For example, the capture kernel runs a script to probe the disk boot partition and uses a Loop device to mount a SquashFS format read-only image to a temporary mount point (e.g., / mnt / debug_assets). After mounting, it outputs an online debugging prompt to the serial terminal, starts a preset countdown (e.g., 5 seconds) based on the kernel's HZ clock, continuously monitors terminal interrupt signals, and waits for maintenance personnel to choose whether to enter online debugging mode.

[0026] By automatically mounting a read-only image containing debugging tools, debugging assets can be quickly put into use. A selectable interactive window is constructed by combining countdown timers and terminal signal monitoring, balancing the needs of manual on-site debugging with the ability to automatically save memory snapshots in unattended scenarios, thus improving the adaptability of kernel crash handling solutions.

[0027] Step 140: When a terminal interrupt signal is detected within the preset countdown time, extract the first Build-ID information of the vmlinux kernel file in the read-only image, and obtain the second Build-ID information of the crashed kernel from the vmcore accessible by the captured kernel. Compare the first Build-ID information and the second Build-ID information. After the comparison is successful, execute the makedumpfile memory dump operation.

[0028] Kernel version consistency is verified through Build-ID identity authentication, avoiding issues such as parsing errors and distorted stack information caused by mismatches between the debugging tool's kernel image and the crash site's vmcore. In scenarios where manual intervention in online debugging is permitted, version verification is performed first; only if a match is successful is a memory dump executed, effectively intercepting invalid dumps and conserving storage resources. It also supports degradation comparison strategies and differentiated handling logic, balancing reliability and solution compatibility.

[0029] For example, during the countdown window, the operations and maintenance personnel issue a terminal interrupt signal, suspending the automatic dump process and activating the online debugging mode. The pre-installed verification program within the image is run, extracting the GNU Build-ID corresponding to vmlinux from the mounted read-only image as the first Build-ID, and reading the Build-ID of the crashed kernel from the PT_NOTE or VMCOREINFO area of ​​the ELF dump segment corresponding to / proc / vmcore, which is accessible to the captured kernel, as the second Build-ID. The two sets of identifiers are compared. If vmcore cannot read the Build-ID, the kernel version string is used for matching. If the two information match, the comparison passes, triggering makedumpfile to compress and write the physical memory data corresponding to vmcore to persistent media, completing the memory dump. If the comparison does not match, error information is output according to a preset strategy. The dump can be terminated, or an exception log can be recorded before continuing the dump operation. After the dump is complete, a kernel cold reboot is triggered to restore the host's production operating environment. If the operations and maintenance personnel do not issue a terminal interrupt signal during the countdown window, the online debugging and Build-ID verification process will be skipped directly. The makedumpfile will be triggered to perform a memory dump operation, compressing the physical memory data corresponding to / proc / vmcore and writing it to the persistent medium. After the dump is completed, a kernel cold reboot will be triggered to restore the host production operating environment.

[0030] This embodiment packages the vmlinux kernel file into a read-only image and stores it in the disk boot partition. The kdump-capture.service service configuration is modified to insert instructions for mounting the read-only image and starting the interactive shell before the makedumpfile startup instruction. When the kernel crashes and triggers the kdump mechanism, the Kdump capture kernel is started. The Kdump capture kernel initializes the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. The Kdump capture kernel probes the disk boot partition, mounts the read-only image to a temporary mount directory by executing the instruction to mount the read-only image, and starts a preset countdown in the interactive shell based on the instructions. During the countdown period, it monitors for terminal interrupt signals. When a terminal interrupt signal is detected within the preset countdown, the first Build-ID information of the vmlinux kernel file in the read-only image is extracted, and the second Build-ID information of the crashed kernel is obtained from the vmcore accessible to the captured kernel. The first and second Build-ID information are compared, and if the comparison is successful, the makedumpfile memory dump operation is executed. By pre-building debug images, intercepting the dump execution flow to build an interactive terminal, intercepting user operations with a countdown after a crash, and verifying kernel identifiers in advance, the system achieves the effects of in-situ online debugging during kernel crashes, early verification of kernel image compatibility, and flexible control over the memory dump process.

[0031] Example 2 Figure 2 This is a flowchart of the Kdump online debugging method for kernel crash scenarios provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiment and optimized. The step of packaging the vmlinux kernel file to generate a read-only image and storing the read-only image to the disk boot partition also includes: packaging the vmlinux kernel file and the user-selected program into a read-only image in SquashFS format and storing the packaged read-only image to the disk boot partition; after the comparison is passed and the makedumpfile memory dump operation step is executed, the method further includes: parsing the NT_VMCOREINFO segment in the vmcore, extracting the stext, KERNELOFFSET and PAGE_SIZE kernel running parameters, running the user-selected program, and using the extracted kernel running parameters in combination with vmlinux and vmcore to perform in-situ fault analysis.

[0032] See Figure 2 Online debugging methods using Kdump in kernel crash scenarios include: Step 210: Package the vmlinux kernel file and user-selected programs into a read-only image in SquashFS format, store the packaged read-only image in the disk boot partition, modify the kdump-capture.service service configuration, and insert the command to mount the read-only image and the command to start the interactive shell before the makedumpfile startup command.

[0033] For example, during the initial debugging asset image pre-build phase, the vmlinux kernel file is extracted from the production kernel debugging symbol path / usr / lib / debug / lib / modules / <kernel version> / vmlinux or the kernel source code build directory, and packaged together with user-selected programs into a SquashFS format read-only compressed image. The user-selected programs may include crash debugging tools, custom kernel information extraction scripts, on-site log collection programs, and preliminary memory data parsing scripts for crash scene analysis. The generated SquashFS read-only image is persistently stored in the disk boot partition, ensuring that kdump can recognize and access the disk boot partition during kernel runtime capture.

[0034] Step 220: When the kernel crashes and triggers the kdump mechanism, Kdump is started to capture the kernel. Kdump captures the kernel to initialize the serial port driver and provides terminal interaction for the interactive shell through the serial port driver.

[0035] Step 230: Kdump captures the kernel's probe disk boot partition, mounts the read-only image to a temporary mount directory by executing the command to mount the read-only image, and starts a preset countdown in the interactive shell based on the command in the interactive shell, monitoring the terminal interrupt signal during the countdown period.

[0036] Step 240: When a terminal interrupt signal is detected within the preset countdown time, extract the first Build-ID information of the vmlinux kernel file in the read-only image, and obtain the second Build-ID information of the crashed kernel from the vmcore accessible by the captured kernel. Compare the first Build-ID information and the second Build-ID information. After the comparison is successful, execute the makedumpfile memory dump operation.

[0037] Step 250: parse the NT_VMCOREINFO segment in the vmcore, extract the kernel runtime parameters stext, KERNELOFFSET, and PAGE_SIZE, run the user-selected program, and use the extracted kernel runtime parameters in conjunction with vmlinux and vmcore to perform in-situ fault analysis.

[0038] By parsing the kernel runtime parameters built into vmcore, critical context can be provided for user-selected debugging programs, ensuring that debugging tools can correctly load vmlinux and vmcore to complete in-situ analysis and avoid debugging failures due to missing kernel runtime information. For example, the system reads the generated vmcore file, parses the NT_VMCOREINFO segment, and extracts key kernel runtime parameters such as stext, KERNELOFFSET, and PAGE_SIZE. This is only used to obtain the context data required for debugging and does not participate in vmlinux version consistency comparison. Subsequently, the user-selected program pre-installed in the image, typically a crash debugging tool, is launched. Using the extracted kernel runtime parameters as input, it performs in-situ fault analysis in conjunction with the mounted vmlinux debugging symbol file and the current vmcore memory dump file. Operations personnel can use the interactive debugging environment to view information such as the kernel crash scene task stack, memory layout, and register status. During online debugging, they can also manually issue commands to trigger memory dump operations based on the progress of the investigation. After the dump is completed, they can continue to call custom analysis scripts to conduct further in-depth investigations.

[0039] This embodiment encapsulates the vmlinux kernel file and user-selected programs into a read-only image in SquashFS format. The encapsulated read-only image is stored in the disk boot partition. The kdump-capture.service service configuration is modified to insert instructions for mounting the read-only image and starting the interactive shell before the makedumpfile startup instructions. When the kernel crashes and triggers the kdump mechanism, the Kdump capture kernel is started. The Kdump capture kernel initializes the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. The Kdump capture kernel probes the disk boot partition, mounts the read-only image to a temporary mount directory by executing the instruction to mount the read-only image, and starts a pre-boot program in the interactive shell based on the instructions in the interactive shell. A countdown timer is set, and terminal interrupt signals are monitored during the countdown period. When a terminal interrupt signal is detected within the preset countdown time, the first Build-ID information of the vmlinux kernel file in the read-only image is extracted, and the second Build-ID information of the crashed kernel is obtained from the vmcore accessible to the captured kernel. The first Build-ID information and the second Build-ID information are compared. If the comparison is successful, a makedumpfile memory dump operation is performed. The NT_VMCOREINFO segment in the vmcore is parsed, and the stext, KERNELOFFSET, and PAGE_SIZE kernel runtime parameters are extracted. The user-selected program is run, and the extracted kernel runtime parameters are used in conjunction with vmlinux and vmcore to perform in-situ fault analysis. Using the above method, key kernel runtime parameters can be obtained in-situ at the crash site. Kernel fault analysis can be performed directly with the pre-built debugging program in conjunction with vmlinux and vmcore without exporting a complete memory dump file first, thus shortening the kernel crash problem localization cycle.

[0040] Example 3 Figure 3 This is a schematic diagram of the structure of the Kdump online debugging device for kernel crash scenarios provided in Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the device includes: Insert the mount module 310, which is used to package the vmlinux kernel file into a read-only image and store the read-only image in the disk boot partition. Modify the kdump-capture.service service configuration and insert the command to mount the read-only image and the command to start the interactive shell before the makedumpfile startup command. The initialization module 320 is used to start Kdump to capture the kernel when the kernel crashes and triggers the kdump mechanism. Kdump captures the kernel to initialize the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. The signal detection module 330 is used to capture the kernel probe disk boot partition by Kdump. By executing the instruction to mount the read-only image, it mounts the read-only image to the temporary mount directory. Based on the instructions of the interactive shell, it starts a preset countdown in the interactive shell and monitors the terminal interrupt signal during the countdown period. The memory dump module 340 is used to extract the first Build-ID information of the vmlinux kernel file in the read-only image when a terminal interrupt signal is detected within a preset countdown time, and to obtain the second Build-ID information of the crashed kernel from the vmcore accessible to the captured kernel. The first Build-ID information and the second Build-ID information are compared. After the comparison is successful, the makedumpfile memory dump operation is executed.

[0041] The Kdump online debugging device for kernel crash scenarios provided in this embodiment packages the vmlinux kernel file into a read-only image, stores the read-only image in the disk boot partition, modifies the kdump-capture.service service configuration, and inserts instructions to mount the read-only image and start the interactive shell before the makedumpfile startup instruction. When the kernel crashes and triggers the kdump mechanism, the Kdump capture kernel is started. The Kdump capture kernel initializes the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. The Kdump capture kernel probes the disk boot partition. By executing the command to mount a read-only image, the read-only image is mounted to a temporary mount directory. Based on commands in the interactive shell, a preset countdown timer is started within the interactive shell, monitoring for terminal interrupt signals during the countdown period. When a terminal interrupt signal is detected within the preset countdown, the first Build-ID information of the vmlinux kernel file in the read-only image is extracted, and the second Build-ID information of the crashed kernel is obtained from the vmcore accessible to the captured kernel. The first and second Build-ID information are compared, and if the comparison is successful, a makedumpfile memory dump operation is executed. Through this entire process—pre-building a debug image, intercepting the dump execution flow to build an interactive terminal, intercepting user operations during the crash countdown, and pre-verifying kernel identifiers—the system achieves in-situ online debugging during the kernel crash phase, pre-verification of kernel image compatibility, and flexible control over the memory dump process.

[0042] Based on the above embodiments, the insertion and mounting module includes: The extraction and packaging unit is used to extract the vmlinux kernel file from the kernel debug symbol directory or the kernel compilation output directory, package the vmlinux kernel file and user-selected programs into a read-only image in SquashFS format, and store the packaged read-only image to the disk boot partition.

[0043] Based on the above embodiments, the initialization module includes: The terminal interaction initialization unit is used to start kdump to capture the kernel when the kernel crashes and triggers the kdump mechanism. The kdump capture kernel receives the CPU control handed over after the kernel crashes through kexec, loads and mounts the initramfs root file system, initializes the UART serial port driver, and provides terminal interaction for the interactive shell through the serial port driver.

[0044] Based on the above embodiments, the signal detection module includes: The detection and mounting unit is used by Kdump to capture the kernel's detection disk boot partition. By executing the instruction to mount the read-only image, it uses the Loop device to mount the read-only image to the temporary mount directory. The countdown start unit is used to start a preset countdown based on the kernel HZ clock, using instructions from the interactive shell, and to monitor terminal interrupt signals during the countdown period.

[0045] Based on the above embodiments, the memory dump module includes: The ID information extraction unit is used to extract the first Build-ID information of the vmlinux kernel file in the read-only image, and to read the second Build-ID information of the crashed kernel from the PT_NOTE or VMCOREINFO of the ELF dump corresponding to the captured kernel accessible to the vmcore.

[0046] The Kdump online debugging device for kernel crash scenarios provided in the embodiments of the present invention can execute the Kdump online debugging method for kernel crash scenarios provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0047] Example 4 Figure 4 This is a schematic diagram of the structure of a terminal provided in Embodiment 4 of the present invention. Figure 4 A block diagram is shown that is suitable for implementing an exemplary terminal 12 of the present invention. Figure 4 The terminal 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0048] like Figure 4As shown, terminal 12 is presented in the form of a general-purpose computing terminal. The components of terminal 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0049] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0050] Terminal 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by terminal 12, including volatile and non-volatile media, removable and non-removable media.

[0051] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Terminal 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0052] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0053] Terminal 12 can also communicate with one or more external terminals 14 (e.g., keyboard, pointing terminal, display 24, etc.), one or more terminals that enable a user to interact with terminal 12, and / or any terminal (e.g., network card, modem, etc.) that enables terminal 12 to communicate with one or more other computing terminals. This communication can be performed via input / output (I / O) interface 22. Furthermore, terminal 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of terminal 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with terminal 12, including but not limited to: microcode, terminal drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0054] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the Kdump online debugging method in the kernel crash scenario provided in the embodiments of the present invention.

[0055] Example 5 Embodiment 5 of the present invention also provides a medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the Kdump online debugging method in any of the kernel crash scenarios provided in the above embodiments.

[0056] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0057] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0058] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0059] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or device. In cases involving a remote computer, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0060] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A Kdump online debugging method for kernel crash scenarios, characterized in that, include: Package the vmlinux kernel file to generate a read-only image, store the read-only image in the disk boot partition, modify the kdump-capture.service service configuration, and insert the command to mount the read-only image and the command to start the interactive shell before the makedumpfile startup command; When the kernel crashes and triggers the kdump mechanism, Kdump is started to capture the kernel. Kdump captures the kernel to initialize the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. Kdump captures kernel probes of disk boot partitions, mounts read-only images to temporary mount directories by executing commands to mount read-only images, and starts a preset countdown in the interactive shell based on commands, monitoring terminal interrupt signals during the countdown period; When a terminal interrupt signal is detected within the preset countdown time, the first Build-ID information of the vmlinux kernel file in the read-only image is extracted, and the second Build-ID information of the crashed kernel is obtained from the vmcore accessible by the captured kernel. The first Build-ID information and the second Build-ID information are compared. After the comparison is successful, the makedumpfile memory dump operation is executed.

2. The method according to claim 1, characterized in that, The process of packaging the vmlinux kernel file into a read-only image and storing the read-only image to the disk boot partition also includes: Extract the vmlinux kernel file from the kernel debug symbol directory or the kernel compilation output directory, package the vmlinux kernel file and user-selected programs into a read-only image in SquashFS format, and store the packaged read-only image into the disk boot partition.

3. The method according to claim 1, characterized in that, When the kernel crashes and triggers the kdump mechanism, Kdump is started to capture the kernel. The Kdump kernel initializes the serial port driver and provides terminal interaction for the interactive shell through the serial port driver, including: When the kernel crashes and triggers the kdump mechanism, kdump is started via kexec to capture the kernel. The kernel captured by kdump takes over the CPU control handed over after the kernel crashes via kexec, loads and mounts the initramfs root file system, initializes the UART serial port driver, and provides terminal interaction for the interactive shell through the serial port driver.

4. The method according to claim 1, characterized in that, The Kdump captures kernel probes of the disk boot partition, mounts the read-only image to a temporary mount directory by executing instructions to mount the read-only image, and starts a preset countdown in the interactive shell based on instructions. During the countdown period, it monitors terminal interrupt signals, including: Kdump captures the kernel probing the disk boot partition and executes the command to mount the read-only image, using the Loop device to mount the read-only image to a temporary mount directory. The system uses interactive shell commands to start a preset countdown based on the kernel's HZ clock, and monitors terminal interrupt signals during the countdown period.

5. The method according to claim 1, characterized in that, The method further includes the following steps: Kdump captures the kernel's probe disk boot partition, mounts the read-only image to a temporary mount directory by executing a command to mount the read-only image, and starts a preset countdown in the interactive shell based on the interactive shell command, monitoring the terminal interrupt signal during the countdown period. If no terminal interrupt signal is detected within the preset countdown time, execute the makedumpfile memory dump operation.

6. The method according to claim 1, characterized in that, The step of extracting the first Build-ID information of the vmlinux kernel file in the read-only image and obtaining the second Build-ID information of the crashed kernel from the vmcore accessible to the captured kernel includes: Extract the first Build-ID information of the vmlinux kernel file in the read-only image, and read the second Build-ID information of the crashed kernel from the PT_NOTE or VMCOREINFO of the ELF dump corresponding to the captured kernel accessible to the vmcore.

7. The method according to claim 2, characterized in that, After the comparison passes and the makedumpfile memory dump operation is executed, the process further includes: Parse the NT_VMCOREINFO segment within the vmcore to extract the kernel runtime parameters stext, KERNELOFFSET, and PAGE_SIZE. Run the user-selected program and use the extracted kernel runtime parameters in conjunction with vmlinux and vmcore to perform in-situ fault analysis.

8. A Kdump online debugging device for kernel crash scenarios, characterized in that, include: Insert a mount module to package the vmlinux kernel file into a read-only image and store the read-only image in the disk boot partition. Modify the kdump-capture.service service configuration to insert the command to mount the read-only image and the command to start the interactive shell before the makedumpfile startup command. The initialization module is used to start Kdump to capture the kernel when the kernel crashes and triggers the kdump mechanism. Kdump captures the kernel to initialize the serial port driver and provides terminal interaction for the interactive shell through the serial port driver. The signal detection module is used by Kdump to capture kernel probe disk boot partitions. By executing the command to mount the read-only image, it mounts the read-only image to a temporary mount directory. Based on the commands in the interactive shell, it starts a preset countdown in the interactive shell and monitors terminal interrupt signals during the countdown period. The memory dump module is used to extract the first Build-ID information of the vmlinux kernel file in the read-only image when a terminal interrupt signal is detected within a preset countdown time, and to obtain the second Build-ID information of the crashed kernel from the vmcore that the kernel can access. The first Build-ID information and the second Build-ID information are compared. If the comparison is successful, the makedumpfile memory dump operation is executed.

9. A terminal, characterized in that, The terminal includes: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the Kdump online debugging method for kernel crash scenarios as described in any one of claims 1-7.

10. A medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the Kdump online debugging method for kernel crash scenarios as described in any one of claims 1-7.

Images