Posted: Fri Apr 06, 2012 17:04 Post subject: Can't enable jffs: "Could not erase MTD device: ddwrt&q
Running DD-WRT v24-sp2 (03/19/12) big - build 18777
on Netgear WNR3500Lv1.
Trying to enable jffs on what little flash remains.
Since the GUI didn't seem to work, I issued:
Code:
nvram set jffs_mounted=1
nvram set enable_jffs2=1
nvram set sys_enable_jffs2=1
nvram set clean_jffs2=1
nvram set sys_clean_jffs2=1
nvram commit
sleep 3
reboot
Console shows the following in the subsequent bootlog.
Code:
Unlocking ddwrt ...
Erasing ddwrt ...
Could not erase MTD device: ddwrt
Attempting to mount (I hope I'm doing this correctly)
with "mount /jffs /dev/mtd4" returns no message, but doesn't mount. Yep, I'm a newbie - could anyone shed some light on what might be happening here?
Is it a bleeding edge bug (yes I'm asking for trouble running builds this new), or something I'm doing wrong?
yes it is a bug that the partition "dd-wrt" has an end address which is lower than the partitions start address and the bug has become visible because the firmware build has grown and exceeded the Netgear size limit.
There is no space left for jffs2 in any router running a big build, either load a std build or spend 3-4 bucks on a USB flash stick of last years size which the shops are praying to get rid of. _________________ Kernel panic: Aiee, killing interrupt handler!
yes it is a bug that the partition "dd-wrt" has an end address which is lower than the partitions start address and the bug has become visible because the firmware build has grown and exceeded the Netgear size limit.
There is no space left for jffs2 in any router running a big build, either load a std build or spend 3-4 bucks on a USB flash stick of last years size which the shops are praying to get rid of.
Ah righo thanks mate, I understand now.
It had me confused when GUI said 6000-odd kb jffs storage free but obviously this is another symptom of build size.
I'm now using a USB key, but I wanted to use jffs because of the support for script autoruns fron jffs /etc/default. Plus several services only support jffs as an alternative to NVRAM storage.
Can you see any way to meet the above two needs - or would I have to choose a smaller build (or repackage the big build) to get autoscript and jffs-based config storage for dhcp etc?
..bump..
is there a way to redirect the mountpoint for services relying on /jffs at boot time?
And any ideas on where I could store my startup scripts? _________________ ========================
<<CURRENTLY WORKING ON>>
-Netgear WNR3500Lv1 w/DD-WRT v24-sp2 (03/19/12) big - build 18777
-Buffalo WBR-G54 w/DD-WRT v24_pre_sp2 (08/07/10) std - build 14896
I enabled jffs using the guide posted by Barryware (using the GUI method), works great on my WNR3500L V1! I use jffs for storing my OpenVPN keys and certs to save on NVRAM space. _________________ James
Main router:
Netgear R7000 overclocked to 1.2GHz - DD-WRT v3.0-r35965M kongac
IPv6 6in4 (HE.net), OpenVPN (with PBR and split tunnelling), Entware, dnsmasq with ipset
That's the problem.. JFFS can't ben enabled because DD-WRT's flash image is too big to allow it (see second post).
So given the bug/issue means I can't enable JFFS, I'm looking for an alternative.
Using a USB key atm but that isn't mounted until late in the boot process - too late to be useful to store startup scripts, and some services require /jffs to be present at boot to store their data there.
Perhaps some kind of virtual FS that rides on NVRAM?
Thanks for the replies! _________________ ========================
<<CURRENTLY WORKING ON>>
-Netgear WNR3500Lv1 w/DD-WRT v24-sp2 (03/19/12) big - build 18777
-Buffalo WBR-G54 w/DD-WRT v24_pre_sp2 (08/07/10) std - build 14896
Maybe I'm getting confused somewhere but I have 14929 Big flashed on my WNR3500L V1 and was able to enable and have been using the 512 KB of jffs space for several weeks.
Is this an issue introduced in newer builds? _________________ James
Main router:
Netgear R7000 overclocked to 1.2GHz - DD-WRT v3.0-r35965M kongac
IPv6 6in4 (HE.net), OpenVPN (with PBR and split tunnelling), Entware, dnsmasq with ipset
Maybe I'm getting confused somewhere but I have 14929 Big flashed on my WNR3500L V1 and was able to enable and have been using the 512 KB of jffs space for several weeks.
Is this an issue introduced in newer builds?
Have you compared the file size of a 14929 big vs a 18777 big? _________________ Kernel panic: Aiee, killing interrupt handler!
Ah yes, haven't looked at the exact size (down to the last byte) but just looking at the FTP repository you can see the difference. 6.8 MB compared to 7.4 MB, I understand now, sorry.
Due to Netgear's partitioning adventures does that mean the big builds are pretty much right on the limit of what can fit in the flash of WNR3500L in terms of the newer builds now? _________________ James
Main router:
Netgear R7000 overclocked to 1.2GHz - DD-WRT v3.0-r35965M kongac
IPv6 6in4 (HE.net), OpenVPN (with PBR and split tunnelling), Entware, dnsmasq with ipset
Earlier post suggests it's close, but my maths says there's still room.
Wholeflash is 8,388,608 bytes.. big 18777 is 7,761,920.
Hmm I might be missing something but I can't see where the other 626,688 bytes are.. even allowing for block boundaries and minor over-allocation (though I don't know what block size is used on mtd's).
Grr even 16kb on jffs would solve my problem.. _________________ ========================
<<CURRENTLY WORKING ON>>
-Netgear WNR3500Lv1 w/DD-WRT v24-sp2 (03/19/12) big - build 18777
-Buffalo WBR-G54 w/DD-WRT v24_pre_sp2 (08/07/10) std - build 14896
Joined: 26 Jan 2008 Posts: 13049 Location: Behind The Reset Button
Posted: Fri Apr 13, 2012 13:58 Post subject:
netgear routers have a few, to several "extra" partitions that you never even see unless you check the boot log.
These partitions hold device specific data (macs, radio params, etc.)
the same build flashed to a linksys router lets say, will yield more free space on the flash chip than a netgear. _________________ [Moderator Deleted]
Ah ok. Still.. after nosing around, it seems to me there's
Somewhere I read the last 2*64k blocks are boarddata and nvram, beginning at 0x007e0000.
Checking big b18777 wholeflash, 0x007b0000-0x007f8000 is empty (0xff's) - that's 294912 bytes!
Even if you subtract nvram and boarddata, that still leaves nearly 167kb unused.
For reference, Netgear wholeflash has a much smaller segment free towards the end.. 0x007FC690-0x00800000 (3970 bytes free).. dunno what's up with that. Boarddata IS present though, though bout 360 bytes of data, and contains the board id, serial#, WPS PIN, mac.
The DD-WRT flash wiped my board_data so it's obviously not important for DD-WRT (maybe if reverting to stock FW it would need to CFE-repaired or reflashed.)
Anyways my point is there's at least ONE 64kb sector free in the map (even allowing for board_data to be left alone). Why didn't the developers partition any of that free space? _________________ ========================
<<CURRENTLY WORKING ON>>
-Netgear WNR3500Lv1 w/DD-WRT v24-sp2 (03/19/12) big - build 18777
-Buffalo WBR-G54 w/DD-WRT v24_pre_sp2 (08/07/10) std - build 14896
Joined: 26 Jan 2008 Posts: 13049 Location: Behind The Reset Button
Posted: Fri Apr 13, 2012 20:33 Post subject:
I don't understand the problem.. Just format & partition a usb mem stick and there you go..
you do not have to enable jffs in the gui to mount external storage to jffs.
I don't use jffs even though my storage is formatted for it..
/opt
/swap
/jffs
/data
I just plop everything into opt and mount the opt partition to opt.
I use otrw.. everything starts as it should.. you might have to put a sleep command in your startup script after the mount so the storage gets mounted, then the data on the storage gets read / executed / whatever. _________________ [Moderator Deleted]
Checking big b18777 wholeflash, 0x007b0000-0x007f8000 is empty (0xff's) - that's 294912 bytes!
Even if you subtract nvram and boarddata, that still leaves nearly 167kb unused.
The reason why it is empty (0xff) is because you have erased what was there.
Look at the mtd partitions in your first post and you will see that the linux partition covers the memory range which the dd-wrt firmware can use and leaves out the 64KB segments 7b, 7c, 7d, and 7e in order to preserve what is originally there.
There is no way for dd-wrt to write to this undefined hole in flash space between the linux partition and the nvram partition at segemnt 7f.
benryanau wrote:
The DD-WRT flash wiped my board_data so it's obviously not important for DD-WRT (maybe if reverting to stock FW it would need to CFE-repaired or reflashed.)
No, dd-wrt didn't wipe your board data, you did it, dd-wrt can not access it.
The board data is needed if you want to flash back stock firmware
benryanau wrote:
Anyways my point is there's at least ONE 64kb sector free in the map (even allowing for board_data to be left alone). Why didn't the developers partition any of that free space?
jffs2 needs 2 (or maybe it is 3) flash sectors (a' 64KB) only for the journalling and root directory.
It also needs a minimum of 1 flash sector for storage of the data. These flash sectors has to bee unique, can not be shared or overlap other sectors.
There is not free space enough for internal jffs2 in recent big builds. _________________ Kernel panic: Aiee, killing interrupt handler!