When installing or removing a package with either pamac-gtk or pamac-gtk3 if the screen was set to blank & does so before entering the password upon unblanking the screen input to the authentication banner is inhibited & no recovery can be accomplished but a hard reset.
That’s a Polkit authentication dialog. Does it happen with any other program that uses Polkit?
To get an idea, you can check which programs you have installed that depend on polkit:
pamac info polkit
or
pacman -Qi polkit
Either way, the screen should not be set to sleep / blank in so short of a time that you miss the authentication dialog. Updating requires your full attention.
Yep, gparted freezes if on launch the screen is allowed to blank before entering the password.
This should not freeze applications from continuing to operate.
This! Screen blanking/suspension/whatever should be turned off for these critical procedures.
Can be done easily in Plasma via the battery icon → √Manually block sleep and screen locking.
NB: This, or something like it, should, IMHO, be the default on a Live Session.
EDIT: I forgot this was for Gnome. Trying Manjaro Gnome is currently still on my to-do list. 
2 Likes
fwiw … software updates with yay or pacman are not adversely affected by screen blanking at the password prompt and from my testing only occurs in the Gnome desktop environment.
Absolutely. Any advice to inexperienced users about resizing/moving partitions one has to remember to point that out, it’s an unnecessary trap that can have disastrous consequences.
1 Like
This is screen blanking with suspend & hibernate disabled…should really NOT be an issue.
1 Like
I don’t know if it really is one.
I remember being annoyed by it - until I disabled screen blanking.
It doesn’t make sense for me and constantly get’s in the way.
But even before, I seem to remember that switching to a TTY and back to the session … did “the trick”.
Will try to replicate - but for me only possible in a (kvm) VM.
Not sure whether the default wayland will even work there.
We will see
!
Are you in a wayland session or in an xorg session?
(there might be a difference - and you didn’t say AFAIK)
I thought I was done with Gnome - but I’m still curious. Feedback could take a while
in the meantime: have you tried switching to TTY and back to the session?
my Opinion:
Gnome is actually pretty cool - as long as you don’t insist on trying to customize it.
then it gets in your way and problems begin
might not be true for fixed release distributions - but it is an issue with moving targets like Arch and Manjaro very much are
Xfce4 FTW 
or some nicely pre-configured window manager (like the Bunsenlabs openbox config …)
Jumping in & out of the tty …ctrl-alt-F3… ctrl-alt-F2 has no effect.
How do you (!) trigger the condition?
I have not even started to install the latest Manjaro Gnome to a VM yet.
I would not know which TTY the (whatever) session ran on.
Are you using xorg or wayland?
Tomorrow is a public holiday here - I may have some time to tinker …
It’s triggered by:
- pick a package to install or remove in pamac
- confirm that you want to continue
- when the authentication banner is displayed let the screen blank
- wait about 30 more seconds
- touch the touchpad to unblank
- observe the authentication banner will not take any keyboard/click input
X11
Which? For example?
From AUR or “normal” repo?
Any…it’s gonna freeze before it’s installed… for the sake of argument I’ve been using braver-browser
Thanks.
I lack imagination.
So now I know what to try
Some of us need to be led by the hand…others by the ring in their nose… 
…and others, still… kicking and screaming…
I wanted to replicate, not guess and then be told that I had to do it differently.
With this procedure:
I can indeed replicate the “issue”.
Cave:
It does not make sense to me to begin installing something, confirm it when asked,
immediately afterwards being asked for authentication
(to actually start carrying out the task you just confirmed you wanted to have done)
…
but then … choosing to NOT authenticate - but waiting and letting the screen go blank instead
and then try to come back and continue
I would likely never have run into this with the default screen blanking time of 5 minutes.
And I had to pay attention and deliberately wait with the screen blanking set to one minute.
Also this:
is not true
While the GUI is indeed totally unresponsive
a hard reset is not the only way out.
It is, for instance, possible to switch to a TTY, log in
and issue:
systemctl restart display-manager.service
and then start over, NOT waiting for the screen to blank before deciding to authenticate the action you just initiated …
My two cents, keep the change.
Cheers!
ps:
The pamac GUI may stall for some reason.
What should NOT happen is:
the whole session being defunct/frozen because of it
The one process (pamac GUI) may be.
But not the rest as well.
One more reason to not use the pamac GUI or pamac in general. 
2 Likes
Although this sounds strange to you, my usage scenario is completely normal for me.
I use my device as a media server not needing the screen & as I interact with said device I want the screen to blank as soon as possible. My scenario to recreate was for ease to recreate. While I’ll give you it’s not likely the practical scenario occurs during a large system update with an AUR update included. These updates can take a considerable amount of time to complete & upon finishing authentication is required AGAIN. If this occurs & usually does occur while the screen is blanked the BUG occurs. Hence a reasonable way to encounter the annoying BUG.
A soft reset is only a LITTLE better way to recover from a BUG.
It’s not a BUG it’s a FEATURE is not a BUG fix.
Apparently!
A possible workaround (strictly when it’s likely to be needed):
sudo pacman -S caffeine
This should prevent most if not all power saving and screen blanking processes while it’s activated.
Cheers.