lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 24 Jul 2007 01:59:45 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Tilman Schmidt <tilman@...p.cc>
CC:	LKML <linux-kernel@...r.kernel.org>, andi@...stfloor.org,
	nix.or.die@...glemail.com
Subject: Re: 2.6.22-git17 boot failure

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