Yes, that message used to disturb me but it happens on every update, from way back, so it seems to be harmless.

CC: (none) => tarazed25

Did you get only on nvidia-current or on *ANY* dkms build, e.g. you might try dkms-sysdig, dkms-virtualbox, dkms-bbswitch, etc.

CC: (none) => ghibomgx

dkms-sysdig fails too. Look like it may need the fix from
https://github.com/draios/sysdig/pull/1621/files/6e5805d381399eaa0ab298618f1d2b7d7cc0f4d8

CC: (none) => davidwhodgins

comment 3 applies to Mageia 7 x86_64. The error on cauldron is different. I'll
attach both make log files.

Created attachment 11797 [details]
Mageia 7 make log for sysdig

Created attachment 11798 [details]
Cauldron make log for dkms-sysdig

sysdig is now in Bug 27084.

This bug can be for the general dkms errors.

With the update for sysdig in bug 27084, the make.log shows no errors on either
Mageia 7 or Cauldron, however the dkms update shows ...

Preparing kernel 5.7.14-desktop-1.mga7 for module build:
(This is not compiling a kernel, just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper....(bad exit status: 2)
using /proc/config.gz
make oldconfig....
make prepare....(bad exit status: 2)

Building module:
cleaning build area....
make -j4 KERNELRELEASE=5.7.14-desktop-1.mga7 -C /lib/modules/5.7.14-desktop-1.mga7/build M=/var/lib/dkms/sysdig/0.27.0-1.mga7/build.....
cleaning build area....
cleaning kernel tree (make mrproper)....(bad exit status: 2)

DKMS: build Completed.

sysdig-probe.ko.xz:
 - Installation
   - Installing to /lib/modules/5.7.14-desktop-1.mga7/dkms/extra/

depmod......

DKMS: install Completed.

# modprobe -v sysdig-probe
insmod /lib/modules/5.7.14-desktop-1.mga7/dkms/extra/sysdig-probe.ko.xz
# grep sysdig /proc/modules
sysdig_probe 643072 0 - Live 0xffffffffc1002000 (O)

So the module compiled cleanly and loads ok, despite the exit status 2 for both
make mrproper and make prepare.

Does the dkms make.log shows some compiler warnings? So it seems the bad exit status comes from kernel source itself or dkms.

This is not a problem, which is while their failure is ignored and things continue and succeed.

CC: (none) => pterjan

Also, I don't think we should be calling make mrproper on the kernel source tree from kernel-devel when building things, it could mess things up, so it is good that it fails.

Failure is: 

Makefile:1422: *** insufficient number of arguments (1) to function 'addprefix'.  Stop.


# mrproper - Delete all generated files, including .config
#
mrproper: rm-dirs  := $(wildcard $(MRPROPER_DIRS))
mrproper: rm-files := $(wildcard $(MRPROPER_FILES))
mrproper-dirs      := $(addprefix _mrproper_)

PHONY += $(mrproper-dirs) mrproper

I agree Pascal, but you must agree that for end-user, such error could afraid him.

Is because DKMS not updated to latest version?

This is due to a bug in http://svnweb.mageia.org/packages/cauldron/kernel/current/SOURCES/disable-mrproper-in-devel-rpms.patch?revision=1612811&view=markup

Instead of making it do nothing, it makes it fail

(In reply to Pascal Terjan from comment #13)
> This is due to a bug in
> http://svnweb.mageia.org/packages/cauldron/kernel/current/SOURCES/disable-
> mrproper-in-devel-rpms.patch?revision=1612811&view=markup
> 
> Instead of making it do nothing, it makes it fail

Do you have some hints on how to fix disable-mrproper-in-devel-rpms.patch so that the error fades away? It should have been not aways broken, problably introduced at some point during some major kernel version update, as much time ago I remember was not happening.

The problem is on this line:

-mrproper-dirs      := $(addprefix _mrproper_,scripts)
+mrproper-dirs      := $(addprefix _mrproper_)

I guess the intention is to not make it clean the scripts directory

The easiest is probably to just change the mrproper line to be the same as clean and not touch the rest...

Something like:

-mrproper: clean $(mrproper-dirs)
+mrproper: clean

OK,(In reply to Pascal Terjan from comment #15)
> The problem is on this line:
> 
> -mrproper-dirs      := $(addprefix _mrproper_,scripts)
> +mrproper-dirs      := $(addprefix _mrproper_)
> 
> I guess the intention is to not make it clean the scripts directory
> 
> The easiest is probably to just change the mrproper line to be the same as
> clean and not touch the rest...
> 
> Something like:
> 
> -mrproper: clean $(mrproper-dirs)
> +mrproper: clean

I tried to add this manually to /usr/src/kernel-5.8.7-desktop-1.mga8/Makefile, but got the same error as before, e.g.:

urpmi dkms-virtualbox
.....
cleaning build area....(bad exit status: 2)

DKMS: build completed.

The error is different, in "cleaning build area...." while it used to fail in "make mrproper...." earlier

New error is:

make -f ./scripts/Makefile.build obj=/var/lib/dkms/virtualbox/6.1.14-3.mga8/build/vboxdrv \
single-build= \
need-builtin=1 need-modorder=1
make -f ./scripts/Makefile.modpost
make[2]: *** No rule to make target '/var/lib/dkms/virtualbox/6.1.14-3.mga8/build/vboxdrv/modules.order', needed by '/var/lib/dkms/virtualbox/6.1.14-3.mga8/build/vboxdrv/Module.symvers'.  Stop.

So we hit a 2nd bug...

It seems that mrproper not being broken causes it to mess with files...

The point of having -devel packages is that they are already configured for that specific kernel so it should not do anything anyway, not touching the .config, not running mrproper or prepare or clean...

Looking at dkms code it is running mrproper because of failing to detect it is running on Mageia because there is no rhconfig.h:


   elif grep -q rhconfig.h $kernel_source_dir/include/linux/{modversions,version}.h 2>/dev/null; then
        if [ -e /etc/mageia-release ]; then
            echo $"Running Mageia style preparation routine"
        else
            echo $"Running Red Hat style preparation routine"
        fi
        invoke_command "make clean" "make clean" background
        [ -n "$config_contents" ] && echo "$config_contents" > .config

        if [ -n "$kernel_config" ]; then
            echo $"using $kernel_config"
            if file -b -i "$kernel_config" | grep -q "application/x-gzip"; then
                    zcat "$kernel_config" > .config
            else
                    cp -f "$kernel_config" .config
            fi
        elif [ -e .config ]; then
            echo $"using $kernel_source_dir/.config"
            echo $"(I hope this is the correct config for this kernel)"
        else
            echo $""
            echo $"Warning! Cannot find a .config file to prepare your kernel with." >&2
            echo $"Try using the --config option to specify where one can be found." >&2
            echo $"Your build will likely fail because of this." >&2
        fi

        # Hack to workaround broken tmp_include_depends for Red Hat
        if grep -q "/usr/src/build" $kernel_source_dir/tmp_include_depends 2>/dev/null; then
            sed 's/\/usr\/src\/build\/.*\/install//g' $kernel_source_dir/tmp_include_depends > $kernel_source_dir/tmp_include_depends.new
            mv -f $kernel_source_dir/tmp_include_depends.new $kernel_source_dir/tmp_include_depends
        fi

        invoke_command "make KERNELRELEASE=$1 oldconfig" "make oldconfig" background
        kerneldoth_contents=`cat /boot/kernel.h 2>/dev/null`
        invoke_command "/usr/lib/dkms/mkkerneldoth --kernelver $1 --targetarch $2 --output /boot/kernel.h" "running mkkerneldoth" background
    else
        echo $"Running Generic preparation routine"
        invoke_command "make mrproper" "make mrproper" background
        [ -n "$config_contents" ] && echo "$config_contents" > .config

... but that code wouldn't work either ...

fixed in kernel(-linus) 5.10.8-1 and cleaned up the fallout in 5.10.8-2

Status: NEW => RESOLVED
Resolution: (none) => FIXED