JFFS2 rootfs appears read only

Still trying to get a simple JFFS2 rootfs to work.

The main problem, which is inhibiting progress, is that any changes made in
the rootfs on the target are not saved across a reboot.

I can have a working u-boot, kernel (2.6.32rc8) and the JFFS2 rootfs from
Kernel Concepts, but as soon as I substitute my_rootfs.jffs2 I get this
problem. (I know you can have other problems mixing one kernel version with
a rootfs built using a different kernel version, but it seems to "work"). 

At a suggestion from a JFFS2 expert I changed the bootargs to include a
<rw>, while another expert said, "JFFS2 is always read/write, so the
default should be read/write".  Well, that doesn't work either.

All directories and executable files are <rwx> everything else <rw> and all
owned by root.

Could anyone with some JFFS2 experience please suggest things to look for?

Really appreciate any comments.

Thanks,
Dave

That's a pretty neat trick; JFFS should be RW with the default settings.

You may want to do a "mount" to make sure that where you're writing is in
fact a jffs2 file system. 

# mount
rootfs on / type rootfs (rw)
/dev/root on / type jffs2 (rw,relatime)

When the file system remounts, do you get error messages?

Regards,
gene

Neat trick?

I can mount it on the host and I can navigate the directories.  I can't
change anything, but I believe that is normal for a mounted drive.

So, do I try to mount it on the target?

Thanks for the response.

Dave

what does "mount" say?

you could try to remount your rootf rw from the console:

mount /dev/root / -o remount,rw

Sorry guys . . . I should have said how I was verifying that I had a JFFS2
filesystem on the host.

I am using mount_jffs2.sh (the bottom one) from:
http://wiki.maemo.org/Modifying_the_root_image

Shell script to mount/unmount JFFS2 using kernel memory emulating MTD 

My understanding is that this script will only let you view the JFFS2
rootfs, not modify it.

So, I can view both my_rootfs.jffs2 and other working JFFS2 rootfs on the
host, but I can not modify (change, edit or add to files) my_rootfs.jffs2
on the target.

Finally got the system running with 2.6.32.7, so back to this problem.

sam:

mount /dev/root / -o remount,rw

says nothing and doesn't change the behaviour


gene:

# mount
rootfs on / type rootfs (rw)
/dev/root on / type jffs2 (rw,relatime)

I don't understand, do I put all this in the command line?

Tried:

mount /dev/root / -o remount,rw  (nothing happened)
mount -t jffs2 -o remount,noatime /dev/mtdblock3 

this one is interesting as it comes back with an error message:
mount: can't find /dev/mtdblock3 in /proc/mounts

/proc/mounts is an empty file on the rootfs that I am constructing from an
example I found, which among other things uses mdev.

Any further clues?

Thanks,
Dave

/proc/mounts should be autogenerated by the kernel. If that's missing on
your platform I suspect your kernel is not working propperly. Is it the
thing fom buserror? If yes, I didn't get mine working either :-/

Sam,

Yes, it is the latest, 2.6.32.7 although .config reports 2.6.32rc8.

/proc/mounts does seem to be autogenerated, as I didn't put it in there. 
It's just that I don't know if it should be a file, an empty file or a
directory.  If it is an empty file, then it might be OK.

I am now thinking I have errors and omissions in both my fstab and rcS
files, as I am working from scratch to some suspect examples!

I had to do two clean gits, as the first one just wouldn't compile.

What errors do you get?

Dave

As it represents the kernels view of mounted filesystems an empty file is
in deed a very bad thing.  This is what mine says:[code]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / yaffs rw,relatime 0 0
none /proc proc rw,relatime 0 0
none /sys sysfs rw,relatime 0 0
none /proc/bus/usb usbfs rw,relatime 0 0
none /dev ramfs rw,relatime 0 0
none /dev/pts devpts rw,relatime,mode=622 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
none /tmp ramfs rw,relatime 0 0
none /var ramfs rw,relatime 0 0
#[/code]

