[oi-dev] OI no longer automounts USB sticks

[Stephan Althaus]

On 6/26/21 3:52 AM, Gary Mills wrote:
> On Fri, Jun 25, 2021 at 12:24:52PM -0700, Joshua M. Clulow via oi-dev wrote:
>> It seems like it would be good to figure out, on the systems that _do_
>> work, what exactly is performing the mount.  Then we can work
>> backwards to why that is no longer happening.
> Good idea.  I have a system running an older BE where the automount
> does work.  I did exactly what you suggested.
>
>> I would probably do something like...
>>
>>
>>     $ pfexec dtrace -w -n '
>>         syscall::*mount*:entry {
>>             raise(SIGSTOP);
>>             system("pargs %d; ptree %d; prun %d", pid, pid, pid);
>>         }'
> Here's the result.  Probably because I ran it as root, the result was
> a bit different from usual, but the mount did succeed.
>
>     <root at ryzen># dtrace -w -n '
>     > syscall::*mount*:entry {
>     > raise(SIGSTOP);
>     > system("pargs %d; ptree %d; prun %d", pid, pid, pid);
>     > }'
>     dtrace: description '
>     syscall::*mount*:entry ' matched 2 probes
>     dtrace: allowing destructive actions
>     CPU     ID                    FUNCTION:NAME
>      10   8968                    umount2:entry 3951:       /usr/lib/hal/hald-addon-storage
>     argv[0]: /usr/lib/hal/hald-addon-storage
>     1994   /usr/lib/hal/hald --daemon=yes
>       1995   hald-runner
>         3951   /usr/lib/hal/hald-addon-storage
>     
>      11   8532                      mount:entry 3955:       mount -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO
>     argv[0]: pcfs_mount
>     argv[1]: -o
>     argv[2]: nosuid
>     argv[3]: /dev/dsk/c4t0d0p0:1
>     argv[4]: /media/STORE N GO
>     1994   /usr/lib/hal/hald --daemon=yes
>       1995   hald-runner
>         3954   /usr/lib/hal/hal-storage-mount
>           3955   mount -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO
>     
>       2   8532                      mount:entry 3951:       /usr/lib/hal/hald-addon-storage
>     argv[0]: /usr/lib/hal/hald-addon-storage
>     1994   /usr/lib/hal/hald --daemon=yes
>       1995   hald-runner
>         3951   /usr/lib/hal/hald-addon-storage
>     
>     ^?
>
> I pressed the interupt key at that point.
>
>
Hello!

i don't seem to have a be that is old enough, a be from february does
not automount.

i have these processes on my current system (updated May, 19):

   296 ?        S  0:00 /usr/lib/hal/hald --daemon=yes
   297 ?        S  0:00 hald-runner
   362 ?        S  0:00 /usr/lib/hal/hald-addon-network-discovery
   364 ?        S  0:00 /usr/lib/hal/hald-addon-cpufreq
   365 ?        S  0:00 /usr/lib/hal/hald-addon-acpi
  2373 ?        S  0:00 /usr/lib/gvfs-hal-volume-monitor
  2442 pts/1    S  0:00 grep hal

and i get some fmd in the suggested trace, but that could be something
very different and not related to this thread:

dtrace: description '
        syscall::*mount*:entry ' matched 2 probes
dtrace: allowing destructive actions
CPU     ID                    FUNCTION:NAME
  1  19130                    umount2:entry 1182:       /usr/lib/fm/fmd/fmd
argv[0]: /usr/lib/fm/fmd/fmd
1182   /usr/lib/fm/fmd/fmd

  0  18696                      mount:entry 1182:       /usr/lib/fm/fmd/fmd
argv[0]: /usr/lib/fm/fmd/fmd
1182   /usr/lib/fm/fmd/fmd


i have an other oi system with a be from november, but that is
physically away, there i could make a check if it is really needed..

Greetings,

Stephan