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.
Bug 691419 - dracut parameter "boot=<boot device>" broken for FIPS mode
Summary: dracut parameter "boot=<boot device>" broken for FIPS mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dracut
Version: 6.1
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: rc
: ---
Assignee: Harald Hoyer
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: RHEL62CCC 692515 846801 846802
TreeView+ depends on / blocked
 
Reported: 2011-03-28 14:18 UTC by Stephan Mueller
Modified: 2018-11-28 20:54 UTC (History)
6 users (show)

Fixed In Version: dracut-004-46.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 11:54:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
dracut with rdinitdebug (13.24 KB, application/octet-stream)
2011-03-30 12:44 UTC, Martin Banas 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0523 0 normal SHIPPED_LIVE dracut bug fix and enhancement update 2011-05-18 17:44:57 UTC

Description Stephan Mueller 2011-03-28 14:18:33 UTC 
Description of problem:

(please note that I am not fully sure that this is the fault of dracut-fips - it may also be an issue in anaconda)

Using the latest RHEL6.1 alpha ISO from Mar 17 and installing it with fips=1, and adding the dracut-fips package, I cannot boot the system.

Note that I installed the system using anaconda kickstart where the boot image was started with fips=1, and a kickstart file where logvol --encrypt is used.

When rebooting after successful installation, I get:

first there is a mount error (wrong fs type, bad option, bad superblock on ...) - I guess it is the error to mount the root partition

dracut: FATAL: FIPS integrity test failed
dracut: Refusing to continue
dracut: FATAL: FIPS integrity test failed
dracut: Refusing to continue


Then a kernel panic due to killing init.
Comment 2 Harald Hoyer 2011-03-28 15:06:08 UTC 
Is the boot device specified on the kernel command line?

