[lug] bizarre 2.6.18 config message
Michael J. Hammel
mjhammel at graphics-muse.org
Sun Oct 8 10:57:09 MDT 2006
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 18.104.22.168
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
> 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
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
More information about the LUG