#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 Bryan Kadzban):
Replying to [comment:14 [EMAIL PROTECTED]: > > Section 7.13 ![...] > > 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. Probably, maybe, yeah. ;-) I don't like trying to enumerate all the ways that a change like this could fail, because I know I'm not any good at it (I usually leave a few out). I think that if the book had always only supported one NIC, then leaving it that way might be fine. It just makes me a bit uncomfortable to change it now that we've released N different book versions that didn't care... > While we could totally move onto BLFS from within chroot, what percentage of users do that? Not sure about anyone else, but I do that every time I build. I never actually boot up a new build (except once, to make sure it actually boots) until I've installed at least X, firefox, thunderbird, and transcode from inside chroot. But maybe I'm the only one. :-) > move some of that configuration of 7.13 to post-first-boot. We might be able to. There's currently nothing that gets run "post-first- boot", though, so it'd be a new section at least. It'd also probably be a pain for any kind of scripted build. > I prefer the script option to patching udev. I've attached the script that I'm looking at; I probably should have attached it last night as well. This is a '''horrific''' hack, is probably completely unsupported by upstream, and will very likely break after a few kernel releases -- but it works under 2.6.24.x, at least for PCI NICs. The more of it that I wrote, the less I liked it. (When I started writing it, I wasn't thinking about the sysfs stuff that it would need to do to get values like what goes into the rule comment, or the driver name, or the subsystem.) > Actually, what is our main goal here? I'd say the main goal would be setting stuff up so the system will come up configured properly once the book is done. But that's only because it used to work, and I don't like changing stuff like that unless we need to. ;-) I guess it depends on which of the script or the patch is a worse hack, and whether the less-hackish one is better than forcing a boot. If neither is better than forcing a boot, then maybe forcing a boot is what we need to do. > 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? There's not much more code that would be required to get all NICs working than the code that would be required for one -- see the script. The only extra thing that the script does to get it to work for all NICs is a loop. :-) The problem with the script (as I see it anyway) isn't the loop -- it's all the assumptions that go into the various readlink calls, and the fact that most of the body of the loop is the shell equivalent of the existing 75-persistent-net-generator.rules file. For instance, is .../device/driver always valid? Is looking for a certain string in the .../device symlink a valid way to figure out what subsystem the device belongs to? (I doubt that it is.) How fragile is that particular case statement, anyway (are there cases where it misdetects the subsystem)? Is the fact that it doesn't support S/390 devices ever going to be a problem? (Perhaps not.) -- Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2057#comment:16> 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
