Bug 138964 - eject unable to eject cd/dvd
Summary: eject unable to eject cd/dvd
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-12 06:52 UTC by James Bennett
Modified: 2015-01-04 22:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-15 22:41:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Error log from dmesg (10.99 KB, text/plain)
2004-11-19 06:00 UTC, Per Bjornsson
no flags Details

Description James Bennett 2004-11-12 06:52:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020 Epiphany/1.4.4

Description of problem:
When attempting to eject certain CDs or DVDs, `eject` fails. I first
encountered this after extracting tracks from an "enhanced" CD (a
music CD with music and other interactive content) with Sound Juicer;
Sound Juicer reported "Could not eject the CD Reason: Input/output
error". In testing with different discs this appears to consistently
happen with DVDs and with "enhanced" audio CDs. After one occurrence,
the problem seems to persist with any disc inserted, regardless of
type, and only goes away after a reboot. Output of `eject -v` in this
situation is as follows:

eject: device name is `/dev/hdc'
eject: expanded name is `/dev/hdc'
eject: `/dev/hdc' is not mounted
eject: `/dev/hdc' is not a mount point
eject: `/dev/hdc' is a multipartition device
eject: trying to eject `/dev/hdc' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/hdc' using SCSI commands
eject: SCSI eject failed
eject: trying to eject `/dev/hdc' using floppy eject command
eject: floppy eject command failed
eject: trying to eject `/dev/hdc' using tape offline command
eject: tape offline command failed
eject: unable to eject, last error: Invalid argument

Pressing the eject button on the drive itself also fails, even though
the disc is not mounted and `lsof` indicates no file on the device is
open. `eject` fails with the above errors regardless of whether the
device specified is '/dev/hdc' or as a symlink to that device, e.g.,
'/dev/cdrom', '/dev/dvd'. Ejection fails on '/media/cdrecorder' as well.

Running `eject -v` as root outputs the above errors but it does work,
leading me to believe that this may be a permissions problem. However,
I have not been able to find a combination of permissions which allow
a normal user to eject the disc and in any case the physical eject
button on the drive should not be disabled. If the system is shut
down, the drive's eject button begins working again as soon as the
shutdown sequence begins.

The system where this is occurring is an IBM Thinkpad G40 with TEAC
DW-224E DVD/CD-RW drive, running a fresh install of FC3. I'll try to
install on a different system later this week and see if it has the
same problem.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Insert a DVD or "enhanced" CD.
2. Attempt to eject it, either with `eject` or by pressing eject button.

Actual Results:  Disc is not ejected.

Expected Results:  Disc is ejected.

Comment 1 Ngo Than 2004-11-12 11:13:56 UTC
if pressing eject button on the drive itself fails and no file on
device is open, it seems a bug in kernel driver.

Comment 2 Dave Jones 2004-11-14 03:58:32 UTC
unless something still has a reference count on that cd.
nautilus (or some other desktop component) seems to automount things.
do you have an icon on your desktop ?    does the cdrom seem to
be mounted if you type 'mount' in a shell ?

do you get any messages in dmesg after a failed 'eject' ?

Comment 3 James Bennett 2004-11-14 07:36:34 UTC
Dave, the CD isn't mounted; I've disabled all of the automount/autorun
stuff, and when I started seeing this problem I double-checked just to
be sure. Between that and `lsof` I'm pretty sure nothing's using the

Regardless of the user `eject` is running as, the following pops up in
the kernel message log:

Nov 14 02:26:04 localhost kernel: program eject is using a deprecated
SCSI ioctl, please convert it to SG_IO

But as root the disc is actually ejected.

Comment 4 Tom Richardson 2004-11-16 02:21:44 UTC
I'm getting the exact same behavior on my system.  I have a brand new
NEC 3500 DVD burner.  This behavior did not occur in Fedora Core 2. 
The only eject command method that works is SCSI.  CD-ROM and others
do not.  Hitting either the button on the drive or the button in
gnome-cd doesn't even interrupt audio CD play.

