[Testing Update] 2022-02-01 - Kernels, Pipewire 0.3.44, Qt5, Mesa 21.3.5, Wine 7.0

… 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. :smiley_cat:

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.

Issue with printing:

Whitespaces are printed black with an hp-printer and the cups-print-driver. Tested with evince, which returns black text on black/grey background (it should be white background). Whilst firefox prints correctly, just the last side(printing 19 pages doublesided) will be black.

Yeah that is what I figured, no package seems to own it, this file isn’t owned by anything (tried pacman -Qo, tried pacman -F, tried pkgfile, tried google too which pointed me to results where this file also exist on other distribution), so it maybe is a leftover from initial installation, but it is hard to find its origin in Manjaro. But if it is a leftover, then that would mean without it we wouldn’t be able to sudo (because we don’t have the corresponding line enabled in /etc/sudoers) so I don’t know something is still weird with that theory.

I also think we can leave it or add the third ALL that wouldn’t change a lot for most/all users. I will keep the file in sudoers.d (and add the third ALL) and leave the sudoers file as default, with wheel line commented.

//EDIT: I will try to install Manjaro on VM to see if the file exist on old/current ISO installation, for the sake of curiosity.

//EDIT2: this file /etc/sudoers.d/10-installer is created at installation apparently, it is not owned by anything, but it is there at first boot of an installation (manjaro-kde-21.0.6-210607-linux510.iso).

//EDIT3: I found it, it is in the Calamares installer configuration file (users.conf), this is indeed created during the installation process:

# When *sudoersGroup* is set to a non-empty string, Calamares creates a
# sudoers file for the user. This file is located at:
#     `/etc/sudoers.d/10-installer`
# Remember to add the (value of) *sudoersGroup* to *defaultGroups*.
#
# If your Distribution already sets up a group of sudoers in its packaging,
# remove this setting (delete or comment out the line below). Otherwise,
# the setting will be duplicated in the `/etc/sudoers.d/10-installer` file,
# potentially confusing users.
sudoersGroup:    wheel

So yeah, by default no one should have the wheel line enabled in /etc/sudoers but should have the 10-installer file with the wheel group privileges.

:male_detective:

4 Likes

There was an update to qt5-wayland that introduced a race condition with plasmashell and kactivitymanagerd. We saw it a lot on Plasma Mobile, but I would imagine it would happen on x64 too if you have systemdBoot=true in kdeglobals config.

You can try downgrading qt5-wayland for now as that specific issue has not been fixed upstream yet.

Thanks @Wollie I can sudo again :slight_smile:

1 Like

It wasn’t laptop’s specs either. This is a high performance gaming laptop. Today pamac’s update check looks better then yesterday’s, so it looks it wasn’t the permanent issue. Nevermind, if the delay will be repeating frequently, I’ll post a bug/issue. Hopefully this was some temporary issue. We’ll see.

Nice, guys, thanks, we had a nice talk here. Pity that some didn’t listen.

Packages (1) manjaro-system-20220202-1

Total Download Size:   0.02 MiB
Total Installed Size:  0.00 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n] 
:: Retrieving packages...
 manjaro-system-2...    23.9 KiB  70.4 KiB/s 00:00 [#########################] 100%
(1/1) checking keys in keyring                     [#########################] 100%
(1/1) checking package integrity                   [#########################] 100%
(1/1) loading package files                        [#########################] 100%
(1/1) checking for file conflicts                  [#########################] 100%
(1/1) checking available disk space                [#########################] 100%
:: Processing package changes...
(1/1) upgrading manjaro-system                     [#########################] 100%
==> Remove obsolete 10-installer file from sudoers.d ...
==> Checking for 'os-prober' setup ...
grep: /etc/default/grub: No such file or directory
    We will reenable 'os-prober' for you ...
/tmp/alpm_vhUpDv/.INSTALL: line 99: update-grub: command not found

==> Remove obsolete 10-installer file from sudoers.d …

“Wow, really?” I thought and issued
$ sudo ls /etc/sudoers.d/
to see

openm is not in the sudoers file. This incident will be reported.

All those who haven’t uncommented the respective line in /etc/sudoers will suffer the way I do now.
I repeat, on my side no pacnew file was created when updating sudo, hence I suppose having that line commented is the DEFAULT for Manjaro systems (EDIT: reason found down here).

TLDR: login as root and edit /etc/sudoers with visudo /etc/sudoers

3 Likes

Well I updated the manjaro-systems package again to not to remove the file. Now we know it gets created by Calamares. The only questions is if we should adopt to the group privileges or not, as both versions work.

The same issue. I got the message of sudo pacman -Syu:

zesko is not in the sudoers file. This incident will be reported.

Solution:

  • Run as root: su
  • I create and edit new file vim /etc/sudoers.d/user.
%wheel ALL=(ALL) ALL
3 Likes

@philm , in the “known issues” section we should maybe add a point for the massive performance backdrop on btrfs file systems with kernel 5.16.
The workaround is to mount the file systems with the noautodefrag option.
The fixes were merged in the mainline and will come with kernel 5.16.5, which is currently in the unstable channel.

2 Likes

I think we should let it be as it was, the Calamares installer adds the user to wheel group, and creates the 10-installer file that allows user in wheel group to be able to sudo. Removing the file would require that the sudoers file is then properly reconfigured or else the user loses his sudo rights. And reconfiguring the sudoers file might be frowned upon by users, if you start automatically messing with it without user consent, especially for people who modify their system and this file and that can have issues by enabling wheel group privileges in this file.

I think that sudoers.pacnew file scare we had was not justified, merging the changes (I mean if the user does it himself by checking it) does nothing bad to the system and there is no need to remove how things worked since the beginning of time in Manjaro (or at least since I use it :D).

5 Likes