[Unstable Update] December 2023 Edition

Yes. plymouth depends on filesystem. There were changes with the newer versions that go together, so both must be downgraded together to match.

Not quite. The logo was moved from plymouth to filesystem, that’s why the old and new packages must be downgraded / upgraded together.

750 is correct in this case. So we have to figure out which package is not matching that folder via pacman -Qo /usr/share/polkit-1/rules.d

1 Like

On my both laptops, I installed 3 years ago Manjaro KDE via Minimal ISO,

But now I don’t find plymouth installed nor configured in /etc/default/grub nor HOOKS in /etc/mkinitcpio.conf
Even /var/log/pacman.log doesn’t contain any install/remove/upgrade related to it,

Was it added later ? And should I add it to avoid problems ?

plymouth is entirely optional, in fact it sometimes causes problems, and is one of the first things I would remove.

4 Likes

:information_source: I’ve just made major changes with plymouth 22.02.122-17 that removed the old unneeded cruft in preparation for the new upstream v23.51.283:

:warning: WARNING: The plymouth-encrypt and sd-plymouth hooks no longer exist in the package. You should replace them with encrypt and plymouth hooks in your mkinitcpio.conf. The lxdm-plymouth.service, lightdm-plymouth.service and sddm-plymouth.service systemd service files no longer exist in the package. You should enable lxdm.service, lightdm.service or sddm.service instead.

A post was split to a new topic: The package grub-update does NOT need to be required by grub

/usr/share/polkit-1/rules.d/ is owned by fwupd 1.9.10-1
/usr/share/polkit-1/rules.d/ is owned by gamemode 1.8.1-1
/usr/share/polkit-1/rules.d/ is owned by geoclue 2.7.1-1
/usr/share/polkit-1/rules.d/ is owned by gvfs 1.52.1-1
/usr/share/polkit-1/rules.d/ is owned by polkit 123-1
/usr/share/polkit-1/rules.d/ is owned by systemd 255.1-1

The only matching package that got updated in that moment was gamemode.

Well, nothing changed with Arch packaging with gamemode 1.8.1-1. :man_shrugging: I haven’t dug into the upstream changes.

Yes, I was wondering the same :thinking:

there seems to be something with that directory maybe?

( 9/37) upgrading gamemode 
warning: directory permissions differ on /usr/share/polkit-1/rules.d/
filesystem: 750  package: 755

I know the answer to my thing is [Unstable Update] December 2023 Edition - #44 by philm
I just meant it’s the same directory and gamemode

this indicates that the permissions are wrong. Someone should open an issue at Arch to change the permissions of that folder to those of the polkit package.

11 posts were split to a new topic: File permissions of /etc/bluetooth

I see reports upstream. And it doesn’t seem to work right at the moment anyway. gamemoded -t fails for me as well. User intervention required to restore functionality, it seems.

That has been the case for a long time, at least it was in the wiki +5months ago when I installed it because I remember adding me to the group when installing.

This feature requires the user to be in the gamemode user group to work.

https://wiki.archlinux.org/title/Gamemode#Renicing

But there IS a bug, that I also reported to the github, that shows gamemode as inactive in mangohud while in reality it actually works.

You can test by starting the game and then type gamemoded -s in a terminal to confirm it is actually active (even though it will say that it is off in mangohud).

Edit
Although, I have no problems reported by gamemoded -t, seems to me a you thing,

gamemoded -t
: Loading config
: Running tests

:: Basic client tests
:: Passed

:: Dual client tests
gamemode request succeeded and is active
Quitting by request...
:: Passed

:: Gamemoderun and reaper thread tests
...Waiting for child to quit...
...Waiting for reaper thread (reaper_frequency set to 5 seconds)...
:: Passed

:: Supervisor tests
:: Passed

:: Feature tests
::: Verifying CPU governor setting
::: Passed
::: Verifying Scripts
::: Passed (no scripts configured to run)
::: Verifying GPU Optimisations
::: Passed (gpu optimisations not configured to run)
::: Verifying renice
::: Passed (no renice configured)
::: Verifying ioprio
::: Passed
:: Passed

: All Tests Passed!
1 Like

The reply I linked apparently fixed that user’s problems.
gamemoded -s only reports if gamemode is running or not. It doesn’t comment on issues like mentioned in the issue report. Here’s what my journal has to say:

