But it does not and should not make a difference if it is used with sudo, right?
I’m not willing to keep a list or database of applications which should be called with sudo, which not 
Yes, it will make a difference, because when run with sudo, all of its normally unprivileged activity will be carried out with root privileges, which will mess up permissions and file ownership.
Then perhaps you should not be using a UNIX-style operating system. 
The golden rule is to run everything without root privileges first before trying it with sudo. Then if it fails, no harm will be done.
4 Likes
In the specific case - pamac - it does matter, because pamac command line can build package from a custom PKGBUILD - and this should not be done using elevated permissions as this could have unforeseen effects - disastrous even - especially if you do not review and verify the content of the PKGBUILD and the actions it performs.
2 Likes
And in the case of pamac which uses polkit for privilege escalation, you will be prompted if – and only if – elevated privileges are required; thus, pamac should never be used with sudo.
This should dispell your fear of having to keep such a list.
3 Likes
The first is a ridiculous argument, if it even is.
While it is obvious that ‘ls’ might not need sudo privileges, it is not obvious for an application doing system updates. Especially if pacman does need sudo.
Your second point is valid for sure and yes, the wiki page states, that sudo might not be used.
Never execute a command — any command! — without reading its manual page.
That said, pamac-cli should really perform a detection first when invoking it in order to determine whether it has been called with root privileges or not, and should then bail out if it is. But that is of course for the pamac developers/maintainers to solve. 
2 Likes
7 posts were merged into an existing topic: The Official Manjaro Staff Lounge
I have this little executable script saved as /usr/local/bin/pamac:
#!/usr/bin/env bash
if [[ $EUID -eq 0 ]]; then
echo "Warning: Do not use 'pamac' with 'root' privileges. It can cause permission issues."
exit 1
fi
/usr/bin/pamac "$@"
If I try to run pamac with sudo:
sudo pamac update
Warning: Do not use 'pamac' with 'root' privileges. It can cause permission issues.
Running pamac without sudo works fine:
pamac update
Preparing...
==== AUTHENTICATING FOR org.manjaro.pamac.commit ====
Authentication is required to install, update, or remove packages
Authenticating as: Scott (scotty)
Password:
==== AUTHENTICATION COMPLETE ====
Synchronizing package databases...
Refreshing AUR...
Nothing to do.
Transaction successfully finished.
8 Likes
And a script to use in conjunction with pacman;
Or, something even simpler…
oops() {
if [ "$1" ]; then
sudo $@
else
sudo "$BASH" -cc "$(history -p !!)"
fi
}
1 Like
That’s potentially dangerous, though.
1 Like
The default file is /usr/lib/NetworkManager/conf.d/20-connectivity.conf, which is owned by a package and as such will be replaced when that package is updated.
/etc/NetworkManager/conf.d/20-connectivity.conf is the override file, which doesn’t exist by default - you have to create it. It won’t be replaced by an update and is the proper place for us to configure it.
I just have an empty file, as that’s enough to override the default.
sudo touch /etc/NetworkManager/conf.d/20-connectivity.conf
You may have to restart Network Manager, or reboot (it’s been so long since I did it that I can’t remember).
5 Likes
pamac comes with two front ends - gui and cli. If you invoke the gui without root why should invoking the cli behave differently? (Because it’s in the terminal? Notice also it’s just the same if you use yay.)
Yes, that’s why you don’t edit these files directly but use systemctl edit ... like described in the Arch wiki. I should have mentioned this at least, but didn’t realise this specific setup for the Networkmanager.
4 Likes
Yes, that should work too. However not everyone knows about that, a lot of people may just edit the file directly - so it’s best to be explicit about the method.
I updated yesterday and a couple of hours later I had a really freakish system freeze which I’ve never experienced in my whole linux life. 
I was browsing reddit and a video on the site was starting to play when the screen suddenly froze and subsequently the monitor went dark displaying “No display port signal”. At first I thought it’s one of the familiar AMD page flip errors so I tried to switch to a virtual terminal (Ctrl + Alt + F3) but that didn’t work. I noticed my USB mouse and keyboard going dark as well as if I would have unplugged them from the motherboard (which I didn’t). I tried unplugging and re-plugging the display port connector on the monitor but it didn’t help.
Next I tried MagicSysRQ with REISUB - no luck. Then I tried the physical ‘reset’ button on the front of my case but (to my surprise) that didn’t work either. Out of desperation I started to hold down the power button beside it but even that refused to shutdown the system. I really started panicking.
That’s when I decided to crawl under the desk and to open the case. The CPU and case fans were still running. Really freaky. I didn’t know what else to do, so I switched off the I/O switch on the back of the power supply which finally worked.
Upon restart everything was working fine again. The system journal didn’t record any errors though. Has anyone ever experienced something like this?
I have absolutely no idea what to do next but I noticed the new stable kernel 6.12.49 changelog (I’m running 6.12.48-1-MANJARO after the last update) listing a commit about ‘amdgpu’:
drm/amd/display: Allow RX6xxx & RX7700 to invoke amdgpu_irq_get/put
commit 232e74984061eea9cb6bf9b67e3070435477048c
Author: Ivan Lipski <ivan.lipski@amd.com>
Date: Tue Sep 2 16:20:09 2025 -0400
drm/amd/display: Allow RX6xxx & RX7700 to invoke amdgpu_irq_get/put
commit 29a2f430475357f760679b249f33e7282688e292 upstream.
[Why&How]
As reported on https://gitlab.freedesktop.org/drm/amd/-/issues/3936,
SMU hang can occur if the interrupts are not enabled appropriately,
causing a vblank timeout.
This patch reverts commit 5009628d8509 ("drm/amd/display: Remove unnecessary
amdgpu_irq_get/put"), but only for RX6xxx & RX7700 GPUs, on which the
issue was observed.
This will re-enable interrupts regardless of whether the user space needed
it or not.
Fixes: 5009628d8509 ("drm/amd/display: Remove unnecessary amdgpu_irq_get/put")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3936
Suggested-by: Sun peng Li <sunpeng.li@amd.com>
Reviewed-by: Sun peng Li <sunpeng.li@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Signed-off-by: Ray Wu <ray.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 95d168b367aa28a59f94fc690ff76ebf69312c6d)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
and wondered if this might be at play here since I’m running an AMD RX6600 gpu.
Something similar happened to me yesterday as well, though I’m not sure if the issue is related as it might have happened once or twice in the past.
Essentially, I left my computer for a bit which subsequently led it to automatically suspend. Upon returning I pressed the power key to wake it up, only for nothing to respond (laptop monitor was off, keys did not respond, caps lock key light did not work). The only sign of life was the lit power key.
Ended up doing a hard reboot.
I am on kernel LTS 6.12 with Intel graphics. Unfortunately I couldn’t capture any logs.
1 Like
Full ACK. That’s what I expected when I initially wrote that it should not make a difference if called with or without sudo.
Maybe I presumed too much at this point. I just have a strong background in defensive programming in which such cases would be checked.
Thanks.
3 Likes
Can t get this release to work on my machine without issues.
It will help if you specify which issues, and provide some system info e.g. inxi -zv8.
1 Like
I decided to start clean with this machine, but after I updated it. I’m booting into dark screen after Manjaro Linux logo.
I’m trying to fix grub according to manual, but seems that btrfs filesystem breaks manjaro-chroot. So can not figure out how to reinstall grub.
My system info could be found in this post:
I had a similar complete system freeze (kernel panic?) in the early days of the 6.12 kernel… basically woke up the next morning and the systems fans were running like crazy but no display or KBM responsiveness.
Back then, I swapped back to kernel 6.6… but it’s hard to know what’s been back-ported to which kernel… it may be a better idea to roll-back/downgrade the 6.12 kernel if that was working for you before the update… assuming you are keeping a few package versions, you should be able to find it locally in /var/cache/pacman/pkg/
$ ls -la /var/cache/pacman/pkg/linux612*
-rw-r--r-- 1 root root 146348829 Jun 19 13:57 /var/cache/pacman/pkg/linux612-6.12.34-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root 438 Jun 19 13:57 /var/cache/pacman/pkg/linux612-6.12.34-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 146352883 Jul 18 01:16 /var/cache/pacman/pkg/linux612-6.12.39-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root 438 Jul 18 01:16 /var/cache/pacman/pkg/linux612-6.12.39-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 146427018 Aug 1 07:32 /var/cache/pacman/pkg/linux612-6.12.41-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root 438 Aug 1 07:32 /var/cache/pacman/pkg/linux612-6.12.41-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 146438171 Sep 1 23:14 /var/cache/pacman/pkg/linux612-6.12.44-3-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root 438 Sep 1 23:14 /var/cache/pacman/pkg/linux612-6.12.44-3-x86_64.pkg.tar.zst.sig
If you have the previously working kernel in your cache, you can install it via…
$ sudo pacman -U file:///var/cache/pacman/pkg/linux612-6.12.44-3-x86_64.pkg.tar.zst
Note: you may also want to repeat the above for amd-ucode and linux-firmware to ensure you have the same kernel with “modules” as you did before… then…
$ sudo mkinitcpio -P
$ sudo update-grub
Thank you for the warning and potential 6.12.49 fix… I have an RX7700S dGPU in my laptop so I’ll delay this update while I wait for the fixed kernel.
2 Likes