Kernel panic 2.6.8-9, unable to boot at all
Hi all, I am in very deep and hot waters... I have upgraded my kernel to 2.6.8-9 using synaptic and now I am getting kernel panic with: pivot-root: no such file or directory sbin/init: 426: cannot open dev/console: no such file I did investigate this as much as I can, and I am led to believe that it has something to with the /usr/sbin/mkinitrd as explained here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=263169 I did apply the patch --using a Knoppix CD as I am not able to login to the box by any other means. All partitions are on a 3ware 8506 RAID 5 card, and I had no problems booting it up until I upgraded my kernel to 2.6.8-9 (using synaptic). I did try any of the follwing 17 (16?) boot options, and each time I get the same kernel panic. I really really would like not to have to re-install this machine if it is at all possible --I have spent so much time setting it up and configuring numerous applications/daemons on it. I dont have any other amd64 machines that I could --if it possibly works-- replace some image in /boot. I am not even sure whether it might work. How do I get out of this catch-22? Could someone help me with this. Thanks in advance, Ray === here is the contents of /mnt/sda1/grub/menu.lst === # Generated by grubconf-0.5.1 default=16 timeout=5 title Debian GNU/Linux, kernel #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz root=/dev/sda1 ro initrd /initrd.img savedefault boot title Debian GNU/Linux, kernel (recovery mode) #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz root=/dev/sda1 ro single initrd /initrd.img savedefault boot title Debian GNU/Linux, kernel 2.6.7-5-amd64-xeon #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz-2.6.7-5-amd64-xeon root=/dev/sda1 ro initrd /initrd.img-2.6.7-5-amd64-xeon savedefault boot title Debian GNU/Linux, kernel 2.6.7-5-amd64-xeon (recovery mode) #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz-2.6.7-5-amd64-xeon root=/dev/sda1 ro single initrd /initrd.img-2.6.7-5-amd64-xeon savedefault boot title Debian GNU/Linux, kernel #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz root=/dev/sda1 ro initrd /initrd.img savedefault boot title Debian GNU/Linux, kernel (recovery mode) #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz root=/dev/sda1 ro single initrd /initrd.img savedefault boot title Debian GNU/Linux, kernel .old #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz.old root=/dev/sda1 .old initrd /initrd.img.old savedefault boot title Debian GNU/Linux, kernel .old (recovery mode) #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz.old root=/dev/sda1 .old single initrd /initrd.img.old savedefault boot title Debian GNU/Linux, kernel 2.6.8-1-amd64-generic #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz-2.6.8-1-amd64-generic root=/dev/sda1 ro initrd /initrd.img-2.6.8-1-amd64-generic savedefault boot title Debian GNU/Linux, kernel 2.6.8-1-amd64-generic (recovery mode) #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz-2.6.8-1-amd64-generic root=/dev/sda1 ro single initrd /initrd.img-2.6.8-1-amd64-generic savedefault boot title Debian GNU/Linux, kernel 2.6.7-5-amd64-xeon #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz-2.6.7-5-amd64-xeon root=/dev/sda1 ro initrd /initrd.img-2.6.7-5-amd64-xeon savedefault boot title Debian GNU/Linux, kernel 2.6.7-5-amd64-xeon (recovery mode) #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz-2.6.7-5-amd64-xeon root=/dev/sda1 ro single initrd /initrd.img-2.6.7-5-amd64-xeon savedefault boot title Debian GNU/Linux, kernel #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz root=/dev/sda1 ro initrd /initrd.img savedefault boot title Debian GNU/Linux, kernel (recovery mode) #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz root=/dev/sda1 ro single initrd /initrd.img savedefault boot title Debian GNU/Linux, kernel .old #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz.old root=/dev/sda1 .old initrd /initrd.img.old savedefault boot title Debian GNU/Linux, kernel .old (recovery mode) #:0 -- type: 0 = linux, 1 = windows, 2 = other root (hd0,0) kernel /vmlinuz.old root=/dev/sda1 .old single initrd /initrd.img.old savedefault boot title Debian GNU/Linux, kernel 2.6.8-9-amd64-k8-smp #:0 -- type: 0 = linux, 1 = windows, 2 =
Re: Kernel panic 2.6.8-9, unable to boot at all
Hello , try to remove root (hd0,0) I dont know how but for my own system this works greetings central
Re: Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On Mon, Oct 25, 2004 at 08:18:40AM +0200, Andreas Jochens wrote: On 04-Oct-24 23:24, Kurt Roeckx wrote: On Sun, Oct 24, 2004 at 10:18:15PM +0200, Andreas Jochens wrote: This patch is harmless with respect to any LSB requirement. The name of the dynamic loader, which is coded into every binary can only be changed in the gcc package. This patch does not change that. I don't know what you all changed in the gcc-3.4 archive. But this is what I now get with something I just compiled: ldd test libc.so.6 = /lib/libc.so.6 (0x002a9566d000) /lib/ld-linux-x86-64.so.2 = /lib/ld-linux-x86-64.so.2 (0x002a95556000) While with the pure64 archive with either gcc-3.3 of 3.4 it's still pointing to /lib64/ld-linux-x86-64.so.2 I patched the gcc-3.4 package in the amd64/gcc-3.4 archive to get that result. For the patch I used please look at BTS #277852. I recompiled the complete amd64/gcc-3.4 archive with that patch and without the '/lib64' and '/usr/lib64' symlinks in place. I still have to reupload most of the recompiled packages to alioth but you should be able to debootstrap a new chroot from the amd64/gcc-3.4 archive and do a 'rm /lib64' without making the system unusable. Does your binaries run on other x86-64 distributions without any compat symlinks ? I think this is an absolute requirement for pure64. Cheers, Bill.
Re: Kernel panic 2.6.8-9, unable to boot at all
Hi, I am afraid it didn't work over here. Cheers, Ray, central wrote on 2004-10-30 16:19: Hello , try to remove root (hd0,0) I dont know how but for my own system this works greetings central
Re: Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On 04-Oct-30 15:36, Bill Allombert wrote: On Mon, Oct 25, 2004 at 08:18:40AM +0200, Andreas Jochens wrote: I patched the gcc-3.4 package in the amd64/gcc-3.4 archive to get that result. For the patch I used please look at BTS #277852. I recompiled the complete amd64/gcc-3.4 archive with that patch and without the '/lib64' and '/usr/lib64' symlinks in place. I still have to reupload most of the recompiled packages to alioth but you should be able to debootstrap a new chroot from the amd64/gcc-3.4 archive and do a 'rm /lib64' without making the system unusable. Does your binaries run on other x86-64 distributions without any compat symlinks ? I think this is an absolute requirement for pure64. The binaries will run on all distributions which have the interpreter accessible as /lib/ld-linux-x86-64.so.2. Gentoo, Ubuntu and of course pure64 install the interpreter as /lib/ld-linux-x86-64.so.2 today, so the binaries will run on these distributions without changes. On other distributions it may be necessary to execute ln -sf /lib64/ld-linux-x86-64.so.2 /lib/ld-linux-x86-64.so.2 to run the binaries until those distributions install that symlink themselves. Anyway, if you intend to run binaries on different distributions, you should create binaries which conform to the LSB standard and you should install the LSB compatibility package on the target system. Otherwise you will certainly have more serious problems than the location of the interpreter. Regards Andreas Jochens P.S.: Do you really want to install Debian binary packages on other (non-Debian related) distributions (e.g. RedHat, SuSe)? Have you already tried that and did it work?
Re: Bug#277972: glibc: Please change the remaining instances of 'lib64' to 'lib' on amd64
On Sat, Oct 30, 2004 at 04:12:01PM +0200, Andreas Jochens wrote: Does your binaries run on other x86-64 distributions without any compat symlinks ? I think this is an absolute requirement for pure64. The binaries will run on all distributions which have the interpreter accessible as /lib/ld-linux-x86-64.so.2. Gentoo, Ubuntu and of course pure64 install the interpreter as /lib/ld-linux-x86-64.so.2 today, so the binaries will run on these distributions without changes. On other distributions it may be necessary to execute ln -sf /lib64/ld-linux-x86-64.so.2 /lib/ld-linux-x86-64.so.2 to run the binaries until those distributions install that symlink themselves. You cannot do that if you are not root, while you can extract binaries out of Debian packages and run them. For simple stuff it works fine. Anyway, if you intend to run binaries on different distributions, you should create binaries which conform to the LSB standard and you should install the LSB compatibility package on the target system. Otherwise you will certainly have more serious problems than the location of the interpreter. Does the LSB compatibility package for RedHat or Suse provide such a symlink ? P.S.: Do you really want to install Debian binary packages on other (non-Debian related) distributions (e.g. RedHat, SuSe)? Have you already tried that and did it work? Yes it works fine for the simple stuff I am interested in (mathematical command-line driven programs). It is far less trouble than installing a proper build environment without root access. Cheers, Bill.
Re: Kernel panic 2.6.8-9, unable to boot at all
John C. Martin wrote on 2004-10-30 16:42: Is the driver for the root filesystem device modularized in your kernel? Yes, it is modularized. This being the 3ware card, it is part of the kernel for a very long time. I just found something somewhat odd while checking if they were actually both modularized in the config-xxx files in /boot Yes, they are both modularized. But, since my card is 3ware, I am not sure if my culprit isn't in these two lines config for kernel 2.6.7-5 CONFIG_BLK_DEV_3W__RAID=m config for kernels 2.6.8-1..2.6.8-9 CONFIG_BLK_DEV_3W__RAID=m CONFIG_SCSI_3W_9XXX=m Now... A couple of days ago I asked the 3ware people about their raid manager stuff for debian, and here is a part of their reply: We are planning to phase these in to the 8000/7000 series in the next release. Make sure the controller has the latest firmware and driver. I wonder if having the 2 modules in is what screws up things. I had the same thing here last week on my systems (Shuttle SN95G5). The driver module supporting the device the root filesystem was on was not being loaded. The problem was solved by explicitly adding the module to /etc/mkinitrd/modules and rebuilding the initrd image (using a full kernel rebuild, I could not get mkinitrd to work for me standalone). I had to fall back to previous kernel I was using (2.6.6) to boot, make these changes, and rebuild the kernel. I added '3w-' (the module I need) to /etc/mkinitrd/modules With that, I tried to login, but ended up with the same kernel panic stuff. Now... Do I need a kernel compilation? If so, how on earth can I do that --I can't even login... BTW, since I am using stock Debian kernels, is there anywhere I can download those images from. I might as well try that --easier than setting up a fresh install, I guess. Cheers, Ray
Re: Kernel panic 2.6.8-9, unable to boot at all
On Sat, Oct 30, 2004 at 02:18:09PM +0300, Basri Kanca wrote: I am in very deep and hot waters... You can try my DFS CD from http://people.debian.org/~jgoerzen/dfs. It contains a kernel that does not* require initrd to boot, and as an added bonus, has most of the critical drivers for your initial boot compiled statically. Make sure to use one of the amd64 kernels if you have an amd64 userland. You should be able to mount your existing filesystems, then chroot into your system to repair it. There are also instructions on the CD for installing one of the kernels included on it to your live system. As a general rule, I never use the initrd kernels for just some of these reasons. It's too error-prone. Once you have your machine installed, you can build your own kernel, and then the whole need for the initrd kernels goes away. (Yes, they're useful if you have to have a generic kernel, but as far as I'm concerned, that's where the usefulness ends.) [*] In the usual sense. The DFS CD does use an initrd to mount the CD and do a little housekeeping, but it doesn't use it for drivers, and when installed on your system, doesn't need an initrd at all. -- John
Re: Kernel panic 2.6.8-9, unable to boot at all
On Sat, Oct 30, 2004 at 06:36:07PM +0300, [EMAIL PROTECTED] wrote: John Goerzen wrote on 2004-10-30 18:10: Hi John, You can try my DFS CD from http://people.debian.org/~jgoerzen/dfs. Thank you. I am not being much a Linux person, yet --I am just a tad above newby level :-) I checked your site and DFS files are all non-amd64, yet there is an amd64 image in there Grab the i386 version. It has both i386 and amd64 kernels on it. Just pick the amd64 kernel from the Grub menu and you're set. It's i386 because the programs on the CD itself are compiled for i386. But they run just fine on a 64-bit machine, too, and the CD can be used to restore a 64-bit installation. http://people.debian.org/~jgoerzen/vmlinuz-2.6.6-amd64 If I placed it in the /boot of the machine (under knoppix), would it work with these in grub It should. Just make sure you delete the initrd line. It'll probably give you enough to get to a root prompt, but then you'll need to compile or install your own kernel, since this one doesn't support things like sound or DRI. As a general rule, I never use the initrd kernels for just some of these reasons. It's too error-prone. Once you have your machine installed, you can build your own kernel, and then the whole need for the initrd kernels goes away. (Yes, they're useful if you have to have a generic kernel, but as far as I'm concerned, that's where the usefulness ends.) I suppose I will have to do just that one day. ATM, I am just not brave enough to compile my own kernels :- It's actually not all that painful under Debian. There's a Linux kernel building HOWTO out there. You can use its instructions to configure that kernel, and then: make-kpkg --rootcmd=fakeroot kernel_image to roll your own .deb of the new kernel. If you can figure out partitioning, OS installation, bootloaders, etc., you can figure out kernel building :-) -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715
Re: Kernel panic 2.6.8-9, unable to boot at all
John Goerzen wrote on 2004-10-30 19:19: I checked your site and DFS files are all non-amd64, yet there is an amd64 image in there Grab the i386 version. It has both i386 and amd64 kernels on it. Just pick the amd64 kernel from the Grub menu and you're set. d/l'ing as I write. http://people.debian.org/~jgoerzen/vmlinuz-2.6.6-amd64 If I placed it in the /boot of the machine (under knoppix), would it work with these in grub It should. Just make sure you delete the initrd line. It'll probably give you enough to get to a root prompt, but then you'll need to compile or install your own kernel, since this one doesn't support things like sound or DRI. Tries it; but I ended up with a different kernel panic: It keeps asking for an 'initrd' value. Apparently, 'initrd' just has to be given. Just out of curiosity --and ignorance :-) --, why do we need anything other than vmlinuz. Why can't the whole thing be a large singular blob :-) It's actually not all that painful under Debian. There's a Linux kernel building HOWTO out there. You can use its instructions to configure that kernel, and then: make-kpkg --rootcmd=fakeroot kernel_image to roll your own .deb of the new kernel. If you can figure out partitioning, OS installation, bootloaders, etc., you can figure out kernel building :-) Kernel building? Ha! The moment I get myself out of this mess, I shall set off to climb Mt Everest --no less :-) Cheers, Ray
Re: Kernel panic 2.6.8-9, unable to boot at all
Hi, [EMAIL PROTECTED] writes: why do we need anything other than vmlinuz. Why can't the whole thing be a large singular blob :-) Because nowadays, that blob would be so large that most bootloaders and many systems would choke on it. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Kernel panic 2.6.8-9 --result
Well, I tried everything I could. -- Deleting 'boot' line: Did not work. -- Using boot images from DFS: Did not work. -- Deleting 'initrd' line: Did not work. -- Using boot images from a fresh install with mkinitrd (all modules): Did not work. -- Debian install images will not install a thing onto a non-clean disk. So, it did not work either. After a little while, it did not even begin to boot; it kept dropping to GRUB CLI. Anyway, at the end of the day --literally-- all I have is GBs of raw data on RAID that once booted. If anyone is interested: I suspect it has something to do with something in the /boot partition. Somehow it gets screwed. Ray
