Opened 16 years ago

Closed 16 years ago

#2125 closed task (fixed)

ALSA Utilities - syntax errors in 15-alsa.rules, and controlC* files are not put into /dev/snd.

Reported by: Bryan Kadzban Owned by: dnicholson@…
Priority: normal Milestone: 6.2.0
Component: BOOK Version: SVN
Severity: major Keywords: udev alsa


The 15-alsa.rules file created in current SVN BLFS ( has several of the same syntax error in it. All occurrences of this type of rule:

KERNEL="whatever", <whatever>

need to be changed to:

KERNEL=="whatever", <whatever>

(add an extra equal sign), otherwise udev-096 and above will complain when they try to load the rule. (And I do not believe the rule will actually be loaded, though I don't know for sure.)

Also, in the same file, the "controlC[0-9]*" device file(s) are not moved to the snd/ subdirectory like the rest of the Alsa devices are. This causes e.g. alsactl restore to fail with an error similar to "no sound cards exist", if no other rule moves the device node.

The standard LFS udev-config tarball has rules in 25-lfs.rules to move the controlC* devices, but CLFS's rules files do not. (Standard LFS udev-config has rules to move the rest of the devices that 15-alsa.rules moves, also, for whatever that's worth.) But I don't think BLFS should rely on LFS's rule overriding an incorrect device node placement in any case, I think the BLFS rules should be correct.

Also, the rule to match midiC0D0 (and friends) may be incorrect. Currently it matches "midiC[D0-9]*", but that will only match "midiC" followed by digits or D characters. (Assuming udev's matching is regex-based, which I'm not at all sure about; I thought it was glob-based. But whatever.) A correct pattern is probably "midi[CD0-9]", just like all the other patterns in the file.

Marking this bug "major" since with a current CLFS, and an unmodified 15-alsa.rules file, Alsa is unusable. (Or at least, the controlC* devices aren't where they need to be, and therefore volumes are never restored. There may be other problems also.) With LFS, it's only usable by accident (because all the incorrect rules here -- both the invalid-syntax ones, and the controlC* one -- are overridden by correct rules later, in 25-lfs.rules).

A correct 15-alsa.rules file creation could look something like this:

cat <<"EOF" >/etc/udev/rules.d/15-alsa.rules
# Give the audio group ownership of sound devices
SUBSYSTEM=="sound",       GROUP="audio"
SUBSYSTEM=="snd",         GROUP="audio"

# ALSA Devices
# When a sound device is detected, restore the volume settings
KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore %n"
KERNEL=="controlC[0-9]*",  NAME="snd/%k"
KERNEL=="hw[CD0-9]*",      NAME="snd/%k"
KERNEL=="pcm[CD0-9cp]*",   NAME="snd/%k"
KERNEL=="midi[CD0-9]*",    NAME="snd/%k"
KERNEL=="timer",           NAME="snd/%k"
KERNEL=="seq",             NAME="snd/%k"

Change History (7)

comment:1 by dnicholson@…, 16 years ago

Glad you opened a ticket, because this really needs to be fixed up.

  1. Testing equality with ==

Obviously, these should be fixed, and I don't know why they haven't already been.

  1. controlC[0-9]* not moved to snd/

That's intentional. It was decided a while back that all the node names for devices are decided in LFS udev-config. Even for things that aren't used in BLFS like device-mapper. So, really, the rest of the rules should be deleted because they're covered in the stock rules and shouldn't be changed without good reason. We really only want to add the group setting and alsactl stuff.

As for not working with CLFS, I don't know what to say. I hope they would follow the same convention of deciding all the node names in the base config (in fact, they already do, adding rules for pktcdvd, device-mapper, etc.) Possibly this is a special case where the alsa rules have been left out because they have been handled by BLFS and this can be straightened out easily.

And it brings up the topic made months ago that there should be a shared project to handle the udev rules. This should be done, but needs some manpower. I'll bring this up on list again soon.

  1. Pattern matching for midi

I really don't know what the names for the midi devices are supposed to be. Change looks fine to me, but I don't really know.

So, the BLFS 15-alsa.rules should probably be moved after the stock 25-lfs.rules and simply be:

# Give the audio group ownership of sound devices
SUBSYSTEM=="sound",       GROUP="audio"
SUBSYSTEM=="snd",         GROUP="audio"

# ALSA Devices
# When a sound device is detected, restore the volume settings
KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore %n"

At least, that's what I think.

comment:2 by Bryan Kadzban, 16 years ago

Yeah, it almost looks like CLFS just used the "default" udev rules. (That is, the ones that came in the udev package. Maybe they added a few files from various distros -- which also came from that package -- though, too. And maybe they wrote some of their own. Not sure.)

Anyway, it looks like CLFS 1.0.0-rc5 uses a new udev-cross-lfs tarball, too. (It uses 0.2, while I had 0.1.) This new tarball has a 55-sound.rules file in it, which does exactly what's needed (moves all the device nodes). So it looks like if I'd have used the current SVN CLFS, I may have been better off; looks like this is only an issue with 1.0.0-rc4 and perhaps earlier.

So never mind that then. Looks like changing 15-alsa.rules as you say (only keeping the GROUP="xxx" and RUN+="..." rules) should work fine for CLFS too.

As far as midi goes: If the device-movement rules are removed, it's not an issue, so don't bother. (At least, not in BLFS.) According to the udev(7) manpage, it's definitely not a regex pattern, but oh well.

comment:3 by DJ Lucas, 16 years ago

Owner: changed from blfs-book@… to DJ Lucas

comment:4 by DJ Lucas, 16 years ago

Status: newassigned

comment:5 by dnicholson@…, 16 years ago

Owner: changed from DJ Lucas to dnicholson@…
Status: assignednew

comment:6 by dnicholson@…, 16 years ago

Status: newassigned

comment:7 by dnicholson@…, 16 years ago

Resolution: fixed
Status: assignedclosed

Fixed in r6419.

Note: See TracTickets for help on using tickets.