What makes remote reboot so unreliable?

R

rpb424

Active Member
As per the title really...

This may have been asked before but I couldn't obviously find anything. Just rebooted remotely having changed by SSH port number back to what I want it to be (it seems to randomly default back to 22 sometimes), and then rebooted from the webif (noting the warning), but it hasn't come back on, necessitating me waiting until i get home to press the button.

What makes the command line reboot process so unreliable? I should simply have restarted the SSH daemon instead.
 
SSH - it might have defaulted because of the recent update to the dropbear-ssh package which was to fix a security problem in the software. It shouldn't default back of course but that's the first time the package has been updated.

Remote reboot - sorry, no idea. I don't think anyone has investigated it. It doesn't make a lot of sense that it occasionally goes into standby.
 
My limited experience suggests that remote reboot works fine if the machine has been powered on manually. However, if it is powered on via a timer, then the remote reboot (issued between a pair of power on and power off events) will most likely fail with the machine going back into standby.
 
I have just confirmed this on my HD-FOX using the rs Schedule Reboot when idle. As stated above it doesn't happen if the box is switched on manually.
 
I find my HDR does not always start up again after a WebIF reboot, which will be a similar thing. We've known it is unreliable or a long time, which is one reason it is better to let the machine cycle through its own start-stop cycles.

The problem is to recreate the standard firmware's shutdown housekeeping sufficiently accurately, and then set the environment in such a way that when the CF hands control back to the standard firmware it believes it is being started up from the standby button. So far it's all guesswork and a pretty good job considering.
 
I am experiencing this on a regular basis with HDR3, which (unlike HDR1) I have configured to turn on and off on its own and therefore become available on the network (and have an opportunity to decrypt etc).

Proposition: the Humax is behaving (on reboot) as if it were recovering from a power interruption, and resuming the state it thinks it was in? Perhaps there is a way to influence this, or at any rate make the warning more informative.
 
Interesting: the normally reliable reboot on HDR1 failed to restart after restoring my recording schedule from backup after the retune.
 
You must log in or register to reply here.
Back
Top