I built and installed Kamikaze trunk r11625 onto a Netgear WGT634U. The build went fine with no errors. I followed the instructions on the wiki <http://wiki.openwrt.org/OpenWrtDocs/Har … ar/WGT634U> to clear the flash before loading the new image.

When the router boots, it goes through a mostly normal sequence, except it doesn't initialize and mount the jffs2 partition on first boot. This leaves the system as read-only, so no changes can be made. It also means that the /etc/config/network and /etc/config/wireless files can't be created, making the router fairly useless.

dmesg shows the necessary pieces are there:

squashfs: version 3.0 (2006/03/15) Phillip Lougher
Registering mini_fo version $Id$
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
...

Creating 4 MTD partitions on "Physically mapped flash":
0x00000000-0x000a0000 : "cfe"
0x000a0000-0x007e0000 : "linux"
0x0015dc00-0x007e0000 : "rootfs"
mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-
only
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=340000, len=4A0000
0x00340000-0x007e0000 : "rootfs_data"
0x007e0000-0x00800000 : "nvram"

Building and installing the Kamikaze 7.09 image works fine and creates the jffs2 file system as expected.

Any hints as to what to look for to make this work with trunk? I need to use some software developed for trunk <http://www.wing-project.org> that won't work with 7.09 stable.

Gus

I found that if I run /bin/firstboot manually it will detect and initialize the jffs2 partition and mount it. Not sure why it won't run initially.

Gus

I was mistaken. The jffs partition root_data will NOT mount because the mount point is missing. The initial mount point is supposed to be /rom/jffs which is used in the /bin/firstboot script. However, that mount point is missing and can't be created because it is on a read-only file system so the jffs partition can't be mounted in the normal manner.

Gus

I was having this same problem and tried to hunt it down.

At bootup I was seeing this from mount_root:

jffs2 not ready yet; using ramdisk
[and from the firstboot ramoverlay function:]
mini_fo: using base directory: /
mini_fo: using storage directory: /tmp/root

... which it does when it doesn't see the magic number on the jffs parition. However later on in init.d/done it checks if we're running with ramdisk for backing store and tries to initialize and pivot over to jffs, that test is '-d /tmp/root' and looking at the console logs from every time it failed for me there's no error either up front (mount_root) or in the end ('S95done') yet S95done didn't run the block of code that initializes jffs. Running it by hand works fine.

After booting in the failure mode I see:

root@OpenWrt:/sbin# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / squashfs rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
tmpfs /dev tmpfs rw 0 0
devpts /dev/pts devpts rw,mode=600 0 0
mini_fo:/tmp/root /mnt mini_fo rw 0 0
none /proc/bus/usb usbfs rw 0 0

which would explain why S95done didn't initialize the jffs from the ramdisk (it expects it mounted on /tmp/root). Tracking back a bit it looks like this all depends on '/rom' being available and there's no /rom known to the kernel (the squashfs is mounted r/w on /). My prior embedded work didn't use mini_fo (I just mounted a full ramdisk copy and pivoted over to it) so I'm guessing there's some trick with /rom I'm just not seeing. Maybe this is a kernel config thing and the config was old/skewed after I did the svn update (?).

Anyway, I'm now unable to reproduce the issue with r11801, and going back to a fresh checkout of r11625 (where it was failing before) is now working (WTF)... I'm guessing that this is either a timing thing or maybe something related to doing an 'svn update' and a 'make clean' then 'make' (some leftover thing in the toolchain perhaps?) vs a full checkout and build from scratch.

If you ever figured this out I'd love to hear the resolution (after spending half a day trying to run it down and then having the problem disappear). Everythings working fine for me now with my fresh checkout so I'm going to move on with what I really wanted to do.

-Eric

No need for a fresh checkout. Save some bandwidth and do this instead: use svn status --noignore and delete everything marked as ignored except the downloaded source tarballs if you have them in your build tree. Then run svn --revert -R . to make sure none of the files are modified.

(Last edited by Wodin on 13 Jul 2008, 11:26)

Thanks, good idea. I didn't know there was a way to ignore the 'ignore' property from the cmd line, handy!

-Eric