"boot=<boot partition>"
Comment 3 Stephan Mueller 2011-03-28 15:16:30 UTC 
there is no boot= entry on the kernel command line.
Comment 4 Harald Hoyer 2011-03-28 15:19:50 UTC 
does it work, if you add it?
Comment 5 Stephan Mueller 2011-03-28 15:34:14 UTC 
(In reply to comment #4)
> does it work, if you add it?

please scratch my previous remark - I already re-installed my system. I again install it with fips=1 and report back.
Comment 6 Stephan Mueller 2011-03-28 17:20:48 UTC 
After re-install with fips=1 and verifying that the same error occurs, the boot= parameter is missing from the kernel command line.

After adding boot=/dev/vda1 (/boot is on /dev/vda1), I still get the error.

When looking further, it seems that the initramfs tries to mount the root partition which however is a dm_crypt partition. Therefore, it *seems* that the logic to figure out that the root partition is a dm_crypt in the initramfs does not work - note that there is a mount of the /dev/mapper/<UUID> where the UUID points to the dm_crypt-protected partition.
Comment 7 Harald Hoyer 2011-03-28 19:00:37 UTC 
(In reply to comment #6)
> After re-install with fips=1 and verifying that the same error occurs, the
> boot= parameter is missing from the kernel command line.
> 
> After adding boot=/dev/vda1 (/boot is on /dev/vda1), I still get the error.
> 
> When looking further, it seems that the initramfs tries to mount the root
> partition which however is a dm_crypt partition. Therefore, it *seems* that the
> logic to figure out that the root partition is a dm_crypt in the initramfs does
> not work - note that there is a mount of the /dev/mapper/<UUID> where the UUID
> points to the dm_crypt-protected partition.

can you add "rdinitdebug" to the kernel command line and show me the boot output?
Comment 8 Stephan Mueller 2011-03-28 19:51:44 UTC 
Instead of rdinitdebug, I got some other news:

If I add boot=/dev/vda1 before the root= parameter, I get the crash as depicted above.

If I append boot=/dev/vda1 as the last parameter, it boots.


So, is there an order of parameters to be maintained?

Why is the boot=... not added by anaconda or any other part of the install system?
Comment 9 Chris Lumens 2011-03-29 14:50:52 UTC 
Please attach the bootloader configuration as written by anaconda before any modification to this bug report.
Comment 10 Stephan Mueller 2011-03-29 15:17:36 UTC 
This is the command line in menu.lst:

kernel /vmlinuz-2.6.32-122.el6.x86_64 ro root=/dev/mapper/luks-6e9bdc63-df7a-43a7-aec9-40462ac37e5a boot=UUID=2ca47455-234f-4ae0-93dd-e682daffe65a rd_LVM_LV=VolGroup01/root rd_LUKS_UUID=luks-6e9bdc63-df7a-43a7-aec9-40462ac37e5a rd_LVM_LV=VolGroup01/LvSwap rd_LUKS_UUID=luks-bbf97b00-74f6-4c7c-bac6-bce8b5d247cd rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us fips=1 crashkernel=auto audit=1 rhgb quiet

Note, audit=1 was added with a kickstart command

bootloader --append="audit=1"

However, the missing boot= parameter also occurs even without this --append.
Comment 11 Stephan Mueller 2011-03-29 15:20:16 UTC 
Oh, I just see that there is a boot= parameter! Hm, but it apparently does not work - see my remark above that the position of the boot= parameter seems to be important too.

Note that the UUID in the boot= parameter points to /dev/vda1 - i.e. the correct partition holding /boot.
Comment 12 Harald Hoyer 2011-03-29 23:09:44 UTC 
(In reply to comment #11)
> Oh, I just see that there is a boot= parameter! Hm, but it apparently does not
> work - see my remark above that the position of the boot= parameter seems to be
> important too.
> 
> Note that the UUID in the boot= parameter points to /dev/vda1 - i.e. the
> correct partition holding /boot.

does it work, if you replace "boot=UUID=2ca47455-234f-4ae0-93dd-e682daffe65a" with "boot=/dev/vda1" ??

Which would explain the position problem... "boot=/dev/vda1" would be overwritten by the later  "boot=UUID=2ca47455-234f-4ae0-93dd-e682daffe65a"
Comment 13 Stephan Mueller 2011-03-30 07:27:38 UTC 
Vhen leaving the boot= parameter at the location where anaconda placed it but replacing the UUID with /dev/vda1, it works (the system boots).
Comment 14 Martin Banas 2011-03-30 12:44:15 UTC 
Created attachment 488751 [details]
dracut with rdinitdebug

Attaching a rdinitdebug log
Comment 16 Martin Banas 2011-03-30 13:14:28 UTC 
Hello Stephan,
If an installation is started with fips=1, should the package dracut-fips be installed by default?

Now the only way how to install it is in kickstart since user can't select it in UI.
Comment 17 Steve Grubb 2011-03-30 13:20:18 UTC 
I would say this is desirable. By booting with FIPS=1, the user has indicated they want FIPS compliance.
Comment 19 Stephan Mueller 2011-03-30 13:28:56 UTC 
From a CC point of view, it is only a nice to have to ensure that the CC configuration automatically is in FIPS mode.

For the FIPS validation, dracut-fips is a must as it ensures the proper integrity checking during boot time.
Comment 20 Stephan Mueller 2011-03-30 13:31:58 UTC 
> Now the only way how to install it is in kickstart since user can't select it
> in UI.

Why would someone boot the install system with fips=1? I guess the only intention is to have the system in FIPS mode after install. Therefore, I would suggest to install dracut-fips unconditionally when fips=1 is given.

Note, having a UI where you select the fips mode is highly misleading as this same UI offers the disk encryption. Only if the kernel is booted with fips=1, the disk encryption key is generated with a FIPS-compliant RNG. Therefore, I would suggest not to provide any UI addition for FIPS mode.
Comment 21 Stephan Mueller 2011-03-30 13:33:40 UTC 
(In reply to comment #14)
> Created attachment 488751 [details]
> dracut with rdinitdebug
> 
> Attaching a rdinitdebug log

With the log you see that the UUID resolution is flawed as it resolves the root partition and not the boot partition.
Comment 22 Harald Hoyer 2011-03-30 13:50:01 UTC 
http://git.kernel.org/?p=boot/dracut/dracut.git;a=commitdiff;h=4ac0cbad25f42b57fc082f89af5da7ba3355eb20
Comment 24 Martin Banas 2011-03-31 13:17:11 UTC 
There's another bug in kernel which prevents this one to be verified:
https://bugzilla.redhat.com/show_bug.cgi?id=692515

It seems the .hmac and checksum differs.

boot: linux
Please wait, loading kernel...
   Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 03700000, size: 17878 Kbytes
OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 2.6.32-128.el6.ppc64 (mockbuild.bos.redhat.com) (gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) ) #1 SMP Mon Mar 28 21:49:38 EDT 2011
Max number of cores passed to firmware: 0x0000000000000200
Calling ibm,client-architecture-support... done
command line: root=/dev/mapper/vg_ibmjs2205-lv_root ro boot=UUID=c01718b0-d895-4895-9b89-c08283baf3f2 rd_LVM_LV=vg_ibmjs2205/lv_root rd_LVM_LV=vg_ibmjs2205/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us fips=1 console=hvc0 crashkernel=auto rhgb quiet 
memory layout at init:
  memory_limit : 0000000000000000 (16 MB aligned)
  alloc_bottom : 0000000004880000
  alloc_top    : 0000000008000000
  alloc_top_hi : 0000000008000000
  rmo_top      : 0000000008000000
  ram_top      : 0000000008000000
found display   : /pci@800000020000202/display@1, opening... done
instantiating rtas at 0x00000000074e0000... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000002... done
starting cpu hw idx 0000000000000004... done
starting cpu hw idx 0000000000000006... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000004890000 -> 0x00000000048917fb
Device tree struct  0x00000000048a0000 -> 0x00000000048c0000
Calling quiesce...
returning from prom_init
radeon 0002:00:01.0: Invalid ROM contents
radeon 0002:00:01.0: Invalid ROM contents
[drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
/boot/vmlinuz-2.6.32-128.el6.ppc64: FAILED
 computed = 6f39b5c725ead894b22fd334b9b349e7c1444d6a705d95a1f1c1655472d744a478d5da5f725287150a5aa45233e59b6ab447714075cf8e4fc88281246dcc7d64
 expected = 6c5c405c9031d5dffae0223e4e5567ab31a64b65b83f50b22ace3e1166d3700bddebb20a522b2a52ad08a447bdab6efe4fb5c59bff0688c61adf1f72a92b19bc
dracut: FATAL: FIPS integrity test failed
dracut: Refusing to continue


Kernel panic - not syncing: Attempted to kill init!
panic occurred, switching back to text console
Rebooting in 180 seconds..
Comment 25 Stephan Mueller 2011-04-04 14:11:03 UTC 
fix works for me
Comment 26 Alexander Todorov 2011-04-05 15:02:58 UTC 
I performed install with fips=1 and anaconda-13.21.109 from a nightly build. /proc/cmline (grub.conf) after install contains boot=UUID=..... parameter and the system was able to boot into runlevel 3 without any issues. Moving to VERIFIED.
Comment 27 errata-xmlrpc 2011-05-19 11:54:23 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0523.html
Note You need to log in before you can comment on or make changes to this bug.