OpenIndiana Distribution

The restart of HAL is not required for me under OpenIndiana with USB storage on a Dell Precision 3640 with USB 3.1 xhci driver and using the following new glib2 package:

$ pkg info glib2
Name: library/glib2
Summary: GNOME core libraries
Category: Desktop (GNOME)/Libraries
Version: 2.66.8
Branch: 2022.0.0.1
Packaging Date: March 18, 2022 at 12:07:09 PM
Source URL: https://download.gnome.org/sources/glib/2.62/glib-2.62.6.tar.xz

Note that 2.66.8 revision 1 is actually glib-2.62.6.

Given the complexity of the issue, it is unclear to me whether the HAL version and DBUS version is also relevant.

The test (where usb did not require a HAL restart and HAL picked up usb changes) was using

service/hal 0.5.11-2022.0.0.21013 i--
system/library/dbus 1.12.20-2020.0.1.1 i--
system/library/dbus/dbus-x11 1.12.20-2020.0.1.1 i--
system/library/libdbus 1.12.20-2020.0.1.1 i--
system/library/libdbus-glib 0.112-2022.0.0.0 i--

Unfortunately the "hal" daemon is again not seeing the hardware change when a USB drive is attached with the following new setup:

1. pkg list hal dbus libdbus-glib media-volume-manager glib2
   NAME (PUBLISHER) VERSION IFO
   library/glib2 2.70.0-2022.0.0.0 i--
   service/hal 0.5.11-2022.0.0.21024 i--
   service/storage/media-volume-manager 0.5.11-2022.0.0.21024 i--
   system/library/dbus 1.12.20-2020.0.1.1 i--
   system/library/libdbus-glib 0.112-2022.0.0.0 i--

the old solution of restarting hal helps :

1. svcadm disable hal
2. svcadm disable rmvolmgr
3. svcadm enable hal
4. sleep 30; svcs hal
5. svcadm enable rmvolmgr

the sleep 30 is because it seems to take a while now for hal to restart but eventually svcs hal reports it is online again.
The sleep is to avoid enabling rmvolmgr while hal is still in offline* state.

Also see Debugging issues with eject and hal in the documention
[[
http://docs.openindiana.org/handbook/community/quikstor/]]

and the link there to the documentation
[[
https://iks.cs.ovgu.de/~elkner/s11/rmmount.html
]]

It is useful to debug this issue with the command:

dbus-monitor --session

Currently it works for me succesfully with the following packages:

1. pkg list media-volume-manager hal glib2 dbus
   NAME (PUBLISHER) VERSION IFO
   library/glib2 2.70.0-2022.0.0.1 i--
   service/hal 0.5.11-2022.0.0.21026 i--
   service/storage/media-volume-manager 0.5.11-2022.0.0.21026 i--
   system/library/dbus 1.12.20-2020.0.1.1 i--

1. pkg contents -t depend media-volume-manager
   TYPE FMRI
   require pkg:/system/library/libdbus-glib@0.112-2022.0.0.0
   require pkg:/shell/ksh93@93.21.1.20120801-2022.0.0.21026
   require pkg:/library/glib2@2.70.0-2022.0.0.0
   require pkg:/SUNWcs@0.5.11-2022.0.0.21026
   require pkg:/service/hal@0.5.11-2022.0.0.21026
   require pkg:/system/library/libdbus@1.12.20-2020.0.1.1
   require pkg:/service/storage/removable-media@0.5.11-2022.0.0.21026
   require pkg:/system/library@0.5.11-2022.0.0.21026
   require pkg:/system/library/dbus@1.12.20-2020.0.1.1
   require consolidation/osnet/osnet-incorporation

The above combination works and HAL receives an update of the USB hardware change.

The above packages claim to use glib2 2.70 but those are built from 2.62

pkg://openindiana.org/library/glib2@2.70.0,5.11-2022.0.0.1:20220331T113620Z

built from https://download.gnome.org/sources/glib/2.62/glib-2.62.6.tar.xz

​

with glib2 2.62 (installed as 2.70 . 0.0.2) on my OpenIndiana system, if I insert a USB device and monitor it with :

$ dbus-monitor --session --profile | grep RemoteVolumeMonitor

I see events on the dbus-monitor output like :

1.  DriveConnected
   2.  DriveChanged
   3.  VolumeAdded
   4.  VolumeMount
   5.  VolumeChanged
   6.  MountAdded

For the versions of OpenIndiana that have glib2 > 2.62 it is not known whether dbus-monitor shows the same events and HAL is not updated.

It seems to be related to glib change (git show c8811da56a6628d9df8a9fa0051c42e6bff94cd6) introduced with 2.63.6:

diff --git a/glib/giochannel.c b/glib/giochannel.c
index ed8546331..d16399846 100644
--- a/glib/giochannel.c
+++ b/glib/giochannel.c
@@ -1669,8 +1669,16 @@ g_io_channel_read_line (GIOChannel  *channel,

   if (status == G_IO_STATUS_NORMAL)
     {
+      gchar *line;
+
+      /* Copy the read bytes (including any embedded nuls) and nul-terminate.
+       * `USE_BUF (channel)->str` is guaranteed to be nul-terminated as it’s a
+       * #GString, so it’s safe to call g_memdup() with +1 length to allocate
+       * a nul-terminator. */
       g_assert (USE_BUF (channel));
-      *str_return = g_strndup (USE_BUF (channel)->str, got_length);
+      line = g_memdup (USE_BUF (channel)->str, got_length + 1);
+      line[got_length] = '\0';
+      *str_return = g_steal_pointer (&line);
       g_string_erase (USE_BUF (channel), 0, got_length);
     }
   else

reverting this change, it works like before.

This is the related glib issue:
https://gitlab.gnome.org/GNOME/glib/-/issues/2002
it seems resonable.

No idea what dbus (or whoever) sends here to hald.

This is the code snipped in hald (solaris/sysevent.c)

        while (g_io_channel_read_line (sysevent_iochannel, &s, &len, NULL,
             &err) == G_IO_STATUS_NORMAL) {
                if (len == 0) {
                        break;
                }
                HAL_INFO (("IOChannel val => %s", s));

Before the change the len != 0 and the while loop statements was executed.