I've got a VirtualBox instance of Oracle Linux 7.2 which won't start because of Failed to start Login Service. On the booting sequence the process hangs on this message and doesn't continue, so I can't even log in and execute systemctl status systemd-logind.service.

The probable cause for this is, that I removed zsh while all my users (including root) have zsh set as the default shell (duh!). After that the machine started and I got to the login prompt, but I couldn't login since the shell couldn't be found. I then inserted a Live CD and went into /etc/passwd to change the default shell for users to /bin/bash. After this the login service won't start at all. Any ideas how to fix this?


I found out that after changing /etc/passwd it didn't have the right SELinux settings anymore. I don't really need SELinux on my machine so I solved the problem by disabling SELinux altogether. This is easily done by modifying the file /etc/selinux/config and setting the option SELINUX=permissive (if you want to keep SELinux file labeling to enable it later) or SELINUX=disabled (turning it off completely).

| improve this answer | |
  • 1
    This failure also occurs when changing the root password from single boot recovery mode. – Shaun Dewberry Aug 11 '17 at 12:31
  • Setting it to disabled worked for me, but not permissive, cheers! – dspacejs Mar 19 '18 at 0:32

After using chage in single user mode because of expired password, it is required to boot with SELINUX=permissive set in /etc/selinux/config to restore proper labels.

Get proper SELinux context for each modified file from a sane system with ls -Z /etc/passwd /etc/shadow and apply context back to broken system.

As an example, here are set of commands used on a CentOS 7 after chage - DO NOT APPLY without comparison from a sane system (test or preproduction) !

chcon system_u:object_r:passwd_file_t:s0 /etc/passwd
chcon system_u:object_r:passwd_file_t:s0 /etc/group
chcon system_u:object_r:shadow_t:s0 /etc/shadow
chcon system_u:object_r:shadow_t:s0 /etc/gshadow

Review SELinux context of any file you have modified in single mode, before rebooting with SELINUX=enforcing to get back to normal operations.

Other ways to copy SELinux context is available at How to copy SELinux context from one directory and apply it to another directory?

| improve this answer | |
  • 3
    or more conveniently, run restorecon or fixfiles restore on /etc/passwd. If there are more files - e.g. /etc/passwd- - mislabelled, it's more comprehensive to just run fixfiles restore. Or, fixfiles onboot and reboot; this can theoretically be more reliable. – sourcejedi Jan 4 '18 at 12:05
  • Thanks. I still have to learn more about SELinux... – Yves Martin Jan 5 '18 at 11:43

I encountered this today with CentOS 7.2 on VirtualBox. I was able to ssh in as a regular user and issued

touch /.autorelabel

Then rebooted to reset all contexts. It takes a while to boot, but worked.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.