How can ofgwrite be debugged on boxes where it doesn't work?

[IanSav]

I am trying to run an online flash update of a Beyonwiz T4 (I believe this is an OEM of a Venton box) running openATV. When ofgwrite starts I see some initialisation and then the screen goes blank and the front panel OLED screen also goes blank. After a while I start seeing screen tearing and flashes on the TV screen. This continues until I use a shell to reboot the box. The box reboots normally with the original image.

Here is a log file extract from the start of ofgwrite until the reboot: log.txt

Is there anything I can do to help get this issue fixed?

[Huevos]

So your unzipped image is here: /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp

Have you tried calling ofgwrite from the command line and checking the output?

/usr/bin/ofgwrite -r -k /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp

[betacentauri]

Better at first add -n option to the command line. This option prevents any changes on the box. It only shows what it found and what it would execute. I have no knowledge about the box. Uses it old ubifs or ext4 root filesystem? Multiboot possible?

[IanSav]

Here are the results of the shell run with the "-n" option:

root@beyonwizt4:~# /usr/bin/ofgwrite -n -r -k /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp mkdir: can't create directory '/newroot': File exists

ofgwrite Utility v4.6.8 Author: Betacentauri Based upon: mtd-utils-native-1.5.1 and busybox 1.24.1 Use at your own risk! Make always a backup before use! Don't use it if you use multiple ubi volumes in ubi layer!

Flashing rootfs Flashing kernel Searching image files in /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp resolved to /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp Found kernel file: /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp/kernel.bin Found rootfs file: /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp/rootfs.bin Found UBIFS rootfs Found mounted /newroot Found mountpoint for rootfs file: /media/hdd

Found /proc/mtd entries: Device: Size: Erasesize: Name: Image: mtd0: 7f900000 00100000 "rootfs" -> /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp/rootfs.bin mtd1: 80000000 00100000 "entire_device" mtd2: 00700000 00100000 "kernel" -> /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp/kernel.bin mtd3: 000a0000 00001000 "cfe" mtd4: 001e0000 00001000 "splash" mtd5: 00080000 00001000 "macadr" mtd6: 00080000 00001000 "nvram" mtd7: 00040000 00001000 "bootconfig" mtd8: 00040000 00001000 "facconfig" mtd9: 00002000 00002000 "physmap-flash.0" Using kernel mtd device: /dev/mtd2 Using rootfs mtd device: /dev/mtd0 Read /proc/cmdline Kexec mode is: Current rootfs is: ubi0:rootfs Current kernel is: Current root sub dir is:

Syncing filesystem Found NAND flash Flashing rootfs: ubiformat /dev/mtd0 -f /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp/rootfs.bin Successfully flashed rootfs! Flashing kernel ... Found NAND flash Erasing kernel: flash_erase /dev/mtd2 0 0 Flashing kernel: nandwrite -pm /dev/mtd2 /media/hdd/images/openatv-7.4-beyonwizt4-20240510_usb.unzipped/beyonwiz/hdp/kernel.bin Successfully flashed kernel! Successfully flashed image Rebooting in 3 seconds...

[IanSav]

If it helps, here are the active filesystems:

root@beyonwizt4:~# mount rootfs on / type rootfs (rw) ubi0:rootfs on / type ubifs (rw,relatime) devtmpfs on /dev type devtmpfs (rw,relatime,size=577208k,nr_inodes=124764,mode=755) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) tmpfs on /media type tmpfs (rw,relatime,size=64k) tmpfs on /var/volatile type tmpfs (rw,relatime) devpts on /dev/pts type devpts (rw,relatime,mode=600) /dev/sda1 on /media/hdd type ext4 (rw,relatime,data=ordered) none on /dev/shm type tmpfs (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) nfsd on /proc/fs/nfsd type nfsd (rw,relatime) /etc/auto.network on /media/autofs type autofs (rw,relatime,fd=6,pgrp=538,timeout=5,minproto=5,maxproto=5,indirect) tmpfs on /newroot type tmpfs (rw,relatime)

[betacentauri]

That looks ok for me. Ofgwrite found the correct mtd0 and mtd2 devices and recognized that it is ubifs and uses the correct tools. Do you have a serial cable for the box? The whole flash process is only visible via serial cable.

So I would say try without -n option. It might be that ofgwrite cannot write to the framebuffer(TV screen) properly, but I would guess that it still flashes the box. So wait at least 5 minutes. If then the box didn’t reboot, try to login on the box. If that works, please look into /var/log/messages. There you find debug info from ofgwrite. Post it here.

You could also try to stop e2 first. This might make a difference for the framebuffer thing.

[IanSav]

I have an interesting update for you. When I generated the results above by using the "-n" option I thought I would try another flash to see what happened. The flash ran, from within openATV, to completion with no issue!!! I can't tell you that anything changed as I don't think anything changed. I just ran the test run, posted the results and then ran another production run and it worked.

There was a message about 6 bad blocks. I don't know if that might be causing issues. In the latest run it all worked.

May I make a request for a new command line option for ofgwrite? I would like to have a "-v" option to write as much logging information as is possible and reasonable into the Enigma log file for analysis by developers and yourself. I think the data should be written to the Enigma log files as users already know about collecting logs and sending them to developers. If there are issues in the future we could add the "-v" option and collect the run data for analysis.

In this case I have the box here to look at another issue but it is not my box. If the user could give me a log file of ofgwrite issues we may be better able to diagnose future issues.

Thank you for your response and suggestions to address the problem.

[betacentauri]

6 bad blocks is no big problem and bad blocks are normal on a nand/ubifs device. Regarding log I’ll comment later. Just don’t have time.

[betacentauri]

First ofgwrite flashes (in many cases) the root filesystem. To be able to do it, it needs to close all open files and so all log files (and also stop e2) before the real flashing starts. So there is no log with all infos. Yes, that would be nice, but without an extra mounted filesystem it’s impossible to do that. /tmp/ is gone after the reboot. Ofgwrite write the output to the console and also to the system log. I think the output is enough to see what it found and tries to do. With an eConsoleAppContainer e2 should be able to write the output from ofgwrite to the e2 log file.

[betacentauri]

Ofgwrite is a standalone application which don’t need e2. E2 can be stopped and ofgwrite be executed via command line. So there is no e2 log there in all cases and how can ofgwrite directly write to the e2 log? It’s a different process. I would prefer eConsoleAppContainer solution, if it works.