Upgrade of parent's CF failed, now have 1 day to fix

O

Owen Smith

Well-Known Member
I tried doing a year's worth of CF updates to my parents HDR Fox T2 yesterday. It was very slow updating packages so I left it doing them all overnight (suspisciously little traffic on the router lights). This morning it had mostly finished and had somehow missed webchannel icons, I did that, rebooted, all seemed fine, did fix-flash-packages and it's all gone wrong. Now all I get is the web page offering me the button to install the full webif. I've clicked on that, and an hour later it's still claiming to be downloading. This can't be right.

I have precisely 1 day to fix this, and then it will have to stay however it ends up for 6 months until I'm at my parents again.

Help please, how do I get it all back and working again?
 
telnet access is working. I assume there's some diagnostic I can run which stands a chance of restoring things, but I have no idea which one.
 
I'm running diag fix-flash-packages from telnet since that seems to be what failed. It's got this far and then hung:

/-------------------------\
| T E L N E T M E N U |
\-------------------------/
[ Humax HDR-Fox T2 (parentshdrfoxt2) 1.03.12/3.03 ]
1 - Restart into maintenance mode.
2 - Remove web interface password.
stat - Show what the box is currently doing.
x - Exit and close connection.
rset - Reset custom firmware environment.
srma - Set return-to-manufacturer (RMA) mode.
diag - Run a diagnostic.
cli - System command line (advanced users).

Please select option: diag

Enter the diagnostic name (or press return to cancel): fix-flash-packages
Are you sure you wish to run diagnostic 'fix-flash-packages'? [Y/N] y
Running: fix-flash-packages
Re-installing dbupdate
Removing package dbupdate from root...
Installing dbupdate (1.0.0) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/dbupdate_1.0.0_mipsel.opk.
Configuring dbupdate.
Re-installing disable-dso
Removing package disable-dso from root...
Installing disable-dso (0.2) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/disable-dso_0.2_mipsel.opk.
Configuring disable-dso.
Re-installing disable-ota
Removing package disable-ota from root...
Installing disable-ota (1.0.3) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/disable-ota_1.0.3_mipsel.opk.
Installing webif (1.2.5-13) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/webif_1.2.5-13_mipsel.opk.
Configuring webif.
SMART: (PASSED)
startstop: 11514
realloc: 1225
hours: 6114
spinretry: 0
pending: 0
offline: 0
Configuring disable-ota.
Re-installing fan
Removing package fan from root...
Installing fan (1.0.0) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/fan_1.0.0_mipsel.opk.
Configuring fan.
Re-installing multienv
Removing package multienv from root...
Installing multienv (1.7-1) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/multienv_1.7-1_mipsel.opk.
Configuring multienv.
Re-installing redring
Removing package redring from root...
Installing redring (2.17) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/redring_2.17_mipsel.opk.
Redring install ()
Configuring redring.
Re-installing rsvsync
Removing package rsvsync from root...
Installing rsvsync (1.0.3) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/rsvsync_1.0.3_mipsel.opk.
Configuring rsvsync.
Re-installing tmenu
Removing package tmenu from root...
Installing tmenu (1.12) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/tmenu_1.12_mipsel.opk.
Configuring tmenu.
Re-installing webif
Removing package webif from root...
Not deleting modified conffile /mod/webif/html/favicon.ico.
Installing webif (1.2.5-13) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/webif_1.2.5-13_mipsel.opk.
 
Why does fix-flash-packages try to install webif twice? And why did it work the first time and hang the second time?
 
I forced reinstallation of webif using this:

opkg install webif --force-reinstall

