Bug 1394770
| Summary: | [RFE] yum does not fail if mkinitrd creation fails | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Klaas Demter <klaas> |
| Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.3 | CC: | asadawar, james.antill, klaas, ksrot, mdomonko, rwolters, vmukhame |
| Target Milestone: | rc | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-03-08 13:42: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
Klaas Demter
2016-11-14 12:29:27 UTC
The exit code gets passed to yum from rpm. The described behaviour is not a bug, please see bug 1105898 for more details. I understand the link to the other bugs, but they do not apply here: this here described error reproducible renders systems unbootable! While the technical reason is comparable to the other bug reports, the outcome is much, much worse. Yum handles the kernel packages specially in many cases (install, not upgrade, etc.) - and it is a valid request to add another yum function or plugin to make sure that a "yum update" which returns with a 0 exit code does not kill a system. I therefore request that the bug is re-opened. Which bz would this be a duplicate of? (In reply to Klaas Demter from comment #9) > Which bz would this be a duplicate of? Bug 1487414, which is marked as internal, so probably you will not be able to access it. Please see this upstream rpm commit for some details about how we want to approach this - https://github.com/rpm-software-management/rpm/commit/5455f02523a9b8583d5a942a6d97f1084f3093df I can't seem to add a connection with the other bug because it is private. Thanks for the upstream link. I came across a similar bug and I noticed the code has changed: this issue was silently fixed in kernel-3.10.0-862.6.3 and I guess somewhere in grubby. Now if a kernel can't create the initrd it won't get added to grub.cfg and an error will be shown: "ERROR: installing kernel-3.10.0-1062.1.2.el7.x86_64: no space left for creating initramfs. Clean up /boot partition and re-run '/usr/sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --install 3.10.0-1062.1.2.el7.x86_64'" yum exit code is still 0 though :) According to [1], the behavior was never changed on RHEL, so the exit code 0, although not ideal, is as expected. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1487414#c8 Oh, I can see the bug is actually private to Red Hat, so you probably don't have access to it. Anyway, here's the comment: ----8<-------- So the change to not error out for these scripts was done for a reason. Stopping the transaction mid way often does more damage than good. Obviously there are cases where stopping the transaction on error is the right thing to do. But rpm can not know what to do. The upstream patch allows marking scriptlets as critical. But this just made it in the upstream repository and is not even released yet. It is thus not tested and stable enough to be back ported into RHEL 7. It also requires both an updated rpm version and modifying packages that need to be both build and installed with this new rpm version. This makes this also not very practical solution for the issue at hand. Best solution for now is probably keep the current behaviour and offer the new feature in the next major RHEL version. Closing. ----8<-------- In any case, please note that RHEL-7 is now in Maintenance Support 1 Phase [1] so no such backports are considered anymore. [1] https://access.redhat.com/support/policy/updates/errata/#Maintenance_Support_1_Phase No I mean the problematic behavior was fixed in a different way than I suggested with a reasonable outcome. It no longer adds the failed kernel update to grub.cfg. Which is acceptable for the general idea of wanting a booting server instead of one stuck at boot. Oh OK, gotcha :) |