Comment 5 Per Bjornsson 2004-11-19 05:56:14 UTC
I believe I have been seeing the same problem: CDs with both audio and
data tracks behave very strangely. When I just mount (either
automatically (gnome-volume-manager/hald) or just using the command
'mount /dev/cdrom /media/cdrecorder'
the disk doesn't mount; instead there is a horrific spew of errors in
the system log, of the kind
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
(I'll attach the complete relevant part of the dmesg output).

/dev/hdc                /media/cdrecorder       auto
pamconsole,ro,exec,noauto,managed 0 0

The CD is mounted just fine if I instead specify the filesystem:
mount -t iso9660 /dev/cdrom /media/cdrecorder

However, once I get the error spew, the "eject" command only works as
root until I reboot the computer. Regular data CDs do mount correctly
later in the same session though, even as an ordinary user, they just
don't get ejected - the error output is exactly the same as in the
original posting.

Comment 6 Per Bjornsson 2004-11-19 06:00:16 UTC
Created attachment 107030 [details]
Error log from dmesg

This is the dmesg output when the CD fails to mount.

Comment 7 James Bennett 2004-11-20 01:26:45 UTC
While tracking down another unrelated issue, I noticed that there are
apparently some problems with the drive on boot. On each boot, the
following appears in the kernel log:

localhost kernel: cdrom: open failed.

Not sure if this is related or something else, but felt it worthy of a

Comment 8 Sandip Bhattacharya 2004-11-20 21:19:37 UTC
Initially after upgrading from FC2, I couldnt use my CD drive for some
reason (didnt explore too much). I decided to add "hdc=ide-scsi" and
could then work comfortably. However, I kept on getting boot log
messages that ide-scsi is deprecated and I should use ide-cd instead.
And so I did make the required change (hdc=ide-scsi) in grub.

Now the CD is completely inaccessible. K3b cant find any CD, even
though cdrecord can find it just fine:
$ cdrecord -scanbus
  1,0,0   100) 'SONY    ' 'CD-RW  CRX230ED ' '4YS1' Removable CD-ROM

Eject doesnt work.

While boot time, the kernel does recognize the device, any attempts to
read the device later gives the following problem:

Nov 21 01:00:14 pluto kernel: device-mapper: 4.1.0-ioctl (2003-12-10)
initialised: dm@uk.sistina.com
Nov 21 01:00:14 pluto kernel: hdc: command error: status=0x51 {
DriveReady SeekComplete Error }
Nov 21 01:00:14 pluto kernel: hdc: command error: error=0x54
Nov 21 01:00:14 pluto kernel: ide: failed opcode was 100
Nov 21 01:00:14 pluto kernel: end_request: I/O error, dev hdc, sector 

For the time being I am going back to ide-scsi.

Comment 9 Tom Richardson 2004-11-21 16:56:00 UTC
It appears that leaving the CD drive *empty* for a long time
(overnight) causes some sort of timeout because when I wake up in the
morning, I can use the eject button on the drive to open it.  However,
after inserting a new disc, behavior reverts back to abnormal.

Comment 10 Tom Richardson 2004-11-22 14:48:39 UTC
Doing an 'init 3' after "locking" the CD drive allows it to be ejected
with the drive button.  Inserting a CDDA/Data disc then again locks
the drive.  Doing a 'eject hdc' ejects it.  However, after that normal
operation is possible.  Is this some strange udev/automount/kernel issue?

Comment 11 Sitsofe Wheeler 2004-12-02 00:39:32 UTC
eject failing on "corrupt" CD/DVDs might be covered by bug 139243

Comment 12 Sitsofe Wheeler 2004-12-02 00:46:59 UTC
The warning message "deprecated SCSI ioctl" is covered by bug 141402

Comment 13 Sitsofe Wheeler 2004-12-02 11:06:41 UTC
This bug might be related to bug 137831

Comment 14 James Bennett 2004-12-07 00:32:56 UTC
Re: possibly being covered by bug 139243, I'm still seeing this when HAL is not

Comment 15 Andreas M. Kirchwitz 2005-05-20 02:20:46 UTC
I have the same problem here (Fedora Core 3 with all patches,
but exactly the same happened to me with Fedora Core 2 as well).

When ripping certain audio CDs (enhanced CDs?) with Grip
(version doesn't matter), the CD cannot be ejected afterwards
without super-user privileges. The CD is not mounted or otherwise
blocked in an obvious way.

Is there any workaround to make it work again without a reboot?
It is a little bit annoying if normal users cannot use the CD drive
any longer and not even the super-user can fix this. ;-) Haven't
found anything helpful in other related bugs.

BTW: Bug 142782 seems to be a duplicate of this one.

Comment 16 Dave Jones 2005-07-15 19:25:49 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 17 James Bennett 2005-07-15 19:47:16 UTC
Some months ago I migrated that machine to another distro, and so I no longer
have a Fedora installation to test. Oddly enough, though, I'm having the same
problem on the other distro... I need to poke around in thei bug database
sometime and see what I can find.

Comment 18 Dave Jones 2005-07-15 22:41:51 UTC
This isn't uncommon btw. I frequently see people file bugs, and later move to a
different distro, and find things work for them. Then, their new distro does a
kernel update to bring it to the same version the Fedora kernel was on, and
their problems return. (Of course, they usually don't mention this in our
bugzilla ;)

The Fedora kernel is usually not patched as heavily as some other distributions
so a lot of bugs end up being inherited directly from the kernel.org kernels
that every distro bases off.

Given you've repeated it on two seperate distributions, I'd recommend filing an
upstream kernel bug at http://bugme.osdl.org

Thanks for the update.

Note You need to log in before you can comment on or make changes to this bug.