[gentoo-user] How to get /dev/cdrom

[gentoo-user] How to get /dev/cdrom

[Michael Sullivan]

OK, for several years I have not had a /dev/cdrom.  My workstation has
an internal cd-rom drive, which gets mapped to /dev/hda, and an external
DVD+R drive, which is mapped to /dev/sr0.  When I look
at /etc/udev/rules.d/70-persistent-cd.rules I see:

camille rules.d # cat 70-persistent-cd.rules 
# LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1-ide-0:0)
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
+="cdrom", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
+="cdrw", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
+="dvd", ENV{GENERATED}="1"
# LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1-ide-0:0)
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
+="cdrom1", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
+="cdrw1", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
+="dvd1", ENV{GENERATED}="1"
# CD.DVDW_SD-R5372 (pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0)
ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0", SYMLINK
+="cdrom2", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0", SYMLINK
+="cdrw2", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0", SYMLINK
+="dvd2", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0", SYMLINK
+="dvdrw2", ENV{GENERATED}="1"
# CD.DVDW_SD-R5372 (pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0)
ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="TOSHIBA_CD.DVDW_SD-R5372_200503021764-0:0", SYMLINK
+="cdrom3", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="TOSHIBA_CD.DVDW_SD-R5372_200503021764-0:0", SYMLINK
+="cdrw3", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="TOSHIBA_CD.DVDW_SD-R5372_200503021764-0:0", SYMLINK
+="dvd3", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="TOSHIBA_CD.DVDW_SD-R5372_200503021764-0:0", SYMLINK
+="dvdrw3", ENV{GENERATED}="1"
# CD.DVDW_SD-R5372 (pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0)
ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0", SYMLINK
+="cdrom4", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0", SYMLINK
+="cdrw4", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0", SYMLINK
+="dvd4", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0", SYMLINK
+="dvdrw4", ENV{GENERATED}="1"
# LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1f.1", SYMLINK+="cdrom5", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1f.1", SYMLINK+="cdrw5", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_PATH}=="pci-0000:00:1f.1", SYMLINK+="dvd5", ENV{GENERATED}="1"

# CD_DVDW_SD-R5372 ()
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="TOSHIBA_CD_DVDW_SD-R5372_200503021764-0:0", SYMLINK
+="cdrom6", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="TOSHIBA_CD_DVDW_SD-R5372_200503021764-0:0", SYMLINK
+="cdrw6", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="TOSHIBA_CD_DVDW_SD-R5372_200503021764-0:0", SYMLINK
+="dvd6", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
ENV{ID_SERIAL}=="TOSHIBA_CD_DVDW_SD-R5372_200503021764-0:0", SYMLINK
+="dvdrw6", ENV{GENERATED}="1"

LITE-ON_COMBO_SOHC-5236K is my internal drive, which SHOULD be mapped
to /dev/cdrom.  But it's not:

camille rules.d # ls /dev/cdrom
ls: cannot access /dev/cdrom: No such file or directory


Why is it not being mapped correctly?  Is the rule above not correct?
I've tried to read tutorials about writing udev rules, but the example
rules in the tutorials look nothing like the above rules, and I didn't
write those.  I think they were created when udev was installed...

Re: [gentoo-user] How to get /dev/cdrom

[Paul Hartman]

On Wed, Jan 12, 2011 at 10:11 AM, Michael Sullivan <msulli1355@gmail.com> wrote:
> Why is it not being mapped correctly?  Is the rule above not correct?
> I've tried to read tutorials about writing udev rules, but the example
> rules in the tutorials look nothing like the above rules, and I didn't
> write those.  I think they were created when udev was installed...

I guess you don't really have 6 optical drives installed? :)

Some of those have -ide- in the device name, did you change form IDE
to ATA kernel driver at some point (like most everyone else did)?
Maybe that's why. New entries are generated for drives that don't
match existing rules, which is probably why you see your SOHC-5236K
down at cdrom5 as well...

