Thanks for the comment, Stig.

Forwarding to the kernel people.

Assignee: bugsquad => kernel

I will try to give a hand on this, but I don't know how far I can go

Created attachment 14222 [details]
1st Try of spec for dkms 3.0.12

I part from the work done in https://svnweb.mageia.org/packages/cauldron/dkms/branches/WIP/current/

And also the spec for dkms 3.0.12 in fedora, I have to redo some mageia patches and drop a lot that can't be imported to this version due lot of changes in sources

Of course my work need revision, but I install the produced rpm, reboot my system, uninstall and reinstall a dkms module and look normal for me

Created attachment 14223 [details]
dkms 3.0.12 version of symvers pacth

Created attachment 14224 [details]
dkms 3.0.12 version of norpm patch

Created attachment 14225 [details]
dkms 3.0.12 versionof detect-Mageia patch

I was using the created package but the modules are not rebuilt when new kernels are installed, and fail when I do by hand, so I need to do more test/research

This version have /usr/lib/dkms/dkms_autoinstaller that is very different of our current /usr/sbin/dkms_autoinstaller

I need to do some test but look like if we succeed to update to this branch we also must modify the dkms_autoinstaller line in the kernel spec

Created attachment 14344 [details]
Some corrections to the spec

I did try to reproduce the messages in plymouth when the module is builded on boot time but not works, also an alias in the new dkms_autoinstaller is not working

I did perform some test and this time all seems working

For kernels is needed change in the spec

if [ -z "$DURING_INSTALL" ] ; then
 	%if %{versionednamingscheme}
 	    if [ -x /usr/sbin/dkms_autoinstaller -a -d /usr/src/kernel-%{kversion}-$kernel_flavour-%{buildrpmrel} ]; then
 	        /usr/sbin/dkms_autoinstaller start %{kversion}-$kernel_flavour-%{buildrpmrel}
 	%else
 	    if [ -x /usr/sbin/dkms_autoinstaller -a -d /usr/src/kernel-%{kversion}-$kernel_flavour-%{rpmrel} ]; then
 	        /usr/sbin/dkms_autoinstaller start %{kversion}-$kernel_flavour-%{rpmrel}
 	%endif
 	    fi
fi

By

if [ -z "$DURING_INSTALL" ] ; then
 	%if %{versionednamingscheme}
 	    /usr/libexec/dkms_autoinstaller start %{kversion}-$kernel_flavour-%{buildrpmrel}
 	%else
 	    /usr/libexec/dkms_autoinstaller start %{kversion}-$kernel_flavour-%{rpmrel}
 	%endif
fi

Or if you wish you can replace /usr/libexec/dkms_autoinstaller start by /sbin/dkms autoinstall --kernelver

Attachment 14222 is obsolete: 0 => 1

