Re: failure to start kernel k8-smp
Sent again because there are two more kernels (k7) today and further problems arose with present kernel, as well as for a question on memories and a reply to what do you think. Today linux-image-2.6.15-1-amd64-k8-smp starts without, however, accepting the user password. To get that accepted, I had to launch from linux-image-2.6-amd64-generic #2 Mon Mar 20 10:43:41 UTC 2006 x86_64 GNU/Linux (the one from installation) On Tuesday 11 July 2006 20:15, helices wrote: * Francesco Pietra [EMAIL PROTECTED] [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-k7 linux-image-2.6-k7-smp 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 Memories are eight slots Kingston KVR400D4R3A/1G PC400 1GB Simple deduction indicates that your problem has three (3) possible root causes: [1] memory[leak?] Taking into account that the above k8-smp kernel failed to start a few days ago, and the systemcould be recovered with reinstall/install, followed yesterday by a breakdown while computing, and finally failure today to accept user password, my naive impression is that of a kernel to get free of. What about, instead of reinstall/install, carry out a purge/remove from this k8-smp kernel and reinstall it freshly by downloading it? If I had no adviser I would do that. AT ANY EVENT, is it any software to carry out an exhaustive check of the 8 slots of ECC memories? You appreciate that I can not rely on a system that works correctly for a few hours only, while Sarge does not support my hardware. [2] kernel [3] application IMHO, the simplest to change, and to test, is [2]. What do you think? Although it may be idiosyncratic, I am very uncomfortable at the /lib32 that the system insists to install even after a purge/remove from them. See the list: /lib libwrap.so.0.76 lsb modules security terminfo udev x86_64-linux-gnu /lib64 - /lib /lib32 - /emul/ia32-linux/lib ld-2.3.6.so ld-linux.so.2 libanl-2.3.6.so libanl.so.1 libBrokenLocale.so.1 libc-2.3.6.so libcidn-2.3.6.so libcidn.so.1 libc.so.6 libdl.so.2 libm-2.3.6.so libmemusage.so libm.so.6 libnsl.so.1 libnss_compsat-2.3.6.2 libnss_compsat.so.2 libnss_dns-2.3.6.so libnss_files-2.3.6.so libnss_files.so.2 libnss_hesiod-2.3.6.so libnss_hesiod.so.2 libnss_nis-2.3.6.so libnss_nisplus-2.3.6.so libnss_nisplus.so.2 libnss_nis.so.2 libpcprofile.so libpthread-2.3.6.so libpthread.so.0 libresolv.so.2 librt.so.1 lib.SegFault.so libthread_db-1.0.so libthread_db.so.1 libutil-2.3.6.so libutil.so.1 I would prefer a system that allows to work with /lib64 only, thus excluding all that it is not ready for 64bit. I wonder also whether it is in the economy to bring to 64bit applications that run satisfactorily at 32bit, instead of concentrating efforts to make the system robust for 64bit. What about BSD and Solaris from the latter viewpoit (and the point of view of the 265 amd64 dual opteron)? This question because my coworkers are pressing for my contribution. What I am aswering them today is that I am down but the problem may be simpler than it appears: simply a faulty installation of the kernel, one can not be recovered with #apt-get --reinstall install linux-image-2.6.15-1-amd64-k8-smp Cheers francesco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: failure to start kernel k8-smp
Francesco Pietra wrote: 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 ? ..snip.. Aptitude will upgrade a kernel of the same revision in place (it will replace 2.6.16-18 with 2.6.16-19) but when the kernel version is upgraded (2.6.16 to 2.6.17), it adds the new kernel to the existing kernel. This is so that if you have problems with the new kernel, you still have a working kernel on your box that you can go back to. If you are using any modules that are not part of the kernel (nvidia, ati, etc.) you will have to rebuild those with your new kernel also. Once you have completed the transition to your new kernel, you have to manually remove the previous one if you don't want it on your box any more. -Scott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: failure to start kernel k8-smp
This sent-again to refer that I have examined the *.out file for the mpqc b3lyp MCSearch OO geometry optimization for the C22H25NO6 molekule. max_iteration = 40 was felt, because the calculation went to iteration 13 (converged at line optimization step 3), when the system crashed (kernel panic!) at iter 5 during iteration 14, with no sign of irregularity in the output file. It seems to me that this rules out any failure due to the application. What remains open is: ---Check of the ECC 8GB memories (I don't know how in this sytem); ---Kernel failure (this is very likely the problem and I am waiting to know what to do: I am no more inclined to a purge and new install of the kernel because the existing alternative (generic kernel) seems also to deserve now little if any confidence. I must add that with the equivalent k7 kernel for i386 32bit I never had problems. francesco _ Sent again because there are two more kernels (k7) today and further problems arose with present kernel, as well as for a question on memories and a reply to what do you think. Today linux-image-2.6.15-1-amd64-k8-smp starts without, however, accepting the user password. To get that accepted, I had to launch from linux-image-2.6-amd64-generic #2 Mon Mar 20 10:43:41 UTC 2006 x86_64 GNU/Linux (the one from installation) On Tuesday 11 July 2006 20:15, helices wrote: * Francesco Pietra [EMAIL PROTECTED] [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-k7 linux-image-2.6-k7-smp 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 Memories are eight slots Kingston KVR400D4R3A/1G PC400 1GB Simple deduction indicates that your problem has three (3) possible root causes: [1] memory[leak?] Taking into account that the above k8-smp kernel failed to start a few days ago, and the systemcould be recovered with reinstall/install, followed yesterday by a breakdown while computing, and finally failure today to accept user password, my naive impression is that of a kernel to get free of. What about, instead of reinstall/install, carry out a purge/remove from this k8-smp kernel and reinstall it freshly by downloading it? If I had no adviser I would do that. AT ANY EVENT, is it any software to carry out an exhaustive check of the 8 slots of ECC memories? You appreciate that I can not rely on a system that works correctly for a few hours only, while Sarge does not support my hardware. [2] kernel [3] application IMHO, the simplest to change, and to test, is [2]. What do you think? Although it may be idiosyncratic, I am very uncomfortable at the /lib32 that the system insists to install even after a purge/remove from them. See the list: /lib libwrap.so.0.76 lsb modules security terminfo udev x86_64-linux-gnu /lib64 - /lib /lib32 - /emul/ia32-linux/lib ld-2.3.6.so ld-linux.so.2 libanl-2.3.6.so libanl.so.1 libBrokenLocale.so.1 libc-2.3.6.so libcidn-2.3.6.so libcidn.so.1 libc.so.6 libdl.so.2 libm-2.3.6.so libmemusage.so libm.so.6 libnsl.so.1 libnss_compsat-2.3.6.2 libnss_compsat.so.2 libnss_dns-2.3.6.so libnss_files-2.3.6.so libnss_files.so.2 libnss_hesiod-2.3.6.so libnss_hesiod.so.2 libnss_nis-2.3.6.so libnss_nisplus-2.3.6.so libnss_nisplus.so.2 libnss_nis.so.2 libpcprofile.so libpthread-2.3.6.so libpthread.so.0 libresolv.so.2 librt.so.1 lib.SegFault.so libthread_db-1.0.so
failure to start kernel k8-smp
The problems with
linux-image-2.6.15-1-amd64-k8-smp
on debian amd64 etch (if it is the kernel - which failed recently as reported
below from previous mail - and not the running application) seem to have no
end. After about 29 hours since the system was computing with mpqc 2.3.1, no
gui, two 265 opterons, mainboard tyan S2895 K8WE, 8GB ram, temperature cpu
ok, adsl cable disconnected (anyway, the installation is such that to get
line, dhclient is needed) the system halted with:
Code: 44 8b 56 08 0f 95 c0 41 84 c7 0f 84 bd 00 00 00 49 63 c5 48
RIP 801ce768 {blk_rq_map_sg+75} RSP 8101444ffd38
0Kernel panic - not syncing: Aiee, killing interrupt handler!
The system did not respond and had to be switched off
It starts again correctly on the k8-smp kernel and responded to
#aptitude update (and upgrade,fo ex it has replaced libselinux1 libtasn1 mutt
libcairo2 python-central menu 2.1.27) My sources are pure debian, see below.
A a dweller in scientific problems I am used to climb but if the system does
not respond I am lost. Before restarting a calculation with mpqc I need to be
sure that the OS is in order.
Thanks for your attention
francesco
___
If it is relevant, copy is given below ofmy recent e-mail concerning
librarieries:
For Debain claiming to pure 64bit, the number of 32bit
libraries that I got is impressively high. Particularly because I was aimed
at an installation of only 64bit applications (read mainly crushing-number
applications, with the minimum of extras, limited here to the jwm window
manager, just to be able to change bash in order to umount without complains)
I hope not to bother, rather to show a landscape that may be of some general
interest. Please examine the sequence of events, and resulting lib
installations below;
Netinstall (amd6a etch raid1), kernel 2.6.15-1-amd64-k8-smp.
Purge/remove /lib32
sources.list
deb http://ftp.debian.org/debian etch main contrib non-free
deb-src http://ftp.debian.org/debian etch main contrib
deb http://security.debian.org etch/updates main contrib non-free
deb-ser http://security.debian.org etch/updates main contrib
Besides frequent update/upgrade, deliberately installed (64bit):
---Two 64bit-compiled applications, one of mine, the other one mpqc 2.3.1
(which involved removing libsc7 and installing libsc8 and tk8.4) both
verified by ldd to only invoke 64bit libraries.
---jwm window manager
---lm-sensors
---lesstif1
Present status:
/lib
libwrap.so.0.76
lsb
modules
security
terminfo
udev
x86_64-linux-gnu
/lib64 - /lib
/lib32 - /emul/ia32-linux/lib
ld-2.3.6.so
ld-linux.so.2
libanl-2.3.6.so
libanl.so.1
libBrokenLocale.so.1
libc-2.3.6.so
libcidn-2.3.6.so
libcidn.so.1
libc.so.6
libdl.so.2
libm-2.3.6.so
libmemusage.so
libm.so.6
libnsl.so.1
libnss_compsat-2.3.6.2
libnss_compsat.so.2
libnss_dns-2.3.6.so
libnss_files-2.3.6.so
libnss_files.so.2
libnss_hesiod-2.3.6.so
libnss_hesiod.so.2
libnss_nis-2.3.6.so
libnss_nisplus-2.3.6.so
libnss_nisplus.so.2
libnss_nis.so.2
libpcprofile.so
libpthread-2.3.6.so
libpthread.so.0
libresolv.so.2
librt.so.1
lib.SegFault.so
libthread_db-1.0.so
libthread_db.so.1
libutil-2.3.6.so
libutil.so.1
__
Sent again to inform that the kernel problem was resolved with
#apt-get --reinstall install linux-image-2.6.15-1-amd64-k8-smp
(need to get 0/15.4 MB of archives)
#aptitude shows the same kernels as below.
Although remedied, any guess at that failure?
Also, I am still curious about the large number of lib32 introduced, as from
my previous mail.
Thank you
francesco
#aptitude
shows
i linux-image-2.6-amd64-generic
i linux-image-2.6-amd64-k8-smp
i linux-image-2.6.15-1-amd64-generic
i linux-image-2.6.15-1-amd64-k8-smp
and no brpken packages are indicated.
I was use to start
i linux-image-2.6.15-1-amd64-k8-smp
before the problem below.
__
Booting Debian GNU Linux kernel 2.6.15-1-amd64-k8-smp root (hd0,0)
Filesystem reiserfs, partition 0xfd
kernel /boot/vmlinuz-2.6.15-1-amd64-k8-smp root -/dev/md0 ro single
Error 13: invalid or unsupported executable found
Press any key...
Same error trying in recovery mode.
It starts with the only other kernel available:
2.6.15-1-amd64-generic (the one used for the installation)
? It is debian amd64 etch, raid1 two 264 dual opteron 8 GB ram.
thank you
francesco pietra
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: failure to start kernel k8-smp
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.
Cheers
francesco
On Tuesday 11 July 2006 16:03, Gudjon I. Gudjonsson wrote:
There are several months since I was running kernel 2.6.15 and I had
problems with it crashing from time to time ( 2.6.14 and 2.6.13 were
worse). My complaints should be somewhere in the mailing list archive.
Kernels 2.6.12 and 2.6.16 have been running without problems for me.
/Gudjon
Þann Þriðjudagur 11. júlí 2006 13:47 skrifaði Francesco Pietra:
The problems with
linux-image-2.6.15-1-amd64-k8-smp
on debian amd64 etch (if it is the kernel - which failed recently as
reported below from previous mail - and not the running application) seem
to have no end. After about 29 hours since the system was computing with
mpqc 2.3.1, no gui, two 265 opterons, mainboard tyan S2895 K8WE, 8GB ram,
temperature cpu ok, adsl cable disconnected (anyway, the installation is
such that to get line, dhclient is needed) the system halted with:
Code: 44 8b 56 08 0f 95 c0 41 84 c7 0f 84 bd 00 00 00 49 63 c5 48
RIP 801ce768 {blk_rq_map_sg+75} RSP 8101444ffd38
0Kernel panic - not syncing: Aiee, killing interrupt handler!
The system did not respond and had to be switched off
It starts again correctly on the k8-smp kernel and responded to
#aptitude update (and upgrade,fo ex it has replaced libselinux1 libtasn1
mutt libcairo2 python-central menu 2.1.27) My sources are pure debian,
see below.
A a dweller in scientific problems I am used to climb but if the system
does not respond I am lost. Before restarting a calculation with mpqc I
need to be sure that the OS is in order.
Thanks for your attention
francesco
___
If it is relevant, copy is given below ofmy recent e-mail concerning
librarieries:
For Debain claiming to pure 64bit, the number of 32bit
libraries that I got is impressively high. Particularly because I was
aimed at an installation of only 64bit applications (read mainly
crushing-number applications, with the minimum of extras, limited here to
the jwm window manager, just to be able to change bash in order to umount
without complains) I hope not to bother, rather to show a landscape that
may be of some general interest. Please examine the sequence of events,
and resulting lib installations below;
Netinstall (amd6a etch raid1), kernel 2.6.15-1-amd64-k8-smp.
Purge/remove /lib32
sources.list
deb http://ftp.debian.org/debian etch main contrib non-free
deb-src http://ftp.debian.org/debian etch main contrib
deb http://security.debian.org etch/updates main contrib non-free
deb-ser http://security.debian.org etch/updates main contrib
Besides frequent update/upgrade, deliberately installed (64bit):
---Two 64bit-compiled applications, one of mine, the other one mpqc 2.3.1
(which involved removing libsc7 and installing libsc8 and tk8.4) both
verified by ldd to only invoke 64bit libraries.
---jwm window manager
---lm-sensors
---lesstif1
Present status:
/lib
libwrap.so.0.76
lsb
modules
security
terminfo
udev
x86_64-linux-gnu
/lib64 - /lib
/lib32 - /emul/ia32-linux/lib
ld-2.3.6.so
ld-linux.so.2
libanl-2.3.6.so
libanl.so.1
libBrokenLocale.so.1
libc-2.3.6.so
libcidn-2.3.6.so
libcidn.so.1
libc.so.6
libdl.so.2
libm-2.3.6.so
libmemusage.so
libm.so.6
libnsl.so.1
libnss_compsat-2.3.6.2
libnss_compsat.so.2
libnss_dns-2.3.6.so
libnss_files-2.3.6.so
libnss_files.so.2
libnss_hesiod-2.3.6.so
libnss_hesiod.so.2
libnss_nis-2.3.6.so
libnss_nisplus-2.3.6.so
libnss_nisplus.so.2
libnss_nis.so.2
libpcprofile.so
libpthread-2.3.6.so
libpthread.so.0
libresolv.so.2
librt.so.1
lib.SegFault.so
libthread_db-1.0.so
libthread_db.so.1
libutil-2.3.6.so
libutil.so.1
__
Sent again to inform that the kernel problem was resolved with
#apt-get --reinstall install linux-image-2.6.15-1-amd64-k8-smp
(need to get 0/15.4 MB of archives)
#aptitude shows the same kernels as below.
Although remedied, any guess at that failure?
Also, I am still curious about the large number
Re: failure to start kernel k8-smp
* Francesco Pietra [EMAIL PROTECTED] [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 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? -- Best Regards, helices - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: failure to start kernel k8-smp
On Tuesday 11 July 2006 20:15, helices wrote: * Francesco Pietra [EMAIL PROTECTED] [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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
failure to start kernel k8-smp
Booting Debian GNU Linux kernel 2.6.15-1-amd64-k8-smp root (hd0,0) Filesystem reiserfs, partition 0xfd kernel /boot/vmlinuz-2.6.15-1-amd64-k8-smp root -/dev/md0 ro single Error 13: invalid or unsupported executable found Press any key... Same error trying in recovery mode. It starts with the only other kernel available: 2.6.15-1-amd64-generic (the one used for the installation) ? It is debian amd64 etch, raid1 two 264 dual opteron 8 GB ram. thank you francesco pietra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
failure to start kernel k8-smp
#aptitude shows i linux-image-2.6-amd64-generic i linux-image-2.6-amd64-k8-smp i linux-image-2.6.15-1-amd64-generic i linux-image-2.6.15-1-amd64-k8-smp and no brpken packages are indicated. I was use to start i linux-image-2.6.15-1-amd64-k8-smp before the problem below. __ Booting Debian GNU Linux kernel 2.6.15-1-amd64-k8-smp root (hd0,0) Filesystem reiserfs, partition 0xfd kernel /boot/vmlinuz-2.6.15-1-amd64-k8-smp root -/dev/md0 ro single Error 13: invalid or unsupported executable found Press any key... Same error trying in recovery mode. It starts with the only other kernel available: 2.6.15-1-amd64-generic (the one used for the installation) ? It is debian amd64 etch, raid1 two 264 dual opteron 8 GB ram. thank you francesco pietra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
failure to start kernel k8-smp
Sent again to inform that the kernel problem was resolved with #apt-get --reinstall install linux-image-2.6.15-1-amd64-k8-smp (need to get 0/15.4 MB of archives) #aptitude shows the same kernels as below. Although remedied, any guess at that failure? Also, I am still curious about the large number of lib32 introduced, as from my previous mail. Thank you francesco #aptitude shows i linux-image-2.6-amd64-generic i linux-image-2.6-amd64-k8-smp i linux-image-2.6.15-1-amd64-generic i linux-image-2.6.15-1-amd64-k8-smp and no brpken packages are indicated. I was use to start i linux-image-2.6.15-1-amd64-k8-smp before the problem below. __ Booting Debian GNU Linux kernel 2.6.15-1-amd64-k8-smp root (hd0,0) Filesystem reiserfs, partition 0xfd kernel /boot/vmlinuz-2.6.15-1-amd64-k8-smp root -/dev/md0 ro single Error 13: invalid or unsupported executable found Press any key... Same error trying in recovery mode. It starts with the only other kernel available: 2.6.15-1-amd64-generic (the one used for the installation) ? It is debian amd64 etch, raid1 two 264 dual opteron 8 GB ram. thank you francesco pietra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
