OpenWrt Forum Archive

Topic: Kamikaze filesystem not writable?

The content of this topic has been archived on 27 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I have been running WhiteRussian a long time, now I'm a Kamikaze n00b with my first problem:

root@OpenWrt:/etc/config# cp network network.bak
Write of 68 bytes at 0x001f24c4 failed. returned -30, retlen 0
Not marking the space at 0x001f24c4 as dirty because the flash driver returned r
etlen zero
mini_fo: create_sto_file: ERROR creating sto file.
'network.bak' exists

I notice this in dmesg output:

mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
0x001e0000-0x003f0000 : "rootfs_data"
VFS: Mounted root (squashfs filesystem) readonly.

However mount indicates it's read-write:

root@OpenWrt:/etc/config# mount
rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro)
none on /dev type devfs (rw)
none on /proc type proc (rw)
none on /tmp type tmpfs (rw,nosuid,nodev)
none on /dev/pts type devpts (rw)
/dev/mtdblock/4 on /jffs type jffs2 (rw)
/jffs on / type mini_fo (rw)

(Last edited by vincentfox on 13 May 2007, 05:28)

vincentfox wrote:

mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
0x001e0000-0x003f0000 : "rootfs_data"
VFS: Mounted root (squashfs filesystem) readonly.

rootfs is the squashfs partition, the filesystem isn't writable so there's no need to make the partition writable, this means that the partition doesn't need to be aligned to erase block boundaries -- in short this is a harmless warning.

The actual error is coming from the flash driver, it seems to think the flack chip is locked. The most likely cause of this is the changes to the preinit scripts last week, removing platform specific startup scripts in favor of generic scripts -- specifically some of the 'mtd unlock' calls got moved.

What device is this? I've already tested on a number of devices and I haven't seen that error yet.

If I'm right the error will go away after 'mtd unlock rootfs_data' is run.

If by device you mean the model, this is Linksys CL7B or GL v1.1 unit.

May 12 build of brcm-2.4 squashfs trx file was flashed using mtd.

Yes running "mtd unlock rootfs_data" did make the filesystem writable.

Fix for it is in 7199

Odd, I just flashed r7256. Been out for a few days.  Anyhow I ended up having to do the mtd unlock rootfs_data with this one also.  I can repeat my steps to be sure, but I think the bug persists.

No sure if this is related - when flushing buffalo routers with KAMIKAZE (7.06) the root file system is read-only.
I then  mtd erase mtd4  and re-flush the linux partition with exactly the same image (as was flushed via TFTP), this time the machine comes back with a writable jffs as root.

Any idea why the first flushing makes the system to mount a RO FS ?

Thanks,

Yahel.

PS - possibly this is the same issue as here:
http://forum.openwrt.org/viewtopic.php?id=11390

Thanks "forum2006".
It make sense.
Other then upgrading to 7.07 which is a bit difficult for me...
Do you know what should be fixed in the 7.06 version to avoid this ?
I bet it's just some bad script somewhere - but which and where ?

Thanks,

Yahel.

The discussion might have continued from here.