Beta [cfupdater] Custom Firmware Updater

xyz321 · Feb 20, 2021

That would bypass the check on the system id.

Black Hole · Feb 20, 2021

xyz321 said:
That would bypass the check on the system id.

What would:

Black Hole said:
have cfupdater accept .zip as well as .hdf update files.

...or

prpr said:
It also occurs to me that just being able to feed it a .raw file would be useful too, as packing .raw files into a .hdf (which takes an annoyingly long time) only for it to be unpacked again by cfupdater as the first step seems like such a waste of time.

?

xyz321 · Feb 20, 2021

Black Hole said:
What would:

Having it trying to read .raw files specified on the command line.

Black Hole · Feb 22, 2021

xyz321 said:
At the moment it is command line only but if it is useful I may create a webif plugin to upload the hdf file.

Having been using cfupdater, here are my suggestions (some of which are covered in previous discussion):

1. Why isn't cfupdater on the default command search path, so the invocation has to be /mod/sbin/cfupdater instead of simply cfupdater?

2. It would be very nice if cfupdater were able to accept a .zip containing the .hdf, and check the .zip does indeed contain a correctly-named .hdf before unpacking, verifying, and flashing. You could even consider only accepting .zip (not .hdf), because of the inadequacy of a single specific filename for version identification. Existing custom firmware downloads are all .zips, as are Humax standard firmware downloads.

3. Having given some thought to the "ease of use" post-beta, I think firmware downloads should be delivered in the form of specific individual packages user-installed in the usual way, which deposit a .zip (for ease of version identification) into a specific known folder. cfupdater would then take that folder as its default working directory for the source of zipped .hdfs (over-rideable on the command line by specifying an explicit path of course).

4. cfupdater could be included as a Maintenance-Mode Telnet Menu option.

5. The command cfupdater invoked without a parameter should list the .zips in the reserved folder (see 3) and prompt the user which one to install (even if there is only one), with the usual "are you sure?".

Black Hole · Feb 22, 2021

On my HD-FOX, I downloaded and extracted 3.14a into /mod/cfupdater. Having installed it (successfully, it seems, complete with RTS), I went into /mod/cfupdater to delete the .hdf and .zip, and discovered a folder tree tmp and tmp_root, which seem to contain a fair few files and a large number of redirects. Are these part and parcel of the cfupdater installation, or temporary? If temporary, should they have been cleaned up automatically?

They appear to occupy 28MB of disk space:

Code:

HDFOX3# du -sh tmp_root                                                                                                                                                  
28M     tmp_root                                                                                                                                                          
HDFOX3# du -sh tmp                                                                                                                                                        
4.0K    tmp                                                                                                                                                              
HDFOX3#

Update: I see tmp_root exists even on a HDR I have installed cfupdater on but not fiddled with (but is 30MB on a HDR-FOX). I'll take it this is a permanent part of cfupdater's installation.

xyz321 · Feb 22, 2021

The tmp directory is used as the working directory for extracting the raw files from the hdf and is normally empty except when cfupdater is running.

The tmp_root directory is created when cfupdater is installed and contains a temporary root filesystem which is used when the flash is being programmed. It is created at installation time instead of run time because it takes a quite a few seconds for it to be generated. Most of the files in there are probably unnecessary but I need to spend time going through it to find those which are essential. I accept that its name tmp_root could easily be interpreted as something which can be deleted, perhaps it should just be called root.

xyz321 · Feb 22, 2021

Black Hole said:
1. Why isn't cfupdater on the default command search path, so the invocation has to be /mod/sbin/cfupdater instead of simply cfupdater?

There was a future intention for it to be run from the webif or as a menu option and not directly by the user.

2. It would be very nice if cfupdater were able to accept a .zip containing the .hdf, and check the .zip does indeed contain a correctly-named .hdf before unpacking, verifying, and flashing. You could even consider only accepting .zip (not .hdf), because of the inadequacy of a single specific filename for version identification. Existing custom firmware downloads are all .zips, as are Humax standard firmware downloads.

