Hi,
I am a newbee to Linux Kernel Programming, recently compiled my new vanilla kernel 2.6.14.2 on FC4 (with kernel 2.6.11). On Booting with this Kernel I am geting the following message-
"kernel panic-not syncing VFS:unable to mount root fs on unknown-block(0,0)"
CONFIGURATION
-------------
Linux Flavor
- Fedora Core 4 with Kernel 2.6.11 preinstalled....
- For compilation I am using VANILLA KERNEL 2.6.14.2
System Model
-Hewlett-Packard Pavilion dv2000 (RD502PA#UUF)
- Enclosure Type Note Book
- Main Circuit Board-Hewlett-Packard 30B2 61.37
- Bus Clock 667 MHz
- BIOS Phoenix F.05 05/11/2006
Processor
- Intel Core Solo 1.87GHz Processor
- 64Kb Primary Memory Cache
- 2048 Kb Secondary Cache
Display
- Mobile INTEL(R) 945GM Express Chipset Family[Display Adapter] (2x)
- QDS14.0 [Monitor](14 inch VIS)(3x)
Memory Modules
-504 Mb Installed Memory
-Slot M1 has 512 Mb Memory
-Slot M2 Is empty
HDD
- SATA 80 GB hard Drive
I searched different Forums...amny are suggesting its a "initrd.img" problem i.e it is not built properly. I have tried 2-3 times to rebuilt my kernel. The problem remains the same
Following are the steps I use to compile my kernel
1. Installed Sources in /usr/src/kernel/linux-2.6.14.2
2. cd /usr/src/kernel/linux-2.6.14.2
3. make mrproper
5. Compile time configuration of kernel 2.6.14.2
- Because it was the first time i was compiling Kernel no .config
file was present. So I had to use "defconfig" files present at the
following path
/usr/src/kernel/linux-2.6.14.2/arch/i386/defconfig
- cp /usr/src/kernel/linux-2.6.14.2/arch/i386/defconfig .config
- make xconfig
- I selected SATA related options [which were by default disabled]
6. make
7. make modules_install
8. make install
After all of the above steps I can see my /boot partition been updated by new vanilla kernel 2.6.14.2 files namely
1. vmlinuz-2.6.14.2
2. initrd-2.6.14.2.img
3. system.map
4. within /boot/grub/menu.lst
As I reboot I get NTLDR screen because its a Dual bott between FC4 & Windows XP I select FC4 then the GRUB screen appears...asking me to select between kernels 2.6.11 and newly installed 2.6.14.2. I select 2.6.14.2 it shows Uncompressing image the the above mention ERROR appears with systems coming to halt.
Any help in this regard would really be appreciated
Thanks In Anticipation
Salil
Can anybody give the updates
Can anybody give the updates regarding above problem????
In Fedora Core you could:
In Fedora Core you could:
1. extract vanilla kernel source, let it be /usr/src/linux-2.6.X
2. cp /boot/config-2.6.11_FEDORA_VERSION /usr/src/linux-2.6.X/
3. cd /usr/src/linux-2.6.X
4. make oldconfig
5. make all
6. make modules_install
7. make install
8. reboot
Step 7, takes care of copying bzImage to /boot and also creating initrd.img, system.map and automagically editing grub.conf. With a proper initrd image, there is really no need to move modules (like ext3, ...) inside the kernel.
If everything goes well after reboot, just edit grub.conf to make the newly installed vanilla kernel the default boot option.
Boot into a live cd and
Boot into a live cd and mount volume and then do something like this:
sudo update-initramfs -k all -u -b /mnt/sda1/bootIt worked for me I hope it works for you too!
need modules at boot
Hi Salil
You need to make disk modules available to the kernel on boot. These modules are necessary to be able to load other modules from (surprise) disk.
The easiest solution is to compile the disk related modules into the kernel instead of compiling them as loadable (say y instead of m).
That way you will not need the initial ramdisk image (initrd.img).
Remember to edit your grub menu.lst and comment out the initrd line.
You say that you enabled all SATA modules, so I take it that you only use SATA. Be careful not to enable the deprecated SATA library, but instead use libata. This makes your disks available as SCSI devices, so you will need SCSI modules.
If in doubt, say y.
Try again and good luck.
I'm having the same problem w
I'm having the same problem with kernel panic, but as you can see from the .config piece below, the filesystem (ext3) has been compiled directly into the kernel. Still won't boot up! Panics, and reports that VFS thing.
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
Here are the lines from grub:
###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux 10.1
root (hd0,4)
kernel /boot/vmlinuz root=/dev/hda5 vga=0x31a resume=/dev/hda6 splash=silent showopts
initrd /boot/initrd
###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE Linux-Rosegarden
root (hd0,4)
kernel /boot/bzImage-2.6.7.11
I don't know. Should just work. Any ideas?
I got same error when I had f
I got same error when I had forgot to create /etc/fstab and /etc/mtab.
Possible Solution for : VFS unable to mount fs
I had this problem recently, and it ended up being a bad memory module.
Try running a memory test to eliminate this possibility. I pulled the bad stick of ram and the problem went away.
Cheers.
CG
I'm having the same problem
I'm having the same problem and unable to pull memory out notebook, any other suggestions? I'm running the kubuntu fiesty fawn 7.04.
you stupid! if you can't
you stupid! if you can't change the memory module, then have somebody do for you, what you expect somebody to come and do for you?. you make me sick!!
Kernel panic: VSF: unable to mount root fs
Dearest reader.
Ok, changing memory is not that hard, but it is not stupid not to do so in this case. Most boot/live cd's come with a memtest utility, for example the minimal lice cd of gentoo . You can simply type memtest at the boot: prompt. This will take some time though. Secondly, I am not quite sure it bad memory blocks are the only reason for this panic. Could it not simply be the absense of the image on the disk, the disk (for /boot) having a different device point in /dev, porn messing with the image. At this moment I have the same problem, I got it after ejecting the the drive on my sata port 1, leaving root on port 2. root Used to be sdb, but got sda and used to be (hd1,*) and got (hd0,*) (in grub). I changed the grub.conf (menu.lst) file to be correct, or so I think and I changed the fstab file. Afterwards I still had the kernel panic, therefore I am recompiling the kernel and all modules. After that I will copy paste the bzImage to /boot (or /boot/grub, I will ask google later).
Anyway, I don't think this kernel panic is a real nasty one, at least in my case.
Yours Sincerely,
foo-nix
if the author posted full kernel log...
If the author posted full kernel log up to the point where it panics, it would be easier to diagnose it.
You may not need a ramdisk
The kernels that come with distributions have to boot up on whatever hardware they find. To do so, they need all the mass storage drivers available. Compiling all those drivers into the kernel would waste a lot of memory and might not even work as some of the drivers are (were?) incompatible with each other. The solution is to put all the drivers in a ramdisk that is loaded by the boot loader. The kernel detects the hardware and requests the drivers from software in the ramdisk.
This is a large amount of confusion to dump on a newbie. A simpler answer for a single computer is to see which drivers are needed with lsmod, then compile them into the kernel. You will need the drivers for the hard disk with the root partition, the controller for that disk and the filesystem used for the root partition.
That unknown block device (0,0) could be an NFS mount (see linux-*/Documentation/devices.txt), but is far more likely to be because the kernel did not get the right root device from the boot loader. Add something like root=/dev/sda1 to the right place in the boot loader configuration file.
Guessing the device name of the root device has become quite difficult. There are some good clues in /proc/partitions.
Initial ramdisks are only required if a kernel has to boot on multiple machines or if you are doing something strange like making a raid array out of loop back encrypted files from multiple NFS servers. Keep it simple.