8 replies to this topic

[snake.bite]

Hi all,

as the recommendation goes to better flash an image rather than update packages, I tried with my VU+ Solo2 running OpenPLI 9.0. It downloads the image, unpacks, starts flashing but immediately fails. No error message apart from "fail". Regardless, which image I try - at least the latest 9.0 and dev builds.

I even tried to flash from USB (image on usb drive, power cycle, press "power") with the same result.

 

I know this brand is not supported officially, but still, is there a way to find out what is going on? Any logs written by the process?

 

Any ideas?

 

Chris.

[WanWizard]

Flashing from USB is done by the bootloader (the BIOS of the box), you need to fabricate a console connection to be able to see what is happening.

 

If the box still boots, most images have an option in the menu to flash the box, that might provide more feedback.

 

It is possible the image has become to big, some bootloaders have limits smaller than the size of flash memory..

[snake.bite]

Good idea, will try to connect to the RS232 next time.

 

Flashing from OpenPLi was my first attempt. I could not see any more hints. Judging on how quickly it fails, I would assume there is some integrity or signature check that fails. Or some magic number is off. Size check would fit as well :-| OTOH the installed image works fine and can take package updates. But then I have no idea about the actual layout in flash and what's on the HDD for example.

 

I was hoping the flash utility in OpenPLi creates some logs while not actually flashing that could be inspected.

 

Chris.

[littlesat]

Are you sure the usb stick is fine? How far did it go? You say it downloaded.. did it unpack? Did it tried to flash?

[WanWizard]

Size check would fit as well :-| OTOH the installed image works fine and can take package updates.

 

Like I said, there is a difference between the size of the root partition in flash, and the maximum file size the bootloader accepts when flashing.

 

You seem to be able to handle the commandline, so you could try flashing it from the commandline, using ofgwite, and see if that produces any useful output.

[twol]

With python 3 it is difficult (but possible to get the image to flash) but only by restricting whats included in the base image.
In OpenViX, there is a small flash option(which Huevos has mentioned) that allows this to happen - but its use is restricted for example to use as a client box in a C/S setup - and even there the user had to add a  swap file to get a working and viable setup.

[WanWizard]

All OpenPLi 9 images should still work on all hardware we support. For OpenPLi 10 that is no longer the case, and we have decided to drop support for those boxes, instead of making "small" images for it.

[snake.bite]

Hi all,

thanks for your great support! I have tried with the command line first. Following https://wiki.openpli...he_command_line

root@vusolo2:~# ofgwrite -r -k /hdd/downloaded_images/vuplus/solo2/
mkdir: can't create directory '/newroot': File exists
/usr/bin/ofgwrite: line 6:   744 Segmentation fault      /newroot/ofgwrite_bin "$@"
root@vusolo2:~#

Moving /newroot away wasn't possible because it was in use.

 

Never give up hope, tried the UI. Used the 2024-09-08 image from 9.0. Output on serial was not helpful. (was it even related?):

[eDVBPESReader] ERROR reading PES (fd=68): Value too large for defined data type

So, next for the USB. Downloaded openpli-9.0-release-vusolo2-20240908_usb.zip. Extracted on 8GB FAT-USB drive according to https://wiki.openpli..._a_Vu.2B_Solo_2

 

Serial console output

FE initialized.
USB: New device connected to bus 3 hub 1 port 1
USB: Resetting device on bus 3 hub 1 port 1
USB: Locating Class 08 Vendor 090C Product 1000: Mass-Storage Device
USBMASS: Unit 0 connected
waiting for usb...done
checking usb
Found high priority Mass Storage bus = 3, index  = 0 
checking front key
readFrontKey 0 0
Checking usbdisk0:/vuplus/solo2/ignore.update......NO
Checking usbdisk0:/vuplus/solo2/force.update......NO
Checking usbdisk0:/vuplus/solo2/cfe_cfe_auto.bin......NO
Checking usbdisk0:/vuplus/solo2/root_cfe_auto.bin......YES
Checking usbdisk0:/vuplus/solo2/splash_cfe_auto.bin......NO
Checking usbdisk0:/vuplus/solo2/kernel_cfe_auto.bin......YES
Checking usbdisk0:/vuplus/solo2/reboot.update......YES
waiting for update key
ACK : 
readFrontKey 0x0
ACK : 
ACK : 
FrontPanel Key : d1, 1
readFrontKey 0xd101
Update
Reading usbdisk0:/vuplus/solo2/cfe_cfe_auto.bin:  Skipping...: File not found
Reading usbdisk0:/vuplus/solo2/initrd_cfe_auto.bin:  Done. 5976879 bytes read

Programming...
done. 5976879 bytes written
Reading usbdisk0:/vuplus/solo2/splash_cfe_auto.bin:  Skipping...: File not found
Reading usbdisk0:/vuplus/solo2/kernel_cfe_auto.bin:  Done. 3601830 bytes read

Programming...
done. 3601830 bytes written
Checking usbdisk0:/vuplus/solo2/root_cfe_auto.bin......YES
Loader:elf Filesys:raw Dev:flash0.initrd File: Options:bmem=192M@64M bmem=256M@512M
Loading: 0x80001000/12707456 0x80c1f680/113040 Entry address is 0x8048f3e0
Starting program at 0x8048f3e0

Linux version 3.3.6-1.2-g7f330e7-dirty (shcheong@NcshN2) (gcc version 4.5.3 (Broadcom stbgcc-4.5.3-2.4) ) #9 SMP Tue Feb 12 10:55:17 KST 2013
Fetching vars from bootloader... found 13 vars.

...

So, it worked!

 

I have no clue what was different this time or why flashing from within OpenPli did not work. Next time, I will definitely monitor the process through serial. That was a great tip WanWizard!

 

[WanWizard]

What OpenPLi was exacly on it? 8.3 ?

 

There was a version where ofgwrite crashed with a segmentation fault on mipsel boxes, guess this was the one. If would also make flashing from the UI fail, as it uses the same ofgwrite command.