-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I've been thinking about this (off and on) for the past few weeks now, and I have a couple ideas that I'd like some comments on. First, the requirements as I see them:
- ----- A) We need to generate the rules, obviously. We don't want the user to boot their LFS system for the first time without any rules in existence, because they've already configured their NICs in chapter 7. B) The method we choose needs to work with any host udev version (including, as Alexander recently noted, no udev at all). We might be able to get away with adding some early version of udev to the host requirements, but I doubt it, and I'd rather not have to. I think that requiring e.g. udev-099 or higher (for persistent-net support) is a bit crazy, though. - ----- Now, my (additional) preferences: a) I'd rather not leave chroot to generate the rules; leaving chroot, doing whatever, and re-entering it would be really hard for automated build systems (stuff like jhalfs). b) I don't believe it's strictly necessary to generate the rules in section 7.13.1, but I think it makes a lot of sense to do it there. If we wanted to do it in chapter 6 somewhere (e.g. right after udev is installed), I think that might work. But I'd rather not move it. - ----- So, these are the possibilities that I see: 1) We could set the appropriate environment variables for each interface and run write_net_rules manually. This would require tracking a lot of state that's provided in the upstream rules files (e.g. they have their own whitelist of which network interface basenames should be used, and all others should be ignored; they also have a fairly large list of environment variables used to communicate back and forth, which we'd have to set from sysfs attribute files). A loop through each interface can probably be done, but I think it'd be a lot of maintenance. And this is already in the rules, if we can get udevd to do the work for us. 2) We could fire up a copy of udevd inside chroot, and trigger all the network-subsystem devices' uevents. We'd have to make sure the new names don't actually get applied, otherwise we screw up the host. There are also a few sockets (well, at least one) that udev listens on that are exclusive: if a version of udevd is already running on the host, we'd either have to kill it (leaving chroot to do so) and restart it afterward (again leaving chroot), or make the udevd-in-chroot not require that socket. 3) Wait to see what Debian does with debootstrap (since I can't find anything regarding udev at the moment) and copy it, if it'll work for us. 4) Possibly others: any ideas? - ----- I don't think staying with udev-113 forever is a good idea. They've added a base set of rules that we can use, for one. They've also fixed the usb_id segfault issues (although kernel 2.6.24 will have an independent fix that should also be applied, so the ID attributes don't disappear in the first place). I'd be in favor of 2, except for the fact that udevd can't currently run two copies. I do have a patch to udevd that creates a new command-line switch that lets it run a second copy that's set up to only generate rules files (--in-chroot). This switch disables RUN rules and network-device renames (and could also disable creating/removing device files), and also disables the socket that's problematic (or at least one of them). But upstream doesn't seem to want it; the Debian udev maintainer, for instance, thinks that Debian's chroot rules can be generated by "adding temporary rules" and doing something unspecified. (But I don't think that'll work for us because of requirement B (and preference a) above.) If we adopt that patch, I'd almost rather *not* leave it in the final udevd, but maybe it doesn't really matter. If we don't want to leave it in the final udevd, then we'll have to compile udevd twice: once with the patch, then run the sequence below, then recompile/reinstall it without the patch. That may be hard for scripting setups though? Anyway, I'd envision something like this to generate the rules: udevd --in-chroot & pid=$! udevadm trigger --subsystem-match=net # optional "sleep X", probably 3-5 seconds or so udevadm settle kill $pid unset pid (Note the use of udevadm: starting in udev-117, all the "udev*" programs except udevd have been changed to "udevadm *" instead. There are compat symlinks pointing at udevadm from the old program names, so it would still work to use udevtrigger and/or udevsettle, but I'd rather not use them if we can change.) The downside here is the patch: we're adding something to a program that it seems upstream doesn't want. But without any other ideas, I don't know how else to get what we need. Unless there are any other ideas? If you have one, please speak up... ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPzayS5vET1Wea5wRA5kMAKCq8QB7xfyeLiLNCnWNYUC0z4MnUwCg3NTz OcHysCBpWNHrBPnxpLWV+u4= =dDXl -----END PGP SIGNATURE----- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
