kernel-packages team mailing list archive

[Launchpad Bug Tracker <795239@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package eject - 2.1.5+deb1+cvs20081104-13.1

---------------
eject (2.1.5+deb1+cvs20081104-13.1) unstable; urgency=low


  [ Ankit Sinha ]
  * Non-maintainer upload.
  * eject now iterates through /dev/device_name[0-9]
    (LP: #795239, Closes: #719110)

  [ Bart Martens ]
  * debian/rules: Create directory debian/eject-udeb if it doesn't exist yet.

 -- Gianfranco Costamagna <costamagnagianfranco@xxxxxxxx>  Fri, 14 Feb
2014 22:17:11 +0100

** Changed in: eject (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to eject in Ubuntu.
https://bugs.launchpad.net/bugs/795239

Title:
  eject: unable to find or open device for: `cdrom' - but my cd is
  /dev/cdrom1

Status in “eject” package in Ubuntu:
  Fix Released
Status in “eject” package in Debian:
  Fix Released

Bug description:
  Binary package hint: eject

  The eject command does not actually eject my cdrom, unless called as
  'eject /dev/cdrom1'

  The problem seems to be that the eject command's default device is set
  to "/dev/cdrom" specifically.  Yet, udev will increment the drive name
  if new cdroms are added or even if you change the cable that the cdrom
  is connected to.  See
  https://bugzilla.redhat.com/show_bug.cgi?id=570490.  udev now assigns
  permanent names to devices in case they're being hotplugged, which
  obviously makes sense for servers but a bit sub-optimal for desktops
  where you generally have no more than one cd...

  Anyway, as a workaround, I can set up a /media/cdrom symlink to the
  proper device and then it works.  But that's a brittle solution since
  if I switched my cable back or changed cdroms, I'd have to manually
  adjust that link again.

  Possibly eject could be modified to determine the default device by
  looking first for /dev/cdrom, and then if that's missing, look for
  /dev/cdrom[0-9].  (Make sure /dev/cdroms is not included in that list
  obviously.)  If there's more than one cd device in the system, either
  bail out or bravely select the lowest numbered one.

  The file /proc/sys/dev/cdrom/info could also be read to discover the
  available devices.  This might be preferable to looking for
  /dev/cdrom*, I'm not sure.

  This udev change is a generic problem that affects all utilities that
  interact with the cdrom.  It is possible that this could be solved in
  a more general purpose way by some sort of little lib shared with xine
  and other cdrom users.  In any case, those other tools may have
  already solved this problem and could be worth examining for code
  reuse.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eject/+bug/795239/+subscriptions