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 1158836 - Can't log into the GUI desktop after enable the FIPS mode in RHEL7.1
Summary: Can't log into the GUI desktop after enable the FIPS mode in RHEL7.1
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gdm
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-30 10:42 UTC by xingge
Modified: 2016-09-20 02:28 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 07:13:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
the journalctl -b cmd log (113.78 KB, text/plain)
2014-10-31 04:35 UTC, xingge 		no flags Details
fips mode failed to start (62.49 KB, image/png)
2014-11-28 07:27 UTC, xingge 		no flags Details
the journalctl -b -l log as asked (350.92 KB, text/x-vhdl)
2014-11-28 07:42 UTC, xingge 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2216 0 normal SHIPPED_LIVE gnome compositor stack bug fix and enhancement update 2015-11-19 08:26:34 UTC

Description xingge 2014-10-30 10:42:00 UTC 
Description of problem:
Can't log into the GUI desktop after enable the FIPS mode in RHEL7.1

Version-Release number of selected component (if applicable):
system : RHEL7.1-server-20141029.0
dracut-fips-033-224.el7.x86_64
hmaccalc-0.9.14-4.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.Install the newest RHEL7.1 build RHEL7.1-20141029
1.Install dracut-fips and hmaccalc 
2.Open /boot/grub2/grub.cfg add "fips=1" in the line "linux16 /vmlinuz ***"
3.Reboot the system

Actual results:
After reboot I can't log in the system from GUI. After I input the username and password, It stays in the log in page.

Expected results:
log in should be succeed.

Additional info:
After I shift to the CLI interface I successfully logged into the system
Comment 1 Harald Hoyer 2014-10-30 14:16:37 UTC 
and why is this assigned to dracut?

Can you attach the output of:

# journalctl -b

after you logged in from the CLI?
Comment 2 Harald Hoyer 2014-10-30 14:18:13 UTC 
(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
Comment 3 xingge 2014-10-31 04:35:36 UTC 
Created attachment 952389 [details]
the journalctl -b cmd log
Comment 4 Harald Hoyer 2014-11-04 15:27:26 UTC 
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.
Comment 5 Harald Hoyer 2014-11-04 15:28:38 UTC 
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.
Comment 6 David King 2014-11-04 16:02:24 UTC 
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.
Comment 7 Ray Strode [halfline] 2014-11-12 18:39:46 UTC 
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
Comment 8 xingge 2014-11-28 07:25:36 UTC 
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.
Comment 9 xingge 2014-11-28 07:27:51 UTC 
Created attachment 962381 [details]
fips mode failed to start
Comment 10 xingge 2014-11-28 07:42:11 UTC 
Created attachment 962384 [details]
the journalctl -b -l log as asked
Comment 12 Ladislav Kolacek 2015-05-14 14:29:58 UTC 
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
Comment 17 errata-xmlrpc 2015-11-19 07:13:22 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.