#2057: Udev-120 ------------------------------------------+--------------------------------- 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 [EMAIL PROTECTED]):
Replying to [comment:11 Bryan Kadzban]: > Wouldn't that be nice. ;-) Yes. :) And I'm still not sure why it isn't an option, see below. > Section 7.13 (Configuring the network Script) requires the user know the interface name that will be assigned to the NIC when the system boots, because that's what the ifconfig.XXXX directory's name is based on. And if there's more than one ethX device, then the assignment will be (or at least, can be) random. Right. I'm aware of this one. The only instance that I can think of where this will pose a major problem is when you are building a system over ssh to which you have no physical access to. (My dedicated servers have been like this - thankfully they've only had one ethernet port.) But even this can be overcome. For example, if only one port has a link, simply assign both of them the same ip configuration for the initial boot. Anyway, I know it's not the prettiest solution, but it's often acceptable (when setting up a machine for the first time) to run through some initial configurations after the first boot. While we could totally move onto BLFS from within chroot, what percentage of users do that? I guess I'm still not sure why we couldn't move some of that configuration of 7.13 to post- first-boot. > The real problem is that the more recent you get with udeRighv, the more of the logic gets pushed out from the script and into the rules file. This isn't really bad, but when the newest daemon won't start inside chroot (because the host's daemon is running), and nothing will be able to interpret the rules in a compatible way, it's a problem. > Understood. > Opinions here? Well... based on what I've heard so far, I prefer the script option to patching udev. Actually, what is our main goal here? To be able to configure one working network card and have it's configuration be persistent? If this absolutely must be done inside chroot, wouldn't it be simpler to just replicate the minimal amount of code needed to generate one rule for a chosen port, and then let the rest be generated post-boot? Is there something else I'm missing? I'll be the first to admit that my head makes for a good cluebat target. ;) -- Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2057#comment:14> 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
