Bug 1158836

and why is this assigned to dracut?

Can you attach the output of:

# journalctl -b

after you logged in from the CLI?

(In reply to Harald Hoyer from comment #1)
> and why is this assigned to dracut?
> 
> Can you attach the output of:
> 
> # journalctl -b
> 
> after you logged in from the CLI?

best after a failed attempt on the GUI login

Created attachment 952389 [details]
the journalctl -b cmd log

Oct 31 11:51:26 localhost.localdomain systemd-logind[628]: New session 2 of user root.
Oct 31 11:51:26 localhost.localdomain systemd-logind[628]: Linked /tmp/.X11-unix/X0 to /run/user/0/X11-display.
Oct 31 11:51:26 localhost.localdomain gdm-password][2638]: pam_unix(gdm-password:session): session opened for user root by (unknown)(uid=0)
Oct 31 11:51:26 localhost.localdomain gnome-keyring-daemon[2653]: Libgcrypt warning: custom allocation handler - FIPS mode inactivated


Don't know, if the gnome-keyring warning is preventing the login, but it is definitely not dracut.

Additionally, you could file a bug for:

Oct 31 11:49:29 localhost.localdomain initial-setup[646]: kickstart parsing failed
                                                          Traceback (most recent call last):
                                                            File "/usr/lib/python2.7/site-packages/initial_setup/__main__.py", line 99, in <module>
                                                              parser.readKickstart(INPUT_KICKSTART_PATH)
                                                            File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 733, in readKickstart
                                                              self.readKickstartFromString(s, reset=False)
                                                            File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 706, in readKickstartFromString
                                                              self._stateMachine (i)
                                                            File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 681, in _stateMachine
                                                              self._tryFunc(lambda: obj.handleHeader(lineno, args))
                                                            File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 609, in _tryFunc
                                                              fn()
                                                            File "/usr/lib/python2.7/site-packages/pykickstart/parser.py", line 681, in <lambda>
                                                              self._tryFunc(lambda: obj.handleHeader(lineno, args))
                                                            File "/usr/lib64/python2.7/site-packages/pyanaconda/addons.py", line 195, in handleHeader
                                                              addon.handle_header(lineno, args[2:])
                                                            File "/usr/lib64/python2.7/site-packages/pyanaconda/addons.py", line 152, in handle_header
                                                              raise KickstartParseError(formatErrorMsg(lineno, msg=msg))
                                                          KickstartParseError: The following problem occurred on line 53 of the kickstart file:
                                                          
                                                          Unhandled arguments on %addon line for com_redhat_kdump
Oct 31 11:49:29 localhost.localdomain systemd[1]: initial-setup-text.service: main process exited, code=exited, status=1/FAILURE
Oct 31 11:49:29 localhost.localdomain systemd[1]: Failed to start Initial Setup configuration program (text mode).
Oct 31 11:49:29 localhost.localdomain systemd[1]: Unit initial-setup-text.service entered failed state.

The log message from gnome-keyring-daemon is a warning (which indicates that the return value of gcry_fips_mode_active(), which is unused by gnome-keyring-daemon, would be false), and does not affect whether gnome-keyring-daemon starts, so it is unlikely that this problem is caused by a bug in gnome-keyring-daemon. The gnome-keyring PAM module is marked as optional in the PAM configuration, so I do not suppose that gnome-keyring-daemon failing to start would lead to a failed login.

If it is only graphical login that is affected, gdm would probably be the relevant product, although the logs do not give much information. Hopefully, Ray (halfine, the gdm maintainer) has some insights. I do not suppose that graphical login as root is well tested, however.

fips mode seems to work here.

Can I get you to:

1) mkdir -p /var/log/journal
2) edit /etc/gdm/custom.conf to have 

Enable=true 

in the [debug] section
3) reboot (make sure fips mode is enabled)
4) reproduce
5) attach the output of journalctl -b -l to this bug report

sorry for the delay to handle this bug cause in RHEL7.1 build 20141011 the fips mode works fine. So I'm waiting another build to see if the bug will shows again. and now the bug shows again with different appearance as the screenshot I attached.

Created attachment 962381 [details]
fips mode failed to start

Created attachment 962384 [details]
the journalctl -b -l log as asked

Issue no longer occurs. 

Adding versions of components: 
kernel-3.10.0-229.el7.x86_64
gdm-3.14.1-3.el7.x86_64
gnome-shell-3.14.2-3.el7.x86_64
dracut-fips-033-240.el7.x86_64
hmaccalc-0.9.13-4.el7.x86_64

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://rhn.redhat.com/errata/RHBA-2015-2216.html