Package Details: corefreq-server 1.98.5-1

Git Clone URL: https://aur.archlinux.org/corefreq.git (read-only, click to copy)
Package Base: corefreq
Description: CoreFreq server
Upstream URL: https://github.com/cyring/CoreFreq
Licenses: GPL-2.0-only
Submitter: artafinde
Maintainer: artafinde
Last Packager: artafinde
Votes: 7
Popularity: 0.21
First Submitted: 2021-04-07 17:46 (UTC)
Last Updated: 2024-11-13 21:00 (UTC)

Latest Comments

1 2 3 Next › Last »

CyrIng commented on 2024-08-29 22:47 (UTC) (edited on 2024-08-30 11:10 (UTC) by CyrIng)

@spacemann @artafinde

ArchLinux: "Remove DKMS modules" issue #508 https://github.com/cyring/CoreFreq/issues/508 [SOLVED]

spacemann commented on 2024-08-28 11:22 (UTC) (edited on 2024-08-28 11:28 (UTC) by spacemann)

Edit: oh, you folks got here quick! I was just reporting back with a further guess, didn't expect you to be on top of it already :D

It seems like it (most likely) is happening as a result of the "Remove DKMS modules" step that happens when installing a new kernel.

This operation seems like it probably removes the corefreqd and corefreq-cli binaries along with the dkms module, and then doesn't reinstall them.

i.e., in the output when installing a new kernel, you'll see two steps that look like the following: (3/3) Remove DKMS modules ==> dkms remove --no-depmod corefreq/1.98.2

followed later by: (3/6) Install DKMS modules ==> dkms install --no-depmod corefreq/1.98.2 -k

(This is just a guess, but it seems like a strong candidate for the reason behind the problem.)

artafinde commented on 2024-08-28 11:21 (UTC)

I see that might be the issue - let me push an update.

skrimix commented on 2024-08-28 10:57 (UTC)

But the files are owned by two other packages and pacman doesn't copy the new ones? I'm not sure how this is supposed to work but it seems weird to me that dkms deletes files managed by pacman, which pacman also gives warnings about later

artafinde commented on 2024-08-28 10:47 (UTC)

Yeah but the subsequent dkms build would rebuild those against new kernel..

skrimix commented on 2024-08-28 10:36 (UTC)

Still happens for me too. As I understand it, kernel changes trigger "dkms remove" command, which reads POST_REMOVE option and calls "scripter.sh rm -rf -- /usr/bin/corefreqd /usr/bin/corefreq-cli", deleting the binaries

artafinde commented on 2024-08-28 10:29 (UTC)

@spacemann hmm that's weird. I don't see something weird there: https://aur.archlinux.org/cgit/aur.git/tree/dkms.conf?h=corefreq

spacemann commented on 2024-08-28 10:15 (UTC)

Hi @CyrIng , there is something still going on with this re: the repeated removal of corefreq-cli and corefreqd. It appears to be happening when the kernel is reconfigured or compiled due to changes made to other aspects of the kernel.

I haven't yet determined what exactly is causing it, as I've been handling a variety of other tasks, but so far tonight, the binaries have disappeared three times (necessitating reinstallation of corefreq-client and corefreq-server).

Doesn't seem to be mkinitcpio -P... idk. Super frustrating though haha

CyrIng commented on 2024-07-23 14:07 (UTC)

@skrimix thank you for your issue.

It means the following substituted POST_REMOVE in dkms.conf did not work with your setup

scripter.sh rm -f /bin/corefreqd /bin/corefreq-cli

Issue #499 is created at https://github.com/cyring/CoreFreq/issues/499

skrimix commented on 2024-07-20 18:57 (UTC)

For me the BINARIES and POST_REMOVE lines in dkms.conf seem to cause the same issue. Any dkms remove operations on the module delete the binaries, requiring a reinstall of corefreq-{client,server} packages.

1 2 3 Next › Last »