[oi-dev] OI no longer automounts USB sticks

[Tony Brian Albers]

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 at 0.5.11-2020.0.1.20171 .
> In the BE from 2021-05-14 where mounts do not work, the package is
> service/hal at 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