[SOLVED] No filesystem could mount root

Not sure if I'm asking this in the right place. I'm n00b to the embedded linux world (and linux world in general) and I'm trying to build an embedded CLFS for a ComExpress-P2020 board. Since embedded CLFS doesn't have a book for embedded CLFS for PowerPC, I've been doing a lot trial and error and guess work. I am using linux 2.6.38.2 and U-Boot as my boot loader.

Currently I'm stumped on why it cannot mount my filesystem. I am attempting to load an ext2 compressed filesystem from ram. I used genext2fs, gzip, and then mkimage to build the ramdisk image. Here is the last bit of the console when I try to boot.

List of all partitions:
No filesystem could mount root, tried:  ext2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Call Trace:
[ee441ee0] [c0007bd8] show_stack+0x48/0x180 (unreliable)
[ee441f20] [c026cb50] panic+0xa4/0x1e0
[ee441f70] [c02cc120] mount_block_root+0x298/0x2bc
[ee441fc0] [c02cc350] prepare_namespace+0x1a4/0x1e4
[ee441fd0] [c02cb5c8] kernel_init+0x208/0x224
[ee441ff0] [c000deac] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..

I've tried using ramdisk_size, but it doesn't seem to alter anything, so I have removed it. I've also read that changing ramdisk_blocksize to 1024 would fix a similar problem, however, when I tried that, the kernel doesn't get as far and then starts spitting out garbage. Here is the bootargs I ran to get the above output.

bootargs=root=/dev/ram rw console=ttyS0,115200


From scavenging the web, it looks like this indicates that either I don't have ext2 support loaded into my kernel or I'm missing the device driver for accessing the ram. As far as I can tell, I have both enabled. I have the following kernel settings set.

CONFIG_EXT2_FS=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=131072


My next guess would be that I'm setting up the device tree wrong... I'm building the device tree with arch/powerpc/boot/dts/p2020rdb.dts. My knowledge is very lacking on device trees...

I was also thinking maybe I botched fstab, but if it can't even load the filesystem, then I guess it wouldn't be at a point to read fstab configuration... Sigh, my knowledge is very lacking here.

I appreciate the help in advance. I will be MIA over this weekend, so I probably won't check back until Monday.

No, this is definitely the wrong place to inquire, but seeing as you did, we'll try to help. :-)))
Welcome to LQ.
My first suspicion is that the unzip part might not be happening. You have choices designed for embedded, and I'll mention 2: yaffs & squashfs.

Another way around is to treat the rootfs as an initrd. Your standard boot line looks like:

kernel some_kernel bootargs initrd some_initrd.gz

That's a gzipped cpio archive. THAT mounts on /. Usually it just has a /lib/modules/kernel-version tree, but you might make it a bit more substantial. When/if you load a / filesystem on top of it, it ceases to matter

Got a little further. Realized I had some things missing from my kernel. I switched the following from n to y.

CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y

Now I am getting a new error message.

EXT2-fs (ram0): error: unable to read superblock
List of all partitions:
No filesystem could mount root, tried:  ext2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Call Trace:
[ee441ee0] [c0007bd8] show_stack+0x48/0x180 (unreliable)
[ee441f20] [c026cb50] panic+0xa4/0x1e0
[ee441f70] [c02cc120] mount_block_root+0x298/0x2bc
[ee441fc0] [c02cc350] prepare_namespace+0x1a4/0x1e4
[ee441fd0] [c02cb5c8] kernel_init+0x208/0x224
[ee441ff0] [c000deac] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..

I assume that I am going down the path of your second suggestion, "Another way around is to treat the rootfs as an initrd." I'm wondering if I'm missing some other configuration and that is why it is unable to read from the ram...

No filesystem could mount root, tried: ext2

The error measns it failed at the 'mounting /' stage. The only filesystem in there that it tried is ext2. I suspect that may be cutting it a bit tight. Did you make a filesystem on the ramdisk? Full list of supported filesystems is in

cat /proc/filesystems

I'd read up on ramdisks - the long windy kind of crap that lists facts in a semblance of order but tells you everything.
http://www.linuxfocus.org/English/No...rticle124.html
http://www.vanemery.com/Linux/Ramdisk/ramdisk.html

S@w33t, I'm up and running... sort of. Kernel now boots, mounts the filesystem, and I can login. A lot of commands are broken and stuff is missing. I'm sure all my configs are incorrect, but at least I got a system to start working with.

I'm still not positive on how I got the ramdisk to successfully mount. I believe what solved my the mounting issue was the kernel configurations I was missing in my second post.

CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y

I think I was tired and copied the newly built kernel to the wrong directory. So tftp picked up the old kernel and not the new one (which is why I thought it was still broke).

I also ran into an issue with cache-sram-size=0x10000 in my boot args. That argument was creating the "EXT2-fs (ram0): error: unable to read superblock" error. Removing it resolved the issue and the filesystem was then being properly mounted.

And finally, I had issues with it running the init binary.

"No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance."

I added some printk() to run_init_process and saw kernel_execve was returning -2. After about three hours of guess work it finally dawned on me that I had installed lib's from a different toolchain into my /lib. Copied in lib's from the correct toolchain, and now we are cooking with fire ^_____^.

Thanks for the assistance.