My Humax HDR-Fox T2 packed in

[Black Hole]

But what I don't understand then is why my box continues to work OK without ever using that command.

It might work "OK" from the point of view of normal operations, but some of the custom stuff won't be working when you peer into the detail. Fan, for example.

 

[Trev]

Fan continues to work, so does everything else as far as I can establish. I have had the 'disabled' warning several times over the last couple of years and never done anything ti fix it. Are things really disabled on a crash? If so, why have I not come across any that have been. IIRC the 'disabled' warning says 'may be disabled'. Don't 'they' know what will or will not be?

 

[prpr]

the 'disabled' warning says 'may be disabled'. Don't 'they' know what will or will not be?

It's a crap error message which has always annoyed me.
Anyway, I've had the automatic disabling disabled for years and never had a problem.

 

[MymsMan]

It's a crap error message which has always annoyed me.
Anyway, I've had the automatic disabling disabled for years and never had a problem.

Agreed, it would be much better if the Disabling process set a flag to definitively show it had done something. then at the next boot it could be checked and a warning shown to indicate that flash package HAD been disabled and to run the fix-flash-packages diagnostic, last step of the diagnostic would be to clear the flag.

 

[Trev]

And a message to tell you to run fix-flash if it has disabled any.

 

[hairy_mutley]

I don't trust my memory these days but wasn't there a sticky option to stop packages being disabled (it still put the message up).
I am not on the best kit for checking my T2, but wonder about the file /mod/boot/no_plugin_autodisable.

 

[Black Hole]

Crashes sometimes disable some of the packages which have bits installed in the flash storage. You can disable this automatic disabling by issuing the following at a command prompt:

humax# touch /mod/boot/no_plugin_autodisable

 

[prpr]

I don't trust my memory these days

Nor 6 years ago: https://hummy.tv/forum/posts/48801
Maybe it was all that pigeon chasing you used to do...

 

[Black Hole]

That was completely off my radar!

We're all nine years older than when we started all this, and it makes a huge difference (as I know only too well).

 

[/df]

So, is this disabling really still a thing?

It's apparent (/mod/etc/init.d/S30posttvcrash) that restarting with a crash log causes the notorious (or crap, take your pick) 'may be disabled' message to be written to a file /mod/tmp/notify.log that is then replayed in the pink pop-up box by the Webif if it finds it.

Equally diag fix-flash-packages just force-reinstalls any package that is recorded as having installed a file to one of the flash filesystems.

There is the Safe mode startup that can be triggered from the telnet menu or Webif, and causes the startup routines in flash /var/lib/humaxtv/mod/xinit.d/* to be skipped.

All in all, from scanning the start-up code and discussions in these forums, I don't see any sign of the active reboot loop protection that has been mentioned here and in documentation.

Is it actually the case that the threatened disabling only occurs if something -- system flush, Humax blob fsck-ing a flash filesystem, ... -- has deleted files from the flash startup directory, and that the CFW doesn't actively disable packages after (some sequence of) crashes, even if it may once have done so?

The following shell script, based on the fix-flash-packages diagnostic lists what the diagnostic would try to fix if run, and thus provides an answer to this question.

...
How do I find out what packages are disabled?
...

#!/bin/sh
# List flash package issues; return 1 if any
main() {

# format file1:file2...
local whitelist="/mod/boot/xinit.d/webshell"

local count=0
local uprm

for uprm in "/mod/var/opkg/info/undelete.postrm"; do
    if [ -f "$uprm" ] &&
        ls -al "$uprm" | grep -qv '^-rwxr-xr-x '; then
        echo "$uprm: wrong permissions"
        count=$(($count + 1))
    fi
done
# kludge structure needed because of no true global vars in POSIX shell
count=$((count+$(grep ^Package: /mod/var/opkg/status | cut -d: -f2- | cut -c2- | sort | uniq |
    while read pkg; do                                                         
        opkg files "$pkg" | grep ^/mod/boot/ |                                  
                while read ff; do                                              
                        if [ -n "$ff" ] && [ ! -f "$ff" ]; then
                                echo ":${whitelist}:" | grep -q ":${ff}:" ||
                                        echo "Package $pkg: missing flash file $ff"    
                        fi                                                     
                done                                                           
done |
        # wc may not be available          
        grep -c '' ) ))                                                        
[ $count -gt 0 ] && return 1
return 0     
}         

main

Updated to add a whitelist feature, as at least one installed file is meant to be deleted.

 

[af123]

So, is this disabling really still a thing?

Look at /mod/boot/posttvcrash, part of the multienv package.

 

[prpr]

It's apparent (/mod/etc/init.d/S30posttvcrash) that restarting with a crash log causes the notorious (or crap, take your pick) 'may be disabled' message to be written to a file /mod/tmp/notify.log that is then replayed in the pink pop-up box by the Webif if it finds it.

Here's a simple one liner that it could use to record which packages were actually disabled, at that time it does it, rather than the pathetic "some packages may be disabled" thing.

humax# (opkg search */mod/boot/bootstrap.d/*; opkg search */mod/boot/2/lib*.so*)|sort|uniq|cut -d\  -f1

