Apparently opensearch and opensearch-cli are in conflict. Is that normal, given that opensearch-cli is listed as an optionnal dependency for opensearch?
Sure. I’m reporting it here though, because that’s the testing branch.
i get a kernel panic under virtualbox , do not detect smtp processor any more
see this ( inxi under vbox )
info: model: AMD Ryzen 5 5600x bits :64 type : MCP arch : Zen 3
Family 0x19 (25) modele-id : 0x21 (33) stepping :0 microcode:0x6000626
Topology cpus:1x cores:2 smt:<unsupported> etc..I am unable to find corresponding packages, like nvidia-utils-495xx, or nvidia-495xx-dkms, in the repository. What am I doing wrong?
The current NVIDIA driver does not have a version number in the name so it’s just nvidia-utils, nvidia-dkms, etc.
Thanks a lot for that update. This now seems to go to 495.46. Unfortunately, that version seems to be incompatible with kernel 5.16 yet:
==> dkms install --no-depmod nvidia/495.46 -k 5.16.0-1-MANJARO
Error! Bad return status for module build on kernel: 5.16.0-1-MANJARO (x86_64)
Consult /var/lib/dkms/nvidia/495.46/build/make.log for more information.
==> WARNING: `dkms install --no-depmod nvidia/495.46 -k 5.16.0-1-MANJARO' exited 10
UPDATE: For this problem, it looks like there is already a solution.
See mm/migrate.c: remove MIGRATE_PFN_LOCKED · torvalds/linux@ab09243 · GitHub for details.
As described there, the driver needs a small patch:
--- a/kernel/nvidia-uvm/uvm_migrate_pageable.c 2022-01-08 21:51:32.672454683 +0100
+++ b/kernel/nvidia-uvm/uvm_migrate_pageable.c 2022-01-08 21:51:52.298644944 +0100
@@ -406,7 +406,7 @@
uvm_push_set_flag(&push, UVM_PUSH_FLAG_CE_NEXT_MEMBAR_NONE);
copying_gpu->parent->ce_hal->memset_8(&push, dst_address, 0, PAGE_SIZE);
- dst[i] = migrate_pfn(page_to_pfn(dst_page)) | MIGRATE_PFN_LOCKED;
+ dst[i] = migrate_pfn(page_to_pfn(dst_page));
}
if (copying_gpu) {
@@ -490,7 +490,7 @@
uvm_push_set_flag(&push, UVM_PUSH_FLAG_CE_NEXT_MEMBAR_NONE);
copying_gpu->parent->ce_hal->memcopy(&push, dst_address, src_address, PAGE_SIZE);
- dst[i] = migrate_pfn(page_to_pfn(dst_page)) | MIGRATE_PFN_LOCKED;
+ dst[i] = migrate_pfn(page_to_pfn(dst_page));
}
// TODO: Bug 1766424: If the destination is a GPU and the copy was done by
But, with 496.46, the screen, especially in the terminal, starts to flicker, and sometimes, the terminal output even jumps up and down by one line, rendering the terminal almost unusable.
UPDATE This seems to be connected to the compositor. I am using picom here - as soon as I kill it, that jumping and flickering disappears.
And, my second screen gets disabled on every start.
Also, in contrast to former versions, I now have to start nvidia-settings with sudo to be able to apply any changes to display settings.
Unfortunately, even when I request the changes to be saved in the X configuration file, they do not survive a reboot - the second screen then gets disabled again.
Saving the nvidia-settings configuration and running nvidia-settings --load-config-only on login does not help - it looks like it is doing nothing.
Using EndeavourOS, 495.46 kept me from logging in, just returned me to the display manager. I ended up using the downgrade command to revert back to 495.44. Did this happen to anyone?
Are you lost? 
1 Like
I’m with Yochanan, are you lost?
1 Like
oldrocker99’s point could be to compare driver work under couple different OS environments. So I think they has at least that point.
Sometimes somebody get lost, sometimes others lacks to get payload idea of question. Payload for Manjaro could be comparison of work under another OS and oldrocker99 and
clarifies for us that it is a broad problem, not only Manjaro.
I think it is good to have such feedback also - to know is it a distros wide issue or Manjaro only: that info could point any user/dev to a possible issue solution which was applied under another environment to fix possible issues or to realize that it could be a package problem on GNU/Linux (or Arch-family distros).
1 Like
For me, with Nvidia driver 495.46, the second screen is always disabled after the system was started.
No matter what I tried, including “Save to X configuration file” in nvidia-settings, running nvidia-settings --load-config-only on login, nothing worked.
Currently, I have to enter something like
nvidia-settings --assign CurrentMetaMode="DVI-I-1: nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DVI-D-0: nvidia-auto-select +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On};"
in a terminal after the desktop appeared.
Interestingly, this command doesn’t seem to do anything if included in .xinitrc, startxfce4 or in the list of programs running on startup.
Only if entered in a terminal on the first screen once the desktop has been fully drawn, the above command activates my second screen.
UPDATE
Seems that xfce4 is interfering here. After entering the command
nvidia-settings --assign CurrentMetaMode="DVI-I-1: nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DVI-D-0: nvidia-auto-select +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On};"
I had to go to Settings, Display, choose my primary screen, set it to primary, and click Apply. Afterwards, I had to go to the second screen, and had to click Apply as well. Apparently, this now made my dual screen setup persistent.
A bit strange, though, as I do not remember having to do that before.
I couldn’t build vhba module for kernel 5.16 from this site:
https://gitlab.manjaro.org/packages/extra/linux516-extramodules/vhba-module
So i changed first sha sum in PKGBUILD file to:
72c5a8c1c452805e4cef8cafefcecc2d25ce197ae4c67383082802e5adcd77b6
just like in PKGBUILD file for vhba module for kernel 5.15 and it worked! 
Well, i am too nooby to tell if this is how i should act but i feel kinda like a developer now XDDD
Everything went fine with the update and as far I can tell, all seems to be working as usual.
However, I have a question. I noticed info about pipewire:
I checked and I have it installed. However, I’m not sure if it’s enabled or doing something. Should I issue that command or not? I’m afraid I will mess up something and enable pipewire if it’s inactive, and then I won’t know how to reverse it. How can I find out if pipewire is active, and I use it (unknowingly)?
My system installation is quite old, probably near to 7 years, and I don’t remember all the things I’ve done so many years ago ;). It’s possible that I wanted to do something with pipewire but in the end I did nothing, so I’m not sure what it is doing (or not doing) in the system.
you can try inxi -Fza and look for
Sound Server-1: ALSA v: k5.16.0-1-MANJARO running: yes
Sound Server-2: JACK v: 1.9.19 running: no
Sound Server-3: PulseAudio v: 15.0 running: no
Sound Server-4: PipeWire v: 0.3.42 running: yes
Or straight to the point:
inxi -A | grep "Sound Server"
1 Like
On Plasma with pulseaudio still in use inxi is getting:
$ inxi -A | grep -i sound
Sound Server-1: ALSA v: k5.15.15-1-MANJARO running: yes
Sound Server-2: PulseAudio v: 15.0 running: yes
AFAIK installation of manjaro-pipewire (vs manjaro-pulse) package “marks” the switch to pipewire audio server:
$ LANG=C pacman -Qi manjaro-pipewire manjaro-pulse | grep -i name
error: package 'manjaro-pipewire' was not found
Name : manjaro-pulse