OpenWrt Forum Archive

Topic: Failsafe: writing to the jffs-partition / serial console

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

Hi

Could i write in the fail-save mode to the jffs-partition ?

When i mount it with
mount -t jffs2 /dev/mtdblock/4 /jffs
try to change a file, i get a longer error-message on the serial console, that is isn't able to write. I use the 20040331-tgz.

And is it possible to install a getty for the serial port ?
Otherwise, do already exist a Howto to build own packages ?

cu Thomas (very impressed of openwrt smile

Hi

Could i write in the fail-save mode to the jffs-partition ?

When i mount it with
mount -t jffs2 /dev/mtdblock/4 /jffs
try to change a file, i get a longer error-message on the serial console, that is isn't able to write. I use the 20040331-tgz.

And is it possible to install a getty for the serial port ?
Otherwise, do already exist a Howto to build own packages ?

cu Thomas (very impressed of openwrt smile

One should be able to write to jffs in FSM.

Even I have successfully written into jffs2 several times,
I once happened to this situation also.
It said something like "can't write to read-only filesystem",
even if I "mount -o rw".
All I could do was re-tftp the firmware.
It seemed that NVRAM had been resetted to default that day.
Would that be the cause?

If you look in /etc/preinit you'll see a line

  mtd unlock mtd4

just before mounting jffs2, the unlock command is used to enable write support on the intel flash chips (v1.1 and above)

If you look in /etc/preinit you'll see a line

  mtd unlock mtd4

just before mounting jffs2, the unlock command is used to enable write support on the intel flash chips (v1.1 and above)

How about execute these two lines, even when booting into FSM?

  mtd unlock mtd4                                                               
  mount -t jffs2 /dev/mtdblock/4 /jffs                                          

How about execute these two lines, even when booting into FSM?

  mtd unlock mtd4                                                               
  mount -t jffs2 /dev/mtdblock/4 /jffs                                          

Nope. The point of failsafe mode is that it doesn't use jffs2.

How about execute these two lines, even when booting into FSM?

  mtd unlock mtd4                                                               
  mount -t jffs2 /dev/mtdblock/4 /jffs                                          

Nope. The point of failsafe mode is that it doesn't use jffs2.

See.

By the way, is there anyway to LOCK mtd4 jffs2, preventing from being written,
after it is mounted on root?

How about execute these two lines, even when booting into FSM?

  mtd unlock mtd4                                                               
  mount -t jffs2 /dev/mtdblock/4 /jffs                                          

Nope. The point of failsafe mode is that it doesn't use jffs2.

Granted, it should not be *used*. What is the point to not trying to mount it though? (Think that would just fail gracefully if corrupt, or not?)

Since I'd guess when you're booting FSM if somthing went wrong on jffs you're likely wanting to fix it and the "mtd unlock mtd4" will probably be a frequently encounterd problem smile.

-Chris

Here is my standpoint as a newbie:

I was to lame to successfully mount the jffs2 partition myself.
Also I hadnt known anything about mtd unlock.

My networking.sh was corrupted somehow, so OpenWRT didn't come up listening on IP 192.168.1.1.

I had no clue what to do, so I had to call firstboot which deleted everything on my jffs2 partition sad

If there would have been some script in /usr/sbin where I could mount the jffs2 partition, this hadn't happend to me.
Unnessesary work for nothing sad

took me 15 mins of searching the forum for this .. i rembered hot to boot into failsafe no problem .. it's mounting the jffs in rw mode that messed me up

just a suggestion , wouldnt hurt to have that command in the MOTD  for the failsafe boot.

The discussion might have continued from here.