# What does "VFS: Cannot open root device..." mean, exactly?

## wynn

Executive Summary

There are three similar messages:

 VFS: Cannot open root device "nnn" or unknown-block(maj,min)

Please append a correct "root=" boot option

VFS: Unable to mount root fs on unknown-block(maj,min) No filesystem could mount root, tried: (list of filesystems)

VFS: Unable to mount root fs on unknown-block(maj,min) (If CONFIG_ROOT_NFS is set in the kernel configuration)

VFS: Unable to mount root fs via NFS, trying floppy.In the first and second messages "nnn" is the device name entered on the kernel command line as "root=/dev/hda1" or "real_root=/dev/sda3". "(maj,min)" is taken from the root device setting in the kernel (you can inspect it by running, for instance:

```
# rdev /boot/kernel-2.6.17-gentoo-r7

Root device /dev/sda1
```

The root device is set when the kernel is compiled to the device mounted as "/" while the compilation is taking place.

In the first message, the kernel panic has occurred because VFS (Virtual File System, cf. Documentation/filesystems/vfs.txt) has not been able to access the root device as the block device code in the kernel hasn't been able to open it. The block device code, in this case, is the high level IDE (PATA) or SATA driver code and the low level chipset driver code. It is either partly or wholly missing or not built in to the kernel. It can also be caused, less often, by missing support for the MSDOS partition type, CONFIG_MSDOS_PARTITION, (or, perhaps the partition type appropriate for your arch).

In the second message, the device can be opened but the available filesystem drivers (ext2, reiserfs, jfs &c.) cannot recognize the filesystem on it. The drivers for the root filesystem are missing or are not built in to the kernel.

In the third message, CONFIG_ROOT_NFS has been set in the kernel configuration

```
Symbol: ROOT_NFS [=n]

 Prompt: Root file system on NFS

   Defined at fs/Kconfig:1635

   Depends on: NET && NFS_FS=y && IP_PNP

   Location:

     -> File systems

       -> Network File Systems
```

and mounting it has failed.

Experiments

Grubby earthbound experimentation can bring down elegant high flying theories.

A 2.6.18-gentoo-r1 kernel was compiled from scratch for an Athlon-XP with an IDE (PATA) drive and VIA IDE chipset. A basic .config was generated with "make defconfig" which had support for the Athlon and VIA chipset already built in. The disk was partitioned as

```
/dev/hda1       /boot   ext2

/dev/hda2       none    swap

/dev/hda3       /       ext3
```

grub.conf was

```
default 0

timeout 10

title=Gentoo Linux 2.6.17-r5

root (hd0,0)

kernel /kernel-2.6.17-gentoo-r5 root=/dev/hda3
```

The experiments changed one of the four components: ext2 filesystem support, ext3 filesystem support, IDE Disk support and VIA chipset support at a time from being built in to a module. After the results of the first two experiments, a third was squeezed in which had both ext2 and ext3 filesystem support as modules.

```

 1  2  3  4  5   experiment

 m  y  m  y  y   CONFIG_EXT2_FS=

 y  m  m  y  y   CONFIG_EXT3_FS=

 y  y  y  m  y   CONFIG_BLK_DEV_IDEDISK=

 y  y  y  y  m   CONFIG_BLK_DEV_VIA82CXXX=
```

For the first experiment only ext2 was a module, booting with just an error message "some filesystems failed to mount"

For the second, only ext3 was a module booting with a warning

```
EXT2-fs warning (device hda3)

ext2_ill_super: mounting ext3 filesystem as ext2

VFS: Mounted root (ext2 filesystem) readonly
```

For the third both ext2 and ext3 were modules and failed to boot

```
No filesystem could mount root, tried:

reiserfs squashfs vfat iso9660 jfs

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,3)
```

For the fourth the high level support for IDE disks was a module and failed to boot with a kernel panic

```
VFS: Cannot open root device "hda3" 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)
```

Removing the "root=" option resulted in

```
VFS: Cannot open root device "<NULL>" or unknown-block(3,3)

Please append a correct "root=" boot option

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,3)
```

In the fifth experiment the low level chipset support was made a module and booting failed with the same kernel panic as in the fourth experiment. Removing the "root=" boot option had exactly the same effect too.

An extra experiment with the filesystem support and the high and low level IDE drivers built in but with support for MSDOS partitions (CONFIG_MSDOS_PARTITION) removed failed with the message

```
VFS: Cannot open root device "hda3" or unknown-block(3,3)

Please append a correct "root=" boot option

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,3)
```

For the Intrepid Explorer:

The error messages appear in init/do_mounts.c (all paths are relative to the kernel source directory, this path, in full, is /usr/src/linux-2.6.18-gentoo-r1/init/do_mounts.c) in mount_block_root which calls do_mount_root just above it.

mount_block_root is called from mount_root and prepare_namespace in do_mounts.c.

In mount_root, create_dev is called to create "/dev/root" from ROOT_DEV and then mount_block_root is called with "/dev/root" as name and the root_mountflags as flags.

prepare_namespace is called when root is initially on a ramdisk; mount_root is called when the root device is NFS mounted, the kernel has been started from a floppy or, the usual case, a hard disk.

ROOT_DEV is set to ORIG_ROOT_DEV in arch/i386/kernel/setup.c and ORIG_ROOT_DEV is set in the boot_params section of bzimage. Its value is determined by the rootdev argument to arch/i386/boot/tools/build.c: if it is "CURRENT", ORIG_ROOT_DEV is set to the major and minor device numbers of the device currently mounted as "/".

If the argument is "FLOPPY", it will be set to the major and minor of the special file FLOPPY.

If the argument appears but doesn't match either of these, ORIG_ROOT_DEV will be set to major 0, minor 0.

If no argument appears (in this position) ORIG_ROOT_DEV will be set to major 0, minor 0.

The default in arch/{i386,x86_64}/boot/Makefile is "CURRENT".

Finally, in do_mount_root, sys_mount (from the VFS) is called with name (="/dev/root"), "/root", a filesystem name (like "ext2" or "reiserfs"), the root_mountflags and root_mount_data (which I haven't been able to unravel).

do_mount is called in a loop which will try all the filesystems which have been built in to the kernel, one by one.

If no error (=0) is returned from sys_mount, the device has been opened and the filesystem recognized.

If the error is "-EINVAL", then the device has been opened but the filesystem has not been recognized. If there are more filesystems to try, the loop will continue, otherwise it will exit and the "No filesystem could mount root, tried: " message will be issued.

If it is any other error, the block device has not been successfully opened, most probably because the high level or low level (or both) drivers have not been built in to the kernel or support for the partition type is missing.

Going back to the messages, the code is

```
printk("VFS: Cannot open root device \"%s\" or %s\n", root_device_name, b);
```

where root_device_name appears to be the name following "root=" on the kernel command line and b is ROOT_DEV split into block major and block minor numbers. In practice this is the compiled in root device but sometimes, although the same code is used (__bdevname is in fs/partitions/check.c)

```
__bdevname(ROOT_DEV, b);
```

unknown-block(0,0) is displayed. "name" is displayed as "<NULL>" if there is no "root=" parameter.

----------

## ebfe

you should add [GUIDE] or something like that to the topic

----------

## wynn

 *ebfe wrote:*   

> you should add [GUIDE] or something like that to the topic

 Trouble is, the subject only just went into the space available. Adding "[GUIDE]" would mean something would have to be taken out and it seems as though it is already the minimum that makes sense and advertises what it is about.

Your suggestions would be welcome though.

----------

## punkid

I was annoyed by this problem for quite a long time.I've went thru this whole thread,and did what it said,but still doesnt work on my box.

I've tried all the kernels (>2.6.13),they all failed,and gimme the 1st message.

```
VFS: Cannot open root device "nnn" or unknown-block(maj,min)

Please append a correct "root=" boot option

VFS: Unable to mount root fs on unknown-block(maj,min)
```

But the kernels <=2.6.13 do work.

My SATA Harddisk is Maxtor 6V160E0

```
Attached devices:

Host: scsi2 Channel: 00 Id: 00 Lun: 00

  Vendor: ATA      Model: Maxtor 6V160E0   Rev: VA11

  Type:   Direct-Access                    ANSI SCSI revision: 05

```

and I've enable these options in kernel with being built-in.

```
File systems -->

      <*> Second extended fs support                                              

           [*]   Ext2 extended attributes                                              

             [*]     Ext2 POSIX Access Control Lists                                      

             [*]     Ext2 Security Labels                                                 

             [*]   Ext2 execute in place support                                         

      <*> Ext3 journalling file system support                                     

             [*]   Ext3 extended attributes                                          

             [*]     Ext3 POSIX Access Control Lists                                    

             [*]     Ext3 Security Labels                                                 

      [ ] JBD (ext3) debugging support                                            

      <*> Reiserfs support                                                        

          [ ]   Enable reiserfs debug mode                                           

          [*]   Stats in /proc/fs/reiserfs                                           

          [*]   ReiserFS extended attributes                                          

             [*]     ReiserFS POSIX Access Control Lists                               

             [*]     ReiserFS Security Labels              

      ...

      Partition Types --->

         [*] Advanced partition selection

         [*]   PC BIOS (MSDOS partition tables) support 
```

And also here for the SCSI support.

```
Device Drivers--->

    SCSI device support --->

         [*]   legacy /proc/scsi/ support 

        <*>  SCSI disk support

                SCSI low-level drivers  --->

                <*> Serial ATA (SATA) support

                <*>   NVIDIA SATA support
```

Well,the same setting,works under kernel-2.6.13,but not >2.6.13

I changed another new Maxtor 6V160E0 harddisk for test,still the same.

OK,let me give you more details.Here's my grub.conf setting

```
title=Gentoo Linux

root (hd0,7)

kernel /boot/vmlinuz-2.6.13-gentoo-r5 root=/dev/sda9 video=vesafb:mtrr,ywrap,1440x900-32 
```

and my partition

```

Filesystem            Mounted on    PartitionType

/dev/sda9             /                   reiserfs

/dev/sda8             /boot             ext2

/dev/sda10           /home            ext3

```

So I'm wondering is this something wrong with the kernel? If it was,why the problem's still there after several kernel updates? Or something wrong with the harddisk? but at least it works under kernel <=2.6.13. 

Regards

----------

## wynn

Your post should really be in a separate thread as this is a document and it is posted in "Documentation, Tips and Tricks" which, it states, is not a support forum.

However, you seem to be missing the SATA chipset driver, you can find out which one to select by looking at the output of lspci.

----------

