Bugzilla – Bug 1220303
KMP installation fails to make device node
Last modified: 2024-03-18 10:00:43 UTC
After installing a KMP such as vhba-kmp-default.rpm, no device node /dev/vhba_ctl shows up until the system is rebooted. As such, the device cannot be opened without loading the module manually (and thus triggering an udev event to produce the device node belatedly). == Observed behavior == # zypper in vhba-kmp-default Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: vhba-kmp-default 1 new package to install. Overall download size: 27.1 KiB. Already cached: 0 B. After the operation, additional 57.7 KiB will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving: vhba-kmp-default-20240202_k6.7.5_1-1.2.x86_64 (base) (1/1), 27.1 KiB Retrieving: vhba-kmp-default-20240202_k6.7.5_1-1.2.x86_64.rpm ............[done] Verifying ................................................................[done] Preparing ................................................................[done] (0/1) Executing prein script for: vhba-kmp-default-20240202_k6.7.5_1-1.2.x[done] (1/1) Installing: vhba-kmp-default-20240202_k6.7.5_1-1.2.x86_64 ..........[done] (1/1) Executing postin script for: vhba-kmp-default-20240202_k6.7.5_1-1.2.[done] (1/1) Executing posttrans script for: vhba-kmp-default-20240202_k6.7.5_1-1[done] # ls -l /dev/vhb* ls: cannot access '/dev/vhb*': No such file or directory == Expected behavior == Create the device node right away. # ls -l /dev/vhb* crw------- 1 root root 10, 170 Feb 25 14:31 /dev/vhba_ctl == Possible implementation == Adjust the KMP %post scriptlet so that it executes: systemctl restart kmod-static-nodes.service systemd-tmpfiles-setup-dev.service
Why do you expect that after installing the package, the module is automatically loaded?
>Why do you expect that after installing the package, the module is automatically loaded? That is *not* what I wrote in the "Expected behavior" section.
Sorry, I was confused by your remark "the device cannot be opened without loading the module manually".
I created https://github.com/openSUSE/suse-module-tools/pull/100, please take a look. I tested it with vhba-kmp successfully. But there's a catch: This works for KMP installation (should also work for "inkmp", not tested), but when KMPs are removed, the previously created static device nodes remain in place, which isn't optimal. This is because "kmod static nodes --format=tmpfiles" creates entries like this: c! /dev/vhba_ctl 0600 - - - 10:170 but it never creates "remove" entries for already existing static nodes that aren't listed in modules.devname any more. I suppose doing so might actually be dangerous. I don't think that there is a safe way to remove such nodes on KMP removal. Note also that according to tmpfiles.d(5), the exclamation mark means "this line is only safe to execute during boot, and can break a running system". kmod always adds this "!", which may seem over-cautious, but is in line with tmpfiles.d(5), which recommends doing this for static device nodes. If we add this functionality, we will be deliberately ignoring these recommendations.
>I don't think that there is a safe way to remove such nodes on KMP removal. The kernel module stays loaded even if you remove the KMP; therefore the node should stay too. Moreover, some kernel modules may not be rmmodable right now due to being in use. >tmpfiles.d(5), which recommends doing [the exclamation thing] for static device nodes I can't find a direct wording in tmpfiles.d(5) for c! specifically (just r! and ! in general). kmod commit 27eceb2e4ecbf2e31940b67cee682a6935f61e6c has some helpful remarks: >creating static nodes later on will likely not >behave as expected. In particular, recreating >the static nodes at run-time will reset any >permissions udev may have applied to the nodes >at boot. However, this problem is caused by kmod's own code: ret = fprintf(out, "%c! /dev/%s 0600 - - - %u:%u\n", It kmod had specified "-" rather than "0600", there would be no mode change of an existing device node. On the other hand, a "-" causes systemd-tmpfiles to perform the initial creation with 0644. Why can't we have nice things 🙄
(In reply to Jan Engelhardt from comment #5) > >I don't think that there is a safe way to remove such nodes on KMP removal. > > The kernel module stays loaded even if you remove the KMP; therefore the > node should stay too. Moreover, some kernel modules may not be rmmodable > right now due to being in use. Right. But the device node stays in place even if the module had never been loaded. > I can't find a direct wording in tmpfiles.d(5) for c! specifically (just r! > and ! in general). "c, c+ [...] It is recommended to suffix this entry with an exclamation mark to only create static device nodes at boot, as udev will not manage static device nodes that are created at runtime." It comes down to basically the same thing as your quote below. > kmod commit 27eceb2e4ecbf2e31940b67cee682a6935f61e6c has > some helpful remarks: > > >creating static nodes later on will likely not > >behave as expected. In particular, recreating > >the static nodes at run-time will reset any > >permissions udev may have applied to the nodes > >at boot. I suppose that we won't do much harm by creating new static nodes when KMPs are added. Unfortunately "systemctl restart kmod-static-nodes.service systemd-tmpfiles-setup-dev.service" will also re-create all previously existing nodes, which may actually be harmful. Michal, what's your take on this?
Sorry, not much idea about static device nodes. In fact I am surprised they are still used, as far as I know newly added driver create device nodes dynamically.
The purpose is other way round, those static nodes are rather to do auto-loading the module, but yeah, they are mostly legacy infrastructure.
Static nodes exist so that opening the device autoloads the module; this is needed for modules which are not autoloaded by hardware discovery events (mostly because said modules are not tied to any real hardware).
I don't think we can follow the approach in https://github.com/openSUSE/suse-module-tools/pull/100 (which is basically what Jan proposed in commment 0). What we can try at KMP install time is to check the output of "kmod static-nodes" for new entries, and create them without touching existing ones. I see this as a feature request though. I don't think I'll have time to work on this soon.
I'll have to close this as WONTFIX per comment 10. @Jan: if you percieve of a clean solution, "patches welcome" ;-)