#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

Reply via email to