Bug 691419

Is the boot device specified on the kernel command line?

"boot=<boot partition>"

there is no boot= entry on the kernel command line.

does it work, if you add it?

(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.

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.

(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?

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?

Please attach the bootloader configuration as written by anaconda before any modification to this bug report.

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.

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.

(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"

Vhen leaving the boot= parameter at the location where anaconda placed it but replacing the UUID with /dev/vda1, it works (the system boots).

Created attachment 488751 [details]
dracut with rdinitdebug

Attaching a rdinitdebug log

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.

I would say this is desirable. By booting with FIPS=1, the user has indicated they want FIPS compliance.

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.

> 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.

(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.

http://git.kernel.org/?p=boot/dracut/dracut.git;a=commitdiff;h=4ac0cbad25f42b57fc082f89af5da7ba3355eb20

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..

fix works for me

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.

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