I normally save the different hdf versions as subdirectories under /mod/cfupdater/fw when testing. Support for zip files can be added but I would prefer to keep support for hdf files since it saves a step in processing and is therefore slightly quicker.

Code:

/mod/cfupdater/fw/3.10/HDR_FOX_T2_upgrade.hdf
/mod/cfupdater/fw/3.11/HDR_FOX_T2_upgrade.hdf
/mod/cfupdater/fw/3.13/HDR_FOX_T2_upgrade.hdf
/mod/cfupdater/fw/3.13a/hdr_fox_t2_upgrade.hdf
/mod/cfupdater/fw/3.14/HDR_FOX_T2_upgrade.hdf
/mod/cfupdater/fw/3.14a/hdr_fox_t2_upgrade.hdf

3. Having given some thought to the "ease of use" post-beta, I think firmware downloads should be delivered in the form of specific individual packages user-installed in the usual way, which deposit a .zip (for ease of version identification) into a specific known folder. cfupdater would then take that folder as its default working directory for the source of zipped .hdfs (over-rideable on the command line by specifying an explicit path of course).

Perhaps the best way to do this would be to remove the requirement for fcfupdater to be run in maintenance mode. That way the CF update package could run cfupdater as part of its installation script and the naming of the files can be hidden from the user. That would mean that hdf files could still be used and would result in a slightly faster installation procedure (since it would no longer have to perform an unzip).

The reason for maintenance mode is to ensure that all processes associated with packages have stopped before switching to the temporary root directory, resulting in a known state. I was too lazy to go through all the packages to ensure that they shut themselves down correctly but perhaps I was being over cautious.

4. cfupdater could be included as a Maintenance-Mode Telnet Menu option.

I did have a version of tmenu to do this but accidentally blew it away when I ran fix-flash-packages.

5. The command cfupdater invoked without a parameter should list the .zips in the reserved folder (see 3) and prompt the user which one to install (even if there is only one), with the usual "are you sure?".

If we were to go for item 3 then cfupdater could be largely hidden from the user and listing zips would be superfluous.

xyz321 · Feb 22, 2021

prpr said:
It also occurs to me that just being able to feed it a .raw file would be useful too, as packing .raw files into a .hdf (which takes an annoyingly long time) only for it to be unpacked again by cfupdater as the first step seems like such a waste of time.

I think there are two issues with this:

As mentioned above the system ID is contained in the hdf file so acting directly on a .raw file would bypass this check.
The raw filename contains the address for where the file is to be copied to flash memory. The hdf file packages this and makes it less prone to user error. Having the user in control of the raw filenames could cause a bricked box.

prpr · Feb 22, 2021

Black Hole said:
If temporary, should they have been cleaned up automatically?

It all gets cleaned up when you run opkg remove --autoremove cfupdater
The standard Webif doesn't remove auto-installed dependent packages (although I did write a patch for it which is incorporated in my Webif build).

prpr · Feb 22, 2021

xyz321 said:
The reason for maintenance mode is to ensure that all processes associated with packages have stopped before switching to the temporary root directory, resulting in a known state. I was too lazy to go through all the packages to ensure that they shut themselves down correctly but perhaps I was being over cautious.

Most of that got worked out with my "restart without a reboot" stuff from several years ago now (eek!)

xyz321 said:
did have a version of tmenu to do this but accidentally blew it away when I ran fix-flash-packages.

xyz321 said:
I think there are two issues with this

I don't disagree it's dangerous, but dd and hdparm are too. It was only a suggestion.

Having the user in control of the raw filenames could cause a bricked box.

Is the loader not still there and usable to re-flash if it all goes pear-shaped?

xyz321 · Feb 22, 2021

prpr said:
Is the loader not still there and usable to re-flash if it all goes pear-shaped?

We don't really know what would happen if the loader area in flash memory is corrupted.

Black Hole · Feb 22, 2021

xyz321 said:
There was a future intention for it to be run from the webif or as a menu option and not directly by the user.

I don't see why that should exclude the possibility of command line usage.

/df · Feb 22, 2021

