[fix-disk] Continue running if connection dies.


Staff member
This feature was first released to beta testers. Following successful testing it is now available in the main package repository.


The beta repository now contains updated tmenu and fix-disk packages which allow fix-disk to continue running in the background if the telnet connection dies. Please test it if you can.

When making a new telnet connection when fix-disk is running, the maintenance menu shows that the operation is in progress and gives the option to re-connect to it rather than starting a new one:

      |  M A I N T E N A N C E   M O D E   M E N U  |

  [ Humax HDR-Fox T2 (gpttest) 1.03.12/3.10 ]

        *** Note: A disk check and repair is in progress. ***

 fixdisk - Re-connect to running hard disk check and repair.
   short - Run short hard-disk self test.
    long - Run long hard-disk self test.
   check - Check self-test progress.
    gptf - Re-format disk using GPT scheme.
... elided ...

ASCII video of it in action at: https://asciinema.org/a/6hahypg6j7m6e1zn0zv51ulrw

Fix disk now also shows some progress indication on the front panel, ending with 'FixDisk Done' when it's complete so you don't need to remain connected throughout.

Although the main aim of this new feature is to stop the problems encountered with laptops etc. going to sleep during a disk check there are a couple of other side-effects that may be useful for power users:
  • You can connect to a running fix-disk process several times at once (so could watch the output on more than one computer or in webshell alongside telnet for example);
  • You can detach from a running fix-disk by pressing control-\ - that lets you return to the menu and leave fix-disk running in the background, just remember that the menu's "x" option will restart the Humax back into normal mode.
Behind the scenes, this uses the abduco utility for session management. There is an abduco package in the beta repository too which provides the command for general use.

Longer term there will need to be a new CFW version incorporating this for users that want/need to install the CFW in order to resolve a disk fault and don't have the luxury of installing the update tmenu package.
Last edited:
I have fixdisk running on both my HDRs as I am writing this. I initiated both sessions from my PC, watching both progress. I then used my iPad to start another Telnet session to check progress from there.

No issues to report at the moment, it is working well. The Telnet sessions are mirrored. So much so that each keystroke I make on the iPad, can in the Telnet session window on my PC.

I only received the tmenu update (version 1.21). Can you please advise what version number fix-disk should be (mines 0.5 at the moment).
When upgrading packages
Collected errors:
 * pkg_run_script: package "fix-disk" preinst script returned status 1.
 * preinst_configure: Aborting installation of fix-disk.
Are you on 3.10 and an HDR?

The dependencies don't seem very sensible:
What depends on root set
        tmenu 1.21      depends on fix-disk (>= 0.5)
        webif 1.3.4-14  depends on tmenu (>= 1.08)
So if you can't install fix-disk if you're not on 3.10 and an HDR, you can't install webif either as the dependencies won't be satisfied...
So if you can't install fix-disk if you're not on 3.10 and an HDR, you can't install webif either as the dependencies won't be satisfied..
Thanks, that needs fixing before release!
Are you on 3.10 and an HDR?

So if you can't install fix-disk if you're not on 3.10 and an HDR, you can't install webif either as the dependencies won't be satisfied...
No I am on 3.03 - never got round tuit for upgrade and will probably wait for 3.11 now
Web interface version: 1.3.5-1
Custom firmware version: 3.03 (build 2368)
Humax Version: 1.03.12 (kernel HDR_CFW_3.03)
tmenu installed on my HD OK just now.
Does one have to install fix-disk manually on an HDR then?
Does one have to install fix-disk manually on an HDR then?
No, it's in /bin/ within the firmware but if it finds a newer version installed into flash by the package, then it will use that instead.
Same thing for tmenu - it's there by default but there's a mechanism for pushing out updates.
Is there a problem with fix-disk writing to the log files when the fix-disk package is installed?

Running with fix-disk and tmenu installed and was not getting the fix.disk.log updated during execution of fix-disk. Uninstalling fix-disk and then tmenu and the log starts to be generated when fix-disk is executed again.
I've been running fix-disk many, many times over the past few days and it appears to be consistent. I.e. the fix-disk logs are not updated when running with fix-disk and tmenu installed but are written to if those two packages are not installed.

Custom firmware version: 3.10 (build 2734)
Humax Version: 1.03.12 (kernel HDR_CFW_3.10)​

I'm now running with
Rotate logs when they exceed 2MiB
How many rotated logs to keep 9999​
but I started off with the default.

I'm now logging via putty instead.
I'm not aware of any problems.
fix-disk writes its log file to /tmp/fix-disk.log while running (since the disk is not mounted), then copies it to /mnt/hd3/fix-disk.0.log once finished. Old logs should be bumped up by one (e.g. the old fix-disk.0.log becomes fix-disk.1.log). The web interface log rotation parameters aren't used here.
This hasn't changed between the version of fix-disk in 3.10 and the latest package update though. Which log is not being updated in your case?
On the last run I cleared down fix-disk.0.log, fix-disk.1.log, fix-disk.2.log via the diagnostics web-if page.
fix-disk.3.log was already 0 size but I cleared it anyway.

After running fixdisk (up until it freezes and I have to power on/off to regain access to the HDR) they are still 0 size and empty.
/tmp/fix-disk.log does not exist.

I'm not sure whether to start a new thread about the freezing or add details to this one. It freezes whether or not fix-disk is installed with 1 particular disk so I'm tempted to start a new thread., as when fix-disk is not installed I get the logs though I might have to uninstall and re-run just to make sure that I know which logs!