Making a backup: Difference between revisions

From Sharpfin
Jump to navigation Jump to search
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Making a backup ==
= Making a Backup =
 
== Overview ==


The reciva module has onboard NAND flash which is used to store the software. The flash is split into several partitions, here's the layout of my IMP box:
The reciva module has onboard NAND flash which is used to store the software. The flash is split into several partitions, here's the layout of my IMP box:
Line 12: Line 14:
  mtd5: 00000000 00004000 "Data"
  mtd5: 00000000 00004000 "Data"


A simple bacup mechanism is storing the raw contents of the block devices. I've been told that simply using cat or cp is not safe on NAND devices, but a better alternative exists: the 'nanddump' tool.
NAND devices do not hide any corrupt blocks.  Furthermore, linux does not interface to the jffs2 disk drive at a particularly low level, so access to the /dev/mtd files will provide all of the nand data, warts and all.
 
When backing up your flash partitions, using functions such as cat or cp on the device will copy the partition data and also any bad blocks; however the tracking information which identifies these as bad blocks is lost, and you will end up with a corrupted output file and will not be able to tell a good data from bad block data.
 
Make sure you use the 'nanddump' utility, which skips bad blocks to provide a representative image of the actual disk data.
 
See [[Reciva NAND Flash]] for more information on the workings of the NAND Flash.
 
== Methods ==


If you've got ssh running, the following is a method of creating a back of the partitions. Run these commands on another machine on the network where you want to store the backups:
Note that the following methods all assume that your partition organisation is the same as that described above. If it is not, you will have to adjust the start addresses and lengths accordingly.


$ ssh root@<address-of-the-box> "nanddump /dev/mtd/0 -" > backup/mtd0
The ''sharpflash'' utility uses files in the nanddump format, so that is what the following sections all generate ...


Repeat the command for each flash partition, increasing the 0 to 5.
=== Via Telnet ===


If you are working through telnet, you will need to dump the partitions to /tmp or a mounted drive
Log into the radio, and create your dumpfiles as follows:


  $ mkdir /tmp/x
  $ mkdir /tmp/x
  $ smbmount //server/share /tmp/x -ousername=username,password=password
  $ smbmount //server/share /tmp/x -ousername=username,password=password
  $ nanddump /dev/mnt/0 /tmp/x/mtd0
  $ cd /tmp/x
$ echo n | nanddump /dev/mtd/0 boot-mtd.bin
$ echo n | nanddump /dev/mtd/1 kernel-mtd.bin
$ echo n | nanddump /dev/mtd/2 root-mtd.bin
$ echo n | nanddump /dev/mtd/3 config-mtd.bin
$ echo n | nanddump /dev/mtd/4 debug-mtd.bin
 
=== Extracting from a Reciva Upgrade mtd.bin File ===
 
Reciva upgrade images seem to be a complete image of the boot, kernel and root partitions, however, if this is written back to the flash using sharpflash, the resulting radio still does not boot - this is because the files do not contain the additional error correction data.
 
''nanddump'' images can be extracted from these Reciva distributions using the ''getpart'' command, for example:
 
$ getpart mtd.bin 0 4000 boot-mtd.bin
$ getpart mtd.bin 4000 fc000 kernel-mtd.bin
$ getpart -jfs2 mtd.bin 100000 d00000 root-mtd.bin
$ getpart -jfs2 mtd.bin e00000 100000 config-mtd.bin
$ getpart -jfs2 mtd.bin f00000 100000 debug-mtd.bin
 
=== Using the JTAG Port ===
 
The sharpflash program creates JTAG images in ''nanddump'' format.  It is recommended that partitions are backed up one-at-a-time, so:
 
$ sharpflash -w boot-mtd.bin 0 4000
$ sharpflash -w kernel-mtd.bin 4000 fc000
$ sharpflash -w root-mtd.bin 100000 d00000
$ sharpflash -w config-mtd.bin e00000 100000
$ sharpflash -w debug-mtd.bin f00000 100000
 
 
=== Using SSH ===
 
If you've got ssh running, the following is a method of creating a back-up of the partitions. Run these commands on another machine on the network where you want to store the backups:
 
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/0 -" > boot-mtd.bin
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/1 -" > kernel-mtd.bin
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/2 -" > root-mtd.bin
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/3 -" > config-mtd.bin
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/4 -" > debug-mtd.bin
 
=== Via the Webserver ===
 
[[Image:Webserver-backup.jpg|Webserver Backup]]
 
Version 0.5 and later of the webserver enable you to backup your partitions.  Simply select 'Backup' from the 'Admin' menu, pick a partition, and the webserver will run 'nanddump', and provide the backup file for you to download.


== Restoring ==
== Restoring ==


