• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 97 subscribers
  • Views 8727 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Why "mounting rootfs on / failed: No such file or directory" ?

Helmut Forren
Mastermind 6805 points

FIRST:

I get the subject error when booting my DM6467EVM-derived custom board, Linux 2.6.32, DVSDK 03.10.00.11.  Here's a console log:

[Thu Mar 22 17:49:57.422 2012] INIT: version 2.86 booting
[Thu Mar 22 17:49:59.004 2012] Please wait: booting...
[Thu Mar 22 17:49:59.372 2012] Remounting root file system...
[Thu Mar 22 17:49:59.698 2012] modprobe: FATAL: Could not open 'kernel/fs/minix/minix.ko': No such file or directory
[Thu Mar 22 17:49:59.699 2012] 
[Thu Mar 22 17:49:59.913 2012] root: mount: mounting rootfs on / failed: No such file or directory
[Thu Mar 22 17:50:02.101 2012] Mon Mar 14 18:09:00 UTC 2011
[Thu Mar 22 17:50:02.132 2012] INIT: Entering runlevel: 5

I'm not sure, but between this and the next output line, it *might* be costing me 2 seconds of boot time, that I want to optimize out.  I don't know what this "rootfs" is.  Everything is running fine.  File system is JFFS2 on NAND.  I don't know if this is germane, but note that the "df" output is:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 125568 19504 106064 16% /
tmpfs 16384 16 16368 0% /var/volatile
tmpfs 54788 0 54788 0% /dev/shm
tmpfs 16384 0 16384 0% /media/ram

I also get the same "mounting rootfs" error when I boot from nfs.  I'm thinking "rootfs" is something I don't have, and I'd like to not try to mount it.  I'm totally not sure.  I'm very new at this kernel stuff. 

SECOND:

If the two second delay from 17:49:59.913  to 17:50:02.101 is not due to this error, then what else might it be and how can I get rid of it.

THIRD:

That modprobe error doesn't appear to be costing me any boot time, and it doesn't appear to be harmful.  As I mentioned, my system runs fine.  Besides, that kernel/fs/minix/minix.ko path and file does INDEED exist at /lib/modules/2.6.32-MyCustomizedName/kernel/fs/minix/minix.ko.  Note that 2.6.32-MyCustomizedName is the same as reported by U-Boot during kernel load, and there are no other modules claimed to be missing, so I believe the "-MyCustomizedName" shouldn't be the cause of the problem.

Thanks!

  • 0
    Guru 26430 points

    I think the "rootfs" error comes from /etc/fstab. That file is contains generic file system table. It usually contains file systems that you probably don't even have or use. It also usually contains the wrong name for the rootfs entry. I have tried removing the rootfs line entirely and my system still booted normally. I chose to leave it in with a corrected name. Just in case something else depends on it.

    The modprobe problems are due to problem with the module dependency file (module.dep?). This is a sort of index for modprobe. For some reason I've never been able to figure out, some loadables modules such as minix.ko and ipv6.ko don't install properly. You need to to a "depmod -a" on the target. Unfortunately, there does not appear to be an equivalent cross-depmod for use on the host. Google gives some hints of such a tool from another platform. It means you need to copy any changes on the target back to your host for production. You may be able to copy just the module.dep file. If you don't use the MINIX file system, you could rebuild the kernel and modules without the minux option.

  • 0 in reply to Norman Wong
    Mastermind 6805 points

    Norman,

    This is excellent info and exactly the kind of guidance I need, for pressing further forward.  Analogy: It gets me headed within +/- 22.5 degrees of the direction I need to be headed, rather than the full 360 ambiguity I begin with.

    Since I won't be able to get back to this task until Monday, I wanted to go ahead and reply now, before being able to do anything about your suggestions.  Please note:

    1) I have notes elsewhere about overriding /etc/fstab from stock to machine-specific.  I thought that would be a back in cleanup, but now it seems it may be a 'now' optimization.  When two independent lines of investigation converge like this, it's a great thing.

    2) I've been learning more and removing unused stuff.  I googled and hadn't gotten to the point of realizing that MINIX is a file system and that minix.ko goes with that.  I can confirm a little bit, but I'm pretty sure i don't use it.  So I'll try getting rid of it altogether.  I'll search .config to see if that's the method of removing the minux option.  Anything removed will surely speed me up a little.  Otherwise, I'm beginning to understand the concept of get it going on the target and then copy back to nfs host for production of future targets.

    3) I'm proud to say I've gotten my power-button-to-live-codec-video-out boot time down from 137 to 27.5 seconds so far. 

    -Helmut

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    ...got some time.  dumb question number 211: What IS the correct name instead of "rootfs"?  df output appears earlier on this thread. When I remove that line, boot slows several seconds...

  • 0 in reply to Helmut Forren
    Guru 26430 points

    Google gives some sites in fstab format:

    http://www.tuxfiles.org/linuxhelp/fstab.html
    http://en.wikipedia.org/wiki/Fstab

    The name should be the device file of the media for the root file system. For the first partition of a SD Card, /dev/mmcblk0p1. For fourth MTD block, /dev/mtdblock3. I usually use whatever is the value for the "root=" bootarg. Something like:

    /dev/mtdblock3  /  auto defaults 1  1

    Your df prints out "/dev/root". That's probably a symbolic link to "/dev/mtdblock3"? You might able to use that in the fstab:

    /dev/root  /  auto defaults 1  1

    The question is who creates "/dev/root"? Hopefully not udev.

    Not sure what happened if you use the same fstab file on your NFS server and in the NAND file system. I suspect "rootfs" is not recognized by the embedded version of mount. It seems okay with procfs, tmpfs, devpts, etc. Why not "rootfs"? No idea. I usually just the actual media device name. Linux just tires me out sometimes.

    There had got to be better way to do this. My ignorance of the subject is showing. If you find a correct solution, please share.

    EDIT: Grammar, spelling

  • 0 in reply to Norman Wong
    Mastermind 6805 points

    Interesting,  /dev/mtdblock3 leads to the same kind of error:

    [Fri Mar 23 18:13:03.152 2012] INIT: version 2.86 booting
    [Fri Mar 23 18:13:04.733 2012] Please wait: booting...
    [Fri Mar 23 18:13:05.101 2012] Remounting root file system...
    [Fri Mar 23 18:13:05.644 2012] root: mount: mounting /dev/mtdblock3 on / failed: Invalid argument
    [Fri Mar 23 18:13:07.002 2012] Mon Mar 14 20:38:00 UTC 2011
    [Fri Mar 23 18:13:07.034 2012] INIT: Entering runlevel: 5

    where /etc/fstab now looks like:

    # stock fstab - you probably want to override this with a machine specific one

    /dev/mtdblock3 / auto defaults 1 1
    proc /proc proc defaults 0 0
    devpts /dev/pts devpts mode=0620,gid=5 0 0
    # usbfs /proc/bus/usb usbfs defaults 0 0
    tmpfs /var/volatile tmpfs defaults,size=16M 0 0
    tmpfs /dev/shm tmpfs mode=0777 0 0
    tmpfs /media/ram tmpfs defaults,size=16M 0 0

    # uncomment this if your device has a SD/MMC/Transflash slot
    #/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0

    Nevertheless, booting works but SLOWS DOWN when I remove the first line altogether.

    I think I need to hang this up for a while.  I did trim another 1.5sec by removing a bunch of CONFIG's from the kernel. I'm down to 25.8sec from power-button-to-live-codec-video-out.

    Thanks for all your help.  On to something else...