• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Beta [cfupdater] Custom Firmware Updater

xyz321 said:
That would bypass the check on the system id.
Click to expand...
What would:
Black Hole said:
have cfupdater accept .zip as well as .hdf update files.
Click to expand...
...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.
Click to expand...
?
 
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.
Click to expand...
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?".
 
Last edited:
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.
 
Last edited:
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.
 
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?
Click to expand...
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.
Click to expand...
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).
Click to expand...
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.
Click to expand...
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?".
Click to expand...
If we were to go for item 3 then cfupdater could be largely hidden from the user and listing zips would be superfluous.
 
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.
Click to expand...
I think there are two issues with this:
  1. As mentioned above the system ID is contained in the hdf file so acting directly on a .raw file would bypass this check.
  2. 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.
 
Black Hole said:
If temporary, should they have been cleaned up automatically?
Click to expand...
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).
 
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.
Click to expand...
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.
Click to expand...
:rolling:
xyz321 said:
I think there are two issues with this
Click to expand...
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.
Click to expand...
Is the loader not still there and usable to re-flash if it all goes pear-shaped?
 
Maybe the core command in sbin with a more user-proof wrapper invokable from tmenu or from the command line with no path?
 
You must log in or register to reply here.
Back
Top