On various virtual servers there is _no_ need for module-init-tools at all. If the dependency is there for the modules init tools, why is it not moved into module-init-tools itself?
openrc executes module-init-tools progs in multiple places your question makes no sense as worded
Can we reduce that so that it doesn't have to use it explicitly, or "soft-fail" if it's not installed? You might very well have systems where module-init-tools wouldn't work (vserver for instance).
Created attachment 251759 [details, diff] Patch for the problem This patch protects all the modprobe calls in openrc with a type-check… this allows to run openrc fine without having module-init-tools installed. Does this suffice? My next move would be to move (sorry for the pun) the modules init script from openrc to module-init-tools that provide the tools it uses, anything seems wrong about that?
ugh, no. if you want to go that route, it'd make sense to have a wrapper func in one place. although i'd be inclined to tell you to just do it yourself: ln -s `which true` /sbin/modprobe
I was just mimicking the kldload handling in init.misc.d. If you want an easier solution what about testing for ! modprobe >/dev/null 2>&1 and let it fail silently if modprobe is not installed?
Created attachment 251773 [details, diff] Alternative approach This one simplifies the code from before as well. If a /proc or /sys path does not exist and module fails to load assume error; this also means that if modprobe succeed, assume success, which was the case for a few checks previously as well.
i'm not interested in hiding modprobe output either. i already spent time in making sure that invocation of it would not output anything in the default case. hiding valid errors to cater to a tiny number of people who dont have modprobe installed isnt going to happen.
What about not-so-tiny number of people who _don't use modules_? Can you provide an alternative? Would a _modprobe() function wrapper work for you? Remember that Gentoo doesn't have to be the way you want it, there are more use cases, and one of this (which is not so rare) is monolithic kernels. There are people for which having module-init-tools is just a waste of space/time/build; we force it already enough with the profile, you don't want to test for it everywhere, you don't want to hide output, tell me what you want, so I can make it, but I don't want module-init-tools forced in on LXC/xen/monolithic installs.
try reading the source. modprobe doesnt care if module support doesnt exist in the kernel. plus, the kernel always populates /sys/kernel/modules/ which is largely what the tools parse.
Does it make sense to add -xenu to the keyword line in the depend function in the modules init script so that the script will not run for xenu installs to begin with (I'm taking this idea from -lxc already being there)?
Not really. You _can_ run a domU-kernel with modules (albeit it makes little sense IMHO); you _cannot_ use different kernels with lxc guests.
vapier: The point I see remaining here is that OpenRC should work without the module-init-tools package installed. Instead of hiding the modprobe output, I think it just shouldn't be called if not present. We don't depend on it anywhere per-se, we just try the modprobe calls in case the user has a modular system. Alternatively, we introduce a variable like RC_NEVER_MODPROBE or something.
openrc does work fine if m-i-t isnt installed. Diego is merely concerned with the harmless warnings at boot time along the lines of "modprobe: command not found". if you really want to waste time on this, then make a wrapper function like "rc_modprobe". openrc isnt the only init.d package that attempts to modprobe. rc_modprobe() { type modprobe >/dev/null 2>&1 || return 1 modprobe -q "$@" }
Comment on attachment 251773 [details, diff] Alternative approach most of the changes in here actually break the initial sanity checks
Now openrc should depend on virtual/modutils, please fix this.
(In reply to comment #15) no, it shouldn't. please read the bug rather than drive by spamming.
@flameeyes: I haven't forgotten about this bug. The fix I'm thinking of won't happen in 0.14, but I'm seriously considering going a completely different direction in 0.15. I'm considering moving the modules service to the sysinit runlevel and making it the very first service we run when we boot. If I can do that, I believe I can remove all other modprobe calls from OpenRC. Thoughts?
*** Bug 582830 has been marked as a duplicate of this bug. ***
I am going to take a look at this again. My current idea is still the same, putting modules in sysinit and making it the very first service to run.
Since we have the want dependency now, I'm thinking I can modify the services that use modprobe directly to have "want modules" in their dependencies and also move toward deprecating the use of modprobe in the services by warning that the modules they load should be configured in /etc/conf.d/modules or built in.
http://github.com/openrc/openrc/commit/73cdf10 This will be included in openrc-0.22. The idea here is to start warning the admin to reconfigure their kernel or set up /etc/conf.d/modules to include the appropriate modules. The next step will be to drop the modprobe calls in 1.0.