Restoring the backup might be possible using the 'nandwrite' utility. I've not tried this myself, and I'm quite sure strange things will happen while writing the flash image while the partition is mounted. Use at your own risk, and feel free to write down your experiences here.
With these saved images, you can perform a restore of your radio if everything goes wrong, using the sharpflash JTAG utility.  Check the [[Unbricking]] page for more information.
 
Restoring the backup might be also possible using the 'nandwrite' utility. I've not tried this myself, and I'm quite sure strange things will happen while writing the flash image while the partition is mounted. Use at your own risk, and feel free to write down your experiences here.

Latest revision as of 22:31, 13 November 2007

Making a Backup

Overview

The reciva module has onboard NAND flash which is used to store the software. The flash is split into several partitions, here's the layout of my IMP box:

# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00004000 00004000 "NAND BootAgent"
mtd1: 000fc000 00004000 "Linux Kernel"
mtd2: 00d00000 00004000 "Root"
mtd3: 00100000 00004000 "Config"
mtd4: 00100000 00004000 "Debug"
mtd5: 00000000 00004000 "Data"

NAND devices do not hide any corrupt blocks. Furthermore, linux does not interface to the jffs2 disk drive at a particularly low level, so access to the /dev/mtd files will provide all of the nand data, warts and all.

When backing up your flash partitions, using functions such as cat or cp on the device will copy the partition data and also any bad blocks; however the tracking information which identifies these as bad blocks is lost, and you will end up with a corrupted output file and will not be able to tell a good data from bad block data.

Make sure you use the 'nanddump' utility, which skips bad blocks to provide a representative image of the actual disk data.

See Reciva NAND Flash for more information on the workings of the NAND Flash.

Methods

Note that the following methods all assume that your partition organisation is the same as that described above. If it is not, you will have to adjust the start addresses and lengths accordingly.

The sharpflash utility uses files in the nanddump format, so that is what the following sections all generate ...

Via Telnet

Log into the radio, and create your dumpfiles as follows:

$ mkdir /tmp/x
$ smbmount //server/share /tmp/x -ousername=username,password=password
$ cd /tmp/x
$ echo n | nanddump /dev/mtd/0 boot-mtd.bin
$ echo n | nanddump /dev/mtd/1 kernel-mtd.bin
$ echo n | nanddump /dev/mtd/2 root-mtd.bin
$ echo n | nanddump /dev/mtd/3 config-mtd.bin
$ echo n | nanddump /dev/mtd/4 debug-mtd.bin

Extracting from a Reciva Upgrade mtd.bin File

Reciva upgrade images seem to be a complete image of the boot, kernel and root partitions, however, if this is written back to the flash using sharpflash, the resulting radio still does not boot - this is because the files do not contain the additional error correction data.

nanddump images can be extracted from these Reciva distributions using the getpart command, for example:

$ getpart mtd.bin 0 4000 boot-mtd.bin
$ getpart mtd.bin 4000 fc000 kernel-mtd.bin
$ getpart -jfs2 mtd.bin 100000 d00000 root-mtd.bin
$ getpart -jfs2 mtd.bin e00000 100000 config-mtd.bin
$ getpart -jfs2 mtd.bin f00000 100000 debug-mtd.bin

Using the JTAG Port

The sharpflash program creates JTAG images in nanddump format. It is recommended that partitions are backed up one-at-a-time, so:

$ sharpflash -w boot-mtd.bin 0 4000
$ sharpflash -w kernel-mtd.bin 4000 fc000
$ sharpflash -w root-mtd.bin 100000 d00000
$ sharpflash -w config-mtd.bin e00000 100000
$ sharpflash -w debug-mtd.bin f00000 100000


Using SSH

If you've got ssh running, the following is a method of creating a back-up of the partitions. Run these commands on another machine on the network where you want to store the backups:

$ ssh root@<address-of-the-box> "nanddump /dev/mtd/0 -" > boot-mtd.bin
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/1 -" > kernel-mtd.bin
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/2 -" > root-mtd.bin
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/3 -" > config-mtd.bin
$ ssh root@<address-of-the-box> "nanddump /dev/mtd/4 -" > debug-mtd.bin

Via the Webserver

Webserver Backup

Version 0.5 and later of the webserver enable you to backup your partitions. Simply select 'Backup' from the 'Admin' menu, pick a partition, and the webserver will run 'nanddump', and provide the backup file for you to download.

Restoring

With these saved images, you can perform a restore of your radio if everything goes wrong, using the sharpflash JTAG utility. Check the Unbricking page for more information.

Restoring the backup might be also possible using the 'nandwrite' utility. I've not tried this myself, and I'm quite sure strange things will happen while writing the flash image while the partition is mounted. Use at your own risk, and feel free to write down your experiences here.