Bug 1902179
Summary: | Ignore message about not using latest kernel after upgrade when a host hasn't been rebooted | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Roman Hodain <rhodain> |
Component: | ovirt-engine | Assignee: | Dana <delfassy> |
Status: | CLOSED ERRATA | QA Contact: | Petr Matyáš <pmatyas> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.4.3 | CC: | dfodor, dougsland, gdeolive, lsurette, mavital, mhicks, mperina, nashok, srevivo |
Target Milestone: | ovirt-4.4.7 | Keywords: | Reopened, Upgrades, ZStream |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ovirt-engine-4.4.7.6 | Doc Type: | No Doc Update |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-07-22 15:12:18 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Roman Hodain
2020-11-27 09:01:33 UTC
Reboot host after upgrade is enabled by default, so the most important issue is why reboot was disabled by the user? But anyway we will take a look if we can improve that yum check-upgrade hack Please attach host upgrade logs Feel free to reopen if reproduced again with the latest version and attach required information (In reply to Martin Perina from comment #4) > Feel free to reopen if reproduced again with the latest version and attach > required information Reopening this since we have a customer hitting the same issue on 3 hosts. As mentioned in comment 0, if the running Kernel is not the latest to that of installed kernel rpm, the "yum check-update -q --excludepkgs=ansible" will give below notice. Security: kernel-core-4.18.0-240.22.1.el8_3.x86_64 is an installed security update Security: kernel-core-4.18.0-240.15.1.el8_3.x86_64 is the currently running version Then the command "yum check-update -q --excludepkgs=ansible | grep '[0-9]' | cut -d ' ' -f1 | sed '/^$/d'" (Task: Check for system updates) will be below. # yum check-update -q --excludepkgs=ansible | grep '[0-9]' | cut -d ' ' -f1 | sed '/^$/d' |tail cockpit-system.noarch gdb-headless.x86_64 grub2-tools.x86_64 grub2-tools-efi.x86_64 grub2-tools-extra.x86_64 grub2-tools-minimal.x86_64 kernel-headers.x86_64 kernel-headers.x86_64 Security: Security: So this "Security:" will also be passed to the task "Upgrade packages" which will fail with the error below. === 2021-05-04 15:41:31 MSK - TASK [ovirt-host-upgrade : Upgrade packages] *********************************** (item=Security:) => {"ansible_loop_var": "item", "changed": false, "failures": ["No package Security: available."], "item": "Security:", "msg": "Failed to install some of the specified packages", "rc": 1, "results": []} === Steps to Reproduce: [1] Reboot the server with an older kernel. [2] Try to update the host from the manager. Nijin, have you seen Comment 2? Why customer turned off reboot after upgrade? It's clearly visible that upgrade the kernel package, but as they didn't reboot the host, the upgrade is not finished. For example if kernel would be a security upgrade, they would still be using vulnerable machine. That's exactly the reason why we enabled reboot after upgrade by default. So yeah, we could filter Security related message from check-for-upgrade flow, but that wouldn't solve the customer problem as customer is still running on the unupgraded kernel Verified on ovirt-engine-4.4.7.6-0.11.el8ev.noarch 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 (Moderate: RHV Manager (ovirt-engine) security update [ovirt-4.4.7]), 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/RHSA-2021:2865 Due to QE capacity, we are not going to cover this issue in our automation |