Possible bad interaction of udev rules for duplicate devices

[alexander@…]

Since I have never built LFS-SVN > 6.2, the information below should be treated as unconfirmed.

It seems that LFS-SVN installs udev-103 with extras/rule_generator unconditionally enabled. This installs the stock rule generators and their udev rules. Later in the book, on the "Creating Custom Symlinks to Devices" and "Configuring the network Script" pages, ther reader is told to write his own udev rules for CD-ROM drives and network cards. The problem is that these two approaches conflict, and only one of them should be enabled on a given system.

[bryan@linuxfromscratch.org]

I think you're right, and I think this was even discussed back when the decision to start installing the rule_generator stuff was made. Maybe not though.

Either way, fixed in r7853.

[alexander@…]

Not fixed.

• The conflict with CD-ROMs is still in the book.
• Even if MAC-based rules are used, udev automagic overrides hand-written rules.

And in fact it needs discussion whether we really want the user to write his own rules manually.

[bryan@linuxfromscratch.org]

When a new NIC is added, the write_net_rules script can generate a collision with names, because it's hardcoded to only lock and check 70-persistent-net.rules. But it won't be called if the device already has a NAME assigned, so the user's rules file won't be overridden. We should, however, rename 26-network.rules to 70-persistent-net.rules, to avoid that collision.

And I did forget about CD-ROMs, but it shouldn't be too hard to fix that -- we could maybe just remove most of section 7.12.1 and call it good. The only issue would be that rule_generator's CD aliases stuff is currently bus-position only; whether that's acceptable should probably be discussed on -dev. The other option would be to set ENV{GENERATED}="1" in the rule that we tell the user to generate, and (likewise) use 70-persistent-cd.rules to avoid symlink-number collisions.

As for the user writing their own rules versus running "write_net_rules all_interfaces": I think running write_net_rules is probably better, as it will keep working if the rules change. But I'd like to add by-path support to the write_net_rules script before doing that, so for the moment, I'd say we should just rename the created rules file to avoid the collision.

If we go with only write_cd_aliases, then the fact that we don't generate the CD symlinks rules files in chapter 7 won't matter, because the symlinks won't be needed until after the user reboots. They can build BLFS (and even run a lot of it) from inside chroot, but that's not exactly following the books -- and even if they do that, the book says to bind-mount the host's /dev into the chroot, so they'll have the host's symlinks already.

Sound good?

[dnicholson@…]

Moving the rules to 70-* definitely seems like the right thing to do if the scripts expect that name. And I would agree that it's better to use the upstream provided scripts and only suggest manually written rules as a last resort.

I haven't looked at the scripts really, so I don't know exactly how these would interact. ENV{GENERATED}="1" is added by the scripts, correct? In that case, telling users to add this to their rules seems like a dirty thing to do.

It seems like removing 7.12.1 is the right way to go and let write_cd_aliases do its thing. However, it might be nice to leave some of the info about finding your CD drive in case you want to make a symlink like /dev/samsung or something. Just not something that would collide with the script aliases.

[bryan@linuxfromscratch.org]

ENV{GENERATED}="1" is added by the scripts, correct?

Only for CD symlinks (not NIC rules), but yes.

telling users to add this to their rules seems like a dirty thing to do.

True, but this variable is the only thing that tells 75-cd-aliases-generator.rules to skip running write_cd_rules for a device. So if the user doesn't add that, then their rule will be overridden by write_cd_rules. It's probably a poor choice of name for the environment variable (GENERATED_CD_RULE_EXISTS sounds better to me), but it's what upstream is using.

I'll see if I can get something together for discussion on -dev for some of this. In the meantime, I've committed r7854 to use 70-* and add ENV{GENERATED}, to get at least most of it correct, for the time being.

[Matthew Burgess]

Bryan, could you provide a status update on this ticket please? Where are we now and what issues still remain to be sorted out?

[bryan@linuxfromscratch.org]

I've temporarily worked around most of the issues, so people following the book shouldn't have problems. But the book still isn't quite the way I'd like it.

I'd like full support for both by-mac and by-path in the NIC script, and full support for both by-id and by-path in the CD script. The choice would be made based on an argument given to the scripts.

Upstream support for the latter exists since udev-104; support for the former does not exist upstream yet. If we want to pull in my patch to add by-path to the NIC script, that's fine, but I'd like to float it on linux-hotplug-devel at least once more. (Of course that means I need to actually *do* that... hopefully tomorrow. I'll commit it to the patches repo tomorrow too, just in case -- barring anything unforseen.)

Then I'd like to rewrite some of the chapter07 files to explain the limitations of both types of approach a bit better, and let the user choose which to use, for both CDs and NICs. (They'll have to modify the 75-*.rules file, which can be done with a sed.)

