Freeze after entering password

After updating my system today i rebooted as recommended.
However, after entering my password it stopped … well sort of.
There was a mouse pointer, it was slightly larger than my usual one, and i could move it. It was just a shame that there was nothing i could move it to :slight_smile:
I rebooted then tried ctrl-alt-f2 instead of entering a password and then tried updating the system again (using pacman AND yay) just to see if that made any difference.
It didn’t!
Obv as i can’t get my system up, i can’t grab any logs (i’m guessing here) but my hd’s would seem to be fine according to a gparted check.

Do you have any suggestions or even just thoughts please?
I really don’t want to lose about four million open tabs in my browser :frowning:

Thanks for reading, happy Linuxing (that really should be a word)

Oops, sorry, i am using xfce … my bad

sure there is enough space in the partition ?
freezing after entering password is often caused by unsufficient space…

1 Like

Thanks colin but …


  • the first entry is my grub drive.

plus over 90Gb free on my main data drive.

yeah - looks fine

1 Like

Anyone got any other thoughts please?

I tried Manjaro three times in the past and each time it has let me down after updating - twice lost all network devices and once looked exactly like this issue. After failing to fix it i gave up and reverted back to MX and waited for the next Manjaro release.
Endeavour has lasted a lot longer than Manjaro ever did, so i would really prefer to fix the issue rather than give up as i’ve done in the past.

Before someone says “sounds like it might be your hardware” i am on a completely new machine from the Manjaro trials, initially i did re-use one hard drive but now i’ve replaced both drives.

Hi, you can try to switch to a text console with Ctrl-Alt-F1 or F2, …

Log in there and check logfiles. dmesg command should show a boot log and as you already have a mouse pointer a look into the Xorg… logs may help, too. Also it may help to temporarily disconnect any USB device you don’t need right now.

1 Like

only a thought…
maybe it is possible to get to the system by autologin ?
out of the shell(tty) changing the entryconditions ?

1 Like

Thank Peter and sorry about the delay … I’ve been giving the gods a bit of a laugh.

Anyway, logs, etc are below, tbh there are so many what looks like “errors” to me i’ve not a clue what it all means.

However, i feel i should mention that when i first tried to reproduce the error, i.e. reboot my system - it WORKED!
As i had a couple of things i really needed to do i did them, plus i ran a backup. After the backup (data only) i rebooted and it failed.
Since then it has been sometimes ok but sometimes (same) failure
… and that does not make any sense to me.
FYI I admit i did struggle a little to get the lightdm log, not sure what i should have done but i eventually copied it to my data drive using an SU prompt as SUDO couldn’t hack it (permissions) and then CAT’d it to sendlog from there. I did similar with the xsession-errors and Xorg files too but not as SU.

So here they are:

$ inxi -Fxxc0z --no-host | eos-sendlog  >
$ journalctl -k -b -0 | grep fail | eos-sendlog  >
$ cat ~/.xsession-errors | eos-sendlog  >
$ cat /var/log/Xorg.0.log | eos-sendlog  >
# cat /var/log/lightdm/lightdm.log | eos-sendlog  >  # as root

Any help at would be greatly appreciated, thanks.

once again i want to ask if you tried to skip the password by running autologin ?

  • sorry, i am not really good in english language and don’t always understand… :frowning:
1 Like

Sorry colin your idea was appreciated but as i implied in my 8, i have had a lot going on.

Also, i wasn’t sure what your suggestion might allow me to do. Obv log on BUT how would it allow me to actually fix whatever is wrong - or even investigate what was causing the problem.

BTW, your english is fine and way, WAY better than the average brit speaks german or any other language. It’s even better than my live-eos US keyboard can type it :slight_smile:

[     4.989] (EE) AIGLX error: dlopen of /usr/lib/dri/ failed (/usr/lib/dri/ cannot open shared object file: No such file or directory)
[     4.989] (EE) AIGLX error: unable to load driver i965

hmm the GPU should be gen 6 I bet so it could be an issue if you have xf86-video-intel driver package installed?
In some rare case it could be also the opposite and intel GPU runs more stable when using that package :wink:

1 Like

@Marvin - sorry, I did understand that your issue is not to be able stepping into the system because it ignores your password; for that an autologin could be a possible way to get in and repair from inside. – was only a thought of mine…
good luck for repairing :+1: :man_detective:

1 Like

Thanks colin but i don’t know what needs repairing. If i did, then yes, i would certainly prefer to use your idea, as i do tend to use gui except for taking backups.
Thanks again though.

Hi Johannes Kamprad, thanks for the info although i’m not sure what i should, or need, to do about it.


The oldest directory on my system is /mnt and that is dated December 2021. I am guessing that means i first installed EOS on that date as it is on my root partition and i know that i wiped that before, and during, the install of EOS.

What i’m saying is why has this issue just reared it’s head as it has obviously been working fine since then, i.e. for over a year?

And why is it working sometimes, e.g. yesterday 3 or 4 reboots were fine and only one was not, whereas on the previous day it had been 5 or 6 fails and only one success.

Could it be that someone has stolen my computer and replaced it with the worlds first quantum desktop but the entanglement isn’t quite right?

I could see that you are using a non LTS kernel.
If you are able to log in to a shell with Ctrl-Alt-F2 you can install one with ‘yay linux-lts’ and try again choosing this in grub on bootup. As it randomly works I suppose it may be caused by kernel hardware detection!!! Just a guess…

1 Like

There is nothing really useful in these logs. We need to see messages that show the problem. Try these, after the issue happens, and rebooting to a good session:

inxi -Fazc0 | eos-sendlog
journalctl -b -1 --no-hostname --no-pager | eos-sendlog
cat /var/log/Xorg.0.log.old | eos-sendlog
1 Like

Thanks petsam i will do what you suggest but it will have to be tomorrow.
Although i’m not sure how they will be different (except for the change in options) from the one’s i posted earlier which were taken after the boot failed and then i had booted from a pen drive.
Won’t that give exactly the same results?

Also, just to ensure it’s in plain sight, doing this might take a number of reboots to get a fail and a number more to get a successful one.

My logic says that as long as this is done immediately after the first successful boot after any number of failed boots, it should not matter.
However, my logic also said it will only give the same logs as in post 8 so we clearly can’t trust my logic.

:zipper_mouth_face: :joy: I guess…?

then they will not be the same :person_shrugging:

Yes. After a fail, reboot. If it succeeds, get info. If not :joy: , keep on trying.

1 Like

Thanks Peter.
I think i understand what you suggest, and it’s implications. However, i am really eager to see what i can personally glean anything from the “useful” logs that petsan has suggested so i am running with that idea … well, chilling first, then sleeping then a slow stumble.

Plus, i’ve not been informed what my daughter has planned for tomorrow yet.

Thanks again though. Everyone’s help is really appreciated.

1 Like

Logs as per above:

inxi -Fazc0 | eos-sendlog  >

journalctl -b -1 --no-hostname --no-pager | eos-sendlog  >

cat /var/log/Xorg.0.log.old | eos-sendlog  >

Are options shown in:
How to include systemlogs in your post?
wrong then? And maybe should be changed?

Or just this case different?