Bug#548841: module-init-tools: Modprobe -q should always return 0.
On 2009-09-30 16:49, Alan Jenkins <sourcejedi.lkml@googlemail.com> wrote:
> On 9/29/09, Alan Jenkins <sourcejedi.lkml@googlemail.com> wrote:
> >> When calling modprobe -q with a non-existing module, it returns with
> >> exit code 1. According to the manpage, modprobe "normally" will report
> >> an error, and with -q shouldn't, so I believe the exist code should
> >> always be 0, at least that seems to be the assumption in some init
> >> scripts (e.g. binfmt-support).
> >
> > That part is ambiguous, but I guess "modprobe will simply ignore any
> > bogus names" is pretty clear.
> >
>
> > ... and comments in the git log imply we _used_ to get this right.
> >
> > ""
> >
> > Andreas, at first glance this regression is due to your commit
> >
73bdf4ab. Care to submit a patch to revert the relevant lines?
>
> Sorry, I completely misread both the git log comments and Andreas'
> code. This isn't a regression, it's more of a feature request.
>
> The manpage does say modprobe -q "will simply ignore any bogus names",
> implying that modprobe should return success in this case. But
> test-modprobe/19quiet.sh has always required "modprobe -q crap" to
> return failure.
>
> So this is intentional at some level, we've always done it this way in
> the past, and we need to consider the risk of breaking scripts which
> expect the current behaviour.
>
> The binfmt-support initscript seems a bad example to me. It does this
>
> # comments added by me
>
> set -e # abort if any command fails
> ...
> modprobe -q binfmt_misc # this will cause an abort if
> binfmt_misc.ko doesn't exist...
> mount -t binfmt_misc ... # but so will this
>
> It's only a problem if binfmt_misc is built into the kernel. However,
> this will be solved by the modules.builtin work.
>
> So I think we would need a better justification to change this.
Ok, but then the manpage should be fixed. How about the attached
patch?
Philipp
--
Philipp Weis
Signed-off-by: Jon Masters <jcm@jonmasters.org>