Description of problem: After RHVH upgrade from older image having kernel version prior to 3.10.0-514.2.2.el7.x86_64 kdump service fails as /boot/vmlinuz-3.10.0-514.2.2.el7.x86_64 is missing. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Install older RHVH e.g. RHVH-4.0-20160817.1. 2. Upgrade RHVH to latest one. 3. Check kdump service status. Actual results: Service kdump fails to start. Expected results: Service kdump should start without any issue. Additional info: Service starts after creating symlink as a workaround: # ln -s /boot/rhvh-4.0-0.20170201.0+1/vmlinuz-3.10.0-514.2.2.el7.x86_64 /boot/
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