Let me respond to Jeroen's post as well..
- first of all, has it really been proven, that authuld is the culprit for rebooting the server ?
* I'm not sure the authuld is the culprit, but it sure seems to reboot at the stage that authuld is started complely. It starts very early in the process:
-> If that is the case, does it do it by directly communicating with the control units or does it also use MicomCtrl to do so ?
-> If it is MicomCtrl that is used to do so, one could try mask ( overlay ) that binary with a script ( mount -o bind ... ) and ignore the reboot request
* The MiComCtrl is not running anymore caused by switching of the watchdog in the service-menu??
- is authuld started by exeDSP or is it started before exeDSP ?
* It looks to me authuld is started before the exeDSP-process; the pid is lower.
- can't authuld be stopped as one of the first actions before exeDSP is started ?
* I'm not able to kill the authuld process.
- can't authuld be overlayed with something less disruptive ( e.g. mind -o bind /mtd_rwarea/my_modified_empty_authuld_script /bin/authuld ) ?
* I'm not sure; the fact that I'm not able to kill it, gives me little hope.
- one could also attempt to do some of these actions from within /mtd_boot/rc.local ( but this one is again a more risky activity, as noone has reflashed the mtd_boot partition as yet )
* Flashing the mtd_boot partition is no option... yet, cause I have no shell access on the terminal as backdoor. I can get that by killing the exeDSP-process, but that's only possible from a remote-terminal. The terminal seems not to respond on ctrl-c.
I still think the key is the authuld. We need to find out how it works, so we can control it.
Authuld is a kernel initiated userspace daemon. It is responsible for making sure that all system components are authentic and have not been modified. You cannot kill it since the kernel made it a kernel thread. It can work in two modes: Normal and Development mode. Normal mode will shut down the system in the event of any modification to partitions. The development mode won't. Unfortunately this cannot be changed (easily, more about this later on) once the thread started.
I am still debugging authuld but for now it seems that it does checks on partitions bml0/6,7,8,9,10 and 11. And also the kernel checks for a genuine copy of authuld just before it executes it.
Authuld does not use MicomCtrl! It doesn't need to as all MicomCtrl does is open the serial line ttyS0 and send packets (commands) to <well, I'm not really sure to what. It looks as there's another arm powered circuitry in the TV which controls the main CPU and other peripherals of the TV>
Authuld sends the commands to ttyS1 to shut the TV down.. Simple as that.
There are two files that the kernel and authuld use to communicate with each other.. They are /dtv/.ku and /dtv/.uk . You can guess these are for the two-way communication (KERNEL-USERSPACE and vice versa). Why it was done this way is beyond me... Understandably.. I'm just a arm kernel enthusiast with a samsung tv..
Question for Jeroen: Does your TV work at the moment? Or it keeps restarting every two minutes or more often?
Did you put the old exe.img back to bml0/8?