Can not eject removable devices

Seems like Fedora also suffers from this bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142782

*** Bug 19423 has been marked as a duplicate of this bug. ***

I get this with USB devices too.

If you just run 'eject' then the 'last error' message is a little bit deceptive.
 When you run eject without params it tries all of the methods of eject. In the
case of a USB device, the last eject error is "invalid argument" because it's
trying to eject a USB device as if it were a floppy (or something else).

If you say eject -s (scsi) then it only tries the one method and you get -EPERM
(permission denied).

Of course, running with sudo works.

Strangely, here's a strace from doing it as a user:

open("/dev/sdb", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, SG_GET_VERSION_NUM, 0xbfce53c0) = 0
ioctl(3, SG_IO, 0xbfce4fb4) = -1 EPERM (Operation not permitted)

and one from root:

open("/dev/sdb", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, SG_GET_VERSION_NUM, 0xbf92fa50) = 0
ioctl(3, SG_IO, 0xbf92f644) = 0
ioctl(3, SG_IO, 0xbf92f644) = 0
ioctl(3, SG_IO, 0xbf92f644) = 0
ioctl(3, BLKRRPART, 0x804d878) = 0
close(3) = 0

Both open the device (and succeed). Both issue the same commands. Some
internal capability check is preventing it from working if you're non-root though.

I've done some looking around in the kernel that suggests that less capability
checks are performed if the user has opened the device read-write instead of
read-only. Of course, in order for this to happen you'd need to make the raw
device node read/write to plugdev users :/

*** Bug 19389 has been marked as a duplicate of this bug. ***

I got this issue in the past on i386, too (it always worked on powerpc and
amd64). But now I just installed today's breezy/i386 CD and it works fine. I
tested the default 386 and the k7 kernel, various configurations of my USB
sticks, and an audio CD, a data CD, and a DVD. Can you please check if you still
get the bug? Maybe by trying the latest live CD or installing the latest daily?
Thanks!

Created an attachment (id=3509)
output of strace eject -v /dev/sdb1 2> eject-strace.txt

*** Bug 19126 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
> Created an attachment (id=3509) [edit]
> output of strace eject -v /dev/sdb1 2> eject-strace.txt

OK, you have:
  open("/dev/sdb1", O_RDONLY|O_NONBLOCK) = 3
  ioctl(3, CDROMEJECT, 0x806c150) = -1 EIO (Input/output error)

On my system this looks like:
  open("/dev/sda1", O_RDONLY|O_NONBLOCK) = 3
  ioctl(3, CDROMEJECT, 0x2aaaaaef6380) = 0

The CD-ROM eject command usually works fine for USB devices, and I never saw it
fail on amd64 and powerpc.

So this is not actually an eject bug, it tries its best to eject the device.
Interestingly enough it seems to work when being executed as root. Ben, does the
kernel have any capability/privilege checking that sometimes makes ejection fail?

Maybe the summary should be changed so it's easier to find,
now that we have found that it affects iPod's and all kinds of stuff.

>> Will 5049 be fixed for breezy?

>I hope so, but I didn't get it any more recently, so it at least gets better...

I still get this with my iPod. Not with my digital camera though (USB Disk).

*** Bug 22298 has been marked as a duplicate of this bug. ***

I have this problem with my ipod and usbkeys on latest breezy.

*** Bug 21373 has been marked as a duplicate of this bug. ***

From a quick glance of the code path, I can't see that CDROMEJECT requires
CAP_SYS_ADMIN like some of the block leyer ioctl's do.