(In reply to katnatek from comment #9)
> Created attachment 14344 [details]
> Some corrections to the spec
> 
> I did try to reproduce the messages in plymouth when the module is builded
> on boot time but not works, also an alias in the new dkms_autoinstaller is
> not working
> 
> I did perform some test and this time all seems working
> 
> For kernels is needed change in the spec
> 
> if [ -z "$DURING_INSTALL" ] ; then
>  	%if %{versionednamingscheme}
>  	    if [ -x /usr/sbin/dkms_autoinstaller -a -d
> /usr/src/kernel-%{kversion}-$kernel_flavour-%{buildrpmrel} ]; then
>  	        /usr/sbin/dkms_autoinstaller start
> %{kversion}-$kernel_flavour-%{buildrpmrel}
>  	%else
>  	    if [ -x /usr/sbin/dkms_autoinstaller -a -d
> /usr/src/kernel-%{kversion}-$kernel_flavour-%{rpmrel} ]; then
>  	        /usr/sbin/dkms_autoinstaller start
> %{kversion}-$kernel_flavour-%{rpmrel}
>  	%endif
>  	    fi
> fi
> 
> By
> 
> if [ -z "$DURING_INSTALL" ] ; then
>  	%if %{versionednamingscheme}
>  	    /usr/libexec/dkms_autoinstaller start
> %{kversion}-$kernel_flavour-%{buildrpmrel}
>  	%else
>  	    /usr/libexec/dkms_autoinstaller start
> %{kversion}-$kernel_flavour-%{rpmrel}
>  	%endif
> fi
> 
> Or if you wish you can replace /usr/libexec/dkms_autoinstaller start by
> /sbin/dkms autoinstall --kernelver

Take care if you choose /usr/libexec/dkms_autoinstaller of make works this 

alias log_daemon_msg='/bin/echo -n'

Because i get complains about log_daemon_msg not found

Created attachment 14353 [details]
Clean version of dkms 3 spec

I add two more patchs and clean almost all the spec

Attachment 14344 is obsolete: 0 => 1

Created attachment 14355 [details]
Patch to replace alias by functions

I replace alias by functions, this works for me, but of course you can review and change

Created attachment 14588 [details]
3rd version of destination override patch

I use sed to remove ^/kernel from the path and I think this works as expected but need test and compare with dkms2 behavior for other modules

At less with dkms-vhba the destination path is the same

This is the result of remove dkms-vhba still with dkms2

rpm -e --nodeps dkms-vhba

-------- Uninstall Beginning --------
Module:  vhba
Version: 20211218-2.mga9
Kernel:  6.6.37-desktop-1.mga9 (x86_64)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

vhba.ko.xz:
 - Uninstallation
   - Deleting from: /lib/modules/6.6.37-desktop-1.mga9/dkms/vhba/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod........

DKMS: uninstall Completed.

------------------------------
Deleting module version: 20211218-2.mga9
completely from the DKMS tree.
------------------------------
Done.

Then install my dkms3 version (sorry for the output in spanish)

urpmi ./RPMS/noarch/dkms-3.0.12-1.WIP.mga9.noarch.rpm 


SEGURIDAD: Los siguientes paquetes _NO_ están firmados (OK ((none))): ./RPMS/noarch/dkms-3.0.12-1.WIP.mga9.noarch.rpm
instalando dkms-3.0.12-1.WIP.mga9.noarch.rpm desde ./RPMS/noarch
Preparando...                    ##################################################################################################
      1/1: dkms                  ##################################################################################################
inactive
      1/2: quitando dkms-2.0.19-46.mga9.noarch
                                 ##################################################################################################
quitando paquete dkms-minimal-2.0.19-46.mga9.noarch
      2/2: quitando dkms-minimal-2.0.19-46.mga9.noarch
                                 ##################################################################################################

And install again dkms-vhba

urpmi  dkms-vhba
Marcando dkms-vhba como instalado a mano, no se marcara como huerfano
writing /var/lib/rpm/installed-through-deps.list


    https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/dkms-vhba-20211218-2.mga9.noarch.rpm
instalando dkms-vhba-20211218-2.mga9.noarch.rpm desde /var/cache/urpmi/rpms                                                         
Preparando...                    ##################################################################################################
      1/1: dkms-vhba             ##################################################################################################
Creating symlink /var/lib/dkms/vhba/20211218-2.mga9/source -> /usr/src/vhba-20211218-2.mga9
The kernel is built without module signing facility, modules won't be signed

Building module:
Cleaning build area...
make -j4 KERNELRELEASE=6.6.37-desktop-1.mga9 KDIR=/lib/modules/6.6.37-desktop-1.mga9/build.....
Cleaning build area...

vhba.ko.xz:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/6.6.37-desktop-1.mga9/dkms//vhba/
depmod.....

As you see, the destination path is the same

Attachment 14434 is obsolete: 0 => 1
Attachment 14354 is obsolete: 0 => 1

I reinstall kernel server from Bug#33373 
As the current dkms options in kernel spec are not compatible with dkms 3 then the module was not built when install the kernel but when reboot and select kernel server

systemctl status dkms.service 
● dkms.service - Builds and install new kernel modules through DKMS
     Loaded: loaded (/usr/lib/systemd/system/dkms.service; enabled; preset: enabled)
     Active: active (exited) since Thu 2024-07-11 19:41:39 CST; 3min 28s ago
       Docs: man:dkms(8)
    Process: 797 ExecStart=/usr/sbin/dkms autoinstall --verbose --kernelver 6.6.37-server-1.mga9 (code=exited, status=0/SUCCESS)
   Main PID: 797 (code=exited, status=0/SUCCESS)
        CPU: 12.230s

jul 11 19:41:02 jgrey.phoenix dkms[2637]: make: se sale del directorio '/usr/src/kernel-6.6.37-server-1.mga9'
jul 11 19:41:02 jgrey.phoenix dkms[1562]: vhba.ko.xz:
jul 11 19:41:02 jgrey.phoenix dkms[1562]: Running module version sanity check.
jul 11 19:41:06 jgrey.phoenix dkms[1562]:  - Original module
jul 11 19:41:06 jgrey.phoenix dkms[1562]:    - No original module exists within this kernel
jul 11 19:41:06 jgrey.phoenix dkms[1562]:  - Installation
jul 11 19:41:06 jgrey.phoenix dkms[1562]:    - Installing to /lib/modules/6.6.37-server-1.mga9/dkms//vhba/
jul 11 19:41:06 jgrey.phoenix dkms[1562]: do_depmod 6.6.37-server-1.mga9
jul 11 19:41:39 jgrey.phoenix dkms[797]: dkms autoinstall on 6.6.37-server-1.mga9/x86_64 succeeded for vhba
jul 11 19:41:39 jgrey.phoenix systemd[1]: Finished dkms.service.

Other side effect of migrate to this version is if you install new dkms-module the module is only build for the current kernel

If you want to emulate the dkms 2 behavior, I suggest add to each dkms-module spec at end of the %post section

for kernel in $(find /lib/modules/*  -maxdepth 0 -type d|sed -e 's|/lib/modules/||') ; do /usr/libexec/dkms_autoinstaller start $kernel ; done

Giuseppe as the kernel list not works I don't know if you have checked this bug

CC: (none) => ghibomgx

Adding also to all packagers for feedback as we still use dkms 2 branch in cauldron

CC: (none) => pkg-bugs

Created attachment 15240 [details]
spec for version 3.3.0

Updated spec for version 3.3.0 
I drop almost all patches
Some ones look not necessary, other like symvers.patch since the version in mageia 9 make at less one of the dkms modules I try, complain in the build so not even try to rediff

Created attachment 15241 [details]
Detect mageia patch for version 3.3.0

Created attachment 15242 [details]
Override destination for version 3.3.0

For unknown cause the update not remove dkms_autoinstaller.service  dkms-autorebuild.service from current dkms packages

Created attachment 15257 [details]
Updated spec for dkms 3.3.x

I still can't clear the services from the dkms 2 package

Attachment 15240 is obsolete: 0 => 1

Created attachment 15258 [details]
scrip to rebuild dkm modules in post transaction of dkms-foo
 
This perhaps make unnecessary enable the dkms.service in spec
If I not enable this script in the framework.conf 
I can see the build of the dkms-foo module in
 
systemctl status dkms.service
 
When I boot in other kernel != of current kernel
 
And If I enable the script, just see basic information of the service when I
perform the same action
 
For me is good enough, but need additional test not by me to see if lack of
symvers.patch produce some unwanted side effect

I don't understand what you mean with "clearthe services". Were the old patches be rewritten to provide the same features they were adding to mageia; e.g. the "-binary" patches were adding the "--binary" to create the rpm binaries, a feature which wasn't present in default dkms. Such features were used elsewhere. Of course the old patches "as is" were not applying to 3.3.x code.

(In reply to Giuseppe Ghibò from comment #27)
> I don't understand what you mean with "clearthe services". Were the old
> patches be rewritten to provide the same features they were adding to
> mageia; e.g. the "-binary" patches were adding the "--binary" to create the
> rpm binaries, a feature which wasn't present in default dkms. Such features
> were used elsewhere. Of course the old patches "as is" were not applying to
> 3.3.x code.

I still se the services in comment#23
Those services come from the dkms 2 package

(In reply to Giuseppe Ghibò from comment #27)
> I don't understand what you mean with "clearthe services". Were the old
> patches be rewritten to provide the same features they were adding to
> mageia; e.g. the "-binary" patches were adding the "--binary" to create the
> rpm binaries, a feature which wasn't present in default dkms. Such features
> were used elsewhere. Of course the old patches "as is" were not applying to
> 3.3.x code.

you can add what you consider needed
I let in this point, fedora don't add
patches of any type

we should stop to use features deprecated upstream

(In reply to katnatek from comment #29)
> (In reply to Giuseppe Ghibò from comment #27)
> > I don't understand what you mean with "clearthe services". Were the old
> > patches be rewritten to provide the same features they were adding to
> > mageia; e.g. the "-binary" patches were adding the "--binary" to create the
> > rpm binaries, a feature which wasn't present in default dkms. Such features
> > were used elsewhere. Of course the old patches "as is" were not applying to
> > 3.3.x code.
> 
> you can add what you consider needed
> I let in this point, fedora don't add
> patches of any type

the problem is the breakage we could have in other tools or package building.

> 
> we should stop to use features deprecated upstream

Or getting the patches merged upstream. On the other hand upstream already includes special checks for ubuntu, debian, arch, gentoo, etc.

Exist

--binaries-only
              This option can be used in conjunction with mktarball in order to create a DKMS tarball which does not  contain  the
              source for the module within it. This can be helpful in reducing the size of the tarball if you know that the system
              which this tarball will be loaded upon already has the source installed. In order to load a tarball  made  as  bina‐
              ries-only you must have the module source in that systems DKMS tree. If you do not, DKMS will refuse to load a bina‐
              ries-only tarball.

I drop some oatches that still were in https://svnweb.mageia.org/packages/cauldron/dkms/branches/WIP/current/
since the 3.0.x version as I don't really understand where to include, the code has changed a lot since our current dkms

I also got stuck on one of the same patches before...

I think it's not easy. An approach could be to avoid trying to apply the older patch to the newer code (which has changed too much). Instead writing a new patch from scratch to provide the same "missed features" in the newer code in another way.

Pascal, do you have any further clues?

OK websearching I find why the old services are still listed

systemctl list-dependencies dkms-autorebuild.service --all --reverse
dkms-autorebuild.service
● └─basic.target
○   ├─initrd.target
●   └─multi-user.target
●     └─graphical.target

systemctl list-dependencies dkms_autoinstaller.service --all --reverse
dkms_autoinstaller.service
● └─basic.target
○   ├─initrd.target
●   └─multi-user.target
●     └─graphical.target

grep -R dkms-autorebuild.service /etc/systemd/system/*
/etc/systemd/system/basic.target.wants/mandriva-everytime.service:After=local-fs.target dkms-autorebuild.service

grep -R dkms_autoinstaller.service /etc/systemd/system/*
/etc/systemd/system/basic.target.wants/dkms-autorebuild.service:Alias=dkms_autoinstaller.service
/etc/systemd/system/dkms_autoinstaller.service:Alias=dkms_autoinstaller.service

So I guess we need to edit mandriva-everytime.service in addition to work 
I'm doing to clean legacy services

(In reply to Stig-Ørjan Smelror from comment #0)
> Our dkms is quite old and since it contains a lot of patches it needs a lot
> of love before we can update it.

(In reply to Giuseppe Ghibò from comment #32)
> An approach could be to avoid trying to apply the
> older patch to the newer code (which has changed too much). Instead writing
> a new patch from scratch to provide the same "missed features" in the newer
> code in another way.

This really do seem like a big undertaking!
I dont think we should change so close to release.
(and better now focus on bugs, kernel 6.18, drivers...)

We apparently really need nee new dkms though....

Is our version good enough to last throughout Mageia 10?

Can it be updated during Mageia 10 lifetime?
- Like implemented in Cauldron this summer, and then backported for experienced users to gain enough mileage before put in updates?
Will related packages be compatible to both versions during a transition time?

CC: (none) => fri
Target Milestone: Mageia 10 => Mageia 11
Priority: Normal => High

Created attachment 15275 [details]
dkms 3.3.x spec with service cleanup & restored dkms.depmod.conf

The cleanup of old services depend on the update of mandriva-everytime.service as I say before

(In reply to Morgan Leijström from comment #34)
> (In reply to Stig-Ørjan Smelror from comment #0)
> > Our dkms is quite old and since it contains a lot of patches it needs a lot
> > of love before we can update it.
> 
> (In reply to Giuseppe Ghibò from comment #32)
> > An approach could be to avoid trying to apply the
> > older patch to the newer code (which has changed too much). Instead writing
> > a new patch from scratch to provide the same "missed features" in the newer
> > code in another way.
> 
> This really do seem like a big undertaking!
> I dont think we should change so close to release.
> (and better now focus on bugs, kernel 6.18, drivers...)
> 
> We apparently really need nee new dkms though....
> 
> Is our version good enough to last throughout Mageia 10?
> 
> Can it be updated during Mageia 10 lifetime?
> - Like implemented in Cauldron this summer, and then backported for
> experienced users to gain enough mileage before put in updates?
> Will related packages be compatible to both versions during a transition
> time?

I just can talk about the test I did perform in mageia 9

1. The dkms module is installed in same path that in current dkms. tested with 2 dkms modules that install in different paths in current dkms
1.1  You can install a dkms module in one version and uninstall in the other without issue.
2. The postin script added in new version saves boot time when you switch between kernels as the module is not build at boot time, perhaps could be intriduced in current dkms but I not sure.
3. We lost the messages in plymouth in dkms 3 version, I think this is due the dkms.service start first so I not see advantage in disable the build of module for all kernels in the postin script or change the script to just run dracut

The problems of compatibility of comment#32 are due to the use of features not native/never integrated in upstream

I not have clear what they do, so can't work on reintegrate, the current dkms works well and as long as I know we not have security issues due to use of legacy version.