Hide Forgot
Newer kernel-core packages package the kernel to in /lib/modules, so supermin should look for /lib/modules/$(uname -r)/vmlinuz first before looking in /boot for the kernel image.
Since when this change started? Also, are there compatibility symlinks in /boot?
/boot cannot carry symlinks in EFI environments. Also, /boot/vmlinuz-$(uname -r) might not even exist, if someone is using a bootloader, which follows the bootloader specification. kernel-install in kernel %post will install /lib/modules/$(uname -r)/vmlinuz to /boot ... location depends on the bootloader. So, just look for /lib/modules/$(uname -r)/vmlinuz first and all should be fine.
OK, I see. One last question: is /lib/modules/$(uname -r)/vmlinuz always guaranteed to be unversioned, i.e. just "vmlinuz" no matter which arch/version/variant/etc?
(In reply to Pino Toscano from comment #3) > OK, I see. > > One last question: is /lib/modules/$(uname -r)/vmlinuz always guaranteed to > be unversioned, i.e. just "vmlinuz" no matter which arch/version/variant/etc? yes, because the version is already in the directory path
Just sent a couple of patches for this: https://www.redhat.com/archives/libguestfs/2016-November/msg00102.html https://www.redhat.com/archives/libguestfs/2016-November/msg00103.html
Fixed with commits https://github.com/libguestfs/supermin/commit/1fa9b49caccaf7e3d6cbde916df322b6d7554eb6 https://github.com/libguestfs/supermin/commit/d4029206e8ab7372db727837ce39f64b713ef7c6 which will be in supermin >= 5.1.18.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
Other than what said already in comment 6, this is fixed in Fedora starting with the following packages: - supermin-5.1.18-1.fc25 - supermin-5.1.18-1.fc26 - supermin-5.1.18-1.fc27