FC2; VFS: Cannot open root device "LABEL=/" or unknown-block(0,0)
FedoraThis forum is for the discussion of the Fedora Project.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Location: At a tea party with Alice in Wonderland.
Distribution: Fedora 7
Posts: 65
Rep:
FC2; VFS: Cannot open root device "LABEL=/" or unknown-block(0,0)
I haven't managed to find a solution to this. I've seen different people getting this or a similar error, but for different reasons.
I've put the background info a bit further down.
Description of the error:
Full error Message:
VFS: Cannot open root device "LABEL=/" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel Panic - not syncing: VFS Unable to mount root fs on unknown-block(0,0)
After this, the system hangs.
The message occurs during boot-up right after
Loading jdb.ko module
Loading ext3.ko module
Creating block devices
curiously (to me) is that a few lines up we have:
VFS: Mounted root (ext2 filesystem)
The kernels I've tried are all stock kernels;
2.6.9-1.6_FC2
2.6.9-1.3_FC2
2.6.7-1.494
2.6.5-1.358
Same result with all of them.
grub.conf:
Code:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd1,4)
# kernel /vmlinuz-version ro root=/dev/sdb6
# initrd /initrd-version.img
#boot=/dev/sda
default=6
timeout=10
splashimage=(hd1,4)/grub/splash.xpm.gz
title Fedora Core (2.6.9-1.6_FC2)
root (hd1,4)
kernel /vmlinuz-2.6.9-1.6_FC2 ro root=LABEL=/
acpi=ht
initrd /initrd-2.6.9-1.6_FC2.img
title Fedora Core (2.6.9-1.3_FC2)
root (hd1,4)
kernel /vmlinuz-2.6.9-1.3_FC2 ro root=LABEL=/
acpi=ht
initrd /initrd-2.6.9-1.3_FC2.img
title Fedora Core (2.6.8-1.521)
root (hd1,4)
kernel /vmlinuz-2.6.8-1.521 ro root=LABEL=/
initrd /initrd-2.6.8-1.521.img
title Fedora Core (2.6.7-1.494.2.2)
root (hd1,4)
kernel /vmlinuz-2.6.7-1.494.2.2 ro root=LABEL=/
initrd /initrd-2.6.7-1.494.2.2.img
title Fedora Core (2.6.6-1.435.2.3)
root (hd1,4)
kernel /vmlinuz-2.6.6-1.435.2.3 ro root=LABEL=/
initrd /initrd-2.6.6-1.435.2.3.img
title Fedora Core (2.6.5-1.358)
root (hd1,4)
kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/
initrd /initrd-2.6.5-1.358.img
title Windows
rootnoverify (hd0,1)
makeactive
chainloader +1
The drive itself is a SATA drive; Maxtor 7Y250M0
I've tried root=/dev/sdb6 ,(my root partition) but no dice.
Background
I got a new PC.
My old PC has 1 120Gb Hd with win and 1 30 Gb hd with linux (both PATA).
My new PC has 2 250Gb SATA drives + 1 160Gb portable PATA hd.
I tansfered my old linux system with dd to the new computer via the portable drive. So fara so good. The partitions were also resized to take
advantage of the increased disc-space. Though I could not resize the root partiton for some reason.
parted says that it has some oddities, that may cause (fixable) problems. Though it has always said that, iirc. It was originally created with PQ:s Partition Magic 8.0, but that program can't resize it either.
So instead of resizing the root partition, I just created a new one (tried merging it with the root partition, but no success )
grub also installed without any problems (well a few, but none irreversible, and they were caused by my own silliness ).
fstab is also updated to reflect the new hd layout.
All is booting fine on the old computer.
Any suggestions appreciated.
I'm also considering upgrading to FC3, hoping that that might kill the problem.
ok, /dev/sda5 doesn't exist yet, but I can't see how that could cause the problem.
And I see haven't added sdc yet either. That's the portable disc, btw.
Location: At a tea party with Alice in Wonderland.
Distribution: Fedora 7
Posts: 65
Original Poster
Rep:
Thanx, but I actually tried that, out of desperation and tiredness.
However, that root command above kernel, root (hd1,4), is used by grub to find the boot partition.
The kernel image is relative to this path. The kernel images are found and loaded fine, until we need the stuff on root.
So that is as it should be.
(Btw setting this to hd1,5 will cause the system to hang much earlier with a different error message, as I have no kernel images on hd1,5.)
The second root (root=LABEL=/), is a kernel command-line parameter. And also the one mentioned in the error msg.
hey i am out of options here
all the problms that i have seen have occered due to
incorrect entry in grub.conf
or
using kernel with no ext3/ext2 / FS support
or
sometimes when i have grub.conf on non-primary master hdd
then too some grub reacts ina undefined way, so i keep grub on primary hdd
Location: At a tea party with Alice in Wonderland.
Distribution: Fedora 7
Posts: 65
Original Poster
Rep:
Well, thanx for your help and effort.
As far as I can tell, my grub.conf i sound.
The fs support is there.
grub.conf is on a secondary master, though this hasn't been a problem in the past.
Anyhoo, I tried to uppgrade to FC 3, see if that will solve it. Guessing it has a later version of grub as well, not that I've checked.
Ran in to an unrelated install bug, though one with a workaround, so it'll take a while longer to know if uppgradeing will fix it.
Additional Comment #1 From C.Laurence Gonsalves on 2004-06-30 14:50 -------
It looks like the problem was due to the initrd being incomplete. In
particular, I think it was missing the ata_piix module. To fix this, I
ran the following:
and then I modified my grub parameters in two ways:
- I changed the initrd line to refer to the output of the above
command
- I changed the root= option to use /dev/sda3
My system is now able to boot again. So there appears to be a problem
in the way the FC2 installer constructs the initrd that it installs on
some systems.
Now my system boots up as it should!
Though, I still have root=LABEL=/ as kernel parameter, not root=/dev/sdb6
Now I have a few other things to fix, as my new keyboard is usb now, not ps/2...
kudzu could prolly fix it for me, but it's waiting for a keyboard press to activate
Anyway, I'll com back and open an other thread, should I not be able to solve this on my own.
I am having a simillar problem. I am tring to compile a new kernel from 2.6.10-1.771_FC2 to shrink the size of the modules and image. I know I can compile a working kernel from this source, I've done it before, but now that I am trying to reduce the size of it I keep getting a kernel panic.
I notice that after the computer probes for IDE interfaces it brings up hda and it doesn't know what fs it is. Is there something I should have compiled that involves the root filesystem that I forgot. I thought I compiled all EXT2 and EXT3 support.
UDF-fs: No partition found : My solution! It's reiserfs.
My story is this:
I've been using the reiser file system for years and have been very happy with it and have kept up with new releases as they were available. Then one day I compiled a new kernel and got the UDF-fs: No partition found error.
I tried everything to resolve this problem and searched the web for an answer with no luck. I went back to my old kernel and the problem went away, but every attempt to use any new kernel failed in the same way. I researched and tried every suggestion to fix the problem.
Then I finally narrowed it down to the filesystem. The file system I was using was the new reiser4. I may have seen this problem with reiser3 also....not sure. It seems that when you compile a new kernel, the reiser file system will not access the hard drive without some manipulation with the reiserfs tools.
This also fixed a problem with compiling the NVidia graphics driver.
I reinstalled using the ext3 file system and now have no problem with the UDF-fs: No partition found error or the NVidia driver.
Also: I find that the ext3 file system works every bit as fast and good as the reiser file system. I guess I'll stick with ext3 from now on.
I have nonstandard boot configuration so I get lots of practice with booting weirdness....I have to have my jaz drive on the first channel of my 39160 because of the 50 pin connector but plugging a u160 device to this channel seems to slow it down ro 40or80Mhz. So.. the primary boot device is on the second channel and currently I'm booting on the second drive of the 2nd channel.
Now.. when GRUB is running it doesn't recognize the jaz drive as it is currently disabled as a boot device although I have booted from the jaz in the past - the point of all this being that grub's root device and linux's boot device are not the same thing. It is perfectly ok to point grub to a kernel on (hd0,0) and tell the kernel that you mean sdb for root.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.