Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1150641

Summary: X fails to start after yum update
Product: Red Hat Enterprise Linux 7 Reporter: Martin Frodl <mfrodl>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED NOTABUG QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: lnykryn, mmalik, pmoore, systemd-maint-list
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-09 11:43:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
List of updated/newly installed packages from /var/log/yum.log
none
journalctl output none

Description Martin Frodl 2014-10-08 14:57:45 UTC
Created attachment 945047 [details]
List of updated/newly installed packages from /var/log/yum.log

Description of problem:

Yesterday I ran 'yum update' on my system, resulting in a total of 407 packages being updated or newly installed (see complete list of these packages in attachment). After reboot, X system failed to start normally; instead, the following messaged appeared:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot into default mode.
Give root password for maintenance
(or type Control-D to continue):

I logged in and tried running 'systemctl default' but the previous error screen reappeared soon after. I was only able to continue to the X login screen after running 'setenforce 0'. After logging in, instead of executing Gnome, this login screen turned up again.

I was only able to get to Gnome after running 'X :1', then 'DISPLAY=:1 gnome-session' and pressing Ctrl+Alt+F5 (all in Permissive mode).

There is a whole bunch of packages that had been changed prior to this issue, so I have unfortunately little idea as to which of them can cause it. I chose to set the component to systemd since journalctl log contained quite a few systemd errors, but it can as well be another package. I am attaching my journalctl output should it be of any help. These lines caught my attention in particular, but it may as well be a false alarm (I don't know what the log usually looks like):

Oct 08 09:52:26 dhcp-24-105.brq.redhat.com systemd[1]: Starting GNOME Display Manager...
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com colord[2909]: device removed: xrandr-eDP1
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com colord[2909]: device removed: xrandr-NEC Corporation-E231W-43323960NB
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com colord[2909]: Profile removed: icc-0e29edb081153273e0c3678821524a42
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com colord[2909]: Profile removed: icc-4dbe4dc588e7bbb10f7f769959108489
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com colord[2909]: Profile removed: icc-e524b375f695441f0b23163c0a6ba1ba
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com gdm-launch-environment][3967]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com gdm[1108]: GLib-GObject: g_object_unref: assertion 'object->ref_count > 0' failed
[^^^ THIS LINE IS RED ^^^]
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com polkitd[1196]: Unregistered Authentication Agent for unix-session:c2 (system bus name :1.77, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Oct 08 09:52:26 dhcp-24-105.brq.redhat.com systemd[1]: Started GNOME Display Manager.


Version-Release number of selected component (if applicable):
(see attached list of updated/installed packages)

Comment 1 Martin Frodl 2014-10-08 15:01:55 UTC
Created attachment 945049 [details]
journalctl output

Comment 3 Lukáš Nykrýn 2014-10-08 15:19:30 UTC
Oct 08 09:57:31 dhcp-24-105.brq.redhat.com gnome-session[6713]: libGL error: failed to open drm device: Permission denied
Oct 08 09:57:31 dhcp-24-105.brq.redhat.com gnome-session[6713]: libGL error: failed to load driver: i965

This looks quite suspicious, I don't think that your problem was caused by systemd. Lets look to the selinux part.

Meanwhile can you try 'touch /autorelabel' and reboot?

Comment 4 Milos Malik 2014-10-08 19:52:57 UTC
The first AVC I found in the journal records is:

Oct 08 09:45:16 dhcp-24-105.brq.redhat.com kernel: type=1400 audit(1412754316.033:4): avc:  denied  { write } for  pid=810 comm="systemd-cryptse" scontext=system_u:system_r:lvm_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket

Something is not correctly labeled on your machine. Everything that followed could be just a consequence.

Please reboot your machine with kernel parameter: enforcing=0

And then do the whole file-system relabel:
# touch /.autorelabel
# reboot

Comment 5 Martin Frodl 2014-10-08 21:18:34 UTC
Ran 'touch /.autorelabel' and rebooted with 'enforcing=0' kernel parameter. On startup, the relabel took place just as expected, yet it does not seem to have made much difference. In particular, the AVC message you mention remains virtually the same in the new journalctl -xb output:

Oct 08 22:52:54 dhcp-24-105.brq.redhat.com kernel: type=1400 audit(1412801574.357:4): avc:  denied  { write } for  pid=828 comm="systemd-cryptse" scontext=system_u:system_r:lvm_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket

Anyway, I would like to share another possibly useful piece information -- this is what the last few lines of /var/log/boot.log look like, now as before:

...
[  OK  ] Started Activation of DM RAID sets.
[FAILED] Failed to start Cryptography Setup for luks-00b97a4e-e3b8-458a-87fe-96a6fa484509.
See 'systemctl status systemd-cryptsetup@luks\x2d00b97a4e\x2de3b8\x2d458a\x2d87fe\x2d96a6fa484509.service' for details.
[DEPEND] Dependency failed for Encrypted Volumes.
[DEPEND] Dependency failed for /home.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Relabel all filesystems, if necessary.
[DEPEND] Dependency failed for Mark the need to relabel after reboot.

Comment 6 Martin Frodl 2014-10-09 09:05:37 UTC
Digging further into the issue, I have a suspicion that a botched yum update is to blame. Apparently, the update did not went quite smoothly, rendering the current yum database broken. I seem to be unable to perform another yum update and/or yum distro-sync, even with the --skip-broken option. I will try to fix the database by installing some dependencies manually and will report on my progress later.

Comment 7 Martin Frodl 2014-10-09 11:43:55 UTC
Having done a handful of manual yum {upgrade|downgrade|removes}s, I ran yum distro-sync again. As a result, most of the 407 formerly updated packages were downgraded again. After reboot, X started normally and we have been living happily together ever after.

Looking at the list of upgraded packages in attachment 945047 [details], it is obvious that most of them have not been released yet -- indeed, I can see a couple packages I am QA'ing at this very moment. It appears I must have had some repository set up that provided packages from RHEL-7.1-20141006.1 or a similar compose. This does not seem to be the case any longer: according to 'yum update', there are 'No packages marked for update'.

I will take the liberty of closing this bug right now as NOTABUG -- it does not seem to be a real issue provided the repositories and/or subscription are set up correctly.

Comment 8 Miroslav Grepl 2014-10-09 15:03:27 UTC
This is a kernel issue.