I’d run the update again, and let it finish.
Since sudo now doesn’t appear to work
you have to use su to get permission to do that.
… and you did:
pkexec su
What you then did was … blindly trying to fix something that wasn’t broken
and break even more in the process
but
you reverted that.
ls -l /usr/lib/sudo/sudoers.so
should indeed show:
-rw-r--r-- 1 root root ...
If that is the current state
just run the update, using su to get to be root:
pkexec su
pacman -Syu
and let it finish
or perhaps report what error messages you get when doing that.
If you run the command like this:
LANG=C pacman -Syu
the output will be in english - no need to translate …
ls -l /usr/lib/sudo/sudoers.so
showed
-rw-r–r-- 1 root root
pkexec su
resulted now in
Error executing command as another user: Not authorized
This incident has been reported.
should (!) result in a GUI confirmation dialogue where you give your root password
This is the response you get when you put the wrong password three times.
…
In a terminal, I’d have done just:
su -
I just copy/pasted that
pkexec su
in my reply
because it was already here and seemed to work.
I have never really used that - only always just su -
You could also try to login to a TTY as root directly.
pkexec su
worked in the beginning, but not anymore. Anyway,
su -
worked. The installation showed for most of the files:
Warnung: Verzeichnis-Berechtigungen unterscheiden sich für /usr/lib/systemd/system/
Dateisystem: 757 Paket: 755
So saying directory permissions differeing. File system: 757 Package: 755
That’s just a warning, an information, if you will.
Not sure whether it needs intervention - doesn’t look like it.
permissions are now a bit more restrictive than they where
I have seen these kind of messages and so far always acknowledged and then ignored them.
Maybe because of updating as root (?).
I noticed that during the post-transaction-hooks there was no update-grub. Doing it as root resulted in the following message:
Generating grub configuration file …
…
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings …
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done
So, no kernel was mentioned (?).
No.
Updates have to be done as root.
(sudo gives you these rights temporarily for one command
su makes you root - and any command you run after that is run as root)
It’s because the permissions of the directories and files in the package
(which just got installed in place of the previous one)
are different now - namely (your example): the “write” permission for “other”
was present
but is not anymore now
As you can see in any output of
ls -l /some/directory
there will be three rwx sections, the first for “user”, the second for “group”, the third for “other” - the last one got changed
I’m not qualified to comment.
It would help others to have the full output that you saw.
It’s probably available from the tail end of
/var/log/pacman.log
I do not think there is anything wrong here though.
Does your sudo now work again?
Yes, it does.
Do you mean from the update process?
There still seems to be a permission/ownership issue concerning /usr/lib. I just tried to update the package Oracle VM VirtualBox Extension Pack from AUR using paru and got the following error message:
[2021-12-11T15:08:28+0100] [ALPM] running ‘30-systemd-update.hook’…
[2021-12-11T15:08:49+0100] [PACMAN] Running ‘pacman --upgrade --noconfirm – /home/username/.cache/paru/clone/virtualbox-ext-oracle/virtualbox-ext-oracle-6.1.30-1-any.pkg.tar.zst’
[2021-12-11T15:08:49+0100] [ALPM] transaction started
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] 0%…
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] Progress state: NS_ERROR_FAILURE
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] VBoxManage: error: Failed to uninstall “Oracle VM VirtualBox Extension Pack”
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] VBoxManage: error: The installer failed with exit code 1: VBoxExtPackHelperApp: error: World writable: '/usr/lib’
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] VBoxManage: error: Context: “RTEXITCODE handleExtPack(HandlerArg*)” at line 1465 of file VBoxManageMisc.cpp
[2021-12-11T15:08:50+0100] [ALPM] upgraded virtualbox-ext-oracle (6.1.28-1 → 6.1.30-1)
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] 0%…
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] Progress state: NS_ERROR_FAILURE
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] VBoxManage: error: Failed to install “/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-6.1.30.vbox-extpack”
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] VBoxManage: error: Extension pack ‘Oracle VM VirtualBox Extension Pack’ is already installed. In case of a reinstallation, please uninstall it first
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager
[2021-12-11T15:08:50+0100] [ALPM-SCRIPTLET] VBoxManage: error: Context: “RTEXITCODE handleExtPack(HandlerArg*)” at line 1424 of file VBoxManageMisc.cpp
[2021-12-11T15:08:50+0100] [ALPM] transaction completed
[2021-12-11T15:08:50+0100] [ALPM] running ‘30-systemd-update.hook’…
Setting correct permissions for /var directory recursively - #2 by megavolt
This is a very recent pertinent post from user @megavolt
perhaps in the course of your attempts … you managed to set the wrong permissions on that directory?
anyway - here is the description of the cause for the error - and the link gives the tools and shows how you can fix it
You where concerned about something regarding the grub or kernel installation - I tried to point to the file where the relevant messages will still be.
If you still have the same terminal open, you could just scroll up …
edit:
or, you could simply just reinstall that kernel and review the output again …
(probably via mhwd-kernel - but don’t ask me for specifics
I only run Manjaro in a VM and am not very familiar with the Manjaro tools)
I managed to reinstall the kernels using pacman and then the post-transaction-hooks updated grub and detected the kernels.
Thank you very much for this link. I followed megavolt’s steps applied for /usr.
Thank you so much so far.
So do you think rebooting could be the next step?
When the whole update has finished successfully:
yes.
You could add a safeguard before you do, if you are concerned and haven’t done so until now:
add at least one other kernel to be able to choose from for the unlikely case that the updated one will not work.
… have at least two kernels installed …
Thanks for the answer.
That seems to be the case.
I do have.
So I will try the reboot.
… can’t postpone it forever 
(Man kann es ja nicht ewig verschieben )
Finally, the reboot went fine. Everything seems to work properly, incl. sudo. After resetting the permissions in /usr/lib the update of virtualbox-ext-oracle finished without any error.
@Nachlese: Thank you so much. You solved my problem and saved my day. 
You are very welcome!
anytime - if I can, I will …
Thanks man, this helped me as well. But I have a query. Let me explain the scenario first:
Since during these upgrade my applications tend to hang (For eg: Youtube video or any other stuffs if run when upgrade in running in background tends to hang specially when packages are being installed). So this time, I entered Ctrl+Alt+F6 and went to complete CLI and run the upgrade. As mentioned in the original thread, I didn’t press any keys. To be honest, I wasn’t even near my keyboard. But when I glanced at screen the above posted error was looping really fast. So, my query is was that because of upgrading via CLI mode and not from Terminal in GUI??
You left your graphical session and went to a TTY - the equivalent of the terminal application in your graphical session.
The difference (and this might be an advantage in some cases) is:
If the update somehow renders your graphical session unusable
the update process will still continue to run in TTY
even if you have to close the graphical session/log out of it …
I’m sorry, but right now and even after glancing over all of the above
I have no idea what you mean by that. 
… you did know that you can switch between the TTY and your graphical session - have them both running at the same time? … if not: now you do 
You can switch back and forth anytime
and continue to do whatever you where doing while the update is running in the TTY …
What is absolutely sure is:
no, that wasn’t the reason for it.
During updates, there is a lot of disk activity - and the checking and unpacking of the packages that are about to be installed also can be quite heavy on your CPU.
Thus, some lag or stuttering of apps is normal - it depends on the capabilities and speed of your CPU and hardware whether that will have noticeable effects like you describe.
You could start and run the update on a lower priority - that might help with these issues.
such as:
nice 19 pamac update
see:
man nice
the update process (pamac, for example)
or any program started this way
will be “nicer” to the other, already running programs - hence the name, I guess
… by putting negative numbers, you could also make it less nice, so that it runs with a higher priority …
again:
man nice
Thanks man. Didn’t know about nice until now. Will try that for sure.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.