If you delete the file and reboot, it'll create a new one based on
your currently-installed hardware config. Hopefully that'll solve it
or at least clean up that file to the point where you can manage the
changes more easily.

[gentoo-user] Re: How to get /dev/cdrom

[Nuno J. Silva]

Michael Sullivan <msulli1355@gmail.com> writes:

> OK, for several years I have not had a /dev/cdrom.  My workstation has
> an internal cd-rom drive, which gets mapped to /dev/hda, and an external

If you're using a recent kernel, it's probably udev which refuses to
process devices under the old ATA driver.

(I don't know if it *exactly* refuses, or if it's something else, but
the final result is what you see, no /dev/{cdrom,cdrw,...} link)


> DVD+R drive, which is mapped to /dev/sr0.  When I look
> at /etc/udev/rules.d/70-persistent-cd.rules I see:
>
> camille rules.d # cat 70-persistent-cd.rules 
> # LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1-ide-0:0)
> ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
> +="cdrom", ENV{GENERATED}="1"
...
> # LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1-ide-0:0)
> ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
> +="cdrom1", ENV{GENERATED}="1"
...
> # LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1)
> SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
> ENV{ID_PATH}=="pci-0000:00:1f.1", SYMLINK+="cdrom5", ENV{GENERATED}="1"
>
> LITE-ON_COMBO_SOHC-5236K is my internal drive, which SHOULD be mapped
> to /dev/cdrom.  But it's not:
>
> camille rules.d # ls /dev/cdrom
> ls: cannot access /dev/cdrom: No such file or directory

Check also /dev/cdrom*. Maybe it got another name, as there are at least
three rules to symlink that drive (if it matched all rules, udev would
create the three links, but the third rule looks different).

> Why is it not being mapped correctly?  Is the rule above not correct?
> I've tried to read tutorials about writing udev rules, but the example
> rules in the tutorials look nothing like the above rules, and I didn't
> write those.  I think they were created when udev was installed...

-- 
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg

Re: [gentoo-user] Re: How to get /dev/cdrom

[Michael Sullivan]

On Wed, 2011-01-12 at 16:31 +0000, Nuno J. Silva wrote:
> Michael Sullivan <msulli1355@gmail.com> writes:
> 
> > OK, for several years I have not had a /dev/cdrom.  My workstation has
> > an internal cd-rom drive, which gets mapped to /dev/hda, and an external
> 
> If you're using a recent kernel, it's probably udev which refuses to
> process devices under the old ATA driver.
> 
> (I don't know if it *exactly* refuses, or if it's something else, but
> the final result is what you see, no /dev/{cdrom,cdrw,...} link)
> 
> 
> > DVD+R drive, which is mapped to /dev/sr0.  When I look
> > at /etc/udev/rules.d/70-persistent-cd.rules I see:
> >
> > camille rules.d # cat 70-persistent-cd.rules 
> > # LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1-ide-0:0)
> > ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
> > +="cdrom", ENV{GENERATED}="1"
> ...
> > # LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1-ide-0:0)
> > ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
> > +="cdrom1", ENV{GENERATED}="1"
> ...
> > # LITE-ON_COMBO_SOHC-5236K (pci-0000:00:1f.1)
> > SUBSYSTEM=="block", ENV{ID_CDROM}=="?*",
> > ENV{ID_PATH}=="pci-0000:00:1f.1", SYMLINK+="cdrom5", ENV{GENERATED}="1"
> >
> > LITE-ON_COMBO_SOHC-5236K is my internal drive, which SHOULD be mapped
> > to /dev/cdrom.  But it's not:
> >
> > camille rules.d # ls /dev/cdrom
> > ls: cannot access /dev/cdrom: No such file or directory
> 
> Check also /dev/cdrom*. Maybe it got another name, as there are at least
> three rules to symlink that drive (if it matched all rules, udev would
> create the three links, but the third rule looks different).
> 
> > Why is it not being mapped correctly?  Is the rule above not correct?
> > I've tried to read tutorials about writing udev rules, but the example
> > rules in the tutorials look nothing like the above rules, and I didn't
> > write those.  I think they were created when udev was installed...
> 


