It prompts for a password → no problem, enter password
It then goes off and proceeds to build, which takes a while.
It almost done it prompts for a password → again no problem, enter password
But, it doesn’t re-prompt if you happen to have fumble fingered it…possibly much time down the drain.
Is there a way specify to re-prompt?
Also, if enough time goes by while it’s waiting for the second password. no matter what is typed in it throws an “Authentication Failed” and the terminal is unresponsive. Forcing the terminal to close is the only way I’ve found to end it.
Things I’ve tried like increasing the sudo timeout don’t seem to have any effect.
Is this normal? Or am I doing something wrong?
This happens on both of my Manjaro installs, both are the same from a Manjaro standpoint.
Operating System: Manjaro Linux
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.1
Kernel Version: 6.11.11-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 6 × AMD FX™-6350 Six-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2
CTRL+C or CTRL+D should do it.
If you need to restart the whole process, it will ask the same initial questions, but then it will use the already built stuff instead of building everything all over again
(if you do not explicitly tell it to clean build everything at the beginning).
It will be a lot faster till you get to the point where you might again be asked for the password to actually install the finished product.
That is how yay works, at least - I almost never use pamac but this behavior should be the same.
From what I’ve been reading (years-old threads, though) it seems the password authentication timeout is hard-coded within Polkit, or at least it was back then.
There is a thread on here which might be relevant:
A good reason to take extra care when entering a password.
There is not.
I have noticed this on occasion; and the error doesn’t seem strictly reliant on any timeout. It can manifest immediately after having input a correct password also.
Why?
Nor should it. As others have mentioned, this has no bearing on pamac.
If you mean “Is it normal to not give an opportunity to retype your password?”, then, yes. For what it’s worth, the “Authentication Failed” message should be expected behaviour too; though it clearly does not work well in all scenarios.
As @Wollie suggests, keeping the official repository packages and AUR packages separated during an update is good practice; for example:
Note that pacman is historically more reliable than pamac for updating official Manjaro repository packages – Yet, pacman has no support for the AUR – However, pamac does.
Thus, a fair strategy is to use both commands:
sudo pacman -Syu
pamac update --aur
Or, in combination, like this:
sudo pacman -Syu && pamac update --aur
As suggested, the Yay package manager is a valid alternative to pamac – yay (at least for the time being) remains available in the official Manjaro repositories:
I find the multiple “systems” for software maintenance in Manjaro quite befuddling.
I have read many websites about yay, pamac, pacman.
Every question about one seems to lead to recommendations to use one of the others.
On Debian, which I’ve used for more years than I have Manjaro, I use apt. Just apt. Sure there are other package managers, but, apt seems to be able to handle all conditions. That may be because I’m familiar with it.
I’ve read the man pages for yay, pamac, pacman and plenty of online doc. But, what I have not found is a single webpage or document that is a comprehensive resource for software maintenance on Manjaro. If there is one, please let me know.
My biggest issue is, I have 2 machines with the same Manjaro. For weeks or months a given pamac, etc. command will work the same on both machines. Then one day it works differently on one of the machines. The freecad-git changes daily, so my main goal is to get the latest from that almost daily. When the same command that has worked for weeks on end, then one day it acts different on one of the two machines I start trying to find out why. For instance one machine sees and updates to the latest source, but the other shows no update available. Since one did update, there is obvious an update available.
I suppose at some point I’ll have an Aha! moment and it will become clear.
Are the machines identically with regard to the hardware?
Have you updated more or less exactly at the same time? If not, one might have updated from a fresher repo state, or the AUR maintainer just updated their work…
pacman for Manjaro repo’s (1st step) in combination with an AUR helper like yay (2nd step of update) has been working for me since years without any nameable issue in testing branch.
Hmm…The machines are similar in hardware and updated at virtually the same time, i.e. start update on one, walk over to the other start update.
TBH, this thread has really veered from what I meant ask.
That was: why I would get a password prompt, after waiting too long, even a correctly typed password would fail to authenticate and the terminal window would be unresponsive.
It is probably hard for you to reliably replicate the situation - it never happened to me that I needed to force close the terminal because the update process was somehow hung.
There is always: CTRL+C or CTRL+D
to force the process to end
without having to close the terminal the process was running in.
If there is no way to replicate the issue (for you or for us) then there remains the looking at the system logs
(you could, for instance, run: journalctl -f
in a second terminal, to get a live display of what is written to the log).
Any actual compilation, as is often the case for AUR packages, will very likely also write logs about the progress -
you find those in the directory pamac uses to … build/compile those programs
After that the only thing that remains is speculation.
I’d simply avoid using pamac - both as the tool to install repo packages as well as using it as the AUR helper of choice.
There are certainly tried and true better ones - pacman for the regular repo
and a host of other AUR helpers like yay or trizen or …
Octopi seems to work quite well - as it is (from what I heard) truly just a graphical frontend to the tried and true command line tools pacman and yay.
This is useful for me, who is lazy.
I sometimes update it in the terminal and forget it. I am doing something else in another workspace.
In my case, the terminal has never terminated, but it times out and returns to the prompt. A typical example would be a full kernel build, which sometimes takes about 45 minutes to build.
All of those yay options can be set permanently with no need for an alias.
Because pamac has bugs.
It also has about 1 single developer … who also goes on long hiatuses … and is currently on one … so you cant expect quick fixes either.
Someone or other is going to crow about it, but the reality is pamac is not reliable.
pacman is, but its syntax is considered ‘odd’ by some, and it does not interact with anything but the repos - necessitating an AUR helper for those who wish to use the AUR without always relying on a manual makepkg. AUR helperes are a dime a dozen … but only a handful are really recommended. Some people then choose an AUR-helper that is also a pacman wrapper and make that their default package manager in general - whether yay or trizen or paru, etc.
I use and tend to suggest a pacman-centric approach - only using the AUR helper as needed.
If a GUI is needed then, as others have mentioned, octopi is just about the only recommendable application as it is really just a graphical wrapper for pacman (and certain compatible AUR helpers).
