75 replies to this topic

[betacentauri]

indeed.
Using multiple rootfs images would of course need support from the bootloader, but a more common use, what I do for instance is put config backups in my ubi layer.

Can you flash your box with an usb stick? Does the firmware use something like upiupdatevol or ubiformat?

Edited by betacentauri, 1 June 2013 - 17:47.

[Lost in Space]

Yes, my LowFAT stick flashes the Dreamboxes nicely and if I remeber right your ubiformat when the box is flashed from USBis running in an initramfs and not in the bios itself.

 

And instead of passing the options and use the process_option routines  I made all of then arguments passed to the routines named ad the binaries and don't use the option processing meachanism at all.

 

This is more flexible for my purpose, but there are many ways to solve a problem, so there is no good or bad.

Edited by gutemine, 1 June 2013 - 18:14.

[betacentauri]

Using the original main procedures was initially from my point of view the easiest way to get it running. Afterwards with this "bug" I must say that it might be easier to adapt the main procs...

No other testers??
Vu support comes in some days.

[betacentauri]

Here is a new version, which should support all VU+ boxes.

I flash kernel_cfe_auto.bin with nandwrite and I don't flash boot_cfe_auto.jffs2. I read that it is not necessary to flash it(and nedro's backup suite don't create it any longer). As rootfs I flash root_cfe_auto.bin or root_cfe_auto.jffs2 with ubiformat.

I hope somebody can confirm, that the 2 files are sufficent.

Attached Files

•  ofg_bin_v0.2.zip   303.89KB   6 downloads
•  ofg_src_v0.2.zip   97.41KB   5 downloads

[Lost in Space]

If I remember right in /boot there are only a couple of links from /boot to the logos and a dummy kernel link, with my nfidump I simply create them when unpacking the image to the filesystem. But if you don't replace them when flashing it doesn't do any harm as they should be Ok for every image.

[betacentauri]

Here's a new version of my binary. Fixed is the problem that the path to the image had to end with a /.

I have positive feedback from users with et9000, et9200, et9500, vu duo and xp1000 boxes.
Is there somebody, who has tested it with a solo2?

If you fear that something can go wrong, execute "ofgwrite -nrk <path to image>" and post output. This won't flash your box (because of -n switch).

Attached Files

•  ofg_bin_v0.3.zip   303.93KB   9 downloads
•  ofg_src_v0.3.zip   97.55KB   5 downloads

[Dimitrij]

betacentauri

Perhaps it is necessary to make a new plugin for OFG.
What should it be?

[betacentauri]

Hi Dima73,

 

do you want to build a python plugin for my tool? That would be great. I have used my tool over 30 times without problems.

 

I don't know how much time you want to spend with it.

Perhaps:

1. version: Open a directory tree and select directory. Start flash with the selected directory as parameter.

2. version: Add several switches ( -n simulate, -r only root, -k only kernel )

3. version: Add an unzip functionality to unzip an image zip file.

 

Perhaps my binary needs to be adapted a little bit to write a log file or that the plugin shows all errors, which might be difficult because I shutdown e2 while flashing...

[Dimitrij]

Hi Dima73,

 

do you want to build a python plugin for my tool? That would be great. I have used my tool over 30 times without problems.

 

I don't know how much time you want to spend with it.

Perhaps:

1. version: Open a directory tree and select directory. Start flash with the selected directory as parameter.

2. version: Add several switches ( -n simulate, -r only root, -k only kernel )

3. version: Add an unzip functionality to unzip an image zip file.

 

Perhaps my binary needs to be adapted a little bit to write a log file or that the plugin shows all errors, which might be difficult because I shutdown e2 while flashing...

ok

+

4. create backup current flash image

[betacentauri]

4. create backup current flash image

 

Do we need that? We can use nedro's backupsuite for this...

[theparasol]

Pedro...

[betacentauri]

Pedro...

 

Yes, sure

[Dimitrij]

4. create backup current flash image

 

Do we need that? We can use nedro's backupsuite for this...

It's just an idea.
It may not be necessary.

[Dimitrij]

root@et9x00:~# /usr/lib/enigma2/python/Plugins/Extensions/FullBackup/bin/ofgwrit
e /media/hdd/automatic_fullbackup/20130705_2200/et9x00

ofgwrite Utility v0.3
Author: Betacentauri
Based upon: mtd-utils-native-1.4.9
Use at your own risk! Make always a backup before use!
Don't use it if you use multiple ubi volumes in ubi layer!

