Bug 1422743
| Summary: | [4.0 Only] After RHVH upgrade kdump service fails to start with "Error: /boot/vmlinuz-3.10.0-514.2.2.el7.x86_64 not found." | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ameya Charekar <achareka> |
| Component: | rhev-hypervisor-ng | Assignee: | Ryan Barry <rbarry> |
| Status: | CLOSED ERRATA | QA Contact: | Huijuan Zhao <huzhao> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.0.6 | CC: | achareka, cshao, dfediuck, dguo, eheftman, huzhao, jiawu, mgoldboi, mkalinin, qiyuan, sbonazzo, weiwang, yaniwang, ycui, yzhao |
| Target Milestone: | ovirt-4.1.1 | Keywords: | Reopened, ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 4.1 GA | Doc Type: | Bug Fix |
| Doc Text: |
Previously, Red Hat Virtualization Host (RHVH) placed several requisite files (initrd, kernel) in a subdirectory under /boot. As a result, some system utilities, including kdump, were unable to locate the files in the subdirectory, regardless of the BOOT_IMAGE settings.
In this release, the boot files are copied to /boot on startup and kdump is functioning properly.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-04-20 19:03:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Node | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ameya Charekar
2017-02-16 04:12:53 UTC
Can anyone please confirm is creating symlink is a right workaround or do we have any other recommended workaround? This appears to be yet another utility (along with grub2-mkconfig, virt-v2v, and dracut-fips) which doesn't honor BOOT_IMAGE We now have a service which copies the kernel and initrd to /boot. This resolves the other services, but I suspect kdump may be running first. I'll try to reproduce tomorrow, but can you please attach syslog? I'd like to see whether imgbase-copy-bootfiles ran after kdump. I'd also expect the right vmlinuz to be in /boot before you symlinked, but can't confirm without logs (or until tomorrow when I try to reproduce) After testing, this is fixed in 4.1. Until then, yes, symlinking the kernel (or copying it) is a reasonable workaround. Sandro, since there's a ticket attached, I'd like to backport https://gerrit.ovirt.org/#/c/68749/ to ovirt-4.0 / 4.0.7. I'm not sure if it's worth it given the timeframe and easy workaround, though. (In reply to Ryan Barry from comment #5) > After testing, this is fixed in 4.1. > > Until then, yes, symlinking the kernel (or copying it) is a reasonable > workaround. > > Sandro, since there's a ticket attached, I'd like to backport > https://gerrit.ovirt.org/#/c/68749/ to ovirt-4.0 / 4.0.7. I'm not sure if > it's worth it given the timeframe and easy workaround, though. Ack from devel side for the backport since patch is already available and need just a backport. Given the timeframe, probably not worth to be backported. Adding Marina for getting her opinion. Based on the 2 facts: 1. Any new RHVH is backward compatible with both engine 4.0 and 3.6 + 2. We have an easy confirmed workaround - comment#5 I believe we can have it on 4.1 GA only. Since this is also not something that has a global effect on all the users and would not bring the environment down, it seems ok to me to wait till 4.1 GA. Can reproduce according to Comment 0. According to comment #8, I'm closing next release. It's fixed in 4.1 (In reply to Sandro Bonazzola from comment #11) > According to comment #8, I'm closing next release. > It's fixed in 4.1 I am setting the "Fixed In Version" field to 4.1 GA then. (In reply to Sandro Bonazzola from comment #11) > According to comment #8, I'm closing next release. > It's fixed in 4.1 Sandro, Kindly reminder, according bugzilla process, it is not recommending that close a bug as close next release without no QE verification it. If the bug is fixed in 4.1, whether set target milestone to 4.1 would be more appropriate then 4.0.7? Thanks. Test version: From: RHVH-4.0-20160822.8-RHVH-x86_64-dvd1.iso To: rhvh-4.1-0.20170314.0 Steps to Reproduce: 1. Install older RHVH e.g. RHVH-4.0-20160822.8-RHVH-x86_64-dvd1.iso 2. Reboot and login RHVH, setup local repos, upgrade RHVH to latest one, rhvh-4.1-0.20170314.0 # yum update 3. Reboot and login new build rhvh-4.1-0.20170314.0, check kdump service status. Test results: After step3, kdump service is active. [root@dell-per730-35 ~]# imgbase layout rhvh-4.0-0.20160817.0 +- rhvh-4.0-0.20160817.0+1 rhvh-4.1-0.20170315.0 +- rhvh-4.1-0.20170315.0+1 [root@dell-per730-35 ~]# imgbase w [INFO] You are on rhvh-4.1-0.20170315.0+1 [root@dell-per730-35 ~]# systemctl status kdump ● kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) Active: active (exited) since Fri 2017-03-17 11:40:05 GMT; 7min ago Process: 3457 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS) Main PID: 3457 (code=exited, status=0/SUCCESS) CGroup: /system.slice/kdump.service Mar 17 11:40:04 dell-per730-35.lab.eng.pek2.redhat.com dracut[7586]: drwxr-xr-x 2 root root 0 Mar 17 11:39 usr/share/zone...frica Mar 17 11:40:04 dell-per730-35.lab.eng.pek2.redhat.com dracut[7586]: -rw-r--r-- 1 root root 156 Mar 2 15:01 usr/share/zone...idjan Mar 17 11:40:04 dell-per730-35.lab.eng.pek2.redhat.com dracut[7586]: drwxr-xr-x 2 root root 0 Mar 17 11:39 var Mar 17 11:40:04 dell-per730-35.lab.eng.pek2.redhat.com dracut[7586]: lrwxrwxrwx 1 root root 11 Mar 17 11:39 var/lock -> ...../lock Mar 17 11:40:04 dell-per730-35.lab.eng.pek2.redhat.com dracut[7586]: lrwxrwxrwx 1 root root 6 Mar 17 11:39 var/run -> ../run Mar 17 11:40:04 dell-per730-35.lab.eng.pek2.redhat.com dracut[7586]: ======================================================================== Mar 17 11:40:04 dell-per730-35.lab.eng.pek2.redhat.com dracut[7586]: *** Creating initramfs image file '/boot/initramfs-3.10.0-514.6.1.el7...e *** Mar 17 11:40:05 dell-per730-35.lab.eng.pek2.redhat.com kdumpctl[3457]: kexec: loaded kdump kernel Mar 17 11:40:05 dell-per730-35.lab.eng.pek2.redhat.com kdumpctl[3457]: Starting kdump: [OK] Mar 17 11:40:05 dell-per730-35.lab.eng.pek2.redhat.com systemd[1]: Started Crash recovery kernel arming. Hint: Some lines were ellipsized, use -l to show in full. So this bug is fixed in rhvh-4.1-0.20170314.0, change the status to VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1114 |