camille ~ # ls -l /dev/cdrom*
ls: cannot access /dev/cdrom*: No such file or directory


I need /dev/hda to be /dev/cdrom because I cannot use CD player programs
unless it has that name.  Of course, I can manually create a symlink
from /dev/cdrom to /dev/hda every time I reboot, but I shouldn't have to
do that...

Re: [gentoo-user] How to get /dev/cdrom

[Mike Edenfield]

On 1/12/2011 11:11 AM, Michael Sullivan wrote:
> OK, for several years I have not had a /dev/cdrom.  My workstation has
> an internal cd-rom drive, which gets mapped to /dev/hda, and an external
> DVD+R drive, which is mapped to /dev/sr0.  When I look
> at /etc/udev/rules.d/70-persistent-cd.rules I see:

I just went through this exact same problem, and it turned out that
having both the old ATA drivers and the new libata drivers in my kernel
at the same time was the root of the problem.  I had multiple drivers
fighting for the same device, and it confused udev for some reason.  The
end result was, udev never picked up that the IDE drive was actually a
CD-ROM, so it never ran the udev rules to automatically regenerated
70-persistent-cd.rules.

The existing rules you have don't work because the ID_PATH isn't valid:

ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0"

The "-ide-0:0" part no longer shows up when you get the udev ID_PATH for
a device using the old ATA drivers, so there are no matching udev rules
to create the symlinks.

I fixed it by switching over completely to libata, like this:

1. Delete the 70-persistent-cd.rules file from /etc/udev.  (If
everything is working correctly, udev will regenerate this file from
scratch the next time you start it.)

2. In your kernel config, under Device Drivers --->
* Make sure that ATA/ATAPI/MFM/RLL support is /not/ selected.
* Enable Serial ATA and Parallel ATA
* Under Serial ATA and Paralle ATA --->
** Enable ATA SFF support
** Below that, enable ATA BMDMA support[1]
** Below that, enable whatever IDE chipset you have

3. Back under Device Drivers --->
* Under SCSI device support --->
** Enable SCSI disk support
** Enable SCSI CDROM support
** /Do not/ enable SCSI Generic support[2]

Build/install/reboot and you should now see your two CD drives appearing
as sr0 and sr1.  udev should now pick them both up, and write a new
70-persistent-cd.rules file, with the IDE drive having a different
ID_PATH, something like:

ENV{ID_PATH}=="pci-0000:00:1f.1-scsi-0:0:0:0"

And you should now get your symlinks.

[1] BMDMA is the controller type in all of the machines I have, and
seems to be the standard for most personal desktop/laptop/etc machines.
 If you know differently, of course, pick the correct SFF controller.

[2] The SCSI generic driver has a habit of grabbing my other SCSI
devices and assigning them to sg0/sg1/sg2/etc; this seemed to prevent
udev from picking up that they were CD drives.  If you need SCSI Generic
for some reason, I'd suggest making it a module.

--Mike

Re: [gentoo-user] How to get /dev/cdrom

[Michael Sullivan]

On Wed, 2011-01-12 at 10:28 -0600, Paul Hartman wrote:
> On Wed, Jan 12, 2011 at 10:11 AM, Michael Sullivan <msulli1355@gmail.com> wrote:
> > Why is it not being mapped correctly?  Is the rule above not correct?
> > I've tried to read tutorials about writing udev rules, but the example
> > rules in the tutorials look nothing like the above rules, and I didn't
> > write those.  I think they were created when udev was installed...
> 
> I guess you don't really have 6 optical drives installed? :)
> 
> Some of those have -ide- in the device name, did you change form IDE
> to ATA kernel driver at some point (like most everyone else did)?
> Maybe that's why. New entries are generated for drives that don't
> match existing rules, which is probably why you see your SOHC-5236K
> down at cdrom5 as well...
> 
> If you delete the file and reboot, it'll create a new one based on
> your currently-installed hardware config. Hopefully that'll solve it
> or at least clean up that file to the point where you can manage the
> changes more easily.
> 