Found kernel file: /media/hdd/automatic_fullbackup/20130705_2200/et9x00/kernel.bin
Found rootfs file: /media/hdd/automatic_fullbackup/20130705_2200/et9x00/rootfs.bin

Found /proc/mtd entries:
Device:   Size:     Erasesize:  Name:         Image:
/dev/mtd1 00600000  00020000    "kernel"  ->  /media/hdd/automatic_fullbackup/20130705_2200/et9x00/kernel.bin
/dev/mtd2 07900000  00020000    "rootfs"  ->  /media/hdd/automatic_fullbackup/20130705_2200/et9x00/rootfs.bin


Erasing kernel: flash_erase /dev/mtd1 0 0
Erasing 128 Kibyte @ 5e0000 -- 100 % complete
Flashing kernel: nandwrite -pm /dev/mtd1 /media/hdd/automatic_fullbackup/20130705_2200/et9x00/kernel.bin
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000
Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000
Writing data to block 12 at offset 0x180000
Writing data to block 13 at offset 0x1a0000
Writing data to block 14 at offset 0x1c0000
Writing data to block 15 at offset 0x1e0000
Writing data to block 16 at offset 0x200000
Writing data to block 17 at offset 0x220000
Writing data to block 18 at offset 0x240000
Writing data to block 19 at offset 0x260000
Writing data to block 20 at offset 0x280000
Writing data to block 21 at offset 0x2a0000
Writing data to block 22 at offset 0x2c0000
Writing data to block 23 at offset 0x2e0000
Writing data to block 24 at offset 0x300000
Writing data to block 25 at offset 0x320000
Writing data to block 26 at offset 0x340000
Writing data to block 27 at offset 0x360000
Writing data to block 28 at offset 0x380000
Writing data to block 29 at offset 0x3a0000
Writing data to block 30 at offset 0x3c0000
Writing data to block 31 at offset 0x3e0000
Writing data to block 32 at offset 0x400000
Writing data to block 33 at offset 0x420000
Writing data to block 34 at offset 0x440000
Writing data to block 35 at offset 0x460000
Writing data to block 36 at offset 0x480000
Writing data to block 37 at offset 0x4a0000
Writing data to block 38 at offset 0x4c0000
Writing data to block 39 at offset 0x4e0000
Writing data to block 40 at offset 0x500000
Writing data to block 41 at offset 0x520000
Writing data to block 42 at offset 0x540000
Writing data to block 43 at offset 0x560000
Writing data to block 44 at offset 0x580000
Writing data to block 45 at offset 0x5a0000
Writing data to block 46 at offset 0x5c0000
Writing data to block 47 at offset 0x5e0000
Switching to user mode 2
Syncing filesystem
Remounting root read-only
Erasing rootfs: flash_erase /dev/mtd2 0 0
Erasing 128 Kibyte @ 78e0000 -- 100 % complete
Flashing rootfs: ubiformat /dev/mtd2 -f /media/hdd/automatic_fullbackup/20130705_2200/et9x00/rootfs.bin
Bus error
root@et9x00:~#

betacentauri

Bus error???

 

[betacentauri]

Hi Dima73,

 

- Did you use my binary? Or did you compile it by yourself?

- Does the error occur everytime you call the ofgwrite?

- You have called the binary from console and not from E2, right?

 

I have never seen this error before. I only got one time (after extreme debugging) an out of memory error.

[Dimitrij]

Hi Dima73,

 

- Did you use my binary? Or did you compile it by yourself?

- Does the error occur everytime you call the ofgwrite?

- You have called the binary from console and not from E2, right?

 

I have never seen this error before. I only got one time (after extreme debugging) an out of memory error.

1)yes,yours binary.

2)No, before everything worked.
Now it is not working.

3)in telnet(PC) or E2(self.flash_commands = "%s %s" % (ofgwrite_bin, dir_flash) ,os.system(self.flash_commands))

[betacentauri]

The problem could be that the binary lies in flash memory. Can you please try to copy binary to /tmp before execution.
I have another idea how to fix it. I'll check it and come back later.

[Dimitrij]

Not works (in plugin)

ofgwrite_bin = "/usr/lib/enigma2/python/Plugins/Extensions/FullBackup/bin/ofgwrite"
os.system('cp %s /tmp' % ofgwrite_bin)

 

 

Ok (in telnet)

et9x00 login: root
root@et9x00:~# /tmp/ofgwrite /media/hdd/et9x00/

