2007/11/19, Bryan Kadzban <[EMAIL PROTECTED]>:
> There may be cases other than wireless devices where the type attribute
> needs to be used. Or at least, the upstream persistent-net-generator
> file seems to add that attribute for everything. I don't know if that
> means that it's actually needed for anything other than this case,
> though.
Indeed, you are right - in udev-117, the logic has been moved from the
script itself to the rules and redesigned a bit.
> > 2) every other device that needs persistent rules (eth*, ra* and sta*
> > only) - instruct the reader to write a rule without ATTR{type}
>
> Looking at the upstream persistent-net-generator again, they create
> rules for eth*, ath*, wlan*[0-9], ra*, and sta*, as you've said, but
> also ctc*, lcs*, and hsi*. I don't know how many of those will ever
> appear on an x86 machine, though.
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.
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., there are at
least two ath*, or two eth*, or two sta* with stable MAC addresses.
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.
BTW, the current upstream rules create a disaster for devices with a
locally-administered MAC address. They generate this too-broad rule:
SUBSYSTEM=="net", ACTION=="add", ATTR{type}=="1", NAME="eth0"
(tested by running this command: kvm -net user -net
nic,macaddr=23:45:67:89:ab:cd -cdrom /lfs-livecd/lfslivecd-x86-6.3.iso
-m 1024 -boot d)
> 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.
> It would, of course (so that's another strike against it), but I
> don't think that starting up a secondary udevd inside chroot and killing
> that process later would.
I have not investigated this possibility.
> (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).
> (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.
As for the Debian installer approach, I have no progress to report.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
