Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
dracut-fips does not check BOOT_IMAGE carefully, and assumes .vmlinuz*.hmac will always be found in /boot, even when BOOT_IMAGE specifies a kernel in a subdirectory.
Version-Release number of selected component (if applicable):
dracut-fips-033-463.el7.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Put vmlinuz, initramfs, System.map, and .vmlinuz*.hmac in a subdirectory of /boot
2. Try to boot with fips=1
Actual results:
dracut-fips cannot find .vmlinuz*.hmac
Expected results:
BOOT_IMAGE supports booting from subdirectories, so dracut-fips should do the same.
Harald, Lukáš,
the patch would probably break booting on s390x, since BOOT_IMAGE there doesn't contain the path to the kernel image - it identifies the number of the boot record that was selected in the bootloader, for example:
[root@rtt7 ~]# cat /proc/cmdline
root=/dev/mapper/rhel_rtt7-root crashkernel=auto rd.dasd=0.0.3227 rd.dasd=0.0.3427 rd.dasd=0.0.3727 rd.dasd=0.0.3027 rd.dasd=0.0.3527 rd.dasd=0.0.3327 rd.dasd=0.0.3127 rd.dasd=0.0.3627 rd.lvm.lv=rhel_rtt7/root rd.lvm.lv=rhel_rtt7/swap cio_ignore=all,!condev rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0,portname=FOOBAR BOOT_IMAGE=2
[root@rtt7 ~]#
(In reply to Jan Stodola from comment #3)
> Harald, Lukáš,
> the patch would probably break booting on s390x, since BOOT_IMAGE there
> doesn't contain the path to the kernel image - it identifies the number of
> the boot record that was selected in the bootloader, for example:
>
> [root@rtt7 ~]# cat /proc/cmdline
> root=/dev/mapper/rhel_rtt7-root crashkernel=auto rd.dasd=0.0.3227
> rd.dasd=0.0.3427 rd.dasd=0.0.3727 rd.dasd=0.0.3027 rd.dasd=0.0.3527
> rd.dasd=0.0.3327 rd.dasd=0.0.3127 rd.dasd=0.0.3627 rd.lvm.lv=rhel_rtt7/root
> rd.lvm.lv=rhel_rtt7/swap cio_ignore=all,!condev
> rd.znet=qeth,0.0.0a00,0.0.0a01,0.0.0a02,layer2=1,portno=0,portname=FOOBAR
> BOOT_IMAGE=2
> [root@rtt7 ~]#https://github.com/dracutdevs/dracut/commit/3d875f77f3d1c5e4161794ca59025bc6bcd77eaa
Due to internal working of booting on s390x this fix does not work there because BOOT_IMAGE is not populated with the expected strings but a number instead.
On x86_64 the patch works as expected.
On s390x is the normal boot with everything in /boot unaffected but moving kernel, initrd and hmac into subdirectory results in broken boot as the hmac is still expected directly in /boot.
I am marking this as VERIFIED.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0964