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.
>
> # 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 IDFUNCTION:NAME
> 10 8968umount2: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
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
