> So, I recently built (and rebuilt) svn-20060220.  Both times resulted in 
> the same kernel panic.  Any tips as to how to interpret the panic so as 
> to point to a specific cause would be much appreciated.
> 
> The first time through, I was working (and installing to) a single ext3 
> partition; that was the only deviation from the book.  When I got the 
> kernel panic, I figured I had made a dumb mistake like misconfiguring 
> the kernel (perhaps I didn't compile in ext3) or somesuch.  I had done 
> the final work on it late at night, and perhaps had been sloppy.
> 
> The second time through, I was much more careful.  I started completely 
> from scratch - new disk, newly formatted (ext3), built toolchain from 
> scratch, etc.  I (foolishly, in retrospect) did not run *every* make 
> check, but I did on several (ie, glibc, gcc) and I did do the check 
> compiles to make sure I wasn't linking against tools, that SSP was 
> working correctly, etc.  In particular, in configuring the kernel, I 
> left it at all the defaults (ext3 appeared to be compiled in, not as a 
> module, by default) except the grsec and PaX options.  Same panic.  I 
> then did a cp -pr to an ext2 partition, remounted dev proc etc, chrooted 
> in and reran grub.  Rebooted, same result.
> 
> One thing I thought of was hotplug.  I read that it was needed to 
> populate /dev.  I assumed that that meant for new devices, after boot 
> (ie, usb), but... In make menuconfig, the section for hotplug listed 
> "---" instead of the "<*>" I would have expected, but looking at the 
> .config file showed hotplug set to y, so that seems OK (?)
> 
> I can't see all of the data from the panic, because it scrolls of the 
> screen.  Basically, I see the tail end of a column of hex numbers, then 
> some other data, as follows:
> 
> [<00000000>]
> Code: 57 56 53 83 ec 2c 8b 44 24 44 85 c0 0f 88 e5 04 00 00 8b 74 24 40 
> 8b 44 24 44 8d 6c 06 ff 89 f0 83 e8 01 39 e8 77 43 8b 4c 24 48 <80> 39 
> 00 74 25 0f b6 01 3c 25 74 42 39 ee 77 06 8b 4c 24
> <0>Kernel panic - not syncing: Attempted to kill init!
> 
> I googled the last phrase, but came up mostly with references to a 
> problem in Red Hat that didn't seem relevant - but I admit that I 
> probably don't have the knowledge to know what's relevant and what's not...
> 
> In particular, I'd appreciate not only ideas about what the problem 
> might be, but advice on how I could debug it myself.  Meanwhile I'll be 
> embarking on yet another build, with 'make check' at every point along 
> the way...  Thanks!
> 
> -jps
> 

before goiung any further, stop.

Download something like the ultimate boot cd: http://www.ultimatebootcd.com/
And run memtest86+
(any/all of their memory testers depending on yopur level of paranoia)

I have seen some very strange things happen with compilation and memory issues.

And yes, I have successfully compiled an entire scratch system on a machine 
with bad ram..when it comes to runtime or kernel compile, many strings things 
happen.

-- 
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to