RE: cold plugging
Alexander wrote: Basically, it means that we have three options WRT udev and hotplug. 1) Upgrade to their new way of handling things, (i.e., linux-2.6.15 + patches, new udev, new rules, no hotplug). 2) Keep everything as it is currently (i.e., linux = 2.6.12, udev, current rules, hotplug) 3) Remove both udev and hotplug, revert to static /dev But (1) means that we WILL break things at least for Darren Salt (i.e., make his computer unbootable--do you want this for your own system?). The unable to wait reliably for all hotplug events problem looks unsolvable. (2) is not currently supported upstream, so if we choose this, we are on our own. This leaves us with no option other than (3). Sorry for my inability to say anything else. Well why not choose a sensible timeout, and put a note with an optional sed in the bootscript instructions which says something like Slower machines may need more time on boot to listen for hotplug events. If you are experiencing difficulties, try doing the following: I don't think that is so bad, really. Jeremy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cold plugging
Jeremy Herbison wrote: Alexander wrote: Basically, it means that we have three options WRT udev and hotplug. 1) Upgrade to their new way of handling things, (i.e., linux-2.6.15 + patches, new udev, new rules, no hotplug). 2) Keep everything as it is currently (i.e., linux = 2.6.12, udev, current rules, hotplug) 3) Remove both udev and hotplug, revert to static /dev But (1) means that we WILL break things at least for Darren Salt (i.e., make his computer unbootable--do you want this for your own system?). The unable to wait reliably for all hotplug events problem looks unsolvable. (2) is not currently supported upstream, so if we choose this, we are on our own. This leaves us with no option other than (3). Sorry for my inability to say anything else. Well why not choose a sensible timeout, and put a note with an optional sed in the bootscript instructions which says something like Slower machines may need more time on boot to listen for hotplug events. If you are experiencing difficulties, try doing the following: Your wording is not completely technically correct and should be improved. Try creating a short version of the text below. What happens (at least in my case with USB) is: 1) The script creates an empty /dev/.udev/queue directory 2) The script causes the kernel to emit uevents (that's the new official name of what formerly was called hotplug events). 3) udevd gets those uevents, and reacts upon them. This reaction involves, among other things, making device nodes and calling /sbin/modprobe to load new drivers. 4) Those drivers are bound to devices by the kernel, this produces new uevents, go to (3). 5) When the internal queue of udev becomes empty, it removes the /dev/.udev/queue directory and the loop exits. The problem is that some modules take longer than 0.1s to detect their hardware (e.g., USB storage takes up to 10 seconds), so: 6) such late uevents reach udev _after_ the loop ends, and then it may be too late. My solution is to rewrite the script so that it repeatedly checks that the queue stays empty for some period of time (i.e., retests the existence of /dev/.udev/queue several times with delays between them) instead of exiting immediately when the queue becomes empty for a moment. Although I admit that the reported /dev/hda case doesn't really fit the above scenario, since there are no modules involved. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: file's config files
Robertus Ario Jatmiko wrote: For your information, that file is not static after all. I added a new entry to the magic file: The question is not *can* you add stuff to the magic file. The question is are you *supposed* to add stuff to the magic file. From the comment in the magic file itself, you are not. Re-read what you quoted: # Machine-generated from src/cmd/file/magdir/*; edit there only! Upstream *clearly* does not want the magic file to be edited directly; they want new definitions to be put into the source instead. Presumably this is so the new definitions are available for others too. It does not surprise me that it works to edit the file, BTW. But that doesn't mean it's an approved action. 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
Perl failing test 87
Perl is now failing on my jhalfs build of SVN at ext/DB_File/t/db-recno, Test 87. Probably something to do with db? Or is it me? R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cold plugging
Alexander E. Patrakov wrote: Message at the end is forwarded from linux-hotplug-devel. Basically, it means that we have three options WRT udev and hotplug. 1) Upgrade to their new way of handling things, (i.e., linux-2.6.15 + patches, new udev, new rules, no hotplug). 2) Keep everything as it is currently (i.e., linux = 2.6.12, udev, current rules, hotplug) 3) Remove both udev and hotplug, revert to static /dev But (1) means that we WILL break things at least for Darren Salt (i.e., make his computer unbootable--do you want this for your own system?). The unable to wait reliably for all hotplug events problem looks unsolvable. (2) is not currently supported upstream, so if we choose this, we are on our own. This leaves us with no option other than (3). Sorry for my inability to say anything else. I've been doing that udev coldplugging for a while now with no issues at all, what's unique about Darren's setup. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cold plugging
FYI my testing machine in a P1 233mhz. I see that Darren is using a PII 366. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Very minor issue with text in Changing Ownership in Chapter 6
The last sentence in Changing Ownership reads This book assumes you ran this chown command. That sentence implies (to me, anyway) that some instructions in the remainder of the book would somehow change if you didn't do the chown. However, I really don't see what would be different if you didn't change the ownership of /tools. Maybe I'm just being ridiculously picky, but I've always been a little confused by that statement. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Very minor issue with text in Changing Ownership in Chapter 6
Chris Staub wrote these words on 01/14/06 23:45 CST: The last sentence in Changing Ownership reads This book assumes you ran this chown command. That sentence implies (to me, anyway) that some instructions in the remainder of the book would somehow change if you didn't do the chown. However, I really don't see what would be different if you didn't change the ownership of /tools. Maybe I'm just being ridiculously picky, but I've always been a little confused by that statement. I'm not sure I've been confused by the statement, but I've always thought it was pointless. Sure, there is merit to everything said before that last sentence, but the last sentence is unnecessary. Nothing can come of it if you don't do the chown, other than what is already explained about some other user gaining inadvertent ownership. I suppose though, that you could look at it like this: The LFS book gives two alternatives on what to do: 1)leave it owned by the LFS user and create this user on your new system or 2)chown it to be owned by root. The book says it assumes you ran the chown command. Why it says that, is what you and I think can be done away with. I'm not sure why anyone should be confused about it. The book lists two alternatives, and says it assumes you did one of the two. Not very confusing to me. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 23:55:00 up 112 days, 9:19, 3 users, load average: 0.00, 0.00, 0.06 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Very minor issue with text in Changing Ownership in Chapter 6
Randy McMurchy wrote: I'm not sure I've been confused by the statement, but I've always thought it was pointless. Sure, there is merit to everything said before that last sentence, but the last sentence is unnecessary. Nothing can come of it if you don't do the chown, other than what is already explained about some other user gaining inadvertent ownership. I suppose though, that you could look at it like this: The LFS book gives two alternatives on what to do: 1)leave it owned by the LFS user and create this user on your new system or 2)chown it to be owned by root. The book says it assumes you ran the chown command. Why it says that, is what you and I think can be done away with. I'm not sure why anyone should be confused about it. The book lists two alternatives, and says it assumes you did one of the two. Not very confusing to me. I guess I just read a little more into it than I should bother to. :p As I said, a statement like that seems to imply that the book's instructions would somehow change if you didn't run the command, so I was a bit confused over what in the book would be done differently - that's what I meant. But clearly the answer is nothing. Though it probably wouldn't hurt to replace that sentence with something like It is strongly recommended to run this chown command in case you do plan to keep $LFS/tools. Or would even that be redundant? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Very minor issue with text in Changing Ownership in Chapter 6
Chris Staub wrote these words on 01/15/06 00:15 CST: Though it probably wouldn't hurt to replace that sentence with something like It is strongly recommended to run this chown command in case you do plan to keep $LFS/tools. Or would even that be redundant? Yes, it would be redundant. The instructions already have a shaded box with the command inside it. You know, those things on every page that have stuff the reader is supposed to type. :-) I don't think it really matters, though. Do you think anyone actually keeps the /tools directory on the system? I would hope not. Actually, there should be instructions to archive the directory and then remove it. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 00:22:00 up 112 days, 9:46, 3 users, load average: 0.56, 0.88, 0.73 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Very minor issue with text in Changing Ownership in Chapter 6
Randy McMurchy wrote: Chris Staub wrote these words on 01/15/06 00:15 CST: Though it probably wouldn't hurt to replace that sentence with something like It is strongly recommended to run this chown command in case you do plan to keep $LFS/tools. Or would even that be redundant? Yes, it would be redundant. The instructions already have a shaded box with the command inside it. You know, those things on every page that have stuff the reader is supposed to type. :-) I don't think it really matters, though. Do you think anyone actually keeps the /tools directory on the system? I would hope not. Actually, there should be instructions to archive the directory and then remove it. Yeah, I was thinking that myself. In fact there's a bug in BZ right now about tarring up /tools...with LFS as it is now the suggestion to keep /tools and tar it up is in the wrong place, as well as being incomplete. Not only is the suggestion at the end of the book (after you've already adjusted the /tools gcc) but it it also missing an explanation that you would need the binutils source and build dirs as well. Maybe it would be easier just to remove the suggestion about keeping /tools and eliminate Changing Ownership in the process... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
