30 replies to this topic

[rtzhjgg0]

The Vu images that I use are PLi, VTi, ViX and BH. But actually you can switch from one to the other only manually over USB stick and PC.
But I'm too lazy for that so I created my own method which allows me to flash over GUI using MQB.

How it works:
I have 4 image backups on '/media/hdd/vuBackupsJ/IMAGENAME/' as 'vuplus' folders.
The script that realizes the restoring is in my script folder '/media/hdd/jscripts'
The 4 functions that starts flashing are in the YELLOW button of MQB. When you start one of this functions, the script receives a similar command: '/media/hdd/jscripts/_restore.sh /media/hdd/vuBackupsJ/VTIfull'.
Then the selected image will be immediately flashed - just turn the box on again over remote control (without leaving your sofa ).

ALL you need is the the cool script of scope34,  '_restore.sh' which can be found on VTi images in 'usr/lib/enigma2/python/Plugins/SystemPlugins/VTIPanel'. It can manage all actual Vu boxes. I changed only one line of this script - line 121:

from
'cp /usr/lib/enigma2/python/Plugins/SystemPlugins/VTIPanel/sleep /tmp/'
to
'cp /bin/sleep /tmp/'

This method runs on my Solo2 since a couple of days fast and without any problems. All backup images have now on their YELLOW button the option to change flash over GUI.

To create image backups on HDD I use in all images Pedro_Newbies plugin 'BackupSuite'.

PS.
with this method no VTi-files are copied to other images. The '_restore.sh' script remains on your HDD

 

		<content>
			<name>restore Vu Image PLIfull -as script</name>
			<module>Screens.Console</module>
			<screen><![CDATA[Console, "restore Vu Image PLIfull", ["/media/hdd/jscripts/_restore.sh /media/hdd/vuBackupsJ/PLIfull"]]]></screen>
		</content>
		<content>
			<name>restore Vu Image BHfull -as script</name>
			<module>Screens.Console</module>
			<screen><![CDATA[Console, "restore Vu Image BHfull", ["/media/hdd/jscripts/_restore.sh /media/hdd/vuBackupsJ/BHfull"]]]></screen>
		</content>
		<content>
			<name>restore Vu Image VTIfull -as script</name>
			<module>Screens.Console</module>
			<screen><![CDATA[Console, "restore Vu Image VTIfull", ["/media/hdd/jscripts/_restore.sh /media/hdd/vuBackupsJ/VTIfull"]]]></screen>
		</content>
		<content>
			<name>restore Vu Image VIXfull -as script</name>
			<module>Screens.Console</module>
			<screen><![CDATA[Console, "restore Vu Image VIXfull", ["/media/hdd/jscripts/_restore.sh /media/hdd/vuBackupsJ/VIXfull"]]]></screen>
		</content>

 

Attached Files

•  Restore_vuImges_over_MQB.jpg   40.27KB   69 downloads

[hemertje]

a small note:

 

do it at your own risk

OpenPLi does not support multiboot

[Lost in Space]

Flashing (different) Images with a script is NO Multiboot ...

Edited by gutemine, 9 May 2013 - 21:29.

[rtzhjgg0]

a small note:

 

do it at your own risk

OpenPLi does not support multiboot

It's not a  multiboot - just flashing over GUI.
You don't boot from a different device - you remain on Flash

[hemertje]

as you like...

 

we are not responsible if users use this

[rtzhjgg0]

as you like...

 

we are not responsible if users use this

Of course, its just a wokaround - but it works

Edited by rtzhjgg0, 9 May 2013 - 21:37.

[Lost in Space]

Well to be honest - this way of flashing inspired dFlash Plugin for Dreamboxes and besides that nobody supports flashing this way lots of users like it this way.

 

The bios actually doesn't do ich much different either, even ubiformat gets it's job if I read the bootlogs that I found correctly.

Edited by gutemine, 9 May 2013 - 21:45.

[Rob van der Does]

Are you sure this script works for recent images? As far as I know UBIFS doesn't support 'life-flashing'.

[rtzhjgg0]

Are you sure this script works for recent images? ....

 

The '_restore.sh' script by scope34 was tested from me and works perfectly on this actual Solo2 images: OpenPLi, VTi Team, ViX Team and  Black Hole.

[pieterg]

I have not seen the script, but I'm assuming it chroots to a tmpfs before it replaces the rootfs.
Then, with a synced rootfs, you probably won't run in too many problems if you immediately switch off the power after writing the new image.

