Unable to login after merging /etc/shells

I was going through some previous .pacnew files and found two files I merged. One was /etc/ssh/sshd_config, and the other was /etc/shells. I’m not entirely sure which merger caused the issue, but now I cannot login.

After rebooting, I cannot login to my user account but I can still boot and open my LUKS partition. I just end up on the login screen, and while I keep entering the correct password, it keeps saying my password didn’t work.

I need to know how to fix this without chrooting into my system if possible as I don’t have a live USB at the moment. Is there a way to correct this by logging in as root at the Gnome login screen?

Thank you to everyone in advance. I have work and can’t get anything done right now :confused:

Maybe booting into runlevel 3 or even 1.
1 being single-user mode.

I got into tty2 with CTRL+ALT+F2 but it says my root password is incorrect :slightly_frowning_face:

That would be /etc/shells then. And I’m guessing you probably literally copied the .pacnew over the existing file.

The problem with this — which is already over a year old, mind you — is that the .pacnew does not contain /usr/bin/zsh. So you need to add that back. This is what the file should look like… :point_down:

[aragorn] >  cat /etc/shells 
# Pathnames of valid login shells.
# See shells(5) for details.


[aragorn] >

You can fire up the Manjaro USB in live mode, mount your root filesystem, and then edit the file. No need to chroot, even.

1 Like

Got it I’ll try that and see if it works. But how would I do it if its LUKS encrypted? Like how would I open it then lock it?

I did not suggest tty - I suggest runlevel.
Please read the link.
But instead of 3 try 1.

If that does not work and you dont have grub set to boot a recovery ISO or similar … then you will probably have to use a live USB (or DVD) and chroot.

cryptsetup open /dev/whatever-it's-called

And lock?

Why would you want to “lock” it?
You just need to open the container, mount it and access/edit the file.

cryptsetup open /dev/sdax encrypted
mount /dev/mapper/encrypted /mnt
(for instance)

then edit /mnt/etc/shells

1 Like

Oh what I wanted to do was open the LUKS encrypted OS with Gnome files so I could edit /etc/shells back through a GUI. So after opening it like this, I would just unmount it? I thought we need to lock it after we open it from another media?

Hmm - not sure where you got that notion from.

You access the file, however you get to it.
You edit it (that means: you alter it).

Then you can unmount the device and even close the container.

That would be:
umount /mnt
cryptsetup close encrypted
if you used my example.

Or just: reboot
without bothering to unmount and close it

and see whether the addition of /usr/bin/zsh
had the effect you where hoping for.


OK I got into /etc/shells with Gnome Files and tried modifying with gedit but it says permission denied. Sorry if it’s an easy thing but I’m scared using the terminal to manipulate with cryptsetup.

of course - you need admin (root) permissions to edit the file

It’s not giving me an option to open as admin. Would’ve tried CLI but I don’t know how to follow to the other device directory. Terminal is hung and won’t open.

Also am I not already root since I’m booted from a live USB?

obviously not - the default user in the live system is “manjaro” - it can become root, but isn’t by default
that would be … dangerous …

in the terminal, it would have been as easy as:

sudo cryptsetup open /dev/sdax encrypted
sudo mount /dev/mapper/encrypted /mnt

sudo nano /mnt/etc/shells

save the file

To describe the same process when you want to do it using the graphical file manager, I’d need to write a small essay.
To be honest: I don’t even know how this works in Gnome - it’s something I literally never do.

Just reboot and try the terminal approach - is my recommendation.
I can’t describe how to edit as admin in Gnome files.


You are a legend. Saved me from a headache (although I already had one :slightly_smiling_face:). Thank you so much for helping me with something so simple!

1 Like

My pleasure! :man_bowing:

1 Like

Before the topic closes, do you know why /etc/shells.pacnew didn’t have zsh if it was going to break logging in anyway? Like what was the purpose of the pacnew then?

No, I don’t know.

I don’t know if that was an error from back when or whether it came from your delay in merging it.
No idea.
I just know that it would not have affected me - because the first thing I do when installing is to change my (default) shell to /bin/bash (or: /usr/bin/bash)

That’s why I would not have even noticed it even when I missed to merge that .pacnew

I’m simple - don’t like zsh.

1 Like

Both. It was indeed an error in the file, but at the same time, it should already have been handled back at the time, because it was amply discussed on the pertinent Unstable Updates, Testing Updates and Stable Updates threads. :wink:

1 Like