can't eject cdrom with hardware button

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

not confirming the issue there, unmount in the nautilus computer location and eject works

Pretty much reproducible. Nothing specific is required - just insert the disk, unmount it from computer location and push eject button to see that nothing happens. Additional annoyance is that unmount requires authorization. Anything else I can turn on to debug this misbehaviour?

kern.log
Jul 14 10:20:59 TBX kernel: [ 4447.115031] UDF-fs: No VRS found
Jul 14 10:20:59 TBX kernel: [ 4447.115037] UDF-fs: No partition found (1)

udev
UDEV [1247562419.211713] add /devices/pci0000:00/0000:00:1f.2/host1/target1:0:1/1:0:1:0/block/sr0 (block)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:1/1:0:1:0/block/sr0
SUBSYSTEM=block
DEVTYPE=disk
SEQNUM=1149
ID_CDROM=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_R=1
ID_CDROM_DVD_RAM=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_VENDOR=_NEC
ID_VENDOR_ENC=_NEC\x20\x20\x20\x20
ID_MODEL=DVD_RW_ND-4571A
ID_MODEL_ENC=DVD_RW\x20ND-4571A\x20
ID_REVISION=1-02
ID_TYPE=cd
ID_BUS=scsi
ID_PATH=pci-0000:00:1f.2-scsi-1:0:1:0
ACL_MANAGE=1
GENERATED=1
DEVNAME=/dev/sr0
MAJOR=11
MINOR=0
DEVLINKS=/dev/block/11:0 /dev/scd0 /dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:1:0 /dev/cdrom /dev/cdrw /dev/dvd /dev/dvdrw

I believe devicekit-disks is responsible for this, like with bug 417964. Updating affected package.

I can eject the drive when it is unmounted, but no attempt is made to unmount it if it _is_ mounted.
9.04 didn't have this behavier

So this is two bugs interealeved.

One is that nautilus keeps the cdrom device open (test it with fuser). This is fault of brasero, I will open a seperate bug about that.

As a workaround, rename

mv /usr/lib/nautilus/extensions-2.0/libnautilus-brasero-extension.so /usr/lib/nautilus/extensions-2.0/libnautilus-brasero-extension.s_o

This will make nautilus loose the burn:// capability, but it won't hold burned device opened.

Another problem, which I did report upstream is that devicekit or even kernel locks cdrom while mounted, but it should instead at least try to unmount the disk on button press.

