can't eject cdrom with hardware button

Reported by anatoly techtonik on 2009-07-10
284
This bug affects 79 people
Affects Status Importance Assigned to Milestone
Linux
Invalid
Undecided
Unassigned
obsolete
Fix Released
Medium
Baltix
Low
Mantas Kriaučiūnas
cdrkit (Ubuntu)
Medium
Martin Pitt
Karmic
Undecided
Unassigned
Lucid
Medium
Martin Pitt
devicekit-disks (Ubuntu)
Medium
Martin Pitt
Karmic
Medium
Martin Pitt
Lucid
Medium
Martin Pitt
linux (Ubuntu)
Medium
Andy Whitcroft
Karmic
Low
Unassigned
Lucid
Medium
Andy Whitcroft

Bug Description

Binary package hint: nautilus

When logged in I can't use hardware eject button to eject CD tray if there is a disk in drive. It doesn't work even if I unmount. With empty cdrom or from login screen hardware eject button works as expected.

After unmount lsof shows that /dev/sr0 is still being opened by nautilus.

$ lsof /dev/cdrom
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nautilus 3479 techtonik 26w BLK 11,0 0t0 2464 /dev/sr0

ProblemType: Bug
Architecture: i386
Date: Fri Jul 10 10:43:51 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: nautilus 1:2.27.2-0ubuntu1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-2.16-generic
SourcePackage: nautilus
Uname: Linux 2.6.31-2-generic i686

anatoly techtonik (techtonik) wrote :
Sebastien Bacher (seb128) wrote :

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.

