I'm upgrading my kernel from 2.4 to 2.6. If I choose the kernel 2.4 the Operating System stars, otherwise it tells me:
RAMDISK: compressed image found at block 0
RAMDISK: incomplete write(-1 != 32768) 4134304
VFS: cannot open root device "label=/" or unknown block(0,0)
Please append a correct "root" boot option
Kernel panic: VFS: unable to mount root fs or unknown block(0,0)
Tanks Bye
| high memory | 28 minutes ago | Linux kernel |
| semaphore access speed | 3 hours ago | Applications and Utilities |
| the kernel how to power off the machine | 4 hours ago | Linux kernel |
| Easter Eggs in windows XP | 6 hours ago | Windows |
| Shared swap partition | 7 hours ago | Linux general |
| Root password | 8 hours ago | Linux general |
| Where/when DNOTIFY is used? | 9 hours ago | Linux kernel |
| How to convert Linux Kernel built-in module into a loadable module | 12 hours ago | Linux kernel |
| Linux 2.6.24 and I/O schedulers | 12 hours ago | Linux kernel |
| USB Driver -- Interrupt Polling -- A Little Help Please | 18 hours ago | Linux general |
> VFS: cannot open root devic
> VFS: cannot open root device "label=/" or unknown block(0,0)
> Please append a correct "root" boot option
Here stands it!
Try /dev/hdX in the append line of your bootloader with the right name
of the root device e.g. /dev/hda1
What is the configuration file?
I found a configuration file in /etc "grub.config" and another in /boot. What's the right file? Both? Thanks
they're the same same file
/etc/grub.conf and /boot/grub/grub.conf are the same file.
/etc/grub.conf is just a symlink to the config file in /boot
ls -l /etc/grub.conf will tell you this
Ur answer
Real fine is /boot/grub/grub.conf .. But this real file has a link with /etc/grub.conf . So any change made in /etc/grub.conf file will be updated to orginal file of grub on /boot ..
did you create a new initrd image??
hi,
i learned that this is because it cannot load the correct type of system file driver, i.e. when you use ext3 or reiserfs...
make a new initrd, by doing these steps:
#cd /lib/modules
#/sbin/mkinitrd /boot/initrd-2.6.xx-whatever.img 2.6.xx-whatever
it will create a new initrd in /boot. Adjust the /boot/grub/menu.lst accordingly.
or you can compile suport to your file system inside the kernel (and not as a module...)
i hope this can help you. :-)
cheers,
Clovis Sena
When its an ext3 it will be m
When its an ext3 it will be mounted as ext2 when its a reiserfs as module your're right... :-)
Unfortunatly...
None of the sollutions will work, this is the same problem as here...
When somebody finds a sollution for this one please post it...
Unfortunatly... do not stand
Unfortunatly... do not stand there, that it was Debian. And i think its somebody who has not read the Documentation./usr/src/linux/Documentation/Changes or:
http://www.codemonkey.org.uk/post-halloween-2.5.txt
when it run here since months...
Well, can you please tell whe
Well, can you please tell where can we find more about this Debian bug and how to fix it?
/usr/src/linux/Documentation/Changes tells nothing about it, nor does the Post-Halloween Document... Besides, I can run 2.6.4 without problem, it's something between 2.6.4 and 2.6.5 :-(
I had a similar problem previously...
... and it had me really occupied a time ago. At that time I did not find a solution (this was way back at 2.6.1 or so...) Today I booted up my working 2.4.25 after some unrelated tweaking, when I spotted a message during bootup, that had not previously caught my eye; something similar to "/dev/hda remap +63", so I appended this to the 2.6.5 section in lilo.conf:
and voilá, now my 2.6.5 kernel boots!
Mista Linus
Linus Torvalds is a sexy beast!
kernel panic please append
Hello,
Sorry for my english ...
I had same problem but I found an issue :
Two partition was bootable on my disk, the first, master and one another where my / was. When I load the configuration file /etc/lilo.conf with lilo, I think it install it in the second bootable partition and non in the master. So two possibility : lilo -M for install in the master or remove the tag bootable to the second. With fdsik with "a" and the number of the second bootable.
It's ok for me now.
use other boot manager
use Grub or sbm. both much better than lilo.
http://btmgr.sf.net
RamDisk size too small
> RAMDISK: compressed image found at block 0
> RAMDISK: incomplete write(-1 != 32768) 4134304
this means that the initrd image could not be copied to the ram disk
because it is too big. You can either increase the size of the
ram disks (in kernel config, maybe it can be specified as boot param),
or you decrease the size of your initrd image. The redhat mkinitrd
script just allocates 8M, whatever size the initrd is going to be.
This is stupid, especially because the default size of the ramdisk
in the kernel config is 4M.
You could edit the mkinitrd script:
find the location where the image size is specified and decrease it.
hope that helps,
gamik
ramdisk size indeed!
fix: pass to kernel something like "ramdisk_size=32768", see also bootparam(7).
--
Michael Shigorin
have u tried this??
try... replacing "LABEL=/" by ur correct root device...
i.e. output of 'rdev' command
or mark your boot partition w
or mark your boot partition with tune2fs (in case it ext2/3) to set '/' label.
VFS: cannot open root device
VFS: cannot open root device "label=/" or unknown block(0,0)
its the problem in boot loader
related with root device
kindly check your root device.
Thanks