But it's still a bit of a dirty hack of course.

[Lost in Space]

No the script just copies the needed binaries tp /tmp and then executes them from there to prevent failing due to the already erased root filesystem.

 

But I agree it would be better if after the init 2 to get into single user mode the root filesystem would be re-mounted read only and reboot -f -n would be used instead of the turn off power binary. Then the box would also reboot properly as dFlash does it.

 

And yes, you can flash ubifs images with nandwrite too, as the -F option is used when creating the ubifs images which fixes the freespace. Only the first boot then takes slight longer due to the fixing of the freespace. Using ubiformat with the image would be better off course as the bios does it, but this no must.

 

And dFlash and nfiwrite also flash ubifs nicely due to this.

Edited by gutemine, 10 May 2013 - 15:20.

[rtzhjgg0]

 

...you probably won't run in too many problems if you immediately switch off the power after writing the new image...

 

The sript displays at the end:

 

"Please power on again after 60 seconds to boot the flashed image"

 

And I respect of course this Minute after.

[pieterg]

...you probably won't run in too many problems if you immediately switch off the power after writing the new image...

 
The sript displays at the end:
 
"Please power on again after 60 seconds to boot the flashed image"

OK, I see a simple way to speed up the whole process by about a minute then

[Lost in Space]

There is no need to respect it :-)

 

The power off ist just there to avoid that on a reboot the filesystem cache of the root which still contains stuff from the OLD content is flushed to the root Flash which would runin the newly written root image. if you re-mount the root read only this triggers a sync BEFORE writing the new flash content and then you can reboot with -f -n option and boot immediately the new one without troubles.

 

As I said I use a very similar approach in dFlash and there it works this way nicely ....

 

The Flash is no Flux Compensator that needs to cool down first.

Edited by gutemine, 10 May 2013 - 15:33.

[Pedro_Newbie]

The '_restore.sh' script by scope34 was tested from me and works perfectly on this actual Solo2 images: OpenPLi, VTi Team, ViX Team and  Black Hole.

Could you place the _restore.sh script here so others can have a look/go at it?

[Rob van der Does]

The '_restore.sh' script by scope34 was tested from me and works perfectly on this actual Solo2 images: OpenPLi, VTi Team, ViX Team and  Black Hole.

Could you place the _restore.sh script here so others can have a look/go at it?

Here you go.  _restore.zip   1.56KB   25 downloads

[Pedro_Newbie]

Thanks.

The only "problem" I see is on line 130

            /tmp/nandwrite -q -p /dev/mtd2 boot_cfe_auto.jffs2

Back-up's made with the current BackupSuite don't contain the boot_cfe_auto.jffs2 any more, the creation of this file was skipped a long time ago in the BackupSuite.

 

Eventually the 6 occurrences of the lines:

    BOXTYPE=vuplus

    OPTIONS="--eraseblock=0x20000 -n -l"

could be replaced by 1 entry right after MTDKERNEL=1 (line 52)

[pieterg]

and you really should at least sync the rootfs, before writing to the partition. There can be dirty cache, just waiting to be written to flash.
And I'd remount it readonly, and chroot to /tmp.

[Lost in Space]

I'm not sure if this is the right approach, as the used binaries are not statically linked, so a chroot will only make things worser.

 

But I agree that the script simply is a mess, as it was carried forward to new boxes and just checked if it still works. It includes now some unused parameters and binaries like erase_all which is now a script, etc. And as i already wrote switching root flashing to ubiformat as the Bios of your boxes does it would be also adviceable.

 

If you really want this to work stable and without hassle the full functionality should be migrated into a klibc and statically linked binary as I did it with my nfiwrite for the Dreamboxes. And yes, then it is also amazingly fast and the system can rbeoot nicely after a flash with the new image.

 

As all the mtd utils binaries are open source and the needed klibc patches are available this is only a few hours of work, but it is woth it.

Edited by gutemine, 11 May 2013 - 09:09.

[Rob van der Does]

Is a powercycle really needed for a flash using the above scripts? Could a 'reboot + sleep xx' command not be sufficient?

 

I ask so, because for me the backpanel of my STB's can hardly be reached. And for a 'normal' flash of most VU-boxes the presence of a file named 'reboot.update' is sufficient to reboot the box on completion of the flashing procedure, so to me that would seem to be the same as for a 'life-flash' (and I presume other brands have similar options).