linux-kernel - Re: 2.6.22-git17 boot failure

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:	Mon, 23 Jul 2007 17:14:05 -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:
> Am 23.07.2007 22:32 schrieb Jeremy Fitzhardinge:
>   
>> How much of this is modules?  Is the initrd probing for scsi/sata? 
>> Maybe the the vdso change is having an effect.
>>     
>
> Pretty much all of it is modules. The base system is openSUSE 10.2, and
> SuSE has a long habit of building everything as modules and putting the
> drivers needed for accessing the root filesystem into an initrd. I have
> fought it for a while but nowadays I'm playing along.
>
> So yes, all of ahci, pata_marvell, aic7xxx, jbd, dm_mod, ext3 are in
> fact modules in initrd. Would it help to try a kernel with some or all
> of these built in?
>
>   
>> Ooh, wait.  Do you have an old version of the Xen patches in place,
>> perhaps?
>>     
>
> In which place? I installed and successfully ran the Xen packages that
> came with openSUSE 10.2, so there is a 2.6.18 kernel with SuSE's Xen
> patches on the machine. But that shouldn't have any influence on the
> kernel.org kernels I build myself, should it?
>
>   
>>  Does drivers/block/Makefile have:
>>
>> obj-$(CONFIG_XEN_BLKDEV_FRONTEND)	+= xen-blkfront.o
>>
>> (vs := xen-blkfront.o)
>>     
>
> It has the "+=" variant.
>
>   
>> Could you do a before and after booting with initcall_debug=1?
>>     
>
> "Before" and "after" meaning with CONFIG_XEN=n and CONFIG_XEN=y, I
> suppose. The resulting logs are a bit biggish, so I have put them on
> http://www.phnxsoft.com/~ts/linux/ for download. Let me know if you
> prefer having them mailed.

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).

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.

Andi, any thoughts about how to debug the suse boot sequence?

    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/