kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #46658
[Bug 795239] Re: eject: unable to find or open device for: `cdrom' - but my cd is /dev/cdrom1
** Changed in: eject (Ubuntu)
Status: In Progress => Fix Committed
--
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 Committed
Status in “eject” package in Debian:
New
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