June-25th-2020, 10:16 AM
Dear yoshikawa-san,
thank you for your reply. So it seems that we have more isolated the problem and reduce it to a configuration file that went corrupt maybe (which we don't know by 100% still right now)
I totally agree to your opinion A.) and B.) A loss of power can occur at any time in the field and you have no control of it when it will happen. Also your end customer has no control over the power of his installation.
Right now I have no immediate solution for you. Basically a container cannot access the main host OS like the web UI is able to. So a command like "reboot now" called in a container will never reset the whole device. At the moment only the web UI is able to reset netPI device.
First I want to wait for the opinion of the development team. Since this problem occured now since 4 year of netPI release I think they need to spent some time to solve the problem in a new firmware version in future. I have to wait for their answer first.
thank you for your reply. So it seems that we have more isolated the problem and reduce it to a configuration file that went corrupt maybe (which we don't know by 100% still right now)
I totally agree to your opinion A.) and B.) A loss of power can occur at any time in the field and you have no control of it when it will happen. Also your end customer has no control over the power of his installation.
Right now I have no immediate solution for you. Basically a container cannot access the main host OS like the web UI is able to. So a command like "reboot now" called in a container will never reset the whole device. At the moment only the web UI is able to reset netPI device.
First I want to wait for the opinion of the development team. Since this problem occured now since 4 year of netPI release I think they need to spent some time to solve the problem in a new firmware version in future. I have to wait for their answer first.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
