Everything went fine except audio didn’t work anymore during the session (cracking noises), due to the Pipewire update. It did not go away when re-logging but was okay after rebooting.
I didn’t even try to merge it and forgot to report the change (did the update way before the thread was opened).
Waiting for more info about that (breaking) change in the default file.
//EDIT: /var/cache/pacman/pkg/sudo-1.9.8.p2-3-x86_64.pkg.tar.zst did not have the new sudoers file change.
//EDIT2: can’t find anything relevant…
2 Likes
This should go in the Feb 1 update thread when it goes up. Anyone else seeing plasmashell crashes on wayland after today’s update? Seems to be working on x for now.
Edit: Very strange. I reset panel configs before trying x and still couldn’t keep plasmashell running. After using x for a while and trying wayland again to get the exact error to post here, no crashes.
Crashed real hard for me, had to restore a Clonezilla backup. Even reverting to an earlier btrfs snapshot failed. X kind of worked as far as I was able to get into the desktop, but the panels were missing and I couldn’t right-click on the desktop. The whole system was utterly unstable.
The content of the file /etc/sudoers.d/10-installer which is not owned by any package has not been adjusted to the new sudo syntax. Current content:
%wheel ALL=(ALL) ALL
I think it should read
%wheel ALL=(ALL:ALL) ALL
Anyway, my system worked with and without the above change.
2 Likes
You probably miss a line with
%wheel ALL=(ALL:ALL) ALL
either in /etc/sudoers or in any file in /etc/sudoers.d directory.
2 Likes
Why using files in /etc/sudoers.d if it can be specified in /etc/sudoers?
Ah, I think I did, thanks for pointing that out @Wollie!
1.9.9-1 /etc/sudoers has this line commented out:
# %wheel ALL=(ALL:ALL) ALL
When merging remove the # and all is well.
1 Like
… because this could cause that some users set the %wheel entry in /etc/sudoers.d files, others in /etc/sudoers, so it’s more complex to maintain it from an uniform update approach. I don’t think many users need a different setting here. 
1 Like
I merged the changes, and didn’t uncomment this line that allows members of group wheel to execute any command, everything is working as intended.
I don’t know what’s wrong on your side if it didn’t work the first time your tried to merge or without uncommenting the wheel line.
I use meld with pacdiff to view difference to help merging, you can’t fail this way.
//EDIT: however, I have this file in sudoers.d
[omano-nvme sudoers.d]# cat 10-installer
%wheel ALL=(ALL) ALL
Can’t find the owner of this file though, and I don’t remember creating it.
I don’t think it’s speed related. My Internet is fiber 480Mb/100Mb, and I can get 100% of those speeds via tests, so that’s not too bad either. The delays must be caused by something else.
Thinking about internet speed was low hanging fruit, as I understand there are a wide variety of internet speeds across the globe. I guess we also have to remember that the speed at which one connects to their ISP is not representative of all the hops involved across the greater web… i.e. traceroute
Flipping the connection scope around… Assuming the AUR cache file pamac is consuming is on the Arch Servers, might this be a “max connection” issue? If AUR and Manjaro users (via pamac) are both reading this file, how many connections can it sustain before some users connections are rejected/denied and the long delays are multiple pamac retries? Have I just been lucky (less hits) with my Central timezone usage?
To help prove any of this, and if it’s possible, could a test branch version of pamac with verbose status/progress enabled reveal what pamac is trying to accomplish when the delays occur? If it gets caught in a “file access” retry loop, then it might help strengthen the idea that the server file connections are maxing. Or maybe it tells us something completely different.
I’m on Unstable and I have no pacnews regarding sudo:
find /etc -name \*sudo\*
/etc/sudoers
/etc/sudo_logsrvd.conf
/etc/sudoers.d
/etc/sudo.conf
/etc/pam.d/sudo
No breakage after reboot, and the content of sudoers.d is the same as @omano’s:
%wheel ALL=(ALL) ALL
I mean I didn’t have to merge anything, it just works Ⓒ
1 Like
May be your PC has low free RAM and it has low performance HDD for swap file? Then it could be like this: `Refreshing AUR` stage downloads a 9.3 MiB file and eats about 1.5 GiB of RAM memory
But here in testing branch you got the 11.0.2-6 version of libpamac initially, which takes about 900 MiB of RAM in case of my semi-garbage notebook listed there.
1 Like
I’ve an issue with the package wpa_supplicant (or at least I believe it is this package):
A Wireless hotspot hosted on the Manjaro device can not be accesed by some devices (iphone), if we use the WPA & WPA2 encryption.
Using no encryption (BIG NO) solves that problem.
I tried to understand how this part of the config works, and to my understanding the change is almost null. It seems it adds the group ‘ALL’ to the configuration lines so that doesn’t really change anything.
What I understood is it works like that
A B = (C:D) E
where A is a user (or group when starting with %) for which the configuration line is made, B is the host allowed where commands can be run, the C (or C:D) is the user (or the user:group) for which A is authorized to run command as, and E is the command that A is authorized to run.
So basically the change only adds the group as which root (or other user/group depending on the line changed) is allowed to run commands as.
//EDIT: another change in the file is the syntax of one of the last lines
## Read drop-in files from /etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /etc/sudoers.d
became
## Read drop-in files from /etc/sudoers.d
@includedir /etc/sudoers.d
which seems to change nothing too.
Seems sudo 1.9.9 went for the ALL=(ALL:ALL) ALL hence you might have a pacnew file.
1 Like
So in fact /etc/sudoers.d/10-installer is what rules users of wheel group ability to execute commands as relevant entry in /etc/sudoers in commented out by default:
## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL:ALL) ALL
However, according to
$ pacman -Qo /etc/sudoers.d/10-installer
error: No package owns /etc/sudoers.d/10-installer
that file is some kind of leftover or something.
So I am not sure what is a correct way to proceed here: uncomment a line in sudoers file (which is deviation from package-provided defaults) or simply adjust a custom 10-installer file entry to look like as it goes in sudoers, but without hash symbol. Again, I face no issue yet.