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@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. -- -Gary Mills- -refurb- -Winnipeg, Manitoba, Canada- _______________________________________________ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev