Hide Forgot
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.
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 :)