Bug#345101: [Pkg-alsa-devel] alsa-tools

Michael Prokop mika at grml.org
Fri Dec 30 17:05:51 UTC 2005


* Thomas Hood <jdthood at yahoo.co.uk> [20051230 16:51]:
> Michael Prokop wrote:
> > * Thomas Hood <jdthood at yahoo.co.uk> [20051230 15:15]:

[...]

> But this shouldn't be relevant because (as init(8) says):

>  ENVIRONMENT
>        Init sets the following environment variables for all its children:

>        PATH   /bin:/usr/bin:/sbin:/usr/sbin

Yes, this seems to apply for Debian sarge. But this does not seem to
apply for Debian unstable (or even Ubuntu as someone reported to me
when asking for checking):

root at grml ~ # grep PATH /proc/1/environ
root at grml ~ #

Even though:

mika at grml ~ % strings /sbin/init | grep PATH
PATH=/bin:/usr/bin:/sbin:/usr/sbin
mika at grml ~ % dpkg --list sysvinit
[...]
ii  sysvinit                        2.86.ds1-1                      System-V like init

mika at grml ~ # strings /sbin/init | grep PATH
PATH=/bin:/usr/bin:/sbin:/usr/sbin
PATH
mika at grml ~ % dpkg --list sysvinit
[...]
ii  sysvinit                        2.86.ds1-4                      System-V like init

(Last output applies to sysvinit 2.86.ds1-6 as well.)

and:

,---- [ http://packages.debian.org/changelogs/pool/main/s/sysvinit/sysvinit_2.86.ds1-8/changelog.html ]
| sysvinit  (2.86-1) unstable; urgency=medium
|  [...]
| * Always initialize PATH (to /bin:/usr/bin:/sbin:/usr/sbin) (closes: #258065)
`----

Checked on two Debian sarge, four Debian unstable (2 plain Debian
unstable, 2 grml boxes [grml.org]) and on one Ubuntu Breezy system.

> You need to figure out why the zsh instance started by modprobe on your
> system isn't searching /sbin for the modprobe command.

Well, running modprobe from my zsh instance works of course:

> Please do this for starters:

>     echo 'install envtest env > /tmp/modprobe-env-dump' > /etc/modprobe.d/envtest
>     modprobe envtest
>     grep PATH tmp/modprobe-env-dump

Gives me:

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/usr/NX/bin

The problem exists for example with current udev versions with
udevsynthesize (more precise: /lib/udev/udevsynthesize) if init does
not set $PATH.

So running /lib/udev/udevsynthesize with above modprobe.d-entry does
not provide a $PATH entry in /tmp/modprobe-env-dump. JFTR: There
also does not exist a $PATH entry if I switch /bin/sh to /bin/bash.

> >> (Or modprobe isn't passing PATH, but my testing indicates that
> >> this is not the problem.)

> > Where does modprobe set $PATH? (Sorry, I could not find anything.
> > I'm still investing on the problem, if it's really a zsh problem
> > I'll contact zsh-upstream of course.)

> Last time I checked, modprobe did not set PATH, but did pass on PATH from
> its environment to the enviroment of the commands its executes.

It's not a problem to run modprobe manually.

It's a problem to use /etc/init.d/udev in the bootup process
(resulting in 'snd_...: Unknown symbol snd_...' because of failed
modprobe calls) with current Linux kernel on Debian unstable when
/bin/sh isn't /bin/bash but /bin/zsh.

> That's why the current /etc/modprobe.d/alsa-base works for many,
> many people.

That's just because many, many people use /bin/bash as /bin/sh. ;-)

regards,
-mika-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/attachments/20051230/095a8f1d/attachment.pgp


More information about the Pkg-alsa-devel mailing list