Maybe the core command in sbin with a more user-proof wrapper invokable from tmenu or from the command line with no path?

/df · 2025-11-10T14:34:59+0000

With:

HD, CF3.13
flash memory retained but new blank external storage
wi-fi that needs wifi-helper to connect::

CF update 3.14 from web package manager hangs with panel showing ⋿I-FI after reboot and countdown from 60, after this web output:

Code:

 >>> opkg install custom-firmware-hd
Installing custom-firmware-hd (1.03.02_mod_3.14) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/custom-firmware-hd_1.03.02_mod_3.14_mipsel.opk.
Configuring custom-firmware-hd.
Archive:  /mod/firmware/auto/hd_10302_mod314.zip
  inflating: hd_fox_t2_upgrade.hdf   
HDF Tool v1.0.4, by af123, 2011-2015.

Opening hd_fox_t2_upgrade.hdf, 23432507 bytes.

  Blocks:     723
  Model:      4
  System ID:  806c.7000

x  1.hdfbin-3-000000.raw          (21663744 bytes)
x  2.hdfbin-3-1600000.raw         (1915419 bytes)

Processed in: 35.47s

New version is 3.14

    +---------------------------------------------------------------------+
    | This system will reboot into maintenance mode shortly.              |
    |                                                                     |
    | The firmware upgrade will then be applied and a reboot will follow. |
    | Progress is shown on the front panel display.                       |
    +---------------------------------------------------------------------+


Done.

Unsurprisingly, 3.13 is shown after hitting the big red (actually small black) button.

Owen Smith · 2025-11-10T15:41:20+0000

/df said:
With:

HD, CF3.13

flash memory retained but new blank external storage

Blank external storage basically means you don't have CF installed, so of course this won't work. Fresh installs need a USB stick.

/df · 2025-11-10T15:53:37+0000

Blank before installing WebIf, etc, that is, or the cfupdate package could not have been offered. The actual CF in flash ROM is CF 3.13. The "USB stick" is a 64GB MicroSD card in a USB Hub/reader,. 37GB available after set-up. For further clarity:

Code:

# opkg list-installed
7zip - 9.20.1
abduco - 0.6-1
anacron - 2.3-3
at - 3.1.18
auto-schedule-restore - 1.6-2
bash - 4.3-30
betaftpd - 0.0.8pre17-5
boot-settings - 1.0.5-1
busybox - 1.20.2-1
bzip2 - 1.0.4
ca-bundle - 3.41
cfupdater - 0.0.5
chaseget - 0.1.3-1
cifs - 2.6.18
cron-daemon - 1.18.3-5
curl - 8.15.0
custom-firmware-hd - 1.03.02_mod_3.14
dbupdate - 1.0.0
detectads - 0.2.5-4
dropbear-ssh - 2024.85
e2fsprogs - 1.42.13
epg - 1.3.0-8
exfat - 1.2.6
ffmpeg - 4.1-1
file - 5.0.4
foxlink - 1.0.5-2
fuse - 2.7.6-1
hmt - 2.0.12
humidify - 1.0.4
hwctl - 1.0.0
id3v2 - 0.1.11-1
inotify-tools - 3.14
ir - 1.23-2
jim - 0.83
jim-cgi - 0.7-2
jim-xconv - 1.0.1
lamemp3 - 3.98.4
libevent - 2.0.11
libiconv - 1.13.1-1
libpcre - 8.37-1
libreadline - 6.2-1
libsndfile - 1.0.25-2
libutil - 0.9.29
libxconv - 1.0.5
libzlib - 1.3.1
lighttpd - 1.4.53-3
lsof - 4.87
mediatomb - 0.11.0r2-7
mtd-utils - 1.4.2
multienv - 1.8
multimode - 1.0.2
ncurses - 5.9
network-shares-automount - 1.5
nfs-utils - 1.2.3-3
nicesplice - 1.8
nicesplice-magic-folders - 1.4.1
ntfs-3g - 2013.1.13-5
nugget - 1.0
openssl - 1.1.1.d-1
openssl-command - 1.0.0.d
portmap - 6.0-1
procps - 3.2.8-3
python - 2.7.1-3
qtube - 0.1.0-3
radio-ss-off - 0.53
recmon - 2.2.1-4
rsvsync - 1.1.13
rsync - 3.0.8
samba - 3.6.25-1
schedchk - 0.1.1
service-control - 2.6
sidecar - 2.8
smartmontools - 6.4
sqlite3 - 3.46.1
ssmtp - 2.64
stripts - 1.4.6-1
swapper - 1.1.5
sweeper - 2.3.1
sysmon - 1.2.6-1
tclcheck - 1.2-1
tcpfix - 1.0.0
tcpping - 1.1
tmenu - 1.28-1
transmission - 2.84-1
transportx - 0.5
trm - 1.2
tunefix - 2.4.0
tunefix-update - 1.0.162
tweak - 1.0
virtual-disk - 1.1
virtual-disk2 - 2.0-5
webif - 1.5.4
webif-channelicons - 1.2.21
webif-charts - 1.3
webshell - 1.0.5
wget - 1.24.5
wireless-helper - 2.0
wireless-tools - 29-1
wpa-supplicant - 0.6.10
youtube-dl - 2025.07.01
zeroconf - 2.0-2
zip - 3.0-1
#