joulu 22 17:45:16 jp-gentoo pkexec[66839]: jp: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/jp] [COMMAND=/usr/lib/gamemode/cpugovctl set performance]
joulu 22 17:45:16 jp-gentoo gamemoded[66839]: Error executing command as another user: Not authorized
joulu 22 17:45:16 jp-gentoo gamemoded[66839]: This incident has been reported.
joulu 22 17:45:16 jp-gentoo gamemoded[1140]: ERROR: External process failed with exit code 127
joulu 22 17:45:16 jp-gentoo gamemoded[1140]: ERROR: Output was:
joulu 22 17:45:16 jp-gentoo gamemoded[1140]: ERROR: Failed to update cpu governor policy
joulu 22 17:45:16 jp-gentoo pkexec[66844]: jp: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/jp] [COMMAND=/usr/lib/gamemode/procsysctl split_lock_mitigate 0]
joulu 22 17:45:16 jp-gentoo gamemoded[66844]: Error executing command as another user: Not authorized
joulu 22 17:45:16 jp-gentoo gamemoded[66844]: This incident has been reported.
joulu 22 17:45:16 jp-gentoo gamemoded[1140]: ERROR: External process failed with exit code 127
joulu 22 17:45:16 jp-gentoo gamemoded[1140]: ERROR: Output was:
joulu 22 17:45:16 jp-gentoo gamemoded[1140]: ERROR: Failed to update split_lock_mitigate
joulu 22 17:45:16 jp-gentoo gamemoded[1140]: ERROR: Skipping ioprio on client [66838,66838]: ioprio was (0) but we expected (4)

Perhaps being added to the group is a requirement for governor switching now as well.

Yeah, mods are prob going to split it into its own thread, that is a you thing, check my edited post above.

And the person who started the thread.

Eye-rolling aside, same as the author, I ran sudo usermod -aG gamemode $(whoami), and the tests pass, and no more warnings about lack of permissions on setting governors.

1 Like

Im getting some odd system instability presently, an oops and kernel bug in the logs.

Is this the sort of thing to report upstream, or is this something Manjaro specific? How do I tell the difference?

