[Pkg-alsa-devel] /sbin/init patch to set PATH

[Thomas Hood]

OK, I have done some more investigating.

I wrote:
> My guess is that you are booting an initrd generated with another version of mkinitrd
> or with yaird and that this initrd's init program does not set PATH.  Then for some
> reason sysvinit's init fails to set PATH, your version of udev fails to set PATH
> and then zsh handles the absence of PATH differently from how bash handles it.

Clearly there is a series of failures to specify the path of the modutils command.
At least one of these failures has to be regarded as a bug.

1.  I don't know whether or not the initialization process running from the initial
ram disk is supposed to set a PATH before it execs the standard /sbin/init.  I'll
assume not, but someone (who knows more about initrd) please correct me if I'm wrong.

2.  /sbin/init should set a sane PATH if PATH is not already set, even if the process
thinks that it is only being re-executed.  I attach a patch to the sysvinit package
that fixes this bug.  I am on the sysvinit maintenance team so this patch will make
it into the next release unless someone finds something terribly wrong with it.

3. It would be nice if udevd set a sane PATH in case PATH is unset.  Someone please
file a wish against udev about this.  I don't plan to do it.

4. Linking /bin/sh to bash results in modprobe being found, but linking /bin/sh to
zsh results in modprobe not being found.  I am guessing that this is the result of
this Debian customization (in bash-3.1/debian/patches/deb-bash-config.dpatch):


> [...]
> # DP: Changed compile time configuration options:
> # DP:
> # DP: - Set the default path to comply with Debian policy
> [...]
> --- bash-3.1-alpha1/config-top.h        2005-04-29 20:36:34.000000000 +0000
> +++ bash/config-top.h   2005-09-09 19:26:41.923569456 +0000
> @@ -52,14 +52,14 @@
>  /* The default value of the PATH variable. */
>  #ifndef DEFAULT_PATH_VALUE
>  #define DEFAULT_PATH_VALUE \
> -  "/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:."
> +  "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
>  #endif
> 
>  /* The value for PATH when invoking `command -p'.  This is only used when
>     the Posix.2 confstr () function, or CS_PATH define are not present. */
>  #ifndef STANDARD_UTILS_PATH
>  #define STANDARD_UTILS_PATH \
> -  "/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/etc"
> +  "/bin:/usr/bin:/sbin:/usr/sbin"
>  #endif
> [...]

The result:

> jdthood at turmeric:~$ unset PATH
> jdthood at turmeric:~$ /bin/bash --noprofile --norc
> bash-3.00$ echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

I looked in Debian policy and couldn't find anything that would justify changing
the default PATH to include the sbin directories.  Can anyone give me a section
number?  I notice that different search orders are specified for the two paths;
I don't know of any reason for such a difference.

Assuming that there is a reason for this customization, it should be applied
to zsh too.  I'll file a low-severity bug report against zsh raising this issue.

> jdthood at turmeric:~$ unset PATH
> jdthood at turmeric:~$ /bin/zsh --no-rcs --no-globalrcs
> turmeric% echo $PATH
> /bin:/usr/bin:/usr/ucb:/usr/local/bin

5. Modifying /etc/modprobe.d/alsa-base so that modprobe is run with full path is
acceptable as a temporary workaround to save users some trouble until a fixed
sysvinit makes it into testing.  Jordi: I will make the necessary additional
changes to alsa-driver.  Be warned that I would prefer to remove the workaround
when the fixed sysvinit makes it into testing.  :)
-- 
Thomas Hood