ofgwrite Utility v0.3
Author: Betacentauri
Based upon: mtd-utils-native-1.4.9
Use at your own risk! Make always a backup before use!
Don't use it if you use multiple ubi volumes in ubi layer!

Found kernel file: /media/hdd/et9x00/kernel.bin
Found rootfs file: /media/hdd/et9x00/rootfs.bin

Found /proc/mtd entries:
Device:   Size:     Erasesize:  Name:         Image:
/dev/mtd1 00600000  00020000    "kernel"  ->  /media/hdd/et9x00/kernel.bin
/dev/mtd2 07900000  00020000    "rootfs"  ->  /media/hdd/et9x00/rootfs.bin


Erasing kernel: flash_erase /dev/mtd1 0 0
Erasing 128 Kibyte @ 5e0000 -- 100 % complete
Flashing kernel: nandwrite -pm /dev/mtd1 /media/hdd/et9x00/kernel.bin
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000
Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000
Writing data to block 12 at offset 0x180000
Writing data to block 13 at offset 0x1a0000
Writing data to block 14 at offset 0x1c0000
Writing data to block 15 at offset 0x1e0000
Writing data to block 16 at offset 0x200000
Writing data to block 17 at offset 0x220000
Writing data to block 18 at offset 0x240000
Writing data to block 19 at offset 0x260000
Writing data to block 20 at offset 0x280000
Writing data to block 21 at offset 0x2a0000
Writing data to block 22 at offset 0x2c0000
Writing data to block 23 at offset 0x2e0000
Writing data to block 24 at offset 0x300000
Writing data to block 25 at offset 0x320000
Writing data to block 26 at offset 0x340000
Writing data to block 27 at offset 0x360000
Writing data to block 28 at offset 0x380000
Writing data to block 29 at offset 0x3a0000
Writing data to block 30 at offset 0x3c0000
Writing data to block 31 at offset 0x3e0000
Writing data to block 32 at offset 0x400000
Writing data to block 33 at offset 0x420000
Writing data to block 34 at offset 0x440000
Writing data to block 35 at offset 0x460000
Writing data to block 36 at offset 0x480000
Writing data to block 37 at offset 0x4a0000
Writing data to block 38 at offset 0x4c0000
Writing data to block 39 at offset 0x4e0000
Writing data to block 40 at offset 0x500000
Writing data to block 41 at offset 0x520000
Writing data to block 42 at offset 0x540000
Writing data to block 43 at offset 0x560000
Writing data to block 44 at offset 0x580000
Writing data to block 45 at offset 0x5a0000
Writing data to block 46 at offset 0x5c0000
Writing data to block 47 at offset 0x5e0000
Switching to user mode 2
killall: nmbd: no process killed
killall: smbd: no process killed
Syncing filesystem
Remounting root read-only
Erasing rootfs: flash_erase /dev/mtd2 0 0
Erasing 128 Kibyte @ 78e0000 -- 100 % complete
Flashing rootfs: ubiformat /dev/mtd2 -f /media/hdd/et9x00/rootfs.bin
ubiformat: mtd2 (nand), size 126877696 bytes (121.0 MiB), 968 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 967 -- 100 % complete
ubiformat: 968 eraseblocks are supposedly empty
ubiformat: flashing eraseblock 629 -- 100 % complete
ubiformat: formatting eraseblock 967 -- 100 % complete
Successfully flashed rootfs! Rebooting in 5 seconds...

 

[betacentauri]

Hi Dima73,

 

you use: os.system(self.flash_commands)

According to Milo you shouldn't use os.system:

http://openpli.org/f...ndpost&p=357831

 

And thanks for your work!

I'll test plugin today. Before I try to solve the problem with the Bus error.

[betacentauri]

Hi again,

 

I find no way to avoid bus error except copying binary to /tmp.

 

I took a look at the plugin. Looks quite good, if we get restore running. Thanks for that!!!

I found some minor things:

- Creating backup worked. Would be good if user can change directory name automatic_fullbackup.

- After first start backup location is "Keine" (none in english?). If you start manual backup, you get error messages. With "none" you shouldn't start backup.

- I would like to see a little bit more while backup is running. Something like in BackupSuite from predro...

- I use standard pli hd skin. I started Restore and have selected a directory which includes no image files. The error message is not really readable.
  Even though image files do not exist, user should still select "Simulate, Standart,..." and you call my binary. That's not necessary. Show only error message and return to main menu

Edited by betacentauri, 6 July 2013 - 09:56.