Bug 1014527

If /boot is on a separate partition, it has to be specified on the kernel command line with "boot=<boot device>"

       boot=<boot device>
           specify the device, where /boot is located. e.g.

               boot=/dev/sda1
               boot=/dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:1:0-part1
               boot=UUID=<uuid>
               boot=LABEL=<label>

yes, we had this problem too, it was specified

please boot with "rdinitdebug" on the kernel command line and remove "quiet rhgb" and show me the console messages.

Created attachment 809835 [details]
full console log from failing boot

Looks like "quiet rhgb" are not present by default on the machine.

grub.conf:

default=0
timeout=5
serial --unit=0 --speed=115200
terminal --timeout=5 serial console
title Red Hat Enterprise Linux (2.6.32-358.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-358.el6.x86_64 ro root=/dev/mapper/vg_sunx845001-lv_root rd_NO_LUKS rd_LVM_LV=vg_sunx845001/lv_swap LANG=en_US.UTF-8 rd_LVM_LV=vg_sunx845001/lv_root rd_NO_MD console=ttyS0,115200 crashkernel=auto SYSFONT=latarcyrheb-sun16  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM fips=1 boot=/dev/sdb1 rdinitdebug
        initrd /initramfs-2.6.32-358.el6.x86_64.img



The panic with rdinitdebug:

dracut: Mounted root filesystem /dev/mapper/vg_sunx845001-lv_root 
 %Gdracut: Checking integrity of kernel 
dracut Warning: /boot/.vmlinuz-2.6.32-358.el6.x86_64.hmac does not exist 
dracut: FATAL: FIPS integrity test failed 
dracut: Refusing to continue 
dracut Warning: Signal caught! 
+ echo  
  
+ echo  
  
+ warn Signal 'caught!'  
+ check_quiet  
+ '[' -z yes ']'  
+ echo '<4>dracut Warning: Signal' 'caught!'  
+ '[' yes '!=' yes ']'  
+ source_all emergency  
+ local f  
+ '[' emergency ']'  
+ '[' -d /emergency ']'  
+ for f in '"/$1"/*.sh'  
+ '[' -e /emergency/00plymouth-emergency.sh ']'  
+ . /emergency/00plymouth-emergency.sh  
++ '[' -x /bin/plymouth ']'  
++ /bin/plymouth --hide-splash  
 %G %G+ echo  
  
+ echo  
  
+ warn Signal 'caught!'  
+ check_quiet  
+ '[' -z yes ']'  
+ echo '<4>dracut Warning: Signal' 'caught!'  
+ '[' yes '!=' yes ']'  
+ source_all emergency  
+ local f  
+ '[' emergency ']'  
+ '[' -d /emergency ']'  
+ for f in '"/$1"/*.sh'  
+ '[' -e /emergency/00plymouth-emergency.sh ']'  
+ . /emergency/00plymouth-emergency.sh  
++ '[' -x /bin/plymouth ']'  
++ /bin/plymouth --hide-splash  
+ for f in '"/$1dracut Warning: dracut: FATAL: FIPS integrity test failed 
"/*.sh' 
+ '[' -dracut Warning: dracut: Refusing to continue 
e /emergency/01-Kernel panic - not syncing: Attempted to kill init! 
Pid: 1, comm: init Not tainted 2.6.32-358.el6.x86_64 #1 
Call Trace: 
die.sh ']' 
+ .  [<ffffffff8150cfc8>] ? panic+0xa7/0x16f 
/emergency/01-di [<ffffffff81073ae2>] ? do_exit+0x862/0x870 
 [<ffffffff81073b48>] ? do_group_exit+0x58/0xd0 
e.sh 
++ warn dr [<ffffffff81073bd7>] ? sys_exit_group+0x17/0x20 
acut: FATAL: 'FI [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b 
panic occurred, switching back to text console 
[-- MARK -- Wed Oct  9 09:55:00 2013] 
[-- MARK -- Wed Oct  9 10:00:00 2013] 

full console.log output attached

Let me point out that there is always a straightforward workaround for this bug, you can always use boot=<dev-file> instead of boot=<UUID>. With <dev-file> you will not hit the bug.

(In reply to Ondrej Moriš from comment #18)
> Let me point out that there is always a straightforward workaround for this
> bug, you can always use boot=<dev-file> instead of boot=<UUID>. With
> <dev-file> you will not hit the bug.

The workaround works for most machines, but not all. The original bug description was using boot= specified as a path in /dev. Using UUID just makes the FIPS setup fail on more machines, not on a different set of machines.

(In reply to Hubert Kario from comment #19)
> (In reply to Ondrej Moriš from comment #18)
> > Let me point out that there is always a straightforward workaround for this
> > bug, you can always use boot=<dev-file> instead of boot=<UUID>. With
> > <dev-file> you will not hit the bug.
> 
> The workaround works for most machines, but not all. The original bug
> description was using boot= specified as a path in /dev. Using UUID just
> makes the FIPS setup fail on more machines, not on a different set of
> machines.

Ah, I see now (BZ#1014527#c10). Please ignore my previous comment (c#19). 

Hubert, I've updated the test to use UUID for boot device when it is executed with USE_UUID parameter (see QA Whiteboard).

* ibm-x3650m4-01-vm-16.lab.eng.bos.redhat.com
  - boot on /dev/vda1
  - kernel parameter boot=UUID="62106b0d-ee5d-48c5-96b4-5406009bcd18"

* ibm-p730-06-lp3.rhts.eng.bos.redhat.com 	
  - boot on /dev/sda1
  - kernel parameter boot=UUID="62106b0d-ee5d-48c5-96b4-5406009bcd18"


How can these two machines have the boot partition with the same UUID?

Has anyone verified, that the UUID actually corresponds to the filesystem UUID of /boot?

A question for Steve Grubb: Can we drop the hmac check of the kernel? This check is so bogus, causes only problems to find the boot partition and proves _nothing_.

This could even be done very late in the boot process.

I failed reboot the system with FIPS enabled too, I use RHEL6.5-Snapshot-3 server64 system. I don't know if the reason is the same with this bug, if not please let me know and I'll move this comment to a new bug report. 

Version-Release number of selected component (if applicable):
dracut-004-330.el6.noarch                     
dracut-fips-004-330.el6.noarch
dracut-kernel-004-330.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. Enable FIPS mode
 1.1 Install dracut-fips and hamccalc 
 1.2 modify the /boot/grub/grub.conf to enable FIPS mode
2. reboot machine


Actual results:
Reboot failed.To check the details please see the attachment

Expected results:
system booted to FIPS mode

Additional info:
After I set prelink to NO and run "prelink -ua" reboot succeed but can't log in to the system "Authentication failed".

Created attachment 810952 [details]
bootup screenshot

(In reply to Harald Hoyer from comment #23)
> 
> * ibm-x3650m4-01-vm-16.lab.eng.bos.redhat.com
>   - boot on /dev/vda1
>   - kernel parameter boot=UUID="62106b0d-ee5d-48c5-96b4-5406009bcd18"
> 
> * ibm-p730-06-lp3.rhts.eng.bos.redhat.com 	
>   - boot on /dev/sda1
>   - kernel parameter boot=UUID="62106b0d-ee5d-48c5-96b4-5406009bcd18"
> 
> 
> How can these two machines have the boot partition with the same UUID?
> 
> Has anyone verified, that the UUID actually corresponds to the filesystem
> UUID of /boot?

It's done automatically using:
BOOT_DEV=`df /boot/ | tail -1 | awk '{print $1}'`
BOOT_DEV=$(blkid $BOOT_DEV | head -n 1 | grep -E --only-matching 'UUID="[^"]*"')

I don't see how this code can be failing (or providing wrong UUID) on rhel-6 but work just fine on RHEL-5 and RHEL-7.

Looks like Ondrej copied the same data twice, the log from ibm-x3650m4-01-vm-16.lab.eng.bos.redhat.com has:

    boot=UUID="f06760ef-f72b-45ae-9c5c-513a56aa7e9c"

(In reply to xingge from comment #26)
> Created attachment 810952 [details]
> bootup screenshot

It's different issue.

In our case the boot is aborted before getting to initrd.

(In reply to xingge from comment #25)
> I failed reboot the system with FIPS enabled too, I use RHEL6.5-Snapshot-3
> server64 system. I don't know if the reason is the same with this bug, if
> not please let me know and I'll move this comment to a new bug report. 
> 
> Version-Release number of selected component (if applicable):
> dracut-004-330.el6.noarch                     
> dracut-fips-004-330.el6.noarch
> dracut-kernel-004-330.el6.noarch
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. Enable FIPS mode
>  1.1 Install dracut-fips and hamccalc 
>  1.2 modify the /boot/grub/grub.conf to enable FIPS mode
> 2. reboot machine

did you recreate the initramfs?

> 
> 
> Actual results:
> Reboot failed.To check the details please see the attachment
> 
> Expected results:
> system booted to FIPS mode
> 
> Additional info:
> After I set prelink to NO and run "prelink -ua" reboot succeed but can't log
> in to the system "Authentication failed".

(In reply to xingge from comment #26)
> Created attachment 810952 [details]
> bootup screenshot

This is not a dracut bug!

(In reply to Hubert Kario from comment #28)
> (In reply to xingge from comment #26)
> > Created attachment 810952 [details]
> > bootup screenshot
> 
> It's different issue.
> 
> In our case the boot is aborted before getting to initrd.

before getting to initrd? Then it's not a dracut bug also

(In reply to Harald Hoyer from comment #31)
> (In reply to Hubert Kario from comment #28)
> > (In reply to xingge from comment #26)
> > > Created attachment 810952 [details]
> > > bootup screenshot
> > 
> > It's different issue.
> > 
> > In our case the boot is aborted before getting to initrd.
> 
> before getting to initrd? Then it's not a dracut bug also

I mixed up the terms, I meant system initialization process, when deamons are started.

The stacktrace in Comment #0 clearly shows that the kernel panic is caused by dracut already running inside init process. Sorry if that caused any confusion.

(In reply to Hubert Kario from comment #27)
> It's done automatically using:
> BOOT_DEV=`df /boot/ | tail -1 | awk '{print $1}'`
> BOOT_DEV=$(blkid $BOOT_DEV | head -n 1 | grep -E --only-matching
> 'UUID="[^"]*"')

This would not work on my system! That catches the PARTUUID also and worse, it rewrites it to PARTUUID.

# BOOT_DEV=`df /boot/ | tail -1 | awk '{print $1}'`
# BOOT_DEV=$(blkid $BOOT_DEV | head -n 1 | grep -E --only-matching 'UUID="[^"]*"')
# echo $BOOT_DEV
UUID="B919-3D05" UUID="752799f4-f8f5-4435-9306-0d1550536049"

# blkid /dev/sda1
/dev/sda1: SEC_TYPE="msdos" UUID="B919-3D05" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="752799f4-f8f5-4435-9306-0d1550536049" 

...

# blkid -s UUID -o value /dev/sda1
B919-3D05

(In reply to Harald Hoyer from comment #33)
> (In reply to Hubert Kario from comment #27)
> > It's done automatically using:
> > BOOT_DEV=`df /boot/ | tail -1 | awk '{print $1}'`
> > BOOT_DEV=$(blkid $BOOT_DEV | head -n 1 | grep -E --only-matching
> > 'UUID="[^"]*"')
> 
> This would not work on my system! That catches the PARTUUID also and worse,
> it rewrites it to PARTUUID.

Correction:
This would not work on my system! That catches the PARTUUID also and worse,
it rewrites it to UUID.

(In reply to Harald Hoyer from comment #33)
> (In reply to Hubert Kario from comment #27)
> > It's done automatically using:
> > BOOT_DEV=`df /boot/ | tail -1 | awk '{print $1}'`
> > BOOT_DEV=$(blkid $BOOT_DEV | head -n 1 | grep -E --only-matching
> > 'UUID="[^"]*"')
> 
> This would not work on my system! That catches the PARTUUID also and worse,
> it rewrites it to PARTUUID.
> 
> # BOOT_DEV=`df /boot/ | tail -1 | awk '{print $1}'`
> # BOOT_DEV=$(blkid $BOOT_DEV | head -n 1 | grep -E --only-matching
> 'UUID="[^"]*"')
> # echo $BOOT_DEV
> UUID="B919-3D05" UUID="752799f4-f8f5-4435-9306-0d1550536049"
> 
> # blkid /dev/sda1
> /dev/sda1: SEC_TYPE="msdos" UUID="B919-3D05" TYPE="vfat" PARTLABEL="EFI
> System Partition" PARTUUID="752799f4-f8f5-4435-9306-0d1550536049" 
> 
> ...
> 
> # blkid -s UUID -o value /dev/sda1
> B919-3D05

that would cause the kernel command line to be set to something like this:

boot=UUID="B919-3D05" UUID="752799f4-f8f5-4435-9306-0d1550536049"

The boot= is then correct and UUID= would be ignored so it would not be fatal. It also requires /boot to be on FAT, I don't think we use it in any default config. I'll fix the script to use -s -o syntax just in case. Thanks for pointing it out!

Anyway, both jobs on sun-x8450-01.rhts.eng.bos.redhat.com and the job on dell-pem805-01.rhts.eng.bos.redhat.com used ext4 as the /boot file system and /dev path name so it's certainly not the reason why they fail.

Yes, the hmac files are required. It is weak, but requirement being fulfilled is merely to detect accidental misconfiguration rather than prevent tampering with the kernel.

(In reply to Steve Grubb from comment #36)
> Yes, the hmac files are required. It is weak, but requirement being
> fulfilled is merely to detect accidental misconfiguration rather than
> prevent tampering with the kernel.

Can we delay that check for rc.sysinit time? It would make life soooo much easier!

please provide the console output with "rhgb" removed and "quiet rdinitdebug" added to the kernel command line.

note: add "quiet" ... that lets dracut output directly to the console, instead of using /dev/kmsg, which does not seem to be flushed in this case.

Just so there is a record of this. The check needs to be at the earliest possible time before using the kernel (much) and with FIPS-140 certified software. If we make big changes in how we do it, Atsec will have to explain how the new check works and that will raise questions about whether the old way was correct and cause even more scrutiny of the new way. That's not good for a simple re-validation.

We can make limitations in our Security Policy about what kind of file systems is permissible for /boot if that is a source of problems. Mkinitrd placed the following restrictions in the RHEL5 Security Policy:

-/boot must be on a separate partition (it usually is)
-/boot must *not* be on any of the following which
  are normally supported:
  -nfs
  -dmraid
  -mdraid (note we normally support level 1 only)
-/boot ofcourse also must not be on anything which we normally do
  not support for it, the following come to mind:
  -any kind of device mapper virtual device (ie lvm / dmcrypt)
  -multipath
  -gfs2

So, there is a precedent of restricting use on exotic file systems if it causes problems. Let me know if we need to change documentation.

Created attachment 812038 [details]
Run with UUID and quiet

(In reply to Harald Hoyer from comment #38)
> please provide the console output with "rhgb" removed and "quiet
> rdinitdebug" added to the kernel command line.
> 
> note: add "quiet" ... that lets dracut output directly to the console,
> instead of using /dev/kmsg, which does not seem to be flushed in this case.

That didn't work out, there is no additional info:


The highlighted entry will be booted automatically in 5 seconds.          
      
The highlighted entry will be booted automatically in 4 seconds.          
      
The highlighted entry will be booted automatically in 3 seconds.          
      
The highlighted entry will be booted automatically in 2 seconds.          
      
The highlighted entry will be booted automatically in 1 seconds.          
  
  
%G %Gdracut: FATAL: FIPS integrity test failed 
dracut: Refusing to continue 
  
  
 %G %G  
  
Kernel panic - not syncing: Attempted to kill init! 
Pid: 1, comm: init Not tainted 2.6.32-358.el6.x86_64 #1 
Call Trace: 
 [<ffffffff8150cfc8>] ? panic+0xa7/0x16f 
 [<ffffffff81073ae2>] ? do_exit+0x862/0x870 
 [<ffffffff81182885>] ? fput+0x25/0x30 
 [<ffffffff81073b48>] ? do_group_exit+0x58/0xd0 
 [<ffffffff81073bd7>] ? sys_exit_group+0x17/0x20 
 [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b

Created attachment 812102 [details]
Run with UUID and quiet

(In reply to Harald Hoyer from comment #38)
> please provide the console output with "rhgb" removed and "quiet
> rdinitdebug" added to the kernel command line.
> 
> note: add "quiet" ... that lets dracut output directly to the console,
> instead of using /dev/kmsg, which does not seem to be flushed in this case.

run with uuid option and quiet, the dracut output is too big to quote here.

I'll schedule run with normal dev path and the sun machine in a moment

dracut: ++ '[' -e '/dev/disk/by-uuid/"28920d27-5c30-44c3-84a8-c3be44ead9d0"' ']' 

hmm, according to this log entry, you set:

boot=UUID="28920d27-5c30-44c3-84a8-c3be44ead9d0"

on the kernel command line.

Please remove the apostrophes and retry!

it should look like this: boot=UUID=28920d27-5c30-44c3-84a8-c3be44ead9d0

!!!!!!!!!

(In reply to Harald Hoyer from comment #45)
> dracut: ++ '[' -e '/dev/disk/by-uuid/"28920d27-5c30-44c3-84a8-c3be44ead9d0"'
> ']' 
> 
> hmm, according to this log entry, you set:
> 
> boot=UUID="28920d27-5c30-44c3-84a8-c3be44ead9d0"
> 
> on the kernel command line.
> 
> Please remove the apostrophes and retry!
> 
> it should look like this: boot=UUID=28920d27-5c30-44c3-84a8-c3be44ead9d0
> 
> !!!!!!!!!

Not to say that it should be with apostrophes, but why does the exact same line (with apostrophes) work on RHEL-5 and RHEL-7?

(In reply to Hubert Kario from comment #46)
> Not to say that it should be with apostrophes, but why does the exact same
> line (with apostrophes) work on RHEL-5 and RHEL-7?

Well, in RHEL-5 there is no dracut and the old mkinitrd does not even understand boot=... kernel command line parameter.

Hmm, and if it works in RHEL-7, I would call it a bug.

(In reply to Harald Hoyer from comment #47)
> (In reply to Hubert Kario from comment #46)
> > Not to say that it should be with apostrophes, but why does the exact same
> > line (with apostrophes) work on RHEL-5 and RHEL-7?
> 
> Well, in RHEL-5 there is no dracut and the old mkinitrd does not even
> understand boot=... kernel command line parameter.
> 
> Hmm, and if it works in RHEL-7, I would call it a bug.

ok

I scheduled a run on the sun machine, using /dev path, will see what dracut reports then

This may be totally unrelated, but check out https://bugzilla.redhat.com/show_bug.cgi?id=1016146

Is this the same bug?

(In reply to Suzanne Forsberg from comment #49)
> This may be totally unrelated, but check out
> https://bugzilla.redhat.com/show_bug.cgi?id=1016146
> 
> Is this the same bug?

Hmm, not really.

see https://bugzilla.redhat.com/show_bug.cgi?id=1016706

sha512sum -c <empty-file> always return with 0 (true)

But in this case, when the file could not even be found, dracut errors out earlier:

    if ! [ -e "/boot/.vmlinuz-${KERNEL}.hmac" ]; then
        warn "/boot/.vmlinuz-${KERNEL}.hmac does not exist"
        return 1
    fi

Created attachment 812872 [details]
Run with UUID, rdinitdebug and quiet

The system crashes when boot= is specified with UUID without quotes too, same trace as before.

Created attachment 812967 [details]
Run with /dev path, rdinitdebug and quiet

Run from the dell machine with /dev/ path for boot= kernel option and dracut debug messages.

(In reply to Hubert Kario from comment #54)
> Created attachment 812967 [details]
> Run with /dev path, rdinitdebug and quiet
> 
> Run from the dell machine with /dev/ path for boot= kernel option and dracut
> debug messages.

dracut: ++ mount -oro /dev/sdb1 /boot  
dracut: mount: unknown filesystem type 'LVM2_member'  

If /boot is in the same LVM as the root partition, you must not specify boot=...

user error

(In reply to Harald Hoyer from comment #56)
> (In reply to Hubert Kario from comment #54)
> > Created attachment 812967 [details]
> > Run with /dev path, rdinitdebug and quiet
> > 
> > Run from the dell machine with /dev/ path for boot= kernel option and dracut
> > debug messages.
> 
> dracut: ++ mount -oro /dev/sdb1 /boot  
> dracut: mount: unknown filesystem type 'LVM2_member'  
> 
> If /boot is in the same LVM as the root partition, you must not specify
> boot=...
> 
> user error

or boot=/dev/sdb1 points to the wrong partition here.

(In reply to Harald Hoyer from comment #56)
> (In reply to Hubert Kario from comment #54)
> > Created attachment 812967 [details]
> > Run with /dev path, rdinitdebug and quiet
> > 
> > Run from the dell machine with /dev/ path for boot= kernel option and dracut
> > debug messages.
> 
> dracut: ++ mount -oro /dev/sdb1 /boot  
> dracut: mount: unknown filesystem type 'LVM2_member'  
> 
> If /boot is in the same LVM as the root partition, you must not specify
> boot=...
> 
> user error

not user error, for some reason kernel does reassign device names

Note that the system is installed on two disks.

What with the UUID run?

(In reply to Hubert Kario from comment #58)
> (In reply to Harald Hoyer from comment #56)
> > (In reply to Hubert Kario from comment #54)
> > > Created attachment 812967 [details]
> > > Run with /dev path, rdinitdebug and quiet
> > > 
> > > Run from the dell machine with /dev/ path for boot= kernel option and dracut
> > > debug messages.
> > 
> > dracut: ++ mount -oro /dev/sdb1 /boot  
> > dracut: mount: unknown filesystem type 'LVM2_member'  
> > 
> > If /boot is in the same LVM as the root partition, you must not specify
> > boot=...
> > 
> > user error
> 
> not user error, for some reason kernel does reassign device names

Yes, the kernel does that, and therefore we recommend the usage of UUID= or LABEL=.

> 
> Note that the system is installed on two disks.
> 
> What with the UUID run?

The UUID run is a total different error. The aesni-intel module could not be loaded on this machine. Apparently you installed dracut-fips-aesni on a non-intel CPU machine, which cannot work. There is a reason, why dracut-fips-aesni is in a separate package.

dracut: FATAL: Error inserting aesni_intel (/lib/modules/2.6.32-358.el6.x86_64/kernel/arch/x86/crypto/aesni-intel.ko): No such device

(In reply to Harald Hoyer from comment #59)
> (In reply to Hubert Kario from comment #58)
> > (In reply to Harald Hoyer from comment #56)
> > > (In reply to Hubert Kario from comment #54)
> > > > Created attachment 812967 [details]
> > > > Run with /dev path, rdinitdebug and quiet
> > > > 
> > > > Run from the dell machine with /dev/ path for boot= kernel option and dracut
> > > > debug messages.
> > > 
> > > dracut: ++ mount -oro /dev/sdb1 /boot  
> > > dracut: mount: unknown filesystem type 'LVM2_member'  
> > > 
> > > If /boot is in the same LVM as the root partition, you must not specify
> > > boot=...
> > > 
> > > user error
> > 
> > not user error, for some reason kernel does reassign device names
> 
> Yes, the kernel does that, and therefore we recommend the usage of UUID= or
> LABEL=.
> 
> > 
> > Note that the system is installed on two disks.
> > 
> > What with the UUID run?
> 
> The UUID run is a total different error. The aesni-intel module could not be
> loaded on this machine. Apparently you installed dracut-fips-aesni on a
> non-intel CPU machine, which cannot work. There is a reason, why
> dracut-fips-aesni is in a separate package.
> 
> dracut: FATAL: Error inserting aesni_intel
> (/lib/modules/2.6.32-358.el6.x86_64/kernel/arch/x86/crypto/aesni-intel.ko):
> No such device

that was installed by errata tool, all runs that used the older dracut (303) won't have it installed

I've scheduled a run with a script that makes sure that the package is installed only on supported arches

Created attachment 813804 [details]
Run with UUID, rdinitdebug and quiet, dracut-fips-aesni installed

It crashes with dracut-fips-aesni installed on machine with aes-ni when using boot=UUID=

(In reply to Hubert Kario from comment #61)
> Created attachment 813804 [details]
> Run with UUID, rdinitdebug and quiet, dracut-fips-aesni installed
> 
> It crashes with dracut-fips-aesni installed on machine with aes-ni when
> using boot=UUID=

Please control the boot parameters before you attach the logs here!!!

For this run, you specified an empty "boot=UUID="

If this does turn out to be "user error," let's make sure it is documented clearly for the user.

(In reply to Ann Marie Rubin from comment #64)
> If this does turn out to be "user error," let's make sure it is documented
> clearly for the user.

I'm verifying now different configurations (with/without UUID, AES-NI, no AES-NI, etc.) and can't hit the problem again, either with new or old dracut so ATM it does look like user error (I still have few tests to run on the first box I encountered the problem on so please don't close the bug).

I'd say that not only it should be documented a bit better, but the error messages should be related to the mistake perpetrated by the user. From my point of view, the "/boot/.vmlinuz-2.6.32-358.18.1.el6.x86_64.hmac does not exist" is a "general failure" kind of error...

Looks like it was indeed just configuration/scripting problem. Updated summary and keywords to reflect that.

(In reply to Hubert Kario from comment #66)
> Looks like it was indeed just configuration/scripting problem. Updated
> summary and keywords to reflect that.

CLOSED, NOTABUG ????

Sorry, didn't see the Summary change...

Summary: Enabling FIPS mode does cause kernel panic (.vmlinuz*.hmac does not exist) → Unhelpful error messages in misconfigured system when booting in FIPS mode (.vmlinuz*.hmac does not exist)

fixed since dracut >= 004-327

oops, closed wrong bug