and then shutdown the HDR Fox T2 and power cycled it at the rear panel (shouldn't be necessary but sometimes seems to help).

and things are now working rather better. But I still can't get "fix-flash-packages" to complete without error, it now says this (and only makes one attempt to install webif I note):

>>> Beginning diagnostic fix-flash-packages

Running: fix-flash-packages
Re-installing dbupdate
Removing package dbupdate from root...
Installing dbupdate (1.0.0) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/dbupdate_1.0.0_mipsel.opk.
Configuring dbupdate.
Re-installing disable-dso
Removing package disable-dso from root...
Installing disable-dso (0.2) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/disable-dso_0.2_mipsel.opk.
Configuring disable-dso.
Re-installing disable-ota
Removing package disable-ota from root...
Installing disable-ota (1.0.3) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/disable-ota_1.0.3_mipsel.opk.
Configuring disable-ota.
Re-installing fan
Removing package fan from root...
Installing fan (1.0.0) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/fan_1.0.0_mipsel.opk.
Configuring fan.
Re-installing multienv
Removing package multienv from root...
Installing multienv (1.7-1) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/multienv_1.7-1_mipsel.opk.
Configuring multienv.
Re-installing redring
Removing package redring from root...
Installing redring (2.17) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/redring_2.17_mipsel.opk.
Redring install ()
Configuring redring.
Re-installing rsvsync
Removing package rsvsync from root...
Installing rsvsync (1.0.3) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/rsvsync_1.0.3_mipsel.opk.
Configuring rsvsync.
Re-installing tmenu
Removing package tmenu from root...
Installing tmenu (1.12) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/tmenu_1.12_mipsel.opk.
Configuring tmenu.
Re-installing webif
Removing package webif from root...
Not deleting modified conffile /mod/webif/html/favicon.ico.
Installing webif (1.2.5-13) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/webif_1.2.5-13_mipsel.opk.
SMART: (PASSED)
startstop: 11520
realloc: 1225
hours: 6115
spinretry: 0
pending: 0
offline: 0
Configuring webif.
Collected errors:
* file_md5sum_alloc: Failed to open file /mod/webif/html/favicon.ico: No such file or directory.

>>> Ending diagnostic fix-flash-packages
 
Your last 'fix-flash-packages' run looks fine. I always get the message about it being unable to open 'favicon.ico': I think it must be a bug in the diagnostic itself. All 'favicon.ico' is is the little blue-rimmed oval icon that appears in the address bar of your browser when you open webif.
 
MontysEvilTwin said:
Your last 'fix-flash-packages' run looks fine. I always get the message about it being unable to open 'favicon.ico': I think it must be a bug in the diagnostic itself. All 'favicon.ico' is is the little blue-rimmed oval icon that appears in the address bar of your browser when you open webif.
Click to expand...

Thanks, in which case it's all working again and it was the force reinstall of webif that fixed it. Why it got into such a state is a mystery, it was working fine yesterday.
 
Looks like something went wrong with the webif upgrade but it's hard to work out what. The force re-install should have fixed it.
 
I sometimes have issues when trying to upgrade the webif package which may be related to this. Quite often I find that opkg upgrade will hang when trying to download webif. When this happens I usually resort to manually downloading it with wget. However, I can only download it in chunks. It will download about 20% of the file and then hang. Looking at my router lights show no activity at this time. I then have to do 'wget -c' to get the next chunk and so on until the full file is downloaded. I can then upgrade webif with opkg install <filename>

I wonder if there is some funky firewalling going on somewhere which may be causing this problem. I assume that the reason that this appears to be specific to webif is that it is one of the largest packages.
 
xyz321 said:
I sometimes have issues when trying to upgrade the webif package which may be related to this. Quite often I find that opkg upgrade will hang when trying to download webif. When this happens I usually resort to manually downloading it with wget. However, I can only download it in chunks. It will download about 20% of the file and then hang. Looking at my router lights show no activity at this time. I then have to do 'wget -c' to get the next chunk and so on until the full file is downloaded. I can then upgrade webif with opkg install <filename>
Click to expand...
Yes, I've resorted to exactly that, and posted about this weirdness of the web server on a couple of separate occasions. One can only speculate based on the lack of action/feedback that it may be deliberate for whatever reason. Or it may not...
I wonder if there is some funky firewalling going on somewhere which may be causing this problem. I assume that the reason that this appears to be specific to webif is that it is one of the largest packages.
Click to expand...
It might well be the largest but it's less than a couple of MB, which is hardly large in terms of shifting files around any sort of modern infrastructure.
 
prpr said:
It might well be the largest but it's less than a couple of MB, which is hardly large in terms of shifting files around any sort of modern infrastructure.
Click to expand...
True but most other commonly used packages are probably less than 20% of the size of the webif package. This may be the reason that webif seems most commonly affected.
 
I have been trying a few experiments. The final message before a hang is an outgoing TCP ACK packet to which it receives no response. It does eventually fail and then retry after the default wget read timeout of 15 minutes.

If I try changing the wget bw linit to 300KBps then it downloads fine but the problem reappears at 400KBps. Unfortunately the busybox version of wget dors not support the bw-limit option.
 
I'm not aware of any firewalling or bandwidth limits at the ISP end but I will see what I can find out. Package downloads are just flat files being served by Apache 2.4 so I wouldn't expect any problems!
 
Unfortunately I can't reproduce this from here. I'm running the Apache benchmark tool on a Mac laptop connected via wireless to my broadband router. My line speed is around 30Mb/s on a good day.

Code: 
% ab -n 100 -c 5 http://hpkg.tv/hdrfoxt2/base/webif_1.2.6-2_mipsel.opk
This is ApacheBench, Version 2.3 <$Revision: 1663405 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking hpkg.tv (be patient).....done


Server Software:        Apache
Server Hostname:        hpkg.tv
Server Port:            80

Document Path:          /hdrfoxt2/base/webif_1.2.6-2_mipsel.opk
Document Length:        1884300 bytes

Concurrency Level:      5
Time taken for tests:   175.811 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      188451400 bytes
HTML transferred:       188430000 bytes
Requests per second:    0.57 [#/sec] (mean)
Time per request:       8790.532 [ms] (mean)
Time per request:       1758.106 [ms] (mean, across all concurrent requests)
Transfer rate:          1046.78 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       43  141  51.6    137     264
Processing:  3050 8550 3792.2   7703   20019
Waiting:       45  146  59.4    137     295
Total:       3181 8690 3797.3   7835   20180

Percentage of the requests served within a certain time (ms)
  50%   7835
  66%   9019
  75%  10643
  80%  11589
  90%  13767
  95%  17392
  98%  19889
  99%  20180
100%  20180 (longest request)
 
xyz321 said:
I have been trying a few experiments. The final message before a hang is an outgoing TCP ACK packet to which it receives no response. It does eventually fail and then retry after the default wget read timeout of 15 minutes.

If I try changing the wget bw linit to 300KBps then it downloads fine but the problem reappears at 400KBps. Unfortunately the busybox version of wget dors not support the bw-limit option.
Click to expand...
In my testing, disabling tcp window scaling on the Humax solves this. Not saying it's a problem at the Humax end but this looks like a good workaround.

sysctl -w net.ipv4.tcp_window_scaling=0
 
af123 said:
In my testing, disabling tcp window scaling on the Humax solves this. Not saying it's a problem at the Humax end but this looks like a good workaround.

sysctl -w net.ipv4.tcp_window_scaling=0
Click to expand...

Thanks! Chances are I'll completely forget this by the next time it happens, but there's a chance a search of the forums will find this thread and answer.
 
Click your user name at top right, go to "your content", and this topic will be listed there.
 
Last edited:
You must log in or register to reply here.
Back
Top