Description of problem: After a failed upgrade kernel was not installed completely. Trying to verify the package with rpm -qV kernel-core does not give any indication that there is a problem, yet there is no sign of kernel in /boot . $ rpm -qV kernel-core-4.11.6-301.fc26.x86_64 ..?...... /lib/modules/4.11.6-301.fc26.x86_64/System.map $ rpm -ql kernel-core-4.11.6-301.fc26.x86_64 | while read file; do [ -e "$file" ] || echo $file; done /boot/.vmlinuz-4.11.6-301.fc26.x86_64.hmac /boot/System.map-4.11.6-301.fc26.x86_64 /boot/config-4.11.6-301.fc26.x86_64 /boot/initramfs-4.11.6-301.fc26.x86_64.img /boot/vmlinuz-4.11.6-301.fc26.x86_64 /lib/modules/4.11.6-301.fc26.x86_64/build /lib/modules/4.11.6-301.fc26.x86_64/source Why are these file marked as %ghost?
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs. Fedora 26 has now been rebased to 4.15.4-200.fc26. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27. If you experience different issues, please open a new bug report for those.
This is a packaging issue. Until there are some changes the way kernel is packaged, I don't see how updating a new kernel version would fix this issue. https://lists.fedoraproject.org/pipermail/kernel/2015-May/005819.html
I don't think this is a packaging issue, it sounds like a one off problem of failure to install. If future kernels have worked for you I'd like to close this bug.
When package fails to pass package scriptlets, very common if package manager gets interrupted in the middle of transaction (segfault, driver crash, power outage or something else) this becomes an issue. 'rpm -V kernel-core' should report any missing files and ideally check files attributes, but files under /boot are not being reported even when missing because they are marked as %ghost. IMO %ghost should be used only for non important files that are not essential for a software to operate and not used for a kernel image which pretty much does not boot a machine if not present. I know that initramfs is not possible to check because it is generated on installation, but that is to be expected. Also, because file is marked as %ghost verification of files attributes is not in effect such as MD5 sum, modification date and similar having it a possibility to have a different image in /boot in comparison with what is found under /usr and to not be noticeable if not aware of this issue and a manual check. Why I think it is a packaging issue? Because package incorrectly marks important system files.
I got a bit more historical context from some people and the %ghost and packaging choices are deliberate. dracut handles installation and removal of the kernel files and the dracut maintainers didn't want files in /boot anymore (see https://src.fedoraproject.org/rpms/kernel/c/958df3cff2e241b694c2330cd5004b8c09bc8603) . So this is a distinct packaging choice and not actually a bug. I'm going to close this and move the area over to dracut. If you have further suggestions, please feel free to discuss it with the dracut maintainers.
These are not actually incorrectly marked, the %ghost is there because the files are not actually installed in boot. They are installed in /lib/modules/<kver> and copied over to /boot in %post by kernel-install. The ghost is required to make sure that the size is considered in the install, and that the files get cleaned up correctly. This was part of the stateless initiative a couple of years ago.
For further reading on the issue and justifications: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/HDANRFTC3JIHMSSJYL5Z5H4RM2ULZYZY/
It is possible that I am missing something, but you've repeated mostly what I said and yet not explained some point made. 1. Currently kernel image is booted from /boot 2. Image can not be verified with "rpm -V" because of %ghost directive I am not sure why are this files not installed to /boot in the first place since there is where grub is looking for, but this is how is currently the case and the situation now is that image that is booted can not be verified with "rpm -V". Which should not happen IMO.
(In reply to srakitnican from comment #8) > It is possible that I am missing something, but you've repeated mostly what > I said and yet not explained some point made. > > 1. Currently kernel image is booted from /boot > 2. Image can not be verified with "rpm -V" because of %ghost directive > > I am not sure why are this files not installed to /boot in the first place > since there is where grub is looking for, but this is how is currently the > case and the situation now is that image that is booted can not be verified > with "rpm -V". Which should not happen IMO. They are not installed directly to /boot, because we want to be flexibel in /boot setup. /lib/modules/$(uname -r)/vmlinuz can be used to generate /boot . Especially useful with rpm-ostree.