'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/
