VFS: cannot open root device "mtdblock2" or unknown-block (2, 0)

Document directory

• NFS mount the root file system

[Problem]

After the system is started, although the NAND driver is normal, an error occurs when rootfs is mounted:

Kernel command line: Root =/dev/mtdblock2 RW init =/linuxrc console = ttyama1, 115200 mem = 64 m rootfstype = yaffs2
....
....

Asw.x NAND driver, (c) 2010 austriamicrosystems
Asw.x_nand_probe
Nand clock set to 24000000
Nand: res-> Start at e60000
Nand: mapped registers at c48dc000
Asw.x_nand_inithw
Nand: initialising set 0 (c3a62800, info c3a934e0)
Asw.x_nand_init_chip
Nand device: Manufacturer ID: 0xec, chip ID: 0xd3 (Samsung NAND 1gib, 3 V 8-bit)
Scanning Device for Bad blocks
Bad eraseblock 2262 at 0x11ac0000
Bad eraseblock 3151 at 0x189e0000
Bad eraseblock 3649 at 0x1c820000
Bad eraseblock 5198 at 0x289c0000
Bad eraseblock 6842 at 0x35740000
As353x_nand_add_partition
Creating 5 MTD partitions on "NAND 1gib 3, 3 V 8-bit ":
0x00000000-0x00100000: "U-Boot"
0x00100000-0x00900000: "kernel"
0x00900000-0x0d100000: "root filesystem"
0x0d100000-0x11100000: "Temp"
0x11100000-0x3d700000: "data"
Nand: initialised OK
.......
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root FS via NFS, trying floppy.
VFS: cannot open root device "mtdblock2" or unknown-block (2, 0)
Please append a correct "root =" Boot option; here are the available partitions:
Kernel panic-not syncing: VFS: Unable to mount root FS on unknown-block (2, 0)

[Solution process]

1. I thought there was no/dev/mtdblock2 device in rootfs, and then I went to the file used to create rootfs for verification. The rootfs contained these devices:

[Crifan @ linux-41lh root] $ ls Dev/MTD *-l
-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtd0
-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtd1
-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtd2
-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtd3
-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtdblock0
-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtdblock1
-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtdblock2
-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtdblock3

【!!! This understanding error->] In addition, it is confirmed and confirmed that these Block devices are generated inside the system when the system accesses/dev/mtdblock2, even if you do not create these device files in your rootfs, it will not be affected.

2. I thought there was a problem with rootfs data. Later I found that rootfs Data Reading and Writing was not involved, because it was not mounted successfully yet.

3. My colleague reminded me whether MTD block device support is set. So go to the kernel source code and check the Configuration:

Make arch = arm menuconfig

In Device Drivers-> memory technology device (MTD) support --->

The following options are available:

Caching block Device Access to MTD Devices

After reading its help:

Memory technology device (MTD) Support --------------------------------------------- +
| Config_mtd: |
|
| Memory technology devices are flash, Ram and similar chips, often |
| Used for solid state file systems on embedded devices. This option |
| Will provide the generic support for MTD drivers to register |
| Themselves with the kernel and for potential users of MTD devices |
| To enumerate the devices which are present and obtain a handle on |
| Them. It will also allow you to select individual drivers for |
| Particle hardware and users of MTD devices. If unsure, say n.

And Online Search:

7.1 MTD-supported devices

Caching block Device Access to MTD devices, config_mtd_block

This is the configuration option for the read-write block device MTD user module that is visible/Dev/mtdblockn. If you configure this as a module, the module's filename isMtdblock. o.

It is known that this is the corresponding MTD block device option. Therefore, you can add MTD block device support after selecting and re-compiling.

You can also access the above/dev/mtdblcok2.

[Postscript]

1. after actual tests, it is found that/dev/mtdblockn in rootfs still has a relationship, and its system will still access this MTD device, /dev/mtdblockn is connected to the underlying block device, which is correct:

[Root @ linux-41lh root] $ ls Dev/MTD *-l
CrW-r ----- 1 Root 90, 0 2009-11-16 :06 DEV/mtd0
CrW-r ----- 1 Root 90, 2 2009-11-16 DEV/mtd1
CrW-r ----- 1 Root 90, 4 2009-11-16 DEV/mtd2
CrW-r ----- 1 Root 90, 6 2009-11-16 DEV/mtd3
Crwxr-XR-x 1 Root 90, 8 2009-11-16 15:06 DEV/mtd4
BRW-r ----- 1 Root 31, 0 2009-11-16 DEV/mtdblock0
BRW-r ----- 1 Root 31, 1 2009-11-16 DEV/mtdblock1
BRW-r ----- 1 Root 31, 2 2009-11-16 DEV/mtdblock2
BRW-r ----- 1 Root 31, 3 2009-11-16 DEV/mtdblock3
Brwxr-XR-x 1 Root 31, 4 2009-11-16 15:06 DEV/mtdblock4

As we can see above:

-RW-r ----- 1 Eric develop 0 2010-01-12 13:58 DEV/mtdblock2

This is obviously not a device file, so it is abnormal.

Therefore, you need to generate the corresponding device file and put it in rootfs, and then persistently stick to the roofs image file (here I use mkyaffs2image to access the root/folder and the files below it, create a rootfs file for yaffs2 ).

NFS mount the root file system

Recently, the experiment mounted the root file system from the NFS server. I used the redhat-2.6.18 kernel, after re-compiling the kernel. The following error message is displayed during startup:

.....
Looking up port of RPC 100003/2 on 192.168.1.2
Portmap: RPC call retured error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.1.2
Portmap: RPC call retured error 101
Root-NFS: Unable to get mountd port number from server, using default
Mount: RPC call returned error 101.
Root-NFS: Unable to get mountd port number from server, using default
Mount: RPC call returned error 101.
Root-NFS: server returned error-101 while mounting/tftpboot/nfs
VFS: Unable to mount root FS via NFS, trying floppy
VFS: cannot open root device "NFS" or unknown-block (2, 0)
Please append a correct "root =" Boot Option
Kernel panic-not syncing: VFS: Unable to mount root FS on unknown-block (2, 0)

My default file configuration is as follows:
Default local
Timeout 100
Prompt 1
Display msgs/boot. msg
F1 msgs/boot. msg
F2 msgs/General. msg
F3 msgs/expert. msg
F4 msgs/Param. msg
F5 msgs/rescue. msg
F7 msgs/snake. msg

Label local
Localboot 1

Label 0
Localboot 1

Label 1
Kernel ../boot/bzimage
Append root =/dev/nfs RW nfsroot = 192.168.1.2:/tftpboot/nfs IP = DHCP

The NFS configuration file is as follows:
/Tftpboot * (RW, no_root_squash, sync)

In the kernel compilation File
Config_root_nfs = y
Config_ip_pnp = y
Config_ip_pnp_dhcp = y
Config_ip_pnp_bootp = y
Config_ip_pnp_rarp = y

The reason is that no NIC Driver is compiled in the kernel, as long as the corresponding NIC Driver is compiled in the kernel.