Ticket #1912 is basically a side effect of moving to the upstream Udev extras/rule_generator stuff. It's sort of patched, but to use the rule_generator scripts "properly" (or at least, what I think is "properly"), I think we should rework both the CD aliases section (7.12.1) and the network configuration section (7.13.1).
The CD symlinks should not be required until the new system is booted,
at which point the rule generator script will run, and it'll be OK. If
the user builds or runs programs from inside chroot, they'll have the
host system's /dev tree (including symlinks), because it's supposed to
be bind-mounted before entering chroot. So no manual configuration
should be required there; I think most of that section could be removed.
I think the network section should probably just change to 'run
"/lib/udev/write_net_rules all_interfaces", and inspect the generated
rules in these files before you create the config files in the next
section'. The all_interfaces code really needs to run before the
machine boots, because otherwise the configuration in 7.13.2 isn't going
to use the right names.
Two (similar) issues that I see:
1) NIC rules are MAC-address-based only.
That's the only method that the script supports. I've posted a few
patches to linux-hotplug-devel to add path-based persistence to the
script, but I haven't heard much about them (except from Alexander:
thanks!), so I don't know whether they'll be included in the next (or
any) udev release. But the patch uses path_id to come up with an
ENV{ID_PATH} value that should work, if the user wants path-based
persistence.
This has at least one problem, though: path_id may not support all types
of NICs. It does (with the patch) support PCI, USB, and (I *think*)
Firewire NICs. It probably does not support PCMCIA or Cardbus NICs (I'm
guessing it'll just find their PCI parent device and use that), and
mini-PCI NICs may be unsupported as well. PCIe may likewise need more
work. (All of these are supportable, there's just nothing in path_id to
handle them at this point.)
Multi-port cards are also an issue, but I don't have a few hundred
dollars to pick one up and see how its ports appear in sysfs.
2) CD symlink rules are path-based only.
Again, that's the only method the script supports. I'm actually not
even sure if device-identity persistence is possible with CD drives,
though, because many of them don't provide a serial number. (Model plus
revision may be close, but it's not perfect. Although there are
problems with any kind of persistence, so maybe it'd be good enough.) I
have sent a patch upstream similar to the write_net_rules one, to add
identity support to write_cd_rules (based on ID_SERIAL if present, and
ID_MODEL plus ID_REVISION otherwise), but I haven't heard anything on it
either. (OTOH, I did just send it yesterday.)
So, does this sound good? If so, should we wait for upstream to pick up
the different types of persistence? If so, what do we do if they don't
want to -- add the patches ourselves? I can certainly add them to LFS
if we want to depart from the "standard" upstream code like that.
In summary, this is what I'm thinking: Remove most of section 7.12.1
(certainly the udev rules), and reword section 7.13.1 to grab the names
from the rules that "write_net_rules all_interfaces" will generate. If
we don't care about removing identity-persitence from CDs and
bus-persistence from NICs, or we don't care about having custom code
added to udev by a patch, I could do this anytime; just wondering what
others think.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
