Good evening all!

I just started building a file server from the ground up to learn a little bit (Linux from Scratch v6.7 stable). Everything was going well until an old IBM DeathStar cropped up (I honestly thought that I had gotten rid of all of them). The disk imploded, of course, but I had backed it up and had a copy of the data. When I restored to a new disk (Western Digital Blue, in parallel (PATA) to match the failed IBM disk), I get the message:

Kernel Panic: not syncing: VFS: Unable to mount root fs on unknown block (0,0)

The part where my understanding stops is that I have put an EXACT COPY of the old disk on the new disk. What in the world would cause a new disk with a restored copy of an old disk not to boot? What am I missing here?

Thanks!

DJ
dj@fluidnetwork.com

Somehow, your kernel seems to be thinking that the root filesystem isn't set. So either you've specified it wrong, or it isn't specified at all.

Before you get this message, you should be able to enter a boot-menu. Modern systems have "grub". If you intercept it (by pressing a key) you should be able to view and modify the boot entries. If you don't know which of your partitions it is, try all of them in succession. But you should be able to figure it out...

I don't think that I did too good of a job explaining the situation... When the one drive went down, I took
a backup set that I had made earlier in the day (talk about timing!), restored to the new drive, reinitialized
the MBR via grub, and now the system is not booting with Kernel Panic VFS not syncing.

Given that the old IBM drive has now failed, I have replaced it with a (more) modern drive that runs on
the same interface (PATA), with the EXACT same kernel, filesystem, initialization vectors and variables used
on the old drive (I saved my sources and command lines used so that in the event of failure, I would have an
exact copy to restore from). Also given is that the chain has been checked to the best of my ability to ensure the
hardware is known good: after the problems getting Linux to run, I installed a copies of both windows 7 and xp to
test the functionality of the drive, changed the IDE cable, and checked the power supply on another machine.
Each time, windows loaded itself and is able to boot with no issues. Every now and again, I can get the old IBM GXP
to spin up and boot Linux successfully.

The kicker is, when I take the new WD Blue with copied file structure, I know, there hasn't been anything new as far
as interface improvment on the PATA front in a LONG time... what makes this drive different so that the kernel on the
old drive boots (when the drive spins up!) and the new drive doesn't? What in the world would make a difference to
kernel and file system mounts? The new drive was even put in the same position on the IDE chain to prevent errors
related to incorrect bus position.

Oh, I am sorry that I cannot give the exact line at the moment as I am nowhere near the machine, but I do remember
something directly after the VFS error line as to the effect of offering correct partitions to choose from, but they
only show the CDROM drives, **NOT** the drive that the kernel is loaded from... why wouldn't the disk be recognized??
Wasn't the kernel itself just loaded from the now-disappeared drive? For what it matters, fdisk -l from a LiveCD
boot sees the disk just fine, as where it is expected (/dev/hda[x]).


Ideas?

Dear Dtex, if you state that the new situation is exactly the same as before, the system would boot. Linux doesn't care if it is an IBM or an WD drive! I'm really 100% sure!

So there MUST be a difference. Now feel free to reread my message again. You've done a reasonable job in explaining the situation the first time, because my reply is basically the same.

Sounds like you might have missed the "initrd=" in the grub setup.

Rew, I have read the reply and did take it into consideration. As far as using grub's menu and initrd, neither of your suggestions are appropriate to the situation. The machine does not use an initrd; all filesystems needed are compiled into the kernel (and, in case of emergency, a second kernel was compiled with *every* option enabled so there was never a question of missing modules.... same effect with the kernel panic). As to the grub menu, everything is the same between the old disk and the new disk, down to checking the md5sums on the kernels and grub.

The question on disk differences is more towards are there changes in disk firmware, etc, that would give rise to this type of problem? Is the new disk taking longer to report partition tables or the spindle speed not coming up fast enough (don't think this is a problem as grub is getting the kernel off the disk in time for it to panic)? Anything?

I am at a loss. If you can think of any other way of verifying sameness of systems between the two disks and the backup other than md5sum, or even what files might have been effected, please share!

Yes different brand disks run different firmware. They might take different times between "poweron" and "becoming ready". The specs state a computer should wait up to 60 seconds for a slow drive to become ready. Linux might be naughty and wait only 30 seconds. But because grub already got your kernel, the drive IS ready.

Different disks will take different times to read the partition table from the drive. Modern drives have an average seek time of under 10ms, and a max rotational latency of 8.3ms. For a total of 20ms. So one drive might have reported the partition table in 7ms while the other drive takes 17ms. Linux will wait something like 30 seconds before it will reset the drive and try again.

Your kernel panics. So, from this I deduce that your kernel booted. So it is not a case of not finding the kernel.

If you specify "root=/dev/sda3" on the kernel command line, it would print: "unable to mount root (8,3)". So from this I deduce that you did NOT specify the root partition that way.

Now I think that if the initrd is missing, I think it would print (0,0). But you are saying you're not using an initrd anyway. Fine.

I would suggest you add "root=/dev/sda1" to your kernel command-line. If you get "unable to mount root (8,1)", we're one step closer to the solution.

Why don't you have an "initrd"? Any recent distribution will give you an initrd.

Now although we have hints that it is something different, it might be that it didn't detect the harddrive. (This could happen if you DID have an initrd, but just didn't think so, and now you don't) So, can you watch while it is booting to see if you see anything about a detected harddrive?

When troubleshooting, if you're sure you can rule something out, you might get stuck because it IS something that you've ruled out.