1

What is the naming scheme of MTD partitions listed in the following boot log?

5 cmdlinepart partitions found on MTD device phys_mapped_flash
Creating 5 MTD partitions on "phys_mapped_flash":
0x00000000-0x00080000 : "bootloader" 
0x00080000-0x00680000 : "kernel"
0x00680000-0x01680000 : "rootfs" 
0x01680000-0x01780000 : "data"
0x01780000-0x017a0000 : "bootload-env"

In particular, I am asking what naming scheme to use to specify the "rootfs" partition in the U-Boot prompt as an argument to the command:

setenv bootargs 'root= ???????'

IMO, I need to specify the root= because the boot log shows, that the kernel does not know what the root device is.

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

...and also the boot log shows:

Kernel command line:  bootoctlinux 0x2a00200 mtdparts=phys_mapped_flash:512k(bootloader)ro,6M(kernel),16M(rootfs),1024k(data),128k(bootload-env) console=ttyS0,115200

BTW: The root file system is stored in an embedded section (.init.ramfs) of the kernel ELF file (vmlinux64) as a gzipped cpio archive and the boot log indicates, that it is loaded into RAM successfully:

Loading .init.ramfs @ 0xffffffff806ac000 (0x185ac7 bytes)

This is on an embedded system with 32MB of flash storage only ( Linux kernel v2.6.21.7 ( Distro: Cavium-Octeon for MIPS64 ) ).
U-Boot 1.1.1 (Development build, svnversion: 176)

EDIT: Some people say it is MTD1, some that MTD2 some /dev/MTD1, some /dev/mtd1, some that it is MTDblock1, some mtdblock1, some mtdblock2, some ubi.mtdblock1, some ubi:mtdblock1, (why the colon?) etc....
What is the truth? How can it be discovered from only the U-Boot prompt or the boot log?

0

root=/dev/mtdblock3 or some UBI options. You haven't noticed that the different advice is for different filesystems :-). I don't know if /dev/mtd3 is used for any in-tree filesystem.

If then root filesystem is a read-only instance of a block-based (non-mtd-aware) filesystem, then use /dev/mtdblock3.

If the root filesystem is an instance of JFFS2, then use /dev/mtdblock3. See https://www.denx.de/wiki/DULG/RootFileSystemOnAJFFS2FileSystem In general and for some examples of other filesystems, you may check out http://www.denx.de/wiki/publish/DULG/DULG-enbw_cmc.html#Section_9.5. (but this section does not mention UBI).

If rootfs uses UBI, use some UBI options. You haven't shown any details about UBI though - there should be some kernel boot messages about UBI devices/volumes, before you can get root= to work with any UBI device/volume. See here: http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mount_ubifs It gives an example of UBI options: ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs. Since your mtd partition is directly called "rootfs", I expect it is not UBI.

I would avoid using the root=mtdblock3 format, at least if you are not sure. The difference is that it might not be supported by some initramfs. Whereas, the kernel understands the format root=/dev/mtdblock3, when you use the kernel to mount the root filesystem and do not use an initramfs.

  • So you think that these MDT partitions are numbered form 1 (as opposed to from zero). That is a big help already! I also think, that the different advice must for different systems and I think that there is no UBI on that system. What surprises me, that I expected the ramfs root file system to be in RAM (page caches) and populated by the ungzipped cpio archive from the vmlinux64 ELF file section (.init.ramfs)... not in an MTD flash memory. Does the "phys_mapped_flash" confuse matters ? – George Robinson Jul 16 '18 at 22:34
  • ah... I didn't think about 0 v.s. 1-based indexing, sorry. It looks like I assumed 1-based indexing and the document I linked confirms it, but if so this is a happy accident :). – sourcejedi Jul 16 '18 at 22:52
  • @GeorgeRobinson no, what I think confuses you is that people abbreviate "root filesystem" as "rootfs", and this is entirely separate from the kernel filesystem type "rootfs" which is used for the initramfs. Really horribly confusing and it would be nice if the kernel people had anticipated this confusion when they named it! – sourcejedi Jul 16 '18 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.