I deleted /etc/udev/rules.d/70-persistent-cd.rules and rebooted the
system.  The file is still gone, and still no /dev/cdrom:
camille ~ # ls /etc/udev/rules.d/
10-zaptel.rules   70-bluetooth.rules   70-libsane.rules
90-hal.rules   hsf.rules
30-svgalib.rules  70-libgphoto2.rules  70-persistent-net.rules
99-btnx.rules
camille ~ # ls /dev/cdrom*
ls: cannot access /dev/cdrom*: No such file or directory


What should I do now?

Re: [gentoo-user] Re: How to get /dev/cdrom

[Mike Edenfield]

On 1/12/2011 11:31 AM, Nuno J. Silva wrote:
> Michael Sullivan <msulli1355@gmail.com> writes:
> 
>> OK, for several years I have not had a /dev/cdrom.  My workstation has
>> an internal cd-rom drive, which gets mapped to /dev/hda, and an external
> 
> If you're using a recent kernel, it's probably udev which refuses to
> process devices under the old ATA driver.
> 
> (I don't know if it *exactly* refuses, or if it's something else, but
> the final result is what you see, no /dev/{cdrom,cdrw,...} link)

The problem, as far as I could figure out, is that the ID_PATH that udev
gets from the old ATA drivers is identical for everything on the same
IDE controller; it basically gives the path to the PCI bus slot where
the IDE controller is connected.  So udev has no way to differentiate
between multiple drives connected to a single controller.  This is a
change at some point from the previous behavior, which specified the IDE
information as well.

You used to get something like:

ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0"

and now you get:

ENV{ID_PATH}=="pci-0000:00:1f.1"

Switching over to libata gives you:

ENV{ID_PATH}=="pci-0000:00:1f.1-scsi-0:0:0:0"

which returns everything to working order :)

--Mike

Re: [gentoo-user] How to get /dev/cdrom

[Michael Sullivan]

On Wed, 2011-01-12 at 11:54 -0500, Mike Edenfield wrote:
> On 1/12/2011 11:11 AM, Michael Sullivan wrote:
> > OK, for several years I have not had a /dev/cdrom.  My workstation has
> > an internal cd-rom drive, which gets mapped to /dev/hda, and an external
> > DVD+R drive, which is mapped to /dev/sr0.  When I look
> > at /etc/udev/rules.d/70-persistent-cd.rules I see:
> 
> I just went through this exact same problem, and it turned out that
> having both the old ATA drivers and the new libata drivers in my kernel
> at the same time was the root of the problem.  I had multiple drivers
> fighting for the same device, and it confused udev for some reason.  The
> end result was, udev never picked up that the IDE drive was actually a
> CD-ROM, so it never ran the udev rules to automatically regenerated
> 70-persistent-cd.rules.
> 
> The existing rules you have don't work because the ID_PATH isn't valid:
> 
> ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0"
> 
> The "-ide-0:0" part no longer shows up when you get the udev ID_PATH for
> a device using the old ATA drivers, so there are no matching udev rules
> to create the symlinks.
> 
> I fixed it by switching over completely to libata, like this:
> 
> 1. Delete the 70-persistent-cd.rules file from /etc/udev.  (If
> everything is working correctly, udev will regenerate this file from
> scratch the next time you start it.)
> 
> 2. In your kernel config, under Device Drivers --->
> * Make sure that ATA/ATAPI/MFM/RLL support is /not/ selected.
> * Enable Serial ATA and Parallel ATA
> * Under Serial ATA and Paralle ATA --->
> ** Enable ATA SFF support
> ** Below that, enable ATA BMDMA support[1]
> ** Below that, enable whatever IDE chipset you have
> 
> 3. Back under Device Drivers --->
> * Under SCSI device support --->
> ** Enable SCSI disk support
> ** Enable SCSI CDROM support
> ** /Do not/ enable SCSI Generic support[2]
> 
> Build/install/reboot and you should now see your two CD drives appearing
> as sr0 and sr1.  udev should now pick them both up, and write a new
> 70-persistent-cd.rules file, with the IDE drive having a different
> ID_PATH, something like:
> 
> ENV{ID_PATH}=="pci-0000:00:1f.1-scsi-0:0:0:0"
> 
> And you should now get your symlinks.
> 
> [1] BMDMA is the controller type in all of the machines I have, and
> seems to be the standard for most personal desktop/laptop/etc machines.
>  If you know differently, of course, pick the correct SFF controller.
> 
> [2] The SCSI generic driver has a habit of grabbing my other SCSI
> devices and assigning them to sg0/sg1/sg2/etc; this seemed to prevent
> udev from picking up that they were CD drives.  If you need SCSI Generic
> for some reason, I'd suggest making it a module.
> 
> --Mike
> 
I was still running linux-2.6.30-gentoo-r8.  I didn't even HAVE an
option for ATA SFF support.  I'm going to build a v2.6.36-gentoo-r5
kernel and pray that my ivtv stuff still works...

