[oi-dev] OI no longer automounts USB sticks

Joshua M. Clulow josh at sysmgr.org
Fri Jun 25 19:24:52 UTC 2021


On Fri, 25 Jun 2021 at 11:45, stes at PANDORA.BE <stes at telenet.be> wrote:
> I can reproduce the problem;
>
> When I plugin a USB key on my OI 2021.04 latest update system it does not automount the volume;
>
> cdrecord -scanbus shows the USB key controller.target.disk 5.0.0 so from there it is also possible to deduce
>
> root at wapper:~#  mount -F pcfs /dev/dsk/c5t0d0p1 /mnt
>
> that works
>
> This is USB 2 key in a USB 3.2 port for me
>
> root at wapper:~# modinfo | grep xhci
> 103 fffffffff7cef000   e8f0 251   1  xhci (USB xHCI Driver)
>
> There are also 2 USB 2 ports on my computer but that doesn't help for automount either.
>
> David Stes
>
> ----- Op 25 jun 2021 om 17:30 schreef gary mills gary_mills at fastmail.fm:
>
> > On Sun, Jun 06, 2021 at 09:49:58PM +0200, Andreas Wacknitz wrote:
> >>
> >> service/hal is delivered by illumos-gate
> >
> > Well, hal seemed to be a good lead, but turned out to be another dead
> > end.
> >
> > Curiously, there seem to be many versions of the hal package in OI.
> > The range is enormous.  I wonder why there are so many?  The ones in
> > my recent BEs are service/hal at 0.5.11-2020.0.1.20171 and
> > service/hal at 0.5.11-2020.0.1.20514 .
> >
> > At the moment, I've run out of leads.  All that I know is that a BE
> > dated 2021-05-15 has this problem but a BE dated 2020-11-27 does not
> > have it.
> >
> > Of course, if you don't use USB sticks, and don't disconnect your USB
> > mouse or keyboard, you will never experience the problem.

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.

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);
        }'

    dtrace: description 'syscall::*mount*:entry ' matched 2 probes
    dtrace: allowing destructive actions
    CPU     ID                    FUNCTION:NAME
      3   6941                      mount:entry 3938:       mount blah /a
    argv[0]: tmpfs_mount
    argv[1]: blah
    argv[2]: /a
    977    /usr/lib/ssh/sshd
      3916   /usr/lib/ssh/sshd -R
        3918   /usr/lib/ssh/sshd -R
          3919   -bash
            3938   mount blah /a

And then plug in a device, to see what triggers the mount.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org



More information about the oi-dev mailing list