I am pretty deep into this now and operating at about 50% understanding. We have a Raspi 3B+ running Ubuntu 20.04 for Raspi. We have a Teensy 3.7. They are connected together with a USB cable. I know that the Teensy is getting power.

This is the rule that I am being told to use:

KERNEL=="ttyACM?", SUBSYSTEM=="tty", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0478", ATTRS{serial}=="000F0B8C", MODE="0666" SYMLINK+="linobase"

Not sure what udev rules do exactly

I have the feeling the the udev rule is not "matching" and that's why it is not creating the symlink. But I really am not at all sure. But honestly I don't really understand udev. I am just kind of plowing through with "common sense' which is not working for me.


I was also suspecting it might be the usb cable? As I understand it many usb cables are "power only". However, the problem didn't go away when I used a "known good" data USB cable.

Code 43?

There may be an esoteric problem known as the "Code 43" problem that is in play here - see pjrc.com/teensy/troubleshoot.html. Anyone know anything about it?

  • Can you describe a bit more detailed what actually happens?
    – PMF
    Jan 31, 2022 at 8:32

1 Answer 1


Traditional unix preassigned device numbers for every possible device at the time the kernel was compiled, and a script would then probe the system and create device files for devices that actually exist.

However, modern systems have several orders of magnitude more possible devices, and it is possible to connect more devices to the system than the original unix designs envisioned. However, the bit fields used to store the device numbers haven't grown, and even if they did, it wouldn't be big enough without being wasteful of memory and storage.

So the linux device system was redesigned to compensate for this by using dynamic device numbers that are assigned when the device is detected. The udev system was created to dynamically manage the /dev/ directory which is now in a ram disk and device nodes are created as needed using udev rules, especially for hot plug dynamic devices like USB.

The udev rule you specified works like this:

  • KERNEL=="ttyACM?" looks for the serial device that the teensy is assigned by the USB device driver when it is plugged in
  • SUBSYSTEM=="tty" filters for this type of device
  • ATTRS{idVendor}=="16c0", , ATTRS{idProduct}=="0478" filters for this device type, it matches "Teensy Halfkay Bootloader" in the USB ID database
  • ATTRS{serial}=="000F0B8C" filters for your exact device by serial number; if you have multiple identical devices, they should have different serial numbers, so you could have multiple udev rules that give each one a different symlink name (see below)
  • MODE="0666" tells udev to make the permissions rw-rw-rw rather than the default (I think) of rw------- so that any user can access the device
  • SYMLINK+="linobase" tells udev that after creating the device, it should also create a symlink /dev/linobase that points to the device file; this allows you to have a stable name to find your device, as the primary name would change depending on the order devices were plugged in.

After you save this in the correct udev config directory with the correct name, assuming there isn't an alphabetically prior entry that matches instead, udev should load this configuration.

However, the configuration will not be immediately effective. With USB, typically unplugging the device and plugging it back in is enough to re-trigger the udev rules. You can check by looking at system logs and checking if the named symlink is properly created.

If it is not, you should use lsusb to see if your device actually was detected (compare output of lsusb with and without the device plugged in), and if it is, you need to use the udev tools to dump out the device information and verify that the identifier numbers above are all correct without typos (especially the serial number).

If all the numbers match correctly, you will need to use the udev debug tools to determine why your rule is not being triggered.

If the device doesn't show up with lsusb (it may take a few seconds for the bootloader to time out and the device to initialize), and presuming that your USB cable is good, then there may be something wrong, including possibly bad code in the teensy, and you may need to reload the code or correct bugs in the code so that the teensy correctly initializes its end of the serial port. (Or, hopefully not, reflash the bootloader.)

  • 1
    Wow, this is the most useful, clear and actionable explanation I’ve ever seen in my googling and reading and posting about udev. If I could give you a tip or a triple thumbs up I would!!
    – pitosalas
    Jan 31, 2022 at 12:12
  • 1
    I've got a big pile of usb devices on my system, i got sick of hunting for them when they rearranged after every boot. There's a lot of good guildes online on how to debug and how to find the numbers, but very few that are short and clearly document what the udev entry does.
    – user10489
    Jan 31, 2022 at 12:25
  • 1
    If this fixes it for you, don't forget to accept it as an answer!
    – user10489
    Jan 31, 2022 at 12:32
  • 1
    I believe there is a default for every device type built into the driver and the device would be created even without udev running. I'm not sure why you'd want to access it in a way other than /dev so I don't know what you mean.
    – user10489
    Feb 3, 2022 at 2:44
  • 1
    udev will modify the device, although it could replace it. The += syntax adds another whatever it is. If the same device shows up with different settings, that's a device driver thing, not a udev thing. If you plug in a usb device, have a program open that device, and then unplug it, when you plug it back in, a new device will be created and the original will be left non-functional.
    – user10489
    Feb 3, 2022 at 23:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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