Hi all,
Got this weird problem for a few weeks now where I cannot eject optical disks after buring. (strangely, my old Tiberian Sun game disks can now be read, whereas previously could not on the desktop...).
I burn an optical disk using K3b -> burn succeeds and can mount it and read all the files using md5sum to compare against known checksum file.
I want to eject the disk, and then KDE pops up a message: "The device was successfully unmounted, but the tray could not be opened".
I also cannot eject using /usr/bin/eject
Stracing it:
open("/dev/hda", O_RDONLY|O_NONBLOCK) = 3 ioctl(3, CDROMEJECT, 0x1) = -1 EIO (Input/output error) ioctl(3, SG_GET_VERSION_NUM, 0x7fffdc13f47c) = 0 ioctl(3, SG_IO, 0x7fffdc13f3d0) = -1 EFAULT (Bad address) ioctl(3, FDEJECT, 0x1) = -1 ENOSYS (Function not implemented) ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0x7fffdc1440e0) = -1 ENOSYS (Function not implemented)
Oddly there's not close(3) but maybe it's not needed.
Another run: open("/dev/hda", O_RDONLY|O_NONBLOCK) = 3 ioctl(3, CDROMEJECT, 0x1) = -1 EIO (Input/output error) ioctl(3, SG_GET_VERSION_NUM, 0x7fff97ef8fac) = 0 ioctl(3, SG_IO, 0x7fff97ef8f00) = -1 EFAULT (Bad address) ioctl(3, FDEJECT, 0x1) = -1 ENOSYS (Function not implemented) ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0x7fff97efdc10) = -1 ENOSYS (Function not implemented)
The device is the correct device, and perms are:
brw-rw---- 1 root cdrom 3, 0 2009-11-16 08:57 /dev/hda
And I'm in the 'cdrom' group. From this moment onwards (until a reboot I guess), I have the same behaviour with optical disks: I can mount them, read them, unmount them, but cannot physically eject the drive, even if pressing (and/or holding) the drive eject button.
Running eject as root works perfectly, which seems to suggest a permissions problem.
As root:
open("/dev/hda", O_RDONLY|O_NONBLOCK) = 3 ioctl(3, CDROMEJECT, 0x1) = -1 EIO (Input/output error) ioctl(3, SG_GET_VERSION_NUM, 0x7fff6f0d36ec) = 0 ioctl(3, SG_IO, 0x7fff6f0d3640) = 0 ioctl(3, SG_IO, 0x7fff6f0d3640) = 0 ioctl(3, SG_IO, 0x7fff6f0d3640) = 0 ioctl(3, BLKRRPART, 0x7fff6f0d3640) = -1 EINVAL (Invalid argument) close(3) = 0
and again as root:
open("/dev/hda", O_RDONLY|O_NONBLOCK) = 3 ioctl(3, CDROMEJECT, 0x1) = -1 EIO (Input/output error) ioctl(3, SG_GET_VERSION_NUM, 0x7fff93f2ffac) = 0 ioctl(3, SG_IO, 0x7fff93f2ff00) = 0 ioctl(3, SG_IO, 0x7fff93f2ff00) = 0 ioctl(3, SG_IO, 0x7fff93f2ff00) = 0 ioctl(3, BLKRRPART, 0x7fff93f2ff00) = -1 EINVAL (Invalid argument) close(3) = 0
Initial searching suggests and issue with HAL. I've found that it seems k3b is still running and can be seen to have /dev/hda still open using lsof. Killing the process causes it to not appear in the lsof output, but still cannot eject. So it may even be a bug with K3b.
Any ideas, please?
Thanks Srdjan
Srdjan Todorovic wrote:
Initial searching suggests and issue with HAL. I've found that it seems k3b is still running and can be seen to have /dev/hda still open using lsof. Killing the process causes it to not appear in the lsof output, but still cannot eject. So it may even be a bug with K3b.
Do you have the "verify written data" option checked in k3b's burning window ?
For some time now that hasn't worked for me and leaves k3b holding onto the burnt disc. Although it visibly errors on the verify which you don't mention.