Can not login to personal user, but as root

I think this may be the route to success, because I can do successfully the following (starting in the terminal of the root user)

manj-laptop ~]# su - manolo
05:58:22 me@manj-laptop ~ → export DISPLAY=':0.0'
05:58:59 me@manj-laptop ~ → echo $DISPLAY
05:59:09 me@manj-laptop ~ → firefox &
[1] 9077
05:59:16 me@manj-laptop ~ → ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.

this starts firefox as the personal user. So I guess I need to find out how to set this value for DISPLAY constantly. I guess it is not adding export DISPLAY=':0.0' to /etc/profile which I will try as a temporary solution maybe anyway.

That seems rather full to me, but you should have enough space for it to not cause this.

I suspect DISPLAY is not set because you’re initially logged in as root. You’re not meant to log in as root in the GUI.

yes, maybe that gets generated during the login procedure

My point is that it’s a red herring. You’re trying to fix something that isn’t meant to work, instead of finding your real problem.

I’d put it as “trying to locate the real problem”.

As I have no clue what to look for I am probably guilty of snapping at all the herring I can come across during that process. And some of them may be red :slight_smile: . Do you have any other suggestions?

1 Like

I forgot that with btrfs you need to use btrfs to report the space, so you may still be running out.

btrfs filesystem usage /
btrfs filesystem usage /home

true, but the outcome is not significantly differrent

sudo btrfs fi usage /home | grep Free
Free (estimated):		  42.96GiB	(min: 42.96GiB)
Free (statfs, df):		  42.96GiB

Is the password rejected or do you start to log in and then get dumped out?

Have you checked the password is what you expect? If not, go to a TTY and type the password in the username field.

Did you install today’s Stable Update? If so, then you should have paid attention to this… :arrow_down:

You probably need to set a new password in order for yescrypt to be able to work on your old login, because your old login was still using sha512, and with the new encryption algorithm in place, logind can probably not recognize the sha512-encrypted password for your account in /etc/shadow.

My 2 cents – If your data is disposable; you could simply start over while this new information is fresh in your mind. There will probably be some blowback; some shock and horror, from the community at large for even hinting at this … but … often, it just saves time and complication. That is all. Cheers.

It can easily add or modify anything that will apply to existing and new users.

To back waaaay up, so you did install this? And everything in that quote is true? They say:

can do su [username]

This bypasses the login environment. Can you even login normally? Forget GDM/X/whatever. su needs the -i parameter to use the user’s login environment. Heck even just: ssh user@localhost

With the little I know, seems possible that installer messed up the login scripts for everyone.

Edit: Sorry, I was thinking sudo -i

Dropping to the Super User su - would be done usually from the logged in User. Considering he cannot seem to login as any normal User; seemingly only as root, then the point is moot.

Root already has the access and permissions needed to workaround the issue; or to delete/create profiles or partitions aswell, if desired.

Something that hasn’t yet been asked: was the Manjaro installer (CD/DVD/USB) a current version; and did the OP check the media for defects using the provided hashes, before install?

1 Like

hm. I started this on Oct 4th, and certainly ran a pacman -Syu after things went sour. So I am pretty so, I guess I should have that update installed.

The things you have listed to pay attention to boil down to “This should not require any manual intervention.” So I wouldn’t really know which action to take away from this.

What I don’t get is what yescript actually is. I can find it neither via pacman -Ss yescript, pacman -Sl | grep yescript, nor in pamac. A .tar downloads exist at though. Can someone shed some light on this?
From a naive point of view a package should exists in order to use it, or do I understand something fundamentally wrong here?

tried that once again just now … the new password is still not accepted as login in lightdm.

(*) [Stable Update] 2023-10-04 - Kernels, Systemd, LibreOffice, NVIDIA, Mesa, GNOME, AMDVLK

Is your login shell listed in /etc/shells? If it’s not, then you cannot log in.


Is there possibly a umask override still in place within /etc/profile.d/ since before the path change; and could this be overriding the new default umask value in place at /etc/login.defs?

spot on :champagne:

[manj-laptop ~]# cat /etc/shells


[manj-laptop ~]# getent passwd | grep [username]

added /usr/bin/bash to `/etc/shells/ and I am back in the game.

Apparently the existing /bin/bash entry (even though /bin/bash exists and works) was not good enough.

and probably I digged my own grave here … I was playing a bit with zsh lately and might have switched back to /usr/bin/bash instead of /bin/bash (which might have been the original setting) instead.

Thanks everybody for the outstanding support. I really appreciate it as always.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.