[gentoo-user] Re: How to get /dev/cdrom

[Nuno J. Silva]

Mike Edenfield <kutulu@kutulu.org> writes:

> On 1/12/2011 11:31 AM, Nuno J. Silva wrote:
>> Michael Sullivan <msulli1355@gmail.com> writes:
>> 
>>> OK, for several years I have not had a /dev/cdrom.  My workstation has
>>> an internal cd-rom drive, which gets mapped to /dev/hda, and an external
>> 
>> If you're using a recent kernel, it's probably udev which refuses to
>> process devices under the old ATA driver.
>> 
>> (I don't know if it *exactly* refuses, or if it's something else, but
>> the final result is what you see, no /dev/{cdrom,cdrw,...} link)
>
> The problem, as far as I could figure out, is that the ID_PATH that udev
> gets from the old ATA drivers is identical for everything on the same
> IDE controller; it basically gives the path to the PCI bus slot where
> the IDE controller is connected.  So udev has no way to differentiate
> between multiple drives connected to a single controller.  This is a
> change at some point from the previous behavior, which specified the IDE
> information as well.

So is this supposed to be a problem only if there is more than one PATA
device?

I never investigated this deeply enough, thanks for your explanation. I
ended up adding code to init scripts to create the links.


> You used to get something like:
>
> ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0"
>
> and now you get:
>
> ENV{ID_PATH}=="pci-0000:00:1f.1"
>
> Switching over to libata gives you:
>
> ENV{ID_PATH}=="pci-0000:00:1f.1-scsi-0:0:0:0"
>
> which returns everything to working order :)

I guess this means that if one gets some other way to match a drive (by
name? serial number?), it's possible to make a working rule.

>
> --Mike
>
>

-- 
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg

Re: [gentoo-user] Re: How to get /dev/cdrom

[Mike Edenfield]

On 1/12/2011 12:13 PM, Nuno J. Silva wrote:
> Mike Edenfield <kutulu@kutulu.org> writes:
> 
>> On 1/12/2011 11:31 AM, Nuno J. Silva wrote:
>>> Michael Sullivan <msulli1355@gmail.com> writes:
>>>
>>>> OK, for several years I have not had a /dev/cdrom.  My workstation has
>>>> an internal cd-rom drive, which gets mapped to /dev/hda, and an external
>>>
>>> If you're using a recent kernel, it's probably udev which refuses to
>>> process devices under the old ATA driver.
>>>
>>> (I don't know if it *exactly* refuses, or if it's something else, but
>>> the final result is what you see, no /dev/{cdrom,cdrw,...} link)
>>
>> The problem, as far as I could figure out, is that the ID_PATH that udev
>> gets from the old ATA drivers is identical for everything on the same
>> IDE controller; it basically gives the path to the PCI bus slot where
>> the IDE controller is connected.  So udev has no way to differentiate
>> between multiple drives connected to a single controller.  This is a
>> change at some point from the previous behavior, which specified the IDE
>> information as well.
> 
> So is this supposed to be a problem only if there is more than one PATA
> device?

