Change reset behavior, etc/button.rc/reset not working

Hi friends, I know this may be asked a couple of times, but online resources didn't help.
I have an unconventional openwrt install (a porting of openwrt on a telco router) which I configured for my needings and now working fine. Now I would like to come back at this point when I press the reset button on the back of my router. As I can not build a custom openwrt build because of my situation the only option is to change the rc.button script to get some other things done but unfortunately changes to /etc/rc.button/reset does not make much. I'll explain better
To test the behavior of the reset script, I added a mkdir /home/itworked && after the reset script. This is how reset script looked after the change

#!/bin/sh

[ "${ACTION}" = "released" ] || exit 0

. /lib/functions.sh

logger "$BUTTON pressed for $SEEN seconds"

if [ "$SEEN" -lt 1 ]
then
	echo "REBOOT" > /dev/console
	sync
	reboot
elif [ "$SEEN" -gt 5 ]
then
	echo "FACTORY RESET" > /dev/console
	jffs2reset -y && mkdir /home/itworked && reboot &
fi

return 0

if I vi /etc/rc.button/reset and reboot the router my change is kept in the file but as I reset the router, the original untouched reset file is restored without any changes made and without making dir itworked in home. I know that openwrt is an overlay filesystem but why my command isn't executed for the first time either?
Is there something I can do to append a custom .sh script after the jiffs2reset and make this work?

Why don't you keep your working config in /etc/backup (just copy the /etc/config folder to /etc/backup) and modify the reset button script to copy from backup to config instead of jffs2reset?

Another option is to "burn" the settings into a custom ROM.

See, for example, https://openwrt.org/docs/guide-developer/build-system/use-buildsystem#custom_files or similar for using the image builder.

1 Like

sysupgrade -b and sysupgrade -r could be of use here.
Note that these do not completely return to original configuration, since packages that have been installed or files added outside of the sysupgrade "keep" system will not be deleted.

Could also work to tar up the whole /overlay/upper tree then delete and restore it. You also want the tar file with the original settings to survive this process so that it can be done more than once.

2 Likes

Would have been my first suggestion, but:

3 Likes

I'm afraid the problem is deeper.
I just don't understand why but editing reset file in rc.button folder doesn't work by any chance.
Tried

#!/bin/sh

[ "${ACTION}" = "released" ] || exit 0

. /lib/functions.sh

logger "$BUTTON pressed for $SEEN seconds"

if [ "$SEEN" -lt 1 ]
then
	echo "REBOOT" > /dev/console
	sync
	reboot
elif [ "$SEEN" -gt 5 ]
then
	echo "FACTORY RESET" > /dev/console
	mkdir /home/itworked && reboot &
fi

return 0

and it reset as usual
also sending

#!/bin/sh

[ "${ACTION}" = "released" ] || exit 0

. /lib/functions.sh

logger "$BUTTON pressed for $SEEN seconds"

if [ "$SEEN" -lt 1 ]
then
	echo "REBOOT" > /dev/console
	sync
	reboot
elif [ "$SEEN" -gt 5 ]
then
	mkdir /home/itworked && reboot &
fi

return 0

resetting as usual.

Is there another way to change the reset button script? A uci set command? I managed to change wps button behavior through

set uci.button.button.@wps.handler '/path/to/script.sh'

Is there a way for the reset button also?

Another little update:
when I click the reset button if I quickly logread before ssh is turned off it throws this message

Sat Jul 20 07:19:42 2019 user.notice [Buttons]: pressed BTN_0

could that be useful to trace the real reset script?

1 Like

https://openwrt.org/docs/guide-user/hardware/hardware.button

@vgaetera I already read this but it says just how to add a button and not how to change behavior of an existing one. Also I don't understand how the Hardware-level gpio pin triggering is linked to the button name. Is it just BTN_0 the HWID of the reset button? In this case, creating a new button as the tutorial says with the name BTN_0 and with my script as header should work. Is this the case?

Modify the script so it doesn't ever call reboot, it just changes a file or something. Then see if it still reboots when you press the button.

2 Likes

ok @vgaetera just tried sending this commands one by one but still don't work, it resets deleting everything as usual

uci add system button
uci set system.@button[-1].button="BTN_0"
uci set system.@button[-1].action="released"
uci set system.@button[-1].handler="mkdir /home/itworked"
uci set system.@button[-1].min="5"
uci set system.@button[-1].max="30"
uci commit system

@mk24
As I said some posts ago, changing /etc/rc.button/reset script doesn't work in any way. Almost sure that when I push the reset button that's not called either. Even if I delete it, it still resets. That script is no use

ubus call system board
find /etc /sys -iname "*button*"
grep -C 1 -i -r -e "BTN_" -e "BUTTON" /etc 2>/dev/null

What is this for? Explain me a bit

Which device you are talking about?
the button names can vary between devices, and are defined in DTS or other device definoitions files.

Button name is BTN_0 as I read from logread and the button we're talking about is reset. Router is Telstra tg789vac v2 with rooted firmware based on Chaos Calmer 15.02

Button handling etc. has changed somewhat during the years, so the advice given for current firmware versions may be different than the suitable advice for the ancient CC 15.05 (there is no 15.02).

With that old firmware, the esiest thing might be to copy the /etc/rc.button/reset script to be /etc/rc.button/BTN_0 script (and I think that it needs to be chmodded executable, also).

The problem is that, even if I remove completely the reset file on that folder, reset works as usual. So I think that's not the script we're looking for. It should be somewhere else

Try to collect the data related to the issue.

This worked! I found out that the button header was on /etc/config/button
And this approach is useful for searching other keywords too! Thanks for this @vgaetera

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.