Bug 1703715 - kmodtool expects existence of System.map-$(uname -r) in /boot/ directory
Summary: kmodtool expects existence of System.map-$(uname -r) in /boot/ directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kmodtool
Version: 29
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-27 20:49 UTC by Marcel Metz
Modified: 2019-05-25 01:05 UTC (History)
7 users (show)

Fixed In Version: kmodtool-1-34.fc30
Clone Of:
Environment:
Last Closed: 2019-05-25 01:05:00 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Check if System.map file exists and set system_map_file_option for depmod accordingly (RHBZ#1703715). (3.01 KB, patch)
2019-04-29 10:12 UTC, nicolas.vieville
no flags Details | Diff
Check if System.map file exists and set system_map_file_option for depmod accordingly (RHBZ#1703715). (3.05 KB, application/mbox)
2019-04-30 18:25 UTC, nicolas.vieville
no flags Details

Description Marcel Metz 2019-04-27 20:49:19 UTC
Description of problem:

When installing the VirtualBox kernel modules via `akmods` those modules could not be loaded via `insmod` or `systemctl restart systemd-modules-load.service`, reporting the modules as missing.

It seems like the `kmod-VirtualBox-*.rpm` generated by `akmods` contains the following post{,un}install lines:

```
postinstall scriptlet (using /bin/sh):
/usr/sbin/depmod -aeF /boot/System.map-5.0.9-200.fc29.x86_64 5.0.9-200.fc29.x86_64 > /dev/null || :
postuninstall scriptlet (using /bin/sh):
/usr/sbin/depmod -aeF /boot/System.map-5.0.9-200.fc29.x86_64 5.0.9-200.fc29.x86_64 &> /dev/null || :
```

However the referenced System.map files don't exist on my system, causing the installation to fail and subsequently to the incomplete installation of the VirtualBox kernel modules.

My current setup uses UEFI and systemd's `bootctl` tool to boot up the system, `grub2` is not installed at all.  This causes `grubby` to not install the System.map from the regular kernel installation directory into boot.

`kmodtool` expects the mentioned System.map to exist within /boot, which probably also conflicts with the future use of the boot loader specification suggested by https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault


Version-Release number of selected component (if applicable):

* kmodtool-1-33.fc29.noarch.rpm
* grubby-8.40-18.fc29.x86_64.rpm
* akmods-0.5.6-19.fc29.noarch.rpm

Additional info:

By editing the `/usr/bin/kmodtool` and changing the pathes to the System.map from `/boot` to `/lib/modules/` the issue is fixed for me. I can provide a patch if needed, however I don't have the required insight into the whole kernel install mechanism on all platforms and would appreciate some opinion from someone more knowledgeable.

Comment 1 nicolas.vieville 2019-04-29 10:12:51 UTC
Created attachment 1559848 [details]
Check if System.map file exists and set system_map_file_option for depmod accordingly (RHBZ#1703715).

Hello,

Thanks for reporting this issue.

Here is a proposed patch to address this problem. It has to be applied to the kmodtool shell script.

Hope this will fix your issue.

Feedback is welcome.

Cordially,


-- 
NVieville

Comment 2 Marcel Metz 2019-04-29 21:25:30 UTC
Hello Nicolas,

thank you very much for the patch.  After applying it cleanly on top of an installation of
`kmodtool-1-33.fc29.noarch.rpm` and making sure that neither any `kmod-*`
package is installed nor that there are stale rpm files within the  `/var/cache/akmods` directory,
`akmods` now creates rpm files with the proper post{,un}install scripts for my setup.

So the patch works for me without issues.

regards,

Marcel

Comment 3 nicolas.vieville 2019-04-30 18:25:56 UTC
Created attachment 1560442 [details]
Check if System.map file exists and set system_map_file_option for depmod accordingly (RHBZ#1703715).

Hello Marcel,

Thank you for testing this patch and your feedback.

Here is, as an attachment, the patch I submitted as a pull request (in order to review it). It does the same as the previous one but uses a RPM macro expanded at install time of the kmod-foo package instead of build time.

I wonder if you could please give it a try, and provide feedback. That's not a problem if you don't have time for it.

Cordially,


-- 
NVieville

Comment 4 Nicolas Chauvet (kwizart) 2019-05-14 15:26:51 UTC
I still don't get why yet another crazy echoed macro... /:


Why it's not such a dead simple solution ?!?
---
 %post          -n kmod-${kmodname}
if [ -f /boot/System.map-${kernel_uname_r} ] ; then
 %{?_prefix_usr}/sbin/depmod -aeF /boot/System.map-${kernel_uname_r} ${kernel_uname_r} > /dev/null
elif [ -f /lib/modules/${kernel_uname_r}/System.map ] ; then
 %{?_prefix_usr}/sbin/depmod -aeF /lib/modules/${kernel_uname_r}/System.map ${kernel_uname_r} > /dev/null
else 
 %{?_prefix_usr}/sbin/depmod -a
fi || :
---
etc

Comment 5 nicolas.vieville 2019-05-14 17:09:31 UTC
Hello Nicolas,

(In reply to Nicolas Chauvet (kwizart) from comment #4)
> I still don't get why yet another crazy echoed macro... /:

Because this has to be done in %post and %postun sections, and I thought
it was better to be short rather than get the risk of repeating two
identical pieces of code with the well-known problems of copying/pasting,
or the long term later modifications.

There seems I was wrong!

> Why it's not such a dead simple solution ?!?
> ---
>  %post          -n kmod-${kmodname}
> if [ -f /boot/System.map-${kernel_uname_r} ] ; then
>  %{?_prefix_usr}/sbin/depmod -aeF /boot/System.map-${kernel_uname_r}
> ${kernel_uname_r} > /dev/null
> elif [ -f /lib/modules/${kernel_uname_r}/System.map ] ; then
>  %{?_prefix_usr}/sbin/depmod -aeF /lib/modules/${kernel_uname_r}/System.map
> ${kernel_uname_r} > /dev/null
> else 
>  %{?_prefix_usr}/sbin/depmod -a
> fi || :
> ---
> etc

If you think this is the way for both sections (post and postun), so let's 
go.

Cordially,


-- 
NVieville

Comment 6 Fedora Update System 2019-05-16 18:35:17 UTC
kmodtool-1-34.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a96c293fab

Comment 7 Fedora Update System 2019-05-17 15:38:05 UTC
kmodtool-1-34.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a96c293fab

Comment 8 Fedora Update System 2019-05-25 01:05:00 UTC
kmodtool-1-34.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.