2008-02-23 15:55:11     vmImage with jffs2 root file system

Document created by Aaronwu Employee on Aug 5, 2013
Version 1Show Document
  • View in full screen mode

2008-02-23 15:55:11     vmImage with jffs2 root file system

J. William Campbell (UNITED STATES)

Message: 51562    I have encountered what I think is a bug. If I download the uImage produced by 2008R1-RC1, everything works as expected. However, if I burn a vmImage and rootfs.jffs2 into the serial flash, I have observed the following. First, if the root file system is full enough that there are no free 65K sectors, the system does not create /var/log/messages and you periodically get the message init: /bin/watchdogd respawning too fast followed by init: /sbin/syslogd respawning too fast. A root file system containing a full free sector does not do this. Second, although the system operates normally with the larger file system, I find that the system is writing into the root file system on the flash. Exactly what it is writing, I am not sure. This is not a one-time thing either. You can make an image of (in my case) /dev/mtdblock2 via ftp to another computer at one time, come back 10 minutes later, do it again, and the files differ. This is with no user applications running, the system just sitting at a command prompt. Obviously this is not good in that it will eventually wear out the flash, but I also didn't expect this to occur. I tried changing the bootargs to mount the root read only instead of read-write. This works, except you then get the respawning too fast messages back and have no /var/log/messages. I am at a loss to explain this, as /var and /var/log are created on what should be a ram files system by /etc/rc, so /var/log/messages should be rw even if the / directory is not.

 

Any ideas?

QuoteReplyEditDelete

 

 

2008-02-23 16:15:39     Re: vmImage with jffs2 root file system

Mike Frysinger (UNITED STATES)

Message: 51563    watchdog does not care about free space ... it does care about being able to open its device node read/write ... so if your /dev is not created properly, it would screw up the watchdog

 

to find out what processes have what files opened and in what mode, you can use the fuser or lsof utilities

QuoteReplyEditDelete

 

 

2008-02-24 15:27:25     Re: vmImage with jffs2 root file system

J. William Campbell (UNITED STATES)

Message: 51566    Mike, you are exactly correct. It appears that the rc files in all the blackfin processors share a flaw when mdev is used. Instead of mounting a new /dev as a tmpfs, mdev is allowed to modify the /dev on the root file system. With a uImage, this works correctly, since the root file system is a ram file system anyway. However, if the root is a "real"  file system, mdev will attempt to modify that file system every time the system is booted. This is bad wear -wise and time-wise for a jffs2 file system and naturally fails completely if the root is mounted read-only. I have a modification of the rc file listed below that solves the problem, working both with a uImage and a jffs2 root file system.  When you get a chance, could you please look it over to make sure there are no bad effects that I haven't seen, and if there are none, incorporate it into the tree? These lines are lines 2 through 19 of the stamp rc file after modification.

 

mount -t proc proc /proc

mount -t ramfs ramfs /var

mount -t sysfs sysfs /sys

[ -d /sys/kernel/debug ] && mount -t debugfs debugfs /sys/kernel/debug

[ -d /proc/sys/fs/binfmt_misc ] && mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc

[ -d /sys/kernel/security ] && mount -t securityfs securityfs /sys/kernel/security

grep -qs nfsd /proc/filesystems && mount -t nfsd nfsd /proc/fs/nfsd

if [ -e /bin/mdev ] ; then

        mount -t tmpfs -o rw mdev /dev

        chmod 0755 /dev

        mknod -m 0755 /dev/null c 1 3

        mkdir /dev/pts

        chmod 0755 /dev/pts

       echo /bin/mdev 2>/dev/null > /proc/sys/kernel/hotplug

       /bin/mdev -s 2> /dev/null

fi

mount -t devpts devpts /dev/pts

mkdir /var/tmp /var/log /var/run /var/lock

QuoteReplyEditDelete

 

 

2008-02-24 23:22:50     Re: vmImage with jffs2 root file system

Yi Li (CHINA)

Message: 51573    user/blkfin-apps/watchdogd/Makefile:

 

"$(ROMFSINST) -e CONFIG_USER_BLACKFIN_WATCHDOGD -a "watchdogd:unknown:/bin/watchdogd -f -s" /etc/inittab

"

 

This may cause trouble if the watch dog driver is not enabled in kernel.

QuoteReplyEditDelete

 

 

2008-02-25 13:58:19     Re: vmImage with jffs2 root file system

Mike Frysinger (UNITED STATES)

Message: 51612    that line would only be executed if you enabled the watchdog userspace daemon ... so yes, if you enable the userspace daemon but not the kernel driver, you'd hit a problem.  but that's your fault

QuoteReplyEditDelete

 

 

2008-02-25 14:04:18     Re: vmImage with jffs2 root file system

Mike Frysinger (UNITED STATES)

Message: 51615    you should not have to create the null device ... `mdev -s` will generate it for you

 

all you need is the mount+mkdir:

mount -t tmpfs mdev /dev -o exec,nosuid,mode=0755,size=10M

mkdir /dev/pts

 

the rc files for the Analog Devices boards left out these steps as the default build is out of ram, so i didnt bother mounting /dev as well.  it is also confusing to users if they add stuff to the device table as their nodes would "disappear" from /dev.  anyone porting to their own board is expected to customize all the files according to their needs as our default configuration targets a development environment, not a production setup.  i can add commented out lines to the default rc file to assist people though.

QuoteReplyEditDelete

 

 

2008-02-25 15:51:32     Re: vmImage with jffs2 root file system

J. William Campbell (UNITED STATES)

Message: 51626    Thanks Mike. It turns out that you DO need to create /dev/null before you execute mdev with /dev/null as an output file. If you don't you end up with a regular file as /dev/null, instead of a device file. I actually tried this to make sure! While I don't totally buy your position that the default build is out of ram so it doesn't matter, you point that entries made to the device table will disappear (which would have been a modification from the default build anyway) is a good one. This has led me to an improved script that preserves these entries and is actually shorter than the original. Perhaps you could add this second attempt, (preferably alive but commented out is ok if you prefer) I have tested it and it works fine for me. I have omitted the size on the tmpfs without any obvious harm, but feel free to put it back if it is in some way better!

if [ -e /bin/mdev ] ; then

        mount   /dev   /mnt

        mount -t tmpfs   -o rw,exec,nosuid,mode=755 mdev    /dev

        cp   -ar /mnt/*     /dev

        umount     /mnt

        echo /bin/mdev 2>/dev/null > /proc/sys/kernel/hotplug

        /bin/mdev -s 2> /dev/null

fi

mount -t devpts devpts /dev/pts

mkdir /var/tmp /var/log /var/run /var/lock

QuoteReplyEditDelete

 

 

2008-02-25 17:22:00     Re: vmImage with jffs2 root file system

Mike Frysinger (UNITED STATES)

Message: 51631    that is true ... but we can just drop the /dev/null redirects as in the proper course of things, there will be no output.  if there is, we should probably be seeing it instead of ignoring it.

 

the size limit is there just for sanity's sake ... the default limit of tmpfs is half of the system ram, but rarely will ever need even a meg of storage for device nodes

QuoteReplyEditDelete

 

 

2008-03-12 16:23:11     Re: vmImage with jffs2 root file system

Robin Getz (UNITED STATES)

Message: 52409    William:

 

I also think you want noatime in your mount options - for sure in your bootargs with a jffs2 file system.

 

-Robin

Attachments

    Outcomes