#1912: Possible bad interaction of udev rules for duplicate devices
--------------------------------------------+-------------------------------
Reporter: [EMAIL PROTECTED] | Owner: [email protected]
Type: defect | Status: reopened
Priority: normal | Milestone: 6.3
Component: Book | Version: SVN
Severity: normal | Resolution:
Keywords: |
--------------------------------------------+-------------------------------
Comment (by Bryan Kadzban):
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?
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/1912>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page