Also wondering, if this isn't a kernel issue then why does
70-persistent-cd.rules get generated if it's missing under kernel 3.2.29,
but under 3.6.7 it does not?
On Sat, Nov 24, 2012 at 1:44 PM, Nelson <dim...@gmail.com> wrote:
> Using udevadm as you suggested yielded some interesting results. Under
> kernel 3.6.7 70-persistent-cd.rules does in fact get loaded, however
> ID_PATH is no longer exported, which is what 70-persistent-cd.rules uses to
> identify the DVD-ROM on my system. While I am able to get udev working
> properly with ENV{ID_SERIAL_SHORT}, I was wondering if the lack of ID_PATH
> is because of a turned off option in the kernel or the removal of it?
>
>
>
> On Sat, Nov 24, 2012 at 8:29 AM, Kay Sievers <k...@vrfy.org> wrote:
>
>> On Sat, Nov 24, 2012 at 8:55 AM, Nelson <dim...@gmail.com> wrote:
>> > While my issue is still with udev 182 and kernel 3.6.7, does
>> > 70-persistent-cd.rules even get USED at all if it was created beforehand
>> > with 183?
>>
>> Yes, it should still work. Just new devices would not be automatically
>> added.
>>
>> Newer udev versions dropped all persistent rule generators, we will
>> not create any system config from device hotplug handlers anymore. It
>> turned out to be the wrong thing and it created more problems than it
>> solved.
>>
>> Regarding the initial question, there are no known kernel changes
>> which would make these rules not work anymore. The only reports so far
>> are from people who somehow enabled IDE drivers (/dev/hda) instead of
>> libata (/dev/sr0), which will not work with the rules.
>>
>> You might want to check with:
>> udevadm test /sys/class/block/sr0
>> if it tells what's going wrong.
>>
>> Kay
>>
>
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
