[lfs-dev] Udev-177 and a monolithic kernel
Hello, When I'm booting with udev-177 I get a cryptic message output to the screen in amongst the bootscripts that reads: udevd[120]: No such file or directory Is anyone else seeing this? I suspect it may be due to kmod looking for something that is not present in a monolithic kernel. When I run the network interface commands I see this in amongst that output: index_mm_open: No such file or directory Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-177 & Kmod-3 WIP patch
Matt Burgess wrote: > Yeah, both xz and zlib install their libraries to /lib, but oddly > enough, kmod still found them after telling it that they were > in /usr/lib. I guess the linker's searching in /lib by default? Yes, it should search /lib by default. (Wandering a bit off topic...) dummy.log: Libraries: LIBRARY_PATH= 1. /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/: exists 2. /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib64/: = /usr/lib64/ symlink to /usr/lib 3. /lib/../lib64/: = /lib64/ symlink to /lib 4. /usr/lib/../lib64/: = /usr/lib64/ symlink to /usr/lib 5. /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../: = /usr/lib 6. /lib/: 7. /usr/lib/ 1. SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64"); 2. SEARCH_DIR("/usr/local/lib64"); 3. SEARCH_DIR("/lib64"); 4. SEARCH_DIR("/usr/lib64"); 5. SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib"); 6. SEARCH_DIR("/usr/local/lib"); 7. SEARCH_DIR("/lib"); 8. SEARCH_DIR("/usr/lib"); Note: On my system 1, 2, 4, and 5 do not exist. 3 and 7 are the same. 4 and 8 are the same. I wonder if it would be useful to try to remove what's not used? Includes: ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../x86_64-unknown-linux-gnu/include" Translates to /usr/x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/include /usr/local/include (empty) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/include-fixed /usr/include I wonder if changing these search paths would make any significant difference in compile times. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-177 and a monolithic kernel
On Tue, 2012-01-17 at 13:38 +, Andrew Benton wrote: > Hello, > > When I'm booting with udev-177 I get a cryptic message output to the > screen in amongst the bootscripts that reads: udevd[120]: No such file > or directory I got a similar message during testing, complaining about line 52. See the last hunk of version 2 of the patch I sent out last night at 23:38. > > Is anyone else seeing this? I suspect it may be due to kmod looking for > something that is not present in a monolithic kernel. When I run the > network interface commands I see this in amongst that output: > index_mm_open: No such file or directory I see that as well, but seeing as everything worked OK with the rules generation, I ignored it during testing. I'll go back now and see if I can figure out what it's trying to do and whether we can shut it up! Thanks for testing. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-177 and a monolithic kernel
On Tue, 2012-01-17 at 21:41 +, Matt Burgess wrote: > On Tue, 2012-01-17 at 13:38 +, Andrew Benton wrote: > > When I run the > > network interface commands I see this in amongst that output: > > index_mm_open: No such file or directory > > I see that as well, but seeing as everything worked OK with the rules > generation, I ignored it during testing. I'll go back now and see if I > can figure out what it's trying to do and whether we can shut it up! Well, I'm giving up on that particular exercise now. I've passed '--enable-debug' to both kmod and udev, and by looking at the code, that should be enough to get it to spit out the filename it tried to open, but still nothing. If it helps alleviate your concerns, if I run those commands from within a booted LFS system, I don't get that error message. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page