Confirmed in an F31 VM with:

# dnf update --nogpg kernel-0:5.7.0-0.rc2.20200422git18bf34080c4c.1.fc33.x86_64 --releasever=33

Top shows CPU usage by depmod approaching 100% at times:

$ top -bc -n 1 -u root | head -9
top - 10:31:33 up 28 min,  1 user,  load average: 1.20, 1.11, 0.99
Tasks: 186 total,   2 running, 184 sleeping,   0 stopped,   0 zombie
%Cpu(s): 94.1 us,  5.9 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3928.0 total,   2000.5 free,    734.9 used,   1192.6 buff/cache
MiB Swap:    512.0 total,    512.0 free,      0.0 used.   2942.6 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  38906 root      20   0   41960  39528   4220 R  81.2   1.0   0:03.82 /sbin/depmod -C /tmp/weak-modules.Os10HS/depmod.conf +
      1 root      20   0  172764  16432   9752 S   0.0   0.4   0:02.78 /usr/lib/systemd/systemd --switched-root --system --d+

$ rpm -qf /usr/sbin/depmod
kmod-26-4.fc31.x86_64

Opened against kmod:

Bug 1828455 - depmod running for a long time when installing F33 kernel

This problem could have something to do with the ARK project:

kernel-ark
https://gitlab.com/cki-project/kernel-ark

(In reply to H.J. Lu from comment #0)
> kernel-core-5.7.0-0.rc1.20200416git9786cab67457.1 took very long time,
> > 20 minutes, to install.  Most of time was spent in /usr/sbin/weak-modules:
> 
> posttrans scriptlet (using /bin/sh):
> if [ -x /usr/sbin/weak-modules ]
> then
>     /usr/sbin/weak-modules --add-kernel
> 5.7.0-0.rc1.20200416git9786cab67457.1.1.cet.fc31.x86_64 || exit $?
> fi
> /bin/kernel-install add
> 5.7.0-0.rc1.20200416git9786cab67457.1.1.cet.fc31.x86_64
> /lib/modules/5.7.0-0.rc1.20200416git9786cab67457.1.1.cet.fc31.x86_64/vmlinuz
> || exit $?

This is due to old kernels installing kernel-modules-extra into the wrong directory. Current kernels now install them into kernel/ rather than the confusingly-named extra/ directory, but old kernels dropped them in extra/. A work-around would be to uninstall old versions of the kernel-modules-extra package.

(In reply to Jeremy Cline from comment #3)
...
> This is due to old kernels installing kernel-modules-extra into the wrong
> directory. Current kernels now install them into kernel/ rather than the
> confusingly-named extra/ directory, but old kernels dropped them in extra/.
> A work-around would be to uninstall old versions of the kernel-modules-extra
> package.

That doesn't explain why depmod is spawning a process storm, instead of failing with an error.

See Bug 1828455, Comment 3, for a summary of strace results captured after only a few seconds. depmod is obviously failing to detect invalid input.

Validating your input is an elementary principle of software engineering.

(In reply to Jeremy Cline from comment #3)
...
> This is due to old kernels installing kernel-modules-extra into the wrong
> directory. Current kernels now install them into kernel/ rather than the
> confusingly-named extra/ directory, but old kernels dropped them in extra/.
> A work-around would be to uninstall old versions of the kernel-modules-extra package.

I am still seeing this depmod process storm with:

kernel-5.7.0-0.rc3.20200429git1d2cc5ac6f66.1.fc33 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-297b9b9340

I would like to refer a bug reporter* who is on F31 to a rawhide kernel for testing, but cannot do that if the install is going to cause him problems.

Please clarify the status of the current rawhide builds and suggest a workaround that doesn't require a complicated procedure.

* Bug 1817368 - Random hangs with sof-audio-pci

(In reply to Steve from comment #5)
> ... and suggest a workaround that doesn't require a complicated procedure.

Here is a simple workaround:

$ cd /usr/sbin
# mv -i weak-modules weak-modules.DISABLE

The installed kernel boots fine:

$ uname -r
5.7.0-0.rc3.20200429git1d2cc5ac6f66.1.fc33.x86_64

BTW, weak-modules is a 1200-line bash script. weak-modules should be rewritten in Python or C.

Even better would be to remove weak-modules from the install process entirely.

==
$ wc -l /usr/sbin/weak-modules.DISABLE 
1199 /usr/sbin/weak-modules.DISABLE

(In reply to Steve from comment #6)
> Even better would be to remove weak-modules from the install process entirely.

Or, at least, make it optional. The kernel scripts are half-way there:

$ rpm -q --scripts -p kernel-core-5.7.0-0.rc3.20200429git1d2cc5ac6f66.1.fc33.x86_64.rpm | grep -m1 weak-modules
if [ -x /usr/sbin/weak-modules ]

A second test on a config variable would stop weak-modules from running for people who don't want it.

(In reply to Steve from comment #7)
> Or, at least, make it optional.

If weak-modules is truly optional, it should go into a sub-package: kmod-weak-modules.