[LFS Trac] #2057: Udev-120

LFS Trac trac at linuxfromscratch.org
Thu May 8 17:10:27 PDT 2008

#2057: Udev-120
 Reporter:  matthew at linuxfromscratch.org  |        Owner:  lfs-book at linuxfromscratch.org
     Type:  enhancement                   |       Status:  new                          
 Priority:  normal                        |    Milestone:  7.0                          
Component:  Book                          |      Version:  SVN                          
 Severity:  normal                        |   Resolution:                               
 Keywords:                                |  
Comment (by jhuntwork at linuxfromscratch.org):

 Replying to [comment:16 Bryan Kadzban]:
 > The problem with the script (as I see it anyway) isn't the loop -- it's
 all the assumptions that go into the various readlink calls, and the fact
 that most of the body of the loop is the shell equivalent of the existing
 75-persistent-net-generator.rules file.
 > For instance, is .../device/driver always valid?  Is looking for a
 certain string in the .../device symlink a valid way to figure out what
 subsystem the device belongs to?  (I doubt that it is.)  How fragile is
 that particular case statement, anyway (are there cases where it
 misdetects the subsystem)?  Is the fact that it doesn't support S/390
 devices ever going to be a problem?  (Perhaps not.)

 I see what you mean about assumptions and re-using logic built into udev.
 So the patch is preferable to the script. Even so, I really don't like
 where that leaves us. Either we leave the hacked up functionality in our
 final udev, or we build it twice. Ugh to both.

 Personally, I think I still prefer to let just let udev auto handle it at
 first boot. By far most of my systems have one NIC port which will always
 be named eth0. On other systems that have more than one, it doesn't matter
 to me which one is named what so long as it is consistent (it will be when
 udev generates the rule). In those circumstances, if I am only using one
 NIC then it's easy to find which one is named eth0. If I'm using both
 NICs, then it will be an advanced network setup that isn't really going to
 be covered in LFS, and I'll still be able to determine which one needs
 which configuration. And, I know a user might start doing BLFS stuff while
 in chroot, but technically, that's not by-the-book anyway. See section

 In any case, if more feel that it's better to patch up udev so that this
 configuration can be done in chroot, I'll conform. :)

Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2057#comment:17>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.

More information about the lfs-book mailing list