help

zhou zhouchonghz at gmail.com
Wed Mar 2 20:48:46 PST 2011


于 2011-3-2 15:00, lfs-support-request at linuxfromscratch.org 写道:
> Send lfs-support mailing list submissions to
> 	lfs-support at linuxfromscratch.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://linuxfromscratch.org/mailman/listinfo/lfs-support
> or, via email, send a message with subject or body 'help' to
> 	lfs-support-request at linuxfromscratch.org
>
> You can reach the person managing the list at
> 	lfs-support-owner at linuxfromscratch.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lfs-support digest..."
>
>
> Today's Topics:
>
>     1. Re: Ruminations on Udev, null and console (Bruce Dubbs)
>     2. Re: Ruminations on Udev, null and console (alupu at verizon.net)
>     3. Issue compiling kernel? - WARNING: modpost: Found 41 section
>        mismatch(es). (bsquared)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 01 Mar 2011 01:59:14 -0600
> From: Bruce Dubbs<bruce.dubbs at gmail.com>
> Subject: Re: Ruminations on Udev, null and console
> To: LFS Support List<lfs-support at linuxfromscratch.org>
> Message-ID:<4D6CA752.4090909 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> alupu at verizon.net wrote:
>> Bruce Dubbs wrote,
>>
>>> When I rebooted, I got the following messages:
>>> cannot open /dev/null
>>> FATAL: Module platform: regulatory not set
>>> FATAL: Module LNXSYTEM: not found
>>> FATAL: Module doc not found
>>> FATAL: pci:v............... not found
>>> This last was repeated about 20 times for various pci values.
>>> When I added null back to /lib/udev/devices/ and reenabled the copy in
>>> the bootscripts, I got none of these messages.
>> Awful.  A few thoughts.
>> As I said in my OP:
>>
>>>> LFS book: Version SVN-20110218
>>>> Script activation order in '... rcsysinit.d/':
>>>>    mountkernfs
>>>>    consolelog
>>>>    modules (no modules to install, in my case)
>>>>    udev
>>>>    ...
>> iN MY PREvious post, sections 5-7, null (and console) is already fully
>> represented.  Unfortunately, "modules" comes before "udev":
> I don't have any modules to load.  No console to update either.  I agree
> that the /dev/null entries in mountkernfs could be removed by using the
> -q option for mountpoint.  I suspect that option was added after the
> bootscript was written.
>
> Actually, on my system, those errors appeared to come up before any
> bootscripts were started.  They came about 4 seconds into the boot.  It
> takes about 8 or 9 seconds to get to the boot prompt.
>
> I think those 'module' errors are being generated by drivers built into
> the kernel.  Note that LNXSYTEM is an ACPI device.
>
> Since the instruction to copy null to /dev occurs after the error
> message, I have no idea why they are coming up.
>
>     -- Bruce
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 01 Mar 2011 15:01:53 -0600 (CST)
> From: alupu at verizon.net
> Subject: Re: Ruminations on Udev, null and console
> To: lfs-support at linuxfromscratch.org
> Message-ID:<385680687.499296.1299013313419.JavaMail.root at vznit170132>
> Content-Type: text/plain; charset=UTF-8
>
> Bruce Dubbs wrote:
>
>> When I rebooted, I got the following messages:
>> cannot open /dev/null
>>   ...
>> FATAL: Module LNXSYTEM: not found
>>   ...
>> When I added null back to /lib/udev/devices/ and reenabled
>> the copy in the bootscripts, I got none of these messages.
>>   ...
>> I don't have any modules to load.  No console to update either.
>> I agree that the /dev/null entries in mountkernfs could be removed
>> by using the -q option for mountpoint.
>> I suspect that option was added after the bootscript was written.
>> Actually, on my system, those errors appeared to come up before any
>> bootscripts were started.  They came about 4 seconds into the boot.
>> It takes about 8 or 9 seconds to get to the boot prompt.
>> I think those 'module' errors are being generated by drivers built into
>> the kernel.  Note that LNXSYTEM is an ACPI device.
>> Since the instruction to copy null to /dev occurs after the error
>> message, I have no idea why they are coming up.
> Hi Bruce,
>
> 1.  One thing at a time.
> To RE-recap the conclusions about null/console situation
> from my OP and the "time-line" post:
>
> 1.1. The "null" and "console" nodes MUST exist in the "metal" /dev
> directory before start-up.
>
> 1.2 If one follows the LFS script order, the null/console coverage
> is practically perfect.  No gaps.
>
> 1.2.1. The "metal" null disappears after the line
>   if ! mountpoint /dev
> while heroically taking the last direct hit:
>   >  /dev/null
>
> 1.2.2. "null" reappears (practically reborn), through some mysterious
> machinations (more about that later) while still in "udev" (time-line,
> sections 5-7), which makes it impossible to be missed by anybody else:
>
> The "udev" script, what with 'udevadm settle' and all, makes sure that
> unless and until it is done, no other script, program, bash construct,
> etc. can start and potentially miss "null".
>
> A corollary of this whole 1.2. is that no scripts ahead of "udev"
> can fail, be it the much maligned (by me) "rc", or the others,
> even in their original form (without the "-q", _with_ ">/dev/null").
> In other words, "null" (here, in the "metal" avatar) will always
> be there, for example to gracefully absorb any blows of the form
>   "...>  /dev/null".
>
> 2.  I wish I could help/explain your problem(s) including your
> suspicion that the "udev" null copy (or rather the lack of it)
> has something to do with the errors.
> I've been wrong before (so many times!).
>
> In the beginning of my tests/ruminations, as I mentioned, I made
> sure I use copies of the latest scripts in their exact sequence:
>
>>>> LFS book: Version SVN-20110218
>>>> Script activation order in '... rcsysinit.d/':
>>>>    mountkernfs
>>>>    consolelog
>>>>    modules (no modules to install, in my case)
>>>>    udev
>>>>    ...
> Note:  I always boot to INIT level 3.  (id:3:initdefault:)
>         That may matter.
>
> If you find any similarities, I'd be more than willing to compare
> notes on this subject.
> It's definitely an intriguing project.
>
> 3. As a general comment, we are all aware that Udev has been a
> moving target, ever since its inception.  No problem with that.
> It's just that you have to aim more carefully, but there's the
> risk of being hit right in the face when you become complacent
> and not continuously on the ball.
>
> My parents always told me to be careful with people who say
> 'if SoAndSo=="?*" then ...' instead of 'if SoAndSo!="" then ...',
> which _is_ the the same thing, true, but shows those people might
> not talk straight.
>
> 3.1.  I have NO idea how all those devices (null, etc.) appear
> in my main-line section 5, as if out of thin air.
>
> Does udevd take a peak in my forgotten directory '/lib/udev/devices'
> (we _know_ Udev _knows_ about '/lib/udev/', for the rules)?
> Does it have its own internal rules?
>
> On a personal level, this is to me the last missing piece of my
> otherwise pretty airtight (I think) coverage of Udev activities
> on _my_ system and _my_ hardware.
> I'll be away from the test machine for a couple of days.
> As soon as I'm back, you can be sure I'll start looking hard into
> this quandary and the copy implications.
>
> By way of an example, if you do
>     'strings udevd | egrep "console|null"'
> you get only
> <<
> /dev/null
> cannot open /dev/null
> open /dev/null failed: %m
> and no "console", although the "console" node is there (in Sec. 5).
>
> Nor if you grep for "console" among the rules.
>
> Best regards,
> -- Alex
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 1 Mar 2011 13:14:58 -0800
> From: bsquared<bwcode4u at gmail.com>
> Subject: Issue compiling kernel? - WARNING: modpost: Found 41 section
> 	mismatch(es).
> To: LFS Support List<lfs-support at linuxfromscratch.org>
> Message-ID:
> 	<AANLkTikVfMGQO-4LR6=RO0afdcGkqXhp8yk+a+m5Eedy at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
>
> I am wondering if this is anything to be concerned about.  I googled
> some, and what I found did not seem to apply (using old config file),
> or indicated it may be normal.
>
> I have a pretty generic kernel configuration -- actually tried two
> different.  I get the following message when I make.
>
> WARNING: modpost: Found 41 section mismatch(es).
>
> it indicates that i should do the following to see details, so i did.
>
> make CONFIG_DEBUG_SECTION_MISMATCH=y
>
>
> 40 of the warnings are like this:
> WARNING: drivers/video/built-in.o(.devinit.text+0xb0): Section
> mismatch in reference from the function efifb_probe() to the (unknown
> reference) .init.data:(unknown)
> The function __devinit efifb_probe() references
> a (unknown reference) __initdata (unknown).
> If (unknown) is only used by efifb_probe then
> annotate (unknown) with a matching annotation.
>
> and the remaining one is
> WARNING: arch/x86/pci/built-in.o(.text+0x10fb): Section mismatch in
> reference from the function pcibios_scan_specific_bus() to the
> function .devinit.text:pci_scan_bus_on_node()
> The function pcibios_scan_specific_bus() references
> the function __devinit pci_scan_bus_on_node().
> This is often because pcibios_scan_specific_bus lacks a __devinit
> annotation or the annotation of pci_scan_bus_on_node is wrong.
>
>
> I searched in menuconfig for efifb but found no matches.  I double
> checked my video config and it seems OK.
>




More information about the lfs-support mailing list