[lfs-dev] Udev-177 and a monolithic kernel

2012-01-17 Thread Andrew Benton
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

2012-01-17 Thread Bruce Dubbs
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

2012-01-17 Thread Matt Burgess
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

2012-01-17 Thread Matt Burgess
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