[Unstable Update] November 2024 Edition

Announcements Unstable Updates
,
21

It happened here:

(2/3) Remove DKMS modules

Error! acpi_call/1.2.1: Missing the module source directory or the symbolic link pointing to it.
Manual intervention is required!
==> dkms remove --no-depmod acpi_call/1.2.2 -k 6.6.59-1-MANJARO

Error! acpi_call/1.2.1: Missing the module source directory or the symbolic link pointing to it.
Manual intervention is required!
==> dkms remove --no-depmod acpi_call/1.2.2 -k 6.11.6-1-MANJARO
==> depmod 6.6.59-1-MANJARO
==> depmod 6.11.6-1-MANJARO

But everything went fine apparently, because the command acpi_call/1.2.2 was executed.

The command dkms status returns the following:

acpi_call/1.2.1: broken

Error! acpi_call/1.2.1: Missing the module source directory or the symbolic link pointing to it.
Manual intervention is required!
acpi_call/1.2.2, 6.11.7-1-MANJARO, x86_64: installed
acpi_call/1.2.2, 6.6.60-1-MANJARO, x86_64: installed
22

Please define broken. :wink:

23

Hi @Yochanan,

You’re right, it wasn’t clear enough :wink:

Kernel linux612 start loading after GRUB but no Plymouth boot screen.
It remain on a black screen even if kernel seem to load in the background. Keyboard respond to ctrl+alt+del to reboot as the PC stuck in that black screen state.

EDIT1: Same problem as linux612-nvidia 565.57.01-0.2 → lightdm.service failed to start.

If I may bring more help on this, let me know :slight_smile:

Wish You well

24

Can you not use nvidia-dkms instead?

25 
v86d-0.1.10-9-x86_64
(1/1) checking keys in keyring
(1/1) checking package integrity
(1/1) loading package files
(1/1) checking for file conflicts
error: failed to commit transaction (conflicting files)
v86d: /sbin exists in filesystem (owned by filesystem)
v86d: /sbin/v86d exists in filesystem
Errors occurred, no packages were upgraded.
3 Likes
26

Can confirm here too.
And for whatever its worth … both filesystem and v86d are manjaro packages.
(built by @Yochanan and @philm respectively)

I’d probably assume its fine to force it through.
But its still probably something to handle before it gets to the other branches.

27

Got the same error using pacman, however when I try with pamac cli, it still ends with an error but the output is slightly different:

Apply transaction ? [y/N] y
Checking keyring...                                                                                                             [25/25]
Checking integrity...                                                                                                           [25/25]
Loading packages files...                                                                                                       [25/25]
Checking file conflicts...                                                                                                      [25/25]
Warning: v86d: /sbin/v86d already exists in filesystem
It has been backed up to /sbin/v86d.old
Resolving dependencies...
Checking inter-conflicts...
Checking keyring...                                                                                                             [25/25]
Checking integrity...                                                                                                           [25/25]
Loading packages files...                                                                                                       [25/25]
Checking file conflicts...                                                                                                      [25/25]
Error: Failed to commit transaction:
conflicting files:
- v86d: /sbin already exists in filesystem (owned by filesystem)
28

Huh… so … pamac just defaults to automatically moving the conflicting file to *.old?

Eek, thats an undocumented feature.

But also apparently it wont do the same for a directory.

EDIT.
@annoying_daniel @ydar
There is a merge request in that will be removing the v86d dependency, meaning v86d could be removed, which would likewise do away with this error.
If you feel so inclined you can get ahead by manually removing it, ex:

sudo pacman -Rdd v86d

This of course assumes you dont have anything else relying on it, but you should not.
Or you can just wait for the changes to be applied and filter through the mirrors.

1 Like
29

FYI: looking at the directory profile for the new: v86d-0.1.10-9-x86_64 … there appears to be an error in the directories used … falling back to the old style:
/sbin instead of the new /usr/bin

New: just released
mhwd-db-0.6.5-37-any
mhwd-0.6.5-37-x86_64

use command: sudo pacman -Syu --ignore v86d

so conflicts with v86d are avoided

then use: pamac remove -o
to remove the orphaned v86d

1 Like
30

Built mhwd/mhwd-db from updated PKGBUILD, removed v86d and all is well.

31

Is it all is well? Sure the package is built, but does mhwd function properly without that dependency?

32

Yes.

The only thing using v86d was mhwd-fb and nothing was actually using mhwd-fb.

It also placed some things in your initram hooks that would also go unused.

If you want to take my word for it; before this was pushed I manually ripped out the files associated with mhwd-fb and manually removed all of v86d. I ran the updates, rebuilt initramfs, updated grub, and rebooted.

“All is well.”

mhwd appears to function as normal.

(Again - there was not really any other expectation as all of the associated files were effectively unused.)

33

That’s quite odd. All I did is rebuild it with GCC 14 instead of 13.

However, I just removed v86d from the repos as mhwd >=0.6.5.37 (currently 0.6.6-1) no longer requires it.

2 Likes
34

Hi @Yochanan,

As You may see in the EDIT1 of my original post, here is the problem:

Same as linux612-nvidia 565.57.01-0.2 → lightdm.service failed to start. Workaround have been made in linux612-nvidia 565.57.01-0.4 but I don’t know if same patches may be applied for Open Source drivers?

Wish You well

35

11 posts were split to a new topic: Re: Unstable Update MHWD disussion

48

2 posts were merged into an existing topic: Re: Unstable Update MHWD disussion

49

It seems the new version of mesa conflicts, and these packages were removed from the repository, is there any information why this happened?

изображение
изображение547×503 13.5 KB

UPD: According to the archlinux mesa packages, it really does now provide all this
lib32-libva-driver, lib32-libva-mesa-driver=1:24.2.7-1, lib32-mesa-libgl=1:24.2.7-1, lib32-mesa-vdpau=1:24.2.7-1, lib32-opengl-driver, lib32-vdpau-driver
https://archlinux.org/packages/multilib/x86_64/lib32-mesa/

I have not yet found the source information to which it relates, all the required libraries were included in the package mesa ? Nothing in the change list 24.2.7 says about it

3 Likes
50

Try nvidia-open-dkms 565.57.01-4.

1 Like
51

Hi @Yochanan,

I may confirm that linux612 now work as expected with nvidia-open-dkms 565.57.01-4

Wish You well

52

So far, I’m happy with 6.12. Previous version 6.11 since few months caused random issues with screen stuttering. Had to use 6.6 to avoid it.

I’m using 6.12 since few days and haven’t approached this stuttering bug. It still may show up, but so far, so good.

If the bug is gone, I will be really happy. I was ready to look to report this bug, which would require a lot of time, but since 6.11 will be EOL at some time and 6.12 seems to be fine, it is not necessary.

EDIT: Spoke too soon. The bug is also present on 6.12 line, which is not surprising.

1 Like