Bug 1254406
| Summary: | guest can not generate vmcore file after trigger a crash in the guest | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Yanan Fu <yfu> | ||||
| Component: | qemu-kvm-rhev | Assignee: | Radim Krčmář <rkrcmar> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.2 | CC: | chayang, hhuang, juzhang, knoel, virt-maint, xfu, yfu | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-09-18 12:50:01 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: | |||||||
| Attachments: |
|
||||||
|
Description
Yanan Fu
2015-08-18 03:11:09 UTC
Is this a regression from rhel 7.1? (In reply to Karen Noel from comment #2) > Is this a regression from rhel 7.1? with rhel 7.1 host， this issue still exist. host version: kernel:3.10.0-229.el7.x86_64 qemu:qemu-kvm-rhev-2.1.2-21.el7.x86_64 (In reply to Yanan Fu from comment #3) > (In reply to Karen Noel from comment #2) > > Is this a regression from rhel 7.1? > > with rhel 7.1 host， this issue still exist. > host version: > kernel:3.10.0-229.el7.x86_64 > qemu:qemu-kvm-rhev-2.1.2-21.el7.x86_64 In your experiment with rhel 7.1 host, was the guest still rhel 7.2? If so, then it could a guest kernel issue. Can you try rhel 7.1 guest on rhel 7.2 host? And, both host and guest rhel 7.1? Thnaks. (In reply to Karen Noel from comment #4) > (In reply to Yanan Fu from comment #3) > > (In reply to Karen Noel from comment #2) > > > Is this a regression from rhel 7.1? > > > > with rhel 7.1 host， this issue still exist. > > host version: > > kernel:3.10.0-229.el7.x86_64 > > qemu:qemu-kvm-rhev-2.1.2-21.el7.x86_64 > > In your experiment with rhel 7.1 host, was the guest still rhel 7.2? If so, > then it could a guest kernel issue. Can you try rhel 7.1 guest on rhel 7.2 > host? And, both host and guest rhel 7.1? > > Thnaks. 1.yes, in my experiment with rhel 7.1 host, guest was rhel 7.2. 2.rhel 7.1 guest on rhel 7.2 host, it is ok, guest can generate vmcore file successfully. host: kernel-3.10.0-309.el7.x86_64 guest:kernel-3.10.0-229.el7.x86_64 What does "sometimes" mean in a $number_of_failures to $number_of_tries ratio? Does it happen if you use crashkernel=auto? Please provide full console output for the failing case. (In reply to Radim Krčmář from comment #6) > What does "sometimes" mean in a $number_of_failures to $number_of_tries > ratio? > Does it happen if you use crashkernel=auto? > > Please provide full console output for the failing case. 1.with my latest test, the probability is 100% now. 2. crashkernel=128M in my test. 3. add full console output in the attachment(begin when do "echo c > /proc/sysrq-trigger"), please check. guest kernel:3.10.0-304.el7.x86_64 host kernel: 3.10.0-316.el7.x86_64 qemu-kvm:qemu-kvm-rhev-2.3.0-23.el7.x86_64 Created attachment 1074276 [details]
full console output when this bug reproduce
*** Bug 1254409 has been marked as a duplicate of this bug. *** Thanks. The relevant part is: [ 2.375538] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 [ 183.710106] dracut-initqueue[235]: Warning: Could not boot. [ 183.711412] dracut-initqueue[235]: Warning: /dev/disk/by-uuid/9a64b37a-fd56-48b5-a491-b5195d89a77c does not exist [ 183.713169] dracut-initqueue[235]: Warning: /dev/mapper/rhel_dhcp--66--72--83-root does not exist [ 183.714489] dracut-initqueue[235]: Warning: /dev/rhel_dhcp-66-72-83/root does not exist [ 183.716086] dracut-initqueue[235]: Warning: /dev/rhel_dhcp-66-72-83/swap does not exist Dracut cannot find the disk, so the kdump boot fails. I see that the other bug used the same image -- can you reproduce the bug if you # rm /boot/*kdump*; systemctl restart kdump before the first `echo c > /proc/sysrq-trigger`? (In reply to Radim Krčmář from comment #10) > Thanks. The relevant part is: > > [ 2.375538] input: ImExPS/2 Generic Explorer Mouse as > /devices/platform/i8042/serio1/input/input3 > [ 183.710106] dracut-initqueue[235]: Warning: Could not boot. > [ 183.711412] dracut-initqueue[235]: Warning: > /dev/disk/by-uuid/9a64b37a-fd56-48b5-a491-b5195d89a77c does not exist > [ 183.713169] dracut-initqueue[235]: Warning: > /dev/mapper/rhel_dhcp--66--72--83-root does not exist > [ 183.714489] dracut-initqueue[235]: Warning: /dev/rhel_dhcp-66-72-83/root > does not exist > [ 183.716086] dracut-initqueue[235]: Warning: /dev/rhel_dhcp-66-72-83/swap > does not exist > > Dracut cannot find the disk, so the kdump boot fails. > I see that the other bug used the same image -- can you reproduce the bug if > you > # rm /boot/*kdump*; systemctl restart kdump > before the first `echo c > /proc/sysrq-trigger`? After # rm /boot/*kdump*; systemctl restart kdump---->rebuild the file:/boot/initramfs-****kdump.img "echo c > /proc/sysrq-trigger" can generate vmcore file successfully. In my test before,there has a same file. Restart the kdump server ,rebuild the file, it is ok, why? Information about the system is built into *kdump.img so re-using the same image for multiple machines is going to get unexpected results and possibly fail. It's a minor bug (use-case is rare) and it's dracut's problem anyway so I'm closing it here, |