Problems with ImgBurn, err:aspi:ASPI_GetNumControllers

Carlos Mason · Post by **Carlos Mason** » Thu Mar 01, 2012 10:48 pm

I don't know exactly when, but something about my Linux Mint Debian Edition (LMDE) installation has changed that seems to have broken Wine when it comes to detecting ASPI devices, because I get the following error.

Code: Select all

err:aspi:ASPI_GetNumControllers Could not open HKLM\L"HARDWARE\\DEVICEMAP\\Scsi"

I tried searching the forums with the Forums -> Search for info about this error, but I got no results. If there are threads dealing with this topic elsewhere, I'd gladly move my discussion there. I also searched in the bug tracker for "ASPI_GetNumControllers" and the three references I found don't quite fit my case. I'm not getting any "ioctl" related errors, I'm not running OS X, and as far as I can tell the mount points for my optical drive have the correct permissions. Though in LMDE, most optical media is auto-mounted, bypassing the static mount points anyway.

From what I can deduce, whatever underlying component of LMDE Wine relies on to enumerate SCSI devices is not doing what it used to. As a result Wine (I presume) doesn't generate the "Scsi" key under "DEVICEMAP" and ImgBurn can't find any ASPI compliant devices. I'd try rolling back whatever it is that is supposed to do this, I'd guess libhal or libdbus if the Recommended Packages wiki page is anything to go by.

However, I'd like some confirmation that my hunch is leading me in the right direction and what version I should be looking to test. Or does anyone here have some other ideas about what might be wrong. For example, I did have some problems installing the proprietary fglrx drivers. Something about a bad "dkms.conf" file. I seem to have resolved that, but perhaps there's a kernel module that just isn't quite right. Or perhaps some other kernel related issue... My level of Linux expertise is probably somewhere between an apprentice and a journeyman.

FYI, I attempted to figure this out using various versions of Wine including 1.3.32 from the frickelplatz repository, 1.3.37 from Wine for Debian Sid page, and 1.2.3, 1.3.30, 1.3.37, 1.4-rc5 using PlayOnLinux. All are affected, a prime reason I think some other OS component is to blame.

Any advice will be appreciated.

Martin Gregorie · Post by **Martin Gregorie** » Fri Mar 02, 2012 6:28 am

On Thu, 2012-03-01 at 21:48 -0600, Carlos Mason wrote:

Any advice will be appreciated.

This won't help directly, but are you running logwatch and do you read
the overnight report that logwatch sends to root? This, amongst other
stuff, should show a list of the packages that have been updated during
the day - at least it does in a RedHat distro. If you see this list,
then you can determine what changed since the last time you used the
Wine app successfully.

FWIW I have logwatch set up to provide a daily report and I have
modified /etc/aliases so the mail system redirects mail for root, which
includes the logwatch report, to my own mailbox.

Martin

Carlos Mason · Post by **Carlos Mason** » Fri Mar 02, 2012 11:37 am

Martin Gregorie wrote:On Thu, 2012-03-01 at 21:48 -0600, Carlos Mason wrote:

Any advice will be appreciated.

This won't help directly, but are you running logwatch and do you read the overnight report that logwatch sends to root? <snip>

Martin

No, the logwatch package, while available in the repository(s), is not installed by default under LMDE. But it sounds like something I'll give a try, thanks.

Carlos Mason · Post by **Carlos Mason** » Thu Apr 05, 2012 12:06 am

Well, I finally found something of a solution. It's not ideal, but that may be down to my distro or my unfamiliarity with "udisks". I have to unmount the udisks auto-mounted optical device and then manually mount that drive to /media/cdrom0 (or wherever). At which point I can start ImgBurn and change the Interface (Tools->Settings->I/O->Page1) to SPTI. The drive can then be detected, so long as it is mapped in winecfg (Drives->Drive mappings).

Thing is, this isn't 100% reliable. In some cases I end up having to use "eject" on the command line to open the drive tray and/or unmount the device. I had one situation where during the same Wine session, ImgBurn 'lost' the CD-ROM. Unfortunately an errant mouse click minimized the "ImgBurn Log" and I was unable to copy the log messages (once the ImgBurn Log is minimized, the only way to get it back to hack Wine's registry and restart ImgBurn). I also couldn't eject or unmount the optical device no matter what I did... Well, other than a reboot.

I'm going to poke around and see if I can't get udisks and Wine cooperating in such a way that udisks mounted optical devices just work under Wine. At which point, I'll call this thread solved. If anyone else has suggestions, I'd be happy to hear them.

Carlos Mason · Post by **Carlos Mason** » Thu Apr 05, 2012 12:33 am

Hadn't realized ImgBrun keeps a running log until I went to its Forums... Odd thing is, where I thought the error would appear is not there. Though I think it may have been this.

Code: Select all

W 10:03:55 I/O Interface 'SPTI - Device Enumeration Method' has been changed!
I 10:03:55 Searching for SCSI / ATAPI devices...
E 10:03:57 Device->Initialise() Failed!
E 10:03:57 Device: [0:0:0] (D:)
E 10:03:57 This drive will not be visible in the program.

Which to me would indicate that the device may have been in use by a 'phantom' process. Given that I couldn't eject or umount either.