Bug 1876589
Summary: | Crash utility cannot analyse a core dump image from virsh | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kappa <commodorekappa+redhat> |
Component: | crash | Assignee: | lijiang |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | jieli, lijiang, ruqin, xiawu |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | crash-7.3.0-1.fc35 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-06-17 01:48:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Kappa
2020-09-07 16:20:13 UTC
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Crash can not still work on the latest Fedora vmcore from "virsh dump". It reported a failure of initialization and eventually failed on the "qemu_load()". So reopen this issue and move it to rawhide. Thanks. Hi, Emma, Ruowen and Kappa It doesn't support to analyze a vmcore dumped by "virsh dump domain file", the vmcore must be dumped with option "--memory-only", otherwise it will fail to analyze vmcore. Important The crash utility no longer supports the default core dump file format of the virsh dump command. If you use crash to analyze a core dump file created by virsh dump, you must use the --memory-only option. Here is a documentation link: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-domain_commands-creating_a_dump_file_of_a_domains_core Thanks. Hi, Kappa Would you mind trying it again with the following command? I didn't see this issue on the latest crash-utility. # virsh dump fedora34 /tmp/vmcore --memory-only --format=kdump-lzo Domain 'fedora34' dumped to /tmp/vmcore # crash /usr/lib/debug/usr/lib/modules/5.12.9-300.fc34.x86_64/vmlinux /tmp/vmcore crash 7.3.0-1.fc34 Copyright (C) 2002-2021 Red Hat, Inc. Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005, 2011, 2020-2021 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... WARNING: kernel relocated [192MB]: patching 134298 gdb minimal_symbol values KERNEL: /usr/lib/debug/usr/lib/modules/5.12.9-300.fc34.x86_64/vmlinux DUMPFILE: /tmp/vmcore [PARTIAL DUMP] CPUS: 4 DATE: Tue Jun 15 05:24:18 EDT 2021 UPTIME: 00:31:45 LOAD AVERAGE: 0.00, 0.00, 0.00 TASKS: 175 NODENAME: fedora RELEASE: 5.12.9-300.fc34.x86_64 VERSION: #1 SMP Thu Jun 3 13:51:40 UTC 2021 MACHINE: x86_64 (2499 Mhz) MEMORY: 8 GB PANIC: "" PID: 0 COMMAND: "swapper/0" TASK: ffffffff8ea1a940 (1 of 4) [THREAD_INFO: ffffffff8ea1a940] CPU: 0 STATE: TASK_RUNNING (ACTIVE) WARNING: panic task not found crash> bt PID: 0 TASK: ffffffff8ea1a940 CPU: 0 COMMAND: "swapper/0" [exception RIP: native_safe_halt+14] RIP: ffffffff8dbf6e5e RSP: ffffffff8ea03eb0 RFLAGS: 00000206 RAX: ffffffff8dbf6d00 RBX: 0000000000000000 RCX: ffff99e7b7c2b180 RDX: 0000000000000000 RSI: 0000000000000083 RDI: 0000000000000000 RBP: ffffffff8ea1a940 R8: 000001beef6153db R9: 0000000000000004 R10: 0000000000000a08 R11: 0000000000000cb5 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000008e R15: 000000000026b508 CS: 0010 SS: 0018 #0 [ffffffff8ea03eb0] default_idle at ffffffff8dbf6d0a #1 [ffffffff8ea03eb8] default_idle_call at ffffffff8dbf6f78 #2 [ffffffff8ea03ec0] do_idle at ffffffff8d114d00 #3 [ffffffff8ea03ef8] cpu_startup_entry at ffffffff8d114f09 #4 [ffffffff8ea03f08] start_kernel at ffffffff8f258631 #5 [ffffffff8ea03f50] secondary_startup_64_no_verify at ffffffff8d000107 crash> kmem -s CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME ffff99e646013a00 216 0 0 0 4k nf_conntrack_expect ffff99e646013000 256 48 125 5 8k nf_conntrack ffff99e64a5b5500 184 0 0 0 4k nf-frags ffff99e64a5b5b00 640 22 23 1 16k rpc_inode_cache ffff99e6462c3500 2048 15 16 1 32k rpc_buffers ffff99e6462c3b00 232 15 16 1 4k rpc_tasks ffff99e649d35e00 736 42 44 2 16k fat_inode_cache ffff99e649d35100 32 0 0 0 4k fat_cache ffff99e647b09000 136 0 0 0 4k kvm_async_pf ffff99e647b09f00 9728 0 0 0 32k kvm_vcpu ffff99e647b09d00 184 0 0 0 4k kvm_mmu_page_header ffff99e647b09300 32 0 0 0 4k pte_list_desc ffff99e647b09600 2672 0 0 0 32k x86_emulator ffff99e647b09200 4160 0 0 0 32k x86_fpu ffff99e646013f00 48 84 85 1 4k zspage ffff99e646013d00 8 511 512 1 4k zs_handle ffff99e647b09c00 152 0 0 0 4k fuse_request ffff99e647b09900 824 0 0 0 16k fuse_inode ffff99e6464d0600 528 0 0 0 16k xfs_dqtrx ffff99e6464d0200 496 0 0 0 8k xfs_dquot ffff99e6464d0c00 360 2159 2163 103 8k xfs_buf ffff99e649d35400 200 0 0 0 4k xfs_bui_item ffff99e649d35700 168 0 0 0 4k xfs_bud_item ffff99e649d35800 424 0 0 0 8k xfs_cui_item ffff99e649d35a00 168 0 0 0 4k xfs_cud_item ffff99e6409c9000 680 0 0 0 16k xfs_rui_item ffff99e6409c9f00 168 0 0 0 4k xfs_rud_item ffff99e6409c9d00 176 0 0 0 4k xfs_icr ffff99e6409c9300 192 113 126 6 4k xfs_ili ffff99e6409c9600 960 9490 9504 594 16k xfs_inode ffff99e6409c9200 424 50 57 3 8k xfs_efi_item crash> It could run okay with Fedora 34 now. But previously, at specific conditions, the virsh dump memory/core has problem. It happened when the guest is at 100% processing power or hanged. I tried to reproduce the problem (waiting for VM to hang) and try to run the virsh dump command. Also, I used --memory-only option when I run the dump command in the past (https://bugzilla.redhat.com/show_bug.cgi?id=1876589#c0) Usually the guest reboot by itself or hanged and used 100% processing power. If it reboot my itself I can't run the virsh dump. Usually the problem happened again within a few days. When the guest VM has problem, I have test the virsh dump on it. The crash program is okay now. Version is crash-7.3.0-1.fc34.x86_64. Thank you for the confirmation, Kappa. This has been fixed on Fedora 34(crash-7.3.0-1.fc34) and rawhide(crash-7.3.0-1.fc35), so I will close it as current release. https://src.fedoraproject.org/rpms/crash |