Dec 23 16:10:56 kitsune kernel: DR3: 0000000180022fd0 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Dec 23 16:10:56 kitsune kernel: DR0: 0000000180022c70 DR1: 0000000180022cc0 DR2: 0000000180022d00
Dec 23 16:10:56 kitsune kernel: CR2: 00000934fb017000 CR3: 000000018dbf2000 CR4: 00000000003506e0
Dec 23 16:10:56 kitsune kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 23 16:10:56 kitsune kernel: FS:  00007fb6278cc740(0000) GS:ffff96dddec00000(0000) knlGS:0000000000000000
Dec 23 16:10:56 kitsune kernel: R13: ffffbbc7c6043f58 R14: 0000000000000000 R15: 0000000000000000
Dec 23 16:10:56 kitsune kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RBP: ffffbbc7c6043f48 R08: 0000000000000000 R09: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RDX: 0000000000000802 RSI: 0000000000000000 RDI: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RAX: ffffbbc7c6040000 RBX: 0000000000000001 RCX: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RSP: 0018:ffffbbc7c6043e50 EFLAGS: 00010202
Dec 23 16:10:56 kitsune kernel: Code: 08 00 00 03 00 00 00 f6 05 e9 46 cf 01 02 74 0c 31 d2 be 09 00 00 00 e8 73 40 ff ff bf 09 00 00 00 e8 69 e5 ec ff 0f 0b eb f2 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 >
Dec 23 16:10:56 kitsune kernel: RIP: 0010:__secure_computing+0xbb/0xc0
Dec 23 16:10:56 kitsune kernel: ---[ end trace 0000000000000000 ]---
Dec 23 16:10:56 kitsune kernel:  asus_wmi crypto_simd snd_hwdep ledtrig_audio sparse_keymap cryptd platform_profile snd_pcm i8042 cfg80211 rapl igb asus_wmi_sensors snd_timer serio dca sp5100_tco mxm_wmi rfkill >
Dec 23 16:10:56 kitsune kernel: Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat nf_tables libcrc32c br_ne>
Dec 23 16:10:56 kitsune kernel:  </TASK>
Dec 23 16:10:56 kitsune kernel: R13: 00007ffcc0760298 R14: 000055b4a452b930 R15: 000055b4a4252c78
Dec 23 16:10:56 kitsune kernel: R10: 00000000ffffffff R11: 0000000000000246 R12: 0000000000000001
Dec 23 16:10:56 kitsune kernel: RBP: 00007ffcc0760288 R08: 0000000000000000 R09: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RDX: 0000000000000008 RSI: 00007ffcc0760230 RDI: 0000000000000005
Dec 23 16:10:56 kitsune kernel: RAX: ffffffffffffffda RBX: 000055b4a45339d0 RCX: 00007fb6279f756c
Dec 23 16:10:56 kitsune kernel: RSP: 002b:00007ffcc07601e0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
Dec 23 16:10:56 kitsune kernel: Code: ec 28 48 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 19 58 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 34 44 89 c7 48 89 44 24 >
Dec 23 16:10:56 kitsune kernel: RIP: 0033:0x7fb6279f756c
Dec 23 16:10:56 kitsune kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Dec 23 16:10:56 kitsune kernel:  ? do_syscall_64+0x6c/0x90
Dec 23 16:10:56 kitsune kernel:  ? do_syscall_64+0x6c/0x90
Dec 23 16:10:56 kitsune kernel:  ? srso_return_thunk+0x5/0x10
Dec 23 16:10:56 kitsune kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
Dec 23 16:10:56 kitsune kernel:  ? srso_return_thunk+0x5/0x10
Dec 23 16:10:56 kitsune kernel:  ? do_syscall_64+0x6c/0x90
Dec 23 16:10:56 kitsune kernel:  ? srso_return_thunk+0x5/0x10
Dec 23 16:10:56 kitsune kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
Dec 23 16:10:56 kitsune kernel:  ? srso_return_thunk+0x5/0x10
Dec 23 16:10:56 kitsune kernel:  do_syscall_64+0x3a/0x90
Dec 23 16:10:56 kitsune kernel:  syscall_trace_enter.isra.0+0x9a/0x1a0
Dec 23 16:10:56 kitsune kernel:  ? __secure_computing+0xbb/0xc0
Dec 23 16:10:56 kitsune kernel:  ? asm_exc_invalid_op+0x1a/0x20
Dec 23 16:10:56 kitsune kernel:  ? __secure_computing+0xbb/0xc0
Dec 23 16:10:56 kitsune kernel:  ? exc_invalid_op+0x50/0x70
Dec 23 16:10:56 kitsune kernel:  ? __secure_computing+0xbb/0xc0
Dec 23 16:10:56 kitsune kernel:  ? do_error_trap+0x6a/0x90
Dec 23 16:10:56 kitsune kernel:  ? __secure_computing+0xbb/0xc0
Dec 23 16:10:56 kitsune kernel:  ? do_trap+0xda/0x100
Dec 23 16:10:56 kitsune kernel:  ? die+0x36/0x90
Dec 23 16:10:56 kitsune kernel:  <TASK>
Dec 23 16:10:56 kitsune kernel: Call Trace:
Dec 23 16:10:56 kitsune kernel: DR3: 0000000180022fd0 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Dec 23 16:10:56 kitsune kernel: DR0: 0000000180022c70 DR1: 0000000180022cc0 DR2: 0000000180022d00
Dec 23 16:10:56 kitsune kernel: CR2: 00000934fb017000 CR3: 000000018dbf2000 CR4: 00000000003506e0
Dec 23 16:10:56 kitsune kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 23 16:10:56 kitsune kernel: FS:  00007fb6278cc740(0000) GS:ffff96dddec00000(0000) knlGS:0000000000000000
Dec 23 16:10:56 kitsune kernel: R13: ffffbbc7c6043f58 R14: 0000000000000000 R15: 0000000000000000
Dec 23 16:10:56 kitsune kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RBP: ffffbbc7c6043f48 R08: 0000000000000000 R09: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RDX: 0000000000000802 RSI: 0000000000000000 RDI: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RAX: ffffbbc7c6040000 RBX: 0000000000000001 RCX: 0000000000000000
Dec 23 16:10:56 kitsune kernel: RSP: 0018:ffffbbc7c6043e50 EFLAGS: 00010202
Dec 23 16:10:56 kitsune kernel: Code: 08 00 00 03 00 00 00 f6 05 e9 46 cf 01 02 74 0c 31 d2 be 09 00 00 00 e8 73 40 ff ff bf 09 00 00 00 e8 69 e5 ec ff 0f 0b eb f2 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 >
Dec 23 16:10:56 kitsune kernel: RIP: 0010:__secure_computing+0xbb/0xc0
Dec 23 16:10:56 kitsune kernel: Hardware name: ASUS System Product Name/ROG CROSSHAIR VII HERO (WI-FI), BIOS 5003 02/03/2023
Dec 23 16:10:56 kitsune kernel: CPU: 8 PID: 2074 Comm: pipewire-pulse Tainted: G           OE      6.6.8-2-MANJARO #1 146dce4c0b8863ad44f28ec2edb37ecbadc944c7
Dec 23 16:10:56 kitsune kernel: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
Dec 23 16:10:56 kitsune kernel: kernel BUG at kernel/seccomp.c:1361!

It depends what kernel that is, when it happened and if it is indeed a regression in stable branched kernels. You may need to do a git-bisect on the kernel to find that faulty commit.

  • get familiar with git bisect
  • check my sample on how to do it with a PKGBUILD
  • get back to us and send an detailed email to upstream if you found a regression.
1 Like

So far its only happened the once, and I dont have reproduction steps for it. This was 6.6.8-2. Is the purpose of git-bisect to build the kernel multiple times to see if I can reproduce the bug on different kernels? If so I guess Ill need to figure out how to trigger it first.