Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 27, 2021 at 01:00:46AM -0700, Joshua M. Clulow wrote: > > OK, so I have looked into this a little bit. It seems like there is a > bug in the HAL code we ship, or in the glib that OI is now using, or > somewhere inbetween. [...] > This seems about right. These writes are into a self-pipe (i.e., both > ends of the pipe are held open within this single hald process) that > is established in the sysevent_init() routine, and stored in the > "sysevent_pipe_fds" global where I was able to confirm with pfiles > that the pipe is still open. > > Where things appear to fall down is once we get into the glib area. > The strings that are written into one end of the pipe by the sysevent > consumer, as described above, are meant to then be read through a glib > GIOChannel object in sysevent_iochannel_data(): [...] > I have run out of steam on this for now, but I hope this is enough for > someone to keep digging. As far as I can tell, nobody has taken up the chase from here. I'd like to do that myself, but I don't know enough dtrace to do it. This does look like a job for dtrace. In particular, I'd like to find out what glib is doing after that function call. There should be a read() system call at the bottom of it all. I'd like to see what's returned from that system call. Pipes on illumos are completely different internally from pipes on Linux, and certainly could behave differently. Self-pipes on illumos are even more likely to misbehave. Would it be possible for you to suggest some dtrace code that will reveal what I need from that glib function? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On 6/30/21 6:46 PM, Gary Mills wrote: On Mon, Jun 28, 2021 at 02:55:21PM -0700, Alan Coopersmith wrote: On 6/28/21 12:52 PM, Gary Mills wrote: I don't know yet if the glib developers have dropped support for solaris or illumos. I've not seen any such moves by them, and have gotten Solaris-specific pull requests accepted in recent years. Okay thanks. I'll drop that idea from my list of known unknowns, and look elsewhere. They don't regularly test on Solaris though, and could easily have missed adding something we need, or broken something on our platforms without realizing it, so those are still possibilities. Breaking something HAL relies on is also a possibility, as outside the world of Solaris/illumos, HAL has been abandoned, deprecated, and removed for almost a decade as noted by the first line on: https://www.freedesktop.org/wiki/Software/hal/ and the last commit dates in: https://gitlab.freedesktop.org/archived-projects/hal/hal/-/commits/master For whatever it's worth, the Solaris patches to HAL are available at: https://gitlab.freedesktop.org/alanc/hal/-/commits/solaris as we've still not replaced it either. -alan- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Mon, Jun 28, 2021 at 02:55:21PM -0700, Alan Coopersmith wrote: > On 6/28/21 12:52 PM, Gary Mills wrote: > > I don't know yet if the glib developers have > > dropped support for solaris or illumos. > > I've not seen any such moves by them, and have gotten Solaris-specific > pull requests accepted in recent years. Okay thanks. I'll drop that idea from my list of known unknowns, and look elsewhere. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
When I initially said that I could reproduce the problem, (I am testing on this completely new 2021.04 system) I didn't check that rmvolmgr was enabled. I should have verified that to begin with ... I can still reproduce the problem that you reported, but for example with an old Olympus camera SmartMedia card reader, it is automounted fine as follows: # svcadm restart hal # svcadm restart rmvolmgr # eject -l /dev/dsk/c4t1d0s2cdrom,cdrom0,cd,cd0,sr,sr0 /dev/dsk/c6t0d0p0:1 rmdisk4,USBSLACK,/media/USBSLACK /dev/dsk/c5t0d1p0:1 rmdisk1,/media/2.0 Reader-SM-xD Of course restarting should not be necessary but this is a workaround. David Stes - Op 28 jun 2021 om 21:52 schreef gary mills gary_mi...@fastmail.fm: > On Mon, Jun 28, 2021 at 06:53:33PM +0200, s...@pandora.be wrote: >> >> It's good that you reported the issue and of course USB automount >> is useful. >> >> Andreas Wacknitz also confirmed this, and is trying to help as much >> as possible. > > I didn't know this. In fact, I generally don't know when somebody > else is working on something. We should be collaborating, rather > than duplicating effort. > > I'm assuming the problem is in glib. I have several snapshots of the > OI source, including the current one of course. I don't know yet if > a patch disappeared. I don't know yet if the glib developers have > dropped support for solaris or illumos. Going through the layers, > I've gotten as far as: > >status = channel->funcs->io_read (channel, channel->read_buf->str + > cur_len, > channel->buf_size, _size, err); > > I'm assuming that OS-specific versions of "io_read" exist in glib, > but I haven't found them yet. > > > -- > -Gary Mills- -refurb--Winnipeg, Manitoba, Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On 6/28/21 12:52 PM, Gary Mills wrote: I don't know yet if the glib developers have dropped support for solaris or illumos. I've not seen any such moves by them, and have gotten Solaris-specific pull requests accepted in recent years. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Mon, Jun 28, 2021 at 06:53:33PM +0200, s...@pandora.be wrote: > > It's good that you reported the issue and of course USB automount > is useful. > > Andreas Wacknitz also confirmed this, and is trying to help as much > as possible. I didn't know this. In fact, I generally don't know when somebody else is working on something. We should be collaborating, rather than duplicating effort. I'm assuming the problem is in glib. I have several snapshots of the OI source, including the current one of course. I don't know yet if a patch disappeared. I don't know yet if the glib developers have dropped support for solaris or illumos. Going through the layers, I've gotten as far as: status = channel->funcs->io_read (channel, channel->read_buf->str + cur_len, channel->buf_size, _size, err); I'm assuming that OS-specific versions of "io_read" exist in glib, but I haven't found them yet. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
Perhaps # svcadm restart hal # svcadm restart rmvolmgr is a temporary workaround but indeed eventually should fix the underlying problem. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
- Op 27 jun 2021 om 15:27 schreef gary mills gary_mi...@fastmail.fm: > I use it periodically to transfer files from my main Unix system to > another system that runs Windows 10. I know there are alternatives to > USB sticks, but they are convenient. USB automount is useful to me. It's good that you reported the issue and of course USB automount is useful. Andreas Wacknitz also confirmed this, and is trying to help as much as possible. Perhaps restarting 'hal' is a workaround. If I insert a USB mouse or USB storage device, and give hal a kick: root@wapper:~# svcadm restart hal then eject -l lists the usb storage root@wapper:~# eject -l /dev/dsk/c4t1d0s2cdrom,cdrom0,cd,cd0,sr,sr0 /dev/dsk/c5t0d0p0:1 rmdisk,rmdisk0,USBSLACK I agree that it shouldn't be necessary to restart hal, but this could be a workaround. I use an old PS/2 keyboard and PS/2 mouse on my system, as the Dell Precision still has PS/2 connectors (in addition to the USB 3.2 ports),so I'm not affected by USB keyboard, but obviously all modern mice and keyboards are USB, and restarting hal maybe helps. Theoretically the SMF dependents are root@wapper:~# svcs -D hal STATE STIMEFMRI disabled 18:19:30 svc:/network/device-discovery/printers:snmp disabled 18:19:31 svc:/system/filesystem/rmvolmgr:default online 18:28:36 svc:/application/graphical-login/lightdm:default root@wapper:~# svcs -d hal STATE STIMEFMRI online 18:19:34 svc:/system/device/local:default online 18:19:35 svc:/system/filesystem/minimal:default online 18:19:37 svc:/system/sysevent:default online 18:19:37 svc:/system/dbus:default online 18:19:44 svc:/system/keymap:default Looking at the above I also note that I wasn't running rmvolmgr for some reason! root@wapper:~# svcadm enable rmvolmgr and voilà: /media/USBSLACK on /dev/dsk/c5t0d0p0:1 read/write/nosetuid/nodevices/hidden/nofoldcase/clamptime/noatime/timezone=-3600/dev=2ec1090 on Mon Jun 28 18:48:24 2021 Pardon my French (I'm Flemish) but automount is working for me ! If I remove the USBSLACK key it is unmounted. If I insert it again, it is not mounted, but root@wapper:~# svcadm restart hal root@wapper:~# svcadm restart rmvolmgr is doing the trick of automount. So this could provide a temporary work-around. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
Stephan Althaus wrote: > Hi! > > i would be happy to test something. > > I would have a use case for the usb automount feature, > and the issue with the mouse/keyboard not changeable in X as it seems, > is related and something i am not happy with. > > Stephan > > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > I'd also like to lend a hand. /tony -- Tony Albers - Systems Architect - Data Department, Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, 27 Jun 2021 at 21:30, Tony Brian Albers wrote: > I was trying to use a KVM switch the other day, and I suppose this issue > is why I had to force a shutdown(power btn) of OI every time I had > switched to another machine and back again. Mouse and keyboard were > unresponsive but powered up. > > Potentially this is a lot worse than automounting of usb devices not > working IMO. At a cursory glance, it appears to be the same problem. I plugged a keyboard in to the machine while doing the same tracing as before, and I see these sysevents: EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1 EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1/keyboard@0 EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1/input@1 I believe, if these were correctly received through the glib GIOChannel, these would end up calling into devinfo_usb_add() which would look at the driver, find that it was "hid", and then call devinfo_usb_input_add() to notify HAL consumers that there are new input devices. If someone fixes the glib channel issue, I would imagine keyboard and mouse hotplug under X11 would also start working again. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On 6/27/21 10:55 AM, Andreas Wacknitz wrote:
> Am 27.06.21 um 10:00 schrieb Joshua M. Clulow via oi-dev:
>> On Fri, 25 Jun 2021 at 18:52, 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.
>>> # 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
>> Thanks for that!
>>
>> OK, so I have looked into this a little bit. It seems like there is a
>> bug in the HAL code we ship, or in the glib that OI is now using, or
>> somewhere inbetween.
>>
>> With DTrace, I am able to see (in the "hald --daemon=yes" process at
>> the top of the HAL process tree) that it receives the appropriate
>> sysevents from the kernel when a USB disk is plugged in or removed.
>> We get as far as the sysevent_dev_handler() routine:
>>
>>
>> https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L157-L191
>>
>> In particular, on my system, I see three write(2) calls that look
>> like this:
>>
>> EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2
>>
>> EC_devfs ESC_devfs_devi_add
>> /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
>>
>> EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
>> /dev/rdsk/c4t0d0 0
>>
>> This seems about right. These writes are into a self-pipe (i.e., both
>> ends of the pipe are held open within this single hald process) that
>> is established in the sysevent_init() routine, and stored in the
>> "sysevent_pipe_fds" global where I was able to confirm with pfiles
>> that the pipe is still open.
>>
>> Where things appear to fall down is once we get into the glib area.
>> The strings that are written into one end of the pipe by the sysevent
>> consumer, as described above, are meant to then be read through a glib
>> GIOChannel object in sysevent_iochannel_data():
>>
>>
>> https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272
>>
>> Though we do enter sysevent_iochannel_data() on schedule for each
>> sysevent, it seems like the call to g_io_channel_read_line() always
>> returns a value of 3 on my system -- which seems like an EOF? Because
>> the value is not G_IO_STATUS_NORMAL, we don't even try to call
>> sscanf() to parse the lines we wrote above. This means we never call
>> into sysevent_dev_add() and thus we never pass the hotplug event on to
>> the rest of HAL.
>>
>> I have run out of steam on this for now, but I hope this is enough for
>> someone to keep digging. In particular, it seems like it is worth
>> investigating whether glib has been updated in OI at some point
>> between when this was last working and now. Perhaps there is a build
>> issue or a bug there. It doesn't seem like there has been a lot of
>> change in the HAL daemon itself (which is in the gate, as linked
>> above).
>>
>> One imagines this may also have an impact on the X11 keyboard/mouse
>> situation as those changes are presumably communicated via sysevents
>> to HAL, and HAL is similarly dropping the ball there.
>>
>> Cheers.
>>
> Thanks a lot for your analysis, Josh.
>
> In fact we had some minor glib updates in the past. Alas we have neither
> automatic tests nor official testers at all.
> So, the main test burden is left to me. And I am only able to do limited
> manual tests, because I have lots of other things I want to do.
> I only use
Re: [oi-dev] OI no longer automounts USB sticks
Gary Mills wrote: > On Sun, Jun 27, 2021 at 01:00:46AM -0700, Joshua M. Clulow wrote: >> >> OK, so I have looked into this a little bit. It seems like there is a >> bug in the HAL code we ship, or in the glib that OI is now using, or >> somewhere inbetween. > > You've gone much farther than I have. With some help from you, I've > determined, with a current OI BE, that: > > Something failed to notify hald of new USB devices. Hald failed to > notify the process spawner: hald-runner. The mount was never done. > In general, we agree. > >> With DTrace, I am able to see (in the "hald --daemon=yes" process at >> the top of the HAL process tree) that it receives the appropriate >> sysevents from the kernel when a USB disk is plugged in or removed. > > It's good to know that that bit of IPC works as intended. > > [...] >> Where things appear to fall down is once we get into the glib area. >> The strings that are written into one end of the pipe by the sysevent >> consumer, as described above, are meant to then be read through a glib >> GIOChannel object in sysevent_iochannel_data(): >> >> >> https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272 >> >> Though we do enter sysevent_iochannel_data() on schedule for each >> sysevent, it seems like the call to g_io_channel_read_line() always >> returns a value of 3 on my system -- which seems like an EOF? Because >> the value is not G_IO_STATUS_NORMAL, we don't even try to call >> sscanf() to parse the lines we wrote above. This means we never call >> into sysevent_dev_add() and thus we never pass the hotplug event on to >> the rest of HAL. > > That sounds like the "temporarily unavailable" or the "interrupted > system call" errors for the read() system call in glib. > >> I have run out of steam on this for now, but I hope this is enough for >> someone to keep digging. In particular, it seems like it is worth >> investigating whether glib has been updated in OI at some point >> between when this was last working and now. Perhaps there is a build >> issue or a bug there. It doesn't seem like there has been a lot of >> change in the HAL daemon itself (which is in the gate, as linked >> above). > > The hal package is rebuilt for OI. There have been many changes, with > different revision numbers. For example, in the BE from 2020-11-27 > where mounts work, the package is service/hal@0.5.11-2020.0.1.20171 . > In the BE from 2021-05-14 where mounts do not work, the package is > service/hal@0.5.11-2020.0.1.20514 . I assume the revision numbers > do not indicate actual changes. > > I was trying to use a KVM switch the other day, and I suppose this issue is why I had to force a shutdown(power btn) of OI every time I had switched to another machine and back again. Mouse and keyboard were unresponsive but powered up. Potentially this is a lot worse than automounting of usb devices not working IMO. /tony -- Tony Albers - Systems Architect - Data Department, Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 27, 2021 at 01:00:46AM -0700, Joshua M. Clulow wrote: > > OK, so I have looked into this a little bit. It seems like there is a > bug in the HAL code we ship, or in the glib that OI is now using, or > somewhere inbetween. You've gone much farther than I have. With some help from you, I've determined, with a current OI BE, that: Something failed to notify hald of new USB devices. Hald failed to notify the process spawner: hald-runner. The mount was never done. In general, we agree. > With DTrace, I am able to see (in the "hald --daemon=yes" process at > the top of the HAL process tree) that it receives the appropriate > sysevents from the kernel when a USB disk is plugged in or removed. It's good to know that that bit of IPC works as intended. [...] > Where things appear to fall down is once we get into the glib area. > The strings that are written into one end of the pipe by the sysevent > consumer, as described above, are meant to then be read through a glib > GIOChannel object in sysevent_iochannel_data(): > > > https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272 > > Though we do enter sysevent_iochannel_data() on schedule for each > sysevent, it seems like the call to g_io_channel_read_line() always > returns a value of 3 on my system -- which seems like an EOF? Because > the value is not G_IO_STATUS_NORMAL, we don't even try to call > sscanf() to parse the lines we wrote above. This means we never call > into sysevent_dev_add() and thus we never pass the hotplug event on to > the rest of HAL. That sounds like the "temporarily unavailable" or the "interrupted system call" errors for the read() system call in glib. > I have run out of steam on this for now, but I hope this is enough for > someone to keep digging. In particular, it seems like it is worth > investigating whether glib has been updated in OI at some point > between when this was last working and now. Perhaps there is a build > issue or a bug there. It doesn't seem like there has been a lot of > change in the HAL daemon itself (which is in the gate, as linked > above). The hal package is rebuilt for OI. There have been many changes, with different revision numbers. For example, in the BE from 2020-11-27 where mounts work, the package is service/hal@0.5.11-2020.0.1.20171 . In the BE from 2021-05-14 where mounts do not work, the package is service/hal@0.5.11-2020.0.1.20514 . I assume the revision numbers do not indicate actual changes. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 27, 2021 at 11:50:31AM +0200, s...@pandora.be wrote: > I like the 2021.04 release of OI, this is a great piece of work, > and this release works well on my PC (thanks for the work on it). I like it too, especially the new Firefox. So far, I've only found one anomaly with it, and I have a workaround. It does work with web pages where previous versions would not. > Regarding the USB automount, I can personally live with the > workaround of manual mount. Automount would be nice so if it gets > fixed all the better. I use it periodically to transfer files from my main Unix system to another system that runs Windows 10. I know there are alternatives to USB sticks, but they are convenient. USB automount is useful to me. In both cases, it has taken me some time to notice problems with OI. Automated testing would not help much, because you have to know what a problem is, before you can design a test for it. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
Quiesce is to support fast reboot, it does not interfere with device connectivity. Sent from my iPhone > On 27. Jun 2021, at 15:27, s...@telenet.be wrote: > > > Although that OI 2020.04 and 2021.04 install both on this Dell Precision 3640 > system, > I have noticed: > > reboot: Not all drivers have implemented quiesce(9E) >Please see /var/adm/messages for drivers that haven't >implemented quiesce(9E). > > The driver that is indicated there is > > Jun 27 14:18:24 wapper genunix: [ID 884581 kern.warning] WARNING: xhci has no > quiesce() > > It would be interesting to compare to an older system which uses the ehci or > ohci USB driver. > > > Maybe OpenIndiana running on a PC without the xHCI behaves differently. > > David Stes > > - Op 27 jun 2021 om 13:14 schreef Andreas Wacknitz a.wackn...@gmx.de: > >>> Am 27.06.21 um 11:50 schrieb s...@pandora.be: >>> - Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de: >>> And I am only able to do limited manual tests, because I have lots of other things I want to do. I only use USB sticks very rarely and while I do change my mouse or keyboard from time to time, it hasn't been on my test scenarios in the past. So problems like this will only be detected long after they have been introduced. I'd appreciate if we could find some volunteers for tests and would even more appreciate if you could find somebody starting to create automatic tests. >>> >>> The best testing is desktop users of OpenIndiana. >>> >>> I like the 2021.04 release of OI, this is a great piece of work, and this >>> release works well on my PC >>> (thanks for the work on it). >>> >>> Regarding the USB automount, I can personally live with the workaround of >>> manual >>> mount. >>> Automount would be nice so if it gets fixed all the better. >>> >>> David Stes >>> >> While I understand your point of view you should be aware that if I >> continue to update things without proper testing more and more things >> will break. >> At some point in time I will break things you rely on and then your >> unhappiness will begin. >> >> We are a very small community and if I cannot convince more people to >> help out, OI will either become outdated in more and more areas >> or it will be more and more buggy. And probably both. >> >> I didn't find the problem earlier because of how I use OI. I don't use >> many things that I have been working on in the past. I will probably >> stop that, >> because I am running out of time. If I have to care for everything I >> will not be able to do anything in the end. >> >> Regards >> >> ___ >> oi-dev mailing list >> oi-dev@openindiana.org >> https://openindiana.org/mailman/listinfo/oi-dev > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
Although that OI 2020.04 and 2021.04 install both on this Dell Precision 3640 system, I have noticed: reboot: Not all drivers have implemented quiesce(9E) Please see /var/adm/messages for drivers that haven't implemented quiesce(9E). The driver that is indicated there is Jun 27 14:18:24 wapper genunix: [ID 884581 kern.warning] WARNING: xhci has no quiesce() It would be interesting to compare to an older system which uses the ehci or ohci USB driver. Maybe OpenIndiana running on a PC without the xHCI behaves differently. David Stes - Op 27 jun 2021 om 13:14 schreef Andreas Wacknitz a.wackn...@gmx.de: > Am 27.06.21 um 11:50 schrieb s...@pandora.be: >> - Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de: >> >>> And I am only able to do limited >>> manual tests, because I have lots of other things I want to do. >>> I only use USB sticks very rarely and while I do change my mouse or >>> keyboard from time to time, it hasn't been on my test scenarios in the past. >>> So problems like this will only be detected long after they have been >>> introduced. >>> >>> I'd appreciate if we could find some volunteers for tests and would even >>> more appreciate if you could find somebody starting to create automatic >>> tests. >> >> The best testing is desktop users of OpenIndiana. >> >> I like the 2021.04 release of OI, this is a great piece of work, and this >> release works well on my PC >> (thanks for the work on it). >> >> Regarding the USB automount, I can personally live with the workaround of >> manual >> mount. >> Automount would be nice so if it gets fixed all the better. >> >> David Stes >> > While I understand your point of view you should be aware that if I > continue to update things without proper testing more and more things > will break. > At some point in time I will break things you rely on and then your > unhappiness will begin. > > We are a very small community and if I cannot convince more people to > help out, OI will either become outdated in more and more areas > or it will be more and more buggy. And probably both. > > I didn't find the problem earlier because of how I use OI. I don't use > many things that I have been working on in the past. I will probably > stop that, > because I am running out of time. If I have to care for everything I > will not be able to do anything in the end. > > Regards > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
Am 27.06.21 um 11:50 schrieb s...@pandora.be: - Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de: And I am only able to do limited manual tests, because I have lots of other things I want to do. I only use USB sticks very rarely and while I do change my mouse or keyboard from time to time, it hasn't been on my test scenarios in the past. So problems like this will only be detected long after they have been introduced. I'd appreciate if we could find some volunteers for tests and would even more appreciate if you could find somebody starting to create automatic tests. The best testing is desktop users of OpenIndiana. I like the 2021.04 release of OI, this is a great piece of work, and this release works well on my PC (thanks for the work on it). Regarding the USB automount, I can personally live with the workaround of manual mount. Automount would be nice so if it gets fixed all the better. David Stes While I understand your point of view you should be aware that if I continue to update things without proper testing more and more things will break. At some point in time I will break things you rely on and then your unhappiness will begin. We are a very small community and if I cannot convince more people to help out, OI will either become outdated in more and more areas or it will be more and more buggy. And probably both. I didn't find the problem earlier because of how I use OI. I don't use many things that I have been working on in the past. I will probably stop that, because I am running out of time. If I have to care for everything I will not be able to do anything in the end. Regards ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
- Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de: > And I am only able to do limited > manual tests, because I have lots of other things I want to do. > I only use USB sticks very rarely and while I do change my mouse or > keyboard from time to time, it hasn't been on my test scenarios in the past. > So problems like this will only be detected long after they have been > introduced. > > I'd appreciate if we could find some volunteers for tests and would even > more appreciate if you could find somebody starting to create automatic > tests. The best testing is desktop users of OpenIndiana. I like the 2021.04 release of OI, this is a great piece of work, and this release works well on my PC (thanks for the work on it). Regarding the USB automount, I can personally live with the workaround of manual mount. Automount would be nice so if it gets fixed all the better. David Stes ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
Am 27.06.21 um 10:00 schrieb Joshua M. Clulow via oi-dev:
On Fri, 25 Jun 2021 at 18:52, 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.
# 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
Thanks for that!
OK, so I have looked into this a little bit. It seems like there is a
bug in the HAL code we ship, or in the glib that OI is now using, or
somewhere inbetween.
With DTrace, I am able to see (in the "hald --daemon=yes" process at
the top of the HAL process tree) that it receives the appropriate
sysevents from the kernel when a USB disk is plugged in or removed.
We get as far as the sysevent_dev_handler() routine:
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L157-L191
In particular, on my system, I see three write(2) calls that look like this:
EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2
EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
/dev/rdsk/c4t0d0 0
This seems about right. These writes are into a self-pipe (i.e., both
ends of the pipe are held open within this single hald process) that
is established in the sysevent_init() routine, and stored in the
"sysevent_pipe_fds" global where I was able to confirm with pfiles
that the pipe is still open.
Where things appear to fall down is once we get into the glib area.
The strings that are written into one end of the pipe by the sysevent
consumer, as described above, are meant to then be read through a glib
GIOChannel object in sysevent_iochannel_data():
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272
Though we do enter sysevent_iochannel_data() on schedule for each
sysevent, it seems like the call to g_io_channel_read_line() always
returns a value of 3 on my system -- which seems like an EOF? Because
the value is not G_IO_STATUS_NORMAL, we don't even try to call
sscanf() to parse the lines we wrote above. This means we never call
into sysevent_dev_add() and thus we never pass the hotplug event on to
the rest of HAL.
I have run out of steam on this for now, but I hope this is enough for
someone to keep digging. In particular, it seems like it is worth
investigating whether glib has been updated in OI at some point
between when this was last working and now. Perhaps there is a build
issue or a bug there. It doesn't seem like there has been a lot of
change in the HAL daemon itself (which is in the gate, as linked
above).
One imagines this may also have an impact on the X11 keyboard/mouse
situation as those changes are presumably communicated via sysevents
to HAL, and HAL is similarly dropping the ball there.
Cheers.
Thanks a lot for your analysis, Josh.
In fact we had some minor glib updates in the past. Alas we have neither
automatic tests nor official testers at all.
So, the main test burden is left to me. And I am only able to do limited
manual tests, because I have lots of other things I want to do.
I only use USB sticks very rarely and while I do change my mouse or
keyboard from time to time, it hasn't been on my test scenarios in the past.
So problems like this will only be detected long after they have been
introduced.
I'd appreciate if we could find some volunteers for tests and would even
more appreciate if you could find somebody starting to create automatic
tests.
Regards
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, 25 Jun 2021 at 18:52, 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.
> # 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
Thanks for that!
OK, so I have looked into this a little bit. It seems like there is a
bug in the HAL code we ship, or in the glib that OI is now using, or
somewhere inbetween.
With DTrace, I am able to see (in the "hald --daemon=yes" process at
the top of the HAL process tree) that it receives the appropriate
sysevents from the kernel when a USB disk is plugged in or removed.
We get as far as the sysevent_dev_handler() routine:
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L157-L191
In particular, on my system, I see three write(2) calls that look like this:
EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2
EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
/dev/rdsk/c4t0d0 0
This seems about right. These writes are into a self-pipe (i.e., both
ends of the pipe are held open within this single hald process) that
is established in the sysevent_init() routine, and stored in the
"sysevent_pipe_fds" global where I was able to confirm with pfiles
that the pipe is still open.
Where things appear to fall down is once we get into the glib area.
The strings that are written into one end of the pipe by the sysevent
consumer, as described above, are meant to then be read through a glib
GIOChannel object in sysevent_iochannel_data():
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272
Though we do enter sysevent_iochannel_data() on schedule for each
sysevent, it seems like the call to g_io_channel_read_line() always
returns a value of 3 on my system -- which seems like an EOF? Because
the value is not G_IO_STATUS_NORMAL, we don't even try to call
sscanf() to parse the lines we wrote above. This means we never call
into sysevent_dev_add() and thus we never pass the hotplug event on to
the rest of HAL.
I have run out of steam on this for now, but I hope this is enough for
someone to keep digging. In particular, it seems like it is worth
investigating whether glib has been updated in OI at some point
between when this was last working and now. Perhaps there is a build
issue or a bug there. It doesn't seem like there has been a lot of
change in the HAL daemon itself (which is in the gate, as linked
above).
One imagines this may also have an impact on the X11 keyboard/mouse
situation as those changes are presumably communicated via sysevents
to HAL, and HAL is similarly dropping the ball there.
Cheers.
--
Joshua M. Clulow
http://blog.sysmgr.org
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sat, Jun 26, 2021 at 07:56:41AM +0200, s...@pandora.be wrote: > > Shouldn't 'eject' be listing those removable disks (they currently > do not for me). You can't eject USB sticks because there is no eject mechanism. Only CD and DVD drives have the mechanism. You have to remove USB sticks from the connector yourself. The best you can do is un-mount them first. That's adequate. > I'd expect something like > > # eject -l > /dev/dsk/c12t0d0p0:1 rmdisk,rmdisk0,USBSLACK,/media/USBSLACK > /dev/dsk/c1t0d0s2cdrom,cdrom0,cd,cd0,sr,sr0 Perhaps you are thinking of "rmumount -l"? You can also un-mount them from the desktop icon. > and > > # eject rmdisk > rmdisk /dev/dsk/c12t0d0p0:1 unmounted Notice that it un-mounted the device but didn't eject it. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
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
Re: [oi-dev] OI no longer automounts USB sticks
Shouldn't 'eject' be listing those removable disks (they currently do not for
me).
I'd expect something like
# eject -l
/dev/dsk/c12t0d0p0:1 rmdisk,rmdisk0,USBSLACK,/media/USBSLACK
/dev/dsk/c1t0d0s2cdrom,cdrom0,cd,cd0,sr,sr0
and
# eject rmdisk
rmdisk /dev/dsk/c12t0d0p0:1 unmounted
Regards,
David Stes
- Op 26 jun 2021 om 3:52 schreef gary mills gary_mi...@fastmail.fm:
> 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.
>
>
> --
> -Gary Mills- -refurb--Winnipeg, Manitoba, Canada-
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
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.
--
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 25, 2021 at 08:45:10PM +0200, s...@pandora.be wrote: > > I can reproduce the problem; Knowing that helps a lot: I thought for a while that I was the only one. > When I plugin a USB key on my OI 2021.04 latest update system it > does not automount the volume; Yes, that's the same problem > cdrecord -scanbus shows the USB key controller.target.disk 5.0.0 so > from there it is also possible to deduce > root@wapper:~# mount -F pcfs /dev/dsk/c5t0d0p1 /mnt > > that works I used "fstyp" to find the right device name. > This is USB 2 key in a USB 3.2 port for me > > root@wapper:~# modinfo | grep xhci > 103 f7cef000 e8f0 251 1 xhci (USB xHCI Driver) I tried that too, also this: # mdb -ke '::prtusb' INDEX DRIVER INST NODE GEN VID.PID PRODUCT 1 xhci0 pci1043,8694 3.0 . No Product String 2 hid 3 mouse 1.1 045e.0040 Microsoft Wheel Mouse Optical� 3 usb_mid 1 device1.1 046d.c31c USB Keyboard 4 scsa2usb0 storage 2.0 13fe.3423 STORE N GO > There are also 2 USB 2 ports on my computer but that doesn't help > for automount either. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, 25 Jun 2021 at 11:45, s...@pandora.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@wapper:~# mount -F pcfs /dev/dsk/c5t0d0p1 /mnt
>
> that works
>
> This is USB 2 key in a USB 3.2 port for me
>
> root@wapper:~# modinfo | grep xhci
> 103 f7cef000 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_mi...@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@0.5.11-2020.0.1.20171 and
> > service/hal@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 IDFUNCTION: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
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
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@wapper:~# mount -F pcfs /dev/dsk/c5t0d0p1 /mnt that works This is USB 2 key in a USB 3.2 port for me root@wapper:~# modinfo | grep xhci 103 f7cef000 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_mi...@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@0.5.11-2020.0.1.20171 and > service/hal@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. > > > -- > -Gary Mills- -refurb--Winnipeg, Manitoba, Canada- > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
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@0.5.11-2020.0.1.20171 and service/hal@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. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On 6/6/21 9:43 PM, Gary Mills wrote: On Sun, Jun 06, 2021 at 11:06:06AM -0700, Alan Coopersmith wrote: hal monitors the devices and uses dbus to send messages to other programs on certain events - like notifying the GNOME/Mate file manager when a new removable media device is inserted or removed so they can show/hide it. So, I got it backwards. dbus is only a message bus or a rendevous point. It's hal that's likely responsible for ignoring changes to USB devices. I've already got ideas how to debug this problem. service/hal is delivered by illumos-gate ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, Jun 06, 2021 at 11:06:06AM -0700, Alan Coopersmith wrote: > > hal monitors the devices and uses dbus to send messages to other programs > on certain events - like notifying the GNOME/Mate file manager when a new > removable media device is inserted or removed so they can show/hide it. So, I got it backwards. dbus is only a message bus or a rendevous point. It's hal that's likely responsible for ignoring changes to USB devices. I've already got ideas how to debug this problem. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 04, 2021 at 03:11:32PM -0500, Gary Mills wrote: > > Ah, I tried the first command on an OI system running the 2020-11-27 > BE and did get some output while I inserted and removed a USB stick: > > # lshal --monitor > > Start monitoring devicelist: > - > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 added > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 added > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 added > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 > added > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 > added > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > added > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.mount_point = '/media/STORE N GO' > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.is_mounted_read_only = false (new) > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.is_mounted = true > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.mount_point = '' > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > property volume.is_mounted = false > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 > removed > > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 > removed > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 > removed > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 removed > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 removed > pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 removed > I also tried "dbus-monitor --system" on the same system as I inserted and removed a USB stick. I got too much output to capture, but this is part of it: method call time=1622910378.194372 sender=:1.39 -> destination=org.freedesktop.Hal serial=555 path=/org/freedesktop/Hal/devices/pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1; interface=org.freedesktop.Hal.Device; member=GetAllProperties method return time=1622910378.194409 sender=:1.2 -> destination=:1.39 serial=867 reply_serial=555 array [ ... dict entry( string "org.freedesktop.Hal.Device.Volume.method_execpaths" variant array [ string "hal-storage-mount" string "hal-storage-unmount" string "hal-storage-eject" ] ) ... dict entry( string "volume.label" variant string "STORE N GO" ) ... dict entry( string "block.solaris.raw_device" variant string "/dev/rdsk/c4t0d0p0:1" ) dict entry( string "block.device" variant string "/dev/dsk/c4t0d0p0:1" ) ... Note that the "lshal" output shows the mount point as '/media/STORE N GO', but the "dbus" output only shows the device name. "/media" is the mount point used by the "rmvolmgr" daemon and the "rmmount" command. Something must have mounted the USB stick between those two services. I'm not familiar with this area of OI; I only know what I saw in the output cited above. However, something must have convinced "dbus" to send those messages when the USB stick was inserted. I don't know what is missing or changed in the current OI BE so that it seems to ignore USB devices. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On 6/6/21 10:30 AM, Gary Mills wrote: As far as I can tell, "dbus" sends messages to "hal" about the state of devices on the system. However, for insertion of USB sticks, this does not happen. I don't know why it doesn't happen. hal monitors the devices and uses dbus to send messages to other programs on certain events - like notifying the GNOME/Mate file manager when a new removable media device is inserted or removed so they can show/hide it. -alan- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 04, 2021 at 01:16:38PM -0500, Gary Mills wrote: > I tried both of those commands, and got no output. That was "lshal --monitor" and "dbus-monitor --system" on a recent BE. Both of those commands produced no output. I know they work because I tried both of them on another system that was booted back to an older BE. There, both of them produced copious output, just as the support document showed. > The insertion and > removal does appear in /var/adm/messages, but goes no further. Here's what I saw on insertion of a USB stick: Jun 5 16:52:03 z400 usba: [ID 912658 kern.info] USB 2.0 device (usb951,160b) operating at hi speed (USB 2.x) on USB 2.0 root hub: storage@6, scsa2usb3 at bus address 3 Jun 5 16:52:03 z400 usba: [ID 349649 kern.info] Kingston DataTraveler2.0 0805050224383 Jun 5 16:52:03 z400 genunix: [ID 936769 kern.info] scsa2usb3 is /pci@0,0/pci103c,1309@1a,7/storage@6 Jun 5 16:52:03 z400 genunix: [ID 408114 kern.info] /pci@0,0/pci103c,1309@1a,7/storage@6 (scsa2usb3) online Jun 5 16:52:03 z400 scsi: [ID 583861 kern.info] sd9 at scsa2usb3: target 0 lun 0 Jun 5 16:52:03 z400 genunix: [ID 936769 kern.info] sd9 is /pci@0,0/pci103c,1309@1a,7/storage@6/disk@0,0 Jun 5 16:52:03 z400 genunix: [ID 408114 kern.info] /pci@0,0/pci103c,1309@1a,7/storage@6/disk@0,0 (sd9) online Jun 5 16:52:03 z400 genunix: [ID 127566 kern.info] device pciclass,03@0(display#0) keeps up device sd@0,0(disk#9), but the former is not power managed Note that the messages show only "sd9" as the disk device name. This is the old-style name, one that is no longer used. /dev/sd9 does not exist. The "rmformat" command show the device name as: /dev/rdsk/c8t0d0p0 . It does exist, as does the block device: /dev/dsk/c8t0d0p0 . As far as I can tell, "dbus" sends messages to "hal" about the state of devices on the system. However, for insertion of USB sticks, this does not happen. I don't know why it doesn't happen. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
It's possible to pkg install diagnostic/ddu and run ddu (Device Detection Utility) and check USB in the BE (boot env.) that works, and compare with the BE that doesn't work. Click on "Show details" for USB and what is the driver name for USB ? Is it : driver name ohci or driver name xhci ? - Op 5 jun 2021 om 16:00 schreef Andreas Wacknitz a.wackn...@gmx.de: > On 6/5/21 3:43 PM, Gary Mills wrote: >> On Sat, Jun 05, 2021 at 11:07:46AM +0200, Andreas Wacknitz wrote: >>> I don't use USB sticks with OI but I noticed something probably related >>> on my desktop: For some time now newly plugged mice or keyboards cannot >>> be used in X11. Even logout and re-login doesn't help. It looks as if >>> USB device need to be plugged during boot in order to be usable. >> I noticed that too. I thought at first that it was an illumos >> problem, but now I believe that it's another manifestation of the same >> OI problem. I'm assuming now that dbus is not noticing changes in USB >> devices, but I want to confirm that theory with more testing on OI. >> The next step is to determine why this is happening. >> >> > The last dbus change was > > commit d6ee7970120f4fc2201e33f2bcdcb318235ab0c3 > Author: Andreas Wacknitz > Date: Sat Oct 3 18:56:09 2020 +0200 > > libdbus, dbus, dbus-x11: update to 1.12.20 > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On 6/5/21 3:43 PM, Gary Mills wrote: On Sat, Jun 05, 2021 at 11:07:46AM +0200, Andreas Wacknitz wrote: I don't use USB sticks with OI but I noticed something probably related on my desktop: For some time now newly plugged mice or keyboards cannot be used in X11. Even logout and re-login doesn't help. It looks as if USB device need to be plugged during boot in order to be usable. I noticed that too. I thought at first that it was an illumos problem, but now I believe that it's another manifestation of the same OI problem. I'm assuming now that dbus is not noticing changes in USB devices, but I want to confirm that theory with more testing on OI. The next step is to determine why this is happening. The last dbus change was commit d6ee7970120f4fc2201e33f2bcdcb318235ab0c3 Author: Andreas Wacknitz Date: Sat Oct 3 18:56:09 2020 +0200 libdbus, dbus, dbus-x11: update to 1.12.20 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
I don't have an answer but the following manpage : man cfgadm_usb (1M) has some info that may help, such as the command to list usb: cfgadm -l -s "select=class(usb),cols=ap_id:info" | grep Mfg Taken from that manpage. Also I believe there are various USB drivers see "man usba" For example possibly check : modinfo | grep xhci David Stes - Op 5 jun 2021 om 11:07 schreef Andreas Wacknitz a.wackn...@gmx.de: > On 6/4/21 10:11 PM, Gary Mills wrote: >> On Fri, Jun 04, 2021 at 07:31:20AM -0500, Gary Mills wrote: >>> I found a document that might help. It describes: >>> >>> lshal --monitor >>> dbus-monitor --system >> Ah, I tried the first command on an OI system running the 2020-11-27 >> BE and did get some output while I inserted and removed a USB stick: >> >> # lshal --monitor >> >> Start monitoring devicelist: >> - >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 added >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 added >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 added >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 >> added >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 >> added >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 >> added >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 >> property volume.mount_point = '/media/STORE N GO' >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 >> property volume.is_mounted_read_only = false (new) >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 >> property volume.is_mounted = true >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 >> property volume.mount_point = '' >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 >> property volume.is_mounted = false >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 >> removed >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 >> removed >> >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 >> removed >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 >> removed >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 removed >> pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 removed >> >> This system did automount the USB stick and did pop up a window >> showing the contents of the stick. Now we are getting somewhere. >> Something is wrong with the OS upgrade. All that's left is to figure >> out what is missing or what is ignoring USB events. >> >> > I don't use USB sticks with OI but I noticed something probably related > on my desktop: For some time now newly plugged mice or keyboards cannot > be used in X11. Even logout and re-login doesn't help. It looks as if > USB device need to be plugged during boot in order to be usable. > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On 6/4/21 10:11 PM, Gary Mills wrote: On Fri, Jun 04, 2021 at 07:31:20AM -0500, Gary Mills wrote: I found a document that might help. It describes: lshal --monitor dbus-monitor --system Ah, I tried the first command on an OI system running the 2020-11-27 BE and did get some output while I inserted and removed a USB stick: # lshal --monitor Start monitoring devicelist: - pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.mount_point = '/media/STORE N GO' pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted_read_only = false (new) pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted = true pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.mount_point = '' pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted = false pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 removed This system did automount the USB stick and did pop up a window showing the contents of the stick. Now we are getting somewhere. Something is wrong with the OS upgrade. All that's left is to figure out what is missing or what is ignoring USB events. I don't use USB sticks with OI but I noticed something probably related on my desktop: For some time now newly plugged mice or keyboards cannot be used in X11. Even logout and re-login doesn't help. It looks as if USB device need to be plugged during boot in order to be usable. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 04, 2021 at 07:31:20AM -0500, Gary Mills wrote: > I found a document that might help. It describes: > > lshal --monitor > dbus-monitor --system Ah, I tried the first command on an OI system running the 2020-11-27 BE and did get some output while I inserted and removed a USB stick: # lshal --monitor Start monitoring devicelist: - pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 added pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.mount_point = '/media/STORE N GO' pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted_read_only = false (new) pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted = true pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.mount_point = '' pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 property volume.is_mounted = false pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4/p0_1 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4/sd4 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0/disk4 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0/scsi_host0 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_if0_0 removed pci_0_0/pci1022_1453_1_3/pci1b21_1142_0/storage_a_0 removed This system did automount the USB stick and did pop up a window showing the contents of the stick. Now we are getting somewhere. Something is wrong with the OS upgrade. All that's left is to figure out what is missing or what is ignoring USB events. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, Jun 04, 2021 at 07:31:20AM -0500, Gary Mills wrote: > I found a document that might help. It describes: > > lshal --monitor > dbus-monitor --system I tried both of those commands, and got no output. The insertion and removal does appear in /var/adm/messages, but goes no further. Is it possible that dbus is ignoring the USB messages? > which seem to be both clients. The document is at: > > https://www.suse.com/support/kb/doc/?id=16652 -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Thu, Jun 03, 2021 at 01:30:43PM -0300, Till Wegmueller wrote: > > To understand which service might be affected by the problem, could you > check if one either hal or rmvolmgr produce informative output? I found a document that might help. It describes: lshal --monitor dbus-monitor --system which seem to be both clients. The document is at: https://www.suse.com/support/kb/doc/?id=16652 -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Thu, Jun 03, 2021 at 01:30:43PM -0300, Till Wegmueller wrote: > > To understand which service might be affected by the problem, could you > check if one either hal or rmvolmgr produce informative output? How would I do that? I'm not familiar with either of those subsystems. I assume that the output would come from a client of those daemons. > Also another thing that might have changed is behaviour in the Mate > components in the UI that control the mounting. What do the GUI tools say > about mounting? Nothing, as far as I can tell. Are they supposed to? What tool or tools do you suggest? -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
Hi Gary To understand which service might be affected by the problem, could you check if one either hal or rmvolmgr produce informative output? Also another thing that might have changed is behaviour in the Mate components in the UI that control the mounting. What do the GUI tools say about mounting? -Till On 03.06.21 11:11, Gary Mills wrote: A couple of weeks ago, I upgraded my OI systems to the current version of OI. Everything seemed to work, although I didn't test everything. Yesterday, I inserted a USB stick into one of the systems, and was surprised that it didn't mount. It used to work. This event start me on an investigation. All of my USB sticks use a FAT32 filesystem and one FDISK partition. They all automount on Windows 10 and show no errors. On my test OI system, running the 2021-05-15 version of OI, they do not automount. A reboot did not help. The "fstyp" command for the :1 device shows a "pcfs" filesystem. I am able to mount and umount the device as root. It shows the correct content. When I booted the 2020-11-27 BE on that same system, the USB stick did automount. A window popped up showing the contents of the device. It also showed up in "mount | grep media". Another USB stick also automounted the same way. I conclude that something happened between those two versions of OI to prevent USB sticks from mounting. I don't know what changed or what is missing. Has anyone else seen the same problem? Automounting is complicated. These are three services that have to be operating properly for USB sticks to be automounted: $ svcs hal dbus rmvolmgr STATE STIMEFMRI online 20:54:09 svc:/system/dbus:default online 20:54:11 svc:/system/hal:default online 20:54:11 svc:/system/filesystem/rmvolmgr:default All three of them are online on all of my OI systems. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
