[SOLVED] New install, boot stuck on Started TLP system startup/shutdown

Hi,
I know this question has been posted a few times already, but I wasn't able to find any solutions.
I did a fresh install of Manjaro Gnome. Afterwards, the boot process always stops after Started TLP system startup/shutdown. No error message or anything is shown.
Pressing Alt F2 brings up the DE and everthing runs fine afterwards.
I am not sure how to debug the issue since there is no error message or anything to start. How could I start debugging the issue? Thanks for the help.

Read this first:

I strongly suspect that it's got to do with the entropy pool in your system ─ see this article at the Arch wiki.

You could try...

sudo pacman-mirrors -f 5 && sudo pacman -Syyu

Let it update, and then install haveged.

sudo pacman -S haveged

Enable it at boot time...

sudo systemctl enable haveged.service

... and then reboot...

sudo systemctl reboot

Please let us know whether that solved the issue. If it didn't, then it's either way not a bad thing to have haveged installed.

:thinking:

1 Like

Wait... I missed this:

Do you mean CTRL-ALT-F2 ? If so that should not switch to a graphical session unless you have reconfigured the system away from its defaults.

Technically you are correct, He Who Until Very Recently Was Not To Be Pinged™, but there's a bit of an "optical illusion" going on. :stuck_out_tongue:

The thing is that in the OP's case, pressing Ctrl+Alt+F2 ─ which will indeed switch him/her over to tty2 ─ sufficiently increases the entropy to speed up the loading of the display manager, which will then automatically switch back to tty1, or whatever the default tty is for Manjaro GNOME.

So it's not like the display manager is suddenly running on tty2. It only looks that way because the user switched over to tty2 during the boot process, which in turn accelerates the boot process because it increases the entropy pool .

The machine is still trying to boot up and load the display manager at that point, and this is what then switches back over to the default tty for the display manager.

1 Like

Installilng haveged did indeed fix the issue. Is there any wiki article explaining this? I don't quite understand what enabling the service has to do with the problem. Anyway, thanks for the quick replies.

1 Like

Yes, there is. I mentioned it in post #2, as quoted here below....:

Certain components of your system ─ such as cryptography ─ depend on the entropy pool. This is especially the case for GNOME and other GTK-based software. If your system boots up with only very little entropy, then it gets stuck during the boot process until there is enough entropy available. This is where haveged comes in ─ it's a random number generator. :wink:

I'll mark post #2 as the solution and I'll edit the thread title. That way the solution will get added to your opening post, so that other people with the same problem can easily find it. It is quite a common problem with certain hardware. :wink:

1 Like

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

Forum kindly sponsored by Bytemark