(In reply to comment #14)
> From a quick glance of the code path, I can't see that CDROMEJECT requires
> CAP_SYS_ADMIN like some of the block leyer ioctl's do.

Right, and on many computers eject actually works as normal user, it just breaks
on some.

*** Bug 21853 has been marked as a duplicate of this bug. ***

*** Bug 24201 has been marked as a duplicate of this bug. ***

*** Bug 24399 has been marked as a duplicate of this bug. ***

*** Bug 24272 has been marked as a duplicate of this bug. ***

*** Bug 24845 has been marked as a duplicate of this bug. ***

I am regularly seeing this bug with any usb mass storage I plug in to my system.
The CDROM ejects perfectly, but usb mass storage needs to be done as root to
avoid errors. I've tried messing with permissions in /etc/udev/permissions.rules
with no success.

This bug has been flagged because it is old and possibly inactive. It may or may
not be fixed in the latest release (Breezy Badger 5.10). It is being marked as
"NEEDSINFO". In two weeks time, if the bug is not updated back to "NEW" and
validated against Breezy, it will be closed.

This is needed in order to help manage the current bug list for the kernel. We
would like to fix all bugs, but need users to test and help with debugging.

If this change was in error for this bug, please respond and make the
appropriate change (or email <email address hidden> if you cannot make the
change).

Thanks for your help.

I'm still getting that issue with a breezy installation each time I try to eject
my iPod using nautilus. Doing it from the command line works fine.

The main cause of this bug is a patch to the ubuntu version of hal (added in
version 0.5.3-0ubuntu8) to force the storage.requires_eject property on usb
storage devices. You can locally workaround the issue, see bug 24399 for the file.

FWIW, this affects me with my Nokia 770 device

I'm not sure this is relevant, but the ipod needs an eject before being removed
(I don't think it's mandatory, but it's nicer since it gets rid of the "do not
disconnect" screen displayed on the ipod when it's plugged in), so I don't think
the workaround you mention would work.

Interesting bug. Putting it back to P3 so I can get around to it soon.

(In reply to comment #26)
> Interesting bug. Putting it back to P3 so I can get around to it soon.

Yes, it is by no way inactive, I get duplicates every week. Too bad that I
cannot reproduce it to investigate the problem.

Martin, it's 100% reproducible on my work machine, I can do any test that would
be useful for you to track down this problem (during the work week). I can
connect on jabber if necessary.

Created an attachment (id=4979)
test script

Usage: python cdeject.py <device>

Hi Christophe!

(In reply to comment #28)
> Martin, it's 100% reproducible on my work machine, I can do any test that would
> be useful for you to track down this problem (during the work week). I can
> connect on jabber if necessary.

IRC prefered - pitti on Freenode (I hang out in #ubuntu-devel when I'm at the
computer).

I would love to settle this, it is an utterly annoying bug. To start somewhere,
let's first nail down the ioctl to that it is really the sole cause. I wrote a
tiny python script that issues the ioctl for a given device. I. e. 'python
cdeject.py /dev/cdrom' ejects my CD, 'python /dev/sda' ejects my USB stick (i.
e. powers it off). Don't do that on mounted devices! :)

Can you please check whether these two commands work/fail on your system? (All
the other reporters are of course welcome to test this, too).

For the record, and for easier access to the relevant code: the ioctl is
implemented in drivers/block/scsi_ioctl.c, scsi_cmd_ioctl():

                case CDROMEJECT:
                        rq = blk_get_request(q, WRITE, __GFP_WAIT);
                        rq->flags |= REQ_BLOCK_PC;
                        rq->data = NULL;
                        rq->data_len = 0;
                        rq->timeout = BLK_DEFAULT_TIMEOUT;
                        memset(rq->cmd, 0, sizeof(rq->cmd));
                        rq->cmd[0] = GPCMD_START_STOP_UNIT;
                        rq->cmd[4] = 0x02 + (close != 0);
                        rq->cmd_len = 6;
                        err = blk_execute_rq(q, bd_disk, rq);
                        blk_put_request(rq);
                        break;

so let's see what the return code from the ioctl is (-1?).

Martin, I'm on longer at work at the moment, but I'll run your test first thing
on Monday.

Created an attachment (id=4983)
Output from strace eject -v /dev/sdb3 2> ipod_mini_strace.txt

This is the strace from ejecting my iPod mini, I hope it's helpful. I can do
more tests if necessary just be explicit in what to do as I'm new to this but
very willing to help.

Thanks.

if i take this out form /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi
i do not get the error. not sure if that helps...

<!-- Always eject USB storage devices to properly power them off -->
<device>
    <match key="info.category" string="storage">
      <match key="storage.bus" string="usb">
        <merge key="storage.requires_eject" type="bool">true</merge>
      </match>
    </match>
  </device>

With my Nokia 770, the test script gives:

Traceback (most recent call last):
  File "f", line 12, in ?
    r = fcntl.ioctl(f, CDROM.CDROMEJECT, 0)
IOError: [Errno 5] Input/output error

<email address hidden>: Removing that block from the .fdi file is basically what my
workaround in bug 24399 does (but I do it just for the one device that gives me
problems).

(In reply to comment #33)
> Created an attachment (id=4983) [edit]
> Output from strace eject -v /dev/sdb3 2> ipod_mini_strace.txt
>
> This is the strace from ejecting my iPod mini, I hope it's helpful. I can do
> more tests if necessary just be explicit in what to do as I'm new to this but
> very willing to help.

ioctl(3, CDROMEJECT, 0x804d9f8) = -1 EIO (Input/output error)

ok, this is basically the same result as the python script.

Thanks!

$ python ./eject.py /dev/sdb2
Traceback (most recent call last):
  File "./eject.py", line 12, in ?
    r = fcntl.ioctl(f, CDROM.CDROMEJECT, 0)
IOError: [Errno 5] Input/output error

(same thing if I call the script on /dev/sdb)
eject(1) usually works (I'm saying usually because I tested it after running
your script, and it's hanging)

Me, I can not eject even normal data CDs as a non-root user. The reason seems to
be that the normal eject command does not work on my drive, not even as root:

# strace eject -v -r /dev/hdc
[...]

write(1, "eject: trying to eject `/dev/hdc"..., 61eject: trying to eject
`/dev/hdc' using CD-ROM eject command) = 61
ioctl(3, CDROMEJECT, 0x2aaaaadf51c0) = -1 EIO (Input/output error)
write(1, "eject: CD-ROM eject command fail"..., 35eject: CD-ROM eject command
failed) = 35

On the other hand, making eject use a SCSI command by running "eject -s
/dev/hdc" as root works fine.

BUT: that does not work as a non-root user, since a SCSI eject seems to require
CAP_SYS_RAWIO. At least, running "eject -s /dev/hdc" as non-root returns ENOPERM.

Any suggestions? This is on an AMD64 system, a HP6125 laptop. The drive is a
TEAC DV-W28EW DVD writer.

*** Bug 25730 has been marked as a duplicate of this bug. ***

*** Bug 26877 has been marked as a duplicate of this bug. ***

Can someone upgrade to dapper with 2.6.15 kernel and retry this?

Sadly, 2.6.15-8-k7 still suffers from this bug with my Nokia 770, I still get
the errors from nautilus and the attached test script.

Today I borrowed an USB hd that reproduces the problem. It seems that some USB
devices do not like the CD-ROM eject ioctl, they want to be ejected only with
the SCSI eject ioctl. However, the CD-ROM one can be executed as a normal user,
while the SCSI one requires root privileges. This explains why eject works as
root -- it's not the fault of the cdrom ioctl permission check.

Ben, any idea about this? We probably shouldn't remove the capability check of
the SCSI command to protect internal SCSI drives from being ejected by normal users.

I basically see two options:

 * Make the cdrom ioctl work on all USB devices. I do not know whether this is
possible, though.
 * As a fallback, add support for calling eject to pmount, so that we call eject
with root privileges.

(In reply to comment #43)
> Today I borrowed an USB hd that reproduces the problem. It seems that some USB
> devices do not like the CD-ROM eject ioctl, they want to be ejected only with
> the SCSI eject ioctl. However, the CD-ROM one can be executed as a normal user,
> while the SCSI one requires root privileges. This explains why eject works as
> root -- it's not the fault of the cdrom ioctl permission check.

But I had the same problem on an IDE CDROM drive just the other day. This
problem isn't isolated to USB devices.

I investigated the differences between CDROMEJECT and "eject -s". Seems they
basically try to do the same thing (although one is done from the kernel). The
reason the -s works for IDE is because it is using the same interface as
cdrecord does when it writes to CDR's on IDE.

So, the commands are not SCSI specific. They are actually part of the generic
MMC spec. The difference between CDROMEJECT in the kerenl and eject -s is this:

CDROMEJECT:
    send START_STOP(0x1b) block 2

eject -s:
    send ALLOW_MEDIUM_REMOVAL(0x1e)
    send START_STOP(0x1b) block 1
    send START_STOP(0x1b) block 2

I am creating a test kernel for Martin that tries to match the eject -s behavior
more closely.

Martin, can you test the kernel I placed at this URL:

http://people.ubuntu.com/~bcollins/kernels/Bug-5049/

(new one since you tested the last one). This one has some printk's in the
CDROMEJECT stuff, so check dmesg if it fails again. I have about as close as I
think I can get to the eject -s emulation.

(In reply to comment #46)
> Martin, can you test the kernel I placed at this URL:
>
> http://people.ubuntu.com/~bcollins/kernels/Bug-5049/
>
> (new one since you tested the last one). This one has some printk's in the
> CDROMEJECT stuff, so check dmesg if it fails again. I have about as close as I
> think I can get to the eject -s emulation.

Unfortunately this still fails:

$ LANG=C eject -rv /dev/sda
eject: device name is `/dev/sda'
eject: expanded name is `/dev/sda'
eject: `/dev/sda' is not mounted
eject: `/dev/sda' is not a mount point
eject: `/dev/sda' is a multipartition device
eject: trying to eject `/dev/sda' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: unable to eject, last error: Input/output error

with the dmesg output:
Dec 16 11:13:05 localhost kernel: [ 501.616135] Sending
GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL

One last try might be to ignore the ALLOW_MEDIUM_REMOVAL failure and try with
START_STOP(0x1b) block 1 and 2. This is certainly not the scientific way, but it
would at least be interesting to figure out what is actually required to eject
these beasts.

Thank you!

New kernel, same location. THis time it ignores the errors and just sends the
three commands. Please test.

(In reply to comment #48)
> New kernel, same location. THis time it ignores the errors and just sends the
> three commands. Please test.

Alas, this bloody hard disk from hell really does not want to cooperate. CD-ROM
eject still fails, dmesg says

Dec 17 12:04:45 localhost kernel: [ 291.052351] Sending
GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL
Dec 17 12:04:45 localhost kernel: [ 291.053347] Sending GPCMD_START_STOP_UNIT
block 1
Dec 17 12:04:45 localhost kernel: [ 291.054213] Sending GPCMD_START_STOP_UNIT
block 2

If this is exactly the same as the SCSI eject command sends, then I'm really
puzzled. Thanks a million for your efforts, though.

(In reply to comment #49)
> Alas, this bloody hard disk from hell really does not want to cooperate. CD-ROM
> eject still fails, dmesg says

I think we've found the root of the problem. There is an error sending the
command to the device when it's done by the block layer via CDROMEJECT. If I
find the reason that, then I can probably resolve this.

Ok, new kernel, same location (.3 this time).

I think I found the problem (or atleast a problem). The code path for the eject
-s is also in block/scsi_ioctl.c. In sg_io, it pretty much does the same thing
we do for CDROMEJECT (but uses the data passed by the user to fill in the req).
However, there is one big difference. The sg_io code path will set the req to
READ for the eject -s req's, while CDROMEJECT sets it to WRITE. Bug? I think so,
because the ll_rw_blk.c stuff will eventually error because of the
data_len==0/type=WRITE combination.

Not sure why this only affects some devices, but it surely isn't correct.

Please test and let me know.

*** Bug 20303 has been marked as a duplicate of this bug. ***

Have an i386 kernel now that is reported to fix the problem (seb128 was able to
eject his iPod from gnome)

http://people.ubuntu.com/~bcollins/kernel/Bug-5049/

Make sure you get the -8.10.1 i386 kernel. Pretty certain I've got this fixed.
I'm marking it as pending upload (-9.11 will have this fix).

Just wanted to note a few other things I've discovered with regards to this problem.

1) eject -s was not working for non-root because it had a bug. Jens Axboe
pointed out that it needs to open the device O_RDWR, and it was opening with
O_RDONLY. I submitted bug #27380 with a patch to fix this, and also uploaded a
fixed eject package.

2) If you do eject a device such as an iPod or USB card reader, you may notice
that you cannot use this device again unless it is replugged. On my system, I
even restarted the machine and it was still inaccessible (power still to the USB
card reader). However, I found that if you do "eject -t" for CDROMCLOSETRAY on
the device, it comes back without replug. Nifty.

2.6.15-9 is uploaded, so this bug is resolved.

I tested with the latest kernel, and still get the problem:

Linux lifebook 2.6.15-9-386 #1 PREEMPT Wed Dec 21 14:24:17 UTC 2005 i686 GNU/Linux

julien@lifebook ~/Desktop $ python cdeject.py /dev/sda1
Traceback (most recent call last):
  File "cdeject.py", line 12, in ?
    r = fcntl.ioctl(f, CDROM.CDROMEJECT, 0)
IOError: [Errno 5] Input/output error

If you want me to perform some tests, just say it.

Yep, me too, I still get the same problem with the new kernel, trying to unmount
a Nokia 770 device

The final version in the upload was trimmed down a bit because Jens recommended
that the 0x01 start-stop was not needed, and that WRITE operations for blk
requests should be ok. Obviously one of those was wrong.

Next version will go back to my original changes.

(In reply to comment #58)
> The final version in the upload was trimmed down a bit because Jens recommended
> that the 0x01 start-stop was not needed, and that WRITE operations for blk
> requests should be ok. Obviously one of those was wrong.
>
> Next version will go back to my original changes.

With the upgrade to 2.6.15-9-686, my iPod generation 5 is being umouned and
remounted properly. The "do not disconnect" message is even removed from the
ipod when umounted.

Could this be somehow be ported to Breezy and uploaded to Breezy Updates? This
is a fairly serious bug that requires reboots on every change of removable media.

*** Bug 27553 has been marked as a duplicate of this bug. ***

(In reply to comment #60)
> Could this be somehow be ported to Breezy and uploaded to Breezy Updates? This
> is a fairly serious bug that requires reboots on every change of removable media.

I can hardly see how this requires a reboot. sudo eject -s is a workaround. As
such, with a workaround, there's no chance of it being put into breezy.

Actually, for me eject -s never worked. What worked was running eject more than
once. If I used eject -s I still had to run it twice.

As for there being a workaround, you're thinking from an elite user's
perspective. eject -s isn't going to help my sister-in-law. It's not a huge
patch, right? Why not let the patch through to breezy? What release rule does
"fixing user-visible bugs" violate? Breezy was, in several ways, a somewhat
embarassing release. Why not fix the embarassing bugs so that people can feel
confident encouraging others to use it?

(In reply to comment #63)
> Actually, for me eject -s never worked. What worked was running eject more than
> once. If I used eject -s I still had to run it twice.

That's a different issue altogether.

> As for there being a workaround, you're thinking from an elite user's
> perspective. eject -s isn't going to help my sister-in-law. It's not a huge
> patch, right? Why not let the patch through to breezy? What release rule does
> "fixing user-visible bugs" violate? Breezy was, in several ways, a somewhat
> embarassing release. Why not fix the embarassing bugs so that people can feel
> confident encouraging others to use it?

This bug has been around always. It's not like it just popped up in breezy.
Since it is not a regression, it's not considered that important. Rebuilding 12
kernels on 3 architectures and forcing everyone (even the majority not affected
by this bug) to update a 20meg .deb is not considered feasible, nor ideal.

I'm not saying I like this, but that's the way it is right now. After dapper is
released, it is my intention to make things easier for upgrades to get to users
post-release.

Fix as of atleast 2.6.15-11.16