It's possible you might be low on space on the /boot partition. Yum or RPM disk requirement calculations aren't perfect and it can fail if you are right on the edge.
But I've seen similar behavior in the past 5-6 months when I wasn't low on space - seemingly at random except that they are all CentOS 7 systems. However, I have plenty of C7 systems that seem to work fine and there is no substantial difference between them. My fix for this is to simply boot into the previous kernel and do a "yum reinstall kernel-3.10.0-514.21.1.el7.x86_64" and then reboot it one more time. It seems like the initrd may not be properly built after the kernel update. I don't know what the root cause is - it seems like there is some kind of bug when updating the kernel that doesn't trigger consistently. The other bug that I think might be related to the same root cause is that the default kernel isn't updated even though /etc/sysconfig/kernel is set to updatedefault. I catch this when I do post-patch auditing and fix it pretty much the same way. If you do a yum reinstall a second time - the default is updated correctly. Very weird. Regards, --Tony -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Huber, Peter Sent: Tuesday, June 6, 2017 5:50 AM To: [email protected] Subject: [Spacewalk-list] cannot boot after kernel update I have updated 2 centos hosts today. The following updates were installed: firewalld-0.4.3.2-8.1.el7_3.3.noarch libnetfilter_conntrack-1.0.6-1.el7_3.x86_64 sudo-1.8.6p7-22.el7_3.x86_64 dracut-config-rescue-033-463.el7_3.1.x86_64 nss-sysinit-3.28.4-1.2.el7_3.x86_64 yum-rhn-plugin-2.6.4-1.el7.noarch NetworkManager-wifi-1.4.0-20.el7_3:1.x86_64 glibc-2.17-157.el7_3.2.x86_64 nss-tools-3.28.4-1.2.el7_3.x86_64 systemd-sysv-219-30.el7_3.9.x86_64 python-perf-3.10.0-514.21.1.el7.centos.plus.x86_64 systemd-219-30.el7_3.9.x86_64 kpartx-0.4.9-99.el7_3.3.x86_64 systemd-libs-219-30.el7_3.9.x86_64 firewalld-filesystem-0.4.3.2-8.1.el7_3.3.noarch java-1.8.0-openjdk-devel-1.8.0.131-3.b12.el7_3:1.x86_64 NetworkManager-team-1.4.0-20.el7_3:1.x86_64 java-1.8.0-openjdk-headless-1.8.0.131-3.b12.el7_3:1.x86_64 polkit-0.112-12.el7_3.x86_64 systemd-python-219-30.el7_3.9.x86_64 tuned-2.7.1-3.el7_3.2.noarch nss-3.28.4-1.2.el7_3.x86_64 rdma-7.3_4.7_rc2-6.el7_3.noarch NetworkManager-1.4.0-20.el7_3:1.x86_64 NetworkManager-tui-1.4.0-20.el7_3:1.x86_64 dracut-033-463.el7_3.1.x86_64 java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3:1.x86_64 dracut-network-033-463.el7_3.1.x86_64 kernel-tools-3.10.0-514.21.1.el7.x86_64 libgudev1-219-30.el7_3.9.x86_64 python-firewall-0.4.3.2-8.1.el7_3.3.noarch kernel-tools-libs-3.10.0-514.21.1.el7.x86_64 glibc-common-2.17-157.el7_3.2.x86_64 NetworkManager-libnm-1.4.0-20.el7_3:1.x86_64 kernel-3.10.0-514.21.1.el7.x86_64 after a reboot, both servers do not start anymore. There is a kernel panic - not syncing: VFS: Unable to mount root fs on unknown wm block(0,0) Any idea what can cause this problem? Both servers got this kernel-update.... Regards Peter Private Universität Witten/Herdecke gGmbH Alfred-Herrhausen-Straße 50 D - 58448 Witten Homepage: http://www.uni-wh.de Twitter: http://twitter.com/UniWH Facebook: http://www.facebook.com/UniWH Geschäftsführung: Prof. Dr. Martin Butzlaff (Präsident), Dipl. oec. Jan Peter Nonnenkamp (Kanzler) Sitz der Gesellschaft: Witten Handelsregister des Amtsgerichts Bochum Nr. HRB 8671 _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
