Re: failure to start kernel k8-smp

[Francesco Pietra <frapietra@alice.it>]

On Tuesday 11 July 2006 20:15, helices wrote:
> * Francesco Pietra <frapietra@alice.it> [2006:07:11:15:56:12+0200] scribed:
> > If this is the situation, I hope that a suggestion will come whether to
> > unistall (I still have the generic kernel)
> >  linux-image-2.6.15-1-amd64-k8-smp
> > and install
> >  linux-image-2.6.16-1-amd64-k8-smp
> > should it exist. Why replacement does not occur on
> > #aptitude upgrdade
> > ?
> >
> > If I am not alone having problems, or the problems I reported seem to be
> > caused by the OS system, this is a situation to clarify. One does not
> > come to 64bit to run applications that can be run at the same level of
> > efficiency at 32bit (personally I'll never install such applications as
> > kde gnome openoffice, etc at 64bit, or 32bit chroots or ia386 (although
> > lib32 are installed by the system against my will!) as I have my old pc
> > for that). One comes to 64bit for the floating point and the precision.
> >
> > Until a clarification and a path to follow I must sadly say that I am
> > stopped with quantum mechanical calculations.
>
> What do you get with the following?
>
>     COLUMNS=200 dpkg -l 'linux-image*' | sed 's!^....!!;s! .*$!!' | grep ^l

$ COLUMNS=200 dpkg -l 'linux-image*' | sed 's!^....!!;s! .*$!!' | grep ^l
linux-image
linux-image-2.6
linux-image-2.6-386
linux-image-2.6-486
linux-image-2.6-686
linux-image-2.6-686-smp
linux-image-2.6-amd64-generic
linux-image-2.6-amd64-k8
linux-image-2.6-amd64-k8-smp
linux-image-2.6-em64t-p4
linux-image-2.6-em64t-p4-smp
linux-image-2.6.15-1-amd64-generic
linux-image-2.6.15-1-amd64-k8
linux-image-2.6.15-1-amd64-k8-smp
linux-image-2.6.15-1-em64t-p4
linux-image-2.6.15-1-em64t-p4-smp
linux-image-amd64-generic
linux-image-amd64-k8
linux-image-amd64-k8-smp
linux-image-em64t-p4
linux-image-em64t-p4-smp

I move here your question: what do you think from the above?

Memories are eight slots Kingston KVR400D4R3A/1G PC400 1GB


>
> Simple deduction indicates that your problem has three (3) possible root
> causes:
>
>   [1] memory[leak?]
>   [2] kernel
>   [3] application
>
> IMHO, the simplest to change, and to test, is [2].
>
> What do you think?