#2057: Udev-122 ------------------------------------------+--------------------------------- Reporter: [EMAIL PROTECTED] | Owner: [email protected] 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 [EMAIL PROTECTED]: > 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. -- http://linuxfromscratch.org/mailman/listinfo/lfs-book FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
