running custom commands during sysupgrade -

Adrian Schmutzler mail at adrianschmutzler.de
Fri Oct 16 19:15:38 EDT 2020


Hi Sven,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> On Behalf Of Sven Roederer
> Sent: Samstag, 17. Oktober 2020 00:51
> To: openwrt-devel at lists.openwrt.org
> Subject: running custom commands during sysupgrade -
> 
> Hi,
> 
> based on my setup for some 8/32 MB devices I'd like to run a custom script
> before / during sysupgrade.  The main task of the script should be to free
> additional RAM, as I suspect some soft-bricks and aborted upgrades to a
> OOM- situation.

it's not exactly what you are looking for, but I'm sharing it anyway in case it helps you somehow:

With our downstream (Freifunk) firmware, we already had the problem of 4/32 devices being soft-bricked quite a while ago (I'd say since 17.01 or 18.06). Out of a few hundred TL-WR841N upgrades, it was about 3 % fallout (per upgrade, not accumulated). Devices could be recovered via TFTP easily, but you had to drive around and pick them up. Several people used to always do a reboot before upgrade in order to prevent that.

Fortunately, and I don't fully understand why, we were able to drive this to effectively zero by simply running

echo 3 > /proc/sys/vm/drop_caches

directly before sysupgrade. Out of a few hundred upgrades since then, I haven't had a single soft-brick. I do occasionally have the situation that the device reboots into the old firmware again (i.e. upgrade failed in an early stage), but for some reason the soft-bricks were completely gone.

Regarding your actual question, we have a custom upgrade script for our firmware where the command above is simple the line before calling "sysupgrade $FILE", so we didn't touch OpenWrt routines at all here.

Sorry for wasting your time if that's an old hat to you.

Best

Adrian

> 
> To me the /lib/upgrade folder seems a good place to add such scripts, as the
> *.sh files there will be sourced already, So additional patching is not required.
> 
> My problem is: adding a script
> --------------------------
> root at gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-
> ram.sh
> ffberlin_freeup_ram() {
>   # remove LuCI-caches
>   rm >/dev/null -f /tmp/luci-indexcache*
>   rm >/dev/null -rf /tmp/luci-modulecache } ffberlin_freeup_ram
> ---------------------------------
> works as expected. The files are delete the the firmware gets flashed. But
> just adding  a "ifdown" or "/etc/init.d/<service> stop" make the upgarde fail
> -------------------------------
> root at gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-
> ram.sh
> ffberlin_freeup_ram() {
>   # stop uhttpd and luci
>   /etc/init.d/uhttpd stop
>   # remove LuCI-caches
>   rm >/dev/null -f /tmp/luci-indexcache*
>   rm >/dev/null -rf /tmp/luci-modulecache } ffberlin_freeup_ram
> -----------------------------------
> 
> The Upgrade starts as expected and runs up to
> 
> Saving config files...
> Commencing upgrade. Closing all shell sessions.
> 
> and then times out. on the serial console I can see that the board just
> reboots after some time.  Normally it will do:
> 
> Watchdog handover: fd=3
> - watchdog -
> killall: telnetd: no process killed
> killall: ash: no process killed
> Sending TERM to remaining processes ... netifd odhcpd uhttpd udhcpc
> odhcp6c ntpd dnsmasq pingcheck crond ubusd askfirst urngd logd rpcd
> hostapd Sending KILL to remaining processes ... netifd uhttpd dnsmasq
> pingcheck sh sh rpcd netifd uhttpd dnsmasq sh rpcd rpcd Switching to
> ramdisk...
> Performing system upgrade...
> Unlocking firmware ...
> 
> Writing from <stdin> to firmware ...
> Appending jffs2 data from /tmp/sysupgrade.tgz to firmware..
> 
> Upgrade completed
> Rebooting system...
> umount: can't unmount /dev: Resource busy
> umount: can't unmount /tmp: Resource busy [  343.465535] reboot:
> Restarting system
> 
> 
> Any idea what is causing this behavior?
> Is my idea a totally wrong approach?
> 
> 
> Thanks Sven.
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20201017/af9325b3/attachment.sig>


More information about the openwrt-devel mailing list