OpenWrt Forum Archive

Topic: Failed flash to kamikaze

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

I rather foolishly flashed kamikaze (9th Mar, 2.6 kernel) without checking the nvram defaults on this router (WRT54GS v1) so I have boot_wait turned off!  I can reach failsafe mode, but then:

root@(none):~# /sbin/mount_root
Unlocking linux ...
Could not open mtd device: linux
jffs2 not ready yet; using ramdisk

root@(none):~# firstboot
Unlocking OpenWrt ...
Could not open mtd device: OpenWrt
Segmentation fault
(Then I have to reboot.)

This is the first time I've managed to screw it up this badly without being able to tftp a new firmware so I'm not sure if I'm going to need to make a serial port for it.  Is there a way to change the nvram variable from the failsafe environment?  `Nvram set` does not work.

Sorry if I've missed something really obvious.  Next time I'll be more careful about boot_wait and development code wink.

The failsafe mode on Kamikaze is a bit of mistery f.i. cannot get into it on my fonera, so is it working at all ?

Kamikaze has dropped nvram for use of configuration files so nvram cannot be your problem. I think you are going to need a serial connection to try to reflash...

It's my understanding that the bootloader still uses the boot_wait variable even in kamikaze.  If it does, I can tftp a known working firmware.  I might have been a bit misleading by posting the two failed commands above but all I wanted to do was get back to a working copy rather than attempt to fix the current installation.  It doesn't seem to be bricked - I mean I can telnet to it, it'll respond to ping, it just won't boot into normal mode.

Incidentally, I can load a firmware from a local webserver and run:
# wget http://192.168.1.100/temp/whiterussian.bin
# dd bs=32 skip=1 if=whiterussian.bin of=whiterussian.trx
# mtd -e linux -r write whiterussian.trx linux

But I get the 'unable to use mtd device: linux' error.

(Last edited by bunker on 11 Mar 2007, 03:28)

I have this problem also, I would like to turn on boot_wait or even better write a new image with mtd.
when I try to flash I get the same message as you did

bunker wrote:

root@(none):~# /sbin/mount_root
Unlocking linux ...
Could not open mtd device: linux
jffs2 not ready yet; using ramdisk

You shouldn't need to run this manually. The "Could not open mtd" is a result of the devfs changes last week. The "jffs2 not ready using ramdisk" means that there is no jffs2 partition yet.

root@(none):~# firstboot
Unlocking OpenWrt ...
Could not open mtd device: OpenWrt
Segmentation fault

More devfs bugs that were already fixed.

FYI - if you're still running this image, you need /dev/mtd and /dev/mtdblock as directories, containing the devices 0-4.

I just solved my problem.

(Last edited by mbm on 21 Mar 2007, 01:33)

Thanks, mbm.  Problem solved by your FYI.

FYI - if you're still running this image, you need /dev/mtd and /dev/mtdblock as directories, containing the devices 0-4.

I apologize, I am not usually this much of a knobhead, but what exactly do you mean by "containing devices 0-4"?

I created those directories, but am stuck there.

I am having exactly the same symptoms as bunker, I just did not do my research on kamikaze. :foolish me:

Now I need to reflash with whiterussian.

Just to be thorough:

whr-g54s with kamikaze 2.6 on it.
basic knowledge of *nix.

so knowing WHAT to do (commands, etc.) would be greatly appreciated.
(will I need to setup the pppoe and have it d/l the image from the site? should I setup a webserver on my lan?)


I PROMISE I will not do this again without knowing more and researching first.

Thank you

(Last edited by filsee on 2 May 2007, 05:36)

Well luckily enough, I found my resolution under "deinstalling openwrt".

I think that is a fairly obscure title, considering the possibilities that may need such a resolution.

I apologize for sounding so kooky yesterday. My head fell off for a bit.

Sorry to bump an old/solved thread, but I haven't checked the email I subscribed to this topic with for some time.  Since someone else got the problem recently(ish) I'll clarify.  All I did was move /dev/mntdblockX to /dev/mntdblock/X and /dev/mtdX to /dev/mtd/X, where X is a number from 0-4.  I'm sure this info is all incredibly irrelevant now though wink.

The discussion might have continued from here.