{"id":5558,"date":"2026-09-21T12:18:59","date_gmt":"2026-09-21T09:18:59","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5558"},"modified":"2026-09-21T06:25:52","modified_gmt":"2026-09-21T03:25:52","slug":"linux-kernel-panic-recovery","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/linux-kernel-panic-recovery\/","title":{"rendered":"Server Kernel Panic: Root-Cause Analysis and Recovery"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div class=\"aiw-summary\">\n<p class=\"aiw-box-title\">Quick summary<\/p>\n<p>If your server restarts unexpectedly, SSH stops responding and services fail to start, collect console evidence before attempting a reinstall. Linux kernel panic recovery starts with identifying the failing layer, then applying the narrowest safe fix.<\/p>\n<ul>\n<li>Record the kernel panic screen and restart time before changing or rebuilding the system.<\/li>\n<li>Use your provider&#8217;s console, BMC\/iKVM interface or physical display instead of SSH.<\/li>\n<li>Try the previous kernel to isolate a faulty kernel update, initramfs or third-party module.<\/li>\n<li>Review journal, kdump, pstore, hardware and storage evidence together rather than relying on one log line.<\/li>\n<li>Take a snapshot or verified backup before data-changing work, then verify boot and critical services afterward.<\/li>\n<\/ul>\n<\/div>\n<p>If your VPS or physical server suddenly restarted and SSH no longer accepts connections, your first task is not to restart services at random. Determine which stage of the system has stopped. Messages such as <code>Kernel panic<\/code>, <code>Unable to mount root fs<\/code> or <code>Out of memory<\/code> can indicate that Linux stopped or became unable to continue safely.<\/p>\n<p>A kernel panic is a critical condition, not a root cause. An incompatible module, damaged file system, inaccessible root disk, faulty memory, firmware problem, bad kernel update or virtualization-layer fault can produce similar symptoms. Effective Linux kernel panic recovery is therefore a controlled diagnostic process rather than a single command.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#How_to_recognize_a_kernel_panic\"><span class=\"toc_number toc_depth_1\">1.<\/span> How to recognize a kernel panic<\/a><\/li><li><a href=\"#Secure_access_and_evidence_first\"><span class=\"toc_number toc_depth_1\">2.<\/span> Secure access and evidence first<\/a><ul><li><a href=\"#Use_console_access\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> Use console access<\/a><\/li><li><a href=\"#Build_an_event_timeline\"><span class=\"toc_number toc_depth_2\">2.2.<\/span> Build an event timeline<\/a><\/li><\/ul><\/li><li><a href=\"#Inspect_logs_after_the_server_boots\"><span class=\"toc_number toc_depth_1\">3.<\/span> Inspect logs after the server boots<\/a><ul><li><a href=\"#Separate_kernel_storage_and_memory_evidence\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> Separate kernel, storage and memory evidence<\/a><\/li><\/ul><\/li><li><a href=\"#Use_the_lowest-risk_recovery_options\"><span class=\"toc_number toc_depth_1\">4.<\/span> Use the lowest-risk recovery options<\/a><ul><li><a href=\"#Try_the_previous_kernel_first\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> Try the previous kernel first<\/a><\/li><li><a href=\"#Inspect_the_root_disk_from_rescue_or_live_media\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> Inspect the root disk from rescue or live media<\/a><\/li><li><a href=\"#Rebuild_the_kernel_package_and_initramfs\"><span class=\"toc_number toc_depth_2\">4.3.<\/span> Rebuild the kernel package and initramfs<\/a><\/li><\/ul><\/li><li><a href=\"#Classify_the_likely_root_cause\"><span class=\"toc_number toc_depth_1\">5.<\/span> Classify the likely root cause<\/a><ul><li><a href=\"#Kernel_update_or_third-party_module\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> Kernel update or third-party module<\/a><\/li><li><a href=\"#File_system_disk_or_RAID_problem\"><span class=\"toc_number toc_depth_2\">5.2.<\/span> File system, disk or RAID problem<\/a><\/li><li><a href=\"#Memory_CPU_and_firmware\"><span class=\"toc_number toc_depth_2\">5.3.<\/span> Memory, CPU and firmware<\/a><\/li><li><a href=\"#Do_not_confuse_OOM_with_a_kernel_panic\"><span class=\"toc_number toc_depth_2\">5.4.<\/span> Do not confuse OOM with a kernel panic<\/a><\/li><\/ul><\/li><li><a href=\"#Capture_the_next_event_with_kdump_and_pstore\"><span class=\"toc_number toc_depth_1\">6.<\/span> Capture the next event with kdump and pstore<\/a><\/li><li><a href=\"#Verify_the_system_after_the_change\"><span class=\"toc_number toc_depth_1\">7.<\/span> Verify the system after the change<\/a><\/li><li><a href=\"#Frequently_Asked_Questions\"><span class=\"toc_number toc_depth_1\">8.<\/span> Frequently Asked Questions<\/a><ul><li><a href=\"#Does_a_kernel_panic_delete_data_from_the_server\"><span class=\"toc_number toc_depth_2\">8.1.<\/span> Does a kernel panic delete data from the server?<\/a><\/li><li><a href=\"#What_if_the_server_restarts_but_no_panic_appears_on_screen\"><span class=\"toc_number toc_depth_2\">8.2.<\/span> What if the server restarts but no panic appears on screen?<\/a><\/li><li><a href=\"#Should_you_remove_the_new_kernel_if_the_old_one_works\"><span class=\"toc_number toc_depth_2\">8.3.<\/span> Should you remove the new kernel if the old one works?<\/a><\/li><li><a href=\"#Is_a_kernel_panic_the_same_as_an_application8217s_blank_page\"><span class=\"toc_number toc_depth_2\">8.4.<\/span> Is a kernel panic the same as an application&#8217;s blank page?<\/a><\/li><\/ul><\/li><li><a href=\"#Action_checklist\"><span class=\"toc_number toc_depth_1\">9.<\/span> Action checklist<\/a><\/li><\/ul><\/div>\n<h2><span id=\"How_to_recognize_a_kernel_panic\">How to recognize a kernel panic<\/span><\/h2>\n<p>With a normal application failure, one process exits while the rest of the operating system continues running. During a kernel panic, the kernel may stop the system because it cannot continue safely. Depending on the configuration, the server may display an error, restart automatically or appear frozen.<\/p>\n<p>Common observable signs include:<\/p>\n<ul>\n<li>SSH and other network services become unreachable at the same time.<\/li>\n<li>Monitoring reports repeated restarts within a short period.<\/li>\n<li>The provider console shows <code>kernel panic<\/code>, a stack trace or <code>not syncing<\/code>.<\/li>\n<li>After a restart, the root file system cannot be mounted or the server enters an emergency shell.<\/li>\n<li>The machine boots only with a particular kernel version or fails again under load.<\/li>\n<\/ul>\n<p>An SSH outage alone does not prove a kernel panic. Network configuration, a firewall, a full disk, a stuck service or a provider-side virtual machine event can create the same external symptom. Capture the console output and note the restart time in the provider panel before deciding which layer is responsible.<\/p>\n<h2><span id=\"Secure_access_and_evidence_first\">Secure access and evidence first<\/span><\/h2>\n<h3><span id=\"Use_console_access\">Use console access<\/span><\/h3>\n<p>When SSH is unavailable, connect through a web console, virtual serial console, KVM, iKVM or physical display. These methods do not depend on the operating system&#8217;s network services, so they let you continue investigating. If you use a VPS, confirm how the provider console is enabled and how to save its screen output.<\/p>\n<p>Record the complete panic message before taking other action. Pay particular attention to <code>Call Trace<\/code>, <code>RIP<\/code>, <code>Oops<\/code>, module names, disk devices, UUIDs, file systems and the kernel version. A module shown in one line is not always the definite cause; it may be the last component visible in the call chain.<\/p>\n<div class=\"aiw-note aiw-note-warning\">\n<p class=\"aiw-box-title\">Caution<\/p>\n<p>Reinstalling the system, removing the old kernel or running broad cleanup commands before collecting evidence can hide the root cause. Save a screenshot, the event time and the current disk state first.<\/p>\n<\/div>\n<h3><span id=\"Build_an_event_timeline\">Build an event timeline<\/span><\/h3>\n<p>Compare the following information across the same time period:<\/p>\n<ul>\n<li>The first time access was lost, including the time zone.<\/li>\n<li>Power-cycle, migration, maintenance or virtual machine events in the provider panel.<\/li>\n<li>The latest kernel, firmware, driver, storage or security update.<\/li>\n<li>Unusual changes in traffic, disk usage, memory consumption or temperature.<\/li>\n<li>Scheduled cron jobs, backups, large file operations or intensive build processes.<\/li>\n<\/ul>\n<p>This timeline can distinguish a boot failure that began immediately after a kernel update from a memory fault that appears only after sustained load. If the system can boot again, export the basic records before making changes.<\/p>\n<h2><span id=\"Inspect_logs_after_the_server_boots\">Inspect logs after the server boots<\/span><\/h2>\n<p>If the server starts with an older kernel or a temporary recovery option, search first for records from the failed boot. The following commands require a systemd-based Linux installation for <code>journalctl<\/code>; run them from the affected system after it boots or from an appropriate mounted environment.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">journalctl --list-boots\njournalctl -b -1 -k --no-pager\njournalctl -b -1 -p err..alert --no-pager\nuname -a\ncat \/proc\/cmdline<\/code><\/pre>\n<p><code>-b -1<\/code> selects the previous boot, <code>-k<\/code> selects kernel messages and <code>-p err..alert<\/code> selects errors and higher-priority messages. If the previous boot does not appear, do not interpret that as evidence that nothing went wrong. Persistent storage may not be configured, or the panic may have been written only to the console.<\/p>\n<p>Check whether the current system has a persistent journal:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">test -d \/var\/log\/journal &amp;&amp; echo &quot;Persistent journal directory exists&quot; || echo &quot;Persistent journal directory does not exist&quot;\nfindmnt \/var\nfindmnt \/<\/code><\/pre>\n<p>These commands only inspect the current state. Enabling journal persistence later can help with future incidents, but it cannot restore records that have already been lost. If you change the configuration, check your distribution&#8217;s systemd version, available disk space and log-retention policy first.<\/p>\n<h3><span id=\"Separate_kernel_storage_and_memory_evidence\">Separate kernel, storage and memory evidence<\/span><\/h3>\n<p>Messages such as <code>BUG:<\/code>, <code>Oops:<\/code>, <code>Call Trace:<\/code> or a specific module name may point to the kernel or driver layer. Messages containing <code>I\/O error<\/code>, <code>ata<\/code>, <code>nvme<\/code>, <code>EXT4-fs error<\/code>, <code>XFS<\/code> or <code>buffer I\/O<\/code> require storage investigation. <code>Out of memory<\/code> and OOM records usually indicate that Linux terminated processes because of memory pressure; they are not always kernel panics.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dmesg -T --level=emerg,alert,crit,err,warn\njournalctl -k -b 0 --no-pager | grep -Ei &#039;panic|oops|call trace|oom|io error|nvme|ata|ext4|xfs|mce|edac&#039;<\/code><\/pre>\n<p><code>dmesg<\/code> displays kernel messages. Some systems require root access because of message restrictions. Filtering the output can speed up diagnosis, but do not disregard lines that the filter does not show. If an error identifies a hardware device, also request the provider&#8217;s disk and virtualization records.<\/p>\n<h2><span id=\"Use_the_lowest-risk_recovery_options\">Use the lowest-risk recovery options<\/span><\/h2>\n<h3><span id=\"Try_the_previous_kernel_first\">Try the previous kernel first<\/span><\/h3>\n<p>If the problem began after the latest update, select an older kernel under <em>Advanced options<\/em> in the GRUB menu. If the server boots, verify the root file system, network and essential services. Do not remove the working kernel immediately.<\/p>\n<p>This test suggests that the kernel package or initramfs may be involved, but it does not completely rule out a hardware fault. If the server also panics under load with the older kernel, investigate memory, storage, firmware and the virtualization layer separately.<\/p>\n<div class=\"aiw-note aiw-note-example\">\n<p class=\"aiw-box-title\">Example scenario<\/p>\n<p>Assume a VPS fails to boot only with its newest kernel, while the previous kernel starts and its network and disk services work. This does not prove that the kernel package is defective, but it provides a relatively safe way to isolate the new version, its initramfs or a third-party module. Compare logs from both boots before making a permanent change.<\/p>\n<\/div>\n<h3><span id=\"Inspect_the_root_disk_from_rescue_or_live_media\">Inspect the root disk from rescue or live media<\/span><\/h3>\n<p>If no kernel boots, use the provider&#8217;s rescue environment or a distribution live environment. The purpose is not to repair the system blindly. First verify that the root partition is visible, that the file system can be examined and that important data can be copied.<\/p>\n<p>Identify devices and mount points first. The following commands are for discovery only. They require the corresponding rescue tools, and the device names must be confirmed from the output:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">lsblk -f\nblkid\nfindmnt\nsmartctl -a \/dev\/sdX<\/code><\/pre>\n<p><code>smartctl<\/code> can provide useful information on physical hardware, but its output may be limited or meaningless for virtual disks. Replace the <code>\/dev\/sdX<\/code> placeholder with the real device name before running the command. Also check any health information the provider offers for the virtual disk infrastructure. Before checking or repairing a file system, unmount the relevant partition and, where possible, take a provider snapshot or confirm a usable backup.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">umount \/dev\/mapper\/vg-root\nfsck -f \/dev\/mapper\/vg-root<\/code><\/pre>\n<p>These commands are examples and device names vary. Run <code>fsck<\/code> only against the confirmed, unmounted target after preserving data and recording the current storage layout. LVM, RAID, encrypted disks and XFS require the relevant layers and native tools in the correct order; XFS, for example, uses its own repair utility rather than the generic <code>fsck<\/code> workflow. Running a repair command on the wrong partition can cause data loss. After repair, remount the file system and verify that essential files can be read.<\/p>\n<h3><span id=\"Rebuild_the_kernel_package_and_initramfs\">Rebuild the kernel package and initramfs<\/span><\/h3>\n<p>On a system that runs with an older kernel, check the package database, free disk space and the boot partition. A full boot partition can leave a new kernel package apparently installed while its initramfs was not completed.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">df -h\nfindmnt \/boot\nls -lh \/boot<\/code><\/pre>\n<p>Without knowing the distribution and package manager, giving one reinstall command would be unsafe. On Debian or Ubuntu-based systems, use APT to verify and reinstall the relevant kernel package. On AlmaLinux, Rocky or RHEL-based systems, use DNF and the appropriate initramfs tools. First record the running kernel, package name and distribution version:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">cat \/etc\/os-release\nrpm -q kernel 2&gt;\/dev\/null || dpkg-query -W &#039;linux-image*&#039; 2&gt;\/dev\/null<\/code><\/pre>\n<p>Take a backup or snapshot before reinstalling official distribution packages and record the currently working kernel as the rollback option. If you use a third-party kernel module, inspect its DKMS build status separately. A module that was not built for the new kernel can prevent boot. After rebuilding, confirm that the initramfs file exists in the boot partition and that the boot menu recognizes the relevant version.<\/p>\n<h2><span id=\"Classify_the_likely_root_cause\">Classify the likely root cause<\/span><\/h2>\n<h3><span id=\"Kernel_update_or_third-party_module\">Kernel update or third-party module<\/span><\/h3>\n<p>If the panic started immediately after a kernel update, use the older-kernel boot test, verify the package and initramfs, and then review module records. Kernel modules for graphics, storage, security or virtualization can be affected by version changes. A module name in the error does not mean you should delete it immediately. First record the package and DKMS state.<\/p>\n<p>Apply only the fix associated with the identified package or return to a compatible vendor version. Do not change multiple kernel parameters at once. After each change, perform one controlled boot, compare logs and check application services.<\/p>\n<h3><span id=\"File_system_disk_or_RAID_problem\">File system, disk or RAID problem<\/span><\/h3>\n<p>If the root partition cannot be mounted, the panic may be a boot failure in which the kernel is running but cannot access the essential file system. A changed UUID, damaged superblock, disk connection problem, degraded RAID or file-system inconsistency may be responsible. Check <code>\/etc\/fstab<\/code>, the initramfs contents and boot parameters together.<\/p>\n<p>If hardware errors recur, repairing the file system alone is not a lasting solution. Copy data to another environment as soon as possible, verify RAID status and disk health, and arrange replacement with the provider or hardware administrator for a physical server.<\/p>\n<h3><span id=\"Memory_CPU_and_firmware\">Memory, CPU and firmware<\/span><\/h3>\n<p><code>MCE<\/code>, <code>EDAC<\/code>, corrected ECC errors, unrelated kernel traces on different incidents or crashes that recur under load increase the likelihood of a hardware problem. In a VPS, these signs may relate to the physical host, virtualization layer or resource allocation. On a physical server, inspect vendor diagnostics, ECC counters, temperature and firmware versions.<\/p>\n<p>Firmware updates carry data and boot risks. Prepare a backup, maintenance window and rollback plan first. Do not change the kernel, firmware and driver at the same time, because isolating the effective change becomes difficult.<\/p>\n<h3><span id=\"Do_not_confuse_OOM_with_a_kernel_panic\">Do not confuse OOM with a kernel panic<\/span><\/h3>\n<p>When memory is exhausted, the Linux OOM killer may terminate selected processes. A website, database or PHP process can stop while the kernel continues running. Search <code>journalctl<\/code> for <code>Out of memory<\/code>, <code>Killed process<\/code> and cgroup information. After reviewing swap, application limits and per-process memory use, consider a resource increase or application change.<\/p>\n<p>Also distinguish PHP-FPM web workers from CLI cron or queue workers. A CLI job that does not make an HTTP request does not consume a PHP-FPM web worker. It can still consume the server&#8217;s total memory and contribute to an OOM event. This distinction helps you avoid reconfiguring the wrong service.<\/p>\n<h2><span id=\"Capture_the_next_event_with_kdump_and_pstore\">Capture the next event with kdump and pstore<\/span><\/h2>\n<p>Normal disk writes may not finish after a panic. <code>kdump<\/code> starts a reserved crash kernel to collect a memory dump. <code>pstore<\/code> can preserve some kernel messages across a restart when the firmware or hardware supports it. These are tools for future diagnosis, not recovery mechanisms for a panic that already occurred.<\/p>\n<p>Before enabling kdump, verify your distribution&#8217;s package, kernel version, reserved-memory requirement and available space at the dump target. Crash dumps can contain sensitive memory contents, so define access permissions and retention rules. If kdump was not enabled before the previous panic, it cannot create a retroactive dump.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">systemctl status kdump 2&gt;\/dev\/null || true\nls -la \/var\/crash 2&gt;\/dev\/null || true\nmount | grep -E &#039;pstore|ramoops&#039; || true<\/code><\/pre>\n<p>These commands only show the current state. Apply kdump configuration together with the distribution&#8217;s documented kernel parameters and dump target. Do not add an arbitrary <code>crashkernel<\/code> value to a production server. A controlled panic test should be attempted only during a maintenance window, with a backup and an accepted service interruption.<\/p>\n<h2><span id=\"Verify_the_system_after_the_change\">Verify the system after the change<\/span><\/h2>\n<p>SSH access alone does not prove that the problem is solved. Verify the system in this order:<\/p>\n<ol>\n<li>Record the running kernel and boot time with <code>uname -r<\/code> and <code>uptime -s<\/code>.<\/li>\n<li>Check the latest boot for new panic, Oops, I\/O or file-system errors.<\/li>\n<li>Confirm that the root and boot partitions have free space.<\/li>\n<li>Test the network interface, DNS resolution and firewall.<\/li>\n<li>Check the database, web server, PHP-FPM, queue workers and scheduled jobs separately.<\/li>\n<li>Run a simple read test through the application and, where necessary, a controlled write test.<\/li>\n<li>Confirm that restart, latency, disk and memory alerts have returned to normal.<\/li>\n<\/ol>\n<p>Before making the newest kernel the permanent default, plan at least one controlled restart. Keep the older working kernel installed long enough to provide a rollback path. If you clean up packages, decide in advance which version will remain available as the recovery option.<\/p>\n<p>For repeated incidents, prepare a post-event record containing the symptoms, time, last change, kernel, relevant log excerpts, corrective action and verification result. A clear <a href=\"https:\/\/www.dchost.com\/blog\/en\/patch-management-for-linux-servers-and-web-apps-finding-the-right-balance\/\">patch management approach<\/a> can help you plan kernel updates with testing and rollback steps before production deployment.<\/p>\n<p>If more than one disk or host layer is affected, a fix on one server may not be enough. Run <a href=\"https:\/\/www.dchost.com\/blog\/en\/rpo-rto-and-disaster-recovery-planning-for-small-businesses\/\">disaster recovery drills<\/a> regularly to verify that backups can actually be restored, console access is available and your recovery time objective is practical.<\/p>\n<h2><span id=\"Frequently_Asked_Questions\">Frequently Asked Questions<\/span><\/h2>\n<h3><span id=\"Does_a_kernel_panic_delete_data_from_the_server\">Does a kernel panic delete data from the server?<\/span><\/h3>\n<p>A kernel panic does not delete data by itself, but an interrupted write can cause file-system inconsistency or loss of the latest operation. Check the backup and disk state before continuing a restart loop.<\/p>\n<h3><span id=\"What_if_the_server_restarts_but_no_panic_appears_on_screen\">What if the server restarts but no panic appears on screen?<\/span><\/h3>\n<p>Review provider power and hypervisor records, watchdog events and physical hardware alerts. Automatic restart may hide the panic screen. Persistent console logging, kdump or pstore can provide evidence during a future event.<\/p>\n<h3><span id=\"Should_you_remove_the_new_kernel_if_the_old_one_works\">Should you remove the new kernel if the old one works?<\/span><\/h3>\n<p>Not immediately. Inspect the new kernel package, initramfs, third-party modules and boot space first. Keeping a rollback path is safer while you repair or replace the affected version.<\/p>\n<h3><span id=\"Is_a_kernel_panic_the_same_as_an_application8217s_blank_page\">Is a kernel panic the same as an application&#8217;s blank page?<\/span><\/h3>\n<p>No. A blank page usually belongs to the application, PHP, theme, plugin or web-server layer. A kernel panic is a critical stop in the operating system kernel. Use console and SSH access to identify the affected layer.<\/p>\n<h2><span id=\"Action_checklist\">Action checklist<\/span><\/h2>\n<ul>\n<li>Open console access and save the panic screen.<\/li>\n<li>Match the restart time with recent changes and provider events.<\/li>\n<li>Try the working or previous kernel without removing the working version.<\/li>\n<li>Review <code>journalctl<\/code>, <code>dmesg<\/code>, disk, file-system, memory and hardware evidence together.<\/li>\n<li>Prepare a snapshot or verified backup and rollback step before changing anything.<\/li>\n<li>Apply a narrowly targeted fix to the identified layer.<\/li>\n<li>Verify boot, critical services, disk state and monitoring alerts.<\/li>\n<li>Plan persistent journal, kdump and pstore options for recurring incidents.<\/li>\n<\/ul>\n<p>Your next step is to access the server through its console and save the latest panic output together with <code>journalctl -b -1 -k<\/code>. These two pieces of evidence help you choose the right recovery path before attempting an irreversible action such as a reinstall.<\/p>\n<p>Emre<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>A practical process for diagnosing Linux kernel panic on VPS and physical servers, collecting evidence, recovering safely and verifying services after reboot.<\/p>\n","protected":false},"author":4,"featured_media":5555,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[182],"tags":[572,60,575,577,576],"class_list":["post-5558","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server","tag-kernel-panic","tag-linux","tag-server-recovery","tag-system-administration","tag-vps-troubleshooting"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5558","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5558"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5558\/revisions"}],"predecessor-version":[{"id":5560,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5558\/revisions\/5560"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5555"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5558"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5558"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5558"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}