For the workaround, you need to logout/login or kill nautilus for changes to take effect (remember desktop windows is managed by nautilus, and btw its address is x-nautilus-desktop://)

So, according to the upstream discussion David Zeuthen recommended to just not lock CD-ROM trays by default. Kernel/userspace already handles prematurely removed USB storage devices reasonably, and with read-only devices like CD-ROMs it is even less of an issue. So we should just set /proc/sys/dev/cdrom/lock to 0 by default.

From my POV, I'd just change procps to ship a new file /etc/sysctl.d/10-cdrom-tray-lock.conf with this setting. Scott, do you have an opinion whether this is reasonable?

@Martin Pitt:

I have tried your suggestion, but it doesn't work.

Here I have my own made kernel, and cdrom driver is compiled as a module (sr_mod)
I think ubuntu also has sr_mod as a module.

However, the procps upstart job is currently running before modules are loaded by udev, thus this doesn't work.

On Tue, 2009-09-29 at 20:21 +0000, Maxim Levitsky wrote:

> However, the procps upstart job is currently running before modules are
> loaded by udev, thus this doesn't work.
>
If we want to change the default, we should just change that in the
kernel

 affects linux

Scott
--
Scott James Remnant
<email address hidden>

This may be a duplicate of this bug:
https://bugs.launchpad.net/ubuntu/+source/devicekit-disks/+bug/438065

Seems like a kernel bug, fixed in 2.6.32...

if this is fixed in kernel 2.6.32 are we going to get this kernel in karmic, as this will be a major usability bug, especially for new users or users not use to linux.

Kernel team, are you fine with making this change in karmic? (Switching the default value of /proc/sys/dev/cdrom/lock to 0). They are currently discussing making that change upstream.

If not, I'll hack it into a sysctl script somewhere, but it'd be both subject to race conditions (see previous comment), and also just busywork (shipping one default in the kernel, but unconditionally changing it during boot).

Thanks for any comment,

Martin

So, procps wouldn't work due to module loading race conditions. Preferably this should just be changed in the kernel (waiting for Kernel team input), if not,I'll hack it into devkit-disks.

If the upstream default is changing and we are going to smash it in userspace unconditionally it seems reasonable to change this in the kernel to me. Do we have the upstream commit yet?

I can see no upstream commits changing this default at this time. Nor any specific change between v2.6.31 and v2.6.32-rc1 which would account for this working there. Does anyone have a pointer to the relevant discussion.

Discussion result in upstream bug:

------------------------------
I think the kernel defaults should lock all used drives by default, and should
not be touched at bootup, and thhings like liveCD rootfs and similar setups
should not be unlocked by a global default setting.

I think we might want to unlock individual drives though, if our own services
have applied the policy and mounted a media. I expect:
  ioctl(fd, CDROM_LOCKDOOR, 0);
would unlock only the single drive we are currently handling, and would not
touch other drives, or drives which have media which is mounted manually or by
a system-wide configuration.
----------------------

Patch sent upstream for review.

This bug was fixed in the package devicekit-disks - 007-1ubuntu1

---------------
devicekit-disks (007-1ubuntu1) karmic; urgency=low

  * Upload current Debian git head to pick up recent bug fixes.
  * debian/rules: Enable quilt patch system. Add quilt build dependency.
  * Add 01-mkfs-tempdir.patch: Daemon does not create /var/run/DeviceKit-disks/,
    so mkfs jobs fail. Just create the directory in /tmp, this is what /tmp is
    for, after all. (See https://bugs.freedesktop.org/show_bug.cgi?id=24265)
  * Add 00git-fix-inhibit.patch: Actually make Inhibit() work again. Taken
    from upstream git head. (LP: #428133)
  * Add 02-unlock-CD-trays-after-mounting.patch: Unlike in the hal world, we
    do not have a daemon polling CD drives for eject button presses. In order
    to make hardware tray eject buttons work, unlock the tray after
    mounting a CD. This is pretty much equivalent to yanking out USB sticks,
    which we already handle reasonably (detecting disappeared device,
    force-unmounting). (https://bugs.freedesktop.org/show_bug.cgi?id=24052,
    LP: #397734)
  * Add 03-fix-subsystem-check-for-firewire.patch: Firewire subsystem is
    called "ieee1394" in current Linux. Now check for both "ieee1394" and
    "firewire". This fixes firewire drives to not be considered system
    internal any more. (https://bugs.freedesktop.org/show_bug.cgi?id=24351,
    LP: #442604)
  * Add 04-mount-vfat-with-shortname-mixed-by-default.patch: The previous
    default, shortname=lower, breaks all-uppercase file names ("touch
    FOO" creates "foo"), thus breaks rsync, and Windows compatibility. The
    default was changed in the Linux kernel for 2.6.32 as well.
    (https://bugs.freedesktop.org/show_bug.cgi?id=24129, LP: #428174)
  * Add 05-dont-remove-NULL-values-from-hash-tables.patch: In device_remove(),
    device_file, object_path, or dev are sometimes NULL. Do not attempt to
    remove NULL from the hash tables, since this crashes. This is mainly a
    robustification patch, it does not really fix the underlying
    state bookkeeping. (http://bugs.freedesktop.org/show_bug.cgi?id=24264,
    LP: #414407)

 -- Martin Pitt <email address hidden> Fri, 09 Oct 2009 09:55:41 +0200

I confirm that now eject works as expected.

I also have confirmed that eject now works as expected. Thanks for the quick response and obvious hard work.

sorry but this still doesn't seem to work for me.
when i insert a dvd-video and then stop watching it and close totem and press the eject button on the drive nothing happens. i still have to open nautilus and unmount/eject from there.

i have done abit more testing with regard to this problem.

in the test i used an audio-cd, dvd-video, dvd-data disc (win 7 disc), and cd data disc (ubuntu 9.10 & ubuntu 9.04 discs)

this is the behaviour of these discs.
-the audio cd will mount and play in app and then unmount and eject with the eject drive button.
-dvd-video once mounted does not respond at all to the eject button press and needs to unmount/eject from nautilus.
-dvd-data disc will mount and allow you to navigate the data on the disc, when you press the eject button it does eject but leaves itself mounted, so when you but in another disc it doesn't mount, until you have unmounted this disc in nautilus.
-cd data discs works the same as dvd data discs.

This appears to be an ill advised 'fix' and some consideration should be given to reverting the 02 patch.

While it will work as intended some some combinations of hardware types and configurations it by no means works on all and most likely not even the majority.

Can confirm with what Mr. Gardner has posted some minor differences that are for the most part unimportant other than the fact that even the 'misbehaviour' is inconsistent.

On 2 desktops with 4 drives total only 1 out of the 4 will remove the mount when manually ejected.

To point out the unacceptable states ( 2 different drves, dvd media

dvd manually ejected, tray open
configuration: ansiversion=5 mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,utf8 state=mounted status=open

dvd manually ejected, tray closed
configuration: ansiversion=5 mount.fstype=udf mount.options=ro,nosuid,nodev,relatime,utf8 state=mounted status=nodisc

Since you report different followup problems now, and it's very impractical to track them all in just one report, can you please open new reoprts about (1) eject button not working for you (since that needs a different fix), and (2) mount not being removed automatically on eject? Thanks!

martin

i have raised a new bug for the further problems

#448921

 * Add 02-unlock-CD-trays-after-mounting.patch: Unlike in the hal world, we
    do not have a daemon polling CD drives for eject button presses. In order
    to make hardware tray eject buttons work, unlock the tray after
    mounting a CD.

Does this mean rw mounted media will get corrupted and/or data be lost?

it works when you first use the unmount option in nautilus and then eject. then, it opens.
but when pressing the hardware button for opening the cd-rom, it ain't working until you log off and/or log on again.

As discussed in bug 448921, the dk-d change was just enough to not lock the door on mount. However, the door is still locked on open("/dev/sr0"), which is done by DVD/audio CD players, CD recorders/rippers, etc. So the current dk-d fix is far from sufficient.

The only reliable way to make it work that I found is

  # echo 0 > /proc/sys/dev/cdrom/lock

So it seems we need to fix this in our kernel after all?

I'd just like to add an observation that the CD/DVD drive ejects just fine if you press the software eject button next to the drive in the Places sidebar of the File browser. This is pretty inconvenient for a HTPC however. The point is that maybe it would be easier to catch a hardware button press and execute the same bit of code that happens when you press the soft eject button?

Maybe related: I could not eject the medium (at all), then it ejected after a minute or two. See bug 489427.

Just informing everyone that I seem to be still encountering this bug - DVD movie which has been opened in a movie player cannot be ejected by the hardware button on the drive without first manually unmounting the drive or software ejecting the drive in nautilus. I am running a Karmic AMD_64 install.

As explained further above, we can't do any better in devicekit-disks. For totem etc. the locking needs to be fixed in the kernel.

Since that the case, I think that kernel defauit ought to be changed by patching the kernel.
The devicekit solution is really not full answer

Btw, folks, to workaround this, you can add to boot scripts the

'echo 0 > /proc/sys/dev/cdrom/lock' as suggested in one comment above.

With this, cdrom eject button ought to work.

I'm uncertain but could this bug be the same as https://bugs.launchpad.net/linux/+bug/412527 ? just wondering

Proposing for lucid. This is still causing a lot of grief, and I just got pinged by the OEM team about it as well.

We should check that wodim and friends do lock the CD tray while burning.

This bug was fixed in the package linux - 2.6.32-17.26

---------------
linux (2.6.32-17.26) lucid; urgency=low

  [ Amit Kucheria ]

  * [Config] SECURITY_FILE_CAPABILITIES dissapeared in 2.6.33

  [ Andy Whitcroft ]

  * rules -- allow architecture configurations to be missing
  * SAUCE: cdrom -- default to not locking the tray when in use
    - LP: #397734
  * expose the kernel EXTRAVERSION in dmesg and /proc/version_signature
  * record the drm version in EXTRAVERSION
  * linux-tools -- pull out the perf binary into a binary package
  * [Config] enable MMIOTRACE for graphics debugging
  * [Config] enable BLK_DEV_BSG
  * debian -- fix builds when tools are disabled
  * allow us to build default configs for automated builds
  * config -- allow locally specified configuration overrides
  * [Config] de-modularise PATA disk controllers
  * [Config] de-modularise SATA disk controllers

  [ Stefan Bader ]

  * Revert "SAUCE: (pre-stable) netfilter: xt_recent: fix buffer overflow"
    - LP: #540231
  * Revert "SAUCE: (pre-stable) netfilter: xt_recent: fix false match"
    - LP: #540231
  * [Config] Update configs for 2.6.32.10
    - LP: #540231

  [ Tim Gardner ]

  * [Config] Add vmw_pvscsi and vmxnet3 to -virtual flavour
    - LP: #531017
  * SAUCE: igb: Supress an upstream compiler complaint
  * [Config] Fix sub-flavours package conflicts
    - LP: #454827

  [ Upstream Kernel Changes ]

  * Revert "tpm_tis: TPM_STS_DATA_EXPECT workaround"
    - LP: #540231
  * Revert "(pre-stable) sched: Fix SMT scheduler regression in
    find_busiest_queue()"
    - LP: #540231
  * (pre-stable) Bluetooth: Fix sleeping function in RFCOMM within invalid
    context
    - LP: #534549
  * igb: remove unused temp variable from stats clearing path
  * igb: update comments for serdes config and update to handle duplex
  * igb: update the approach taken to acquiring and releasing the phy lock
  * igb: add locking to reads of the i2c interface
  * igb: add combined function for setting rar and pool bits
  * igb: make use of the uta to allow for promiscous mode filter
  * igb: add support for 82576NS SerDes adapter
  * igb: add function to handle mailbox lock
  * igb: fix a few items where weren't correctly setup for mbx timeout
  * igb: change how we handle alternate mac addresses
  * igb: remove microwire support from igb
  * igb: move the generic copper link setup code into e1000_phy.c
  * igb: add code to retry a phy read in the event of failure on link check
  * igb: add additional error handling to the phy code
  * igb: add flushes between RAR writes when setting mac address
  * igb: Use the instance of net_device_stats from net_device.
  * igb: Fix erroneous display of stats by ethtool -S
  * igb: add new data structure for handling interrupts and NAPI
  * igb: remove rx checksum good counter
  * igb: increase minimum rx buffer size to 1K
  * igb: move the tx and rx ring specific config into seperate functions
  * igb: remove rx_ps_hdr_len
  * igb: move SRRCTL register configuration into ring specific config
  * igb: change the head and tail offsets into pointers
  * igb: add pci device pointer to ring structure
  * igb: move rx_buffer_len into the ring structu...

Finally!

I burned a data CD-RW, and can confirm that pressing the eject button does nothing while cleaning, burning, or finalizing is in progress. After the burning is done, eject button works again.

So it seems cdrkit already properly locks the drive door for burning, and all is well.

I also tested burning a DVD (which uses growisofs, not cdrkit), and locking works there, too.

This Ubuntu/Baltix 9.10 eject bug can be easy fixed creating text file /etc/sysctl.d/60-cdrom-lock.conf with this content:

# CD/DVD eject button doesn't work until /proc/sys/dev/cdrom/lock is 1
dev.cdrom.lock = 0

I will attach the 60-cdrom-lock.conf file to this bugreport - it seems I should include this file into baltix-default-settings package for Baltix 9.10 (Karmic)

Martin Pitt or other Ubuntu developer, please tell me if "dev.cdrom.lock = 0" setting in /etc/sysctl.conf can cause any problems in Ubuntu 10.04, because I don't wanna to create problems for our users when they will upgrade Baltix 9.10 to Ubuntu 10.04.

Mantas -
Adding your file to a lucid testing install has resolved a long-standing odd behavior on one of my drives -/dev/sr0 - Lite-on DVD A DH20A4P ( since karmic alpha 1

The behavior was that to open the drive from a fresh start required exactly 3 presses on the drive's eject button. The first 2 would result in the drive attempting to open but failing (like the tray was 'stuck'

After that 1 press would suffice till a reboot when it would take 3 again, ect.

Noting that a launcher running 'eject' would work from a fresh start, though it seemed to take unusually long to do so. (the first time.
Now the eject button works the first time from a fresh/reboot start.

Whether the file has any unforeseen/ill effects on't know as yet.

was alpha 4, not 1, when behavior first started

doesnt work on minimal karmic

X3: Others have confirmed the fix, please file a different bug. Thanks.