Updating Firmware on HD-FOX T2

prpr

prpr

Well-Known Member
For what it's worth, I tried going from 1.00.08 straight to 1.02.31 mod 300 and the box refused to boot.
I installed 1.02.29 official which also upgraded the loader and then re-did 1.02.31 and it's now happy.

1.00.08 is a very strange beast. I tried manual tuning it and it added some channels with LCN 0, didn't add others at all, and refused to delete old channels which were already there.

What do I do with it now? I've got Telnet access but nothing responds on port 80 and "ps" shows nothing looking like a web server.
I haven't got any storage on it yet. Obviously this is required to install packages but I'd have expected the bootstrap web server.
Also, if I select "Network" from the storage menu, it spins for ages and then announces "No server found" or such like. I'd have expected it to find the HDRs on the network (DLNA stuff).
 
You should expect to see a minimal web page complaining that there is no suitable external storage attached.
 
I suspect you got past this stage now earlier but the process which should be running is called 'bootstrap'. If it isn't there then modinit.log may shed some light on why.
 
"bootstrapd" isn't running if you boot the HD without any storage. The log never showed it attempted anything apart from setting up the host name. Running it up manually from telnet allows connection from a browser which prompts to install the Web interface (nowhere have I seen what BH said). Attempting it obviously fails, but I tried it just to see what happens.

(The missing DLNA was caused by a very stupid TP-Link WR743 which doesn't update its ARP cache when IP addresses change. That's in the network between the HDRs and the HD as they're on different floors. I've been caught by this before, but it always get me every time. Resolved by rebooting it, and all now works.
Edit: This got permanently resolved after more problems... by me putting my foot through the stupid TP-Link box and getting some decent kit.)
 
Last edited:
Hmm. I just tried it with the UPD unplugged, and got a failure to connect. I'm sure it has worked in the past, I had a dialogue with AF about it.
 
Here is the log info:
Code: 
#humax# ls -l /tmp
-rw-r--r--  1 root  root  0 Jan  1  2000 banner.log
-rw-r--r--  1 root  root  4 Jan  1  2000 dnsmasq.pid
-rw-r--r--  1 root  root  41 Jan  1  2000 hosts
-rw-r--r--  1 root  root  0 Jan  1  2000 if-up
-rw-r--r--  1 root  root  6 Jan  1  2000 ifstate
-rw-r--r--  1 root  root  534 Jan  1  2000 modinit.log
-rw-r--r--  1 root  root  209 Jan  1  2000 rsvsync.log
-rw-r--r--  1 root  root  0 Jan  1  2000 utmp
-rw-r--r--  1 root  root  0 Jan  1  2000 xinit.log
humax# cat /tmp/modinit.log
=== Sat Jan  1 00:00:10 GMT 2000 - modinit - setup_hosts ===========================
=== Sat Jan  1 00:00:10 GMT 2000 - setup hosts ===========================
Kernel IP routing table
Destination  Gateway  Genmask  Flags Metric Ref  Use Iface
192.168.0.0  *  255.255.255.0  U  0  0  0 eth0
default  192.168.0.254  0.0.0.0  UG  0  0  0 eth0
  Interface: [eth0]
  IP: [192.168.0.17]
=== Sat Jan  1 00:00:10 GMT 2000 - complete ===========================
This just looks like "modinit setup_hosts" is being called, but I can't find where.
I don't understand why there isn't a rag.log file either.
 
There's a spelling error in /bin/tmenu as well:

/bin/tmenu: echo "This process wil convert the USB flash drive to EXT2"\
 
Also relating to tmenu, it looks like the flash version is later than the disk version. Is this intentional or an oversight?
Code: 
humax# diff /bin/tmenu /var/lib/humaxtv/mod/2/tmenu
--- /bin/tmenu
+++ /var/lib/humaxtv/mod/2/tmenu
@@ -1,8 +1,8 @@
#!/bin/sh
-# $Id: tmenu 2052 2014-05-18 21:18:53Z af $
+# $Id: tmenu 2028 2014-05-07 21:49:40Z af $
-vers=1.11
+vers=1.10
pkgtmenu=/var/lib/humaxtv_backup/mod/tmenu
if [ -x $pkgtmenu -a "$0" = /bin/tmenu -a $pkgtmenu -nt $0 ]; then
@@ -348,7 +348,7 @@
     if ays "enter maintenance mode?"; then
       [ -d /var/lib/humaxtv/mod ] || \
        mkdir /var/lib/humaxtv/mod
-       echo 2 > /var/lib/humaxtv/mod/maintenance.boot
+       touch /var/lib/humaxtv/mod/maintenance.boot
       if [ $? -ne 0 ]; then
         echo "Problem enabling maintenance mode!"
         return
 
Last edited:
Black Hole said:
Hmm. I just tried it with the UPD unplugged, and got a failure to connect. I'm sure it has worked in the past, I had a dialogue with AF about it.
Click to expand...
It turns out that the "bootstrapd" web server only runs if there is a UPD (eek! I feel a bit sick...) plugged in. If it is not formatted in an acceptable way, then you get the message telling you how to go about preparing it. If it is, then you get the normal "install the Webif" page.

