δΊ 2011-3-2 15:00, [email protected] ει: > Send lfs-support mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 ([email protected]) > 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<[email protected]> > Subject: Re: Ruminations on Udev, null and console > To: LFS Support List<[email protected]> > Message-ID:<[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > [email protected] 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: [email protected] > Subject: Re: Ruminations on Udev, null and console > To: [email protected] > Message-ID:<385680687.499296.1299013313419.JavaMail.root@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<[email protected]> > Subject: Issue compiling kernel? - WARNING: modpost: Found 41 section > mismatch(es). > To: LFS Support List<[email protected]> > Message-ID: > <[email protected]> > 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. >
-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
