4

I have a very simple udev rule at /etc/udev/rules.d/sdcard.rules:

KERNEL=="mmcblk1", SUBSYSTEM=="block", SYMLINK+="sdCARD"

Problem is the symlink is not created for me automatically at boot. I have many other rules and all them work just fine at boot (my symlinks are created).

However, if I run this then the symlink IS created:

udevadm test /block/mmcblk1

What could be going on here? Why isn't it created at boot? Could the device not be available yet? How could I find that out?


Update One


Output of udevadm:

 looking at device '/block/mmcblk1':
    KERNEL=="mmcblk1"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{ro}=="0"
    ATTR{size}=="3862528"
    ATTR{stat}=="       9        0       74        0        1        0        8        0        0        0        0"
    ATTR{range}=="8"
    ATTR{discard_alignment}=="0"
    ATTR{force_ro}=="0"
    ATTR{ext_range}=="8"
    ATTR{alignment_offset}=="0"
    ATTR{inflight}=="       0        0"
    ATTR{removable}=="0"
    ATTR{capability}=="10"
  • What if you use last rule... something like: KERNEL=="mmcblk[0-9]", SYMLINK+="sdcard-%k", OPTIONS="last_rule" ? – don_crissti Apr 16 '15 at 18:16
  • @don_crissti Just tried it out, doesn't seem to make a difference... – dtmland Apr 16 '15 at 18:59
1

Rename the rules file to: /etc/udev/rules.d/99-sdcard.rules , possibly some rules are required to run before it.

  • Tested just now - didn't appear to make a difference. I am so stumped on this problem. – dtmland May 26 '15 at 19:46
  • @dtmland , Could I ask what hardware setup you are using? Could you post output of udevadm info --name=/block/mmcblk1 --attribute-walk? – user.dz May 26 '15 at 19:53
  • @dtmland, you run it with --attribute-walk I don't see any parent device. What's this hardware/embedded system ? – user.dz May 26 '15 at 20:11
  • 1
    Yes, I ran it with the walk attribute. I believe the mmcblk1 is the parent device? It's on unreleased SAMA5D3 based hardware. – dtmland May 26 '15 at 20:43
  • 2
    @dtmland , I think that block device is added too early before udevd can catch it. – user.dz May 26 '15 at 21:21
1

Check that

  1. the boot environment has udev enabled
  2. that the newly created udev rules are included in the Linux boot environment.

For example (#2) for Arch Linux requires $ mkinitpio -P to update the boot initramfs image.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.