That leads on to another slight irritation (with the tmenu code), in that you can only use the automated prep. in maintenance mode if your USB stick is already formatted with a vfat filesystem. If it's anything else then it point blank refuses to have anything to do with it. This is a bit ridiculous really. Why should it matter what's on it to start with? You want to blast it all anyway...
 
Last edited:
Maybe that was it then, I just assumed the message would appear if there was no suitably prepared UPD or none at all. Needs tweaking.
 
prpr said:
This just looks like "modinit setup_hosts" is being called, but I can't find where.
I don't understand why there isn't a rag.log file either.
Click to expand...
Probably from the DHCP client code on acquisition of an address. See /usr/share/udhcpc/default.script
run-and-gun (rag.log) is fired by mdev so only runs once a disk is connected, hence no log.
It's tricky to determine that no disk is connected as it may not always be immediately detected, but I will be able to come up with something for the next version.
 
prpr said:
Sorry, this thread kinda got hijacked. I wonder if a mod. could split it at an appropriate point to the custom firmware section please?

Also relating to tmenu, it looks like the flash version is later than the disk version. Is this intentional or an oversight?
Code: 
humax# diff /bin/tmenu /var/lib/humaxtv/mod/2/tmenu
--- /bin/tmenu
+++ /var/lib/humaxtv/mod/2/tmenu
@@ -1,8 +1,8 @@
#!/bin/sh
-# $Id: tmenu 2052 2014-05-18 21:18:53Z af $
+# $Id: tmenu 2028 2014-05-07 21:49:40Z af $
-vers=1.11
+vers=1.10
pkgtmenu=/var/lib/humaxtv_backup/mod/tmenu
if [ -x $pkgtmenu -a "$0" = /bin/tmenu -a $pkgtmenu -nt $0 ]; then
@@ -348,7 +348,7 @@
     if ays "enter maintenance mode?"; then
       [ -d /var/lib/humaxtv/mod ] || \
        mkdir /var/lib/humaxtv/mod
-       echo 2 > /var/lib/humaxtv/mod/maintenance.boot
+       touch /var/lib/humaxtv/mod/maintenance.boot
       if [ $? -ne 0 ]; then
         echo "Problem enabling maintenance mode!"
         return
Click to expand...
Intentional, or at least there was no point updating the packaged version for that change. CFW 3.00 uses that file to store a counter which it decrements each time it tries to start in maintenance mode. Once the counter reaches 0 it will revert to a normal boot. Previous CFW versions just used the file as a flag.

The script will always use whichever is the latest version.
 
prpr said:
That leads on to another slight irritation (with the tmenu code), in that you can only use the automated prep. in maintenance mode if your USB stick is already formatted with a vfat filesystem. If it's anything else then it point blank refuses to have anything to do with it. This is a bit ridiculous really. Why should it matter what's on it to start with? You want to blast it all anyway...
Click to expand...
Only supporting that one upgrade path should mean that the risk of overwriting something by mistake is reduced. It also simplifies the code and makes it easier to test.
For a normal user, it's straightforward enough for them to plug the stick into their computer and format it as FAT32 before starting the conversion process. For someone like you, it's no problem to do it all by hand anyway.
 
af123 said:
Only supporting that one upgrade path should mean that the risk of overwriting something by mistake is reduced. It also simplifies the code and makes it easier to test.
Click to expand...
I can see your point.
For a normal user, it's straightforward enough for them to plug the stick into their computer and format it as FAT32 before starting the conversion process.
Click to expand...
True, if it told you what the problem was, but it doesn't. It tests for specific things, so why can't it give specific error messages when it doesn't like something? I hate "There was an error" type messages, without giving any detail as to what it's unhappy with (and I mean in general across everything, not just the CF).
For someone like you, it's no problem to do it all by hand anyway.
Click to expand...
It is now I know how, but I had to dig about for the info. to work it out.
 
af123 said:
Probably from the DHCP client code on acquisition of an address. See /usr/share/udhcpc/default.script
Click to expand...
Ah, yes, didn't search through /usr
run-and-gun (rag.log) is fired by mdev so only runs once a disk is connected, hence no log.
Click to expand...
Thanks. I think I'd just about worked out how all this stuff hangs together after today's playing.
It's tricky to determine that no disk is connected as it may not always be immediately detected, but I will be able to come up with something for the next version.
Click to expand...
OK.
 
af123 said:
It's tricky to determine that no disk is connected as it may not always be immediately detected, but I will be able to come up with something for the next version.
Click to expand...
Whatever you came up with seems to work OK!
prpr said:
There's a spelling error in /bin/tmenu as well:

/bin/tmenu: echo "This process wil convert the USB flash drive to EXT2"\
Click to expand...
That's still wrong (both in flash and in the disk package).
 
prpr said:
That's still wrong (both in flash and in the disk package).
Click to expand...
I vaguely remembered that when building the latest firmware but couldn't find the reference. I'll fix it ready for the next one, if there ever is a next one : )
 
Just a minor observation: Web-If does not recognise the new HD-FOX kernel version. I presume it needs to be added to the kernel list.
 
I've already updated that in my development copy so it will be in the next release..
 
Thanks af123. I am always amazed by how quickly you release custom firmware versions after Humax make the standard versions available.
 
You must log in or register to reply here.
Back
Top