I think it's a problem in theory since udev doesn't "know" how many PATA
devices are present.  But I'm not sure that's the only problem, its only
the most obvious change in behavior I could track down between "worked"
and "didn't work".

--Mike

Re: [gentoo-user] How to get /dev/cdrom

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

On Wed, 12 Jan 2011 11:08:58 -0600, Michael Sullivan wrote:

> I was still running linux-2.6.30-gentoo-r8.  I didn't even HAVE an
> option for ATA SFF support.  I'm going to build a v2.6.36-gentoo-r5
> kernel and pray that my ivtv stuff still works...

ATA_SFF was definitely in 2.6.30. Press / in menuconfig and search for
SFF, you may find you need to enable something else for it to show up.

-- 
Neil Bothwick

Don't put all your hypes in one home page.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How to get /dev/cdrom

[Paul Hartman]

On Wed, Jan 12, 2011 at 10:57 AM, Michael Sullivan <msulli1355@gmail.com> wrote:
> On Wed, 2011-01-12 at 10:28 -0600, Paul Hartman wrote:
>> On Wed, Jan 12, 2011 at 10:11 AM, Michael Sullivan <msulli1355@gmail.com> wrote:
>> > Why is it not being mapped correctly?  Is the rule above not correct?
>> > I've tried to read tutorials about writing udev rules, but the example
>> > rules in the tutorials look nothing like the above rules, and I didn't
>> > write those.  I think they were created when udev was installed...
>>
>> I guess you don't really have 6 optical drives installed? :)
>>
>> Some of those have -ide- in the device name, did you change form IDE
>> to ATA kernel driver at some point (like most everyone else did)?
>> Maybe that's why. New entries are generated for drives that don't
>> match existing rules, which is probably why you see your SOHC-5236K
>> down at cdrom5 as well...
>>
>> If you delete the file and reboot, it'll create a new one based on
>> your currently-installed hardware config. Hopefully that'll solve it
>> or at least clean up that file to the point where you can manage the
>> changes more easily.
>>
>
> I deleted /etc/udev/rules.d/70-persistent-cd.rules and rebooted the
> system.  The file is still gone, and still no /dev/cdrom:
> camille ~ # ls /etc/udev/rules.d/
> 10-zaptel.rules   70-bluetooth.rules   70-libsane.rules
> 90-hal.rules   hsf.rules
> 30-svgalib.rules  70-libgphoto2.rules  70-persistent-net.rules
> 99-btnx.rules
> camille ~ # ls /dev/cdrom*
> ls: cannot access /dev/cdrom*: No such file or directory
>
>
> What should I do now?

I saw from your other post that you're using an old kernel, maybe
you're using an old udev too. I'm using 164-r1 and
70-persistent-cd.rules is auto-generated by this rule:

/lib/udev/rules.d/75-cd-aliases-generator.rules

which really just runs /lib/udev/write_cd_rules script, you could also
try to run manually if that exists in your system.

Re: [gentoo-user] How to get /dev/cdrom

[Paul Hartman]

On Wed, Jan 12, 2011 at 11:08 AM, Michael Sullivan <msulli1355@gmail.com> wrote:
> I was still running linux-2.6.30-gentoo-r8.  I didn't even HAVE an
> option for ATA SFF support.  I'm going to build a v2.6.36-gentoo-r5
> kernel and pray that my ivtv stuff still works...

If you have any IDE devices you might want to read this short migration guide:

https://forums.gentoo.org/viewtopic-p-6362608.html#6362608