Beta [cfupdater] Custom Firmware Updater
- Thread starter xyz321
- Start date
Black Hole
May contain traces of nut
Having it trying to read .raw files specified on the command line.
Last edited:
Black Hole
May contain traces of nut
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:
Black Hole
May contain traces of nut
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:
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.
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
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.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 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.hdfPerhaps 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.
I did have a version of
tmenu to do this but accidentally blew it away when I ran fix-flash-packages.
If we were to go for item 3 then
cfupdater could be largely hidden from the user and listing zips would be superfluous.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
Well-Known Member
It all gets cleaned up when you run
opkg remove --autoremove cfupdaterThe 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
Well-Known Member
Most of that got worked out with my "restart without a reboot" stuff from several years ago now (eek!)
I don't disagree it's dangerous, but dd and hdparm are too. It was only a suggestion.
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
May contain traces of nut
I don't see why that should exclude the possibility of command line usage.