-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Alexander E. Patrakov wrote: > IMHO, we should follow the rationale, not the letter, of the upstream > rules, because previously users with interface names not in the > whitelist but needing persistent rules had to either edit the script > or to add rules by hand anyway.
Good point. > And the rule of thumb is that a rule should be written if there is a > chance that the interface will be randomly renamed, > <...> > I.e., if you have only one eth* card and don't create a rule for it, > you can still be sure that it will get eth0, and that the rule with > eth0 will be written on the first boot. Oh, right. Yeah, I didn't think of that. That probably means most people won't have to do anything, doesn't it. Hmm... > BTW, the current upstream rules create a disaster for devices with a > locally-administered MAC address. Yeah, I saw your post to linux-hotplug-devel. Hopefully something will get figured out. (I'm not sure that should hold this up though. I doubt we'll release a new book until it gets fixed. Actually the way this is going, we may not even get udev updated until after it gets fixed. ;-) ) >> Oh -- did you mean that killing the host's udevd would require another >> if? > > Yes, killing and restarting. And restarting will surely break on new > systems when they rename udevd or do something equally stupid. Right. So let's forget that path entirely then. >> (I'd think that writing manual rules would be hard for jhalfs also, >> right?) > > Correct, but there are other hard-to-configure files, so in the worst > case, the jhalfs team will either add a "use this file for persistent > network rules" option like we have for fstab, or simply ignore the > issue (because jhalfs currently doesn't even attempt to configure the > network). Oh, I see. >> (Going back to telling the user to write their own rules is one way to >> do it, but IMO, we have most of the required stuff in place to write the >> rules for the user already. Does it make sense to make them re-do >> work?) > > Yes, IMHO it has a lot of educational value for them not to rely on > the "run the magic script" approach. Hmm. You're right. It probably depends on whether the risk of screwing something up (e.g. by copying a host's wrongly-renamed wlan0->eth0 (or ethX->ethY_rename!) mapping without thinking, because the host had an older udev without the correct rules) justifies the added learning. I don't really follow the -support list (though I probably should), so I don't like doing things that might be easily messed up, that will add to the traffic over there. (Now OTOH, there may be a typo in some part of the list of commands I posted earlier, too; that was a fairly complex list of stuff. So maybe I'd be adding to the -support traffic no matter what. Hmm... :-/ ) And from your second message: > Debian installer allows udev in the installer to generate rules, then > allows the user to choose and configure the primary network card, and > then copies the generated rules to the target system. I see; thanks for looking into it! > This solution doesn't work for LFS, because we can't assume that we > can copy udev rules from the host. Right. And if they change the method that they use (e.g. by patching in support to change the generated rules file's name, or something), that will still only work if the host udev is a new-enough version (it has to have support for changing the rules file name). That's valid under debian-installer, but not LFS. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQjpoS5vET1Wea5wRAwUbAKChGlTZuXcECr6eVoiFFe4TSLy5jACgiHyY boYCTGdIEsMckRKxdoAB5IA= =6f51 -----END PGP SIGNATURE----- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
