[Mageia-dev] HAL woes

Colin Guthrie mageia at colin.guthr.ie
Tue Jul 31 19:04:37 CEST 2012


'Twas brillig, and Frank Griffin at 30/07/12 13:00 did gyre and gimble:
> On a pre-/usr cauldron which has intentionally not been updated, wine
> apps have suddenly stopped being able to "see" mounted DVDs.
> 
> Checking syslog immediately after ejecting and reloading the disk, I find:
> 
> **************************************************************************
> Jul 29 10:50:50 localhost kernel: [  302.664794] sr 0:0:0:0: [sr0]
> Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Jul 29 10:50:50 localhost kernel: [  302.664798] sr 0:0:0:0: [sr0] Sense
> Key : Illegal Request [current]
> Jul 29 10:50:50 localhost kernel: [  302.664801] sr 0:0:0:0: [sr0] Add.
> Sense: Read of scrambled sector without authentication
> Jul 29 10:50:50 localhost kernel: [  302.664805] sr 0:0:0:0: [sr0] CDB:
> Read(10): 28 00 00 00 04 00 00 00 02 00
> Jul 29 10:50:50 localhost kernel: [  302.664810] end_request: I/O error,
> dev sr0, sector 4096
> Jul 29 10:50:50 localhost kernel: [  302.664812] Buffer I/O error on
> device sr0, logical block 512
> Jul 29 10:50:50 localhost kernel: [  302.697982] sr 0:0:0:0: [sr0]
> Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Jul 29 10:50:50 localhost kernel: [  302.697984] sr 0:0:0:0: [sr0] Sense
> Key : Illegal Request [current]
> Jul 29 10:50:50 localhost kernel: [  302.664801] sr 0:0:0:0: [sr0] Add.
> Sense: Read of scrambled sector without authentication
> Jul 29 10:50:50 localhost kernel: [  302.664805] sr 0:0:0:0: [sr0] CDB:
> Read(10): 28 00 00 00 04 00 00 00 02 00
> Jul 29 10:50:50 localhost kernel: [  302.664810] end_request: I/O error,
> dev sr0, sector 4096
> Jul 29 10:50:50 localhost kernel: [  302.664812] Buffer I/O error on
> device sr0, logical block 512
> Jul 29 10:50:50 localhost kernel: [  302.697982] sr 0:0:0:0: [sr0]
> Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Jul 29 10:50:50 localhost kernel: [  302.697984] sr 0:0:0:0: [sr0] Sense
> Key : Illegal Request [current]
> Jul 29 10:50:50 localhost kernel: [  302.697987] sr 0:0:0:0: [sr0] Add.
> Sense: Read of scrambled sector without authentication
> Jul 29 10:50:50 localhost kernel: [  302.697990] sr 0:0:0:0: [sr0] CDB:
> Read(10): 28 00 00 00 04 00 00 00 02 00
> Jul 29 10:50:50 localhost kernel: [  302.697994] end_request: I/O error,
> dev sr0, sector 4096
> Jul 29 10:50:50 localhost kernel: [  302.697996] Buffer I/O error on
> device sr0, logical block 512
> Jul 29 10:50:50 localhost systemd-udevd[32108]: failed to execute
> '/lib/udev/socket:@/org/freedesktop/hal/udev_event'
> 'socket:@/org/freedesktop/hal/udev_event': No such file or directory
> Jul 29 10:50:50 localhost systemd-udevd[32109]: failed to execute
> '/lib/udev/socket:/org/kernel/dm/multipath_event'
> 'socket:/org/kernel/dm/multipath_event': No such file or directory
> Jul 29 10:50:50 localhost udisksd[29333]: Error opening /etc/crypttab
> file: Failed to open file '/etc/crypttab': No such file or directory
> (g-file-error-quark, 4)
> 
> Jul 29 10:50:54 localhost haldaemon[27164]: Starting HAL daemon: [FAILED]
> Jul 29 10:50:54 localhost systemd[1]: haldaemon.service: control process
> exited, code=exited status=2
> Jul 29 10:50:54 localhost systemd[1]: Unit haldaemon.service entered
> failed state.
> Jul 29 10:50:54 localhost systemd[1]: Startup finished in 1s 93ms 504us
> (kernel) + 5s 214ms 916us (initrd) + 5min 1s 511ms 645us (userspace) =
> 5min 7s 820ms 65us.
> *******************************************************************************
> 
> 
> Based on observation, the stuff timestamped 10:50:50 is the result of
> ejecting the disk, and the last few lines timestamped 10:50:54 are the
> result of reloading it, with the intervening 4 seconds consumed by
> reading the disk headers and such.
> 
> I seem to remember here that nothing is supposed to be using HAL, so
> it's puzzling as to why systemd would be trying to start it in response
> to the load.  It's equally puzzling as to why this should suddenly
> affect wine, when nothing's been upgraded (this worked 2 or 3 days ago).
> 
> The disk is correctly mounted and identified by KDE, and is usable by
> k3b and command-line utilities.  k3b also detects the load event, and
> switches its GUI prompt from "insert a disk" to the actual label.
> 
> Is wine still hal-dependent when it ought not to be ?

FYI systemd is only used here because of a dbus activation request
coming in. Possibly there are still one old udev rules or something
similar that installs it.

Personally I remove haldaemon and lib64halX from my systems and have
done under mga1 too.

I hope it will be gone completely by mga3. I think there is still some
old perl code using it for dealing with install media in drak* as that
was mentioned recently. Also I think draksnapshot uses it too.

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


More information about the Mageia-dev mailing list