The fifo_file is a known problem with a leak in systemd.  THe exemod is a different problem  which I have not seen.  Could you attach the AVC's for the execmod/  We should not be seeing these on an executable, could be a problem with gcc.

Can you be a little more specific on that? Is this a file that you want attached or a cut and paste from a log file?

ausearch -m avc -ts -i

Will dump all avcs that you have.

Ok, this happened again with the latest iso that I build for ppc64le
So I booted rescue:


sh-4.3# chroot /mnt/sysimage/
bash-4.3# ausearch -m avc -ts -i
-ts requires either date and/or time
type=UNKNOWN[1327] msg=audit(05/07/2014 14:05:12.650:11) : proctitle=2F7573722F7362696E2F69727162616C616E6365002D2D666F726567726F756E64
type=SYSCALL msg=audit(05/07/2014 14:05:12.650:11) : arch=ppc64 syscall=mprotect success=no exit=-13(Permission denied) a0=0x221e0000 a1=0x10000 a2=PROT_READ|PROT_EXEC a3=0x0 items=0 ppid=1 pid=2852 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=irqbalance exe=/usr/sbin/irqbalance subj=system_u:system_r:irqbalance_t:s0 key=(null)
type=AVC msg=audit(05/07/2014 14:05:12.650:11) : avc:  denied  { execmod } for  pid=2852 comm=irqbalance path=/usr/sbin/irqbalance dev="dm-0" ino=663594 scontext=system_u:system_r:irqbalance_t:s0 tcontext=system_u:object_r:irqbalance_exec_t:s0 tclass=file
----
type=UNKNOWN[1327] msg=audit(05/07/2014 14:05:12.750:14) : proctitle=2F62696E2F646275732D6461656D6F6E002D2D73797374656D002D2D616464726573733D73797374656D643A002D2D6E6F666F726B002D2D6E6F70696466696C65002D2D73797374656D642D61637469766174696F6E
type=SYSCALL msg=audit(05/07/2014 14:05:12.750:14) : arch=ppc64 syscall=mprotect success=no exit=-13(Permission denied) a0=0x57e2000^[[1;23r^[[23;1H
^[[131C^[M00 a1=0x80000 a2=PROT_READ|PROT_EXEC a3=0x0 items=0 ppid=1 pid=2864 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=dbus-daemon exe=/usr/bin/dbus-daemon subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(05/07/2014 14:05:12.750:14) : avc:  denied  { execmod } for  pid=2864 comm=dbus-daemon path=/usr/bin/dbus-daemon dev="dm-0" ino=660769 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file
----
type=UNKNOWN[1327] msg=audit(05/07/2014 14:06:02.809:31) : proctitle=2F62696E2F646275732D6461656D6F6E002D2D73797374656D002D2D616464726573733D73797374656D643A002D2D6E6F666F726B002D2D6E6F70696466696C65002D2D73797374656D642D61637469766174696F6E
type=SYSCALL msg=audit(05/07/2014 14:06:02.809:31) : arch=ppc64 syscall=mprotect success=no exit=-13(Permission denied) a0=0x5d280000 a1=0x80000 a2=PROT_READ|PROT_EXEC a3=0x0 items=0 ppid=1 pid=2970 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=dbus-daemon exe=/usr/bin/dbus-daemon subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(05/07/2014 14:06:02.809:31) : avc:  denied  { execmod } for  pid=2970 comm=dbus-daemon path=/usr/bin/dbus-daemon dev="dm-0" ino=660769 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file
----
type=UNKNOWN[1327] msg=audit(05/07/2014 14:06:52.899:38) : proctitle=2F62696E2F646275732D6461656D6F6E002D2D73797374656D002D2D616464726573733D73797374656D643A002D2D6E6F666F726B002D2D6E6F70696466696C65002D2D73797374656D642D61637469766174696F6E
type=SYSCALL msg=audit(05/07/2014 14:06:52.899:38) : arch=ppc64 syscall=mprotect success=no exit=-13(Permission denied) a0=0x29f20000 a1=0x80000 a2=PROT_READ|PROT_EXEC a3=0x0 items=0 ppid=1 pid=2975 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=dbus-daemon exe=/usr/bin/dbus-daemon subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(05/07/2014 14:06:52.899:38) : avc:  denied  { execmod } for  pid=2975 comm=dbus-daemon path=/usr/bin/dbus-daemon dev="dm-0" ino=660769 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file

Hrm, A little corruption in capturing the output:

----
type=UNKNOWN[1327] msg=audit(05/07/2014 14:05:12.650:11) : proctitle=2F7573722F7362696E2F69727162616C616E6365002D2D666F726567726F756E64 
type=SYSCALL msg=audit(05/07/2014 14:05:12.650:11) : arch=ppc64 syscall=mprotect success=no exit=-13(Permission denied) a0=0x221e0000 a1=0x10000 a2=PROT_READ|PROT_EXEC a3=0x0 items=0 ppid=1 pid=2852 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=irqbalance exe=/usr/sbin/irqbalance subj=system_u:system_r:irqbalance_t:s0 key=(null) 
type=AVC msg=audit(05/07/2014 14:05:12.650:11) : avc:  denied  { execmod } for  pid=2852 comm=irqbalance path=/usr/sbin/irqbalance dev="dm-0" ino=663594 scontext=system_u:system_r:irqbalance_t:s0 tcontext=system_u:object_r:irqbalance_exec_t:s0 tclass=file 
----
type=UNKNOWN[1327] msg=audit(05/07/2014 14:05:12.750:14) : proctitle=2F62696E2F646275732D6461656D6F6E002D2D73797374656D002D2D616464726573733D73797374656D643A002D2D6E6F666F726B002D2D6E6F70696466696C65002D2D73797374656D642D61637469766174696F6E 
type=SYSCALL msg=audit(05/07/2014 14:05:12.750:14) : arch=ppc64 syscall=mprotect success=no exit=-13(Permission denied) a0=0x57e20000 a1=0x80000 a2=PROT_READ|PROT_EXEC a3=0x0 items=0 ppid=1 pid=2864 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=dbus-daemon exe=/usr/bin/dbus-daemon subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(05/07/2014 14:05:12.750:14) : avc:  denied  { execmod } for  pid=2864 comm=dbus-daemon path=/usr/bin/dbus-daemon dev="dm-0" ino=660769 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file 
----
type=UNKNOWN[1327] msg=audit(05/07/2014 14:06:02.809:31) : proctitle=2F62696E2F646275732D6461656D6F6E002D2D73797374656D002D2D616464726573733D73797374656D643A002D2D6E6F666F726B002D2D6E6F70696466696C65002D2D73797374656D642D61637469766174696F6E 
type=SYSCALL msg=audit(05/07/2014 14:06:02.809:31) : arch=ppc64 syscall=mprotect success=no exit=-13(Permission denied) a0=0x5d280000 a1=0x80000 a2=PROT_READ|PROT_EXEC a3=0x0 items=0 ppid=1 pid=2970 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=dbus-daemon exe=/usr/bin/dbus-daemon subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(05/07/2014 14:06:02.809:31) : avc:  denied  { execmod } for  pid=2970 comm=dbus-daemon path=/usr/bin/dbus-daemon dev="dm-0" ino=660769 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file 
----
type=UNKNOWN[1327] msg=audit(05/07/2014 14:06:52.899:38) : proctitle=2F62696E2F646275732D6461656D6F6E002D2D73797374656D002D2D616464726573733D73797374656D643A002D2D6E6F666F726B002D2D6E6F70696466696C65002D2D73797374656D642D61637469766174696F6E 
type=SYSCALL msg=audit(05/07/2014 14:06:52.899:38) : arch=ppc64 syscall=mprotect success=no exit=-13(Permission denied) a0=0x29f20000 a1=0x80000 a2=PROT_READ|PROT_EXEC a3=0x0 items=0 ppid=1 pid=2975 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=dbus-daemon exe=/usr/bin/dbus-daemon subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(05/07/2014 14:06:52.899:38) : avc:  denied  { execmod } for  pid=2975 comm=dbus-daemon path=/usr/bin/dbus-daemon dev="dm-0" ino=660769 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file

This is either a kernel issue or a glibc issue.  We saw similar things happening on arm.

You mean glibc, right?

Yes sorry.

This just appeared on mine after updating yesterday.

systemd-logind.service entered failed state - has no holdoff time - i686 - broken by glibc
https://bugzilla.redhat.com/show_bug.cgi?id=1121419

2.19.90-29 breaks setuid32 on i686.
https://bugzilla.redhat.com/show_bug.cgi?id=1120473

I *think* this affects today's Workstation compose: http://koji.fedoraproject.org/koji/taskinfo?taskID=7408543

This live image will not boot (running as a guest in gnome-boxes, I did not try on real hardware) in enforcing mode, logind won't start.

Using the same method used in the bug description to get some data:
[root@localhost ~]# audit2allow --all --module=hack > /tmp/hack.te
[root@localhost ~]# cat /tmp/hack.te 

module hack 1.0;

require {
	type geoclue_t;
	type unconfined_t;
	type semanage_store_t;
	type init_t;
	type systemd_localed_t;
	type systemd_logind_t;
	type unconfined_service_t;
	type NetworkManager_t;
	type policykit_t;
	type setroubleshoot_var_lib_t;
	type system_dbusd_t;
	type accountsd_t;
	type colord_t;
	type rpm_t;
	type bluetooth_t;
	type rtkit_daemon_t;
	type systemd_hostnamed_t;
	type rpm_var_lib_t;
	type unlabeled_t;
	type security_t;
	class process { transition signull };
	class unix_stream_socket connectto;
	class dbus { acquire_svc send_msg };
	class file { execute setattr read create getattr execute_no_trans ioctl open };
	class security read_policy;
	class lnk_file { read getattr };
	class dir { write search read open add_name };
}

#============= NetworkManager_t ==============
allow NetworkManager_t init_t:dbus acquire_svc;
allow NetworkManager_t unlabeled_t:file execute;
allow NetworkManager_t unlabeled_t:lnk_file read;

#============= accountsd_t ==============
allow accountsd_t init_t:dbus acquire_svc;
allow accountsd_t unconfined_service_t:dbus send_msg;

#============= bluetooth_t ==============
allow bluetooth_t init_t:dbus { acquire_svc send_msg };
allow bluetooth_t init_t:unix_stream_socket connectto;

#============= colord_t ==============
allow colord_t init_t:dbus { acquire_svc send_msg };

#============= geoclue_t ==============
allow geoclue_t init_t:dbus { acquire_svc send_msg };

#============= policykit_t ==============
allow policykit_t init_t:dbus acquire_svc;
allow policykit_t unlabeled_t:file { read execute open execute_no_trans };

#============= rtkit_daemon_t ==============
allow rtkit_daemon_t init_t:dbus { acquire_svc send_msg };

#============= system_dbusd_t ==============
allow system_dbusd_t init_t:dbus acquire_svc;
allow system_dbusd_t rpm_t:process signull;
allow system_dbusd_t rpm_var_lib_t:dir { write add_name };
allow system_dbusd_t rpm_var_lib_t:file { create open };
allow system_dbusd_t security_t:security read_policy;
allow system_dbusd_t semanage_store_t:dir { read search open };
allow system_dbusd_t semanage_store_t:file { read getattr open };
allow system_dbusd_t setroubleshoot_var_lib_t:dir { write add_name };
allow system_dbusd_t setroubleshoot_var_lib_t:file { create open getattr setattr };
allow system_dbusd_t unlabeled_t:file { ioctl open execute execute_no_trans getattr };
allow system_dbusd_t unlabeled_t:lnk_file { read getattr };

#============= systemd_hostnamed_t ==============
allow systemd_hostnamed_t init_t:dbus { acquire_svc send_msg };

#============= systemd_localed_t ==============
allow systemd_localed_t init_t:dbus acquire_svc;
allow systemd_localed_t init_t:unix_stream_socket connectto;

#============= systemd_logind_t ==============
allow systemd_logind_t init_t:dbus acquire_svc;
allow systemd_logind_t unconfined_service_t:dbus send_msg;

#============= unconfined_service_t ==============
allow unconfined_service_t unconfined_t:process transition;




As such I'm proposing this bug as an Alpha blocker.

Criteria: Release blocking images must boot (https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Release-blocking_images_must_boot)
    *and*
 SELinux must be enabled on Enforcing (https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#SELinux_configuration)

comment 10 and comment 11 are misleading and are different bugs that affect i686.  I assume this one is specific to ppc64le given that it blocks the PPC64LETracker?

I'm seeing this problem on x86_64

Yesterday's compose (http://koji.fedoraproject.org/koji/taskinfo?taskID=7427042) is not affected. I don't know if anything was done to fix it, or if it's random based on some failure in the compose process.

QA Team: Please consider this when discussing blocker status.

This has the potential to bork an entire system.  Without a root cause, how will we know it won't come back?  Until we have that, I think it should still be a blocker.

Discussed in 2014-08-20 Blocker Review Meeting [1].

According to sgallagh, this is most probably caused by #1127103 and should be resolved once it is fixed. We will re-evaluate this bug if it still persists after #1127103 is fixed. Punted for now.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-08-20/

Discussed at 2014-08-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-08-27/f21-blocker-review.2014-08-27-15.59.log.txt . Rejected as a blocker - there is now a workaround in place in releng so this is not preventing image compose. The question of whether the Atomic image blocks the Alpha release becomes moot, as this bug no longer prevents it being generated.

(In reply to Josef Skladanka from comment #17)
> Discussed in 2014-08-20 Blocker Review Meeting [1].
> 
> According to sgallagh, this is most probably caused by #1127103 and should
> be resolved once it is fixed. We will re-evaluate this bug if it still
> persists after #1127103 is fixed. Punted for now.
> 
> [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-08-20/

So what was the verdict?

(In reply to Joseph D. Wagner from comment #16)
> This has the potential to bork an entire system.  Without a root cause, how
> will we know it won't come back?  Until we have that, I think it should
> still be a blocker.

Not only does it have the potential, but this issue just took down my Linux Box.  It's been running for years without a problem.  Because of SystemD I am finally forced to install another distribution that doesn't take itself down.  I've been running Fedora since Fedora 10 or 12 (so long ago I can't remember).  Well I just wanted to say farewell to the Fedora community.

Siddhesh: the 'verdict' so far as the blocker process at the time is concerned was in #c18. The change considered a 'workaround' for #1127103 at the time was institutionalized as a 'fix', I believe. We did not have further issues with composing the Atomic images so far as I know, so this kind of died on the vine.

If anyone's seeing the service startup fail on current builds it might be best to start over with a new bug, I think?

Thanks Adam, I was referring to #1127103 and whether that was found to be the root of the problem.  I agree with starting over with a new bug with a clear description of the problem from whoever is currently able to reproduce this. It seems like multiple possibly unrelated problems are being confused here.  I'll close this as insufficient_data if it's OK.

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

I got a broken Fedora 21 - booting fails  with Failed to start Login Service.
This is not the only error message in system.journal 

How to upload the file??

The upload of the system.journal from systemd fails.:-(

Created attachment 1006238 [details]
attachment for comment  24

No console login was provided either - I had to boot into Ubuntu to get the Fedora log.

remark:
from system.journal 
....
Mär 24 23:10:08 ico-01 systemctl[665]: Libgcrypt error: integrity check using `/lib64/.libgcrypt.so.20.hmac' failed: No such file or directory
Mär 24 23:10:08 ico-01 systemctl[665]: libgcrypt selftest: binary  (0): No such file or directory (/lib64/.libgcrypt.so.20.hmac)
....
from ls:
user@ubuntu:~$ ll /mnt/sdcr/usr/lib64/.libgcrypt.so.20.hmac
-rw-r--r--. 1 root root 65 Mär  6 18:38 /mnt/sdcr/usr/lib64/.libgcrypt.so.20.hmac
......

looks like systemctl looks into a different direction.
(/mnt/sdcr is the mounted Fedora 21 root path)

I don't think your issue has anything to do with this bug report. Please file a new one. Note that on Fedora systems for the last few years, /lib is a symlink to /usr/lib . https://fedoraproject.org/wiki/Features/UsrMove

Because "[FAILED] Failed to start Login Service." was the most obvious message
I append my comments here.
Other systemd errors logged can be seen in the attachment.   

Symptoms:
No graphical login (system hangs), 
slow ssh login, 
yum update: dowloads OK - install stalls (in strace stops at  .. AUTH EXTERNAL .., .. polling ..)

Fix (quite cumbersome):
Boot into linux single   # systemctl set-default rescue
/usr/sbin/setenforce 0
# activate network
yum -y update ( dowload ok, after check it took a couple of minutes to start package install)
# yum stopped working when removing collectl. the scriptlet failed.
reboot; 

# same procedure as before - then
package-cleanup --cleandupes
#again stopped working when removing collectl. the scriptlet failed.
reboot:
# sledgehammer..
rpm -e --noscripts --notriggers collectl-3.7.4-1.fc21.noarch
rpm -e --noscripts --notriggers  qemu-guest-agent-2.1.3-5.fc21.x86_64

# see Bug 1204517 - update to libgcrypt-1.6.3-1 causes error messages 
# download libgcrypt-1.6.3-4.fc21.x86_64.rpm 
yum update libgcrypt-1.6.3-4.fc21.x86_64.rpm

reboot .. BACK TO NORMAL :-)

The system not coming up after a minimal install from the official Fedora 22 Netinst image seems 100% reproducible (I made 3 attempts in VirtualBox).  I see 3 error messages, the first about the inability to create tmp volatile directories, and the following two about being unable to generate SSH keys and to start systemd-logind.  I waited 15 minutes, but no login prompt appeared.  Shouldn't such an important bug be at least mentioned in the release notes?

Fedora 22 Server can be installed without problems from the same netinst image, it can boot and seems to behave as expected; I assume it also works from the DVD image, didn't try.  The XFCE Spin also works (installed from the live image).

Unfortunately I am experiencing this too. Exactly as they original poster described, I did a minimal installation and have extremely slow boot with login service, ntp, volatile directory failures. Eventually getting a login prompt but of course no user can login.

This is a new installation of 22 on a VM..

This is my first experience with Fedora as I have been using only Debian for years. I too think this is a serious bug that should get more priority. The reason is you have a new user like myself that tries your distro for the first time and gets stuck at login with a bug that's more than a year old.

Aside from that I truly appreciate the hard work that goes into your project and understand it's very complex and difficult to catch everything that may be wrong. So I will continue using a different 'spin' and await resolution to this bug..

Thanks,
Brett

I did multiple minimal installs of F22 during validation testing and they all booted fine. You both seem to inferring that this problem affects *all* minimal F22 installs, but that does not in fact seem to be the case.

It also means that I can't diagnose what's going wrong in your cases, because I can't reproduce the problem and you haven't attached any logs. So, it would at least be useful to be able to see the 'journalctl' output after booting in single-user mode, if you can do that.

It's possible that the affected scenario here is, somehow, 'minimal install to a VirtualBox VM', but I wouldn't want to draw that as a definite conclusion as #c30 does not state what virtualization software was in use.

Is there a known workaround for the 'Failed to start Login Service' problem?

I can boot by adding 'rescue' to the grub config, but when I do a 'systemctl start systemd-logind.service' it doesn't seem to complete.

I was working on fedup problem where a F21 system won't update to F22.
I just did a yum update on Fedora 21 and after a somewhat large 246M/318 packages, I now fail to get a login. I saved the output of the yum update.
I had just updated within a week or so as I have been working on what I assume are unrelated fedup issues.


  Updating   : selinux-policy-3.13.1-105.13.fc21.noarch                                                                                48/649 
libsemanage.semanage_install_active: Could not copy /etc/selinux/strict/modules/active/policy.kern to /etc/selinux/strict/policy/policy.29. (No such file or directory).
libsemanage.semanage_install_active: Could not copy /etc/selinux/strict/modules/active/policy.kern to /etc/selinux/strict/policy/policy.29. (No such file or directory).
semodule:  Failed!

then later

  Cleanup    : kernel-headers-3.18.9-200.fc21.i686                                                                                    648/649 
  Cleanup    : iwl6000g2b-firmware-18.168.6.1-43.fc21.noarch                                                                          649/649 
sed: warning: failed to get security context of /var/tmp/initramfs.PQht14/etc/lvm/lvm.conf: No data availablesed: warning: failed to get security context of /var/tmp/initramfs.PQht14/etc/lvm/lvm.conf: No data availablesed: warning: failed to get security context of /var/tmp/initramfs.PQht14/lib/udev/rules.d/69-dm-lvm-metad.rules: No data availablesed: warning: failed to get security context of /var/tmp/initramfs.PQht14/lib/udev/rules.d/69-dm-lvm-metad.rules: No data availablesed: warning: failed to get security context of /var/tmp/initramfs.PQht14/lib/udev/rules.d/69-dm-lvm-metad.rules: No data availablesed: warning: failed to get security context of /var/tmp/initramfs.PQht14/usr/lib/udev/rules.d/64-m

The big suspects that updated include:
ModemManager
NetworkManager
systemd including systemd-compat-libs and systemd-libs
and the selinux-policy set

---
I wait a while on a normal boot (30min? 1hr-ish maybe) I can login on the console, manually start eth0, then login locally & remote but get:
root@xyz's password: 
Unable to get valid context for root
Last login: Fri Jul 10 15:08:02 2015 from pdqxyz

So this is more likely a bad F21 update than the exact same problem...
Best guess a bad selinux policy given post boot from journalctl -xb:
...
Jul 10 14:18:12 xyz dbus-daemon[934]: Failed to start message bus: Failed to open "/etc/selinux/strict/contexts/dbus_contexts": No such file or directory
Jul 10 14:18:13 xyz NetworkManager[933]: <info>  NetworkManager (version 0.9.10.2-5.fc21) is starting...
Jul 10 14:18:13 xyz NetworkManager[933]: <info>  Read config: /etc/NetworkManager/NetworkManager.conf
Jul 10 14:18:13 xyz NetworkManager[933]: <info>  WEXT support is enabled
Jul 10 14:18:37 xyz systemd[1]: Failed to register match for Disconnected message: Connection timed out
Jul 10 14:18:37 xyz systemd-logind[932]: Failed to add match for NameOwnerChanged: Connection timed out
Jul 10 14:18:37 xyz systemd-logind[932]: Failed to fully start up daemon: Connection timed out
Jul 10 14:19:02 xyz systemd[1]: Failed to register match for Disconnected message: Connection timed out
...
Jul 10 14:19:02 xyz systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE
Jul 10 14:19:02 xyz systemd[1]: Failed to start Login Service.
-- Subject: Unit systemd-logind.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-logind.service has failed.
-- 
-- The result is failed.
...

# ls -l /etc/selinux/strict/modules/active/policy.kern
lrwxrwxrwx 1 root root 36 Jul 10 12:37 /etc/selinux/strict/modules/active/policy.kern -> /etc/selinux/strict/policy/policy.29
(which doesn't exist)

Maybe these breadcrumbs will help someone else that gets this error.
I have the journalctl -xb and pre-reboot yum update output if needed.

A 'quick' fix is to drop from strict to targeted.

Running F23 and experienced this issue (Failed to start Login Service) with selinux=permissive.  Changed to disabled and was able to boot again.

I've just had the "interesting" experience of being unable to install
F23 because the Live Xfce4 USB stick was unable to complete the boot
process.  The computer was an old, slow, but serviceable, IBM T30
laptop.

After removing the egregious 'rhgb' kernel boot option, I was able to
see that the "Login Service" failed to start 6 times, I think.  After
that we waited for "Terminate Plymouth boot screen", went to a black
blank screen, and recycled to the text screen - about once a minute,
or so.  The poor thing seemed to be trying its best to do something
wonderfully graphic, but just couldn't.

Google to the rescue, and Boyd's Comment 34 provided a fix.
I replaced 'rhgb' with 'selinux=0' and the Live Xfce4 USB stick
booted normally (and slowly).

For obvious reasons, I can't add any more real data.  However, it
seems pretty clear that whoever decided this wasn't a blocker needs to
take a step back and reconsider.

FWIW, the installer, in addition to other demerits, has become
massively bloated and slow.  Maybe that should be discussed at the
next blocker review.

The issue that was discussed as a blocker over a year ago is almost certainly nothing at all to do with whatever you're seeing. As I said several comments back, we can't do anything useful for people who keep tacking onto this report with no useful information beyond "the login service failed to start", because we cannot possibly figure out *why* it's failing to start in your particular case. We need you to provide at least the journalctl output to have any chance at figuring out what's going on.

Really, it would make a lot more sense to file a new bug; I can't tell for sure whether the folks who've commented more recently are all seeing the same bug, or seeing different bugs with similar symptoms, but I'm pretty sure it's not actually the same bug we were dealing with back in mid-2014.

I've been suggesting that people file new bugs with their logs since Jan 2015, but no-one seems to pay attention...

again, for the record, this is not a general bug. We know for certain that dozens of testers have done installs of F22 and F23 (network installs, USB installs, and all kinds of package sets) and not had this issue at all; the fact that we don't have huge piles of similar bugs being filed and forum comments and the rest of it strongly implies that tens of thousands of users are doing installs of F22 and F23 and not seeing the same problem. Of course it sucks if you're affected, and we'd like to help, but we can't possibly do so without some information to help figure out what's actually happening to you.

Getting logs from a live image that won't boot to a console is tedious but possible; you can use a serial or network console and tell systemd to redirect its logs there, see http://freedesktop.org/wiki/Software/systemd/Debugging/ .

Adam, I apologize for adding my 2¢ to this BZ and for adding so little
actual data, but as a mere user, there is little else for me to do.

Yes, the problem was reported 20 months ago.
Yes, the problem occurs on a varied assortment of hardware and
on variously controlled software configurations.

Your opinion that my problem is unrelated to the reported bug may
well be correct - I have absolutely no way of knowing.
However, I did observe the repeated failure of the Login Service
and the subsequent failure to start the graphical session.
And that this problem was cured by suppressing selinux, as reported
here.

Further, and most importantly, this occurred with a pristine unaltered
product of the F23 release, arguably the most important, certainly my
only considered F23 product - the Live Xfce4 iso image - not yet installed
on the machine.

I'm sorry, but the challenge of extracting journald logs from a system
running on a USB stick that won't complete the boot process is way
beyond my abilities.

Yes, this very same USB stick did work perfectly on two other i386
machines, but not on the IBM T30 laptop.  That datum is especially
troubling.

Which brings me to That Subject Which Must Not Be Spoken:  systemd
IMHO, systemd has done enormous harm to Linux.  By unnecessarily
parallelizing startup processes, it has introduced race conditions
and made computer operation a stochastic process.
The feedback it gives is poorly written, too verbose, imprecise.

Great efforts have been expended on starting Linux; not so much on
shutting it down.
Startup works - most of the time; in most cases.
Not here.  Not good enough.
The Magic SysReqKey, virtually unknown pre-systemd, now is an essential
tool.
Systemd, after all these years, still cannot reliably perform shutdown.

How the Login Service could ever be (re)written so that it could fail
is mind-boggling.  That the status of selinux could affect it is even
worse.

Systemd has made the underlying architecture of Linux too complex,
too convoluted, too impenetrable; unfixable.

Enough ranting, but it must be said, over and over, until someone
listens.

Adam Williamson, I commend you for your dedication, persistence and
patience in trying to bring order to this chaos.
You must feel like Sisyphus - on a good day.

I am marking this CLOSED/INSUFFICIENT DATA because there is no indication this is a glibc issue. Please open *new* bugs with clear steps to reproduce, and I mean *clear*, everything you clicked on, exactly everything you did from machine startup to failure. Describe the expected and observed behaviour. We need this information to be able to help.

When you file a new bug, the logs from a successful boot with selinux=0 might possibly tell us something. It would also be useful to note if you can boot if you try booting to non-graphical mode, but with selinux enabled (just add '3' to the params).