It has nothing to do with your rootfs. Maybe you should compile a
monolithic kernel without loadable modules - that's what I do for embedded
systems and it works quite well.

What errors I got? Lots, some while comilation - I could work that out -
some while running the Kernel. "init not found", hardware not detected ...
I dropped buserror repository as I did not get the things working, neither
the kernel nor the rootfs.

Here's my output of <cat /proc/mounts> on my rootfs:
                                     

rootfs / rootfs rw 0 0                                                     
    
/dev/root / jffs2 rw,relatime 0 0                                          
    
/proc /proc proc rw,relatime 0 0                                           
    
/sys /sys sysfs rw,relatime 0 0                                            
    
tmpfs /tmp tmpfs rw,relatime 0 0                                           
    
tmpfs /dev tmpfs rw,relatime 0 0                                           
    
tmpfs /mnt tmpfs rw,relatime 0 0                                           
    
devpts /dev/pts devpts rw,relatime,mode=600 0 0                            
    
tmpfs /etc tmpfs rw,relatime 0 0  


# mount
                                                                      
rootfs on / type rootfs (rw)                                               
    
/dev/root on / type jffs2 (rw,relatime)                                    
    
/proc on /proc type proc (rw,relatime)                                     
    
/sys on /sys type sysfs (rw,relatime)                                      
    
tmpfs on /tmp type tmpfs (rw,relatime)                                     
    
tmpfs on /dev type tmpfs (rw,relatime)                                     
    
tmpfs on /mnt type tmpfs (rw,relatime)                                     
    
devpts on /dev/pts type devpts (rw,relatime,mode=600)                      
    
tmpfs on /etc type tmpfs (rw,relatime) 

Sorry about the formatting.  

Your last comment is interesting.  Which rootfs are you talking about on
buserror's site?  The Angstrom one?  I haven't tried that one with my
rootfs.  I have been using the rootfs image from Kernel Concept's download
support package (GPE).  With my kernel I get lots of even FATAL mesgs as
the kernel is booting up, I think mainly due to the fact that the modules
are from 2.6.29.4 and my kernel is 2.6.32.7.  However, I can navigate the
filesystem using minicom I just don't get to the GPE GUI or even the screen
calibration.

The search continues.

Thanks for your input.
Dave

No, the openembedded thingie: http://code.google.com/p/mini2440/w/list

I'd suggest you build a monolithic kernel ;-)

A S3C2410 expert, at work, has suggested that mounting dev on tmps may be a
problem.

I am aware that for a fully embedded system that people generally build
everything in.  I am still playing with the board so wanted to leave a few
options as loadable.  Well, the truth is . . . I have an idea which ones I
wanted to leave out, ie wireless, Bluetooth, media but didn't have enough
knowledge to go through and decide which modules to keep and which ones
build in!

I might try just building in everything that I am not sure about.  I have
built Busybox as static, so by building everything in I wouldn't need any
libraries.

Thanks for the hints.
Dave

Solved?

Not much chance you'll have the same problem, however . . .

I started with an example rootfs, which looks like it was made for the
mini2440.  I wanted to be able to modify files in /etc on the target.

Well, it appears that the lines:

echo "* Mounting tmpfs . . ."  (which I think should say "* Binding
                                /tmp/etc to /etc . . .")
mkdir /tmp/etc
cp -ad /etc/* /tmp/etc
mount -o bind /tmp/etc /etc 

ends up making /etc volatile.

Commented out those 4 lines and I can now modify files in /etc and reboot
and the changes are there.  However, there seems to be another problem, 

JFFS2 notice: (719) check node_data: wrong data CRC . . .

but things seems to work OK.

After I am happy with the changes I want to make in /etc I will do another
mkfs.jffs2 and hopefully everything will be sweet.

Thanks gene and sam for the input towards an acceptable solution.

Moving on . . .

Dave

> JFFS2 notice: (719) check node_data: wrong data CRC . . .

I've got these on other devices with JFFS2, when the NAND was not erased
completely before flashing. As I think to recall, uboot just erases the
NAND as big as the JFF2 image is.