[LFS Trac] #2057: Udev-122

LFS Trac trac at linuxfromscratch.org
Mon May 19 17:25:52 PDT 2008


#2057: Udev-122
------------------------------------------+---------------------------------
 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 Bryan Kadzban):

 Replying to [comment:22 alexander at linuxfromscratch.org]:
 > So they don't have a way to say "let eth1 be the same card that was
 named eth1 in my previous distro" (and that's, essentially, the goal of
 LFS).

 Well, that's what the patch would actually get you.  My goal was less
 specific than that, though; my goal was to generate some fixed name
 (randomly or not, it doesn't matter) before the user runs through section
 7.13 and creates the configuration files based on the NIC's name.  It
 doesn't have to be the same name as the parent distro (though it will be
 here); it just has to be known when the network script is set up (in
 chroot, currently), and fixed from that point forward.

 So my goal is the same as what Debian actually does; the only reason their
 approach won't work for us is that they can rely on the version of udev on
 the installer CD (their host).

 (If the host doesn't run udev, or runs an old version that doesn't do
 NICs, then the generated names could be random; that would be fine.)

 > So my opinion is that we should write rules by hand, explaining the
 logic

 Which is what the book used to do, until write_net_rules came along.

 Of course, the logic has gotten a lot more complicated since we yanked
 that section: excluding Xen devices, skipping devices that have the
 "local" bit set in their MAC, including comments so you know which device
 the rule is for when you look at the generated file later, and even
 letting external tools like biosdevname (for Dell server systems) generate
 a persistent name.  I would rather not duplicate all of that.

 But OTOH, if you generate a rule that doesn't have quite enough info in
 it, you'll start to get users that have *_rename devices because the rule
 that they wrote ended up matching two (or more) of their interfaces.  Or
 they use a NIC driver that generates a random MAC on every boot, but don't
 know it, so their ethX name keeps changing.

 I have a feeling that this could cause a lot more traffic on -support.  Of
 course, I don't know for sure.

 > or, optionally, postpone the configuration until after the reboot (thus
 losing predictable names and the ability to do remote installations).

 I wonder how many users require that (that is, remote installations).
 There's probably no way to know, except yanking it out and seeing who
 complains.  (That's assuming people complain, instead of just moving to
 some other setup.)  It's not like asking on -dev or -support is going to
 reach all the users.

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



More information about the lfs-book mailing list