NavigationUser loginSpam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. |
Kernel panic on original kernel after rebuilding/installing new kernelNewbie here .... MB: Asus A7V880, Athlon 3200+, 512 MB RAM I have a fresh install of debian, desktop environment. I noticed an upgrade occured after completing the install, for something like 'kernel 2.6.18-486' I would like to experiment with various kernels, adding/removing modules and features for best peformance. grub is updated, and I reboot into new kernel with no problem. The PROBLEM is if I try the orignal kernel, I get a kernel panic on the VFS step during the boot. Original kernel is somehow unusable or broken. Debian updates cannot happen in new kernel. What am I doing wrong here? To build kernel I install (as root), fakeroot, kernel-package,linux-source-2.6.18 As user, I extract /usr/src/liniux-source-2.6.18.tar.bz2 to my home directory Now (as user) I follow the well documented instructions for building a new kernel, i.e., Any help is greatly appreciated thock |
Kernel panic on original
Kernel panic with VFS on boot is unusual - did you check your bootloader configuration carefully and make sure it uses the correct "initrd" argument?
Why can't you do Debian updates with your new kernel? This should have nothing to do with the kernel.
What was your old kernel? Did you have to update tools (udev etc), was your old kernel running devfs but the new one is udev, etc.
Thanks!
It alsways pays to check one's assumptions ...
First of all it was the newly built kernel, not the original, that was broken. Kernel version is 2.6.18
Second, I will have to look in menuconfig for options related to the VFS panic. If you have any suggestions for tracking this down, let me know.
I did not build with the initrd option on the build command line. I will try this also.
In the meantime I will try a simple kernel rebuild using x86 target (default)
Cheers!
thok
Thanks!
A VFS panic usually happens when the kernel doesn't have the drivers necessary to mount the 'root' partition. During the boot process, the bootloader reads the (usually compressed) kernel into memory, decompresses it, then runs it - all the reading uses the BIOS. The first thing the kernel does is set up to initialize itself; part of the initialization is to switch the processor to "virtual memory mode" - at this point the BIOS is no longer accessible and you need a kernel driver for everything. A common problem is that people do not use 'initrd' but forget to compile some driver like SATA, ext2, ext2, SCSI, etc, - in this case you just get a panic.
If you use 'initrd', a special compressed file is created which contains drivers and other things to help set up the system. The bootloader (or was it the kernel) reads and uncompresses 'initrd' which contains its own 'root partition' but in reality it is all stored in RAM and not on disk. The kernel can start, 'root' is already mounted, and software can run to identify your hardware and load drivers. When the correct drivers are loaded, the scripts then mount your real root partition and, if instructed, remove the initrd root system from memory.
If you don't use initrd, you need to build all drivers necessary to read the root partition into the kernel for a successful boot.
Re: Thanks!
I think you just need to add the --initrd option to your make-kpkg command:
make-kpkg --initrd kernel_image