• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Crash message Some.... may be deleted...."

Trev

Trev

The Dumb One
Well, lets start a thread that puts this "May be deleted" stuff to bed once and fall all by answering the following without shed loads of code that needs a black belt script kiddie to understand it.
1 When you get the message, has anything actually been deleted?
2 What has been deleted? Although this is fairly irrelevant as log as the answer to 3 is "Yes".
3. Is there a simple method of re-instating the deleted stuff (like clicking a button on the diagnostic page without having to remember what script to run.? (If not, why not?)
 
For the level of detail you say you want:

1. Maybe
2. Doesn't matter
3. WebIF >> Diagnostics and click "fix-flash-packages" from the drop-down list of pre-defined diagnostics.
 
Trev said:
Well, lets start a thread that puts this "May be deleted" stuff to bed once and fall all by answering the following without shed loads of code that needs a black belt script kiddie to understand it.
1 When you get the message, has anything actually been deleted?
Click to expand...
Black Hole said:
1. Maybe
Click to expand...
:rolling:
I'm not sure of the context of this "may be deleted" query. The damned search facility won't allow me to search for "may" and "be"!
BH has it right though. Has anything been deleted? Maybe.
As a very lazy programmer I've been known to trap too many errors and catch them in just one place. Depending on what caused the error, something may have happened. On the other hand it might not. :D
 
It's a 'quantum delete' then - you need to go and look to get the event to actually resolve to something measurable in reality.
 
Black Hole said:
For the level of detail you say you want:
1. Maybe
2. Doesn't matter
3. WebIF >> Diagnostics and click "fix-flash-packages" from the drop-down list of pre-defined diagnostics.
Click to expand...
Thanks for your answer BH, but No, that isn't the level of detail that I want.
Your answer to Q1 does not answer it.
Q2 Agreed if Q2 was "No" as the Q is irrelevant
Q3 I said without having to remember stuff.

Surely if some bit of code has set a flag or whatever to trigger the damn message, then surely whatever set the flag should know what it has deleted, or indeed whether it has deleted something or not. It says check the crash log which says something along the lines of "Humax crashed at....". I bloody well know that, the stupid message has just said so.

If stuff has indeed been deleted, then why does my box and all the packages seem to work OK. I have had 7 crashes since Oct 2108 and have never run fix-flash-packages, so if anything has been deleted, then it ain't anything important.

The level of detail that I would like does not include the pages of code that I don't understand that caused me to ask in this new thread as someone pointed out the other was going a long way off topic. (And breath).
 
Trev said:
(And breath)
Click to expand...
?

"breathe" shirley

Trev said:
I said without having to remember stuff.
Click to expand...
I agree the interface could be friendlier, but not too hard shirley?

In any case, I don't agree that the right process is to have a convenient button to press to fix it and forget about. What it needs is a strongly worded message that pressing the button to fix it as a one-off is OK, but if that results in another immediate crash alarm bells need to be sounded.

Please do not press this button. <PRESS>. Please do not press this button again.
 
Last edited:
As an aside, it seems to me a rare occurrence that my HD-FOX crashes, whereas my three HDR-FOXes all crash on a regular basis (at least every couple of weeks). Apart from the obvious physical difference, the only significant difference of configuration is that the HD-FOX is not a client of RS.
 
Black Hole said:
Please do not press this button. <PRESS>. Please do not press this button again
Click to expand...
And then what happens?
"Breath", "2108". I told you I needed something simple. It's not really 2108, it's my number dyslexia striking again or a perhaps a typo. I can't remember which, as it was so long ago that I typed it.
 
Trev said:
Well, let's start a thread that puts this "May be deleted" stuff to bed once and fall all by answering the following without shed loads of code that needs a black belt script kiddie to understand it.
...
Click to expand...
I'm up.

0. The message says "disabled" not "deleted", as any affected package hasn't actually been deleted, only some of its files.
1. When you get the message, has anything actually been deleted?
Click to expand...
Yes. You will have webif installed and its dependency nugget is one of the packages that will be affected. Other popular packages affected included ir, fan, redring and dlna-servername. Those are all the potential victims on my system. Undelete is another.
2. What has been deleted? Although this is fairly irrelevant as log as the answer to 3 is "Yes".
Click to expand...
Any pre-load library in /mod/boot/2; any hook program in /mod/boot/bootstrap.d. Well, you did ask. Incidentally, nugget has one of each.
3. Is there a simple method of re-instating the deleted stuff (like clicking a button on the diagnostic page without having to remember what script to run.? (If not, why not?)
Click to expand...
Running the fix-flash-packages diagnostic will definitely do so, since it force-reinstalls any package that had put a file in one of the two flash filesystems, such as the files listed under #2 above.
 
Last edited:
The original idea of the plugin disable "feature" was a safety net to protect against bugs in the plugin code. These plugins integrate with the Humax software at a low level and do things like directly manipulating memory, replacing library functions and even calling directly into Humax code. This has associated risks; a bug here could crash the Humax software, causing a reboot, and - if early enough - this would result in a reboot loop from which it is difficult to recover. I know, this happens a lot during plugin development!

The plugins are only disabled if the crash occurred early in boot (within 60 seconds) and this is not something which I expected to be a common occurrence; that assumption turned out to be wrong.

It's obvious that this whole thing needs improving. My own local copy only disables things if there were two reboots within 60 seconds of boot that occurred within 5 minutes of each other. It's dated 2014 but it doesn't look like I ever updated the multienv package. That's a good start that should stop this happening for most people. I'll take the additional ideas for improving the messages too and put a test package out for review.
 
OK. I implied deleted when I should have said disabled. Sorry. My bad. But without the error message in front of me as I typed, I apologise for not remembering the exact wording. But, thank goodness, it wasn't so incorrect so that everyone else didn't have a clue as to what I was talking about. I did see som 'rm' s in the code in the other thread and assumed that this was a remove command which further strengthened my incorrect deduction.

Right then. If there is some code in there that disables 'some packages' why can't it write to a file which packages it has disabled? Or am I missing something.
Also, despite getting the message several times, my box and the CF has not broken as a consequence. So presumably packages have not been disabled for my crashes.
 
Trev said:
Right then. If there is some code in there that disables 'some packages' why can't it write to a file which packages it has disabled? Or am I missing something.
Also, despite getting the message several times, my box and the CF has not broken as a consequence. So presumably packages have not been disabled for my crashes.
Click to expand...

Nobody has so far mentioned a discussion some time back that disabling packages after crash was no longer that important after improvements to the webif. A way to prevent such disabling was offered which I implemented, though I forget how it was done. So far, I haven't noticed any ill effects.

This is what I now get in my crash.log:

Code: 
 26       ... flag prevented plugin disable ...
25    Humax crashed at Sat Oct 12 20:09:28 UTC 2019 - Uptime: 56655

It is, however, mildly irritating that the "some plugins may have been disabled" notice is still displayed when restarting after a crash, even though it is no longer relevant.
 
Trev said:
Also, despite getting the message several times, my box and the CF has not broken as a consequence. So presumably packages have not been disabled for my crashes.
Click to expand...
Let's see the output of these then (yes, you do need to be a little bit of a copy/paste script kiddie):
Code: 
humax# ls -l /mod/boot/bootstrap.d/
humax# ls -l /mod/boot/2/lib*
humax# opkg search */mod/boot*|sort|uniq
Trev said:
And does that get rid of the crash message as well?
Click to expand...
No. It just stops the "may have been disabled" bit.
 
Telnet or WebShell to the Humax and then cli to get to the command prompt (humax# ).
 
You must log in or register to reply here.
Back
Top