Changed in nautilus (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Low
status: New → Incomplete
Sebastien Bacher (seb128) wrote :

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

anatoly techtonik (techtonik) wrote :

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

Brian Rogers (brian-rogers) wrote :

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

affects: nautilus (Ubuntu) → devicekit-disks (Ubuntu)
Changed in devicekit-disks (Ubuntu):
status: Incomplete → Confirmed
Maxim Levitsky (maximlevitsky) wrote :

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

While this might seem to be not a bug, but it used to work with HAL

It was possible to press the button on the cdrom to trigger the unmount & ejection.

It would even fail if some files were opened.

Best reproduced with this:

unset the /apps/nautilus/preferences/show_desktop gconf key.
(It seem that as a seperate bug, nautilus keeps cdrom opened, thus blocks the ejection), then close all nautilus windows.

Now insert a disk, observe that it can be ejected with button.
Now inset again, open g-d-u, and press 'mount'. Now hardware button is locked.
Now press 'unmount'. observe that now eject button works.

100% reproducible

Changed in devicekit:
status: Unknown → Confirmed

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.

Maxim Levitsky (maximlevitsky) wrote :

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://)

For the record, the hal-addon-storage had a poll loop which regularly queried the CD-ROM whether the eject button was pressed, and if so, emit an "EjectPressed" device condition through d-bus. Something in the desktop session (usually nautilus) would pick that up and ask hal to eject the drive.

This mechanism is completely lacking in DK-disks, so it's not a small change. Also, I'm not sure whether we actually want this kind of callback back in DK-disks.

One possible alternative would be to not lock the CD-ROM tray when mounting. This leads to much less clean unmounts, since the device would disappear while it is still mounted (and then the kernel/userspace have to clean up afterwards). For read-only media like CD-ROM or DVDs this does not actually pose a problem, though.

(In reply to comment #1)
> For the record, the hal-addon-storage had a poll loop which regularly queried
> the CD-ROM whether the eject button was pressed, and if so, emit an
> "EjectPressed" device condition through d-bus. Something in the desktop session
> (usually nautilus) would pick that up and ask hal to eject the drive.
>
> This mechanism is completely lacking in DK-disks, so it's not a small change.
> Also, I'm not sure whether we actually want this kind of callback back in
> DK-disks.

Right, I don't think we want to reintroduce that behavior. FWIW, newer SATA optical drives has a mechanism so we can avoid polling at all. This should save ~1W or so since the device and SATA link can be powered down all the time.

> One possible alternative would be to not lock the CD-ROM tray when mounting.
> This leads to much less clean unmounts, since the device would disappear while
> it is still mounted (and then the kernel/userspace have to clean up
> afterwards). For read-only media like CD-ROM or DVDs this does not actually
> pose a problem, though.

I think that is the way to go. So we should just tell distros to do

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

at boot time.

No much objection, but what happens if an application has an opened file on the cdrom, or even worse if a file is loop mounted from the cdrom.

In my opinion this can cause very nasty consequences (lock-ups)

(In reply to comment #3)
> No much objection, but what happens if an application has an opened file on the
> cdrom, or even worse if a file is loop mounted from the cdrom.
>
> In my opinion this can cause very nasty consequences (lock-ups)

It won't cause lock-ups except for the process in question - not for the system anyway. And properly written apps can deal with it, it's just IO errors.

FWIW, what happens today is that if the underlying device goes away, some part of userspace will lazy unmount the device. Ideally the kernel would force unmount filesystems (causing ENXIO (for fds) and SIGBUS (for mapped files) on IO), tear down RAID, LVM, device-mapper etc. but that is not how things currently works. Instead you get stale mount points, broken symlinks in sysfs and so on. My view is that it's a kernel bug, others may agree or disagree. We may end up fixing the kernel, we may not.

BTW, this is not very different from yanking a USB device or pulling out a CF card. And we deal relatively well with this already.

It makes sense. In fact today USB devices are much more common.

Thanks David. So should we close this as "wontfix" then?

(In reply to comment #6)
> Thanks David. So should we close this as "wontfix" then?

Sounds good to me.

Kay, what do you think about changing the defaults in the kernel so distros won't have to do the thing suggested in comment 2 at boot time?

Martin Pitt (pitti) on 2009-09-29
Changed in devicekit-disks (Ubuntu):
status: Confirmed → Triaged

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?

affects: devicekit-disks (Ubuntu) → procps (Ubuntu)
Changed in procps (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Martin Pitt (pitti)
importance: Low → Medium
status: Triaged → In Progress
tags: added: regression-potential
Maxim Levitsky (maximlevitsky) wrote :

@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>

Changed in devicekit:
status: Confirmed → Won't Fix

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.

Martin Pitt (pitti) wrote :

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

Changed in linux (Ubuntu):
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
Martin Pitt (pitti) wrote :

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.

affects: procps (Ubuntu) → devicekit-disks (Ubuntu)
Changed in devicekit-disks (Ubuntu):
status: In Progress → Incomplete
Andy Whitcroft (apw) wrote :

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?

Changed in linux (Ubuntu Karmic):
assignee: Canonical Kernel Team (canonical-kernel-team) → Andy Whitcroft (apw)
importance: Undecided → Low
status: New → In Progress
Andy Whitcroft (apw) wrote :

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.

(In reply to comment #8)
> Kay, what do you think about changing the defaults in the kernel so distros
> won't have to do the thing suggested in comment 2 at boot time?

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.

(In reply to comment #9)
> (In reply to comment #8)
> > Kay, what do you think about changing the defaults in the kernel so distros
> > won't have to do the thing suggested in comment 2 at boot time?
>
> 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.

Sounds good to me.

Sounds good to me as well.

Created an attachment (id=30106)
unlock CD trays after mounting

Tested patch. This hooks into the "mount completed" callback, and sends the ioctl for CD drives. If the mount failed, or we didn't mount anything, we should not mess with the drive, and don't need to either (since only the mounting actually locks the drive).

Thanks in advance for reviewing!

Re-subscribing David, it seems my patch comment wasn't mailed to him.

Created an attachment (id=30108)
unlock CD trays after mounting

Now with fixed whitespace

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.
----------------------

Changed in devicekit-disks (Ubuntu Karmic):
status: Incomplete → In Progress
Changed in linux (Ubuntu Karmic):
status: In Progress → Won't Fix
assignee: Andy Whitcroft (apw) → nobody
Changed in linux:
status: New → Invalid
Martin Pitt (pitti) wrote :

Patch sent upstream for review.

Changed in linux (Ubuntu):
assignee: Andy Whitcroft (apw) → nobody
status: In Progress → Won't Fix
Changed in devicekit-disks (Ubuntu Karmic):
status: In Progress → Fix Committed
Changed in devicekit:
status: Won't Fix → In Progress

(In reply to comment #14)
> Created an attachment (id=30108) [details]
> unlock CD trays after mounting
>
> Now with fixed whitespace
>

Looks good - a couple of notes/questions.

I'm not happy about poking the device directly from the main thread of the daemon to avoid lockups/blocking io. Right now we don't do any IO at all from the daemon - all IO is done from either programs started from udev rules or from separate job processes.

Long term, I want to be able to do IO from separate threads inside the daemon (instead of launching helper processes). But that requires reworking the internals - we should have an abstract Job class with ThreadedJob (to run code in a separate thread) and ProcessJob (to run code in a helper binary - just like most jobs today).

Since this particular case is fairly safe, let's just do it here and then we can move it to a threaded job once the internals has been reworked.

I'm curious what happens when you unmount/eject the disc, turn off automounting, insert a new disc, then mount it manually with mount(8). Is the door the locked?

(In reply to comment #15)
> I'm curious what happens when you unmount/eject the disc, turn off
> automounting, insert a new disc, then mount it manually with mount(8). Is the
> door the locked?

Just tested this: the door is locked.

I've committed the patch with a rewritten subject line "Bug 24052 – CDROM eject button is locked while CDROM is mounted". Thanks for fixing this!

(In the future, to make things easier to find, please use the "Bug <Bug Number> – <Bug Title>" format for patches that fixes bugs filed in bz - note the use of the wide hyphen too!)

(In reply to comment #15)

> I'm curious what happens when you unmount/eject the disc, turn off
> automounting, insert a new disc, then mount it manually with mount(8). Is the
> door the locked?

Right, I forgot to mention this previously, but I tested it when writing the
patch. It seems that mount() re-locks the tray, so unlike
/proc/sys/dev/cdrom/lock
the ioctl isn't "sticky" and needs to be re-issued after mounting.

> (In the future, to make things easier to find, please use the "Bug <Bug Number>
– <Bug Title>" format for patches that fixes bugs filed in bz - note the use
of the wide hyphen too!)

Ah, will do. Thanks for applying!

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

Changed in devicekit-disks (Ubuntu Karmic):
status: Fix Committed → Fix Released
Maxim Levitsky (maximlevitsky) wrote :

I confirm that now eject works as expected.

Joe (jgsylvesterjr) wrote :

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

Changed in devicekit:
status: In Progress → Fix Released

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.

Doug McMahon (mc3man) wrote :

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

Doug McMahon (mc3man) on 2009-10-10
Changed in devicekit-disks (Ubuntu Karmic):
status: Fix Released → New
Martin Pitt (pitti) wrote :

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!

summary: - can't eject unmounted cdrom with hardware button
+ can't eject cdrom with hardware button
Changed in devicekit-disks (Ubuntu Karmic):
status: New → Fix Released

martin

i have raised a new bug for the further problems

#448921

David Balažic (xerces8) wrote :

 * 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.

Martin Pitt (pitti) wrote :

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?

Changed in linux (Ubuntu):
status: Won't Fix → Triaged
scott (whittaker007) wrote :

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?

tags: added: regression-release
removed: regression-potential
David Balažic (xerces8) wrote :

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

Luke (ukee-mail) wrote :

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.

psymy (psymy) on 2009-12-06
Changed in devicekit-disks (Ubuntu Karmic):
status: Fix Released → Incomplete
tags: added: karmic
Martin Pitt (pitti) wrote :

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.

Changed in devicekit-disks (Ubuntu Karmic):
status: Incomplete → Fix Released
Maxim Levitsky (maximlevitsky) wrote :

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.

Martin Pitt (pitti) on 2010-02-15
Changed in linux (Ubuntu):
importance: Low → Medium
executorvs (executorvs) wrote :

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

Martin Pitt (pitti) wrote :

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

Changed in linux (Ubuntu Lucid):
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
Martin Pitt (pitti) wrote :

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

Changed in cdrkit (Ubuntu Karmic):
status: New → Won't Fix
Changed in cdrkit (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Medium
status: New → Triaged
Andy Whitcroft (apw) on 2010-03-11
Changed in linux (Ubuntu Lucid):
assignee: Canonical Kernel Team (canonical-kernel-team) → Andy Whitcroft (apw)
status: Triaged → In Progress
milestone: none → ubuntu-10.04-beta-2
Andy Whitcroft (apw) on 2010-03-12
Changed in linux (Ubuntu Lucid):
status: In Progress → Fix Committed
Martin Pitt (pitti) on 2010-03-14
summary: - can't eject cdrom with hardware button
+ can't eject cdrom with hardware button if CD-ROM is in fstab
summary: - can't eject cdrom with hardware button if CD-ROM is in fstab
+ can't eject cdrom with hardware button
Launchpad Janitor (janitor) wrote :
Download full text (16.5 KiB)

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...

Changed in linux (Ubuntu Lucid):
status: Fix Committed → Fix Released
Maxim Levitsky (maximlevitsky) wrote :

Finally!

Martin Pitt (pitti) on 2010-03-22
Changed in cdrkit (Ubuntu Lucid):
status: Triaged → In Progress
Martin Pitt (pitti) wrote :

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.

Changed in cdrkit (Ubuntu Karmic):
status: Won't Fix → Invalid
Changed in cdrkit (Ubuntu Lucid):
status: In Progress → Invalid
Martin Pitt (pitti) wrote :

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

Mantas Kriaučiūnas (mantas) wrote :

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.

Changed in baltix:
assignee: nobody → Mantas Kriaučiūnas (mantas)
importance: Undecided → High
status: New → In Progress
Doug McMahon (mc3man) wrote :

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.

Doug McMahon (mc3man) wrote :

was alpha 4, not 1, when behavior first started

X3 (x3lectric) wrote :

doesnt work on minimal karmic

David Tombs (dgtombs) wrote :

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

Changed in devicekit:
importance: Unknown → Medium
Changed in devicekit:
importance: Medium → Unknown
Changed in devicekit:
importance: Unknown → Medium
Changed in baltix:
importance: High → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.