The problem is at the fag- but critical end of the installation of custom-firmware-hd - 1.03.02_mod_3.14.

Owen Smith · 2025-11-10T18:54:09+0000

/df said:
Blank before installing WebIf, etc, that is, or the cfupdate package could not have been offered. The actual CF in flash ROM is CF 3.13. The "USB stick" is a 64GB MicroSD card in a USB Hub/reader,. 37GB available after set-up. For further clarity:

The CF is not in flash though, most of it is on disc which you have just said is blank.

/df said:
The problem is at the fag- but critical end of the installation of custom-firmware-hd - 1.03.02_mod_3.14.

This is a blank disc installation case, who cares! Just use a USB stick to update the CF to 3.14 and be done with it. This may require a USB hub on the HD Fox T2.

prpr · 2025-11-10T20:21:11+0000

/df said:
new blank external storage

CF update 3.14 from web package manager hangs with panel showing ⋿I-FI after reboot

How can the storage be blank if the WebIf is installed?
I don't know what generates EI-FI on the display.
What's in /mod/tmp/cfupdate.log (assuming the disk really isn't blank)?
What happens if you go to the Administration (Telnet) menu and select the "reprog" option?

Owen Smith said:
Blank external storage basically means you don't have CF installed,

No it doesn't. The CF is in the flash.

so of course this won't work. Fresh installs need a USB stick.

It's not a fresh install if 3.13 is already installed.

/df said:
Blank before installing WebIf, etc,

So, er, not blank then.

Owen Smith said:
The CF is not in flash though, most of it is on disc which you have just said is blank.

The CF is in the flash. Packages are on the disk.

This is a blank disc installation case, who cares!

It turns out it wasn't blank after all.

Just use a USB stick to update the CF to 3.14 and be done with it.

What if it's remote?

This may require a USB hub on the HD Fox T2.

Why? You would just unplug the disk and plug in the stick if you want to update using the USB stick method.

xyz321 · 2025-11-10T20:59:50+0000

prpr said:
I don't know what generates EI-FI on the display.

I think it comes from the attempt to display "WiFi" on the seven segment display. The 'W' appears as three horizontal bars.

There seems to be a some issue with cfupdater in maintensnce mode on an HD. Running it in "fast mode" worked for me from the command line...

Code:

cfupdater -f /mod/firmware/auto/hd_10302_mod314.zip

Black Hole · 2025-11-11T00:23:01+0000

Owen Smith said:
Just use a USB stick to update the CF to 3.14 and be done with it.

Don't you realise there is now a WebIF method to download and then update the CF in Flash? So much easier...

Beta [cfupdater] Custom Firmware Updater

Well-Known Member

May contain traces of nut

Well-Known Member

May contain traces of nut

May contain traces of nut

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

May contain traces of nut

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

May contain traces of nut