178 replies to this topic

[theparasol]

Hey no problem, add it to the collection and if you need some more just ask. I think google will reproduce my nick quite often

[Lost in Space]

I'm not collecting parasols - lost already too many :-)

[theparasol]

Well actually its just another bad nickname I didnt even invent myself

[Lost in Space]

Well, names are fun, even for Plugins :-)

[radxnl]

so now we wait for 29-08-2013

[Lost in Space]

you are welcome

[Lost in Space]

Just one more question regarding the backup feature request and doing it better/faster.

 

When you are doing a backup you use nanddump for extracting the partitions without a filesystem like the kernel. But you spend lots of time to rebuild the root filesystem with mkfs.ubifs and ubinize. Are you aware that it would be also possible to extract the root filesysystem with nanddump too and flash it back with nandwrite?

 

Using this approach means much faster backups, as the filesystem is dumped as is it is and not re-built file per file with all the compression overhead. On the other hand this mans no defragmentation of ubifs by the backup (which is not a big problem for ubifs as it is part of its design to be fragmented due to the wandering tree aproach) and it means that the extractet root image files would be as big as the root flashpartition (as also the freespace needs to be dumped to be consistent) and should be only flashed back on the same box.

 

Basicall it is the Flash/blockdevice quivalent for backup/restore a filesystem witd dd of the rawdevices.

 

dFlash is offering such a quick backup/restore already sind ages, that's why I was wondering why nobody tried that out on your boxes. Because then you could do a very simple single binary backup solution which just scans /proc/mtd and then dumps them out one after the other with nandwrite code. And I could easily add a -n flag to fgwrite which then would enforce flashing root with nandwrite instead of ubiformat.

 

Any interest in trying out such quick backup?

Edited by gutemine, 19 May 2013 - 09:43.

[rtzhjgg0]

It wold be interesting to see what pieterg and other devs say about this possibility. If it is compatible to PLi structure.

[Lost in Space]

Dumping the content of Flashchips and writing it back has nothing to do with PLi structure. Only as the bios uses now ubiformat to write the root image it will not be able to flash back such dumps. But this is the same on the dremaboxes, nanddump backups can be only flashed with nandwrite and not with the bios.

Edited by gutemine, 19 May 2013 - 10:13.

[nietgiftig]

Any interest in trying out such quick backup?

 

 

Only if it contains no hidden keys, timebombs or spyware related code.

Let's just say open software

 

And only if the developer is has a normal or if possible nice attitude.

 

[Lost in Space]

I never produced any hidden keys or spyware, and if you don't understand the word Testkit it is not my fault.

[Happysat]

True now you only have to take care of this last big problem:

 

 

 

 

 

 

 

[offnow]

... niemand hat die Absicht, eine Mauer zu bauen...

[Lost in Space]

Maybe it is time for a Woody Allen quote:

 

Masturbation is sex with a loved person.

[Rob van der Does]

When you are doing a backup you use nanddump for extracting the partitions without a filesystem like the kernel. But you spend lots of time to rebuild the root filesystem with mkfs.ubifs and ubinize. Are you aware that it would be also possible to extract the root filesysystem with nanddump too and flash it back with nandwrite?

Does that mean that the backup will have the same size as the available flash on the box (e.g. 512MB for the Ultimo)?

[Lost in Space]

The root.bin would be as big as the mtd partition you are dumping, yes.

 

Simply try it out yourself.

[betacentauri]

Hi gutemine,

 

can you give me a hint how you could use ubiformat?

If I use it I get something like this: "please, first detach mtd...". And detaching don't work for rootfs, because it's in use. Did you comment out this check?

[pieterg]

use ubiformat?

It's cleaner (and way faster) to remove the existing rootfs volume, and create a new one.
The UBI layer is fine, there is no need to ubiformat it again.

create a chroot environment with static binaries (klibc-utils or busybox-static will do fine)
use pivot_root to switch the root to it, then chroot into it (to let go of the shell in the old rootfs), and finally umount the (now free) old root.
Now you can remove and replace it.

[betacentauri]

Sounds a little bit difficult... let's see if I can handle it...

 

Currently I use nandwrite to flash rootfs (before I do a remount read-only and a flash_erase). Flashing is not the problem, but after reboot ecc errors (ubi_io_read: error -77 (ECC error)) occur and I have to flash system via usb stick. So I think that I make something wrong. But I do it exactly the same like the _restore script which is used for vu boxes. Well, I use -m option. Perhaps this is the problem.

 

I can post the sources and the binary. But I wanted to post it when it's ready...

Edited by betacentauri, 28 May 2013 - 21:44.

[betacentauri]

Well, I have tested again. Also without -m option it don't work (I use this command: "nandwrite -m /dev/mtd2 ./rootfs.bin"; I have one binary included everything I need).