Best way to run script only after factory reset

It is imagebuilder that adds script to squashfs, it survives factory reset, but you need to maintain script in all your sysupgrades.

I always mod the soure code for my personal uses in my local computer. Sometimes change the /etc/config/* directly, sometimes put a script in the rc.local file.

With modify "directly" the source code I was referring to edit the core source files, not the /files folder, which is what I am using to override the defaults and the way I find proper for this case.

I always build my code from orignal clone, never use the imagebuilder method.

Does not matter, you can add script to squashfs yourself even in firmware-selector web ui

Maybe I'm stupid, everytime compile a new version my build, I have to mod all the following files:

$ git checkout
M	package/base-files/files/bin/config_generate
M	package/base-files/files/etc/init.d/system
M	package/base-files/files/etc/inittab
M	package/base-files/files/etc/rc.local
M	package/base-files/files/etc/sysctl.d/10-default.conf
M	package/base-files/files/etc/uci-defaults/12_network-generate-ula
M	package/kernel/mac80211/files/lib/wifi/mac80211.sh
M	package/network/services/dropbear/files/dropbear.config
M	package/network/services/dropbear/files/dropbear.init
M	target/linux/ramips/base-files/etc/inittab
M	target/linux/ramips/mt76x8/config-5.15

(not included my personal packages folders)

pablo, IMHO you are right in every point. particularly in being surprised that there is no standard method for this detection (i share the feeling), and in that sensing sysupgrade.tgz is a brittle and ugly hack.

sysupgrade.tgz can't be thrown around so lightly. not before verifying what happens with UBIFS overlays. not before looking at eMMC devices with F2FS/ext4 overlays. certainly not without looking at devices with modifiable rootfs and no overlay.

on the other hand, you could propose a standard method yourself and make a PR.

without thinking much, given the available info, i think the API should expose an isRestoringSettings() "something", being true after a sysupgrade with retention and after a plain settings restore.

so your uci-defaults code could would just do an:

if (isRestoringSettings()) exit 0;

at the beginning and be done with the problem.

by a "something" i mean maybe an environment variable, or a function, or an alias... IDK. exactly how to implement that something could be tricky or not, depending on how the various possible setups of openwrt storage are implemented.

as an openwrt api for uci-defaults, it is perfectly ok for the implementation to depend on sensing sysupgrade.tgz. because if low level changes are done to sysupgrade, then they should also fix isRestoringSettings() to retain the api's semantics.

1 Like

of course another api would be to have a different uci-reset directory altogether.

come to think about it, this problem is so pressing that even the firmware selector code template is buggy:

# Configure WLAN
# More options: https://openwrt.org/docs/guide-user/network/wifi/basic#wi-fi_interfaces
if [ -n "$wlan_name" -a -n "$wlan_password" -a ${#wlan_password} -ge 8 ]; then
  uci set wireless.@wifi-device[0].disabled='0'
  uci set wireless.@wifi-iface[0].disabled='0'
  uci set wireless.@wifi-iface[0].encryption='psk2'
  uci set wireless.@wifi-iface[0].ssid="$wlan_name"
  uci set wireless.@wifi-iface[0].key="$wlan_password"
  uci commit wireless
fi

in reality that code shouldn't run after a retaining sysupgrade or a settings restore, but it does: instead of providing defaults, it overwites user settings, and i very much consider it a bug.

1 Like

two updates:

2 Likes

Thank you very much, great work. I will be testing this patch also!