RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1394770 - [RFE] yum does not fail if mkinitrd creation fails
Summary: [RFE] yum does not fail if mkinitrd creation fails
Keywords:
Status: CLOSED DUPLICATE of bug 1487414
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rpm
Version: 7.3
Hardware: x86_64
OS: Linux
high
urgent
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-14 12:29 UTC by Klaas Demter
Modified: 2021-06-10 11:40 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-08 13:42:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 216221 0 medium CLOSED Says it deleted Dependency, but with scriptlet exit status 2, it really did not 2021-02-22 00:41:40 UTC

Internal Links: 216221

Description Klaas Demter 2016-11-14 12:29:27 UTC 
Description of problem:
During a recent yum update I've noticed that the update doesn't fail if the initramfs creation fails.

Version-Release number of selected component (if applicable):
yum-3.4.3-150.el7.noarch

How reproducible:
/var/tmp should have less than a few mb of free space so dracut fails.


Steps to Reproduce:
1. less than Xmb free space on /var/tmp
2. yum install kernel-3.10.0-514.el7.x86_64
3. echo $?

Actual results:
=====================================================================================================================================================================
 Package                          Arch                             Version                                        Repository                                    Size
=====================================================================================================================================================================
Reinstalling:
 kernel                           x86_64                           3.10.0-327.36.3.el7                            rhel-7-server-rpms                            33 M

Transaction Summary
=====================================================================================================================================================================
Reinstall  1 Package

Total download size: 33 M
Installed size: 136 M
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for rhel-7-server-rpms
kernel-3.10.0-327.36.3.el7.x86_64.rpm                                                                                                         |  33 MB  00:00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : kernel-3.10.0-327.36.3.el7.x86_64                                                                                                                 1/1 

Broadcast message from systemd-journald.muenchen.de (Mon 2016-11-14 13:26:29 CET):

dracut[54463]: "depmod -a 3.10.0-327.36.3.el7.x86_64" failed.


Message from syslogd@deployc001 at Nov 14 13:26:29 ...
 dracut:"depmod -a 3.10.0-327.36.3.el7.x86_64" failed.
cp: error writing '/var/tmp/dracut.BnJhzP/initramfs/lib/modules/3.10.0-327.36.3.el7.x86_64/kernel/drivers/md/dm-mod.ko': No space left on device
cp: failed to extend '/var/tmp/dracut.BnJhzP/initramfs/lib/modules/3.10.0-327.36.3.el7.x86_64/kernel/drivers/md/dm-mod.ko': No space left on device
dracut-install: ERROR: installing '/lib/modules/3.10.0-327.36.3.el7.x86_64/kernel/drivers/md/dm-mod.ko'
cp: error writing '/var/tmp/dracut.BnJhzP/initramfs/lib/modules/3.10.0-327.36.3.el7.x86_64/kernel/drivers/md/dm-region-hash.ko': No space left on device
cp: failed to extend '/var/tmp/dracut.BnJhzP/initramfs/lib/modules/3.10.0-327.36.3.el7.x86_64/kernel/drivers/md/dm-region-hash.ko': No space left on device
dracut-install: ERROR: installing '/lib/modules/3.10.0-327.36.3.el7.x86_64/kernel/drivers/md/dm-region-hash.ko'
dracut-install: ERROR: failed to create directory '/var/tmp/dracut.BnJhzP/initramfs/lib/modules/3.10.0-327.36.3.el7.x86_64/kernel/drivers/message'
cp: : No such file or directory
cp: 
cp: 
cp: 
cp: 
cp: 


mkinitrd failed
warning: %posttrans(kernel-3.10.0-327.36.3.el7.x86_64) scriptlet failed, exit status 1
Non-fatal POSTTRANS scriptlet failure in rpm package kernel-3.10.0-327.36.3.el7.x86_64
Uploading Package Profile
  Verifying  : kernel-3.10.0-327.36.3.el7.x86_64                                                                                                                 1/1 

Installed:
  kernel.x86_64 0:3.10.0-327.36.3.el7                                                                                                                                

Complete!
# echo $?
0



Expected results:
Fatal Error by yum and maybe even rollback of the kernel upgrade so it doesn't get booted
# echo $?
1

Additional info:
this is especially a problem if you install a new kernel that is booted by default. this will create a kernel panic because the initramfs file is not found during next boot.
Comment 2 Valentina Mukhamedzhanova 2016-12-06 14:44:11 UTC 
The exit code gets passed to yum from rpm. The described behaviour is not a bug, please see bug 1105898 for more details.
Comment 3 Roland Wolters 2017-01-19 15:04:15 UTC 
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.
Comment 9 Klaas Demter 2018-03-08 13:48:32 UTC 
Which bz would this be a duplicate of?
Comment 10 Valentina Mukhamedzhanova 2018-03-13 12:45:04 UTC 
(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
Comment 11 Klaas Demter 2018-03-13 14:05:50 UTC 
I can't seem to add a connection with the other bug because it is private. Thanks for the upstream link.
Comment 12 Klaas Demter 2020-01-28 14:59:01 UTC 
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'"
Comment 13 Klaas Demter 2020-01-28 15:06:06 UTC 
yum exit code is still 0 though :)
Comment 14 Michal Domonkos 2020-01-28 15:53:15 UTC 
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
Comment 15 Michal Domonkos 2020-01-28 16:00:07 UTC 
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
Comment 16 Klaas Demter 2020-01-28 16:02:28 UTC 
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.
Comment 17 Michal Domonkos 2020-01-28 16:05:48 UTC 
Oh OK, gotcha :)
Note You need to log in before you can comment on or make changes to this bug.