Equally diag fix-flash-packages just force-reinstalls any package that is recorded as having installed a file to one of the flash filesystems.

That's overkill really. It 'fixes' anything with a file in flash, even though most things therein didn't get deleted.

In any case, deleting the files is a bit extreme - they could just be renamed which a) makes it easy to detect what has been disabled, and b) makes it easy to put back. What happens on boxes without net access for example? You're stuck if it crashes and files have just been deleted.

 

[Black Hole]

In any case, deleting the files is a bit extreme - they could just be renamed

I had assumed the reason for disabling these packages is because they patch the standard code - so wouldn't you need to unpatch the code? Otherwise they are no more dangerous than code on HDD.

 

[MymsMan]

I had assumed the reason for disabling these packages is because they patch the standard code - so wouldn't you need to unpatch the code? Otherwise they are no more dangerous than code on HDD.

Our confidence and experience in the reliability and quality of the CF code has increased over the years since the disabling was first introduced.
Do we actually know of any real world scenarios where disabling has been the right solution or is it, like banning the use of mobile phones on planes, a hypothetical risk that could be limited to much smaller list of files if it is needed at all.

 

[prpr]

I had assumed the reason for disabling these packages is because they patch the standard code - so wouldn't you need to unpatch the code?

I would say "hook" rather than "patch" - not quite the same thing. In either case, a crash/reboot loses them, so removing/renaming the files before the hook/patch is loaded at restart is sufficient to disable them.

like banning the use of mobile phones on planes

The last time I went on a plane I accidentally forgot to turn it off. The phone police weren't there on landing...

 

[/df]

Look at /mod/boot/posttvcrash, part of the multienv package.

Bah, thanks. I knew I'd seen it once, and should have seen where it's called from /etc/init.d/S90settop.

So the possible victims are libraries that get pre-loaded into the humax_tv process and the bootstrap programs that hook the process in some way.

On this basis there's no reason for the startup script /mod/etc/init.d/S30posttvcrash, also in the multienv package, not to be explicit about what's happened, eg like this:

#!/bin/sh                                                                      
                                                                               
main() {                                                                       
        local logf=/var/lib/humaxtv_backup/mod/posttvcrash.log
        local nlogf=/mod/tmp/notify.log                       
        local fDisabled=""                                    
                                                                               
        [ -f "$logf" ] || return 0     
        # Look for text from /mod/boot/posttvcrash when disabling packages
        { grep "Your Humax crashed " "$logf" && fDisabled="yes" ||        
                echo "Your Humax crashed."; } >> "$nlogf"                 
        [ -n "$fDisabled" ] &&                                                 
                echo "You should run the fix-flash-packages diagnostic." >> "$nlogf"
        echo " ... view the crash.log for more details." >> "$nlogf"           
        cat $logf >> /mod/tmp/crash.log                                        
        rm -f $logf                                                            
                                                                               
        return 0                                                        
}                                                                              
                                                                    
main

Or if this view prevails

...
In any case, deleting the files is a bit extreme - they could just be renamed which a) makes it easy to detect what has been disabled, and b) makes it easy to put back. What happens on boxes without net access for example? You're stuck if it crashes and files have just been deleted.

/mod/boot/posttvcrash could append .disabled instead of rm -f with a matching /mod/etc/init.d/S30posttvcrash and repair diagnostic.
However we are now massively off-topic in this forum.