Last, I still have a flag set somewhere (maybe there's a ticket for it?) that we should call "write_udev_rules all_interfaces" to pre-generate the rules files for NICs, instead of having the user write them. The CD rules don't need to run or generated until after booting the new system, because the symlinks should exist on the host, and the host's /dev is still bind-mounted. But the NICs need to be given names before the network bootscript runs, because the user needs to create the right files in /etc/sysconfig/network-devices. That should be done regardless of the state of the NIC by-path patch.

I think that's it for the persistent-rule-generator changes that I'd like to see, at least. (And yes, the scope there is wider than just this ticket; in a strict sense, this ticket should probably be closed, since there's no outright problem. But we're not doing it right yet, either.)

[bryan@linuxfromscratch.org]

​http://marc.theaimsgroup.com/?t=117141229000004&r=1&w=2

See the second message. Basically, path-based persistence for NICs doesn't work at all for USB (or other removable) NICs. It can't -- whenever the NIC is plugged into a different port, its physical path changes. It'd probably work OK for PCI/PCIe cards, but even then, it's only useful if the card is in a slot, not if it's built into the motherboard.

So the question is, is it worth keeping the by-path persistence option in the book for NICs? If so, I can commit the patch to patches, with a URL to that thread. But given how it's going to break on a (probably) large number of machines, I don't think it's worth it, unless maybe we specifically say "this is probably only useful if your NIC is a plug-in PCI or PCI-Express card, and you plan on putting a different NIC in its slot it if it dies". I'm guessing that's a fairly low number of potential users.

I still want to modify the chapter 7 text, though; as it is, it's not very clear why you'd want to choose one form of persistence over the other. (That's true for both CDs and NICs, but for NICs it can easily be argued that we should remove the by-path persistence option altogether. So I'll wait a bit for any comments on that, but I'd like to modify 7.12.1 fairly soon.)

[Matthew Burgess]

Thanks for tackling this Bryan!

Given the generally low number of situations that by-path persistence would actually be useful for I'd say not to bother with it. It may be worth mentioning why by-path persistence isn't suitable for NICs (or more generally any device on the USB, PCMCIA or firewire buses, I guess). Actually, I remember a discussion some time ago about a proposal to have the kernel probe devices in parallel during bootup. If that happens, I'm not sure that by-path persistence will be suitable for anything, right?

So, let's not bother patching Udev, we'll describe by-path and by-id for CD drives. We'll describe by-mac for network interfaces.

It'd be nice if we could get the fact that one shouldn't use by-path persistence on USB and other such easily hotpluggable buses into a warning box, as I believe it warrants one. I can't see a way of rearranging the text so that it flows properly though!

[dnicholson@…]

Replying to matthew@linuxfromscratch.org:

So, let's not bother patching Udev, we'll describe by-path and by-id for CD drives. We'll describe by-mac for network interfaces.

Wouldn't the same issue arise on a USB cdrom drive, for example?

It'd be nice if we could get the fact that one shouldn't use by-path persistence on USB and other such easily hotpluggable buses into a warning box, as I believe it warrants one. I can't see a way of rearranging the text so that it flows properly though!

I think the warning needs to be there if we want to keep by-path rules in the book. Maybe I'm wrong, though. My understanding of kernel devices and sysfs is subpar at best.

[bryan@linuxfromscratch.org]

Replying to matthew@linuxfromscratch.org:

Actually, I remember a discussion some time ago about a proposal to have the kernel probe devices in parallel during bootup. If that happens, I'm not sure that by-path persistence will be suitable for anything, right?

Not exactly, I don't think. Parallel device probing is done in 2.6.19 and above, in any case.

But I don't think the numbers in the by-path IDs match the order that the devices were discovered in. I think they're supposed to match bus/slot numbers (for PCI) or bus/port numbers (for USB). I've just tested this (somewhat) by plugging a USB flash device into the same USB port twice -- in both cases, the /dev/disk/by-path symlinks were the same. But when I plugged it in somewhere else, the symlinks were different.

So, let's not bother patching Udev, we'll describe by-path and by-id for CD drives. We'll describe by-mac for network interfaces.

Sounds good to me; I'll try to do it in the next couple days. :-)

Replying to dnicholson@linuxfromscratch.org:

Wouldn't the same issue arise on a USB cdrom drive, for example?

Yes it would, see the USB flash device example above. Plugging it into another port made the path ID change; I don't see how a CD drive would act any differently.

There may be fewer people with USB CDs than USB NICs, but I really have no idea.

I do think it makes sense to keep by-path for CDs, though, just because that was the only option up until udev-104. It was what Debian originally released (with no other option), so having our system act like another system that the user has a decent chance of already knowing is probably not bad. Also, leaving it in provides a halfway-decent place to put the warning about path persistence on hotpluggable buses.

[bryan@linuxfromscratch.org]

Should be fixed in r7923 (CDs) and r7924 (NICs).

[Jeremy Huntwork]

Milestone 6.3 deleted