Problems with udev - Slackware

This is a discussion on Problems with udev - Slackware ; Hi I'm running Slackware 12.0, kernel 2.6.21.5. I have a dvd and a cd drive. My problem is that the link /dev/cdrom intermittently points to /dev/hdd, i.e.: %~$ ls -l /dev/cdrom lrwxrwxrwx 1 root root 3 2008-01-08 07:13 /dev/cdrom -> ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: Problems with udev

  1. Problems with udev

    Hi

    I'm running Slackware 12.0, kernel 2.6.21.5. I have a dvd and a cd
    drive. My problem is that the link /dev/cdrom intermittently points
    to /dev/hdd, i.e.:

    %~$ ls -l /dev/cdrom
    lrwxrwxrwx 1 root root 3 2008-01-08 07:13 /dev/cdrom -> hdd

    rather than /dev/hdc.

    This is after I created the file:

    /etc/udev/rules.d/10-local.rules

    which contains:

    KERNEL=="hdc", SYMLINK="cdrom"

    Before I created this file, it constantly pointed to /dev/hdd. Now,
    it
    seems to alternate daily between hdc and hdd. When I do:

    udevtest /sys/block/hdd

    I get:

    .....

    update_link: found '/block/hdc' for 'cdrom'
    update_link: compare priority of '/block/hdc' 0 > 0
    update_link: found '/block/hdd' for 'cdrom'
    update_link: compare (our own) priority of '/block/hdd' 0 >= 0
    update_link: 'cdrom' with target 'hdd' has the highest priority 0,
    create it
    .....

    which seems to say that there is still some file trying to push /dev/
    hdd as
    the link from /dev/cdrom. One other confusing thing is that the
    timestamp
    in:

    lrwxrwxrwx 1 root root 3 2008-01-08 07:13 /dev/cdrom -> hdd

    for the created link is 07:13, and the computer was not on at this
    time.

    So can anyone tell me how to make the link with /dev/hdc permanent?
    Thanks.

  2. Re: Problems with udev

    On Jan 9, 1:46 pm, "Mr. Usenet" wrote:
    >

    ....
    > So can anyone tell me how to make the link with /dev/hdc permanent?
    > Thanks.


    If you *always* want your cdrom to point to /dev/hdc AND you do not
    need dynamic assignment of you cdrom device... then there is no need
    to use udev for this
    so remove *your* changes from /etc/udev/rules.d, and instead do the
    following:

    Make sure user.group of /dev/hdc is root.cdrom
    (ls -l /dev/hdc = brw-rw---- 1 root cdrom 22, 64 2008-01-09 05:58 /dev/
    hdc)

    Make a symlink /dev/cdrom -> /dev/hdc
    (ls -l /dev/cdrom = lrwxrwxrwx 1 root root 3 2008-01-09 05:58 /dev/
    cdrom -> hdc)

    In fstab uncomment the line (or add the line):
    /dev/cdrom /mnt/cdrom iso9660 noauto,user,ro 0 0

    This should do what you need.

  3. Re: Problems with udev

    toshiro wrote:
    > On Jan 9, 1:46 pm, "Mr. Usenet" wrote:
    > >

    > ...
    > > So can anyone tell me how to make the link with /dev/hdc permanent?
    > > Thanks.

    >
    > If you *always* want your cdrom to point to /dev/hdc AND you do not
    > need dynamic assignment of you cdrom device... then there is no need
    > to use udev for this
    > so remove *your* changes from /etc/udev/rules.d, and instead do the
    > following:
    >
    > Make sure user.group of /dev/hdc is root.cdrom
    > (ls -l /dev/hdc = brw-rw---- 1 root cdrom 22, 64 2008-01-09 05:58 /dev/
    > hdc)
    >
    > Make a symlink /dev/cdrom -> /dev/hdc
    > (ls -l /dev/cdrom = lrwxrwxrwx 1 root root 3 2008-01-09 05:58 /dev/
    > cdrom -> hdc)
    >
    > In fstab uncomment the line (or add the line):
    > /dev/cdrom /mnt/cdrom iso9660 noauto,user,ro 0 0
    >
    > This should do what you need.


    Thanks for the reply. I'm wondering though, if the above will work
    since
    the system was already set similar to what you have said. fstab has
    the
    lines you mention, and I get the following when I do:

    $ ls -l /dev/hdc
    brw-rw-rw- 1 root cdrom 22, 0 2008-01-10 01:08 /dev/hdc
    $ ls -l /dev/cdrom
    lrwxrwxrwx 1 root root 3 2008-01-10 01:08 /dev/cdrom -> hdc

    The only difference is the permissions on my /dev/hdc which is "brw-rw-
    rw-"
    rather than "brw-rw----". And if I remove rw from o, i.e.

    chmod o-rw /dev/hdc

    I'm worried I won't be able to use the cdrom writer.
    I can remove the rules I added to make things almost exactly like
    before, but I think it will just mean that /dev/cdrom will
    permanently point to /dev/hdd which was my initial problem.


  4. Re: Problems with udev

    "Mr. Usenet" writes:


    > So can anyone tell me how to make the link with /dev/hdc permanent?
    > Thanks.


    IMO, dump udev. How many times does one really add devices to their system?
    udev takes something trivial, adds a bunch of config files, makes it
    more complex, and then fails to work. Progression, backwards.


    --
    [** America, the police state **]
    Whoooose! What's that noise? Why, it's US citizen's
    rights, going down the toilet with Bush flushing.
    http://www.wired.com/politics/securi...007/08/wiretap
    http://www.hermes-press.com/police_state.htm

  5. Re: Problems with udev

    On 2008-01-10, toshiro wrote:
    > On Jan 9, 1:46 pm, "Mr. Usenet" wrote:
    >>

    > ...
    >> So can anyone tell me how to make the link with /dev/hdc permanent?
    >> Thanks.

    >
    > If you *always* want your cdrom to point to /dev/hdc AND you do not
    > need dynamic assignment of you cdrom device... then there is no need
    > to use udev for this
    > so remove *your* changes from /etc/udev/rules.d, and instead do the
    > following:
    >
    > Make sure user.group of /dev/hdc is root.cdrom
    > (ls -l /dev/hdc = brw-rw---- 1 root cdrom 22, 64 2008-01-09 05:58 /dev/
    > hdc)
    >
    > Make a symlink /dev/cdrom -> /dev/hdc
    > (ls -l /dev/cdrom = lrwxrwxrwx 1 root root 3 2008-01-09 05:58 /dev/
    > cdrom -> hdc)
    >
    > In fstab uncomment the line (or add the line):
    > /dev/cdrom /mnt/cdrom iso9660 noauto,user,ro 0 0
    >
    > This should do what you need.



    That's great until the OP reboots - it's not going to persist.
    The proper way is to handle it with udev.
    I'll post that in just a moment to the original post.

    -RW

  6. Re: Problems with udev

    ["Followup-To:" header set to alt.os.linux.slackware.]
    On 2008-01-09, Mr. Usenet wrote:
    > Hi
    >
    > I'm running Slackware 12.0, kernel 2.6.21.5. I have a dvd and a cd
    > drive. My problem is that the link /dev/cdrom intermittently points
    > to /dev/hdd, i.e.:
    >
    > %~$ ls -l /dev/cdrom
    > lrwxrwxrwx 1 root root 3 2008-01-08 07:13 /dev/cdrom -> hdd
    >
    > rather than /dev/hdc.
    >
    > This is after I created the file:
    >
    > /etc/udev/rules.d/10-local.rules
    >
    > which contains:
    >
    > KERNEL=="hdc", SYMLINK="cdrom"
    >
    > Before I created this file, it constantly pointed to /dev/hdd. Now,
    > it
    > seems to alternate daily between hdc and hdd. When I do:
    >
    > udevtest /sys/block/hdd
    >
    > I get:
    >
    > ....
    >
    > update_link: found '/block/hdc' for 'cdrom'
    > update_link: compare priority of '/block/hdc' 0 > 0
    > update_link: found '/block/hdd' for 'cdrom'
    > update_link: compare (our own) priority of '/block/hdd' 0 >= 0
    > update_link: 'cdrom' with target 'hdd' has the highest priority 0,
    > create it
    > ....
    >
    > which seems to say that there is still some file trying to push /dev/
    > hdd as
    > the link from /dev/cdrom. One other confusing thing is that the
    > timestamp
    > in:
    >
    > lrwxrwxrwx 1 root root 3 2008-01-08 07:13 /dev/cdrom -> hdd
    >
    > for the created link is 07:13, and the computer was not on at this
    > time.
    >
    > So can anyone tell me how to make the link with /dev/hdc permanent?
    > Thanks.



    See /etc/udev/rules.d/75-optical-devices.rules
    Edit the generated rules in there to make the links point where you
    want them to point. Also remove your custom rule - it's not needed.
    The conflict you were seeing is/was the result of your custom rule
    in conjunction with the generated rules.

    -RW

  7. Re: Problems with udev

    jayjwa wrote:
    > IMO, dump udev. How many times does one really add devices to their system?


    Every time you insert an USB stick? Every time you connect something else
    by USB? IMHO udev is a good replacement for the old hotplug. Also fixed
    devices like network cards are handled well. With udev it is easy to make
    sure that a card with a special mac address always gets named eth1.

    > udev takes something trivial, adds a bunch of config files, makes it
    > more complex, and then fails to work. Progression, backwards.


    For me it was rather easy to understand how to edit udev files. I have
    also been able to edit some hald files, but I think that the hald files
    are more messy.

    regards Henrik
    --
    The address in the header is only to prevent spam. My real address is:
    hc1(at)poolhem.se Examples of addresses which go to spammers:
    root@localhost postmaster@localhost


  8. Re: Problems with udev

    On Jan 10, 1:47 pm, "Mr. Usenet" wrote:
    > toshiro wrote:
    > > On Jan 9, 1:46 pm, "Mr. Usenet" wrote:

    >
    > > ...
    > > > So can anyone tell me how to make the link with /dev/hdc permanent?
    > > > Thanks.

    >
    > > If you *always* want your cdrom to point to /dev/hdc AND you do not
    > > need dynamic assignment of you cdrom device... then there is no need
    > > to use udev for this
    > > so remove *your* changes from /etc/udev/rules.d, and instead do the
    > > following:

    >
    > > Make sure user.group of /dev/hdc is root.cdrom
    > > (ls -l /dev/hdc = brw-rw---- 1 root cdrom 22, 64 2008-01-09 05:58 /dev/
    > > hdc)

    >
    > > Make a symlink /dev/cdrom -> /dev/hdc
    > > (ls -l /dev/cdrom = lrwxrwxrwx 1 root root 3 2008-01-09 05:58 /dev/
    > > cdrom -> hdc)

    >
    > > In fstab uncomment the line (or add the line):
    > > /dev/cdrom /mnt/cdrom iso9660 noauto,user,ro 0 0

    >
    > > This should do what you need.

    >
    > Thanks for the reply. I'm wondering though, if the above will work
    > since
    > the system was already set similar to what you have said. fstab has
    > the
    > lines you mention, and I get the following when I do:
    >
    > $ ls -l /dev/hdc
    > brw-rw-rw- 1 root cdrom 22, 0 2008-01-10 01:08 /dev/hdc
    > $ ls -l /dev/cdrom
    > lrwxrwxrwx 1 root root 3 2008-01-10 01:08 /dev/cdrom -> hdc
    >
    > The only difference is the permissions on my /dev/hdc which is "brw-rw-
    > rw-"
    > rather than "brw-rw----". And if I remove rw from o, i.e.
    >
    > chmod o-rw /dev/hdc
    >


    Hang on you may have misunderstood - your hdc perms are correct,
    they should be brw-rw-rw and the ownership should root:cdrom.
    As a normal user you should belong to the cdrom group by default. If
    not you can add yourself.

    > I'm worried I won't be able to use the cdrom writer.
    > I can remove the rules I added to make things almost exactly like
    > before, but I think it will just mean that /dev/cdrom will
    > permanently point to /dev/hdd which was my initial problem.


    You want the cdrom to point to /dev/hdc right?
    So make the symlink yourself as I stated earlier and udev will not
    change it.

    I had a similar problem when I first started using udev+hal+messagebus
    with Slack12.
    So I simply uncommented the cdrom line in fstab and made the following
    link /dev/cdrom -> /dev/hdc (in my case for CD/RW), and it just worked
    fine after that.
    Programs like kplayer, k3b, xmms, etc work fine, also KDE (which auto
    mounts
    to /media/cdrom/.... work OK)

    The advice of other people about editing udev rules is correct as
    well, but my CD devices are
    *screwed* into my desktop, laptop, whatever - I do not plug them in
    and out at all. So why should I use udev to manage them. Things like
    cameras & mem sticks are good candidates for udev but NOT an internal
    DVD. For me using fstab and /dev/cdrom->/dev/hdc works fine.

    It is your choice which way to go but try the fstab + symlink method,
    it is trivial and
    you can always rollback your changes in a minute.

    And let us know the results. Good luck.

  9. Re: Problems with udev

    On Jan 11, 12:20 am, Robby Workman wrote:
    > On 2008-01-10, toshiro wrote:
    >
    >
    >
    > > On Jan 9, 1:46 pm, "Mr. Usenet" wrote:

    >
    > > ...
    > >> So can anyone tell me how to make the link with /dev/hdc permanent?
    > >> Thanks.

    >
    > > If you *always* want your cdrom to point to /dev/hdc AND you do not
    > > need dynamic assignment of you cdrom device... then there is no need
    > > to use udev for this
    > > so remove *your* changes from /etc/udev/rules.d, and instead do the
    > > following:

    >
    > > Make sure user.group of /dev/hdc is root.cdrom
    > > (ls -l /dev/hdc = brw-rw---- 1 root cdrom 22, 64 2008-01-09 05:58 /dev/
    > > hdc)

    >
    > > Make a symlink /dev/cdrom -> /dev/hdc
    > > (ls -l /dev/cdrom = lrwxrwxrwx 1 root root 3 2008-01-09 05:58 /dev/
    > > cdrom -> hdc)

    >
    > > In fstab uncomment the line (or add the line):
    > > /dev/cdrom /mnt/cdrom iso9660 noauto,user,ro 0 0

    >
    > > This should do what you need.

    >
    > That's great until the OP reboots - it's not going to persist.
    > The proper way is to handle it with udev.


    There is no proper way.

    One has the choice of using udev or not...and you can choose to use
    udev for all devices or just some.

    I'm not sure why you say that it does not persist. I did that change a
    long time ago - did it once - and it has been working ever since. I
    have never had to change or redo it.

    It is persistent because udev *does not* mess with existing
    symlinks...
    Try it yourself...
    This is working for me on three machines:
    desktop: with slack-current, CDRW, DVDRW
    laptop with slack-12.0, CDRW
    laptop with slack-current, DVDRW

  10. Re: Problems with udev

    On 2008-01-11, toshiro wrote:
    > On Jan 11, 12:20 am, Robby Workman wrote:
    >> On 2008-01-10, toshiro wrote:
    >>
    >> > Make sure user.group of /dev/hdc is root.cdrom
    >> > (ls -l /dev/hdc = brw-rw---- 1 root cdrom 22, 64 2008-01-09 05:58 /dev/
    >> > hdc)

    >>
    >> > Make a symlink /dev/cdrom -> /dev/hdc
    >> > (ls -l /dev/cdrom = lrwxrwxrwx 1 root root 3 2008-01-09 05:58 /dev/
    >> > cdrom -> hdc)

    >>
    >> > In fstab uncomment the line (or add the line):
    >> > /dev/cdrom /mnt/cdrom iso9660 noauto,user,ro 0 0

    >>
    >> > This should do what you need.

    >>
    >> That's great until the OP reboots - it's not going to persist.
    >> The proper way is to handle it with udev.

    >
    > There is no proper way.
    >
    > One has the choice of using udev or not...and you can choose to use
    > udev for all devices or just some.



    If you're using udev *at all* then you're using it for all devices.
    Yes, you can certainly disable udev completely, but it's not recommended
    or supported. Therefore, the proper way *is* with udev, even if it's
    not *your* preferred way.


    > I'm not sure why you say that it does not persist. I did that change a
    > long time ago - did it once - and it has been working ever since. I
    > have never had to change or redo it.
    >
    > It is persistent because udev *does not* mess with existing
    > symlinks...
    > Try it yourself...



    If you're using udev, and you create a symlink in /dev, it most certainly
    will NOT persist across a reboot.

    -RW

  11. Re: Problems with udev

    Thanks again for everyone's reply.


    On Fri, 11 Jan 2008 07:39:56, toshiro wrote:
    >You want the cdrom to point to /dev/hdc right?
    >So make the symlink yourself as I stated earlier and udev will not
    >change it.


    I did make this link myself initially before I knew anything about
    udev, but it reverted on the next boot. But not after I learned about
    udev and made all the rules. So I just did this as root and will
    see how it works.

    >And let us know the results. Good luck.


    Thanks, although if the trick was to make the symlink after
    creating rules than before, then this isn't very intuitive.

    On Thu, 10 Jan 2008 20:15:33, jayjwa wrote:
    >IMO, dump udev. How many times does one really add devices to their system?
    >udev takes something trivial, adds a bunch of config files, makes it
    >more complex, and then fails to work. Progression, backwards.


    I admit this is the way I feel too. As a user of Slackware, many
    times
    these attempts to automate configuration usually leads to frustration
    for me, especially since I don't mind manually handling the mounting
    of
    hardware. I remember when setting up a printer first meant
    configuring
    "printcap", then they added "modules.conf", and now CUPS. Sound
    started
    with ISAPNP, then "sndconfig", then they added "modules.conf", and now
    it's "alsaconf". Each time, hours of hard fought knowledge went out
    the window as I struggled with the new system that often still had a
    lot of kinks. I'm an 10+ year user of Linux, and if I get exasperated
    by the changes, what will this mean to non-Unix newbies.

    But I guess the point of the changes were so that new users wouldn't
    have to struggle with configuration, and since every new version of a
    distribution will end up using the new utilities, I've decided just to
    go along.

    On Fri, 11 Jan 2008 05:22:37, Robby Workman wrote:
    >See /etc/udev/rules.d/75-optical-devices.rules
    >Edit the generated rules in there to make the links point where you
    >want them to point. Also remove your custom rule - it's not needed.
    >The conflict you were seeing is/was the result of your custom rule
    >in conjunction with the generated rules.


    I've taken a look but I couldn't figure out what to do except maybe
    comment out the line:

    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-1:1",
    SYMLINK+="cdrom"

    I tried tracing this to /lib/udev/cdrom-symlinks.sh, but I can't see
    anything about "hdd" or "hdc". My online reading of:

    http://reactivated.net/writing_udev_rules.html

    didn't help much either, since it seems they thought that
    my custom rules would have been enough.

    On Fri, 11 Jan 2008 08:27:35, Henrik Carlqvist wrote:
    >Every time you insert an USB stick? Every time you connect something else
    >by USB? IMHO udev is a good replacement for the old hotplug. Also fixed
    >devices like network cards are handled well. With udev it is easy to make
    >sure that a card with a special mac address always gets named eth1.


    I admit, my USB flash drive gets detected pretty easily.


  12. Re: Problems with udev

    ["Followup-To:" header set to alt.os.linux.slackware.]
    On 2008-01-11, Mr. Usenet wrote:
    >
    > I admit this is the way I feel too. As a user of Slackware, many
    > times
    > these attempts to automate configuration usually leads to frustration
    > for me, especially since I don't mind manually handling the mounting
    > of
    > hardware. I remember when setting up a printer first meant
    > configuring
    > "printcap", then they added "modules.conf", and now CUPS. Sound
    > started
    > with ISAPNP, then "sndconfig", then they added "modules.conf", and now
    > it's "alsaconf". Each time, hours of hard fought knowledge went out
    > the window as I struggled with the new system that often still had a
    > lot of kinks. I'm an 10+ year user of Linux, and if I get exasperated
    > by the changes, what will this mean to non-Unix newbies.
    >
    > But I guess the point of the changes were so that new users wouldn't
    > have to struggle with configuration, and since every new version of a
    > distribution will end up using the new utilities, I've decided just to
    > go along.



    While I admit that sometimes there are kinks in the "new" ways,
    the idea behind them is indeed to make the stuff "just work" for
    all users (not just new users).


    > On Fri, 11 Jan 2008 05:22:37, Robby Workman wrote:
    >>See /etc/udev/rules.d/75-optical-devices.rules
    >>Edit the generated rules in there to make the links point where you
    >>want them to point. Also remove your custom rule - it's not needed.
    >>The conflict you were seeing is/was the result of your custom rule
    >>in conjunction with the generated rules.

    >
    > I've taken a look but I couldn't figure out what to do except maybe
    > comment out the line:
    >
    > ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-1:1",
    > SYMLINK+="cdrom"



    Okay, here's what the autogenerated rules put in my 75-optical-devices.rules
    file:

    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdrom0"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdrom"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="dvd0"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="dvd"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdr0"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdr"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdrw0"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdrw"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdwriter0"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdwriter"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="writer"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="cdrom1"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvd1"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvdrw1"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvdrw"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvdwriter1"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvdwriter"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="cdr1"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="cdrw1"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="cdwriter1"

    Since I don't care about all of the "extra" links, here's what I do to that
    file:

    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdrom"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvd"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="cdwriter"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvdwriter"
    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="writer"

    This is because my first drive (at /dev/hda) is a cd writer but only can
    read dvds, and my second drive can write both cds and dvds, and I use the
    second one for most (if not all) writing tasks...

    You can use "trial and error" to find which path points to which actual
    device node, or udevinfo(8) should be helpful.

    -RW

  13. Re: Problems with udev


    On Wed, 9 Jan 2008 10:46:09 Robby Workman wrote:
    > ["Followup-To:" header set to alt.os.linux.slackware.]
    > On 2008-01-11, Mr. Usenet wrote:
    > >



    >Okay, here's what the autogenerated rules put in my 75-optical-devices.rules
    >file:
    >
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdrom0"
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdrom"
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="dvd0"
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="dvd"

    ......
    >Since I don't care about all of the "extra" links, here's what I do to that
    >file:
    >
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK+="cdrom"
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvd"
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="cdwriter"
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="dvdwriter"
    >ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:1", SYMLINK+="writer"
    >
    >This is because my first drive (at /dev/hda) is a cd writer but only can
    >read dvds, and my second drive can write both cds and dvds, and I use the
    >second one for most (if not all) writing tasks...
    >

    I'll try changing:

    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-1:1", SYMLINK
    +="cdrom"

    to

    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0", SYMLINK
    +="cdrom"

    based on your example.

    >You can use "trial and error" to find which path points to which actual
    >device node, or udevinfo(8) should be helpful.


    Doing:

    %udevinfo -q symlink -n /dev/hdd
    disk/by-path/pci-0000:00:1f.1-ide-1:1 cdrom0 cdrom dvd0 dvd

    which probably makes sense, so I hope the change above will do the
    trick.

    Thanks for the reply. This is what I'll do next if my manual symlink
    doesn't survive.


  14. Re: Problems with udev

    Henrik Carlqvist writes:

    >> IMO, dump udev. How many times does one really add devices to their system?

    >
    > Every time you insert an USB stick? Every time you connect something else
    > by USB? IMHO udev is a good replacement for the old hotplug. Also fixed
    > devices like network cards are handled well. With udev it is easy to make
    > sure that a card with a special mac address always gets named eth1.


    OK, I should've said this better: how many times does one initially
    add devices to their system? I don't have to re-make the device files
    every time I plug/unplug, for example, my USB flash drive, ACM modem,
    PSP/SanDisk. The device file is just a window to what's there (or
    not).

    Actually, if udev removes and re-creates device files each and every
    time a device is pulled or plugged in, it's likely slower because the
    act of deletion and creation along with any processing of the program
    itself, takes time.

    There seems to be two hotplugs floating around too. I see Linux
    systems where the users talk about editing files; this would be the
    script one. Then there's one with nothing to edit, which is the one I
    have and like.

    > For me it was rather easy to understand how to edit udev files. I have
    > also been able to edit some hald files, but I think that the hald files
    > are more messy.


    I'm sure it's possible, but with so many other config files and things
    to wrestle with, why make something that's simple and already works
    more differicult?

    --
    [** America, the police state **]
    Whoooose! What's that noise? Why, it's US citizen's
    rights, going down the toilet with Bush flushing.
    http://www.wired.com/politics/securi...007/08/wiretap
    http://www.hermes-press.com/police_state.htm

  15. Re: Problems with udev

    jayjwa wrote:
    > Henrik Carlqvist writes:
    >
    >>> IMO, dump udev. How many times does one really add devices to their system?

    >> Every time you insert an USB stick? Every time you connect something else
    >> by USB? IMHO udev is a good replacement for the old hotplug. Also fixed
    >> devices like network cards are handled well. With udev it is easy to make
    >> sure that a card with a special mac address always gets named eth1.

    >
    > OK, I should've said this better: how many times does one initially
    > add devices to their system? I don't have to re-make the device files
    > every time I plug/unplug, for example, my USB flash drive, ACM modem,
    > PSP/SanDisk. The device file is just a window to what's there (or
    > not).


    You point is that in your case, you have intentionally taken
    something that was inherently designed to be pluggable and want
    to make it static... and as mentioned, there are many things that
    can be keyed off of to create persistent names.

    >
    > Actually, if udev removes and re-creates device files each and every
    > time a device is pulled or plugged in, it's likely slower because the
    > act of deletion and creation along with any processing of the program
    > itself, takes time.


    Sure. Obviously, since the device is inherently non-static, there
    is a dynamic piece to it. And this CAN get in the way if the assumption
    is made that the device is always present. You may well have to thwart
    the system a bit and create a static device file (like the old days).
    However, there are a lot of variables... so even this might not
    work (floating buses).

    >
    > There seems to be two hotplugs floating around too. I see Linux
    > systems where the users talk about editing files; this would be the
    > script one. Then there's one with nothing to edit, which is the one I
    > have and like.


    ???

    I don't edit any files and my device hotplugs and mounts at the
    same location everytime since the volume or device name is used
    for the mountpoint.

    Maybe you simply needs some kind of volume name set on the device (?).

    >
    >> For me it was rather easy to understand how to edit udev files. I have
    >> also been able to edit some hald files, but I think that the hald files
    >> are more messy.

    >
    > I'm sure it's possible, but with so many other config files and things
    > to wrestle with, why make something that's simple and already works
    > more differicult?
    >


    Uh... it didn't work. You "think" it worked because it happened to
    work in your particular case. While it is true that most people
    do define things only in the way that it relates to themselves, it's
    probably more useful to create a definition that everyone can use.


  16. Re: Problems with udev

    jayjwa wrote:
    > OK, I should've said this better: how many times does one initially
    > add devices to their system? I don't have to re-make the device files
    > every time I plug/unplug, for example, my USB flash drive, ACM modem,
    > PSP/SanDisk. The device file is just a window to what's there (or
    > not).


    Yes, but still I think it is nice to only have device files for present
    hardware. Also Slackware 12 with udev and hald is a lot easier to maintain
    for me which have many machines with many users without root privilegies.

    Some users want to be able to use USB sticks. On Slackware 9.1 I had to
    add a line in /etc/fstab looking something like this:

    /dev/sda1 /mnt/usbstick auto noauto,user,ro 0 0

    Then I could instruct the user to do "mount /mnt/usbstick" or help the
    user to create an icon on the KDE desktop that did this. However, things
    start to get messy when someone has more than one stick. If a different
    stick from a different brand is inserted it might not be named /dev/sda
    even if the other stick is removed first. If both sticks are inserted at
    the same time they will for sure have different names. I could have a
    number of lines for usb sticks in fstab, but that was rather confusing for
    the users.

    > I'm sure it's possible, but with so many other config files and things
    > to wrestle with, why make something that's simple and already works more
    > differicult?


    The udev and hald thing didn't work flawlessly out of the box after a
    Slackware 12 installation. However, ater some customizing it really works
    great! For me any user is now able to insert any number of USB sticks and
    for each new stick inserted they will get a KDE dialog asking them if they
    want to open the stick in a new window. Users using xfce will also have
    gui access to the stick. No more messy lines in fstab, no more trouble
    with different USB sticks, no more mount commands at command prompt for
    the users.

    From the users point of view things has become a lot more simple.

    regards Henrik
    --
    The address in the header is only to prevent spam. My real address is:
    hc1(at)poolhem.se Examples of addresses which go to spammers:
    root@localhost postmaster@localhost


  17. Re: Problems with udev

    On 2008-01-14, Henrik Carlqvist wrote:

    > Slackware 12 installation. However, ater some customizing it really works
    > great! For me any user is now able to insert any number of USB sticks and
    > for each new stick inserted they will get a KDE dialog asking them if they
    > want to open the stick in a new window. Users using xfce will also have
    > gui access to the stick. No more messy lines in fstab, no more trouble
    > with different USB sticks, no more mount commands at command prompt for
    > the users.


    Are you going to share this amazing "customizing" feat. I'd be mighty
    grateful.

    nb

  18. Re: Problems with udev

    notbob wrote:
    > Are you going to share this amazing "customizing" feat. I'd be mighty
    > grateful.


    In fact, I found the soluiton in this group, but here we go again:

    http://groups.google.com/group/alt.o...982caf947eee4e

    regards Henrik
    --
    The address in the header is only to prevent spam. My real address is:
    hc1(at)poolhem.se Examples of addresses which go to spammers:
    root@localhost postmaster@localhost


  19. Re: Problems with udev

    On 2008-01-15, Henrik Carlqvist wrote:
    > notbob wrote:
    >> Are you going to share this amazing "customizing" feat. I'd be mighty
    >> grateful.

    >
    > In fact, I found the soluiton in this group, but here we go again:
    >
    > http://groups.google.com/group/alt.o...982caf947eee4e


    Which tinyurls to this:http://tinyurl.com/2khb2f

    thank you
    nb

  20. Final report was Re: Problems with udev


    Here is a summary of my final results in trying to make /dev/cdrom
    always point to /dev/hdc.

    It looks like the only thing that will work for me is to change
    the lines in:

    /etc/udev/rules.d/75-optical-devices.rules

    from:

    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-1:1",
    SYMLINK +="cdrom"

    to

    ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.1-ide-0:0",
    SYMLINK +="cdrom"

    So I recommend setting the link first in /dev/

    %rm /dev/cdrom
    %ln -sf /dev/hdc /dev/cdrom

    and then making the change above.

    Everything else I did as mentioned in the previous posts resulted in
    it being
    occasionally overwritten by udev on the next boot up to /dev/hdd.

    I still don't understand the behavior of udev or what the numbers
    above mean,
    but everything seems to work, so ...

    Anyway, thanks for all who replied so that I could solve this problem.

+ Reply to Thread
Page 1 of 2 1 2 LastLast