Re: 2.6.22-git17 boot failure

[Jeremy Fitzhardinge <jeremy@goop.org>]

Tilman Schmidt wrote:
> Jeremy Fitzhardinge schrieb:
>   
>> Well, it looks to me like it all falls over once it hits usermode;
>> everything up till then is identical (except for the Xen-related
>> initcalls which naturally don't exist in the non-Xen case).
>>     
>
> Just a wild thought: could the actual problem be with accessing the
> initrd? After all, everything that's failing is based on modules
> which are stuffed there. But I know far too less about initrd to
> pursue this thought further.
>   

Well, the kernel is managing to mount the initrd as a filesystem, and
the "waiting for root to appear" message looks like its coming from
usermode as well.  So I suspect its something to do with module loading,
but I can't imagine what at the moment.

Statically compiling the scsi/ahci/etc drivers will help make some
progress in debugging this.

I really can't see how its directly Xen related.  It looks like either:

   1. some bug which only appears with particular kernel memory layouts,
      and enabling Xen happens to make it bad
   2. or some kind of linker bug, possibly triggered by Xen's ELF notes
      (but I'd really expect this to break in a more basic way)
   3. ...?


>> I'm at a loss.  I don't know if there's some way to debug the initrd in
>> more detail.  I suspect that its failing all PCI probing, rather being a
>> specific SCSI/AHCI problem (since none of the other messages appear either).
>>
>> Does the Xen case just hang, or reboot, or what?  The kernel messages
>> just appear to stop.  I'd expect it to at least complain about not
>> mounting the root filesystem or something.
>>     
>
> Yes, of course. Sorry, I thought I'd mentioned that. It shows the
> standard behaviour of a Suse that cannot mount its root filesystem:
> first a message: "waiting for /dev/system/root to appear" followed
> by a series of dots, and then fallback into a standalone /bin/sh.
>   

Oh, you get a shell?  What does /proc/pci have in it?  What happens if
you manually try to modprobe something?  That gives us much more to work
with.

    J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/