[lug] bizarre 2.6.18 config message

[Michael J. Hammel]

Semi-educated comments follow:

On Sun, 2006-10-08 at 00:35 +0000, D. Stimits wrote:

> Time: tsc clocksource has been installed.
> Creating initial device nodes
> Setting up hotplug.
> Creating block device nodes.
> Loading scsi_transport_spi.ko module
> scsi_transport_spi: no version for "struct_module" found: kernel tainted.

Not sure about this.  I thought all modules got a module version by
default that they could override with MODULE_VERSION.  In the 2.6.17.1
source I have, the scsi_transport_spi.c doesn't seem to reference
MODULE_VERSION internally or in any headers.  So I'd assume it was
getting it from the default module version string (can't remember what
that is called).  Apparently not, though.

I also thought a kernel was only tainted if the MODULE_LICENSE was not
an acceptable open source license.  I didn't know a version number
(missing or otherwise) could cause that message.

> Loading sym53c8xx.ko module
> Loading jbd.ko module
> Loading ext3.ko module
> Creating root device.
> Mounting root filesystem.
> mount: could not find filesystem "/dev/root"

No /dev/root, which means no root filesysstem.  Without the root, you
can't mount /dev.  This would be my guess as to what is causing all the
other problems.  Maybe this is because the initrd doesn't have a /dev?

> Setting up other filesystems.
> Setting up new root fs
> setuproot: moving /dev failed: No such file or directory

Can't move /dev if root filesystem doesn't exist.

> no fstab.sys, mounting internal defaults
> setuproot: error mounting /proc: No such file or directory

Ditto.

> I can't seem to get around it always losing /dev when I upgrade the 
> kernel, that's probably a config item. But why on earth would it claim 
> the kernel is tainted when there this absolutely pristine 2.6.18 source 
> has zero outside sources added? Has kernel.org started packaging tainted 
> modules that are selectable during build?

The worlds an imperfect place.  It might just be a bug, though I can
find no references to it on the net.  I did find similar messages for
other modules.  Check the changelog for that driver.  Maybe a recent
update accidently mucked the driver, like forgetting to update a header
file or something.

> PS: Any hints on why it can never find /dev with newer kernels is 
> welcome as well...I have the controller and filesystem compiled in or in 
> a properly supported initrd.

The place this is failing appears to be after it loads the initrd.  Dumb
question:  is there a /dev directory in the initrd?  I'm pretty sure you
need the directory to exist even if you're using udev, though I'm not
udev expert.
-- 
Michael J. Hammel           |
mjhammel at graphics-muse.org  |  Books we'll never see:
http://www.ximba.org        |       "The Engineer's Guide to Fashion"
LFS Userid: 16857